SAP NetWeaver ‘04

Using CMS for

SAP XI 3.0
Version 1.1 – June 2005

Applicable Releases:
SAP NetWeaver ’04 SPS12
(SAP Web Application Server 6.40,
Exchange Infrastructure 3.0 SP12)
© Copyright 2005 SAP AG. All rights reserved.
No part of this publication may be reproduced or
transmitted in any form or for any purpose without the
express permission of SAP AG. The information
contained herein may be changed without prior notice.
Some software products marketed by SAP AG and its
distributors contain proprietary software components of
other software vendors.
Microsoft, Windows, Outlook, and PowerPoint are
registered trademarks of Microsoft Corporation.
IBM, DB2, DB2 Universal Database, OS/2, Parallel
Sysplex, MVS/ESA, AIX, S/390, AS/400, OS/390,
OS/400, iSeries, pSeries, xSeries, zSeries, z/OS, AFP,
Intelligent Miner, WebSphere, Netfinity, Tivoli, and
Informix are trademarks or registered trademarks of IBM
Corporation in the United States and/or other countries.
Oracle is a registered trademark of Oracle Corporation.
UNIX, X/Open, OSF/1, and Motif are registered
trademarks of the Open Group.
Citrix, ICA, Program Neighborhood, MetaFrame,
WinFrame, VideoFrame, and MultiWin are trademarks or
registered trademarks of Citrix Systems, Inc.
HTML, XML, XHTML and W3C are trademarks or
®
registered trademarks of W3C , World Wide Web
Consortium, Massachusetts Institute of Technology.
Java is a registered trademark of Sun Microsystems, Inc.
JavaScript is a registered trademark of Sun
Microsystems, Inc., used under license for technology
invented and implemented by Netscape.
MaxDB is a trademark of MySQL AB, Sweden.
SAP, R/3, mySAP, mySAP.com, xApps, xApp, SAP
NetWeaver, and other SAP products and services
mentioned herein as well as their respective logos are
trademarks or registered trademarks of SAP AG in
Germany and in several other countries all over the
world. All other product and service names mentioned
are the trademarks of their respective companies. Data
contained in this document serves informational
purposes only. National product specifications may vary.
These materials are subject to change without notice.
These materials are provided by SAP AG and
its affiliated companies ("SAP Group") for informational
purposes only, without representation or warranty of any
kind, and SAP Group shall not be liable for errors or
omissions with respect to the materials. The only
warranties for SAP Group products and services are
those that are set forth in the express warranty
statements accompanying such products and services, if
any. Nothing herein should be construed as constituting
an additional warranty.
These materials are provided “as is” without a warranty
of any kind, either express or implied, including but not
limited to, the implied warranties of merchantability,
fitness for a particular purpose, or non-infringement.
SAP shall not be liable for damages of any kind including
without limitation direct, special, indirect, or
consequential damages that may result from the use of
these materials.
SAP does not warrant the accuracy or completeness of
the information, text, graphics, links or other items
contained within these materials. SAP has no control
over the information that you may access through the
use of hot links contained in these materials and does
not endorse your use of third party web pages nor
provide any warranty whatsoever relating to third party
web pages.
SAP NetWeaver “How-to” Guides are intended to
simplify the product implementation. While specific
product features and procedures typically are explained
in a practical business context, it is not implied that those
features and procedures are the only approach in solving
a specific business problem using SAP NetWeaver.
Should you wish to receive additional information,
clarification or support, please refer to SAP Consulting.
Any software coding and/or code lines / strings (“Code”)
included in this documentation are only examples and
are not intended to be used in a productive system
environment. The Code is only intended better explain
and visualize the syntax and phrasing rules of certain
coding. SAP does not warrant the correctness and
completeness of the Code given herein, and SAP shall
not be liable for errors or damages caused by the usage
of the Code, except if such damages were caused by
SAP intentionally or grossly negligent.
1 (Business) Scenario................................................................................................1
2 System Landscape in the XI Environment.............................................................1
2.1 Currently Supported System Landscapes ......................................................1
2.2 System Landscapes in XI...............................................................................2
3 Tasks of the Individual Steps (in CMS).................................................................2
3.1 Defining Tracks (Landscape Configuration) .................................................2
3.1.1 Domain Data ..........................................................................................2
3.1.2 Track Data..............................................................................................2
3.2 Transporting Objects Within a Track ............................................................3
3.2.1 Check-In.................................................................................................3
3.2.2 Development ..........................................................................................3
3.2.3 Consolidation .........................................................................................4
3.2.4 Assembly................................................................................................4
3.2.5 Approval ................................................................................................5
3.2.6 Production ..............................................................................................5
3.2.7 System State...........................................................................................5
3.3 Miscellaneous ................................................................................................5
3.3.1 Sequence in the Queues .........................................................................5
3.3.2 Visibility of Change Lists ......................................................................5
3.3.3 Displaying Import Attempts with Errors ...............................................5
3.4 System Landscape..........................................................................................5
4 Using CMS for Integration Repository Transports................................................6
4.1 Setting Up Tracks ..........................................................................................6
4.2 Scenarios in the Integration Repository.........................................................6
4.3 Export Options ...............................................................................................6
4.3.1 Export Using the Context Menu for the Software Component Version 6
4.3.2 Export Using the Change Lists Displayed in the Transportable Status 7
4.4 Special Features When Using the Integration Repository .............................7
4.4.1 Setting User and Password for XIREPUSER in the CMS.....................7
4.4.2 Managing Assembly and Support Packages ..........................................7
5 Using CMS for Integration Directory Transports ..................................................8
5.1 Setting up Tracks ...........................................................................................8
5.2 Scenarios in the Integration Directory ...........................................................8
5.3 Exporting/Importing ......................................................................................9
5.3.1 Exporting from the DEV System...........................................................9
5.3.2 Importing to the CONS System .............................................................9
5.3.3 Assembly..............................................................................................10
5.3.4 Approval ..............................................................................................11
5.3.5 Importing to PROD..............................................................................11
5.4 Special Features When Using the Integration Directory .............................11
5.4.1 Setting User and Password for XIDIRUSER in the CMS ...................11
5.4.2 Selecting the Imports in a New Track..................................................12
5.4.3 Deleting Scenarios in DEV and Transporting Using CMS .................12
5.4.4 Creating the Business Systems in the System Landscape Directory ...12
6 Appendix..............................................................................................................12
1 (Business) Scenario
The aim of this guide is to help you plan and introduce CMS (Change Management
Service) in the SAP Exchange Infrastructure 3.0 (SAP XI) environment. The procedures
described refer to SAP NetWeaver 2004 SP12.

