Skip to Content
Technical Articles

How to use the integration of SAP Cloud Platform Transport Management into SAP Solution Manager Change Request Management and Quality Gate Management

Overview

In this blog I will describe how to use the integration of SAP Cloud Platform Transport Management (TMS) into SAP Solution Manager Change Request Management (ChaRM) and Quality Gate Management (QGM). This integration is available since December 2019 with SPS10 for SAP Solution Manager 7.2. In this blog I will concentrate on Change Request Management but Quality Gate Management uses exactly the same infrastructure.

I will start with describing some prerequisites you need to fulfill for this scenario to work. This will be followed by some preparations in SAP Solution Manager ChaRM and Transport Management. After that I will create a TMS transport request, assign it to a ChaRM change document and trigger the imports into the SAP Cloud Platfrom subaccounts by the corresponding status changes in ChaRM. The whole process will be documented by tons of screenshots.

The overall landsacpe looks like this:

 

Prerequisites

  • The SAP Solution Manager 7.2 has at least SPS10 implemented, which is available since December 2019 and ChaRM or QGM are configured.
  • Optionally you can make on premise systems available in SAP Solution Manager. In this example I have connected the SAP S/4HANA on premise systems S2D, S2Q and S2P to the SAP Solution Manager.

Preparations in Transport Management

I have set up SAP Cloud Platform Transport Management following the documentation at Set Up the Environment to Transport Content Archives directly in an Application including the creation of a TMS service instance with a service key. This information is later needed to configure the RFC connections from SAP Solution Manager to Transport Management.

I have also created a transport landscape in TMS which consists of three transport nodes connected to three SAP Cloud Platform Neo subaccounts. This is described in the chapter Configuring the landscape in the SAP documentation. The destinations pointing from Transport Management to the Neo subaccounts are of the format ‘https://slservice.<landscape-host>/slservice/slp/basic/<account-id>/slp/’ where the <landscape-host> part depends on the data center your subaccount runs in. It can be derived for example when you access the ‘Overview’ tab in the SAP Cloud Platform Cockpit. The URL of this page is of the format ‘https://account.<landscape-host>/cockpit#/…’. For subaccounts running in the SAP datacenter Europe in Rot <landscape-host> has the value ‘eu1.hana.ondemand.com’. The <account-id> can also be found on the overview page in the section ‘Subaccount Information – Technical Name’.

In this scenario I am using the Solution Export Wizard to create the TMS transports to be handled by SAP Solution Manager. Therefore the configuration needed for the Solution Export Wizard has to be performed in the Neo development subaccount. Please see the documentation ‘Set Up Direct Uploads of MTA Archives Using the Transport Management Service‘. Basically you are creating a destination to the TMS in the Solution Lifecycle Management service of the development subaccount. You will be using input from the service key of the TMS service instance. Don’t forget the property ‘sourceSystemId’ of the destination to connect to the development node in your TMS landscape.

In the SAP Cloud Platform Cloud Foundry environment the integration works as well, only the creation of a TMS transport request would work differently, because the Solution Export Wizard (which I will be using later) is only available in the Neo environment. In Cloud Foundry environment you would have to either create the MTA from WebIDE and attach it manually to a new transport request or make these steps part of your CI/CD pipeline.

The scenario uses the nodes Till_DEV, Till_TEST and Till_PROD.

What differs from ‘normal’ transport landscapes is that I have set the flag ‘Controlled by SAP Solution Manager’ for the test and production nodes.

I have not set this flag for the development node, because I will use this node for creating transport requests. This is the recommended approach for the TMS – ChaRM integration scenario.

Preparations in SAP Solution Manager

The overall setup procedure for the integration of Transport Management and SAP Solution Manager ChaRM is described in ‘Change Control Management Using SAP Cloud Platform Transport Management Service‘. In detail the following things have to be done:

Create RFC connections to Transport Management (transaction SM59)

I created two RFC connections to allow SAP Solution Manager to communicate with Transport Management:

One connection (TMS_AUTHENTICATION) is used to obtain an oauth token for the API calls from SAP Solution Manager to Transport Management. For this connection I used the information from the Transport Management service instance service key.

These value are used in the SM59 input screens:

The second RFC connection is used for calls to the REST API of Transport Management.

Please make sure to activate the SSL protocol for both RFC connections.

Unfortunately the RFC connection checks do not deliver really useful information. For the authentication RFC the connection check results in error 400 (bad request). This is the expected message and does not indicate a real error. The REST API RFC connection check asks for a user name and password as the expected result.

