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.
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.
You can transport objects in the Integration Builder in the following ways:
Options in the Transport Wizard
The Integration Builder provides the following options in the transport wizard for the transport or export of configuration objects:
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.