This is a supplementary guide to be used alongside the CMS and XI documentation. It

should not be used as a substitute for the installation documentation. Its aim is to enable
you to implement CMS correctly in the XI environment and thus optimize transport
processes. The contents of this guide are not generally valid for other CMS application
areas outside of XI. For CMS installation with XI please refer to the XI configuration
guide.

CMS was originally designed for use in Java development and was only later adapted to
suit XI requirements.
In the XI 3.0 environment, CMS is used to transport changes and customer developments
in the Integration Repository and Integration Directory of the development system
consistently through the system landscape. Transporting using CMS rather than the file
system simplifies this process significantly, since you no longer have to copy (export and
import) the files manually.

Since the Java development process and the transport process in the XI environment
differ considerably in some aspects, you must be aware of certain points when setting up
and using CMS in the XI environment. These points are addressed in this guide. CMS is
soon to be tailored to the XI process, which will mean that some of the functions
described in this guide will be even easier to use in the future. The guide will be
continually updated to reflect the most current versions of XI and CMS.

2 System Landscape in the XI Environment

2.1 Currently Supported System Landscapes

The system landscape proposed by CMS looks like this:

Track 1

CL SP
DEV CONS PROD

Track Connection SP

Track 2

CL SP
DEV CONS PROD

Change lists (CL) are exported in the development system (DEV) and imported in the
consolidation system/test system (CONS). This is followed by a complete transport from
CONS as a new support package (SP) and an import to the production system (PROD).
After approval, the generated SP can be imported to the DEV system in a new track.

-1-
2.2 System Landscapes in XI

A single SLD is used for both the XI and CMS systems.

3 Tasks of the Individual Steps (in CMS)

3.1 Defining Tracks (Landscape Configuration)

When defining tracks, you must define the domain data and the track data. This guide
only gives a general overview of the individual configuration activities. For more
information and detailed installation instructions, see the CMS-specific documentation.

3.1.1 Domain Data

You enter data for CMS and the corresponding SLD on this tab page.

3.1.1.1 CMS Data

This includes the track data (name, description, and URL), the user used by CMS, the
corresponding password, and the transport directory.

CMS User:

You use this user and the corresponding password to access the XI systems. The user
LSADMIN is generally used. Therefore, a user with the name and password defined here
must be defined in all systems. The user must be assigned at least the following roles in
XI:
• SAP_SLD_ORGANIZER
• SAP_XI_CMS_SERV_USER

Transport Directory:

The CMS uses this directory to save the objects/change lists exported from DEV as files
with the extension .PRA. These are then later imported to CONS. Furthermore, the
assembled change lists/SWCVs (extension .SCA) from CONS are saved in the transport
directory for import to PROD.

3.1.1.2 Domain
A domain is used to group several tracks. At present, you can only define one domain for
each CMS. In the future, it will be possible to manage multiple domains using the CMS.

3.1.1.3 External Server

This is where you specify the SLD to which the CMS connects to display the software
components and their versions (releases) that are available in the track.

3.1.2 Track Data

During track definition (use XI as Repository type), you maintain the SLD and the
involved XI systems in the landscape configurator. You must make entries for DEV and

-2-
CONS; entries for PROD are optional. You must not use the same URLs in DEV and
CONS. It is planned to make track definition possible with just one system (DEV).

This is also where you add the software components and their versions (releases) to the
track. You can only define one version of a software component for each track.

When you save the track, the user LSADMIN informs the DEV-XI that the software
component will be transported with the specified version using CMS. The objects are
linked to the corresponding CMS track so that they automatically appear in the track after
the transport from XI (for variants, see below).

In SP9, it is possible to copy a track 1:1 and use the same SWCVs. In this
case, the maintained XI systems are automatically informed of the switch and
the SWCV now points to the new track. If this track is then deleted, or the
SWCV is removed, the track originally created and the XI systems referenced
are not informed, and the systems behave as if this SWCV had never been
assigned to them, even though the SWCV still appears in the list of SWCVs
contained in the track. You can only transport using CMS once you have
saved the track again. Saving the track again reassigns XI to the CMS track.

On the Track Connections and Track Replications tab pages, you can define subsequent
tracks. This enables the results from CONS (SPs in the above figure) to be transferred as
complete transports to other transport landscapes.

There must be a forward slash (/) at the end of the URL, for example
http://Servername:port/rep/.

To copy a track, you change the current track (URLs and SWCVs are adapted) and create
a new track using Save as. Be careful not to change the existing track by mistake.

3.2 Transporting Objects Within a Track

If a track is fully defined, you can use the Transport Studio to track or control the
transport of the objects.
The exact steps are explained below, and special features of XI are outlined. The
following sections look at XI-specific features for tracks for the Integration Repository
and the Integration Directory.

3.2.1 Check-In
This function is not currently required for XI. A future plan is to distribute the content as
.PRA files which can be loaded into the XI DEV system by using the check-in function of
the CMS.

3.2.2 Development
You use this tab page if the content to be imported to the DEV system is loaded using
check-in.
The change lists or support packages to be imported from a previous track are also
displayed here.

-3-
If only one track is used (DEV, CONS, PROD), processing starts with the Consolidation
step.

3.2.3 Consolidation
If objects or change lists are transferred from the DEV system with the status
Transportable, they then appear as a new entry in this table. At the same time, a .PRA file
is created in the CMS transport directory with the objects/change lists to be transported.

The definition of the CLs to be transported and the start of the export are different in the
Integration Directory and the Integration Repository, as is the import.

3.2.4 Assembly
You use this step to transport a particular SWCV in the CONS system, at a particular
point in time, in order to group all objects contained in CONS into a new SP.

In XI, the Integration Directory and the Integration Repository handle this step
differently. Up to SP10 you also had the option of executing a delta transport as the
default instead of a complete transport in the Integration Directory. As of SP11, the subset
assembly replaces the delta.

On the Assembly tab page, you will find the imports into the CONS system, which have
been transported via the CMS. Additional change lists can be created by changing objects
directly in the CONS system. However, this is not advised, although it is sometimes
necessary. These change lists are the subset.

There are two ways to start the assembly step; you can either choose “All components” or
choose one individual SWCV (out of those attached to the track).
If you choose the “All components” option, it will assemble all change lists of all SWCVs
without differentiating between those that come from transports out of DEV and those
that result from changes in CONS.
If a single SWCV is selected, a popup is displayed. There are two assembly options:
If you select the button “subset assembly”, one or more change lists can be selected. Only
these change lists will then be assembled and you can transport these individual changes
without the transports from DEV. In the next step (approval), the change lists have to be
treated as separate transports.
If you deselect this button, the whole SWCV will be assembled, including the transports
imported from DEV. There will only be one entry to approve this assembly step.

For the change list transport, you can individually select the SWCVs and decide whether
a change list transport is permitted or not. To change the values, go to the XI admin page
(http://server:port/rep/support/admin/index.html) and choose the link CMS transport
settings in the left frame. The default value for all SWCVs is true. If you change this
value to false, the change list is given the status closed, and the SWCV is added to a
track.

For more information (specific to the Integration Repository and the Integration
Directory), please see the relevant sections later in this document.

-4-
3.2.5 Approval
In this step, the changes that were grouped together in the assembly step are released for
further transport to PROD, or to the subsequent track.

3.2.6 Production
As in the Development and Consolidation steps, the list of change lists/SWCVs
(Integration Directory/Integration Repository) to be imported is also displayed in the
Production step, and the changes can be imported to the system in succession.

3.2.7 System State

This table displays an overview of the information for the current versions of the software
components for each track. You cannot modify the table. It is displayed for informational
purposes only.

3.3 Miscellaneous
3.3.1 Sequence in the Queues
The entries in the queues are displayed chronologically but without a time stamp. The
newest entries are displayed at the top. The time stamp is included in the details of the
individual entries. As of SP11 this time stamp is also displayed in the overview.

3.3.2 Visibility of Change Lists

Unfortunately, it is not possible to display the objects transported within the change list in
CMS. However, a change list number is provided during export in the Integration
Directory/Integration Repository. This number is displayed among the detailed
information for the transport. To find the change list, you can search for the numbers in
CMS and then look them up in XI.

3.3.3 Displaying Import Attempts with Errors

The history does not display imports with errors. An import with errors remains in the
import queue until it is successfully completed. Only then is it saved in the history as
successful.

3.4 System Landscape

When using CMS, we recommend that the CMS system and all involved XI systems have
the same SP of NetWeaver 04. However, this is not always possible; for example, if the
DEV System has a higher SP level than the CONS or PROD. In this case, the CMS
should have the same patch level as the CONS system. We also recommend installing
CMS on a stand-alone engine as a separate system, so that patches can be installed
independently of XI systems.

-5-
4 Using CMS for Integration Repository Transports
4.1 Setting Up Tracks
To transport Integration Repository change lists, you define a track with the software
component and the corresponding version. A SWCV can only be used once in a track in
CMS.

When defining the track, you must define the DEV and the CONS systems in the CMS
Landscape Configurator. Specification of the PROD system is optional.

If the system landscape comprises just two systems, the URLs

(http://servername:port/rep/) are only entered for DEV and CONS.

4.2 Scenarios in the Integration Repository

The following system landscapes are supported for the Integration Repository:

• A DEV, a CONS, and a PROD within a track

• A DEV and a CONS within a track
• A DEV, a CONS, and a PROD within a track, and another track containing at
least a DEV and a CONS system (these must not reference the same XI). The
version of the last DEV system must correspond to that of the PROD from the
original track.
• A DEV, a CONS, and subsequent tracks with only one DEV system

The following scenarios are not currently supported for XI:

• A DEV with several CONS systems

• A DEV, a CONS, and several PROD systems or subsequent tracks (see above),
where the latter do not have exactly the same scenarios, but are selected
depending on the scenarios of the PROD systems or subsequent tracks.

4.3 Export Options

There are two export options:
• Export using the context menu for the SWCV
• Export using the change lists displayed in the transportable status

4.3.1 Export Using the Context Menu for the Software Component Version
You can only export using the context menu for the SWCV if the following parameters
are set to true in the properties in the development and consolidation systems:
• com.sap.aii.ibrep.core.cms.enableClTransport
• com.sap.aii.ibrep.core.cms.enableManualSpDefinition
• com.sap.aii.ibrep.core.cms.enableTransportWizard

In addition, add the following value to com.sap.aii.ib.client.properties:

com.sap.aii.ibrep.core.cms*

-6-
Note: Do not replace the existing values under com.sap.aii.ib.client.properties; just add
the new value to these existing values.

To activate the above parameters, refresh the AII properties of the Integration Repository
in the development and consolidation system.

In the Integration Repository, once the parameters have been set, all SWCVs are
presented for transport by the CMS, and not just the SWCVs that have been added to a
track. However, during export an error is displayed for any SWCVs that are not assigned
to a track.

If the transfer to the CMS is successful, the status for the transport lists is set to closed.
Otherwise they are displayed with a red square in the transportable list. They can then be
restarted as soon as the CMS is available.

4.3.2 Export Using the Change Lists Displayed in the Transportable Status
If the properties mentioned earlier are set in the XI DEV system, the Transportable
Change Lists option appears on the Change Lists tab page in addition to the open and
closed change list options. If a change list is activated in DEV, its status is set to
Transportable. You can send the change list to CMS by choosing Transport in the
context menu, or change the status to Closed by using the Close Without Transport
option. This function is only available as of XI 3.0 SP10.

This export variant only contains objects from the change list and not the complete
SWCV. Therefore, the SWCV must either be created in the target system beforehand, or
imported with a previous transport.

4.4 Special Features When Using the Integration Repository

4.4.1 Setting User and Password for XIREPUSER in the CMS
The XIREPUSER has to be defined in all systems (including the CMS) with the same
password. Since this demands too many restrictions on the whole system landscape, you
can set the password of the XIREPUSER in the XI systems in a different way, and
overwrite the password and users for communication with the CMS with customer-
defined values. Therefore, the following parameters have to be set in the XI systems
according to the repository user in the CMS:

com.sap.aii.repository.serviceuser.name.cms
com.sap.aii.repository.serviceuser.pwd.cms

4.4.2 Managing Assembly and Support Packages

You must execute the assembly step for each SWCV even if a track contains multiple
SWCVs. Therefore, do not select Assemble Component(s), but select the SWCVs
individually using Select Component and then assemble them one after the other.

At present, the transport wizard in the Integration Repository can only transport the
devline; it is not possible to transport SPs. This means that any SP that was defined in
DEV using the functions integrated in the Integration Repository cannot currently be
transported.

-7-
If you are not using SP management, you should normally only use the Same Support
Package Number as the Last Support Package Number option in the assembly step.
[Up to SP10, the support package is called patch level in the CMS user interface.]

5 Using CMS for Integration Directory Transports

This section looks at the properties specific to the Integration Directory for setting up and
using CMS.

To be able to use CMS for directory objects, set the following parameter to true in the
development system:
• com.sap.aii.ibrep.core.cms.enableClTransport
• com.sap.aii.ibrep.core.cms.enableTransportWizard

In addition, add the following value to com.sap.aii.ib.client.properties:

com.sap.aii.ibdir.core.cms*

Note: Do not replace the existing values under com.sap.aii.ib.client.properties; just add
this new value to the existing values.

In addition, set the following parameter to true in the consolidation system:

• com.sap.aii.ibrep.core.cms.enableClTransport

To activate the above parameters, refresh the AII properties of the Integration Directory
in the Development & Consolidation system.

5.1 Setting up Tracks

To transport Integration Directory objects in version 3.0, you define a track with the
software component SAP-INTDIR. This is used to transport all scenarios. The
combination SWCV (SAP-INTDIR) and the XI URL Development in the Track Data
must be unique within the CMS, that is, the URL entered in a track in DEV must not be
entered as the DEV system in any other track in this SWCV.

You must define the DEV and the CONS systems in the CMS Landscape Configurator.
PROD is optional. If the system landscape comprises just two systems, URLs
(http://servername:port/dir/) are only entered for DEV and CONS. The supported
scenarios are described in more detail below.

5.2 Scenarios in the Integration Directory

The following system landscapes are supported for the Integration Directory:

• A DEV, a CONS, and a PROD within a track

• A DEV and a CONS within a track
• A DEV, a CONS, and a PROD within a track, and another track containing at
least a DEV and a CONS system (these must not reference the same XI). The
version of the last DEV system must correspond to that of the PROD from the
original track.

-8-
The following scenarios are currently not supported for XI:

• A DEV with several CONS systems

• A DEV, a CONS, and several PROD systems or subsequent tracks (see above),
where the latter do not have exactly the same scenarios, but are selected
depending on the scenarios of the PROD systems or subsequent tracks.
• A DEV, a CONS, and subsequent tracks with only one DEV system. This variant
will be possible in the future.

These restrictions are the result of the fact that all scenarios in the Integration Directory
are transported using a single SWCV. If only three systems are used in a landscape, these
must be specified within a track. If you want to supply several productive systems, you
must create at least one subsequent track with at least two different systems. You must
ensure that the Integration Directories of the DEV systems of the subsequent tracks have
exactly the same version as the PROD system of the original track.

5.3 Exporting/Importing
5.3.1 Exporting from the DEV System
To select the export in the Integration Directory, choose Export on the context menu for a
scenario. You then execute the transport in the export wizard using the Transport Using
CMS option.

All objects that belong to the selected scenario are exported from the DEV system and
grouped together into a change request for the transport in CMS. In this respect, the
export is very different to the export in the Integration Repository. In the Integration
Repository, you can also transport change lists.

It is not possible to transport using change lists from the DEV system, as is possible in the
Integration Repository. This is because scenarios are exported from DEV with all objects
and not just individual change lists. In subsequent transports from CONS to PROD this
behavior changes, however, and the default is to export only change lists and not
complete scenarios. Alternatively, the Integration Directory can be transported as a
whole.

5.3.2 Importing to the CONS System

The transport now appears in the import queue of the CONS system. After the relevant
lines are selected and the import is complete, the imported objects appear with a new
change list under the user LSADMIN in the Integration Directory.
An entry also appears in CMS in the Assembly step.
The objects in CONS can either be activated by the LSADMIN user, or the change list
can be transferred to and activated by another user.

During the assembly step, only activated objects are processed. This means
that the objects must be activated before further processing in CMS. Change
lists that are imported but not yet activated appear in the assembly list, but are
not processed in the assembly.

-9-
5.3.3 Assembly
There are two types of assembly:
• Assembly of the whole Integration Directory
• Assembly of change lists since the last assembly (delta) (up to SP10)
• Subset Assembly (as of SP11)

5.3.3.1 Assembly of the Whole Integration Directory

Up to SP10 the process is as follows: If the Same Support Package Number as the Last
Support Package Number option is not selected during assembly, a complete export of the
whole Integration Directory, or of all objects activated up to this point takes place.
As of SP11, this flag is no longer used. There are then only two options; to assemble the
complete Integration Directory or a subset.

Depending on the number of activated objects, this process can take a very
long time and impede the performance of the systems involved. Therefore, it
is normally advisable to execute a delta assembly and only choose the
complete export option in the case of inconsistencies or complete transports.
Furthermore, all activated objects are transported to the PROD system, which
means that scenarios/objects that have not yet been tested may be transported
as well.

5.3.3.2 Assembly of Change Lists (valid until SP10)

If the Same Support Package Number as the Last Support Package Number option is
selected during assembly, all change lists that have been added and activated since the
last assembly are grouped into a transport. Basically, all specified change requests are
used, irrespective of the selection.

Objects or scenarios that are already activated and not yet tested are also
included in the transport in this assembly step, and transported to the PROD
later.
During assembly you should not use the Assemble all components option but
perform an SWCV-specific assembly.

If you want to test scenarios in succession, you should first activate one
scenario after the other and then process them immediately in a separate
assembly step. If errors are found in the subsequent test in CONS, you can
reject the errors in the subsequent approval process. This is only possible if
the objects included in the transports are not used in the required scenarios.

5.3.3.3 Subset Assembly (As of SP11)

As of SP11, it is possible to select the change lists for assembly. This enables you to
control which objects are to be transported from the CONS system to the PROD system
after assembly. If you did a full export of the whole Integration Directory, the change lists

- 10 -
which have been exported, but not yet assembled, are outdated. They will be removed
from the list of transportable change lists.
The subset assembly can be used for both Integration Repository and Integration
Directory objects in the CONS system.

5.3.4 Approval
This step enables you to release the change lists for import to the productive system one
after the other.

Within the approval process, it is possible to release the assembled scenarios irrespective
of the assembly sequence. This enables a scenario to “overtake” another scenario.
Once an item is rejected, it can no longer be returned to the approval queue. Therefore,
you should be very careful when using reject.

5.3.5 Importing to PROD

This step describes the import to PROD, which is similar to the import to CONS
described above. However, in this case the transport only involves change lists or a
complete import, and not a transport of all objects belonging to a scenario. Therefore, the
user must ensure that the data is consistent. In particular, problems can arise when
branching to another track (see below) or when deleting a change list that has already
been assembled.

Since the complete transport in the Integration Directory uses an SWCV,

older transports (assemblies) are automatically set to outdated as soon as a
newer transport is imported. This may result in inconsistencies and changes
being lost.

5.4 Special Features When Using the Integration Directory

5.4.1 Setting User and Password for XIDIRUSER in the CMS

The XIDIRUSER has to be defined in all systems (including the CMS) with the same
password. Since this demands too many restrictions on the whole system landscape, you
can set the password of the XIDIRUSER in the XI systems in a different way, and
overwrite the password and users for communication with the CMS with customer-
defined values. Therefore, the following parameters have to be set in the XI systems
according to the directory user in the CMS:

com.sap.aii.directory.serviceuser.name.cms
com.sap.aii.directory.serviceuser.pwd.cms

- 11 -
5.4.2 Selecting the Imports in a New Track
If a change list is imported to a new track in DEV after assembly in CONS, it is
theoretically possible to select individual assemblies (for example, particular scenarios)
for import, and to delete the assemblies that are not required. However, we would advise
against this since you must make sure that the scenario is complete and that all objects
belonging to a scenario are included in the assembly. Otherwise, inconsistencies can
arise.

5.4.3 Deleting Scenarios in DEV and Transporting Using CMS

If scenarios are deleted in DEV, the objects contained in the scenario are not deleted, but
only the object scenario itself. This scenario must then be added to a transport separately,
and transported. If you actually want to delete the objects contained in the scenario as
well, you must add these to the transport.

Objects may still be in use in other scenarios.

Deleting scenarios can remove objects from scenarios. You can leave these objects in the
system, delete them in DEV (and transport the change list separately), or delete them
directly in CONS. The deletion is applied in PROD in the next assembly.

5.4.4 Creating the Business Systems in the System Landscape Directory

All business systems that are used in DEV must also be defined in the System Landscape
Directory (SLD) of CONS and the corresponding groups and Transport Targets must be
available. The same applies to the SLD in PROD when transporting from CONS to
PROD.
If there is a central SLD for all XI systems, the groups and Transport Targets must be
defined there for all business systems.

6 Appendix
The documentation for XI and CMS is available on SAP Help Portal at help.sap.com.

CMS:

SAP NetWeaver Æ Application Platform (WAS) Æ Java Technology in SAP WAS Æ

Architecture Manual Æ SAP NetWeaver Java Development Infrastructure Æ
Architecture and Structure of the Change Management Service:
http://help.sap.com/saphelp_nw04/helpdata/en/31/ef4c4005a99523e10000000a1550b0/fra
meset.htm

XI:

SAP NetWeaver Æ Process Integration Æ SAP Exchange InfrastructureÆ Design and

Configuration Time Æ Software Logistics for XI Objects Æ Transporting XI Objects Æ
Transporting Using the Change Management Service:
http://help.sap.com/saphelp_nw04/helpdata/en/e1/69a740aa053a13e10000000a155106/fr
ameset.htm

For more information about error messages, current problems, and solutions, see SAP
Note 780297.

- 12 -
www.sap.com/netweaver