How to use the integration of SAP Cloud Platform T...

Harald_Stevens · ‎04-27-2020

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:

Create a dedicated solution for the SAP Cloud Platform TMS landscape.

Create a logical component group for the SAP Cloud Platform TMS landscape and assign it to the solution.

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.

Troubleshooting

There are many potential sources for issues in this rather complex setup. For troubleshooting purposes in the SAP Transport Management setup I would propose the following approach:

Check the destinations pointing to the target subaccounts. They should return HTTP code 200 (success)

Set up your landscape without the 'Controlled by SAP Solution Manager' flag

Manually upload a test MTA to the first node in your landscape using the 'Add' functionality in the import queue

Import the transport request in all your nodes

This proves that transporting works in principle. Otherwise analyse the error messages provided in the transport logs

Enable the 'Controlled by SAP Solution Manager' for the test node and the productive node and continue with tests including SAP Solution Manager

For analysing potential issues with SAP Solution Manager Change Request Management I recommend this very extensive Wiki.

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.

former_member549471 · ‎07-03-2020

Thanks for sharing nice document. I want to integrate only CPI with ChaRM. Please confirm what are the steps need to perform at cloud side. do we need to perform below steps for CPI as well?

Set Up the Environment to Transport Content Archives directly in an Application

Harald_Stevens · ‎07-08-2020

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

former_member123527 · ‎09-28-2020

Dear Harald,

we try to follow your great blog, and now we are in the phase to create a Change Cycle based on our Change Control Landscape. But we get an error taht no productive System is in the landscape.

Is there any flag to be set that the last system is the prod system ?

From SCP TMS Node there is no entry to say is prod, only on the subaccount level. So any hint where we can maybe set prod so taht the config can be go on.

Best regards

Thorsten

Sharath_vuppula · ‎10-10-2020

Hi Harald,

Thanks for clear explanation and images. Can we use those RFCs(or new ones) for CSOL entries for downgrade protection here?

Best Regards,

Sharath.

chupakebr · ‎08-09-2021

CSOL / DGP currently not supporting non-ABAP systems.

chupakebr · ‎08-09-2021

Hi Thorsten!

Prod. system, which you use in Solution administration (t-code SLAN), should be marked as Production in t-code MAINT_ROLES.

former_member756379 · ‎09-06-2021

Hi Harald,

Thanks for this blog.It's very useful.So, I have created Ext IDs in LMDB and setup SLAN.Now when i create task list it shows No system landscape defined.I checked but did not get the reason where did I go wrong.Could you please help here.

Thanks

Neha

Harald_Stevens · ‎09-07-2021

Hi Neha,

great to hear that to find the blog post useful.

It is of course difficult to find an issue in the fairly large number of configuration steps without really seeing it...

However, there is one thing you could check: if you are on SPS 10 or 11 for SAP Solution Manager 7.2. you would have to implement SAP note 2929892

Without this note there is an issue with handling the authentication tokens which keeps the scenario from working. This issue is a side effect from a change in SAP BASIS.

Hope that helps...

Kind regards

Harald

former_member756379 · ‎09-07-2021

Hi Harald,

Thanks for your reply.I will definitely check on this Note and get back to you.

Thanks

Neha

former_member756379 · ‎09-13-2021

Hi Harald,

The previous error is fixed by implementing the Note.Now it says "Transport track of source system CPD~EXT_SRV does not include a production system".

Does this mean something wrong in TMS configuration in Cloud platform?

TMS is as shown below.

SLAN looks like below.

former_member756379 · ‎09-17-2021

Hi Everyone,

For those who are facing same error, we solved it by creating TMS setup Linearly .Before that we had 3 systems as QA and there is no concept of transport group in Cloud TMS .Hence, it was not working.

Thanks

Neha Singh

former_member723678 · ‎09-17-2021

Hi everyone:

Harald thank you very much for these blogs so well explained, they were very useful.

Neha that 's correct, there is no transport group in Cloud TM, but you can create different options of routes, something like this:

1) First create the different nodes.
2) Then the combinations of routes that you need.

I haven't tried it with ChaRM yet, because I just created it to show you a possible alternative.

I hope this is the solution you are looking for and that it is useful for you.

Best Regards,

Alejandro Schiffrin.

former_member756379 · ‎09-17-2021

Hi Alejandro,

Thanks for your suggestion but we have already tried this approach too.it did not work and so we have to create TMS like

DEV>QA1>QA2>QA3>PRE PROD>PRO

And then scheduled the import job for all 3 QA systems every 5 mins with 2 minutes of gap so that when Cd is set to to be tested, the TR moves to QA1 and then to QA2 after 2 minutes and finally to QA3.

Also, as the TR assigned to Cd is already released and so it moves to QA1 automatically when the job is running although when Cd is in development status.To prevent this, i have created status dependent import in Import strategy for Cd status "To be Tested" and QA1 system.

Now Charm looks good with this setup:)

Thanks

Neha Singh

S0000587367 · ‎10-12-2021

Harald,

Thanks for this wonderful explanation on this difficult process. You make it sound easy.

I still have an issue:

We created a Charm ticket for our Cloud Foundry landscape

Created a transport in Transport organizer and attached a MTA file to it. Release the transport successfully and is visible from the target system in STMS.

The issue is:
1. how to add it to the Charm ticket so the complete change is move via Charm and not directly from STMS?
2. when we tried to add the release transport to the Charm ticket: More -->Assign Transport Request
3. we could not find the transport in the Search area.

is there something we missed in the setup?

Your guidance is appreciated if this situation is possible.

Thanks,

Jose

former_member756379 · ‎10-14-2021

Hi Jose,

Please try searching with *1234* in or just click on search with no input.the TR number is not same in Charm, it must be like C000000* .

jereme_swoboda2 · ‎12-10-2021

Hi Harald,

Thank you for the great blog. We are having in issue with the first step, Identifying the URL from the Transport management service keys in cloud foundry to create our RFC's in Solution Manager. When we look at our service keys in cloud foundry for the Cloud transport management, we only see one service key. When we open it, it is blank. When we select create, we are asked for a JSON file that we dont have.

How do we create the service key properly in cloud foundry? We need URL's to enable the creation of the RFC's.'

Thank you

Harald_Stevens · ‎12-10-2021

Hi Jereme,

please review the steps to create a service instance as described here in the chapter 'Steps to Use Cloud Transport Management Using Programmatic Access'

After you have created the service instance it should look like this (except for the key):

If you then create a new key (by choosing this activity from the three dots at the end of the line) the entry screen should look like this:

You don't have to provide a JSON file, just leave it empty. The only necessary input is the name of the key. Click on 'Create'.

After a few seconds the new key should appear:

From the three dots choose 'View'. The result should look like this:

Hope that helps...

Kind regards

Harald

steven_foo · ‎08-19-2022

We have setup 3 landscape CPI with CTMS.

We test the export from DEV to QAS successfully. We are able to import import QAS and it auto forward to PRD.

1) The issue we see the transport owner is not the email of user.

2) In the instance and Subscription in QAS, we do see an automatic created instance -- process_integration_transport_instance_mtls. Inside this instance for every transport that we import it created automatically each Service Key for each transport.

Any idea how to resolve the above? it should be that for every transport it will create a new service key and also the owner name is not human readable which is required by audit.

jesper_schjoedt · ‎09-07-2022

I have setup TMS on our CF and transport routes for Dev -> Test -> Qas -> Prod for transporting MTA objects.

Everything is working as expected, after import the data is automatically placed in the import queue for the next node defined in "routes", ready for import in the next tenant.

The owner of the transport is an ID and not an email or a username which would be nice, but I will try and see if I can find a solution for this.

A new instance "process_integration_transport_instance_mtls" is automatically created in the Test, Qas and Prod tenants which is all fine and good.

However, a new service key is created for each transport, is this intentional?

This will eventually make quite a clutter of service keys, is it not possible to setup a single service key that can be re-used?

I am looking forward to hearing any good ideas

biswajit_singh1 · ‎09-08-2022

Hi Harald / SAP Team ,

