ALM Coffee Party IX: Features with new features – Downgrade Protection

Introduction

It is a noble task to replace the huge SAP Solution Manager, affectionately known as SolMan, which has grown over more than twenty years and is unique in its broad functionality, with SAP Cloud ALM.

ChaRM (Change Request Management) is a lighthouse scenario for SolMan. As a ChaRM expert, I am of course observing the development of the analog cloud ALM “features”, I have described a first tour here. And as announced in the roadmap quoted at the end, two transport checks have now been delivered with 2025/Q1, namely DGP (Downgrade Protection) and the cross-reference check.

I have illustrated here how valuable the DGP is if the industrial paradigm of the ABAP CTS (Change and Transport System) cannot be followed. We therefore want to focus on this new cloud ALM functionality.

I will compare the Cloud DGP with the DGP in the Solution Manager at appropriate points.

Here is a brief comparison of the checks in Cloud ALM and SolMan:

SAP Solution Manager	Cloud ALM
CSOL Check	./.
Release Check	./.
Predecessor Check	Potential Downgrade
Imminent Check	Imminent Downgrade
./.	Intrinsic Downgrade

As you can see, the Cross System Object Lock (CSOL) checks are still missing. A new feature is the “Intrinsic Downgrade”, which fires if more than one transport is present in a feature, but one of these transports was manually placed in the wrong order outside of the feature (e.g. by a direct import in the STMS). More on this later.

The setup of these important checks is documented in detail in SAP Help and will therefore not be repeated here.

The implementation of the SAP Notes specified there as a prerequisite proved to be completely problem-free with the ST-PI Stand 740 SP28.

Einschränkungen

The SAP Help page quoted above mentions that the two new checks are only performed for transports that are waiting to be imported into the production system (here called production tenant) or have already been imported (?!). This is an important limitation, because it is known that the costs of error correction are lower if they are detected early (“10-rule of error costs“).

One of the joys of agile software development is that functions are only delivered bit by bit. That’s why I’m pinning all my hopes on the adverb I highlighted in green in the SAP Help text: “Transport checks are only possible for production systems. Pre-production and quality assurance systems are currently not supported.“. I therefore deduce that the PreProd system will soon also be able to benefit from these checks (actually, I am almost certain, because – I admit it – I simply asked the product manager).

A further restriction, namely that the productive system must be the last system of a transport route, could force a change to the existing transport landscape, as it is popular to set up a training system as a delivery by the productive system.

Finally, the restriction that the source system and target system should reside on different physical systems worries me a little, because I only have a single sandbox system with different clients to play with. We’ll see…. (Spoiler: it all worked anyway, thankfully!)

Outlook

Currently (early March 2025) these checks are only possible within one feature, but I can see in the roadmap that they will soon be possible for several features at the same time:

I am almost certain [again, I simply asked the product manager] that such a block check will also be possible as part of the fresh “Deployment” app Presumably it is hidden behind this mysterious roadmap announcement for Q1 2026.

Practice

As usual, we test on our sandbox system BSS with different clients:

First DGP test

We want to create a DGP collision within a feature. To do this, we create a feature with two customizing transports:

Now we are tickling the transports a little.

This new entry is recorded in transport BSSK901969 “6-60: RE DGP Check 1 – Two Transports: Older”:

We export this transport, which means that it can no longer be changed. Result:

Now we change the entry and record this change in the transport BSSK901967 “6-60: RE DGP Check 1 – Two Transports: Newer”:

Incidentally, no warning pop-up appears, as is usually the case when SolMan CSOL is active, informing the customizer in which other transports the same entry has already been recorded. We are excited to see what will come in Q4 2005 as the “Cross-system object lock foundation for retrofit”!

We export BSSK901967.

The import sequence for the QA system BSS.803 is correct:

As we are in a hurry, we import BSSK901967 directly into the STMS import queue – there are no longer any CTS project switches to prevent this! This also violates the import sequence of the subsequent systems!

Of course, you can trust that nobody will carry out such a manual intervention. But perhaps you should think carefully about whether you should use an authorization concept to severely restrict the possibility of starting imports directly in the STMS import queue.

We deploy the feature twice, it has reached the PreProd System BSS.804 and is waiting to be imported into the Prod System BSS.805:

The DGP trap is ready:

We execute the DGP check from the individual feature:

Tadaa!

If a person with fine motor skills clicks exactly on the number “2” (there are two table entries in the transports), a new window opens, which in my opinion provides information about the problems in a very successful way:

As expected, the “Intrinsic Downgrade” error is reported here.

Second DGP test

We want to create a DGP collision between two features. To do this, we create two features, each with a customizing transport:

As before, we record different changes with the same transport key in the two different transports with different contents.

