ALM Kaffeekränzchen XI – Dual Landscape: Retrofit aus der Cloud

 Endlich ist es so weit! 

Das SAP Cloud ALM Team hat die Retrofit Funktionalität auch in den SAP Solution Manager Nachfolger SAP Cloud ALM implementiert. 

Spoiler:

Das Wichtigste ist vorhanden, die Retrofit Kategorisierung steht, es gibt aber noch ein paar Schatten, die wir hier ausleuchten möchten. Natürlich fehlen noch Fähigkeiten, wie z.B. die Cross-Release Retrofits, usw., aber wir sind geduldig und können warten. 

Zur Retrofit Thematik haben wir uns beim fünften Kränzchen (Teil 4), Kapitel «Retrofit Grundlagen» bereits ausgetauscht. Wir verwenden wie damals unser Sandbox-System, auf dem wir eine Fünf-System-Landschaft mit Hilfe unterschiedlicher Mandanten simulieren: 

Einrichtung 

Wenn man bereits den ABAP Transport-Use Case für Cloud ALM am Laufen hat, geht die Einrichtung des CALM Retrofits erstaunlich einfach von der Hand, die SAP Help Seiten enthalten alle nötigen Informationen. 

Verwaltete Systeme 

Die Einrichtung in den verwalteten Systemen (Entwicklung in Wartung und in Projekt) hat einen eigenen Abschnitt erhalten: 

• SAP Notes einspielen, die die Software enthalten; ab ST-PI 740 SP33, das Januar 2026 freigegeben wird, sollte dies nicht mehr nötig sein 
• PFCG Rollen aus den Hinweisen implementieren 
• Technische User mit diesen Rollen neu anlegen oder ändern 
• Eine RFC Verbindung von Wartung nach Projekt einrichten 
• In beiden Systemen muss man Steuerungstabellen pflegen 
• Falls noch nicht geschehen, mit SICF den Service CTS_BROWSER aktivieren 

Anmerkungen 

Wie beim SolMan Retrofit ist es immer noch notwendig, dass sich beide Systeme auf Transportebene sehen können (selbe TMS Domäne oder TMS Domain Link). 

Die Rolle SAP_SDF_CALM_CDM_RETROFIT_RFC für das Projekt-Entwicklungssystem enthält eine etwas naive Berechtigung, was das Transportverzeichnis angeht – es gibt sie nämlich noch, die ABAP Windows Server Biotopen, auch lieben es einige SAP Administratoren, bei den Verzeichnisnamen kreativ zu sein: 

Man muss diese Rolle sowieso erweitern, da leider die S_RFC Berechtigung für den Funktionsbaustein RFCPING fehlt, der notwendig ist, um in der SM59 des Wartungssystems die Verbindung auch für Berechtigungen zu testen. 

Die Pflege der pflegedialoglosen Tabelle /SDF/CDM_PARAM, die das anvisierte Produktivsystem bekannt gibt, ist amüsant, aber so wird es uns nicht langweilig: Mit der SE16 muss man nämlich so einem Eintrag hinzufügen:

Hat man mehr als ein Produktivsystem im Transportweg  (im alten SolMan waren dies die Sites), dann muss man jedes weitere Produktivsystem komma-separiert hinzufügen. Ich gebe zu, ich habe so einen lustigen DNO_CUST04 Parameter auch mal programmiert, denn es macht Spaß, der Welt zu zeigen, wie virtuos man die ABAP String-Funktionen beherrscht … 

Cloud ALM 

Auch diese Dokumentation ist völlig ausreichend. Wir fassen daher die Schritte im Stile eines Kochrezepts nur kurz zusammen: 

• Man nehme zwei Projects, eins für Wartung (Retrofit-Quelle), eins für Projektarbeit (Retrofit-Ziel) 
• Passend dazu zwei System Groups anlegen/pflegen 
• Ziel-Deployment Plan mit Ziel-Projekt verbinden 
• Quell-Deployment Plan anlegen/pflegen, hier Retrofit zum Ziel-Projekt konfigurieren 
• Quell-Deployment Plan mit dem Wartungsprojekt verbinden 

