{"id":38156,"date":"2024-11-17T11:57:54","date_gmt":"2024-11-17T10:57:54","guid":{"rendered":"https:\/\/www.blue.works\/?p=38156"},"modified":"2026-02-17T09:10:36","modified_gmt":"2026-02-17T08:10:36","slug":"cloud-alm-kaffeekraenzchen-viii","status":"publish","type":"post","link":"https:\/\/www.blue.works\/de\/cloud-alm-kaffeekraenzchen-viii\/","title":{"rendered":"ALM Kaffeekr\u00e4nzchen VIII \u2013 Transporte in Cloud ALM"},"content":{"rendered":"\n

Das gefiederte Feature<\/strong><\/h2>\n\n\n\n

Ist es die D\u00e4mmerung des SAP Solution Managers oder ist es die Morgenr\u00f6te von SAP Cloud ALM, in der dieses einsame gefiederte Feature in Richtung Produktion segelt? Es ist beides. <\/p>\n\n\n\n

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\u00e4ge eines OnPremise ABAP Systems von der Entwicklung zur Produktion bringen kann.<\/p>\n\n\n\n

Dieser Anwendungsfall ist auch f\u00fcr die SAP Kunden attraktiv, die bisher einen grossen Bogen um ChaRM und\/oder Focused Build gemacht haben. <\/p>\n\n\n\n

Hier konzentriere ich mich auf die sogenannte User Experience und die Governance bei der Verwendung von Features, um OnPremise Transporte zu handhaben. <\/p>\n\n\n\n

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

Schau\u2019n mer mal<\/a> <\/h3>\n\n\n\n

Schauen wir uns dann dieses neue Feature an. <\/p>\n\n\n\n

Wir werden dabei unser bestehendes Wissen verwenden, um dieses Neue einzuordnen. \u00dcbrigens, ich bewege mich hier im Stand zweite H\u00e4lfte von Oktober 2024 – dies muss man hervorheben, da alle zwei Wochen neue Funktionen freigeschaltet werden. <\/p>\n\n\n\n

Bekanntlich hat SAP eine riesige Abteilung, die sich st\u00e4ndig neue Namen f\u00fcr ein-und-dieselbe Funktion ausdenkt. Auch hier war sie sehr erfolgreich: Denn schon auf den ersten Blick scheint ein Feature nur ein sch\u00f6ner neuer Name – wer m\u00f6chte denn Bugs haben – f\u00fcr 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 \u00abDeployment Orchestration<\/em><\/a> von Transport Containern<\/em>\u00bb. <\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Wzhkevin, <\/em>CC BY-SA 4.0<\/em><\/a>, via Wikimedia Commons<\/em> <\/p>\n\n\n\n

Auf den zweiten Blick erinnert das Feature an den guten alten TMS Workflow<\/a>. <\/p>\n\n\n\n

Anlegen oder Verkn\u00fcpfen<\/strong> <\/h2>\n\n\n\n

Features lassen sich stand heute nur aus der \u00abFeatures Overview<\/em>\u00bb oder aus einem \u00abRequirement<\/em>\u00bb heraus anlegen, zus\u00e4tzlich kann man aus einer \u00abUser Story<\/em>\u00bb, und nur hier, auf genau ein Feature referenzieren. <\/p>\n\n\n\n

In einem Feature kann man wiederum nicht nur Transport Auftr\u00e4ge anlegen, sondern auch User Stories und Project Tasks.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Auch in ChaRM Change Documents konnte man Tasks (Vorgangsart 1003) als Nachfolge-Dokumente anlegen. <\/p>\n\n\n\n

Ich habe Kolleg:innen vorgef\u00fchrt, wie man damit zus\u00e4tzliche Team-Mitglieder in einen \u00c4nderungsvorgang einbinden k\u00f6nnte, statt sie per E-Mail zu kontaktieren, womit man ein holistisches Konzept des Change Documents etablieren w\u00fcrde, mit dem man eine sehr gute Dokumentation (Traceability<\/em>) erreichen k\u00f6nnte, aber dies wurde nie angenommen, es blieb bei den informalen E-Mails. <\/p>\n\n\n\n

Deshalb f\u00fcrchte ich, dass die M\u00f6glichkeit, Folge-Tasks anzulegen, auch im Feature brach liegen wird. <\/p>\n\n\n\n

Fehlerkorrektur beim Testen<\/strong><\/h2>\n\n\n\n

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

Zun\u00e4chst muss man das Feature anlegen:<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Erst dann kann man die URL des neuen Features in dem Test Defect als Referenz per Copy&Paste hinzuf\u00fcgen:<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

M\u00f6chte man in dem Feature dokumentieren, f\u00fcr welchen Defect man arbeitet, muss man diese Prozedur f\u00fcr die andere Richtung wiederholen (URL des Defects als Referenz im Feature), denn es gibt hier noch keine Automatik:<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Ich ahne schon, dass diese umst\u00e4ndliche manuelle Verlinkung auf keine grosse Akzeptanz stossen wird. <\/p>\n\n\n\n

Doch es besteht Hoffnung f\u00fcr Q2 2025<\/a>:<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Schau\u2019n mer mal! Dann sehn mer scho! <\/p>\n\n\n\n

Transporte<\/strong> <\/h2>\n\n\n\n

Im Unterschied zum ChaRM und eher in Anlehnung an Focused Build, sind Features immer an Cloud ALM Projekte gebunden. <\/p>\n\n\n\n

Diese Projekte referenzieren einen \u00abDeployment Plan<\/em>\u00bb, der einer ChaRM Change Control Landscape (CCL) \u00e4hnlich ist, und genau wie letztere enth\u00e4lt diese \u00abLandscape<\/em>\u00bb eine oder mehrere \u00abSystem Groups<\/em>\u00bb. Jede \u00abSystem Group<\/em>\u00bb enth\u00e4lt wiederum einen Track, was vormals Logische Systemkomponente genannt wurde. Damit k\u00f6nnen wie gehabt mehrere Tracks mit einem Change, oh, pardon, Feature bespielt werde. <\/p>\n\n\n\n

In unseren Beispielen verwenden wir ein Projekt \u00abMaintenance Project<\/em>\u00bb, das den fantasievoll benannten Plan \u00abDeployment Plan 2024<\/em>\u00bb verwendet, der wiederum nur eine System-Gruppe kennt, n\u00e4mlich die ebenso originell benamste \u00abBSS Maintenance<\/em>\u00bb. <\/p>\n\n\n\n

Unsere Demo-Landschaft auf dem OnPremise ABAP System hat zwei Tracks, einen Vier-Systeme-Track f\u00fcr Projekte (BSS.801 \ud83e\udc7a 803 \ud83e\udc7a 804 \ud83e\udc7a 805) und ein Drei-Systeme-Track f\u00fcr Wartung (BSS.811 \ud83e\udc7a 813 \ud83e\udc7a 805).  <\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Entsprechend ist auch das Wartungsprojekt in Cloud ALM definiert: <\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Das Gegenst\u00fcck w\u00e4re \u00abBSS Project<\/em>\u00bb, wird aber in unseren Beispielen nicht verwendet. <\/p>\n\n\n\n

Wir probieren eine Transportanlage aus<\/strong> <\/h2>\n\n\n\n

Unser Drehbuch: Wir m\u00f6chten niemanden auf unsere Entwicklungen aufmerksam machen, um Diskussionen zu vermeiden, daher belassen wir unser Feature im Status \u00abIn Specification<\/em>\u00bb und legen gleich Transporte an, denn es ist bereits in diesem Anfangsstatus m\u00f6glich! Um Transporte anzulegen, ben\u00f6tigt man die m\u00e4chtige \u00abProject Lead<\/em>\u00bb Rolle<\/a>, die ich nat\u00fcrlich deshalb erhalten habe. <\/p>\n\n\n\n

Eigenartig ist, dass – im Gegensatz zum ChaRM – man Transporte nur anlegen kann, wenn das Feature nicht<\/strong> im \u00c4nderungsmodus ist (siehe den aktiven Edit-Button<\/em>), und dieser Anlage-Button befindet im Feature-Kopf, als ob ein Transport eine Entit\u00e4t auf derselben Ebene wie User Stories usw. w\u00e4re. <\/p>\n\n\n\n

M\u00f6chte man hingegen einen existierenden Transport dem Feature hinzuf\u00fcgen, so muss man stattdessen in den Edit-Modus wechseln und dann zum \u00abTransports<\/em>\u00bb Abschnitt navigieren. <\/p>\n\n\n\n

Man gew\u00f6hnt sich dran. <\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Eigentlich w\u00e4re BSS~813 die richtige Wahl f\u00fcr den \u00abTarget<\/em>\u00bb des \u00abMaintenace Project<\/em>\u00bb, doch dessen \u00abDeployment Plan<\/em>\u00bb wird ignoriert und es wird das fremde Konsolidierungssystem BSS.803 als erstes angeboten. <\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Nun gut. Ich tue so, als ob ich so schusselig bin, wie ich es tats\u00e4chlich bin, wenn in Eile. <\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Ich \u00fcbersehe, dass das falsche Konsolidierungssystem f\u00fcr das Wartungs-Entwicklungssystem BSS.811 angeboten wird, und winke die Transport-Anlage durch. <\/p>\n\n\n\n

Auch habe ich \u00fcbersehen, dass es ein Feld \u00abOwner<\/em>\u00bb gibt, und haben es leer gelassen. Diesem Eingabefeld fehlte sowieso eine Wertehilfe f\u00fcr die m\u00f6glichen User-IDs aus dem Entwicklungssystem. <\/p>\n\n\n\n

Da im Cloud ALM nur ein Merker f\u00fcr eine Transportanlage angelegt wird, m\u00fcssen wir jetzt warten, bis die Batch-Jobs auf dem BSS.811 System endlich starten und die Aufgabe von Cloud ALM holen, ausf\u00fchren und das Ergebnis zur\u00fcckgeben. Hier heisst es, geduldig wiederholt auf den Refresh-Knopf zu dr\u00fccken: <\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Bald haben wir es geschafft: <\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Wir loggen uns in das Maintenance Entwicklungssystem ein und finden die Transporte zun\u00e4chst nicht in der Transaktion SE09. Denn es wurde, da wir das Kann-Feld \u00abOwner<\/em>\u00bb leer gelassen haben, der Eigent\u00fcmer des Batch-Jobs verwendet, bei uns \u00abBG_CALM<\/em>\u00bb:<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Kein grosses Problem, wenn wir die Berechtigung im Entwicklungssystem haben, den Eigent\u00fcmer eines Transports zu \u00e4ndern. <\/p>\n\n\n\n

Aber wenn wir mit den soeben angelegten Transporten arbeiten m\u00f6chten, stossen wir sofort auf Probleme:<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Der eigentlich f\u00fcr die Entwicklung vorgesehene Transport BSSK901892 wird nicht zur Auswahl angeboten, da er leider das falsche Ziel hat. <\/p>\n\n\n\n

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:<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Es ist besser, Transporte hinzuzuf\u00fcgen<\/strong> <\/h2>\n\n\n\n

Wegen dieser Fehleranf\u00e4lligkeit ist es meiner Meinung nach besser, w\u00e4hrend des Entwickelns und\/oder Customizing – wie zu R\/3-Zeiten – einen Transport aus der jeweiligen Anwendung heraus neu anzulegen:<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Der Vorteil ist, dass das Change and Transport System (CTS) alle Werte (Owner<\/em>, Target<\/em>) automatisch korrekt einsetzt: <\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Auch ben\u00f6tigt man hierzu keine so weitreichenden Berechtigungen wie bei der Anlage von Transporten (s.o.). <\/p>\n\n\n\n

Der hochfrequente Synchronisierungs-Job sendet diese Transportdaten an Cloud ALM, so dass sie bald sichtbar sind. Dies kann man zum Beispiel mit der \u00abTransport Analysis<\/em>\u00bb App \u00fcberpr\u00fcfen: <\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n
\"\"<\/figure>\n\n\n\n

Ist der neue Transport in Cloud ALM bekannt, k\u00f6nnen wir das Feature in den \u00c4nderungsmodus versetzen und den neuen Transport \u00abAssign<\/em>en\u00bb: <\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Gl\u00fccklicherweise bietet der Assign<\/em>-Dialog nur Transporte an, die den Source-Tenant<\/em> BSS~811 haben. <\/p>\n\n\n\n

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

Schwierige Ko-Existenz<\/strong> <\/h2>\n\n\n\n

Seit den Anfangszeiten des ChaRMs m\u00fcssen wir bei dessen korrekten Einrichtung den Zwang zum CTS-Projekt einschalten, damit die Projekt-Schalter f\u00fcr Transport-Aktionen es erzwingen, dass nur der ChaRM (oder Focused Build) Transporte anlegen, freigeben und importieren kann. <\/p>\n\n\n\n

Doch Cloud ALM wurde hier vereinfacht und kennt daher keine CTS-Projekte mehr. Also sollte man mit der Transaktion SE03 \ud83e\udc7a \u00abDisplay\/Change Request Attributes<\/em>\u00bb diesen Zwang zur Eingabe des SAP_CTS_PROJECTS wieder entfernen. <\/p>\n\n\n\n

Es gibt keinen \u00abSelective Data Transfer<\/em>\u00bb nach Cloud ALM f\u00fcr ChaRM und Focused Build. Man muss deren Zyklen abarbeiten und schliesslich beenden und w\u00e4hrenddessen Neues nur per Feature anlegen. <\/p>\n\n\n\n

Wollte man in dieser Phase der Ko-Existenz die strenge Governance im ChaRM beibehalten, m\u00fcsste 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? <\/p>\n\n\n\n

Ein Vorteil hat das Ignorieren der CTS-Projekte: Man kann einem Feature auch bereits freigegebene Transporte hinzuf\u00fcgen: <\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Testen mit Transport of Copies (ToC)<\/strong> <\/h2>\n\n\n\n

Im Unterschied zum Normal Change vom ChaRM (und Focused Build) ist das Testen im Konsolidierungssytem mit ToCs freiwillig. Man muss ausdr\u00fccklich den Button dr\u00fccken und die Quellen f\u00fcr die ToCs ausw\u00e4hlen: <\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Leider gibt es keine sichtbare R\u00fcckmeldung daf\u00fcr, dass man die Anlage von ToCs beauftragt hat; man sieht dies nur, wenn man die History \u00f6ffnet: <\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Erst wenn der Batch-Job im ABAP System seine Arbeit getan hat, werden die ToCs sichtbar. <\/p>\n\n\n\n

Wir stellen fest, dass die freundliche L\u00f6schung von leeren Transport-Tasks wie im ChaRM jetzt wieder fehlt: <\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Statusabh\u00e4ngigkeit der Transportaktivit\u00e4ten<\/strong> <\/h2>\n\n\n\n

In einem Feature heraus kann man je nach Status des Features folgende Transport-bezogene Aktivit\u00e4ten durchf\u00fchren: <\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Wie man sehen kann, ist nicht nur im Status \u00abIn Implementation<\/em>\u00bb, sondern auch im Status \u00abIn Testing<\/em>\u00bb alles erlaubt. Dies ist v\u00f6llig anders als in einem ChaRM Change Document, bei dem streng zwischen Entwicklung und Testen getrennt wurde. Mir ist die Begr\u00fcndung f\u00fcr diese hohen Freiheitsgrade nicht klar. <\/p>\n\n\n\n

Nehmen wir n\u00e4mlich an, der Tester hat die Funktion erfolgreich im ABAP QA-System getestet und geht dann im Hochgef\u00fchl des erlebten Erfolges in die Mittagspause, das Setzen des neuen Status \u00abSuccessfully Tested<\/em>\u00bb will er nach der Pause zusammen mit einer Tasse Kaffee machen. <\/p>\n\n\n\n

In der Zwischenzeit f\u00e4llt der Entwicklerin ein, dass sie etwas vergessen hatte; sie legt schnell einen Transport an, zeichnet die \u00c4nderung auf und schiebt die \u00c4nderung in das QA-System. <\/p>\n\n\n\n

Wie wird sichergestellt, dass der Tester diese nachtr\u00e4gliche \u00c4nderung mittestet, bevor er den Status setzt? <\/p>\n\n\n\n

Auch frage ich mich, in welchem Use Case ein Tester den erfolgreichen Test best\u00e4tigt, obwohl die Transporte noch \u00e4nderbar sind: <\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Ah, Fragen \u00fcber Fragen\u2026. <\/p>\n\n\n\n

Zur Produktion<\/strong> <\/h2>\n\n\n\n

Auch hier erlaubt das Feature, Transporte nur dann freizugeben, wenn es nicht im \u00c4nderungsmodus ist: <\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Im Unterschied zur Anlage von ToCs wird diese Aktion sofort im Feature sichtbar. <\/p>\n\n\n\n

Der Import in die Folgesysteme wird jetzt \u00abDeployment<\/em>\u00bb genannt. Dabei verh\u00e4lt sich Cloud ALM ganz anders als der ChaRM. <\/p>\n\n\n\n

Hat man, wie im Beispiel, eine Mischung aus Drei- und Vier-System-Landschaft, so muss man sich daran gew\u00f6hnen, dass Cloud ALM vom Produktivsystem r\u00fcckw\u00e4rts 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: <\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Sehr sch\u00f6n realisiert, finde ich, ist der schliessliche Massen-Import aus der \u00dcbersichtsseite heraus, falls man nach dem passenden Status filtert: <\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Das hat den Vorteil, dass der Import aller hier selektierten Transporte in das Produktivsystem gleichzeitig mit einem tp IMPORT SUBSET erfolgt. <\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Sehr ansprechend finde ich auch die analytische \u00abFeature Traceability\u00bb: <\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Einziger Wermuttropfen ist die Zusammenfassung von QA- und PreProd-System in einer Ikone: <\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Technische Handhabung von CTS-Transporten<\/strong> <\/h2>\n\n\n\n

Stand heute ist das Anlegen und\/oder Freigeben und Importieren eines OnPremise Transportauftrag vom Feature heraus asynchron. <\/p>\n\n\n\n

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\u00fchrt, und das Ergebnis in die Cloud hochl\u00e4dt. <\/p>\n\n\n\n

M\u00f6chte 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. <\/p>\n\n\n\n

Hier tracen wir die Anlage der ToCs von vorhin: <\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Aus dem Feature heraus gelangt man nicht an diese Protokolle. <\/p>\n\n\n\n

In Gespr\u00e4chen w\u00e4hrend des ALM Summit 2024 in Mannheim habe ich erfahren, dass in Zukunft eine direkte Verbindung zwischen den Features und dem OnPremise ABAP System \u00fcber den SAP Cloud Connector angeboten werden wird. <\/p>\n\n\n\n

Zusammenfassung<\/strong> <\/h2>\n\n\n\n

ChaRM und Focused Build sind innerhalb von zwanzig Jahren zur Leuchtturm-Anwendung des Solution Managers gereift und nat\u00fcrlich braucht Cloud ALM Zeit, um es mit diesem Riesen aufnehmen zu k\u00f6nnen:  <\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

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