We are on cloud foundry at the moment so it seems manual addition of transport will be needed for us going forward. Once we generate the transport request in the development tenant , would that transport be available for search and assignment to a charm document ? And would be need to make use of the descriptive search field to query the request similar to what you have performed here ?

Many Thanks,

Biswajit Singh

michael_sharrar · ‎09-09-2022

Yes, the Cloud TMS transport should be available when using the "Attach Transport Request" option in ChaRM.

You can use Request/Task = C* to find all of the relevant cTMS transports.

However, I'm getting an error when trying to attach the transport. Do we also need to add the Cloud TMS nodes into the on-premise STMS domain controller?

I did not see any error during the change cycle creation process (did not have any configuration added in STMS at the time of creating the change cycle).

marc_guillem · ‎09-20-2022

Hi harald.stevens / SAP,

We switched from cTMS in one of our subaccounts to CALM and now we cannot assign the BTP transports to a Change Document as they are not being displayed on the search list.

If we transport using the Cloud Transport Management app everything goes fine.

We think it might be either because:

1. TMS_AUTHENTIFICATION RFC and TMS_REST_API return the following error when we test the connection:

TMS_AUTHENTIFICATION: Connect to https://<cloudalmbaseurl>.authentication.eu10.hana.on demand.com:443 failed: NIEHOST_UNKNOWN(-2)

TMS_REST_API: Connect to https://eu10.alm.cloud.sap:443 failed: NIEHOST_UNKNOWN(-2)

We have the following settings:

TMS_AUTHENTIFICATION:
- Target Host: https://<cloudalmbaseurl>.authentication.eu10.hana.ondemand.com
- Path Prefix: /oauth/token
- User: ClientId from CloudALM API service key
- PW: SecretId from CloudALM API service key

TMS_REST_API:
- Target Host: https://eu10.alm.cloud.sap (from CloudALM Service key)
- Path Prefix: /api/imp-cdm-transport-management-api/v1 (from CloudALM service key)

2. Error on the LMDB definition

Kind Regards and thanks in advance,
Marc

biswajit_singh1 · ‎10-06-2022

Hi Michael,

Were you able to resolve this issue ? Per my understanding there is no need to make any changes in the stms domain controller.This doc does not state anything similar either. It might have to do something with the LMDB setup so you could consider checking it once again. If not maybe involve SAP to look into this issue.

Thanks,

Biswajit.

michael_sharrar · ‎10-10-2022

Yes, my issue was resolved and the integration is now working as expected between Cloud TMS and ChaRM.

In my case the issue was a mismatch of the RFC destination name in the LMDB. The destinations are case sensitive, and we had a mix of upper and lower case in the LMDB compared to SM59.

No changes were required in STMS.

michael_sharrar · ‎10-13-2022

Hi Marc,

We had a similar issue during our initial configuration and found that we needed to apply several OSS notes in our Solution Manager system (7.2 SP11).

I would suggest looking at these notes to see if they apply to your system:

2929892

2939808

3109933

3132124

3198727

Also, per note 2712590, parameter icm/HTTPS/client_sni_enabled should be set to TRUE.

Thanks,

Mike Sharrar

biswajit_singh1 · ‎11-03-2022

Hi Harald,

Could you please help understand if there is any certificate to be used on STRUST when deploying the rfc TMS_AUTHENTICATION and TMS_REST_API .

Harald_Stevens · ‎11-03-2022

Hi Biswajit,

yes, as we are requiring HTTPS / SSL communication for the RFC connections you need to install a certificate for SAP BTP in STRUST.

The easiest approach is to use the root certificates signed by DigiCert:

https://dl.cacerts.digicert.com/DigiCertGlobalRootG2.crt

https://dl.cacerts.digicert.com/DigiCertGlobalRootCA.crt

See also SAP note 2853519

Kind regards,
Harald

yannickbieber · ‎11-15-2022

Hello Steven,

Did you get feedback on your challenges or were you able to resolve the issues yourself?
We have the identical behavior and would be happy for any feedback or assistant.

Thank you!

Kind regards,
Yannick

biswajit_singh1 · ‎03-13-2023

Hi Harald,

We finished deploying our charm landscape with the above mentioned instructions however on testing we have encountered one issue. We we are trying to import the TR on QA through charm,the program is throwing a dump and this happens only for ctms changes.Other changes are working fine. Below is the error we are getting.

CHARM error

Any idea what could possibly be causing this and if there is a note that could fix this. We suspect it could possibly be because the charm ids might be too long for the program to recognize.

Best Regards,

Biswajit.

BorisZarske · ‎03-14-2023

Hi Biswajit,

Thanks a lot for reaching out! Our developers have taken a look at your error message and assume an issue in the SAP CRM coding, not directly in the ChaRM coding. For further analysis, please open an incident under the component SV-SMG-CM.

Sorry for the inconveniences and thanks a lot for your support,
Boris

biswajit_singh1 · ‎03-14-2023

Hello Boris,

Thanks a lot for your suggestion on this topic. We will be opening an incident briefly for this issue.

Best Regards,

Biswajit.

FabricioPereira · ‎06-13-2023

Hello harald.stevens,

Thanks for this great blog.

You mentioned that 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.

Do you have any news on this feature? We integrated CI/CD to CTMS and would like to avoid the manual import in the Dev node.

Do you have any suggestion on how to improve this process?

Regards,

Fabricio

Harald_Stevens · ‎06-14-2023

Hi Fabricio,

great that you liked the blog post 🙂

I am not quite sure if you attached this question to the correct place, because at least in the scenario of the blog post there is no manual import into the DEV node necessary. The same is true if you connect CI/CD service to cTMS integrated with SAP Solution Manager ChaRM. Here it is also possible to upload the content from the pipeline directly to the TEST node and ChaRM can handle that. Please see this example for the release stage of the CI/CD service:

The only thing which is not working with this approach is setting the flag 'Controlled by Solution Manager' for the TEST node, because this would block the upload.

However, the situation looks differently if we look at the combination of CI/CD service, cTMS and Cloud ALM. Here at the moment it is necessary to upload the application MTA from the pipeline to the DEV node, so that the transport request has the correct entry node from the Cloud ALM point of view. But Cloud ALM then expects the transport request to be in the import queue of the TEST node, which can be achieved (currently) only by triggering a manual import into DEV before starting to manage the further imports via Cloud ALM.

Let's assume we are talking about this scenario...

We already have started with implementing the mentioned option. As a first step we implemented a project Piper step to use the 'export' API of cTMS: https://www.project-piper.io/steps/tmsExport/

This allows to specify an entry node for the new transport request (like DEV). The request is then placed into the node(s) following this entry node (for example TEST). This would be how Cloud ALM expects it (and by the way how Solution Export Wizard does it in the above example).

What is still missing, and we plan to implement in Q3 or Q4,2023, is the making this option available from the CI/CD service UI.

To sum it up: the scenario with CI/CD and ChaRM is working already now by specifying the TEST node as upload target. The scenario with CI/CD and Cloud ALM in the moment requires a manual import into DEV node, but we are working on it.

Kind regards
Harald

FabricioPereira · ‎06-14-2023

Thanks harald.stevens for the detailed answered.

We are currently working with CI/CD >> cTMS >> ChaRM.

In cTMS we have the following transport route:

DEV (not controlled by SolMan flag) >> QAS (controlled by SolMan flag) >> STG (controlled by SolMan flag) >> PRD (controlled by SolMan flag)

CI/CD is uploading to the QAS node but the node had the flag 'Controlled by Solution Manager' and it was preventing the uploading from completing.

If I understood correctly, we should keep uploading to QAS but remove the flag from that node to successfully perform the action, right?

Do you see any risk/issue by removing the flag on QAS node?

Please, confirm this assumption so we can complete our configuration.

Thanks in advance,

Fabricio

justin_tobias3 · ‎07-06-2023

Fantastic Blog Thanks

Question, we configured Dev, QAS and Prod systems, but in Solution Manager when I'm trying to activate the Cycle I get an error 'No consolidation system for development system TFD~EXT_SRV'

any idea what this could be?