Erste Begehung

Die neue Retrofit App begrüsst uns mit einer Übersicht der vorhandenen Retrofit-fähigen Projekten, analog zum Focused Build Einstieg über eine Liste von Wartungsplänen. 

Wie erwartet, werden bei bereits existierenden Features des Wartungsprojektes deren Transporte nicht nachträglich der Retrofit Warteschlange hinzugefügt: 

Es geht los 

Um unsere Erfahrungen hier schlank zu halten, nehmen wir uns zwei Fälle vor: «Automatic» und «Manual», die gemischten Varianten, bei denen ein Wartungstransport beides enthält, werden aber auch unterstützt (in Focused Build war dies das Full Scope (AUTO_FULL) Szenario). 

Wir legen ein Feature im Maintenance Projekt an und bestücken es mit einem Transport, wir zeichnen unsere Wartungs-Änderung an der berühmten Tabelle T005a darin auf und geben den Transport frei. 

Die Freigabe triggert den Export und gleich danach die Retrofit Kategorisierung im ABAP Wartungssystem an (hier BSS.811), dessen Ergebnis in der neuen Retrofit App sichtbar sein wird. 

Man muss immer noch blind warten, bis der Job auf dem Wartungssystem gestartet ist und den Transport exportiert hat. 

Nach einer endlichen Zeit und ein paar «Refresh» ist es so weit:

Die neue Spalte «Retrofit Status» zeigt, dass wir loslegen können. 

Die Retrofit App 

Sehr schön ist, dass man die Retrofit App direkt aus dem Feature heraus öffnen kann. Angenehm ist übrigens auch, dass man mit dem Back-Button wieder in das Feature zurückkann.

Wenn wir den Detail-Pfeil klicken, erhalten wir die ausführliche Sicht, und wenn wir dort auf «Show More per Row» wiederum klicken, erfahren wir die Gründe für die Kategorisierung: 

Um die Automatik zu genießen, müssen wir in der Retrofit App ein Feature im Ziel-Projekt angeben und dessen Transporte passend auswählen. 

Da es unser erster Retrofit ist, entscheiden wir uns für eine Neuanlage von allem, denn dafür gibt es eine komfortable Möglichkeit: 

Ein «Refresh» Button fehlt hier leider: 

Wir warten also blind und ohne Instrumente die üblichen CALM Feature Gedenkminuten und drücken irgendwann beherzt «Edit», um eine Aktualisierung der Anzeige zu erzwingen. Siehe da, die Anlage ist endlich erfolgt; der Text des Features wird automatisch vergeben: 

Dabei wird bei der Anlage der Transporte der technische User für die Cloud ALM Integration (hier: BG_CALM) als Owner genommen: 

Man könnte sagen, dass hier nur das Focused Build Retrofit Automation Szenario AUTO_CD unterstützt wird. Wir hoffen, dass irgendwann das stille, stabile und unkomplizierte AUTO_TOC Szenario wieder unterstützt wird. 

Automatic? 

Wir freuen uns und, von Focused Build verwöhnt, erwarten, dass die Automatik jetzt die Arbeit erledige. 

Doch es passiert – nichts. 

Wir schauen enttäuscht tief in die Dokumentation und stellen fest: «Aha, dies ist eine manuelle Automatik» (wenn man so will, ein Oxymoron). Ich kann mich erinnern, wie die Göttin eine ähnliche Halb-Automatik anbot: Um den Gang zu wechseln, musste man einen kleinen Hebel am Lenkrad antippen, immerhin, die Kupplung wurde beim Gangwechsel automatisch betätigt. 

Nun gut. 

Wir selektieren unseren Transport und tippen den Button «Start Retrofit» an: 

Und wieder vermissen wir den Refresh Button: 

Hier kann man sich wenigstens mit dem Öffnen und Schliessen des Detail-Fensters behelfen. 

Doch es tut sich nichts, wir werden nervös. Wir untersuchen mit SM37 im ABAP System, ob wir abgebrochene Jobs entdecken können (siehe weiter unten). 