In some cases we encountered the error message SSSLERR_SERVER_CERT_MISMATCH for the REST API RFC. This can be fixed by setting the paramenter ‘icm/HTTPS/client_sni_enabled’ to TRUE. For more information please check SAP note 510007.

These RFC connections will be used in the subsequent steps.

Create external service systems for the Transport Management nodes (transaction LMDB)

All nodes in Transport Management which should be reflected in ChaRM have to created as external services in LMDB. I have created three external services for the three nodes in my landscape.

There are four special attributes which have to be configured for each node:

  • Is Cloud TMS Node: X
  • Cloud TMS Node Name: The name of the node in TMS, here Till_TEST. Please observe that this name is case sensitive.
  • Cloud TMS Authentication RFC: The RFC connection used for authentication, here TMS_AUTHENTICATION
  • Cloud TMS REST API RFC: The RFC connection used for API calls, here TMS_REST_API

Create a solution using the external service systems (transaction SLAN)

These are the steps which I performed for setting up the solution:

  1. Create a dedicated solution for the SAP Cloud Platform TMS landscape.
  2. Create a logical component group for the SAP Cloud Platform TMS landscape and assign it to the solution.
  3. Assign dedicated external service systems to the related branches of the logical component group.

Additionally, I have added three S/4HANA clients to the solution to show that combined landscapes including ABAP (and non-ABAP) systems are possible. Please observe that central CTS cannot be combined with Transport Management. However, it is possible to have several ABAP and non-ABAB landscapes together with Transport Management within one Change Request Management cycle or Quality Gate Management Scenario. See example below:

 

My overall landscape looks like this:

Create a change cycle with the solution landscape

Now it is time to create a change cycle in which the change documents will be created later.

Start the ‘Change and Release Management’.

 

Go to the ‘Change Request Management’.

 

Create a Change Cycle.

 

I selected ‘Continual Cycle’.

 

The cycle is created in an initial state.

 

I entered a description and selected the solution which contains the Transport Management nodes.

 

I selected the branch of the solution. In this example only ‘Maintenance’ is available.

 

Now the cycle had to be saved and activated.

 

I confirmed the use of Transport Management integration.

 

Now the task list for this cycle is created. The prerequisite checks completed successfully, so I clicked ‘Next’.

 

I double-checked the scope. The transport tracks look as expected.

 

The task list creation can now be triggered.

 

The task list has been successfully created and the change cycle is active.

 

However, the task list is created in a locked status and must be unlocked. For this I opened the task list in the ‘Related Transactions’ of the change cycle (scroll down for this).

 

I unlocked all tasks of the task list by selecting a group and pressing the ‘Lock/Unlock Group’ button.

 

After that all tasks should have the status unlocked.

 

Create a change document within the change cycle

In the next step I created a change document in the change cycle I just created.

Currently the Transport Management integration is based on normal changes only, so I created a normal change.

 

The change is created in an initial state. I now to select the change cycle I just created.

 

I used the term ‘TMS’ which was part of the change cycle description.

 

I now had to provide a Configuration Item for this change.

 

In this example I chose the productive node of the Transport Management landscape. However, this choice does not influence the transport behavior.

 

The change document is now complete and can be saved.

 

In order to attach transport requests to the change document it must be set to ‘In Development’ (and saved).

 

The change document is now ready for the assignment of transport requests.

 

 

Create content for transport

In contrast to the ABAP world for Transport Management the transport requests are not created from within the change document but rather assigned to it after they have been added to the import queue of the test node in Transport Management (pointing to the test subaccount in SAP Cloud platform).

There are several options to achieve this:

  • Manual upload of the content to the development node and import into the development node. By this the transport request is forwarded into the test node queue.
  • Automated upload to the development node from a CI/CD pipeline and manual import into the development node. By this the transport request is forwarded into the test node queue.
  • Direct export from the development subaccount using the Solution Export Wizard (only available for SAP Cloud Platform Neo environment).

Currently we are working to enable the direct upload of the content to the test node, so that the manual import into the development node is not necessary anymore.

For this example, I have used the Solution Export Wizard approach.

 

In my SAP Cloud Platform development subaccount, I opened the ‘Solutions’ tab and clicked on ‘Export’. This starts the Solution Export Wizard.

 

The Solution Export Wizard now analyzes which applications are running in this subaccount and puts them into a list sorted by application type.

 

