ALM Coffee Party VIII – Transports with Cloud ALM
The Feathered Feature
Is it the dawn of SAP Solution Manager or is it the rise of SAP Cloud ALM as this lone feathered Feature soars towards Production? It is both.
Since we are in a phase of transition, I will focus here on the question of how to use Features to bring transport requests of an OnPremise ABAP system from Development to Production.
This use case is also attractive for SAP customers who have previously given ChaRM and/or Focused Build a wide berth.
Here I focus on the so-called user experience and governance when using Features to handle OnPremise transports.
To set up a sandbox system for testing, I would like to refer you to the first three chapters of the wonderful blog by the famous Dolores: First steps to work with SAP Cloud ALM Deployment scenario for SAP ABAP systems (7.40 or higher). The creation and workflow of Features is also described in detail in chapter 4 and does not need to be repeated here.
Schau’n mer mal
Let’s then have a look at this new Feature.
We will use our existing knowledge to contextualize these new Features. By the way, I’m talking about the state of the second half of October 2024 – this needs to be emphasized, as new functions are released every two weeks.
As we all know, SAP has a gigantic department that is constantly coming up with new names for one and the same function. Here, too, it was very successful: even at first glance, a Feature seems to be just a nice new name – who wants bugs – for the good old Change Document. There is also no longer any talk of transports in the Transport Assignment Block, but the latest buzzword is now “Deployment Orchestration of Transport Containers”.
Wzhkevin, CC BY-SA 4.0, via Wikimedia Commons
At second glance, the Feature reminds us of the good old TMS Workflow.
Creating or referencing
As of today, Features can only be created from the “Features Overview” or from a “Requirement”; in addition, you can reference exactly one Feature from a “User Story”, and only here.
In a Feature, you can not only create Transport Requests, but also User Stories and Project Tasks.
It was also possible to create Tasks (Transaction Type “1003”) as successor documents in ChaRM Change Documents.
I demonstrated to colleagues how this could be used to involve additional team members in a change process instead of contacting them by e-mail, which would establish a holistic concept of the Change Document, with which one could achieve very good documentation (traceability), but this was never accepted, it stayed with the informal e-mails.
I therefore fear that the option to create follow-up Tasks will also be left unused in the Feature.
Error correction during testing
What really surprises me is that there is still no direct link between a test defect (technically a task type) and a Feature. You have to take a detour here.
First you have to create the Feature:
Only then can you add the URL of the new Feature in the Test Defect as a reference using copy&paste:
If you want to document in the Feature for which Defect you are working, you have to repeat this procedure for the other direction (URL of the Defect as a reference in the Feature), because there is no automation here yet:
I already anticipate that this cumbersome manual linking will not meet with much acceptance.
However, there is hope for Q2 2025:
Schau’n mer mal! Dann sehn mer scho!
Transports
In contrast to ChaRM and more in line with Focused Build, Features are always linked to Cloud ALM Projects.
These Projects reference a “Deployment Plan”, which is similar to a ChaRM Change Control Landscape (CCL), and just like the latter, this “Landscape” contains one or more “System Groups”. Each “System Group” in turn contains a Track, which was previously called a Logical System Component. This means that, as before, several tracks can be used with one Change, oh, sorry, Feature.
In our examples, we use a Project called “Maintenance Project”, which uses the creatively named Plan “Deployment Plan 2024”, which in turn only knows one System Group, namely the equally originally named “BSS Maintenance”.
Our demo landscape on the OnPremise ABAP system has two tracks, a four-system track for projects (BSS.801 🡺 803 🡺 804 🡺 805) and a three-system track for maintenance (BSS.811 🡺 813 🡺 805).
The maintenance Project is also defined accordingly in Cloud ALM:
The counterpart would be “BSS Project”, but is not used in our examples.
We try out the creation of a transport request
Our screenplay: We don’t want to draw anyone’s attention to our developments in order to avoid discussions, so we leave our Feature in the “In Specification” status and create transports straight away, because it is already possible in this initial status! To create transports, we need the powerful “Project Lead” role, which of course that is why it was granted to us.
It is strange that – in contrast to ChaRM – you can only create transports if the Feature is not in change mode (see the active Edit button), and this Create button is in the Feature header, as if a transport were an entity on the same level as User Stories etc.
However, if you want to add an existing transport to the Feature, you must switch to Edit mode instead and then navigate to the “Transports” section.
You get used to it.
BSS~813 would actually be the right choice for the “Target” of the “Maintenace Project”, but its “Deployment Plan” is ignored and the extraneous consolidation system BSS.803 is offered first.
All right. I’ll pretend I’m as scatterbrained as I actually am when I’m in a hurry.
I overlook the fact that the wrong consolidation system is offered for the maintenance development system BSS.811 and wave the transport creation through.
I also overlooked the fact that there is an “Owner” field and left it empty. This input field was missing a value help for the possible User IDs from the development system anyway.
As only a flag for a transport creation is created in Cloud ALM, we now have to wait until the batch jobs finally start on the BSS.811 system and fetch the task from Cloud ALM, execute it and return the result. This means patiently pressing the refresh button repeatedly:
Soon we will have made it:
We log into the maintenance development system and initially do not find the transports in transaction SE09, because we have left the optional field “Owner” empty and thus the owner of the batch job has been used, in our case “BG_CALM”:
Not a big problem if we have the authorization in the development system to change the owner of a transport.
But if we want to work with the transports we have just created, we immediately encounter problems:
The transport BSSK901892 actually intended for development is not offered for selection, as it unfortunately has the wrong destination.
Despite existing pitfalls to be aware of, creating a transport from a Feature has the advantage that both the descriptive and the technical Feature ID are documented:
It is better to add transports
Because of this error-proneness, it is better in my opinion to create a new transport from the respective application during development and/or customizing – as in R/3 times:
You also do not need the same extensive authorizations as for creating transports (see above).
The advantage is that the Change and Transport System (CTS) automatically sets all values (Owner, Target) correctly:
The high-frequency synchronization job sends this transport data to Cloud ALM so that it will soon be visible. This can be checked with the “Transport Analysis” app, for example:
If the new transport is known in Cloud ALM, we can set the Feature to change mode and “Assign” the new transport:
Fortunately, the Assign dialog only offers transports that have the Source Tenant BSS~811.
The only disadvantage of this procedure is that the technical Feature ID is not documented as an attribute of the transport. But this has no consequences.
Difficult coexistence
Since the early days of ChaRM, we have had to turn on the CTS Project constraint when setting it up correctly so that the project switches for transport actions force only the ChaRM (or Focused Build) to be able to create, release and import transports.
However, Cloud ALM has been simplified here and therefore no longer knows any CTS projects. So you should use transaction SE03 🡺 “Display/Change Request Attributes” to remove again this obligation to enter the SAP_CTS_PROJECTS.
There is no “Selective Data Transfer” to Cloud ALM for ChaRM and Focused Build. You have to work through and finally complete their cycles and only create anything new by Feature in the meantime.
If you wanted to maintain the strict governance in ChaRM in this phase of coexistence, you would have to revoke the authorization to release transports (authorization object S_TRANSPRT, Activity 43) from all users in the development system in order to gently force the switch to cloud ALM Features, but who can do that on an established development system?
Ignoring the CTS Projects has one advantage: You can also add transports that have already been released to a Feature:
Testing with Transport of Copies (ToC)
Unlike the Normal Change of ChaRM (and Focused Build), testing in the consolidation system with ToCs is voluntary. You must explicitly press the button and select the sources for the ToCs:
Unfortunately, there is no visible feedback that you have requested the creation of ToCs; you can only see this when you open the history:
The ToCs only become visible once the batch job has completed its work in the ABAP system.
We note that the friendly deletion of empty transport tasks as in ChaRM is now missing again:
Status dependency of transport activities
Depending on the status of the Feature, the following transport-related activities can be carried out in a Feature:
As you can see, everything is permitted not only in the “In Implementation” status, but also in the “In Testing” status. This is completely different from a ChaRM Change Document, where there is a strict separation between development and testing. The reason for this high degree of freedom is not clear to me.
Let’s assume that the tester has successfully tested the function in the ABAP QA system and then goes into the lunch break on the high of the success he has experienced. He wants to set the new status “Successfully Tested” after the break together with a cup of coffee.
In the meantime, the developer remembers that she had forgotten something; she quickly creates a transport, records the change and pushes the change into the QA system.
How is it ensured that the tester tests this subsequent change before setting the status?
I also wonder in which use case a tester confirms the successful test, although the transports can still be changed:
Ah, questions over questions….
Production
Here too, the Feature only allows transports to be released when it is not in change mode:
In contrast to the creation of ToCs, this action is immediately visible in the Feature.
The import into the subsequent systems is now called “Deployment”. Cloud ALM behaves very differently to ChaRM.
If you have a mixture of three- and four-system landscapes, as in the example, you have to get used to the fact that Cloud ALM calculates backwards from the Production system, which means that you can only import the transport of the three-system landscape into the Consolidation system (here BSS.813) when the transports in the four-system landscape have reached the Pre-Production system (here BSS.804), because both systems (BSS.804 and BSS.813) deliver to Production:
I think the final mass import from the Overview page is very nicely realized if you filter for the appropriate status:
This has the advantage that all transports selected here are imported into the production system at the same time with a tp IMPORT SUBSET.
I also find the analytical “Feature Traceability” very appealing:
The only fly in the ointment is the combination of the QA and PreProd systems in one icon:
Technical handling of CTS transports
As of today, creating and/or releasing and importing an OnPremise transport request from the Feature is asynchronous.
Only a type of flag is created in Cloud ALM. A high-frequency job runs in the connected ABAP system, which retrieves the tasks from the cloud system, executes them and uploads the result to the cloud.
If, for example, you want to trace this process in the event of an error, you must log in to the appropriate client (for export in the development client, for import in client 000) and use transaction SLG1 with a filter for the batch process user to restrict the time period in question.
Here we are tracing the creation of the ToCs from before:
You cannot access these logs from within the Feature.
In conversations during the ALM Summit 2024 in Mannheim, I learned that a direct connection between the Features and the OnPremise ABAP system will be offered in future via the SAP Cloud Connector.
Summary
ChaRM and Focused Build have matured over twenty years to become the lighthouse application of the Solution Manager and of course Cloud ALM needs time to be able to compete with this giant:
The SAP team is working flat out to shoot up to ChaRM/FB, here I offer a short summary with an outlook:
- Features can be used to create CTS transports and move them through the landscape; if you have a simple system landscape, you can already easily control ABAP transports with Features today
- Cloud ALM is very easy to set up and the Features are seamlessly integrated into the Cloud ALM Implementation scenario
- The look and feel of the UI is outstanding, the performance is amazingly good
- The scenario “Customizing/code correction due to incorrect test result” is not directly supported as of today, according to the roadmap it will not come until Q2 2025, but there is a somewhat cumbersome detour
- Cloud ALM does not know CTS Projects, so coexistence with ChaRM/Focused Build in a transport landscape is not recommended
- The creation of transports from the Feature allows too much freedom; it is better to create the required transports directly in the ABAP system and then assign them to the Feature.
- The great freedom in status dependency and in defining the target systems is very reminiscent of the old TMS workflow
- However, if you need a strict set of transport rules, you should wait;
time is cyclical: just as ChaRM and then Focused Build emerged from the shortcomings of the TMW workflow twenty years ago, this cycle is now repeating itself – albeit with a much faster rotation – because SAP is already planning the leap to Focused Build-like checks; however, the planning is only partially fixed in the Roadmap: 
An addition to ITSM
Cloud ALM is explicitly not intended to be an ITSM tool.
If, as I mentioned at the beginning, you have never used ChaRM or Focused Build before, but now finally want to introduce an audit-proof Change Management system that covers the entire process from the incident to the productive transport, then you might want to follow the path taken by the City Administration of Bern (CH).
With the help of our alm360 Hub, an external ITSM tool was linked to Cloud ALM, thus ensuring traceability throughout the entire process:
