
Nov, 2024: SAP Readiness Check for SAP Cloud ALM includes a new dashboard “Change Request Management Insights”. More details in section 8. Transition Phase from SAP Solution Manager Change Control Management to SAP Cloud ALM Change and Deployment Management
Dec, 2024: Transport Checks are delivered, check section 4.2.8. Transport Checks
Image/data in this article is from SAP internal systems, sample data, or demo systems. Any resemblance to real data is purely coincidental.
With the following steps you will be able to create a test landscape to practice with the SAP Cloud ALM Deployment Management scenario without creating interferences with the real TMS landscapes.
SAP NetWeaver Application Server for ABAP (7.40 or higher) can be an SAP S/4HANA On-Premise system, a SAP S/4HANA Cloud Private Edition, and an ECC system, where SAP Cloud ALM integrates with the Change and Transport System (CTS).
Also, I will try to give tips and tricks for the common mistakes in the configuration of this scenario.
I would always refer to the official documentation specific points as this is not a documentation blog. This content has the aim to help you in troubleshooting issues you may have during the configuration and use of the SAP Cloud ALM Deployment scenario, in this case for the CTS integration.
Please to fully understand the workflow of the Implementation scenario I recommend you spend time reading the PDF document and watching these demos from the SAP Cloud ALM for Implementation - Expert Portal, demos recorded in Sept 23:
End to End Implementation Process (PDF download)
DEMO: Introduction & process 7 MIN
DEMO: Part 1 - Create Project and Select Scope 9MIN
DEMO: Part 2 - Conduct Fit-to-Standard Workshops 14 MIN
DEMO: Part 3- Create and Plan User Stories 7MIN
DEMO: Part 4 – Create Feature, Assign Transports and Deploy to QAS 3MIN
DEMO: Part 5 – Test Preparation 5MIN
DEMO: Part 6 – Test Execution and Defect Management 4MIN
DEMO: Part 7 - Deploy to Production 2MIN
This blog is focused on this part of the Implementation Process:
Download from the Expert portal this document SAP Cloud ALM - Change and Deployment Management Overview.
If you want to be aware of the latest information please check the SAP Road Map Explorer.
I would like to highlight also the presentations and recordings of the last ALM Summit EMEA 2024, get all the material in this link.
SAP Cloud ALM application reads important information about the system landscape such as the systems included in the transport track, consolidation and delivery transport routes from the system acting as domain controller, use case Feature Deployment: Read Transport Landscape or Transports: Read Landscape as you will see later on.
Usually, you would like to use SAP Cloud ALM Deployment Management scenario to manage changes in this kind of system landscapes:
DEV:100 -> QUA:200 -> (PRE:XXX) -> PRD:300
The test landscape that I am proponing is one using one of your systems like an S/4HANA 2021 Cloud Private Edition where you have created three additional clients, let say clients 100, 200 and 300.
Note: You could even test with your own SAP Solution Manager by creating clients 100, 200 and 300.
I have an S/4HANA Cloud Private Edition internal system with SID S4H where I created clients 100, 200, 300.
S4H:100 is going to represent the Development system, S4H:200 the first target system, Quality system, and S4H:300 the Production system, S4H system is also the domain controller.
See the usual parameters of an ABAP system at TMS level, in /NSTMS select Overview -> Systems and then double-click in the system, go to Transport Tool tab:
CTC 1
IMPORT_SINGLE_ONLY 1
IMPORT_SINGLE_STRATEGY 1
NO_IMPORT_ALL 1
REPEATONERROR 8
STOPONERROR 9
WORKFLOW_STRATEGY 0
Note: If you would like to import into different system:clients than the export system:client you need to activate the Extended Transport Control, meaning CTC=1. Please see this functionally explained here Change and Transport System - Extended Transport Control.
In the SAP Help portal documentation, SAP S/4HANA Cloud, Private Edition and On-Premise Systems you can see you can see under a Tip section this information:
“We strongly recommend using always client-dependent transport routes (TMS option CTC) from the very beginning. By using client-dependent transport routes, you can always enhance your landscape with additional clients. Turning on client-dependent transport routes at a later point in time is a complete landscape change that isn't supported while there are still transports open.
We strongly recommend using a transport target group as consolidation target. By using the transport target group, you can always change your consolidation systems by just changing the systems within the consolidation target group while technically the consolidation target (which is the consolation target group) stays stable.”
Last remark regarding changes to the transport track after connecting and using it in a Feature.
If you have transport requests released pointing to a target system, without a client, as CTC was not set to 1, and then you add CTC=1 and rebuild your transport track using clients, in the Feature for the transport request the target tenant will be empty and the Deploy could not be triggered.
Unfortunately the target tenant for the transport requests released before the TMS configuration change cannot be derived on SAP Cloud ALM end.
Here the only option is to export the list of all features from the Features Overview. In the Transports column you can select all transports and filter for them in the target system import queue.
For the old ones already released you should import through STMS.
It is only recommended to change the TMS configuration in case the Features are already deployed or transports are still modifiable.
So, this is how this test landscape will look like:
Don´t forget to create a package for the changes of the workbench objects.
Being in /nSTMS, select Display transport routes, and click in Environment-> Packages
Click on Create
In SCC4 assign the following client settings, roles, etc. to these clients.
It is necessary to establish a connection between the Change and Transport System (CTS) of those managed systems and the SAP Cloud ALM application.
The whole communication between the SAP Cloud ALM tenant and the CTS of your managed systems transport track is going to be done through the ST_PI SW component of your managed systems that calls the SAP Cloud ALM application through the SAP Cloud ALM API service instance credentials.
To set up the connection between your managed systems and the SAP Cloud ALM applications like Deployment, you need to retrieve your service key or binding credentials of the SAP Cloud ALM API service instance and then connect your SAP systems to your SAP Cloud ALM instance, by running the /SDF/ALM_SETUP on the managed systems, clients of your TMS transport track.
Please watch these videos in the SAP BTP Onboarding Resource Center, section View Targeted Videos (Quick Hit Videos) to get a basic understanding of Business Technology Platform BTP:
When requesting the provisioning of the SAP Cloud ALM product, SAP automatically creates:
A global account is the realization of a contract you made with SAP. It's region-independent, and it's used to manage subaccounts, members, entitlements (including your SAP Cloud ALM entitlement), and quotas.
Subaccounts let you structure a global account according to your organization's and project's requirements with regard to members, authorizations, and entitlements.
All the required action at BTP level related to SAP Cloud ALM are done in this “SAP Cloud ALM” global account and subaccount.
Depending on the date when you requested the SAP Cloud ALM tenant provisioning there are different ways to get the SAP Cloud ALM API service key/binding credentials, see these different option in the SAP Help Portal section Enabling SAP Cloud ALM API
Before 2023-06-12:
Example for the service key in the SAP BTP cockpit for SAP Cloud ALM subaccount:
Example for the binding credential in the SAP BTP cockpit for SAP Cloud ALM subaccount where Cloud Foundry environment is not activated:
Between 2023-06-12 and 2023-10-16: you will only need to create manually a new instance for the SAP Cloud ALM API if you want to use the Deployment scenario described here, follow all the instructions on SAP Help portal Enabling SAP Cloud ALM API in Cloud Foundry step, section Maintain an Instance, pay attention to the step Paste the following JSON code into the text editor as
{
"xs-security": {
"xsappname": "<your-instance-name>",
"authorities": [
"$XSMASTERAPPNAME.imp-cdm-feature-display-ui",
"$XSMASTERAPPNAME.imp-cdm-feature-manage-ui"
]
}
}
You can see the service key also in the SAP Cloud ALM tile Landscape Management app, under the Settings.
On or after 2023-10-16: A binding was generated automatically.
You can skip these steps altogether and access your binding in the SAP BTP cockpit, information here:
Enabling SAP Cloud ALM API https://help.sap.com/docs/cloud-alm/setup-administration/enabling-sap-cloud-alm-api-in-cloud-foundry
The SAP Cloud ALM API service key or binding credentials, see SAP Help portal Managing the service key https://help.sap.com/docs/cloud-alm/setup-administration/service-key
includes the following information:
To set up the connection between your managed systems and the SAP Cloud ALM applications like Deployment, you need to retrieve your service binding credentials, and connect your SAP systems to your SAP Cloud ALM instance, you will need to enter the SAP Cloud ALM API service key when running the /SDF/ALM_SETUP on the managed systems, clients of your transport track.
This means that the technical prerequisites indicated below needs to be perform in all the systems that you want to manage from SAP Cloud ALM that are part of the TMS defined transport track.
SAP Cloud ALM doesn't directly perform actions on the ABAP systems itself. Instead, actions such as create, release, and import are triggered from your feature. Such tasks are executed by the TMS using the tp commands to create, release, or import the TR, ToC. So, if you encounter any issues in the managed ABAP system related to the TR release or import, you should inspect this in the TMS.
Then the transport-related data about the transport requests release/import status is pushed back to SAP Cloud ALM from your managed systems.
With the SAP Cloud ALM API key/binding already created now we need to prepare the managed systems included in the transport track.
Look for the prerequisites in the Operation Expert Portal, Landscape Management -> Setup Managed Components (Services/Systems).
Select your managed systems type, possible options to use the CTS integration are:
This is the one I need to follow for my test scenario! SAP S/4HANA cloud, private edition.
All these three links contain a section called Transport Management that links to the SAP Help Portal page: SAP S/4HANA Cloud, Private Edition and On-Premise Systems
However, in these pages in the Operations Expert portal if you scroll down you will find also a section called Prerequisites with three tabs:
Go firstly to these three tabs and later to the SAP Help portal page SAP S/4HANA Cloud, Private Edition and On-Premise Systems
SAP_BASIS Release:
SAP_UI Version:
ST-PI Version:
System parameters and required certificates
icm/HTTPS/client_sni_enabled TRUE
For my system I changed the value to
ssl/client_ciphersuites 150:PFS:HIGH::EC_X25519:EC_P256:EC_HIGH
The communication between your ABAP system and SAP Cloud ALM happens from the ABAP system towards SAP Cloud ALM. Hence you do not need to install an SAP Cloud Connector if you only want to use transport management use cases.
To successfully establish the connection from the ABAP system to SAP Cloud ALM:
More information here, select Network Prerequisites tab
You need two users, the one running /SDF/ALM_SETUP and the one used in the jobs
If you do not use the harmonized RFC communication infrastructure, make sure that the user who triggers the import into the target system client exists with the same name in client 000 of the target system. The user needs to have trusted authorization (authorization object S_RFCACL) and import authorizations. The user needs to have at least the authorization profile S_TMW_OPERA in client 000 or role SAP_CM_MANAGED_OPERATOR or SAP_CM_MANAGED_ADMIN. These roles also include the import authorization.
More information here, select Required Authorizations tab and also in But also read the information in SAP S/4HANA Cloud Private Edition and On-Premise Systems.
As my system has these SW components levels:
According now with the information under SAP S/4HANA Cloud, Private Edition and On-Premise Systems
these are the SAP notes to be implemented and in this order:
Since Feb 2024 SAP Note 3322679 is included in the new SAP Note 3425282 that gets the title SAP Cloud ALM - CDM: Master Note - CDM: Master Note
Note: It's recommended to use the latest ST-PI patch level and always implement the ST-PI collective note and then the SAP Cloud ALM- CDM Master Note, in this order!
After getting the system ready are ST-PI level, let continue with the setup
by establishing the connection from the managed system to the SAP Cloud ALM application.
SAP S/4HANA Private Cloud Edition uses a PUSH mechanism to push transport management data to SAP Cloud ALM.
It is important to notice that we are following the Expert portal for Operation, so here we need to follow the given indications but we need to know that you must transaction /SDF/ALM_SETUP in the managed systems always in client 000 plus the source system:client where the transport request will be created.
For example, in landscape DEV:100-> QUA:200 -> PRD: 300, domain controller PRD, you will need to run /SDF/ALM_SETUP exactly in PRD:000, DEV:000, QUA:000 and in DEV:100.
For our test landscape SH4:100 -> SH4:200 -> SH4:300, domain controller S4H, you will need to run /SDF/ALM_SETUP in S4H:000 and in S4H:100.
We will come back to this more in detail in section 3.1.5.6. Use cases, as we need to configure the PUSH Data Provider in these clients but activating specific use cases that will depend on the role of each system:client in that transport track DEV:100-> QUA:200 -> PRD: 300.
Enter any name like for example CALM_CONNECT.
This name will be part of the RFC destination type G that you will get created when clicking in the Register button, RFC name in this case will be ZSDF_CALM_CONNECT.
As I am using the same managed system I can use the same Target ALM Description when running /SDF/ALM_SETUP in clients 000 and then in client 100, as you don´t need to have two different RFC with the same content to push the data to SAP Cloud ALM.
If you need to create a new destination always delete the old one by clicking in Delete Destination, it is worth to also delete the associated RFC in SM59, enter a new name for the destination.
Click "Update destination" and paste the SAP Cloud ALM API service key/binding credentials that you got in section 2.1.
As indicated in section 3.1.3. Required Authorizations:
"The user you specify as background user requires the PFCG role SAP_SDF_ALM_METRIC_PUSH_FND (SAP Note 3104662) and the role SAP_BC_TRANSPORT_ADMINISTRATOR."
More information here, select Required Authorizations tab.
In the system where you run the /SDF/ALM_SETUP in client 000 as first run you will get these messages if you selected name CALM_CONNECT for the Target ALM Description field.
Scheduler job for CALM_CONNECT has been scheduled.
Auto Discovery job for CALM_CONNECT has been triggered.
At this point of time, you have not selected any use case yet, only registering the jobs. You can see these jobs in client 000:
This is the job CALM Scheduler … the one that we need to ensure is being in Released status as this one is the one that will trigger the other Deployment jobs that will push the transport management data to SAP Cloud ALM.
If the registration is ok you will get an entry under Landscape Management for S4H:000 with the same LMS ID.
3.1.5.6. Activation of Deployment Use cases
In /SDF/ALM_SETUP now you need to go to section 4 and click on Activate usecases button.
What use cases activate we need to active in which system client?
For example, in landscape DEV:100-> QUA:200 -> PRD: 300, domain controller PRD, you would need to run /SDF/SETUP and activate these use cases:
Feature Deployment: Read Transport Landscape Information taken from here
Feature Deployment: Manage Transports
Feature Deployment: Import Transports
Deployment: Manage Transport per Client
Note: after implementing the latest version of the CDM master note in my managed system S4H I can see the use cases names changes to these ones:
Despite the names change what is important is to point out for this test landscape, is to set the Collection Interval to 1 for these use cases if you want a quicker reaction to your testing of creating transport request, transport of copies and triggering the Deploy in the Features.
So, for these testing landscape I need to run /SDF/ALM_SETUP for S4H:000 and S4H:100.
In S4H:000 I need to active use cases:
Then in S4H:100 I need to active use case:
In S4H:000 client, this is the sequence of steps and results when you active the indicated use cases:
Job /SDF/CALM_CDM_DIAGNOSTICS is executed for the first time and get status Released with a Daily frequency. This job should be released and executed once per day and system.
Please check this job log as a 403 Forbidden message will mean that the SAP Cloud ALM API instance is missing the JSON code with the CDM scopes (and thus authorizations) required to use SAP Cloud ALM Deployment scenario.
Job /SDF/CALM_CDM_DIAGNOSTICS pushes data to SAP Cloud ALM about the available capabilities in the managed system by checking their ST-PI level and the installed notes. If you miss any option at Feature level like the Copy or Deploy links check here.
The next run of job CALM Scheduler CALM_CONNECT, it is detecting the activated use cases, you will see this in the job log:
Start task for usecase: CALM_CDM_TMS_LNDSCP
Start task for usecase: CALM_CDM_TMS_IMPORT
Start task for usecase: CALM_CDM_TMS
CALM Scheduler CALM_CONNECT run every 1 minute, but only run tasks CALM_CDM_TMS_* every two minutes due to seconds rounded I guess.
In S4H:100 client, this is the sequence of steps and results when you run /SDF/ALM_SETUP:
I get these jobs in client 100:
Now I activate use case Transports: Create & Export (client-specific) 1
Next run of job CALM Scheduler CALM_CONNECT in client 100 detects these new use case:
Scheduler for Destination :CALM_CONNECT
Start task for usecase:CALM_CDM_TMS_CLI_DEP
This triggers the execution of job /SDF/CALM_CDM_TR_PROC_CL_DEP-100, also every two minutes.
Even if there is not any pending creation/release transport request/transport of copies trigger from SAP Cloud ALM this job executes.
Example of job /SDF/CALM_CDM_TR_PROC_CL_DEP-100 logs:
28.02.2024 14:47:07 Job started
28.02.2024 14:47:07 Step 001 started (program /SDF/CALM_CDM_TSK_PROCESS, variant &0000000144893, user ID I020554)
28.02.2024 14:47:07 Program /SDF/CALM_CDM_TSK_PROCESS started with destination CALM_CONNECT
28.02.2024 14:47:07 Call post request to URL: 'https://eu10.alm.cloud.sap/api/featuresService/v1/ odata/v4/FeatureService/readTransportsForProcessin
28.02.2024 14:47:08 Post request returned with status 200
28.02.2024 14:47:08 Creating 0 transports for destination CALM_CONNECT
28.02.2024 14:47:08 Releasing 0 transports for destination CALM_CONNECT
28.02.2024 14:47:08 Creating 0 transports of copy for destination CALM_CONNECT
28.02.2024 14:47:08 Program /SDF/CALM_CDM_TSK_PROCESS ended
28.02.2024 14:47:08 Job finished
However, only when there is a pending transport request import action job /SDF/CALM_CDM_IMPORT_TRANSPORTS is executed.
In case of import issues, you can have a look into the job log. Sometimes a component version mismatch is detected, and this would block the import of all transports assigned to Features if the mismatch situation is not resolved manually at TMS level.
Note: In case several Features are deployed together, all the transports assigned will be imported as import subset. If one transport request of the subset leads to a component mismatch situation the import of all transports is blocked.
In the SAP Cloud ALM for Implementation - Expert Portal please check the demo DEMO: Part 1 - Create Project and Select Scope to see how to create a project and assign a scope.
Another documentation to create a project can be found in TechEd 2023 HANDS-ON SESSION that contains the material for the SAP TechEd 2023 session: DT165 - Your Ultimate End-to-End Implementation Experience with SAP Cloud ALM.
Exercise 1: Create project & maintain project timelines
This is the project I created in the SAP Cloud ALM:
Regarding the Timeboxes I need to address you to the SAP Help Portal Project Planning with Timeboxes and to this blog Using Timeboxes with SAP Cloud ALM
Deployment Landscape tab: Assign a Deployment plan
A Deployment plan is a predefined set of releases and a predefined set of systems groups.
Ensure that the Product is the one that corresponds to the systems you assigned in the system group under the different roles.
In the System group you should include the system:clients of the transport track that you want to manage from SAP Cloud ALM Deployment.
The system group is a representation of the real landscape meaning that the system:client where the transport request is going to be created, source system, can only be under the Development column.
The system where the users are working is the production system and usually is the last one in the transport track.
Any system that is between the source system and the production system is called target system and it should go under the Quality and Pre-production columns.
If you have more target systems, you can include them under Quality Assurance column too.
Note: Ensure that you selected the correct Product, see this in Landscape Management tile, if you don´t select the correct product your will not see the system:clients that you connected to SAP Cloud ALM by running /SDF/ALM_SETUP in them.
Note: If you selected the correct product and you don´t see the expected clients you can add manually in the Landscape Management tile where at least you need to see the system and any client like 000.
Now we are ready to get create our first Feature, you can create it without any relation with a Requirement or you can create it as expected as result of the gaps, required modifications detected during the Fit-to- Standard workshops to the standard delivered process for example, see this perfectly explained in DEMO: Part 2 - Conduct Fit-to-Standard Workshops
To break down Requirement, that is the business need, to smaller work packages managed by the different development teams, we can create user stories for the Requirement, and create sub-tasks for specific developers, DEMO: Part 3- Create and Plan User Stories .
From Requirements we can create Features.
To test how to work with the Features you can directly create a Feature from the tile Features.
Please have a look to DEMO: Part 4 – Create Feature, Assign Transports and Deploy to QAS 3M43S
Select the project and click on Create.
Add all the required information and click on Save and Close, that gets the Feature in status Display.
You can find the whole information for Features in the SAP Help portal Feature.
In Status Flow for Features you will find the different Feature statuses and the possible workflow from on status to the other:
In June 2024, Successfully Tested status was introduced.
Furthermore, you will see what can be done with the transport request in each status and who can do what:
From document SAP Cloud ALM - Change and Deployment Management Overview
Being in Display mode you can Start the Implementation
Being in Display mode you can Create Transport requests, this will trigger to the TMS of the development system:client the command to create the transport request.
From a Feature you can create as many customizing and workbench transport request as you need.
Enter the user to which you want to assign the transport request and task, this user is the SU01 user in the development system:client where the transport request is going to be created.
Note: if you don´t enter any name under the owner, or the entered user does not exist, the transport request and task will be created with the user that is running the step of the job that creates the transport request, job /SDF/CALM_CDM_TR_PROC_CL_DEP-100 in our example, that is the user that you maintained as Background user of section 3. Enter background user and register system when running /SDF/ALM_SETUP initially in S4H:100.
Pay attention to the Export Tenant and Target as they need to match with your reality that is the TMS transport track defined:
Creation is pending for a time.
The one triggering the creation of the transport request in the source system:client is job /SDF/CALM_CDM_TR_PROC_CL_DEP-100 running in client 100 of S4H system.
See the same information in the managed system S4H:100 in /nSLG1
Object /SDF/CALM
Subobject BUILD_CDM
The user indicated as the owner of the transport request should perform the changes and stores them in the transport request, when the changes are complete the developer release the task of the transport request. Now is when we can trigger the transport of copies creation or the release of the transport request directly.
For the customizing request we can add an entry in SM30 T005A for example, save the change to transport request S4HK900114 and then release the task for transport request:
Let me go ahead with this customizing transport request to show you how the TOC is created and imported and later we will come back to the changes into the workbench request S4HK9*112.
Save the change in the customizing transport request S4HK9*114 and then release the task *115, this is a mandatory manual task!
I go to create now a Transport of copies by clicking in the Copy link of the Feature.
The recommendation is to create the transport of copies that will be released and imported automatically into the first target system where the tester can make a first unit test.
If the tester is ok with the changes the transport request can be released clicking in the Release link of the Feature.
When creating a transport of copies, you can select for which specific transport request you want to do this action:
Transport of copies is created; you can see this in the same job /SDF/CALM_CDM_TR_PROC_CL_DEP-100 as before like for the TR creation.
And the import is triggered automatically to S4H:200 by job /SDF/CALM_CDM_IMPORT_TRANSPORTS running in client 000.
This import information is displayed in job /SDF/CALM_CDM_IMPORT_TRANSPORTS, this job is only executed when there is a pending import action triggered from SAP Cloud ALM.
Then this job triggers to the TMS the tp import action.
As you can see my import job has an error that needs to be fixed this time manually before the created TOC *122 can be imported.
The error with the “Requests do not match the component version of the target system” is the TMS component version check error XT 216, that was given when trying to import TR S4HK*37 that contains a SAP Note that was implemented when the S4H system has a different version for ST-PI, so I needed to import it manually at TMS level with the option Ignore Invalid Component Version.
These are the different Import options- umodes:
Note: I could have set TMS parameter SP_TRANS_SYNC to OFF for S4H system, see KBA 1742547 - Information about component version check in TMS and then the CALM import job had been executed correctly.
For the second transport request S4HK*52 I imported also manually at TMS level, but I could have left it, the import job had imported it after importing manually the TR giving the error with the component mismatch that was blocking the import.
So, after unblocking the import our TOC S4HK*122 got imported correctly.
You will see the same information in SLG1, but remember, in the client 000 of the system where the import is triggered.
Let come back to the Feature to see that now the icon on the left of the TR is green and you can see the TOC number:
Then the tester can see that this entry is imported into S4H:200.
And then we are ready to release the transport request.
If tester is not ok with the changes imported into the first target system:client developer could add a new task to the same transport request and remake the changes in this new task.
Transport request will be released only when you know that the changes are the expected ones.
When triggering the release, you will trigger the release of all the transport requests created/assigned from/to this feature, no option to release transport requests separately if they are part of the Feature. Click on the Release link:
At release time the empty TRs are deleted, as they are empty. So, as our current workbench transport request S4K9*112 is empty it would be deleted when triggering te release.
You can see that the empty TR is deleted and this information is shown in the History of the document:
Transport request was empty and is therefore deleted.
Let me go to create a new workbench transport request for the same Feature to see that in this demo landscape we cannot work with workbench request as we get an error at import, because workbench objects are client independent, but let make an example to show you how to work with the repair functionality.
Let create a dummy program in S4H:100 to save into this transport request:
You have created a package for client 100 link to the transport layer used in your consolidation route.
And then go to the transport request to release the task of the TR S4HK9*123.
Now we are ready to release the TR and this will work correctly.
In Edit Mode you can see the option to Assign already created transport requests for this source system:client independently of their transport request release/import status or you can unassign a transport request from a Feature by clicking in the X at the end of the transport request line:
Now is time to trigger the import of the transport requests of a Feature in the Quality system by clicking in the Deploy button.
Currently we have for the import into quality systems only the option to trigger the Deploy at Feature level, and as for the release action you cannot select or unselect any transport requests, SAP Cloud ALM can only trigger the tp import of all transport request assigned to the Feature.
For the import into production there is an option to select all Feature is status Ready for Production and click on Deploy to Production all transport requests included in the selected Features.
Note: According to the SAP Road Map Explorer in Q1 2025 we will have a Deployment scheduler for transports that allow us to trigger the import
“Scheduling one-time or recurring deployments of transports based on following selection criteria:
Project (single select)
Coming back to our Feature, click on Deploy to trigger the import into the first quality system S4H:200:
Check in client 000 for the *CALM*IMPORT* job:
The customizing transport request was imported correctly into S4H:200.
However, for the workbench transport request we get status Deployment failed in S4H:200, with the button Set Status to Repaired available.
This is the error in the WB transport request: “R3TRPROGZDC_FULLSEQUENCE original object cannot be replaced”- CORRECT!!
At this point of time in our case, the import is not done, but the import process is not getting blocked.
As soon as a transport request get status “Deployment failed” with the button Set Status to Repaired, SAP Cloud ALM is not going to trigger again the import of this transport request.
See that I released and trigger the import for an old TR created in another Feature and in the import job I could see that we only try to import this new TR, we don´t retry the import of the failed TR S4HK9*123 as it is set to “Deployment failed”.
So, this means that we have a transport request in the import buffer of the target system:client with a RC 8 during the import, and now it is on your hands decide what to do with this TR.
For this particular case we could trigger a manual import from TMS selecting the option Overwrite Originals this time:
Then as the import issue is fixed manually the Set status to repair button will disappear and the status will change to Deployed in S4H~200.
June 2024, SAP Note 3480914 - Client-specific import handling for Transport of Copy and Workbench Transport Request was delivered to avoid the import error of workbench WB transport requests into a different client of the same system, so now the creation of TOC that means its import will not fail with the Overwrite Originals error, and also not the import of the WB transport request into S4H:200 and 300 clients.
However I leave the example just to explain how the import error should be fixed manually at TMS level.
However, there will be situations where it is not possible to fix the import for an individual transport request, in this case what SAP Cloud ALM offers is to “Set status to repair” if you want to continue working with the other transport requests of this Feature.
I move the Feature to status In testing by clicking in Handover to Test.
Please see the demos in
DEMO: Part 5 – Test Preparation
DEMO: Part 6 – Test Execution and Defect Management
When being in the In Testing phase the tester can click on Approve for Production and get the document in status Ready for Production.
But when clicking in Deploy to import the transport requests into the production system S4H:300 I get this error:
Please repair the transport conflicts in your managed system first. Afterwards, set the transport status to “Repaired”.
So, take your manual actions at TMS level and set the status to Repaired in the Feature as from SAP Cloud ALM we are not going to trigger the import of the TR into this S4H:200 any more but YES into S4H:300 as the transport request is in the import buffer of S4H:300.
I click on Set Status to Repaired.
Now I can trigger the Deploy into target tenant S4H:300 production system, only TR S4HK*114 is shown in the Deploy popup.
Please check this video: DEMO: Part 7 - Deploy to Production
See that we trigger the import of the WB TR not imported correctly into S4H:200, now in S4H:300 and of course it is failing too!
When clicking in the Confirm Deployment the action is showing message:
Switching feature status to "Deployed" isn’t possible. Please make sure that all assigned transports are successfully deployed to or repaired in the respective target system.
So, I repaired again the TR for S4H:300 and move the document to status Deployed:
In the ULOG file you will see an entry like this one:
APServiceS4H 2023... RFC: tp IMPORT S4HK900123 S4H clires300 pf=\\...\sapmnt\trans\bin\TP_DOMAIN_S4H.PFL FEEDBACK AFTERIMP -Dimpmon_mode=DETAILED -DSYSTEM_PF=
See below how to trigger the import into production for several Features by selecting all the Features that are in status Ready for Production and clicking in Deploy to Production button:
In the ULOG file you will see an entry like this one:
APServiceS4H 2023... RFC: tp IMPORT SUBSET S4H pf=\\...\sapmnt\trans\bin\TP_DOMAIN_S4H.PFL FEEDBACK AFTERIMP -Dimpmon_mode=DETAILED -DSYSTEM_PF=\\...\sapm
SUBSET means in detail: S4HK900042 300 S4HK900064 ..... 300 (pid=14044)
as the CALM tenant is triggering a single tp import subset command to the TMS, where in the subset you will have all the transport requests included in the selected Features.
You can navigate to the transport organizer by selecting the transport id link, information in Navigate to the Transport Organizer for CTS-managed Transports via Transport ID
Prerequisites
Before you can start using the navigation to the transport organizer for CTS-managed transports by using the transport id, make sure that you have followed all steps in the following documentation: Configuration of the Transport Organizer Web UI.
From SAP S/4HANA Cloud Private Edition and On-Premise Systems you can read:
If you have transport requests released pointing to a target system, without a client, as CTC was not set to 1, and then you add CTC=1 and rebuild your transport track using clients, in the Feature for the transport request the target tenant will be empty and the Deploy could not be triggered.
Unfortunately, the target tenant for the transport requests released before the TMS configuration change cannot be derived on SAP Cloud ALM end.
Here the only option is to export the list of all features from the Features Overview. In the Transports column you can select all transports and filter for them in the target system import queue.
For the old ones already released you should import through STMS.
It is only recommended to change the TMS configuration in case the Features are already deployed, or transports are still modifiable.
If you want to implement landscape changes, please note the following information:
Adding new systems to a track is supported as long as no consolidation routes are changed. Mind that you need to adjust the transport buffers manually.
If you need to perform unsupported changes of the transport configuration in the Transport Management System (TMS), make sure that all open features and transports are completed and deployed to the production system. Therefore, the transport buffers should be empty.
A summary about how to setup and troubleshoot the transport checks can be found in KBA 3554749 - Transport Checks.
For the Features tile you can open the Feature Analytics:
Watch DEMO: Part 4 – Create Feature, Assign Transports and Deploy to QAS for more details
As you can read in What's New for SAP Cloud ALM in Sep 18, 2024 it was delivered the app Transport Analysis that is located within the Cross-Project Overview tile. With this app you will be able to find all the system transports known by your SAP Cloud ALM tenant. More information in Transport Analysis.
There you can search for transports and check which feature they are assigned to.
The Status which is shown in the Transport Analysis always refers to the tenant/client which is shown in the column 'Current tenant'. There is a Help/Info-Icon next to the column header which explains this too.
Transports without Target Tenant should mean, that the transport has reached the final tenant (e.g. production). This should be consistent to what is shown in the feature.
I did this testing with a user having these roles
See what each role can achieve in Role Collections and in Roles and Authorizations.
There are two specific roles for Change & Deployment Management:
These role templates can be used to create your own custom role collections on the SAP BTP subaccount.
But these roles can only do exactly these actions, not other actions, so add always role Project Lead role as indicated in Status Flow for Features
From document SAP Cloud ALM - Change and Deployment Management Overview you can find information:
From the SAP CALM application, you can get these self-explanatory error messages:
May 2024: Connection Setup Checks for Deployment Management for Managed Systems On-Premise ABAP systems
With the corrections included in SAP Note 3426408 - Cloud ALM: Connection Setup Checks for Deployment Management you can troubleshoot problems with Managed ABAP systems connected to SAP Cloud ALM.
Checks have been implemented via transaction /sdf/alm_diagnostic, or via report /SDF/CALM_CDM_CONN_DIAGNOSTIC and should be used as the first step when having issues with the Managed ABAP system.
As you can see there are various checks and the solutions can be found in the Solutions for Errors in the Managed System Setup Check.
Firstly, check that for this landscape DEV:100->QUA:200-> PRD: 300, domain controller PRD you have done the setup explained in section 3.1.5. Configure the PUSH Data Provider.
What is really important is that you check the specific use cases are activated according to the role of each system:client in the transport track.
This means that if you logon to:
PRD:000, you will see in se16: /SDF/CALM_SCHED entries for use cases CALM_CDM_TMS_LNDSCP and CALM_CDM_TMS_IMPORT
DEV:000, se16: /SDF/CALM_SCHED entry CALM_CDM_TMS
DEV:100, se16: /SDF/CALM_SCHED entry CALM_CDM_TMS_CLI_DEP
QUA:000, se16: /SDF/CALM_SCHED entry CALM_CDM_TMS_IMPORT
For our test scenario you will see in
Jobs:
Example of the CALM Scheduler Destination logs running in client 000:
Example of the CALM Scheduler Destination logs running in client 100:
Entries in S4H:000 se16 /SDF/CALM_SCHED
Entries in S4H:100 se16 /SDF/CALM_SCHED
Job /SDF/CALM_CDM_DIAGNOSTICS is released and running daily in each system:client 000:
Job /SDF/CALM_CDM_IMPORT_TRANSPORTS is only running on demand, when a Deploy is triggered from a Feature.
When the import queue is stuck like in our example you will see it running periodically after the periodic execution of job CALM Scheduler Destination name is running in client 000:
As soon as we resolved the error with the component version mismatch, the *CALM*IMPORT* job started to execute only on demand.
If you see 403 in the import job or in /SDF/CALM_CDM_DIAGNOSTICS job this will mean that managed system contacted with SAP Cloud ALM application but in the credentials, service key/binding, generated for the SAP Cloud ALM API service instance you did not enter the required scopes (and thus authorizations) required to use SAP Cloud ALM Deployment scenario.
HTML codes: 403 Forbidden, 200 OK, 204 No Content
The scopes can be checked by running report /SDF/CALM_CDM_CONN_DIAGNOSTIC Connection Check Report.
Select the already created Cloud ALM Destination (find this value in transaction /n/SDF/ALM_SETUP -> Target ALM Description).
In the report result, check the Token Scopes section and ensure the entries for imp-cdm-feature-display-ui and imp-cdm-feature-manage-ui are shown:
Another option is to check this missing authorizations is to run report /SDF/CALM_CDM_DIAGNOSTICS and check in SLG1 the exit of this execution:
'https://<domain>.alm.cloud.sap/api/featuresService/v1/odata/v4/FeatureService/handleABAPSystemDiagnostic’
Post request returned with status 403
Post request failed with status 403
As you can read in Help Portal section Enabling SAP Cloud ALM API in Cloud Foundry if you are using a service key for the instance of the SAP Cloud ALM API service, Cloud Foundry environment, you need to create a new instance using this json file:
{
"xs-security": {
"xsappname": "<your-instance-name>",
"authorities": [
"$XSMASTERAPPNAME.imp-cdm-feature-display-ui",
"$XSMASTERAPPNAME.imp-cdm-feature-manage-ui"
]
}
}
Replace <your-instance-name> with your instance name.
Then create a service key.
In the case that you have a SAP BTP Global account SAP Cloud ALM without Cloud Foundry environment, then use a binding for the instance of the SAP Cloud ALM API service, as indicated in Enabling SAP Cloud ALM API you need to create a new instance using this other json file:
{
"xs-security": {
"xsappname": "<your-instance-name>",
"authorities": [
"$XSMASTERAPPNAME.imp-cdm-feature-display-ui",
"$XSMASTERAPPNAME.imp-cdm-feature-manage-ui"
],
"oauth2-configuration": {
"credential-types": [
"binding-secret"
]
}
}
}
Replace <your-instance-name> with your instance name.
Then create the binding.
You again to follow the indications in section 3.1.5.3. Maintain HTTP Destination as you need to update the HTTP Destination by entering the new service key/binding credentials created for this new created instance.
Note: I would suggest firstly deregister the jobs in /SDF/ALM_SETUP, delete the destination and then go again to create a destination by entering the new service key/binding. Do these actions in the systems:clients where you need to activate a Deployment use cases, and exactly in this sequence.
Source system:client in the system group should be under the Development column, target systems:client are under Quality and Preproduction colunms, and the production system:client is under the Production column
In case of error User * has no authorization for tp command * - TP 607 in the import job check that the user running the step of the job has the authorizations indicated in 3.1.3. Required Authorizations.
If you miss transport request in the Feature Assign result list, please implement SAP Note 3409285 - CALM: Missing Transports in change and deploy management (CDM) in the development system.
Then in development system client 000 you need to run report "/SDF/CALM_CDM_SET_TR_SYNCHTIME" and input a date in the "pa_date" field that corresponds to date preceding the occurrence of missing transports, then all transports on the development system changed after the set date will be read again and sent to SAP Cloud ALM.
The entered "pa_date" will change the table /SDF/CALM_SCHED for the use case CALM_CDM_TMS, field SYNC_TIMESTAMP. You need to have activated use case Feature Deployment: Manage Transports CALM_CDM_TMS previously in source system client 000.
So the next time job CALM Scheduler, with task CALM_CDM_TMS, runs in 000 the information will be send to SAP Cloud ALM and the missing TRs will be found in the Assign popup, or you can call report /SDF/CALM_CDM_DIAGNOSTICS directly to get the modified transport requests sent to SAP Cloud ALM
In SLG1 you will see logs like:
Start Transport synchronisation from client: 000, to CALM destination: CALM_CONNECT.....
Diagnostics Job already scheduled. Not scheduling again
Read transports from date 01.01.2024 10:45:39
Number transports found XX
Uploading 'XX' transport requests
Call post request to URL: 'https://eu10.alm.cloud.sap/api/featuresService/v1/ odata/v4/FeatureService/handleTransportsFromDevSys
Post request returned with status 204
Uploaded 123 transport requests to CALM
Set synchronisation timestamp to: 20.02.2024 10:46:56
Check the logs related to the Deployment scenario in the managed systems in SLG1
Please watch ALM Summit session: Fire up your transition journey with the SAP Readiness Check for SAP Cloud ALM Video Min 16, PDF slides 10-15, where you will see the new dashboard “Change Request Management Insights” in the SAP Readiness Check for SAP Cloud ALM just delivered in November 2024.
This dashboard will help you: to know the capabilities being used in your SolMan ChaRM/Focused Build cycles that are already available or in the roadmap in SAP Cloud ALM Change and Deployment Management and decide which landscapes managed by Solman can be managed by SAP Cloud ALM initially.
Watch also session Learn how SAP Cloud ALM supports your change control management process Video Min 29, PDF slides 26-28.
Please implement the latest version of SAP Note 3236443 to enable the data collection.
Note: There will not be any ChaRM/Focused Build object that will be transferred to SAP Cloud ALM.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
7 | |
7 | |
7 | |
6 | |
6 | |
5 | |
5 | |
5 | |
5 | |
5 |