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.
JDI (Java Development Infrastructure):
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 System
CMS (which is part of JDI) is installed on WAS system.
Separate 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.
All systems ?
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.
Users
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.
Track Definition:
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.
How many tracks ?
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.
Naming Convention
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.
Change Request :
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.
Version Conflict:
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.
5 Comments