I selected the content I wanted to transport (in this case an HTML5 application). It is also possible to select several items. Please note that Java applications can currently not be exported.

 

I now had to provide some information for the export:

  • Title and description
  • Solution ID (here ‘Demo.ChaRM.Neo’)
  • Three part version number

I also selected the Export of the MTA archive to Transport Management Service. This subaccount was configured to act as transport node ‘Till_DEV’ in my transport landscape as described here. I confirmed my entries by pressing ‘Export’.

 

The export completed successfully and created a transport request in the queue of the node ‘Till_TEST’.

 

To verify the success, I switched to Transport Management and opened the queue of the transport node ‘Till_TEST’.

 

You can see the newly created transport request in the import queue of the node. As the node is controlled by Solution Manager, it is not possible to manually trigger the import.

 

Assign Transport Request to Change Document

Now it is possible to assign this transport request to the change document in SAP Solution Manager ChaRM. The corresponding functionality can be found when scrolling down on the change document screen.

 

In the ‘Transport Management’ section I opened the drop-down ‘More’ and started ‘Assign Transport Request’.

 

The search can be specified by search criteria (which I didn’t do).

 

The Transport Management transport requests appear with an internal request ID. Therefore, it is important to identify the correct transport request by the descriptive text. After selecting the required requests, I pressed ‘Assign Transport Request’.

 

The transport request is now assigned to the change document. It is not yet imported to the test subaccount.

 

Set Change Document to ‘To be Tested’

I now changed the status of the change document to ‘To be Tested’. This triggers the import of the assigned transport request into the test subaccount.

I selected ‘Pass Normal Change to Test’ from the ‘Actions’ menu and saved the change document. This triggers the import of the assigned Transport Management transport requests (and also a transport of copies of potentially assigned ABAP transports).

 

The change document is now in the status ‘To be Tested’.

 

The import status of the request has changed to green (= imported).

 

I checked the status of the transport request in the queue of the test node in Transport Management. It has been successfully imported. I also opened the transport log by clicking on the corresponding icon.

 

The transport log shows the successful import.

 

Additionally, I checked the import queue of the production node.

 

The transport request has automatically been forwarded to the import queue of the production node and is waiting there to be imported when the change document reaches the corresponding status.

 

Handling of errors during test

Please note that in contrast to the ABAP transport request there is no transport of copies for the Transport Management transport requests. If you find errors during testing which require development changes on the SAP Cloud Platform you have to create a new transport request and add it to the queue of the test node (with the methods discussed above). However, in order to assign it to the change document you have to reset the status of the change document to ‘In Development’. The import of the new transport request is then triggered upon the status change to ‘To be Tested’.

I did not use this option in this example.

 

Perform further status changes

I now ran through the next status changes of the change document in SAP Solution Manager ChaRM. Due to my comparably simple landscape this resulted not in further transports (of Transport Management Requests).

I confirmed the successful test.

 

The status changed to ‘Successfully Tested’.

 

I approved the preliminary transport.

 

The status changed to ‘Testing for Preliminary Import’.

 

I confirmed the successful test.

 

The status changed to ‘Tested for Productive Import’.

 

I authorized the productive import.

 

The status changed to ‘Authorized for Import’.

 

Trigger transport into productive node

The final step was to set the status of the change document to ‘Import Normal Change into Production’. This triggers the import of the transport request into the productive node in Transport Management.

 

The status changed to ‘Imported into Production’. 

 

I switched to the import queue of the productive node Till_PROD in SAP Cloud Platform Transport Management. The transport request has been successfully imported into the productive subaccount.

 

Summary

The new integration of SAP Cloud Platform Transport Management into SAP Solution Manager Change Request Management and Quality Gate Management allows you to document all aspects of a change, on premise and in the cloud, in one place. It also synchronizes the transports in the different landscapes. This is a great step forward for managing changes in hybrid landscapes.

 

2 Comments
You must be Logged on to comment or reply to a post.
    • Hi Jalandhar Reddy,

      yes, that is correct. As the transport of CPI packages is based on MTA archives you have to perform the steps mentioned in the documentation. On top of that there is specifically for CPI an additional destination needed: you have to configure the destination ‘CloudIntegration’ as described in ‘Creating HTTP Destination in Solutions Lifecycle Management‘. This step has to be performed in all subaccounts hosting a CPI tenant.

      After that you are able to create CPI transports directly from your CPI development environment, which then appear in the import queue of your CPI test tenant and can be attached to your ChaRM change document as described above.

      Kind regards

      Harald