Similarities and Differences in CMS and CM Services

[daniel_noethe]

CMS and CM Services seem to be two methods for doing the same thing. In this blog, I will try to explain what the differences are and what is maybe similar. Hopefully, this gives you some hints, what is the appropriate tool for which scenario. In addition, I recommend that you start with going through SAP Note 1775838 ‘CMS / CM Services: What to use in which scenario?’ to read SAP´s general recommendations on this topic.

Differences of Import Result Handling

In CMS, the imports to “Development” and “Consolidation” finish successfully even if deployment fails. CM Services puts more focus on the runtime system and if deployments are not done or if they fail after an import to DTR and CBS has been performed, the import ends with an error in CTS.

Check-In vs. Synchronize Service (Upload System)

In CMS, you initially fill up CBS / DTR by using “Check-In” and "Import" in CMS Transport Studio. In detail, you first copy the SCA to be checked in to the CMS inbox and then use the “Check-In” tab in CMS Transport Studio to load the SCA into the track. After this “Check-In” the SCA can be imported into the “Development” system of the track in CMS transport studio. This import will fill DTR workspaces (if sources are part of the SCA and the SC is configured as to be developed) and the import will fill the CBS buildspace (if archives are part of the SCA and the SC is a required SC).

In CM Services with CTS, the CBS / DTR can be filled up in 2 ways:

1. As of the SAP NetWeaver 7.30 version of CM Services you can use the Synchronize Service to compare the system state of the NWDI with the runtime system and to upload the correct SCA files into CBS / DTR. To do so, you first copy the SCAs you used to set up the runtime system (development system) into a folder that is accessible from the AS Java that hosts the CM Services and then you use Synchronize Service with this folder to fill up DTR / CBS.
2. If your CM Services version is lower than 7.30 you define an “Upload System” in CTS and connect it with the development system. Afterwards you create a transport request for this upload system and attach all SCAs which you need to fill up CBS / DTR. (These are all SCAs you would have used for “Check-In” in CMS.)

For both variants see also “How To Setup CM Services” guides for more details: http://scn.sap.com/docs/DOC-8576#section6.

Remark: For both CMS and CM Services scenario the SCAs to be used are the same that were used to install the runtime system  (with SAPInst) or update it (with SUM / JSPM).

Meaning of activate and release in CMS in normal and “Development System Only” tracks

In CMS tracks there have always been 2 development configurations, dev and cons. Later the option “Development System Only” (sometimes also named Single System track) was introduced in CMS.

Using this option you can get rid of the consolidation system but this also changes the development process. That’s because already after an activation done by the developer the change will be transported to further systems (if defined in following / connected tracks) as soon as somebody triggers an assembly in CMS. In this case, it is not necessary to release the activities. However, the release step in NWDS is mandatory if there are repair connections defined.

For more information on a single system track, refer to the SAP Help Portal at: http://help.sap.com/saphelp_nw70ehp3/helpdata/en/48/104caf3b2b3558e10000000a42189d/frameset.htm

Meaning of activate and release in CM Services

In CM Services with CTS you have one source system with development configuration where you develop. (Similar to a CMS track with option “Development System Only”)

Important to know is that already after activation the change might get transported:

• because somebody triggers an SCA Export in the Export Service UI which will export all activated changes and release them
• because another developer triggers a release in NWDS and the change is related to the change to be released. (either a predecessor in DTR or the changes are changing the same runtime objects – See also “How To Setup CM Services” guides as for 7.02 on http://scn.sap.com/docs/DOC-8576?rid=/webcontent/uuid/c0ce1dd8-c020-2b10-d080-a1cd3e985af1 sections about deployable and source transport)

Assembly vs. SCA Export

In CMS you trigger an assembly to assemble all the changes in an SCA. This assembly reads the active sources from DTR, downloads the archives from CBS and then creates the SCA. In a normal track the sources are read from cons/active workspace and the archives are read from consolidation buildspace. In a “Development System Only” track the sources are read from dev/active workspace and the archives are read from development buildspace.

In CM Services this assembly is also available but it is called SCA Export. This SCA Export can be performed in the Export Service UI. Because the SCA created during SCA export contains all active sources of the whole software component all activated but not yet released activities will be released automatically. (Concerning the content of the SCA – packing all active sources and current archives - that’s the same behavior as in CMS with the option “Development System Only”. But in CMS the activities are not released automatically. – See sections "Meaning of activate and release in CMS in normal and “Development System Only” tracks" and “Meaning of activate and release in CM Services” for more details)

Maintenance / Repair Support

Guides for doing maintenance / repairs are available for CMS and CM Services.

In CMS there are repair connections to bring a fix to the queue of the development system. Such repair connections are not available in CTS. Therefore, the maintenance / repair scenario in CTS requires manual effort for double maintenance as described in the guide.

Guide for CMS: http://scn.sap.com/people/marion.schlotte/blog/2006/03/30/best-practices-for-nwdi-track-design-for-o...

Guide for CM Services: http://scn.sap.com/docs/DOC-31315

Check and Trigger Auto Deployment

If you configure runtime systems for development and/or consolidation in CMS, deployments are done automatically as soon as a deployable DC is built by CBS. The build in CBS can be triggered by an activation, an import in CMS, a manual DC build or an init compartment. To monitor or manually trigger this auto deployment a servlet on CBS server is available under http://<host>:<port>/TCS/Deployer.

In CM Services the auto deployment is also available for all CTS systems that have a development configuration. But in CM Services the servlet is running on the CM Services server and is available under http://<host>:<port>/DI/Deployer.

Track-Specific Authorizations

In CMS you can define track-specific authorizations to allow different users to perform different actions in different tracks. CM Services has no tracks, therefore there are no track-specific authorizations. It is also not possible to have different permissions on different development configurations in one CM Services Server. Access can only be restricted on the sources in DTR by using Access Control Lists (ACLs).

But in CTS you can allow/deny imports for user/system combinations. More details can be found on the SAP Help Portal in the chapter ‘System-Specific Authorizations’. http://help.sap.com/saphelp_nw73ehp1/helpdata/en/69/78ff8f8223429da34482c38e18dbcb/frameset.htm

Caching of SLD data

CMS caches software component information of the SLD. If there are changes in SLD ‘Update CMS’ needs to be triggered and finally SCs might need to be synchronized in the tracks.

CM Services does not cache SLD data but always reads data from SLD during configuration. As of SAP NetWeaver 7.20  CM Services can also compare the current SC configuration within a development configuration with the SC definition in SLD by using the “Check SC” option in the CM Services Development Configuration Management UI.

Tips and Tricks

Do not use the NWDI as Runtime System

The update of the NWDI forces the update of other applications running on this server and servers  behind (QAS, PROD, …) and vice versa (e.g. if EP and NWDI run on the same server, an EP update forces an update of the NWDI)

Offline deployments will restart the engine and therefore never finish successfully.

Source Transport Scenario in CM Services

If you don’t follow the recommendation to use deployable transport but use source transport instead make sure to protect the sources in QA and PROD workspaces by defining Access Control Lists (ACLs) in DTR. You also need to make sure that if source changes are done behind the development system, the corresponding activities are integrated to development as well. Otherwise conflicts will occur in next transport! See also Maintenance with CM Services here on SDN. (http://scn.sap.com/docs/DOC-31315).

Release Transport Requests as early as possible

The order of the queue in CTS is based on the export timestamp of the transport request (this is the time when you release the transport request from a non-ABAP perspective) and the queue is the order in which the transport requests will be imported later!

As the CTS queue defines the order of imports, deployments are always done with force mode when importing into non-ABAP systems without development configuration.