Transporting Design Objects

You can transport design objects from the development repository to a consolidation repository, and from there to a productive repository. The following figure shows the usual transport units:

Further possible transport scenarios are described in CMS Transports (ES Repository)

You have created an XI track in the Landscape Configurator and entered the addresses of the development, consolidation, and productive repository, and the software component versions that you want to transport using the track. Once you have made this setting, you can create transport lists for the CMS. The status of the change lists of the registered software component version no longer changes to Closed immediately after their release, but first changes to Transportable.

(1) Transporting from the Development to the Consolidation Repository

The transport has two steps: You use the ES Builder to export your changes from the development repository and then use the Transport Studio to transport the changes to the consolidation system.

Exporting Change Lists

To release changes to the CMS for transport to the consolidation repository, developers usually use change lists, which already contain the changes in the development repository. To execute the actions described in this section, you must be the owner of the change list.

1. In the ES Builder, release your change list. On the Change Lists tab page, the status of the change list first changes to Transportable. You can transport the changes at a later point in time.
2. If you want to transfer changes to the CMS for transport to the consolidation system, call the context menu for a transportable change list on the Change Lists tab page and choose Release for Transport. If you do not want to transport the changes, choose Close Without Transport.
3. A change request for a change list appears in the Transport Studio, see below. No further steps are required in the ES Builder.

Exporting Transport Lists

Alternatively, users can compile transport lists in the ES Builder independently of change lists (see also: Change and Transport Entities for CMS Transports ).

1. In the ES Builder of the development repository, generate a transport list using the transport wizard (Tools → Export Design Objects).
2. The ES Builder transfers the change list to the Transport Studio; see below. No further steps are required in the ES Builder.

Transporting Changes to the Consolidation System in the Transport Studio

A change request for the change or transport list appears in the Transport Studio on the Consolidation tab page.

1. To transport the changes to the consolidation repository, choose Import on the tab page.
2. Once the CMS has transported the changes in the change request to the consolidation repository, the Transport Studio removes the change requests from the Consolidation tab page and adds them to the list on the Assembly tab page, where they have the status Waiting for assembly.

(2) Transporting from the Consolidation to the Productive Repository

When transporting to the productive repository, you must bundle the changes that have been imported to the consolidation repository into a software component version and transport them to the productive system:

1. In the Transport Studio, select the Assembly tab page. This tab page displays a list of those change or transport lists that have been imported from the development repository to the consolidation repository. They have the status Waiting for assembly.
2. Select one software component version that you want to transport the changes for from the Select Component list box. The Assembly tab page now only displays the transport and change lists of the selected software component version.
3. Choose Assemble component(s).
   • As long as no emergency corrections have been made for the selected software component version in the consolidation repository, a Complete Copy of the software component version is created. A dialog box appears, where you can select the assembly options and start the assembly. The complete copy of the software component version contains all active objects of the consolidation repository, including the transport and change lists imported from the development repository.
   • If emergency corrections have been made in the consolidation repository and released to the CMS, a dialog window appears for selecting these emergency corrections for transport (for more information, see below in the Exporting Emergency Corrections from the Consolidation Repository section). You have two options:
     • If you want to make a complete copy of the software component version, including the emergency corrections (displayed in the dialog box) and all active objects of the consolidation repository (including the transport and change lists imported from the development repository), do not choose Subset Assembly.
     • If you only want to transport the emergency corrections, or a selection of them, select the change or transport lists that you want to bundle in a software component version in the dialog box (you can select multiple entries by using CTRL and SHIFT), and choose Subset Assembly. Only those lists selected in the dialog box are transported.

Assembly Options

1. Once assembly is complete, you must confirm or reject the import of the software component version to the productive system on the Approval tab page. Rejected imports are removed from the track and are no longer visible on the Assembly tab page (except in the history). Therefore, you must reimport any changes from rejected imports from the ES Builder.
2. Import your changes to the productive repository on the Production tab page.

Conflicts in Imports to the Target Repository

The Transport Studio notifies you of any version conflicts that occur during import to the target repository and cancels the transport. You can resolve such conflicts in the ES Builder on the Conflicts tab page.

More information: Conflicts when Importing Objects

Exporting Emergency Corrections from the Consolidation Repository

Depending on your transport schedules, it may be necessary in urgent cases to change objects in the consolidation repository instead of waiting to transport changes from the development repository.

1. In such cases, instead of starting the export using the Transport Studio, export the relevant transport or change lists directly from the ES Builder of the consolidation repository. The ES Builder displays the status Waiting for Export for these exports.
2. The Transport Studio does not display the lists for emergency corrections on the Assembly tab page. To use the Transport Studio to transport the transport or change lists exported in the last step, choose Assemble component(s) on this tab page. The following dialog window for the selective transport displays the exported transport units. Therefore, before assembly, choose the Subset Assemblyoption so that the assembly will only include the change or transport lists shown in the dialog window (the other options are described in the table above).
3. Once you have started the transport using the Transport Studio as described in the last step, the status in the ES Builder changes to either Closed or Export Failed.
   Caution

   To ensure that the development and consolidation repository remain consistent, you must make any changes to the consolidation repository in the development repository as well. (You cannot transport the changes back to the development system using the CMS.) However, if you change the objects that you have changed in the consolidation repository in the development repository as well, a version conflict will occur in the next import to the consolidation repository. To avoid having to resolve these version conflicts manually, you can transport changes back to the development system by using the file system (more information: Transporting ESR Content using the File System