ALM Kaffeekränzchen VIII – Transportieren mit Cloud ALM

Das gefiederte Feature

Ist es die Dämmerung des SAP Solution Managers oder ist es die Morgenröte von SAP Cloud ALM, in der dieses einsame gefiederte Feature in Richtung Produktion segelt? Es ist beides. 

Da wir uns in einer Phase der Transition befinden, werde ich mich hier auf die Frage konzentrieren, wie man mit Hilfe von Features Transport Aufträge eines OnPremise ABAP Systems von der Entwicklung zur Produktion bringen kann.

Dieser Anwendungsfall ist auch für die SAP Kunden attraktiv, die bisher einen grossen Bogen um ChaRM und/oder Focused Build gemacht haben. 

Hier konzentriere ich mich auf die sogenannte User Experience und die Governance bei der Verwendung von Features, um OnPremise Transporte zu handhaben. 

Um ein Sandbox-System zum Testen einzurichten, darf ich auf die ersten drei Kapiteln des wunderbaren Blogs der berühmten Dolores verweisen: First steps to work with SAP Cloud ALM Deployment scenario for SAP ABAP systems (7.40 or higher). Auch die Anlage und der Workflow von Features wird in Kapitel 4 ausführlich beschrieben und brauchen hier nicht wiederholt zu werden. 

Schau’n mer mal 

Schauen wir uns dann dieses neue Feature an. 

Wir werden dabei unser bestehendes Wissen verwenden, um dieses Neue einzuordnen. Übrigens, ich bewege mich hier im Stand zweite Hälfte von Oktober 2024 – dies muss man hervorheben, da alle zwei Wochen neue Funktionen freigeschaltet werden. 

Bekanntlich hat SAP eine riesige Abteilung, die sich ständig neue Namen für ein-und-dieselbe Funktion ausdenkt. Auch hier war sie sehr erfolgreich: Denn schon auf den ersten Blick scheint ein Feature nur ein schöner neuer Name – wer möchte denn Bugs haben – für das gute alte Change Document zu sein. Es wird auch nicht mehr von Transporten im Transport Assignment Block gesprochen, sondern der letzte Schrei ist jetzt die «Deployment Orchestration von Transport Containern». 

Wzhkevin, CC BY-SA 4.0, via Wikimedia Commons 

Auf den zweiten Blick erinnert das Feature an den guten alten TMS Workflow. 

Anlegen oder Verknüpfen 

Features lassen sich stand heute nur aus der «Features Overview» oder aus einem «Requirement» heraus anlegen, zusätzlich kann man aus einer «User Story», und nur hier, auf genau ein Feature referenzieren. 

In einem Feature kann man wiederum nicht nur Transport Aufträge anlegen, sondern auch User Stories und Project Tasks.

Auch in ChaRM Change Documents konnte man Tasks (Vorgangsart 1003) als Nachfolge-Dokumente anlegen. 

Ich habe Kolleg:innen vorgeführt, wie man damit zusätzliche Team-Mitglieder in einen Änderungsvorgang einbinden könnte, statt sie per E-Mail zu kontaktieren, womit man ein holistisches Konzept des Change Documents etablieren würde, mit dem man eine sehr gute Dokumentation (Traceability) erreichen könnte, aber dies wurde nie angenommen, es blieb bei den informalen E-Mails. 

Deshalb fürchte ich, dass die Möglichkeit, Folge-Tasks anzulegen, auch im Feature brach liegen wird. 

Fehlerkorrektur beim Testen

Was mich stark verwundert, ist, dass es bis heute keine direkte Verbindung zwischen einem Test-Defect (technisch eine Task-Art) und einem Feature existiert. Man muss hier einen Umweg nehmen. 

Zunächst muss man das Feature anlegen:

Erst dann kann man die URL des neuen Features in dem Test Defect als Referenz per Copy&Paste hinzufügen:

Möchte man in dem Feature dokumentieren, für welchen Defect man arbeitet, muss man diese Prozedur für die andere Richtung wiederholen (URL des Defects als Referenz im Feature), denn es gibt hier noch keine Automatik:

Ich ahne schon, dass diese umständliche manuelle Verlinkung auf keine grosse Akzeptanz stossen wird. 

Doch es besteht Hoffnung für Q2 2025:

Schau’n mer mal! Dann sehn mer scho! 

Transporte 

Im Unterschied zum ChaRM und eher in Anlehnung an Focused Build, sind Features immer an Cloud ALM Projekte gebunden. 

Diese Projekte referenzieren einen «Deployment Plan», der einer ChaRM Change Control Landscape (CCL) ähnlich ist, und genau wie letztere enthält diese «Landscape» eine oder mehrere «System Groups». Jede «System Group» enthält wiederum einen Track, was vormals Logische Systemkomponente genannt wurde. Damit können wie gehabt mehrere Tracks mit einem Change, oh, pardon, Feature bespielt werde. 

In unseren Beispielen verwenden wir ein Projekt «Maintenance Project», das den fantasievoll benannten Plan «Deployment Plan 2024» verwendet, der wiederum nur eine System-Gruppe kennt, nämlich die ebenso originell benamste «BSS Maintenance». 

Unsere Demo-Landschaft auf dem OnPremise ABAP System hat zwei Tracks, einen Vier-Systeme-Track für Projekte (BSS.801 🡺 803 🡺 804 🡺 805) und ein Drei-Systeme-Track für Wartung (BSS.811 🡺 813 🡺 805).  

Entsprechend ist auch das Wartungsprojekt in Cloud ALM definiert: 

Das Gegenstück wäre «BSS Project», wird aber in unseren Beispielen nicht verwendet. 

Wir probieren eine Transportanlage aus 

Unser Drehbuch: Wir möchten niemanden auf unsere Entwicklungen aufmerksam machen, um Diskussionen zu vermeiden, daher belassen wir unser Feature im Status «In Specification» und legen gleich Transporte an, denn es ist bereits in diesem Anfangsstatus möglich! Um Transporte anzulegen, benötigt man die mächtige «Project Lead» Rolle, die ich natürlich deshalb erhalten habe. 

Eigenartig ist, dass – im Gegensatz zum ChaRM – man Transporte nur anlegen kann, wenn das Feature nicht im Änderungsmodus ist (siehe den aktiven Edit-Button), und dieser Anlage-Button befindet im Feature-Kopf, als ob ein Transport eine Entität auf derselben Ebene wie User Stories usw. wäre. 

Möchte man hingegen einen existierenden Transport dem Feature hinzufügen, so muss man stattdessen in den Edit-Modus wechseln und dann zum «Transports» Abschnitt navigieren. 

Man gewöhnt sich dran. 

Eigentlich wäre BSS~813 die richtige Wahl für den «Target» des «Maintenace Project», doch dessen «Deployment Plan» wird ignoriert und es wird das fremde Konsolidierungssystem BSS.803 als erstes angeboten. 

Nun gut. Ich tue so, als ob ich so schusselig bin, wie ich es tatsächlich bin, wenn in Eile. 

Ich übersehe, dass das falsche Konsolidierungssystem für das Wartungs-Entwicklungssystem BSS.811 angeboten wird, und winke die Transport-Anlage durch. 

Auch habe ich übersehen, dass es ein Feld «Owner» gibt, und haben es leer gelassen. Diesem Eingabefeld fehlte sowieso eine Wertehilfe für die möglichen User-IDs aus dem Entwicklungssystem. 

Da im Cloud ALM nur ein Merker für eine Transportanlage angelegt wird, müssen wir jetzt warten, bis die Batch-Jobs auf dem BSS.811 System endlich starten und die Aufgabe von Cloud ALM holen, ausführen und das Ergebnis zurückgeben. Hier heisst es, geduldig wiederholt auf den Refresh-Knopf zu drücken: 

Bald haben wir es geschafft: 

Wir loggen uns in das Maintenance Entwicklungssystem ein und finden die Transporte zunächst nicht in der Transaktion SE09. Denn es wurde, da wir das Kann-Feld «Owner» leer gelassen haben, der Eigentümer des Batch-Jobs verwendet, bei uns «BG_CALM»:

Kein grosses Problem, wenn wir die Berechtigung im Entwicklungssystem haben, den Eigentümer eines Transports zu ändern. 

Aber wenn wir mit den soeben angelegten Transporten arbeiten möchten, stossen wir sofort auf Probleme:

Der eigentlich für die Entwicklung vorgesehene Transport BSSK901892 wird nicht zur Auswahl angeboten, da er leider das falsche Ziel hat. 

Trotz vorhandener Fallen, auf die man achten muss, hat die Anlage eines Transports aus einem Feature heraus den Vorteil, dass sowohl die sprechende als auch die technische Feature-ID dokumentiert werden:

Es ist besser, Transporte hinzuzufügen 

Wegen dieser Fehleranfälligkeit ist es meiner Meinung nach besser, während des Entwickelns und/oder Customizing – wie zu R/3-Zeiten – einen Transport aus der jeweiligen Anwendung heraus neu anzulegen:

Der Vorteil ist, dass das Change and Transport System (CTS) alle Werte (Owner, Target) automatisch korrekt einsetzt: 

Auch benötigt man hierzu keine so weitreichenden Berechtigungen wie bei der Anlage von Transporten (s.o.). 

Der hochfrequente Synchronisierungs-Job sendet diese Transportdaten an Cloud ALM, so dass sie bald sichtbar sind. Dies kann man zum Beispiel mit der «Transport Analysis» App überprüfen: 

Ist der neue Transport in Cloud ALM bekannt, können wir das Feature in den Änderungsmodus versetzen und den neuen Transport «Assignen»: 

Glücklicherweise bietet der Assign-Dialog nur Transporte an, die den Source-Tenant BSS~811 haben. 

Der einzige Nachteil dieses Vorgehens ist, dass die technische Feature-ID nicht als Attribut des Transportes dokumentiert wird. Aber das hat keine Konsequenzen. 

Schwierige Ko-Existenz 

Seit den Anfangszeiten des ChaRMs müssen wir bei dessen korrekten Einrichtung den Zwang zum CTS-Projekt einschalten, damit die Projekt-Schalter für Transport-Aktionen es erzwingen, dass nur der ChaRM (oder Focused Build) Transporte anlegen, freigeben und importieren kann. 

Doch Cloud ALM wurde hier vereinfacht und kennt daher keine CTS-Projekte mehr. Also sollte man mit der Transaktion SE03 🡺 «Display/Change Request Attributes» diesen Zwang zur Eingabe des SAP_CTS_PROJECTS wieder entfernen. 

Es gibt keinen «Selective Data Transfer» nach Cloud ALM für ChaRM und Focused Build. Man muss deren Zyklen abarbeiten und schliesslich beenden und währenddessen Neues nur per Feature anlegen. 

Wollte man in dieser Phase der Ko-Existenz die strenge Governance im ChaRM beibehalten, müsste man die Berechtigung, Transporte freizugeben (Berechtigungsobjekt S_TRANSPRT, Activity 43) allen Usern im Entwicklungssystem entziehen, um somit den Wechsel auf Cloud ALM Features sanft zu erzwingen, aber wer schafft das schon auf einem etablierten Entwicklungssystem? 

Ein Vorteil hat das Ignorieren der CTS-Projekte: Man kann einem Feature auch bereits freigegebene Transporte hinzufügen: 

Testen mit Transport of Copies (ToC) 

Im Unterschied zum Normal Change vom ChaRM (und Focused Build) ist das Testen im Konsolidierungssytem mit ToCs freiwillig. Man muss ausdrücklich den Button drücken und die Quellen für die ToCs auswählen: 

Leider gibt es keine sichtbare Rückmeldung dafür, dass man die Anlage von ToCs beauftragt hat; man sieht dies nur, wenn man die History öffnet: 

Erst wenn der Batch-Job im ABAP System seine Arbeit getan hat, werden die ToCs sichtbar. 

Wir stellen fest, dass die freundliche Löschung von leeren Transport-Tasks wie im ChaRM jetzt wieder fehlt: 

Statusabhängigkeit der Transportaktivitäten 

In einem Feature heraus kann man je nach Status des Features folgende Transport-bezogene Aktivitäten durchführen: 

Wie man sehen kann, ist nicht nur im Status «In Implementation», sondern auch im Status «In Testing» alles erlaubt. Dies ist völlig anders als in einem ChaRM Change Document, bei dem streng zwischen Entwicklung und Testen getrennt wurde. Mir ist die Begründung für diese hohen Freiheitsgrade nicht klar. 

Nehmen wir nämlich an, der Tester hat die Funktion erfolgreich im ABAP QA-System getestet und geht dann im Hochgefühl des erlebten Erfolges in die Mittagspause, das Setzen des neuen Status «Successfully Tested» will er nach der Pause zusammen mit einer Tasse Kaffee machen. 

In der Zwischenzeit fällt der Entwicklerin ein, dass sie etwas vergessen hatte; sie legt schnell einen Transport an, zeichnet die Änderung auf und schiebt die Änderung in das QA-System. 

Wie wird sichergestellt, dass der Tester diese nachträgliche Änderung mittestet, bevor er den Status setzt? 

Auch frage ich mich, in welchem Use Case ein Tester den erfolgreichen Test bestätigt, obwohl die Transporte noch änderbar sind: 

Ah, Fragen über Fragen…. 

Zur Produktion 

Auch hier erlaubt das Feature, Transporte nur dann freizugeben, wenn es nicht im Änderungsmodus ist: 

Im Unterschied zur Anlage von ToCs wird diese Aktion sofort im Feature sichtbar. 

Der Import in die Folgesysteme wird jetzt «Deployment» genannt. Dabei verhält sich Cloud ALM ganz anders als der ChaRM. 

Hat man, wie im Beispiel, eine Mischung aus Drei- und Vier-System-Landschaft, so muss man sich daran gewöhnen, dass Cloud ALM vom Produktivsystem rückwärts rechnet, das heisst, dass man den Transport der Drei-System-Landschaft erst dann in das Konsolidierungssystem (hier BSS.813) importieren kann, wenn in der Vier-System-Landschaft die Transporte das PreProduction System (hier BSS.804) erreicht haben, denn beide Systeme (BSS.804 und BSS.813) beliefern die Produktion: 

Sehr schön realisiert, finde ich, ist der schliessliche Massen-Import aus der Übersichtsseite heraus, falls man nach dem passenden Status filtert: 

Das hat den Vorteil, dass der Import aller hier selektierten Transporte in das Produktivsystem gleichzeitig mit einem tp IMPORT SUBSET erfolgt. 

Sehr ansprechend finde ich auch die analytische «Feature Traceability»: 

Einziger Wermuttropfen ist die Zusammenfassung von QA- und PreProd-System in einer Ikone: 

Technische Handhabung von CTS-Transporten 

Stand heute ist das Anlegen und/oder Freigeben und Importieren eines OnPremise Transportauftrag vom Feature heraus asynchron. 

Es wird in Cloud ALM nur eine Art Vormerkung angelegt. Im Verbundenen ABAP System rennt ein hochfrequenter Job, der sich die Aufgaben von dem Cloud System holt, sie ausführt, und das Ergebnis in die Cloud hochlädt. 

Möchte man zum Beispiel im Fehlerfall diesen Vorgang nachvollziehen, so muss man sich im passenden Mandanten (beim Export im Entwicklungsmandanten, beim Import im Mandanten 000) einloggen und hier mit der Transaktion SLG1 mit Filter nach dem Batchprozess-User den fraglichen Zeitraum eingrenzen. 

Hier tracen wir die Anlage der ToCs von vorhin: 

Aus dem Feature heraus gelangt man nicht an diese Protokolle. 

In Gesprächen während des ALM Summit 2024 in Mannheim habe ich erfahren, dass in Zukunft eine direkte Verbindung zwischen den Features und dem OnPremise ABAP System über den SAP Cloud Connector angeboten werden wird. 

Zusammenfassung 

ChaRM und Focused Build sind innerhalb von zwanzig Jahren zur Leuchtturm-Anwendung des Solution Managers gereift und natürlich braucht Cloud ALM Zeit, um es mit diesem Riesen aufnehmen zu können:  

Das SAP Team arbeitet mit Hochdruck daran, zum ChaRM/FB aufzuschiessen, hier biete ich eine kleine Zusammenfassung mit Ausblick: 

• Mit Features kann man CTS-Transporte anlegen und durch die Landschaft bewegen; hat man eine einfache Systemlandschaft, so kann man heute schon problemlos ABAP Transporte mit Features steuern 

• Cloud ALM ist sehr leicht einzurichten und die Features sind in das Cloud ALM Implementierungs-Szenario nahtlos eingebunden 

• Das Look&Feel der UI ist hervorragend, die Performance erstaunlich gut 

• Das Szenario «Customizing/Code-Korrektur wegen fehlerhaftem Test-Ergebnis» wird stand heute nicht direkt unterstützt, es wird laut Roadmap erst Q2 2025 kommen, aber es gibt einen etwas umständlichen Umweg 

• Cloud ALM kennt keine CTS-Projekte, daher ist eine Ko-Existenz mit ChaRM/Focused Build in einer Transport-Landschaft nicht zu empfehlen 

• Die Anlage von Transporten aus dem Feature heraus erlaubt sehr viele, zu viele Freiheiten; besser ist es, bei Bedarf die benötigten Transporte direkt im ABAP System anzulegen, um sie dann dem Feature hinzuzufügen 

• Die grosse Freiheit bei der Status-Abhängigkeit und beim Definieren der Zielsysteme erinnert stark an den alten TMS Workflow 

• Bedarf man hingegen eines strengen Transport-Regelwerks, so sollte man noch warten;  
  die Zeit ist zyklisch: so wie vor zwanzig Jahren aus den Unzulänglichkeiten des TMW Workflows heraus der ChaRM und danach Focused Build entstanden, so wiederholt sich jetzt dieser Zyklus – wenn auch mit viel schnellerer Rotation -, denn SAP plant bereits den Sprung zu Focused-Build-ähnlichen Checks; die Planung ist jedoch nur teilweise in der Roadmap fixiert: 
  

Eine Ergänzung zu ITSM 

Cloud ALM will ausdrücklich kein ITSM-Werkzeug sein. 

Wenn man, wie ich anfangs erwähnte, bisher nie ChaRM oder Focused Build verwendet hat, aber jetzt endlich eine revisionssichere Änderungsverwaltung einführen möchte, die den gesamten Prozess von der Störung bis zum produktiven Transport abdeckt, so möge man den Weg gehen, den die Stadtverwaltung von Bern (CH) gegangen ist.

Mit Hilfe unseres alm360 Hub wurde hier ein externes ITSM-Werkzeug mit Cloud ALM verknüpft und so eine Traceability über den gesamten Prozess erhalten: