Use the following tools for PI transports using Change Management Services (CMS).
· Landscape Configurator - allows you to set up the transport landscape using XI tracks.
· Enterprise Services Builder - to export ESR content of the development system or of the consolidation system (for emergency corrections) and to track completed transports.
· Integration Builder for Integration Directory transports - to export configuration contents of the development system or of the consolidation system (for short notice changes) and to track completed transports
· Transport Studio - to perform transports using CMS:
This section focuses on the basic steps and options for CMS transports. More detailed procedures are referenced at the relevant points.
CMS supports the defintion of different transport landscapes using the definition of XI tracks in the Landscape Configurator. The following scenarios are supported:
In the case of transport scenarios with linked tracks, the objects versions in PROD1 must be identical to those in DEV2. You can only link XI tracks from different system landscapes (see also: Connecting Tracks); this means if you link two tracks, A and B, a system from track A may not appear in track B. You can enter the systems for both system landscapes in a System Landscape Directory.
In CMS mode, you perform transports using the ES Builder (for design objects) or the Integration Builder (for configuration objects) and the CMS Transport Studio. The tools focus on the following transport areas:
Transport Functions in the ES Builder/Integration Builder and Transport Studio
ES Builder/ |
Determining the object set for transport |
Status Display |
|
Resolving conflicts in imports |
|
Finding Transports |
|
Importing change
requests to the target system |
|
Assembling software component versions (Assembly) |
|
Quality assurance step (Approval) |
We will assume that the software component version of the objects that are to be transported is released for transport using the CMS. SAP provides a software component version for the entire content of the Integration Directory.
You define the object set of a transport for design objects in the ES Builder and for configuration objects in the Integration Builder. You can transfer either change lists or transport lists to the CMS. Once the change or transport list has been exported from the Integration Builder or ES Builder, it appears as a change request in the Transport Studio.
Both the ES Builder and the Integration Builder collect all changes to objects in a change list. It stands to reason that these are the changes you will want to transport (from the development system, for example). Once you have released the change list, its status changes from Open to Transportable. To transfer it to the CMS, choose Release for Transport in the context menu on the Change Lists tab page. All changes at the time of release are transported in a change list.
To compile a list of objects independently of change lists, you use the transport wizard to create transport lists. To create a transport list, proceed as follows:
...
1. Choose Tools → Export Design Objects (Enterprise Services Builder) or Tools → Export Configuration Objects (Integration Builder).
2. Select the Transport Using CMS mode and determine the object set in the next step.
You can use change lists as a filter when determining the object set in the transport wizard. Objects lists compiled in this way nevertheless have all the normal properties of a transport list.
Both the ES Builder and the Integration Builder display the transport list on the Change Lists tab page. This list is transferred directly to the CMS and has the status Waiting for export… until the process is complete. Object versions that are active at the time the transport list is compiled are transported in a transport list.
Within an XI track you can transport objects from a development system (DEV) to a consolidation system (CONS) and then from the consolidation system (CONS) to a productive system (PROD). Both the ES Builder and the Integration Builder offer different options for defining the transport entities depending on the target system:
Transport Units by XI Track and Transport Scenario
Type of XI Track |
Supported Transport Units |
|
From DEV to CONS |
From CONS to PROD |
|
ES Repository |
Change and transport lists |
Usually: |
Change and transport lists (emergency corrections in the ES Builder) |
||
Integration Directory |
Transport
lists |
Usually: You can also create new transport lists. |
Complete copy |
As shown in the table, the usual transport units and the necessary steps depend on the type of the XI track (Enterprise Services Repository or Integration Directory) and the transport scenario.
In the CMS Transport Studio, there are a number of tab pages for each track, which you work through one after the other during a transport. The tab page on which your exported change or transport lists are shown depends on the Integration Builder or ES Builder you are working with (development, consolidation, or productive system). The following figure shows the process for the Integration Builder. The process is the same for the ES Builder.
You usually export transport requests from the development system, which appear in the import queue of the Transport Studio for the consolidation system. You control the rest of the transport from here. Exceptions:
· In the consolidation Integration Directory, change lists are usually generated when changes are imported. You must check and release these change lists in the Integration Builder before you can transport them further with the Transport Studio.
· If you have to make emergency corrections in the ES Repository of the consolidation system, you export change or transport lists, which appear in the Transport Studio (as in the Directory case). You can then either reassemble the whole software component version (in the Assembly step) or create a package containing just the changes for the productive system.
More information: Transporting Design Objects and Transporting Configuration Objects
The table below summarizes the transport procedures in the CMS. The sequence of the tab pages in the Transport Studio corresponds to the transport route within a track.
Development Status of the XI Track in the Transport Studio
Step |
Tab Page |
Use |
|
Check-In |
You use check-in to make archive files with the extension .PRA that you have received from an external source known to the Change Management Service, and make them available for transport through the development landscape. Checked-in archives are added to the import queue on the Development tab page. Integration Builder or ES Builder users do not use this function at present because both tools have their own import function (file system-based import). |
0 |
Development |
This import queue contains checked-in archives and exports from other XI tracks connected to this track (more information: Connecting Tracks). |
1 |
Consolidation |
Once a transport request has been exported in the development ES Builder/Integration Builder, this is where the change requests appear for each software component version for import to the consolidation system (ES Repository or Integration Directory). |
2 |
Assembly |
After import in the consolidation system, this is where you assemble transports of software component versions. |
3 |
Approval |
This tab page displays assembled software component versions. You use this step for quality assurance, to decide which changes to import to the productive system. |
4 |
Production |
After approval, the transport is ready for import to the productive system. The corresponding tab page is only displayed if you have entered a productive system in the corresponding track. |