Diese Beschäftigungstherapie bringt uns über die leere Wartezeit, endlich können wir das Ergebnis bewundern:

Unser erster halb-automatischer Cloud ALM Retrofit war erfolgreich! 

Warnung! Ergebnisse konsolidieren 

Das mit der Retrofit App erzeugte Target Feature hat den Anfangsstatus «In Specification»: 

Dies hat zur Folge, dass man das Feature wieder löschen kann, obwohl Wartungs-Transporte bereits in die Target Transporte dieses Feature retrofitted wurden. 

Wir haben es natürlich ausprobiert, und mit tragischem Erfolg:

Man sollte also so früh wie möglich das Target Feature «In Implementation» setzen! 

Wo bleiben die Kollisionen? 

Wir versuchen, eine Kollision zu erzeugen, um den manuellen Retrofit zu untersuchen. 

Wir legen in unserem Wartungs-Feature einen neuen Transport an und bestücken ihn mit demselben und einem neuen Schlüssel in Tabelle T005a und geben den Transport frei. 

Das Ergebnis ist ebenso ein automatischer Retrofit. 

Eine nachträgliche Freigabe des Ziel-Transports BSSK902202 und die Anlage eines neuen Target-Transport (BSSK902218) in der Retrofit App ändert nichts an dieser Kategorisierung:

Wir starten den halb-automatischen Retrofit, der trotzdem sauber durchläuft. 

Eigentlich hätten wir erwartet, dass dabei die Kategorisierung wiederholt wird und einen Retrofit-Fehler generiert (wir werden es etwas später forcieren). 

Das verwirrt uns jetzt etwas, da die Dokumentation statuarisch deklariert: «This means that target transports, containing the same objects as source transports, which have been released in the last 6 months are included in conflict determination». Ob das damit zusammenhängt, dass der Zieltransport dem “Default Target Feature for Retrofit” angehört? 

Wir hätten gerne die Kategorisierung wiederholt, um eine Änderung des Retrofit-Status zu erzwingen, aber man kann sehen, dass «Regenerate Retrofit» inaktiv ist, denn im Unterschied zum SolMan Retrofit kann man die Retrofit-Daten erst dann neu generieren, wenn es einen Fehler bereits gegeben hat. 

Dies ist schade, denn in der SolMan-Vergangenheit war die Funktion «Create Retrofit Data Again» oft der Retter aus der Not, falls eine Aktion z.B. wegen RFC-Verbindungsproblemen mittendrin abbrach und sich alles verknotete. 

Aber vielleicht gibt es in der neuen SAP Cloud ALM Welt keine hässlichen Abbrüche mehr! 

Endlich haben wir eine Kollision! 

Wir starten also einen zweiten Versuch, einen Konflikttransport zu erzeugen. Diesmal legen wir ein neues Feature im Implementierungsprojekt an und zeichnen eine Änderung am selben Objekt in dem Projekt-Transport BSSK902220 «6-242: RE Retrofit Test – Project Work» auf. 

Und siehe da, wir der Status ist rot geworden:

«Start Retrofit» ist jetzt inaktiv. 

Wir müssen das Detail-Fenster des einzelnen Retrofit Eintrags im Änderungsmodus öffnen und für jedes manuelle Objekt einen Zieltransport auswählen. Falls es hier eine Massen-Zuweisung gäbe, so ist sie mir entgangen. Ein Glück, dass es nur zwei Einträge sind! 

Die Auswahl des jeweiligen Zieltransports ist ziemlich verwirrend, denn sie zeigt alle(!) änderbaren Transporte an, die das Projekt-QA-System (803) als Ziel haben, auch solche ohne Feature, sie verrät aber weder die Transportnummer noch zu welchem Cloud ALM Projekt sie gehören! 

Was auch m.E. problematisch ist, ist, dass wir keinen Hinweis erhalten, welches denn der Konflikt-Transport aus dem Implementierungsprojekt sei. Falls dieser noch änderbar wäre: Wäre er dann nicht der ideale Kandidat für die Auswahl als Target Transport? Man könnte mit diesem änderbaren Konflikt-Transport das Eingabefeld sogar vorbelegen. 

Ferner, wir können beliebig unterschiedliche Transporte als manuelle Ziele angeben, wie hier als Probe aufs Exempel geschehen. 

Gut, diese Target-Transport-Einträge haben nur dokumentarischen Charakter. 

Doch wir sehen ziemlich schwere Fehlerwolken am Horizont aufkommen und höre viel Sand im Getriebe knirschen, falls eines Tages ein produktiver Software-Missstand die Suche nach möglichen Ursachen notwendig machte … 

Photo by Elise Teur on Unsplash 

Zum Glück (?) bleiben die Einträge für die Target Transporte sowie deren «Implementation Status» weiterhin änderbar, obwohl der manuelle Retrofit längst als erfolgt gilt:

Der Status «Manually Retrofitted» bleibt bestehen, auch wenn man Einträge als mit «Not Implemented» kennzeichnet. 

Man kann als Scherzkeks sogar eine Target Transport-Nummer angeben, in die «Nicht implementiert» wurde. Dies erinnert mich an den netten Mathematiker-Witz zur Mengenlehre: «Wenn in einem Raum 5 Leute sind und 6 Leute gehen raus, muss einer wieder reingehen, damit der Raum leer wird». 

Update: Dies war der Stand Ende Januar 2026. Jetzt beim Korrekturlesen Anfang Februar ist der nachträgliche Edit-Button verschwunden. Trainingsmaterial für eine agil gelieferte Anwendung ist eine Herausforderung! 

Wir erhalten einen Retrofit Error! 

Doch wie präzise ist die Kategorisierung? 

Wir legen einen kleinen Versuchsaufbau an. In unserem Maintenance Feature legen wir einen neuen Transport an, zeichnen darin eine Änderung auf, die mit Sicherheit keinen Konflikt mit dem Projekt hat und geben Aufgabe und Transport frei. 

Wie erwartet strahlt der Retrofit Status wunderschön grün unter der CALM Sonne: 

Gemeinerweise entscheidet das Implementierungsteam, dass das Projekt für genau diesen Eintrag einen neuen Inhalt benötigt, es ändert ihn entsprechend und zeichnet die Änderung in dem Projekt-Transport BSSK902220 auf. 

Es gibt keine CSOL Warnung mehr wie damals im Solution Manager! 

Dies erhöht die Anforderungen an die Projektleitung, die regelmässige Kommunikation mit dem Wartungs-Team von allem Anfang an einzuplanen und nicht erst zum Ende in der Hypercare oder Operativen Phase des Projektes. 

Wir starten den Retrofit des immer noch «grünen» Transport-Eintrags:

Nach ein paar CALM Warteminuten erhalten wir dieses Ergebnis:

Sehr gut! Die Kategorisierung ist robust und fängt nachträgliche kollidierende Änderungen ein! Was uns aber etwas irritiert, ist, dass der Button «Regenerate Retrofit» immer noch inaktiv ist. 

Erst nach einem kompletten Neu-Laden der Anwendung im Browser (!) erhalten wir unsere Chance zur Neu-Bewertung:

Ab jetzt geht es «Manual» weiter. 

Reject Retrofit 

Diese Aktion verhält sich ziemlich anders als im SolMan ChaRM: Man kann in Cloud ALM nur «Automatische» Retrofits «Reject»en. 

Und der bereits erzeugte und freigegebene ToC muss dann auch noch manuell von der Import-Queue des Projekt-Entwicklungssystem gelöscht werden. Ob wir dazu die Berechtigung haben? Oder müssen wir die Systemadministration bemühen? 

Dabei erhält der Quell-Transport den Status «Manually Retrofitted»:

Wir finden dies schade. 

Denn die seltensten Projekte beeinflussen das gesamte Produktivsystem. Sehr oft bezwecken sie die Einführung zusätzlicher Komponenten oder Länder-Rollouts. 

So haben wir bei Kunden mehrere Fälle erlebt, bei denen ein Retrofit in die Projektlandschaft ausdrücklich und wohlbegründet verweigert wurde: Den Einbau von für die Produktion notwendigen SAP Hinweisen, die die Projektarbeit nur stören würden, Customizing-Änderungen von Interfaces zu Nicht-SAP Systemen, die in der Projektlandschaft gar nicht eingerichtet waren, Berechtigungs-Rollen, BRF+-Regeln, die in der Projektlandschaft nicht vorgesehen waren, usw. 

Damit verlieren wir die Übersicht in der Retrofit App, welche Source-Transporte den Status «Manually Retrofitted» besitzen, weil sie «Rejected» und welche «Manually Retrofitted» sind, weil tatsächlich die Wartungsänderung manuell in die Projektlandschaft übernommen wurde. 

Einziges kleines Indiz könnte bei manuellen, roten Objekten das leere Feld für den Target-Transport sein, aber dies ist ein sehr schwacher Hinweis, und es fehlt eine Reporting-Möglichkeit hierzu. 

Bei gemischten Transporten wird es noch undurchsichtiger.

Hier wurde bei zwei Transporten die Funktion «Reject» angewendet. Mit viel Aufmerksamkeit und Wissen könnte man eruieren, dass der vorletzte Transport (BSSK902234) ein «Rejected» sei, weil nur dann der Transport gleichzeitig «Automatic» und «Manually Retrofitted» sein kann. 

Doch wer kann ahnen, dass beim letzten, gemischten Transport (BSSK902237) ebenso die Funktion «Reject» den automatischen Teil zurückgewiesen hat? 

Wir können nur hoffen, dass der alte SolMan Retrofit Status «Rejected» wieder zurückkehrt. 

Unter die Haube geschaut 

Wegen der hochfrequenten CALM Synchronisierungs-Jobs im ABAP System ist es ziemlich schwer, die entscheidenden Protokolle zu identifizieren. Ein Monitor Report, der nur das Anwendungs-Log von Jobausführungen mit Inhalt anzeigt, fehlt bisher. 

Mit der SM37 kann man mandantenunabhängig versuchen, den Job aufzuspießen, hier ein Beispiel: 

Das entsprechende Anwendungs-Log ist hingegen mandantenabhängig, also suchen wir im Mandanten 811. Man erkennt den Lauf, bei dem sich etwas getan hat, eigentlich nur an der höheren Anzahl von Nachrichten. Hier ein Beispiel für eine Transportanlage im Mandanten 811:

Die Übersicht der verwendeten «External Identification»s kann man in der Dokumentation finden. 

Export

Hier ist ein Beispiel für die Freigabe eines Transportauftrags: 

Gleich nach dem Export (1) wurde der Job gestartet (2), der den Report für die Retrofit-Kategorisierung (3) startet. Falls das Ergebnis der Kategorisierung grün ist, legt dieser Report auch den ToC (Transport of Copies) für das Ziel-Projektsystem an und gibt ihn frei. 

Es ist übrigens die einzige Stelle, bei der wir den «Zwischen-ToC» identifizieren konnten. 

Hier kann man sehen, dass der ToC gleich nach der Anlage freigegeben wurde:

 Schön ist, dass bei ToC Anlage der «Owner» des Quell-Transports (hier RE) beibehalten wurde. 

Die Freigabe des ToCs hinterlässt aber keine Spuren im Anwendungs-Log. Man fragt sich, wie es aussehen wird, falls die Freigabe des ToCs bei den «Pre-Export Methods» scheiterte, was immer wieder mal passiert. 

Automatischer Retrofit 

Wir finden den Retrofit Job des automatischen Retrofits, das Log-Protokoll sieht beruhigend aus: 

Wir waren etwas überrascht, dass das Anwendungsprotokoll des Retrofits, der immerhin den Import eines ToCs in das Zielsystem und eine Übernahme der Stückliste in den «echten» Transport des Zielsystems durchführen muss, nur im Quellsystem zu finden sei (in unserem Sandbox System ist das der Mandant 811):