●
Transport
Lists
The Integration Builder creates a transport list when you group objects
together by using the transport wizard in Transporting with CTS mode. The name of the transport list is
displayed later during the transport. Once you have performed all the steps in
the transport wizard, the Integration Builder transfers the transport list
directly to CMS and displays it on the Change Lists tab page. As usual,
the Integration Builder exports the last active version of the
objects.
●
Change
Lists
The Integration Builder creates a standard change list as soon as an object is
saved or deleted by a user who has not yet been assigned a change list. Since
you cannot change the name of the standard change list, we recommend that you
create your own change list before saving or deleting an object. The name of
the change list is displayed later during the transport. Once activated, an
open change list has the status transportable. You can then either
transfer the change list to CMS (context menu Transport) or close the
change list (Close Without Transport) on the Change Lists tab
page. In the first case, the Integration Builder exports the changes
contained in the change list. This corresponds to the object versions at
the time of release of the change list (see the example below).
In the ES Repository, the export of objects is generally restricted to one software component version. Therefore, you cannot include objects from change lists of different software component versions in an export.
The following figure gives you an overview of the different statuses that change lists and transport lists can have:
The different statuses are displayed in the quick info for either the transport or change list, and when searching for transports.
You want to transport a change list with CTS. Once you have activated the change list, the Integration Builder moves it to the Transportable branch of the Change Lists tab page.
The Integration Builder transfers open change lists of software component versions that are not entered in CMS directly to the Closed branch at release.
In this way, when you release changes, the intermediate Transportable status gives you control over whether and when changes are transported.
You can make new changes to objects in transportable change lists before transport. The result of this is that different versions of an object can exist in different transportable change lists. The following figure provides an example:
The transportable change list CL1 contains three objects. At the time CL1 was released, both objects Object2 and Object3 had version 1 and Object1 had version 2. After this, the objects Object2 and Object3 were changed using other change lists. You now have the following options:
● To transport the object versions in change list CL1, use the Release for CTS Transport function on the Change Lists tab page.
● To transport the current object versions, create a transport list by using the transport wizard.