ALM Kaffeekränzchen X – Berechtigungen bei hybrider Transportsteuerung
Es gibt viele Möglichkeiten, sein Leben aufs Spiel zu setzen.
Man kann zum Beispiel sich dem legendären Irland-Korrespondenten der TAZ in den Weg stellen, wenn im Pub die Glocke für die letzte Bestellung läutet. Brenzliger wird es, wenn man in Rom die Spaghetti für eine Carbonara bricht, um dann – Kapitalverbrechen! – Sahne in die Sosse zu giessen! Sehr unangenehm wird es auch, wenn man von einem Handwerker höchste Qualität verlangt, ihm aber die Werkzeuge seiner Wahl verweigert.
In unserer SAP ABAP Welt sind Transportanträge das Werkzeug, mit dem Entwickler ihre Arbeit aufzeichnen, um sie in die Richtung des Produktivsystem zu schicken. Sie daran zu hindern, diese Transporte selbst anzulegen, erzeugt daher immer einen Tsunami an Protesten. Doch genau das müssen wir tun, um einen stringenten Transport-Workflow zu haben.
Die Zeit vor dem ChaRM
Im Altertum der R/3 Entwicklung war es die Aufgabe der hierzu berechtigten Projektleitung, Transportanträge anzulegen, um dann für jede Entwicklerin eine Aufgabe einzurichten. War die Entwicklerin fertig, so signalisierte sie dies, indem sie die ihr zugewiesene Aufgabe freigab. Waren alle Aufgaben freigegeben, konnte die Projektleitung endlich den Transport selbst freigeben, womit die Kernel-Programme tp und R3trans loslegten und gesteuert von den Transportobjekten die Datenbank auslasen und in eine Archivdatei auf Platte schrieben.
Doch diese Arbeitsteilung hielt dem Sturm der Entwicklerinnen nicht stand, und ziemlich rasch bekamen alle Entwicklerinnen und Customizer die Berechtigung, selbst Transporte anzulegen und freizugeben.
Dies war das paradiesische Reich der Freiheit für die Entwicklung, und es war die Chaos-Hölle für die Administratoren und CCOE-Verantwortlichen.
Nicht nur lagen hunderte von Transporten im Entwicklungssystem herum, von denen niemand mehr wusste, was sie sollten – ich habe mehr als einmal assistiert, ein vollkommen verhunztes Entwicklungssystem aus einer Datenbank-Kopie des QA-Systems wieder aufzubauen -. Nicht nur hingen hunderte von Transporten in den Import-Warteschlangen der Folgesysteme herum, von denen niemand mehr wusste, wer wann was warum diese Transporte in Richtung Produktion geschickt hat und wieso sie liegen blieben.
Denn nun kamen hochbezahlte Revisoren ins Haus, die die Importhistorie des Produktivsystems öffneten und mit rhabdomantischer Sicherheit ihr Fingerchen auf einen Transport legten und die einfache Frage stellten, wer diese Änderung genehmigt habe, wer vom Business ihn getestet und für die Produktion freigegeben habe, und wer ihn in die Produktion importiert habe: Siehe da, es war ein sensibler FI-Transport. Die Revisoren freuen sich über ihren Treffer: Ein Finding! Die Leitung der Anwendungsentwicklung hingegen erbleicht: Das Testat ist gefährdet, ein Karriereknick droht.
Das Reich des ChaRMs
Nach einem Interregnum von Ordnern voller gedruckter und unterschriebener Formulare, bei denen niemand so schnell etwas finden, aber mit denen wenigstens die Revision besänftigt werden konnte, frei nach dem Motto: Hauptsache, sie bekommen viel Papier in die Hand, wurde Anfang 2005 der ChaRM im SAP Solution Manager eingeführt.
Jetzt übernahm der ChaRM die Rolle der Projektleitung bei der Anlage und der Freigabe von Transporten. Nur die Tätigkeit, die jeweiligen Transportaufgaben freizugeben und so dem neuen elektronischen Projektleiter das Ende der Entwicklung zu signalisieren, blieb bei der Entwicklung.
Aber was für Diskussionen! Denn in einem unter ChaRM-Verwaltung stehenden Quell-System kann man nicht mehr mit den antiken Transport Organizer Transaktionen SE09/SE10 Transportanträge anlegen, obwohl man von alters her die Berechtigung dazu hätte.
Jetzt zwingt nämlich das Transport-Attribut SAP_CTS_PROJECT für den Arbeits-Mandanten, so ein CTS-Projekt bei Transportanlage anzugeben, und gleichzeitig sorgt der böse, hinterlistige ChaRM-Administrator, dass die Projektschalter für Anlage, Freigabe und Import von Transporten immer brav geschlossen sind, womit verhindert wird, dass man am ChaRM vorbei transportieren kann.
Jede ChaRM-Novizin murrt und grummelt und beschimpft diesen Zwang als eine Arbeitsbehinderung. Nun ja, als ChaRM Einführer und Verantwortlicher lernt man, geduldig aber hartleibig zu werden.
Natürlich: Intern öffnet der ChaRM bei transportrelevanten Statuswechsel die Projektschalter, führt die jeweilige Transport-Aktion aus und schliesst die Schalter schnell wieder. Manchmal verheddert sich dieser Öffnen-Schliessen-Mechanismus, wenn bei mehreren fast-gleichzeitig arbeitenden Anwendern diese Aktionen sich überlappen, doch meistens geht es gut.
Leider hat es sich herumgesprochen, wie einfach es sei, diese Projektschalter zu manipulieren. In der Regel begnügen sich die Verantwortlichen vom CCOE damit, wie im SAP Hinweis 2207598 „What log shows the user who changed CTS Project Status Switch setting for a ChaRM project? – Solution Manager“ beschrieben, zu ermitteln, wer es diesmal gewesen ist, um dann mit wedelndem Du-Du-Finger eine Predigt zu halten. Doch – frei nach Hegel – der Heilige Antonius von Padova hat mehr erreicht, als er zu den Fischen predigte.
Zu einer Reform der Berechtigungsrollen hat sich eigenartigerweise niemand durchringen können. Denn die Erfahrung lehrt, dass eine solche Änderung einer Herakles Tat gleich kommt.
Die Zeit nach dem ChaRM
Der grosse, mächtige ChaRM (und seine Schönwetter-Sonntagsversion Focused Build) hat jetzt einen jungen Nachfolger in Cloud ALM gefunden, das Feature.
Da das Feature keine CTS-Projekte mehr kennt, muss man im ABAP Entwicklungssystem den Zwang zum Setzen des SAP_CTS_PROJECT Attributs zurücknehmen, womit das Tor zur wärmenden alten Beliebigkeit und dem kalten Chaos wieder geöffnet wird.
Ich habe seinerzeit in meinem «ALM Kaffeekränzchen VIII» wegen der Fehleranfälligkeit bei der Transportanlage aus dem Feature heraus empfohlen, Transporte in dem ABAP-System anzulegen und dann dem Feature zuzuordnen. So vermeidet man die Verwirrung die entsteht, wenn bei falscher «Owner» Angabe die Transporte unter dem System-Benutzer angelegt werden, der die Synchronisationsjobs durchführt.
Es gab mittlerweile eine kleine Verbesserung. Das ominöse Eingabefeld «Owner» ist jetzt ein Muss-Feld, doch der Inhalt wird immer noch nicht überprüft.
Solange das Feature keine Wertehilfe für den «Owner» anbietet und eine beliebige Auswahl des «Targets» erlaubt, befinden wir uns in einem Dilemma!
Möchte man eher die Fehleranfälligkeit bei der Transportanlage aus dem Feature heraus vermeiden, sollte man, wie seinerzeit vorgeschlagen, Transporte im System anlegen und sie danach dem Feature zuordnen. Die Transporte werden somit automatisch dem korrekten Benutzer zugeordnet und zielen auf das korrekte System. Doch es besteht ein gewisses Risiko, dass Chaos entsteht.
Möchte man hingegen das Chaos vermeiden, das gemäss langjähriger schmerzhafter Erfahrung entsteht, wenn jeder Transporte anlegen darf, muss man die Anlage der Transporte nur aus dem Feature heraus erzwingen und die zurzeit leider vorhandene Fehleranfälligkeit in Kauf nehmen.
Doch dieses Dilemma ist nur vorübergehend, denn SAP wird im Laufe von 2026 die Lücken bei der Transportanlage im Feature schliessen, und dann kann man ohne Risiko die Anlage und Freigabe von Transporten nur aus dem Feature heraus erzwingen.
Tuning der Berechtigungsrollen
Man könnte jetzt das Transport-Attribut CALM_CDM_FEATURE_ID, das mit Hinweis 3322679 « SAP Cloud ALM – CDM: Master Note up to ST-PI SP 24» eingeführt wurde, für den Arbeitsmandanten auf Obligatorisch setzen:
Jetzt kann man ein Transport immer noch anlegen, doch nicht mehr freigeben:
Doch der Langtext der Fehlermeldung verrät, wie man hier doch noch sich am Feature vorbeischummeln kann, denn das Flag «Attribute assigned externally» (siehe oben) ist nicht gesetzt:
Unabhängig, ob man sich schon jetzt für den Feature-Zwang entscheidet, oder ob man lieber warten möchte, bis die Lücken geschlossen werden, man wird daher auf jeden Fall die Berechtigungsrollen anpassen müssen.
Die zwei Berechtigungsobjekte, die die Anlage und die Freigabe von Transporten steuern, sind S_TRANSPRT und S_SYS_RWBO, das zusätzlich eine Feinsteuerung nach einzelnen Systemen erlaubt.
Da S_SYS_RWBO genau die gleichen Werte für die Felder ACTVT und TTYPE bietet, konzentriere ich mich hier auf das Objekt S_TRANSPRT, doch aufgepasst! Wenn S_TRANSPRT nur die Anzeige (ACTVT=03) erlaubt, schaut das System zusätzlich in S_SYS_RWBO nach, ob eine Aktion für das jeweilige System nicht doch erlaubt sei. Man muss also immer beide pflegen.
Zunächst muss man mit der Transaktion SUIM alle Rollen suchen, die S_TRANSPRT mit ACTVT=01 «Anlegen» oder =43 «Freigeben» haben. Um die Ergebnisliste auf die tatsächlich verwendeten Rollen einzuschränken, kann man die eher selten in Anspruch genommenen erweiterten Selektionsmöglichkeiten einblenden:
E voila!
- Namensraum der Rollen: Wir wollen alle Rollen sehen
- Wir wollen nur Einzelrollen sehen, um die geht es nämlich
- Hier sollte man passende User eintragen, die tatsächlich im Team die Rolle Entwicklerin/Customizer haben
- DTRA=Workbench, CUST=Customizing
- 01=Anlage, 43=Freigabe
Das Ergebnis auf unserem Sandbox-System:
Einige Beschreibungen der Aktionen in der PFCG-Wertehilfe sind verwirrend. Wer würde zum Beispiel vermuten, dass ACTVT=75 «Remove» bedeutet, dass man den Transport eines anderen Anwenders freigeben kann? Eine ergänzende Erklärung der in Frage kommenden Werte für die Aktionen befindet sich hier.
Voschlag
Für Workbench und Customizing Transporte würde ich diese Berechtigungen vorschlagen:
Man kann sehen, dass ich das Löschen nicht erlauben würde – denn Stand heute (Oktober 2025) merkt Cloud ALM es nicht, wenn Transporte wieder gelöscht wurden. Und man kann leider keine Transporte aus der Replikationsliste in Cloud ALM entfernen.
Bei den Transportaufgaben (TTYPE=TASK) benötigt man mehr Freiheiten, da würde ich folgende Berechtigungen vorschlagen:
Transport of Copies (ToCs) (TTYPE=TRAN) können aus dem Feature heraus erzeugt werden. Eigentlich wären hier keine OnPremise Berechtigungen notwendig.
Doch die Erfahrung lehrt, dass es oft besser ist, bei umfangreichen Transporten, die beim Import in das QA-System sehr viel Zeit benötigen, nur die geänderten Transportaufgaben per ToC in das QA-System zu transportieren.
Da es in Cloud ALM keine Unterstützung für solche Delta-Transporte gibt, könnte man dieselben Berechtigungen für Aufgaben auch für die Handhabe von ToCs vergeben.
With a little help from my friends
Es folgen einige sehr interessante Verbesserungsvorschläge, die dringend notwendige aber immer noch fehlende Fähigkeiten adressieren, mit der Bitte, bei Interesse sie zu «voten». Eine gültige S-Nummer ist hierzu notwendig.
Und hier ein Verbesserungsvorschlag, der zum Thema passt, der aber leider abgelehnt wurde:
