Configuring CTS+ in Solution Manager 7.0 EhP1
With the following steps you will be able to create a project to practice with the CTS+ scenario in Solution Manager 7.0 EhP1 and in Soution Manager 7.1.
Also I will try to give tips and tricks for the common mistakes in the configuration of this scenario.
I will work in this example TMS landscape for portal systems: XAD->XAQ->XAP
NEWS: For implementing this scenario in SAP Solution Manager 7.1 I created wiki page
Step 1- TMS configuration for CTS+ in solman system
Please check in detail the following document regarding this step:
Other CTS+ resources can be found in http://scn.sap.com/docs/DOC-8576 .
The first step is always to create the system in the TMS of the Transport Domain Controller TDC, also called communication system.
This TDC can be located on the SAP Solution Manager for example in the case of the non-ABAP systems.
Important note: In order to use Charm with the CTS+, the communication system for your non-ABAP systems must have at least SAP_BASIS Release 701 SP Level SAPKB70103 or higher. For more information, check note 1356771.
For the case of a system with only Java-stack create a non-ABAP systems, This system type is needed for all pure AS Java landscapes for example EP, JAVA or SLD.
/nSTMS -> Overview -> Systems -> Create -> Non-ABAP System.
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 (/nSTMS -> Overview -> Systems -> Create ->Java Stack).
However in solman 7.0 we have some limitations for this CTS+ functionality in a dual stack system, as in solman 7.0 we cannot differentiate distinct systems with the same SID, even if they are located in different domains. I mean if you define a system in SMSY with two Main instances, one for the ABAP stack and the other for the Java stack with the Technical name for the Java like in the screen below, the non-ABAP instance of a dual-stack system could not be used in charm because we will still consider it as an ABAP system by reading its main instances from SMSY.
But not only non-ABAP instance will not work, the ABAP instance might also be affected. The logic is this: we try to read the system configuration from SMSY -> we can correctly determine that it is dual stack system because the relevant flags are selected -> but when we want to do the real transport we need to read the domain info -> two systems with exactly the same SID -> cannot differentiate them and cannot get the domain info correctly -> both ABAP and non-ABAP instance might not work in charm.
So, in the case that you want to transport Java objects for ABAP systems (dual-stack) via charm in solman 7.0 them you have two options:
1. If you only want to manage the transport in the non-ABAP stack side, you could simply create the project by using ABAP stack of the system, and create transport requests in the ABAP system. After that, you will be able to use those requests to save non-ABAP changes as well and transport them. This is a existing functionality for CTS+.
2. If the dual-stack system is called DEV, create a non-ABAP system for DEV system but with a different SID in the STMS of the domain controller. Then assign this system to the technical system field of the non-ABAP stack in SMSY entry of DEV, and use this new to create the logical component/projects.
In Solman 7.0 we cannot differentiate distinct systems with the SID, even if they are located in different domains.
In Solman 7.1 this issue will be solved by using the long SID functionality provided by SMSY, that is, systems in different transport domains with the same SID can be managed by charm, you only need to assign them to different technical system names in SMSY, see also note 1523511 beforehand.
Note: In this case we are doing this is the solman system itself because we are going to use the solman system like COMMUNICATION SYSTEM for this non-ABAP system.
In case you want to use another ABAP system like communication system do this TMS configuration in the TMS domain controller of this ABAP systems landscape.
After create a domain link between this TMS domain controller and the domain controller of the solman systems landscape where charm is configured.
The following parameters are mandatory:
For XAD system (source system):
– CTC 0
– CTS_SYSTEM_TYPE JAVA (according to note 1464456 it should be MDM for MDM systems, BOBJ for Business Object systems, HANADB for Hana systems …)
– NON_ABAP_SYSTEM 1
– COMMUNICATION_SYSTEM: CXE
(SAPSID of the ABAP communication system (e.g. the domain controller))
– NON_ABAP_WBO_CLIENT 100
(Client of the ABAP stack on which the Transport Organizer Web UI (CTS_BROWSER) is activated and will run.)
– WBO_GET_REQ_STRATEGY TAGGED
– WBO_REL_REQ_STRATEGY MANUAL
For quality and production Java system (target systems):
– CTC 0
– CTS_SYSTEM_TYPE JAVA (according to note 1464456 it should be MDM for MDM systems, BOBJ for Business Object systems…)
– NON_ABAP_SYSTEM 1
– COMMUNICATION_SYSTEM: CXE
– DEPLOY_WEB_SERVICE CTSDEPLOY
– DEPLOY_DATA_SHARE: <DIR_TRANS>\\data
– DEPLOY_URL: http://<JQS_host>:<JQS_SDM_Port>
Note: This would be the CTC correct value:
CTC=1 Client specific for ABAP and Double Stack systems
CTC=0 Client independent for Java standalone systems
/nSTMS in the solman system -> Transport routes
Look for XAD->XAQ->XAP landscape
Specify the transport layer used for the development system, in this case ZXAD.
More details in:
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”.
Step 2- Definition of non-ABAP Systems in SMSY
The Java system must be defined in this way for a portal system:
Product version: SAP Netweaver 7.0
In selection of Main Instances tab you need to flag as relevant the Enterprise Portal instance:
Always use SLD landscape fetch for systems in Solman EhP1.
Important point: Communication system´s information will be read in the background from the tranport parameter settings on remote systems (“COMMUNICATION_SYSTEM” and “NON_ABAP_WBO_CLIENT”).
I mean this data are fullfilled automatically from TMS, these values can not be maintained in SMSY.
This data are stored in database table SMSY_SYSTEM_OTO. If the relevant entry is missing, try to press the button “Read System Data Remote” for the domain controller of the non-ABAP system in SMSY.
In this example we are using the Solman system itself.
Note: Don’t forget the create the RFC connection for CXE:100 system in order to be able to create the IMG project afterward in solar_project_admin. Also don´t forget to create the ibase component for the non-ABAP system or to check that the ibase component was created automatically.
For the quality Java portal XAQ and XAP created them as explained about for XAD with only one difference, you need to see only the ABAP Transport System and not the client.
Note: Please run Read System Data Remote in SMSY from the communication system to get the data under Transport System/Client for non-abap systems
Note: For a PI system select Java System instance as relevant.
Note: For a MDM system select Master Data Server instance as relevant type MDM server (correct definition for Diagnostics) or Thirdparty.
In the case that you are using a non-abap system tha is a virtual system please see the SDN doc Change Request Management: How to create a virtual system in Solution Manager 7.1
“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….”
Step 3- Definition of Logical Components in SMSY
Note: Not clients are selected.
Note: For a PI system choose Application Server JAVA
Step 4- Definition of a Project and a Task List
To use Change Request Management, 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 communication system of the development system.
If there are different non-ABAP dev systems share the same communication systems, then you should created different IMG projects for each non-ABAP dev system separately.
Please see point “25. Special considerations for non-ABAP landscapes in ChaRM” in SDN blog: Change Request Management scenario: Usual questions and known errors
Choose tab Change Requests and select Activate Change Request Management. Choose Create Task List.
Now you can use the Change Request Management within/with help of this task list.
Tables to check in Solman system:
SMSY_SYSTEM_OTO: check the RFC to the communication system (OTO_SYSTEM and
Now you can work with Charm to manage your changes also for non-ABAP objects, take care of the ibase component selected when you create a change request
document for a non-ABAP object, the ibase component must be the ibase of the
productive Java system, select the upper entry without client. DO NOT use the IBase of the communication system!
The main differences between managing ABAP and non-ABAP sytem are:
– IMG and CTS project is created on the communication system of the non-ABAP development system and not in the development system like for an ABAP system.
– To manage the transport request we will use CTS+ web UI and not se09 like for ABAP systems, however still you can see the transport logs in se09 of the communication system.
– The action “System Logon” for non-ABAP dev system will open a pop-up for the user to choose: 1)Open the CTS+ web UI on the communication system (Request button) or 2)Logon to the non-ABAP system directly (Logon button).
For the non-ABAP qua and prd system action “System Logon” will go to the respective non-ABAP system directly.
Please check note 907768 for all available corrections concerning non-ABPA feature in Charm up to now.
To use the full non-ABAP functinoality in ChaRM, the communication system should have SAP_BASIS version at least NetWeaver 7.01 SP 03 or higher.
If you are going to use normal corrections SDMJ to manage non-ABAP transports, please implement notes 1388112, 1410010 and 1293449 to your SOLMAN system and TMS communication system.
Still there are these restrictions:
– At present empty non-ABAP requests cannot be deleted automatically when releasing them from ChaRM, further correction/development in component BC-CTS-ORG-PLS is required to realize this functionality.
– As a prerequisite for transport request to be used in CTS+ web UI of “Close Coupling”, you must pre-selected it as the default request. Currently we cannot do it in ChaRM. Therefore you have to do it manually for each request in the CTS-Browser within the TMS:
1. Call transaction “STMS”.
2. Press the button “Transport Organizer WEB UI” (or press F7) to start the Browser.
3. Select the system in the popup where the request was created.
4. Mark the request you want to use for the Non-ABAP-Objects
5. Set the marked request as preselected request (button “Preselect Request”).
After that the request is available and can be used to add objects.
Further information in:
1003674 – Enhancementfor non-ABAP systems in CTS
1045501 Integration of CTS+ in Change Request Management
1155884 – CTS+, configuration ‘close coupling’: Troubleshooting guide
Check also notes:
1360910 Deploy error of NWDI or CTS deploy proxy 7.0 to NW CE/7.20
1266133 CommunicationData-Address (no URL):’null’ error