Change Request Management: Configuring CTS+ in SAP Solution Manager 7.1

With the following steps you will be able to create a project to practice how to manage a non-ABAP landscape from the Change Request Management in Solution Manager 7.1.

Also I will try to give some tips and tricks for the common mistakes in the configuration of this scenario.

I will work in this example with a TMS landscape for portal systems: XAD->XAQ->XAP.

With the enhanced Change and Transport System (CTS+) you can transport non-ABAP objects via the CTS. CTS+ is offered starting with SAP NetWeaver 7.0 SPS 12.
On the SCN document Other CTS+ resources you can find the documentation and How-to Guides which can help you setting up CTS+ in your environment.
CTS+ can be used for different environments like Enterprise Portal systems (Java system), PI systems (dual stack systems), SAP Hana, SAP Business Objects, SAP NetWeaver Master Data Management 7.1 systems, etc...
See guide Best Practices for Implementing CTS+.

So the first step is setting up CTS+ in your environment, if CTS+ can be used for your specific product landscape then ChaRM can be used to manage this landscape.

In the Best Practices for Implementing CTS+ guide you can read:
For the usage of CTS+ at least one ABAP and one JAVA stack is needed. The recommendation is to use the SAP Solution Manager system, which is a dual stack system. CTS+ does not need any Solution Manager functionality, it is a pure SAP NetWeaver technology. But the Solution Manager system can act as central transport management system for the whole landscape.

The decision where to configure the CTS+ components will depend on the use case (such as PI, EP, NWDI) and the system landscape.

Picture below is an example for a central dual-stack system that acts as domain controller for a non-ABAP landscape. Here all server components are configured within the same system.

If the ABAP and Java stacks are implemented on separate systems that run on different hosts, some additional configuration aspects need to be considered, see next picture:

From ChaRM point of view the relevant CTS+ components are:

- Domain Controller (ABAP): The domain controller is the system, where the TMS transport systems (ABAP and non-ABAP) with their transport layer and transport route are configured.
- TMS Communication System (ABAP): The communication system is the ABAP where the transport program tp is triggered to perform the transport steps. By default the Domain Controller is used as Communication system. But that is not mandatory as any other system can act as Communication system.
- CTS Export Client: tight integration of CTS+ in the application of the source system where the non-ABAP objects are created. The Export Client communicates with the enhanced Transport Organizer to fetch a proper transport request and to attach the non-ABAP object directly within the application.

Please follow the Best practises guide completely to setup the CTS+ in your environment, in step 2 section I will make some remarks for using later ChaRM scenario to manage your environment.

Case1. Non-ABAP systems
With the enhanced CTS a new type of TMS/CTS System is introduced – the non-ABAP System.
Logon to the client 000 of the domain controller of the system that you want to use as TMS communication system, there is transaction stms  →  SAP System  → Create  → Non-ABAP System.

This system type is needed for all pure AS Java landscapes for example EP and for the other systems like SAP Hana, SAP Business Objects, SAP NetWeaver Master Data Management 7.1 systems, etc...
Create all systems of your landscape.

Case 2. Dual-Stack systems
Existing systems in the transport landscape that are dual-Stack systems (e.g. use case PI) can now be enhanced with the new Transport Tool parameters for the Java stack to be able to transport non- ABAP objects. Typically the ABAP stacks are already configured and included in the transport domain. To add the CTS+ functionality for transports to the Java stack, the existing configuration for the ABAP systems needs to be extended with the relevant CTS+ parameters. Since SAP NetWeaver 7.0 SP Stack 14 a wizard can be used to add the relevant parameters to existing ABAP system configurations. Logon to the client 000 of the domain controller of the dual-Stack system and call transaction stms → Create →Java Stack:

Case1. Non-ABAP systems
Enter the System ID and description and choose the Source System Settings. With the Source System Settings the SAP System ID (SAPSID) of the Communication System and the client on which the Transport Organizer Web UI should run is defined. With the activation of the Transport Organizer for this system, transport requests for that system will be created here. The transport requests will have names starting with the SAPSID of this system.

The following parameters are mandatory for the configuration of a pure non-ABAP source system:
- CTC: 0
- CTS_SYSTEM_TYPE: This parameter is only needed when using CTS+ with Solution Manager Change Request Management (ChaRM)
Depending on the system type we should enter here the following values:
JAVA   *for pure Java systems
MDM   *for MDM systems according to note 1464456
BOBJ   *for Business Object systems, 
HANADB    *for Hana systems

UNSPECIFIC *for technical system type Unspecific ... System
others     *for pure file system deployment
- NON_ABAP_SYSTEM: 1
- COMMUNICATION_SYSTEM:  SAPSID of the ABAP communication system (e.g. the domain controller)
- NON_ABAP_WBO_CLIENT: Client of the ABAP stack on which the Transport Organizer Web UI (CTS_BROWSER) is activated and will run.
- WBO_GET_REQ_STRATEGY:TAGGED

Case 2. Dual-Stack systems
The difference of the two wizards is, that for adding Java stack parameters an existing system is selected and no new system is created. Furthermore no COMMUNICATION_SYSTEM parameter is needed for dual-stack systems, as every ABAP system has its own tp that manages transports.
- CTC: 1
- NON_ABAP_WBO_CLIENT: Client of the ABAP stack on which the Transport Organizer Web UI (CTS_BROWSER) is activated and will run.

Case1. Non-ABAP systems
To create a non-ABAP target system, the wizard to create non-ABAP Target System can be used. Enter the System ID and description and choose the Target System Settings. The Communication System for a non-ABAP target system has the task to communicate with the transport control program tp running on that system together with the Deploy Web Service Client to trigger the import on the target runtime system. With the Target System Settings the types of import are specified.

The following parameters are mandatory for the configuration of a pure non-ABAP target system:

- CTC: 0
- CTS_SYSTEM_TYPE: This parameter is only needed when using CTS+ with Solution Manager Change Request Management (ChaRM)
Depending on the system type we should enter here the following values:
JAVA   *for pure Java systems
MDM   *for MDM systems according to note 1464456
BOBJ   *for Business Object systems, 
HANADB    *for Hana systems
others     *for pure file system deployment
- NON_ABAP_SYSTEM: 1
- COMMUNICATION_SYSTEM:  SAPSID of the ABAP communication system (e.g. the domain controller)
- DEPLOY_WEB_SERVICE: CTSDEPLOY (Name of the Logical Port) that is created to connect to the Java Web Service DeployProxy
- DEPLOY_DATA_SHARE: (shared) transport directory (e.g. <DIR_TRANS>\data)
- DEPLOY_URL and/or DEPLOY_SLD_URL and/or DEPLOY_XI_URL and or
DEPLOY_OUTBOX

Note: In the case that your non-ABAP system acts like a source system and also as a target system in your TMS landscape ensure that you apply SAP Note

2202519 ChaRM/QGM: import to non-ABAP system cannot be started for cCTS project

Case 2. Dual-Stack systems
The following Java parameters are added using the wizard in  transaction STMS → Create →Java Stack:
- DEPLOY_DATA_SHARE: (shared) transport directory (e.g. <DIR_TRANS>\data)
- DEPLOY_URL and/or DEPLOY_SLD_URL and/or DEPLOY_XI_URL and or
DEPLOY_OUTBOX
- DEPLOY_WEB_SERVICE: CTSDEPLOY (Name of the Logical Port) that is created to connect to the Java Web Service DeployProxy)
Ensure that CTC: 1.

Once the systems are created in /nSTMS-> Systems go to configure the Transport routes.
Look an example for a Java systems landscape:

The transport routes for the non-ABAP system landscape can be configured as described in the standard documentation. No additional or CTS+ specific configuration is needed.
Specify the transport layer used for the development system, in this case ZXAD.
More details in:
http://help.sap.com/saphelp_nw70/helpdata/en/45/EC25370FDC3481E10000000A1553F6/frameset.htm
http://help.sap.com/saphelp_nw70/helpdata/en/44/b4a09a7acc11d1899e0000e829fbbd/frameset.htm
In ChaRM for non-ABAP systems, notice that we will only use the standard transport layer as they defined in STMS.  So we could only recognize one Q system.
In case you have two Q systems, configure a target group to the two Q systems, this will link your D system to the group by using one transport layer, in this way both systems will be recognizable under the same "standard transport layer".

In Solution Manager 7.1, SAP has introduced the Landscape Management Database (LMDB) as editor and store for landscape data, which works very closely with the System Landscape Directory (SLD) . With Solution Manager 7.1 SPS10, SMSY is reduced to a read-only store for landscape data (see Evolution of Landscape Data Management – Part II: What’s better with LMDB in SAP Solution Manager 7.1, SPS10? ).

Please see the SCN doc Documentation for System Landscape Management – LMDB to know the way to get the systems created in LMDB.

How to get the non-ABAP (technical) systems into the LMDB?

- Some non-ABAP system have their own SLD data suppliers, i.e. the system can register automatically in the SLD. From the SLD they are synchronized to the LMDB.

- Systems without SLD data supplier have to be created manually in the LMDB.

Important notes for Solman system with component ST with patch level <SAPKITL710:
Until this patch level ChaRM is relying on the information in SMSY for the systems managed from ChaRM, so once you have created the systems at TMS level in the domain controller system you need to ensure that this information is updated in SMSY, for that go to SMSY, select the communication system of your non-ABAP landscape and press the button "Read System Data Remote" this will ensure that the information under ABAP Transport System/Client is filled, see that you have the systems also in table SMSY_SYSTEM_OTO with the correct communication system indicated.

For source systems ABAP Transport System and ABAP transport client needs to be filled with the values indicated at TMS level for parameters COMMUNICATION_SYSTEM and NON_ABAP_WBO_CLIENT, for target systems only the ABAP Transport System will be filled showing the COMMUNICATION_SYSTEM value.
Example for a source system:

These two values cannot be maintained manually in SMSY, these values should be retrieved from TMS.

Starting in SAPKITL710 ChaRM will check the system information at LMDB level. For non-ABAP systems don´t try to find this information about communication system/client in LMDB because LMDB is not saving this information, but it is not needed.

However still you need to check that the information of the systems is in table SMSY_SYSTEM_OTO. If this is not the case please run "Read system data remote" in SMSY for the communication system.

Depending on the patch level of the Solman 7.1 you need to create the logical component in SMSY (System Groups and Logical Components, Logical components ->Right click on Logical Components -> Create New Logical Components -> Enter name and product information) or in LMDB (select the Logical component tab).
You need to put the relevant systems into their corresponding system roles, ensure that the system entered fits with the real TMS landscape that you have.
I mean ensure that there are consolidation routes defined from the source system to the first target system and delivery routes created between target systems and from the last target system to production system.
For non-ABAP system you would define a logical component like:

The important remark here is that the logical component contains systems but NO CLIENTS.

For Dual-Stack systems define your logical component as always using system:clients.

To use Change Request Management ChaRM to manage a non-ABAP landscape, you need to define a project in the Solution Manager in transaction SOLAR_PROJECT_ADMIN.
Call transaction SOLAR_PROJECT_ADMIN, choose New Project.
Choose tab System Landscape and then tab strip Logical Components, enter your Logical component and save:

Choose tab IMG Project and create the IMG project:

The IMG project is created in the ABAP communication system:client of the development system specified in TMS parameters COMMUNICATION_SYSTEM and NON_ABAP_WBO_CLIENT.
Note: don’t forget to create the RFC connections for the ABAP Communication system:client in order to be able to create the IMG project.
If there are different non-ABAP development systems sharing the same communication systems, then you should create different IMG projects for each non-ABAP development system separately.

Please see point "25. Special considerations for non-ABAP landscapes in ChaRM" in SCN blog: Change Request Management scenario: Usual questions and known errors

For non-ABAP system, the IMG project is created on the communication system and the CTS project will be created "implicitly". That means, you will not be able to see the CTS project in SPRO_ADMIN in the communicationsystem.
However if you check in table CTSPROJECT, in the solman system, the correct entry is there looking like "SID/IMG project ID”.
So, please keep in mind that you should NEVER activate the CTS project manually for non-ABAP IMG projects.

