Transporting XI Objects 

Use

Integration Repository objects are referred to as design objects and Integration Directory objects are referred to as configuration objects. Together, they are referred to as XI objects. The transport of XI objects consists of an export from the source repository or directory and an import to the target repository or directory, respectively. You can transport XI objects for the following reasons:

●      To copy design objects from one Integration Repository to another Integration Repository. The software component version must be the same in the source and target repository in this case. In this way, you provide the design objects of the Integration Repository using export files. The Importing Process Integration Content section gives a brief description of how customers can import this Process Integration Content to their Integration Repository.

●      To copy configuration objects from one Integration Directory to another Integration Directory. In this way, you can copy a test configuration to a productive landscape.

Integration

Besides the transport functions, there are also some other related functions that are not described here.

Related Functions

Function	Use
Release Transfer	Transfer design objects within an Integration Repository from one software component version to another.
System Content Copy	Transfer all content in one XI landscape to another XI landscape (Integration Repository, Integration Directory, as well as other data, for example Integration Server configuration data). For more information, see the System Content Copy Guide on SAP Service Marketplace at service.sap.com\instguidesNW04 ® Operations ® SAP XI.
Cross-Release Transports	Transports from an older release version of an Integration Repository or Integration Directory. For more information about cross-release transports, see SAP Note 834507.

In SAP NetWeaver 7.0 SP Stack 12 and higher, you can transport XI objects by using CTS+. CTS+ is an enhanced version of Change and Transport System in SAP NetWeaver Application Server – ABAP. For more information see, How-To Guide How to transport repository content and directory content using CTS+ on SAP Developer Network at http://www.sdn.sap.com/irj/sdn/howtoguides  ® SAP NetWeaver 7.0  ® End-to-End Process Integration (SDN-User required).

Features

General

●      When exporting XI objects, you can limit the number of objects exported.

●      You can only export active objects. If an object to be exported is not active, the Integration Builder exports the last active version. Exception: If a change list is being exported using the Transport function on the Change Lists tab page, the Integration Builder exports the object versions at the time of release. See: Transporting Change Lists.

●      If an object has been deleted, the Integration Builder exports a Delete Version so that the target Integration Repository or 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.

Integration Repository

You have the following options for selecting the objects to be exported:

●      All objects of a software component version. When you select this option, the Integration Builder always includes the delete versions in the export.

●      All objects of individual namespaces for a software component version.

●      Individual objects of a software component version. The deleted objects have the Delete Version () icon next to them in the selection list. See also Selecting Individual Objects.

The export file also contains information about higher-level software components when exporting objects of a namespace, because the version of the software component of the object to be imported must be checked when you import.

If you have only exported the objects of one namespace, the namespaces of the same software component version are nevertheless visible in the target repository following the import. However, these namespaces are empty because they could not be exported. SAP recommends that you only export complete software component versions so as to avoid confusion.

During the import, version management checks whether the objects to be imported already exist in the target repository, and if so, what their version status is (see: Versioning in Transports). Version conflicts may arise if objects have been changed in both the source and target Integration Repositories. You can resolve these conflicts during the import (see: Conflicts When Importing).

Integration Directory

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

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

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 services, which are entered as business systems in the SLD, are assigned to the services of the productive directory, and dependent objects are converted. (see SAP Note 764393 for alternative SLD scenarios).

See also: 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 Integration 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.

There are also attributes that need to be 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.

Versioning

Unlike importing in the Integration Repository, version management always creates a new version for the object to be imported in the target directory. Object versions of the source and target repository are therefore independent of each other. This means that you can also import configuration objects that have a version that is older than the version currently in the directory (see also: Versioning in Transports).

Activities

...

       1.      Transport using the file system.

       2.      Alternatively, transport using the Change Management Service.

       3.      You can also search for transports that have already been completed (see: Searching for Transports).