Here is just one example of the first change.

I’ll skip the further changes now, they are almost analogous to the previous chapter and come to the crucial point that allows the DGP check, this time we use the beautiful “Transport Analysis” app:

The overtaker (transport BSSK901965) is ready:

We start the DGP check in both features almost simultaneously.

Unfortunately, neither this status nor the check result is displayed in the “Feature Overview”, nor in the “Transport Analysis”, nor in the otherwise very appealing “Feature Traceability”.

We have to select one of the two features and refresh the “Transport Checks” section with the “refresh” button until the job has finally started in the ABAP system and completed its work request:

The result is interesting. The feature with the overtaking transport does not indicate any problems. Actually, I would have expected it to show the “Potential Downgrade” error.

Only in the feature that could actually produce a downgrade does a red message exist, here are the crucial details:

But it is not as bad as the “Imminent Downgrade” long text says, because both transports have not yet been productively imported. We can still carry out the correct import by deploying the features individually.

So we start the deploy of the feature “RE DGP Check 2 – Older Transport” first, wait until the import is finished, and then start the deploy of the newer one.

This is what the entry in the PreProd System BSS.804 looked like:

Definitely a downgrade!

And this is what the entry in the production system BSS.805 looks like, thanks to our cautious behavior:

Of course, one wonders what was tested in the PreProd system, but that’s another story.

Rating

On the whole, the DGP Check works well. We wonder whether the omission of the error message “Potential Downgrade” in the feature “RE DGP Check 2 – Newer Transport” could be a bug.

The long wait for the results of the asynchronous call could reduce acceptance. I have not yet given up hope that my suggested improvement “Direct CTS Transport Handling by Feature via Cloud Connector” will finally be accepted.

Two SAP Solution Manager skills are still missing:

• The automatic system; the checks must be started voluntarily, so to speak, by the person responsible instead of being executed automatically when the status changes as in SolMan
• An import block that must first be released by an authorized person before the import is actually carried out.

Cross Reference Check

We were also able to test the Cross Reference Check on a customer system and it worked brilliantly. This check, also known as the RC=8 check, is worth its weight in gold!

In short, it resolves all objects of a workbench transport into their basic elements and performs a “dependency walk” for these elements so that it also determines the implicitly referenced elements.

The check then checks whether all these required elements are present in the target system and, if so, compares the versions. If there are gaps or discrepancies, it fires errors or warnings. For example, if I use transport A to import an include that references a table field whose addition was recorded in transport B, but which is still under development (oh, how often such clumsy architecture happens!), then this import crashes with a syntax error.

If I’m unlucky, it was one of those ZX extension includes in the Sales and Distribution that are called several times a second. In no time at all, thousands of short dumps pile up in the production system! I speak from experience here. A proactive check that threatens the mess before the fatal import can avert a career break.

How does it work?

As it is hardly possible to carry out the cross-reference check in a sandbox system, we will concentrate on the DGP check here.

The DGP was originally part of the CTS plug-in, which has been part of the Basis component since Netweaver Basis 7.40 SP10. However, it was controlled in SolMan, and the results of the checks were temporarily stored in /TMWFLOW/DGP_CHK and /TMWFLOW/DGP_CNF in SolMan, and the execution itself was logged in /TMWFLOW/DGP_ENT.

Now the DGP check is only carried out in the production system.

As analyzed in my blog quoted in the introduction, a batch job in the production system retrieves this DGP task from Cloud ALM and executes it in the /SDF/CALM_CDM_TR_SUB_CHECK report. It retrieves the transport history from the source system for this purpose. The result of the check (everything roger or list of conflicts) is sent to the Cloud ALM service ‘/api/transportCockpitService/v1/odata/v4/TransportCockpitService/handleCheckResult’, i.e. it is saved in Cloud ALM.

The question naturally arises as to what reorg options there are or will be in Cloud ALM, as cloud storage is expensive.

As an example, here are the logs from client 000 of a successful check run for a feature (the system user for the batch jobs is BG_CALM, and the RFC destination that is maintained in transaction /SDF/ALM_SETUP as “Target ALM Description” is specified as the “Transaction Code”)

The corresponding job logs (SM37) contain the same information.

One fly in the ointment: you are not told which features triggered the check, nor are you told which transports were checked.

If the check is triggered promptly from more than one feature, a separate batch report run is started for each feature:

Appendix

RFC connection

Just a small remark in passing. We had overlooked this little word in note 3447901 “Set Up Transport Check for Feature in SAP Cloud ALM Change and Deploy Management”:

Although the validation “Check use-cases” from transaction /SDF/ALM_SETUP gave the green light, the DGP check still terminated with an error:

As soon as you get it right, everything works: