ALM Kaffeekränzchen IX: ​Features mit neuen Features – Downgrade Protection 

Einleitung

Es ist eine hehre Aufgabe, den riesigen, in seiner breiten Funktionalität einmaligen, über mehr als zwanzig Jahren gewachsenen SAP Solution Manager, liebevoll SolMan genannt, mit SAP Cloud ALM zu ersetzen.

Ein Leuchtturm-Szenario des SolMans ist der ChaRM (Change Request Management). Als ChaRM-Experte beobachte ich natürlich das Werden der analogen Cloud ALM «Features», einen ersten Rundgang habe ich hier beschrieben . Und wie in der am Ende zitierten Roadmap angekündigt, sind jetzt mit 2025/Q1 zwei Transport-Checks, nämlich die DGP (Downgrade Protection) und der Cross-Reference-Check geliefert worden.

Wie wertvoll die DGP ist, falls man nicht dem industriellen Paradigma des ABAP CTS (Change and Transport System) Folge leisten kann, habe ich hier  verdeutlicht. Wir wollen uns daher auf diese neue Cloud ALM Funktionalität konzentrieren.

Ich werde dabei an passenden Stellen den Cloud DGP mit dem DGP im Solution Manager vergleichen.

Hier eine kurze Gegenüberstellung der Überprüfungen in Cloud ALM und SolMan:

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

Wie man sehen kann, fehlen noch die Cross System Object Lock (CSOL) Überprüfungen. Neu ist der «Intrinsic Downgrade», der dann feuert, wenn mehr als ein Transport in einem Feature vorhanden ist, eins dieser Transporte aber ausserhalb vom Feature, manuell, in eine falsche Reihenfolge gebracht wurde (z.B. durch einen direkten Import in der STMS). Dazu später mehr.

Die Einrichtung dieser wichtigen Überprüfungen wird ausführlich in der SAP Hilfe dokumentiert, sie soll daher hier nicht wiederholt werden.

Die Implementierung der dort als Voraussetzung vorgegebenen Hinweise gestaltete sich bei dem ST-PI Stand 740 SP28 völlig problemlos.

Einschränkungen

Die oben zitierte SAP Help Seite erwähnt, dass die zwei neuen Checks nur für Transporte durchgeführt werden, die auf den Import in das Produktivsystem (hier production tenant genannt) warten oder bereits importiert worden sind (?!). Das ist eine gewichtige Einschränkung, denn es ist bekannt, dass die Kosten der Fehlerbehebung niedriger sind, wenn diese früh erkannt werden («10er-Regel der Fehlerkosten »).

Zu den Freuden der agilen Software-Entwicklung gehört, dass Funktionen nur scheibchenweise geliefert werden. Daher setzte ich meine ganze Hoffnung auf das von mir grün markierte Adverb aus dem SAP Help Text: «Transport checks are only possible for production systems. Pre-production and quality assurance systems are currently not supported.». Ich deduziere daher, dass bald auch das PreProd System in den Genuss dieser Überprüfungen kommen wird (Eigentlich bin ich fast sicher, denn – ich gebe es zu -, ich habe einfach den Produktmanager gefragt).

Eine weitere Einschränkung, dass nämlich das Produktivsystem das letzte System eines Transportweges sein muss, könnte eine Änderung der bestehenden Transportlandschaft erzwingen, es ist nämlich beliebt, ein Schulungssystem als Belieferung durch das Produktivsystem einzurichten.

Schließlich, die Einschränkung, dass Quell-System und Ziel-System auf unterschiedlichen physischen Systemen residieren sollen, macht mir etwas Sorgen, denn ich habe nun mal nur ein einziges Sandbox-System mit unterschiedlichen Mandanten zum Spielen. Wir werden sehen…. (Spoiler: es hat trotzdem alles funktioniert, zum Glück!)

Ausblick

Zurzeit (Anfang März 2025) sind diese Überprüfungen nur innerhalb eines Features möglich, doch ich kann in der Roadmap sehen, dass sie bald für mehrere Features gleichzeitig möglich sein werden:

Ich bin mir fast sicher [auch hierzu habe ich einfach den Produktmanager gefragt], dass so eine Block-Überprüfung auch im Rahmen der frischen «Deployment» App möglich sein wird! Vermutlich verbirgt sie sich hinter dieser geheimnisvollen Roadmap-Ankündigung für Q1 2026.

Praxis

Wir testen wie üblich auf unserem Sandbox-System BSS mit unterschiedlichen Mandanten:

Erster DGP Test

Wir möchten eine DGP Kollision innerhalb eines Feature erzeugen. Dazu legen wir ein Feature mit zwei Customizing Transporten an:

Jetzt kitzeln wir etwas die Transporte.

Diese Neuanlage wird in Transport BSSK901969 «6-60: RE DGP Check 1 – Two Transports: Older» aufgezeichnet:

Wir exportieren diesen Transport, womit er nicht mehr änderbar ist. Ergebnis:

Jetzt ändern wir den Eintrag und zeichnen diese Änderung in den Transport BSSK901967 «6-60: RE DGP Check 1 – Two Transports: Newer» auf:

Übrigens taucht kein Warnungs-Popup auf, wie er sonst bei aktivem SolMan CSOL beim Speichern die Customizer informiert, in welchen weiteren Transporten derselbe Eintrag bereits aufgezeichnet ist. Wir sind gespannt, was in Q4 2005 als «Cross-system object lock foundation for retrofit» kommen wird!

Wir exportieren BSSK901967.

Die Import-Reihenfolge für das QA-System BSS.803 ist korrekt:

Da wir es sehr eilig haben, importieren wir BSSK901967 direkt in der STMS Import Queue – es gibt ja keine CTS Projektschalter mehr, die dies verhindern! Damit verletzen wir die Import-Reihenfolge auch der Folgesysteme!

Man kann natürlich vertrauen, dass niemand einen solchen manuellen Eingriff vornimmt. Doch vielleicht sollte man es sich genau überlegen, ob man nicht doch per Berechtigungskonzept die Möglichkeit stark einschränkt, direkt in der STMS Import Queue Importe zu starten.

Wir deployen das Feature zwei Mal, es hat damit das PreProd System BSS.804 erreicht und wartet, in das Prod System BSS.805 importiert zu werden:

Die DGP Falle steht bereit:

Wir führen den DGP-Check aus dem einzelnen Feature aus:

Tadaa!

Klickt man als feinmotorisch begabter Mensch genau auf die Zahl «2» (es befinden sich ja zwei Tabellen-Einträge in den Transporten), so navigiert man in ein neues Fenster, das m.E. auf sehr gelungene Weise über die Probleme informiert:

Wie erwartet, wird hier der «Intrinsic Downgrade» Fehler gemeldet.

Zweiter DGP Test

Wir möchten eine DGP Kollision zwischen zwei Features erzeugen. Dazu legen wir zwei Features mit je einem Customizing-Transport an:

Wie vorhin, zeichnen wir unterschiedliche Änderungen mit dem gleichen Transportschlüssel in die zwei unterschiedlichen Transporte mit unterschiedlichen Inhalten.

Hier nur ein Beispiel für die erste Änderung.

Ich überspringe jetzt die weiteren Änderungen, sie sind fast analog zum vorherigen Kapitel und komme zur entscheidenden Stelle, die die DGP Überprüfung gestattet, diesmal verwenden wir die schöne «Transport Analysis» App:

Der Überholer (Transport BSSK901965) steht bereit:

Wir starten den DGP Check in beiden Features fast gleichzeitig.

Dieser Zustand als auch das Check-Ergebnis wird leider weder in der «Feature Overview», noch in der «Transport Analysis», noch in der ansonsten sehr ansprechenden «Feature Traceability» angezeigt.

Wir müssen eins der zwei Features auswählen und Refreshen ständig mit Geduld gewappnet den «Transport Checks» Abschnitt mit dem Button «refresh», bis der Job im ABAP System endlich gestartet ist und seinen Arbeitsauftrag durchgeführt hat:

Das Ergebnis ist interessant. Das Feature mit dem Überholer-Transport zeigt nämlich keine Probleme an. Eigentlich hätte ich hier erwartet, dass es den Fehler «Potential Downgrade» anzeigen würde.

Nur im Feature, das einen Downgrade tatsächlich produzieren könnte, existiert eine rote Meldung, hier die entscheidenden Details:

Doch so schlimm, wie es der «Imminent Downgrade» Langtext sagt, ist es nicht, denn beide Transporte sind ja noch nicht produktiv importiert worden. Wir können immer noch durch Einzel-Deploy der Features den korrekten Import durchführen.

Wir starten also den Deploy des Features «RE DGP Check 2 – Older Transport» zuerst, warten bis der Import fertig ist, und starten dann den Deploy des neueren.

So sah der Eintrag im PreProd System BSS.804 aus:

Eindeutig ein Downgrade!

Und so sieht der Eintrag im Produktivsystem BSS.805 aus, dank unseres vorsichtigen Verhaltens:

Natürlich fragt man sich, was denn im PreProd System getestet wurde, aber das steht auf einem anderen Blatt.

Bewertung

Der DGP Check funktioniert im Grossen und Ganzen gut. Wir fragen uns, ob das Ausfallen der Fehlermeldung «Potential Downgrade» bei dem Feature «RE DGP Check 2 – Newer Transport» eher ein Bug sein könnte.

Das lange Warten auf die Ergebnisse des asynchronen Aufrufs könnte die Akzeptanz mindern. Ich habe noch nicht die Hoffnung aufgegeben, dass mein Verbesserungsvorschlag «Direct CTS Transport Handling by Feature via Cloud Connector», endlich angenommen wird.

Zwei SAP Solution Manager Fähigkeiten fehlen noch:

• Die Automatik; die Checks müssen, sozusagen freiwillig, vom Verantwortlichen gestartet werden, statt wie im SolMan beim Statuswechsel automatisch ausgeführt zu werden
• Eine Import-Blockade, die erst durch eine berechtigte Person freigegeben werden muss, bevor der Import tatsächlich ausgeführt wird.

Cross Reference Check

Wir durften auf einem Kundensystem auch den Cross Reference Check testen und er hat prächtig funktioniert. Dieser Check, auch RC=8-Check genannt, ist nämlich Gold wert!

Kurz gesagt, löst er alle Objekte eines Workbench-Transports in ihre Grundelemente auf und führt für diese Elemente einen «Dependency Walk» durch, so dass er auch die implizit referenzierten Elemente ermittelt.

Für all diese vorausgesetzten Elemente überprüft der Check dann, ob sie im Zielsystem vorhanden sind und wenn ja, vergleicht er auch die Versionen. Bei Lücken oder Unstimmigkeiten feuert er Fehler oder Warnungen. Denn wenn ich z.B. mit Transport A einen Include importiere, der ein Tabellenfeld referenziert, dessen Hinzufügung in Transport B aufgezeichnet wurde, der aber noch in Entwicklung ist (oh, wie häufig passiert so eine ungeschickte Architektur!), dann kracht es bei diesem Import mit einem Syntaxfehler.

Wenn ich Pech habe, so war es eins dieser ZX-Erweiterungs-Includes im Vertrieb, die mehrmals in der Sekunde aufgerufen werden. In Nullkommanichts türmen sich im Produktivsystem Tausende von Short Dumps! Ich spreche hier aus Erfahrung. Da kann ein proaktiver Check, der den Schlamassel vor dem tödlichen Import androht, den Karriereknick abwenden.

Wie funktioniert es?

Da es in einem Sandbox-System kaum möglich ist, den Cross-Reference-Check durchzuführen, konzentrieren wir uns hier auf den DGP Check.

Die DGP war ursprünglich Teil des CTS Plug-Ins, das seit Netweaver Basis 7.40 SP10 Teil der Basis-Komponente geworden ist. Doch die Steuerung erfolgte im SolMan, und die Ergebnisse der Überprüfungen wurden im SolMan in /TMWFLOW/DGP_CHK und /TMWFLOW/DGP_CNF zwischengespeichert, die Durchführung selbst in /TMWFLOW/DGP_ENT protokolliert.

Jetzt wird der DGP Check nur noch im Produktivsystem durchgeführt.

Wie in meinem in der Einleitung zitierten Blog analysiert, holt sich ein Batch-Job im Produktivsystem diese DGP Aufgabe aus Cloud ALM und führt sie im Report /SDF/CALM_CDM_TR_SUB_CHECK aus. Er holt sich dazu die Transport-History aus dem Quell-System. Das Ergebnis der Überprüfung (alles roger oder Liste der Konflikte) wird an den Cloud ALM Service ‹/api/transportCockpitService/v1/odata/v4/TransportCockpitService/handleCheckResult› gesendet, es wird also in Cloud ALM gespeichert.

Es stellt sich natürlich die Frage, welche Reorg-Möglichkeiten es in Cloud ALM gibt oder geben wird, da Cloud Speicher teuer ist.

Hier als Beispiel die Protokolle aus dem Mandanten 000 eines gelungenen Überprüfungslaufs für ein Feature (der Systembenutzer für die Batch-Jobs ist BG_CALM, und als «Transaction Code» wird die RFC Destination angegeben, die in Transaktion /SDF/ALM_SETUP als «Target ALM Description» gepflegt wird)

In den zugehörigen Job-Protokollen (SM37) steht das Identische drin.

Ein Wermutstropfen: Weder erfährt man, welche Features die Überprüfung getriggert haben, noch erfährt man, welche Transporte überprüft wurden.

Hat man die Überprüfung zeitnah aus mehr als einem Feature heraus getriggert, so wird für jedes Feature ein eigener Batch Report Lauf gestartet:

Anhang

RFC Verbindung

Nur eine kleine Bemerkung am Rande. Wir hatten dieses kleine Wörtchen in Hinweis 3447901 «Set Up Transport Check for Feature in SAP Cloud ALM Change and Deploy Management» übersehen:

Obwohl die Validierung «Check use-cases» aus Transaktion /SDF/ALM_SETUP grünes Licht gab, brach der DGP Check trotzdem mit Fehler ab:

Kaum macht man es richtig, funktioniert alles: