XI Software Logistics Solution III: CMS

In the XI Software Logistics II: Overview, we discussed two transport options viz. transport using File system and transport using CMS.

In this blog, we’ll discuss CMS in detail.

Change Management System is a part of SAP Netweaver JDI (Java Development Infrastructure).
As SAP claims, with JDI they are introducing SAP Software Logistics concepts to the java

world. Since this is intended to cater to most of the components in Netweaver stack, CMS is a

just a part of it. Rather in broader view, JDI is more of a Software Life-cycle management

tool for Netweaver stack. It consists of a set of closely coupled central services for the

design, implementation, build and test, both in a local and in a central environment. Other

JDI components being DTR(Design Time Repository), CBS (Central Build Services).

For detailed information on JDI, please browse to http://service.sap.com/nw04 ->SAP Netweaver

in detail -> Application Platform ->Java, J2EE technology ->Developer Studio

CMS (which is part of JDI) is installed on WAS system.

A question commonly asked about CMS is whether its required to be installed on separate WAS

system. Answer is not required. As such you can install it on separate WAS if you’ve multiple

XI landscapes or along with XI, few other Netweaver components like EP as well access it. Else

normally it can be be installed on same WAS system which hosts XI.

We don’t setup CMS on all systems meaning XI DEV, CON, PRD. In needs to be installed only

on one system. In its configuration, we enter URL for all three environments and that’s how it

access all the systems.

For detailed information on CMS implementation, take a look at How to CMS with XI guide at

http://service.sap.com/xi -> Media Library -> How to guides. It elaborately discusses various

steps involved.

You need to create LSADMIN user in all the systems.

However user CMSADMIN is required only in CMS system i.e. WAS system where you’ve installed

CMS.

There are two types tracks each one corresponding to its related repository. For XI track we

choose Repository Type as XI. For Java transport we need to create DTR track. In Integration

Repository, SWCV is the development and shipment unit individual design objects belong to.

When we define track, we mark the SWCV and thereby decide the transport target, corresponding

TEST, PRD systems for objects belonging to that SWCV.

For ID, we just need one track and with software component SAP-INTDIR.
However for IR, we can either define one track for all SWCV or define separate one for each. I

strongly recommend creating separate track for separate SWCV since this offers more

flexibility in managing imports and assembly of the transport list. Especially with assembly,

you can assemble transport lists of a particular SWCV in an individual track.

Its very important for transport and change list to have some sensible and self explanatory

naming. And more when currently CMS doesn’t offer any facility to view the list of the objects

in particular transport / change list. As in the below screen shot, we can’t view the objects

included in transport list testTransportList.

For any further changes, a change request should be generated and documented in excel sheet.

Now we can follow below procedure for transporting objects.

1. After consulting team lead developer will create export / change list and fill up the

relevant columns of excel sheet.

2. QA Manager/ Team lead will then QA the changes, complete ‘QAd by’, section and then

send a mail to XI administrator with the request details.

3. XI Administrator will assemble the export / change list and inform Authorised

approver.

4. Approver will login to CMS, approve the request and inform the same to XI

administrator after filling up ‘Approved by’ column.

5. XI administrator will import the request and intimate team lead.

6. Transports should be verified and confirmed in PRD systems by Development team and any

discrepancy should be reported to team lead and XI administrator.

As we discussed in earlier blog, IR doesn’t overwrite higher version with lower one. Rather

when we import design object, it compares all earlier version of the object and maintains the

higher one as active.

Also obeying originality principle, we should not change the object in target system. Say I

changed version V2 in target repository and it creates a new version Vmod.
Npw when we try to import version V3,it checks and identifies object being modified and

reports conflict with version Vmod.

In IR, there is a separate tab ‘Conflict’. Under this tab, you’ll find all the conflicting

objects.

You can double click respective object and it displays below version editor.

Here you can display both conflicting version and active version and then choose the one which

is required.