For Dual-Stack system, the IMG will be created in the development system:client indicated for the source system.

Choose tab Change Requests and select Activate Change Request Management. Choose Create Task List.

See details about how to create the project in SCN doc First steps to work with Change Request Management scenario in Solution Manager 7.1, section 4.

For creating change documents for the non-ABAP landscape don´t forget to create the ibase component for the non-ABAP production system or to check that the ibase component is already created.

Note: For a Java system see the KBA 2022069 - Difference in using IBase and IObject for JAVA systems of Incident management to change mamagement scenario, you need to use in the ChaRM document the ibase component for the parent entry “<SID> + <installation number>" , don´t select ibase component “<SID> <installation> ---“.
For a Hana system only entry “<SID> + <installation number>"  will be create in IB52, select this ibase component for the ChaRM document, see note 1885728 - Change Management: support HANA managed system.

Please pay attention to note 1767384 - Maintaining installation and system numbers in SolMan 7.1:
“Not all systems known in the Solution Manager know both numbers; they are only registered automatically for the system types:
AS ABAP
AS Java
HANA DB “

This means that SLD is getting the system number and installation number for ABAP, JAVA and HANA DB systems, then LMDB will have this information only for these type of system.

So, if you are using systems like SAP Netweaver Master Data Management Server MDM, SAP BusinessObjects Cluster or others technical systems then for these other systems the system registration in SLD does not provide any numbers, the link of the system to both numbers must be carried out manually.
I mean only very few systems (ABAP, Java, HANA) know the concept of installation numbers. Other technologies (from SAP acquisitions) are not familiar with this installation number.

So, for ChaRM scenario up to SAP Solution Manager Release 7.1 Support Package 10 we were reading SMSY and in SMSY this information was usually filled from the SAP Service Marketplace.
“The manual assignment of the installation number and system number was possible up to SAP Solution Manager Release 7.1 Support Package 5 in transaction SMSY. In Release 7.1 Support Package 5, only the system types that automatically register the numbers are supported with the Landscape Management Database (LMDB). For other system types, you currently have to use a workaround.”

Since SAP Solution Manager Release 7.1 Support Package 10 we are reading the information from the LMDB:
“As of SAP Solution Manager Release 7.1 Support Package 8, it is possible to maintain the installation number and system number in the LMDB for all relevant system types. However, the numbers maintained there are not synchronized to SMSY in every case, which means that the workaround described here is not yet obsolete. For the system types AS ABAP and AS Java, the numbers - if they are unique - are automatically transferred from the technical system of LMDB to the product system in SMSY.

As of SAP Solution Manager Release 7.1 Support Package 11, it is possible to maintain the installation number and system number in the LMDB for all relevant system types.”

So in the case that you are not filling the installation number manually, then you need to implement  note  2130165 - ChaRM: no project can be selected when IBase of non-ABAP system is maintained, if the note is implemented even if the system in LMDB is not having an installation number maintained ChaRM will be able to select the correct project for the production Ibase component.
However ensure that the Ibase component for the production system is having in the Identification field the SID of the system, I am saying this because if the installation number is missing in LMDB for a BusinessObject system for example, you will see that the system in IB52 does not appears under the customer number, it appears separately under tree “Cluster SAP BusinessObjects” with an empty Identification field, please enter the BusinessObjects SID in this field manually. Note 2153616 was created to fix this issue.

In the case that you are using a non-abap system that is a virtual system please see the SCN doc Change Request Management: How to create a virtual system in Solution Manager 7.1 pay attention to this paragraph: "Note: If you want to create a virtual system for a non-Abap system take the following into account: strictly speaking there is no non-ABAP virtual system...

2054403 - ChaRM: failed to create test transport for non-ABAP systems

2062414 - ChaRM: error TK 587 for release of non-ABAP requests

1803185 - ChaRM: change document cannot be created for non-ABAP system

2153616 - Enter SID in Ibase identtification when no instno exists

1003674 - Enhancement for non-ABAP systems in CTS

2148577 - RZ70 always sets communication client to 000 for non-ABAP system

2202519 ChaRM/QGM: import to non-ABAP system cannot be started for cCTS project