Show TOC

Integration Directory TransportsLocate this document in the navigation structure

With Integration Directory transports you can transport configuration objects of the Integration Directory from one system to another. At configuration time you have the option of testing the configuration in a test directory. If the tests are successful, you can then transport the configuration objects in the test directory to the Integration Directory for the productive landscape.


SAP recommends that you work with a System Landscape Directory (SLD), in which you have entered the test environment systems and the productive environment systems for this procedure. Using groups and transport targets in the SLD, you can automatically convert the system names of the test system to the system names of the productive system. See SAP Note 764393 for alternative SLD scenarios.

Therefore, at configuration time, transports are not used to ship objects, but to test the configuration separately from the productive landscape before the configuration objects are used productively.

  • There are no software component versions in the Integration Directory. You can export all objects of a scenario, party, service, or individual objects.
  • No large transport landscape with multiple directories is required. As a rule, one test directory and one productive directory is sufficient. There is also a test repository and a productive repository. If required, you can of course also create three-tier or four-tier test landscapes.

    Objects in the Integration Directory reference objects in the ES Repository. We therefore recommend that you first transport the required ES Repository objects followed by the Integration Directory objects. The configuration is not complete if the Integration Directory references objects in the ES Repository that have not yet been imported. You can also import the missing objects into the ES Repository at a later date.

In the test scenarios at configuration time, it is not always the case that the most recent version from the test directory is transported to the productive directory. Often an older version is the more appropriate version. Therefore, unlike when importing in the ES Repository, when importing objects to a directory, version management always creates a new version for the objects:

In the example, the initial version V1 of an object is exported from the test directory. Since a new version ID is created when you import objects to the productive directory (here V3 for V1), you can import version V1 to the productive directory despite the fact that the more recent versions V2 and V3 have already been imported.

Support for Transports in the Integration Builder

You can transport objects in the Integration Builder in the following ways:

  • The transport wizard (menu Tools → Export Configuration Objects). In the wizard you can select the mode for the export (CMS transport or file system).
  • Transport using change lists. On the Change Lists tab page you can, using the context menu, release transportable change lists for a CMS transport. A file system-based export of a change list is not possible.

Options in the Transport Wizard

The Integration Builder provides the following options in the transport wizard for the transport or export of configuration objects:

  • When exporting the objects, you can restrict the object set exported, see below. You can only export active objects. If an object to be exported is not active, the last active version is exported.
  • If an object has been deleted, a Delete Version is exported so that the target Directory deletes the object when it is imported. In exceptional cases, it may be necessary to deactivate the export of delete versions. Delete versions are exported if the Include Deleted Objects checkbox is selected.
  • You can also simulate the export of objects. The export is not simulated if the Skip Preview checkbox is selected.
  • If you use the file system for the transport, you exchange the import or export files by using a directory on either the client (local PC) or the server.

Limiting the Object Set

You can select to export all objects in a configuration scenario, party, communication component, or folder. The Integration Builder then exports the configuration scenario (or the party, communication component, or folder) and all sub objects. You can also select individual objects by using the function for selecting individual objects .

Converting and Merging During Import

We recommend that you use one System Landscape Directory (SLD) that contains both the test and productive system landscapes. To import configuration objects into the productive directory from the test directory, you must define transport targets in the SLD. This means that test directory communication components, which are entered as business systems in the SLD, are assigned to the communication components of the productive directory, and dependent objects are converted. See SAP Note 764393 for alternative SLD scenarios.

For more information: Configuring Groups and Transport Targets .

Note the following for communication channels: To avoid messages being sent from a productive system to systems in the test landscape, the Integration Builder only exports a selection of attributes. Therefore, address data (host, port) and access data (user, password) are not contained in the export. In the adapter metadata in the ES Repository, such attributes are flagged as not transportable (they depend on the adapter type and are fixed). Once new objects have been imported, you must add the non-transportable attributes in the target system. These additions are retained in any further import of the object.


Some attributes are converted: During the import, the Integration Builder converts the address of the non-central adapter engine to the address of the central adapter engine. This is because the address of the non-central adapter engine is probably no longer valid in the productive landscape.