{"id":43476,"date":"2025-11-28T16:17:47","date_gmt":"2025-11-28T15:17:47","guid":{"rendered":"https:\/\/www.blue.works\/?p=43476"},"modified":"2026-03-16T09:04:12","modified_gmt":"2026-03-16T08:04:12","slug":"alm-kaffeekraenzchen-x-berechtigungen-bei-hybrider-transportsteuerung","status":"publish","type":"post","link":"https:\/\/www.blue.works\/de\/alm-kaffeekraenzchen-x-berechtigungen-bei-hybrider-transportsteuerung\/","title":{"rendered":"ALM Kaffeekr\u00e4nzchen X – Berechtigungen bei hybrider Transportsteuerung"},"content":{"rendered":"\n

Es gibt viele M\u00f6glichkeiten, sein Leben aufs Spiel zu setzen<\/a>. <\/p>\n\n\n\n

Man kann zum Beispiel sich dem legend\u00e4ren Irland-Korrespondenten<\/a> der TAZ in den Weg stellen<\/a>, wenn im Pub die Glocke f\u00fcr die letzte Bestellung l\u00e4utet. Brenzliger wird es, wenn man in Rom die Spaghetti f\u00fcr eine Carbonara<\/a> bricht, um dann \u2013 Kapitalverbrechen! – Sahne in die Sosse zu giessen! Sehr unangenehm wird es auch, wenn man von einem Handwerker h\u00f6chste Qualit\u00e4t verlangt, ihm aber die Werkzeuge seiner Wahl verweigert<\/a>. <\/p>\n\n\n\n

In unserer SAP ABAP Welt sind Transportantr\u00e4ge 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\u00fcssen wir tun, um einen stringenten Transport-Workflow zu haben. <\/p>\n\n\n\n

Die Zeit vor dem ChaRM <\/h2>\n\n\n\n

Im Altertum der R\/3 Entwicklung war es die Aufgabe der hierzu berechtigten Projektleitung, Transportantr\u00e4ge anzulegen, um dann f\u00fcr 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<\/a>. <\/p>\n\n\n\n

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

Dies war das paradiesische Reich der Freiheit f\u00fcr die Entwicklung, und es war die Chaos-H\u00f6lle f\u00fcr die Administratoren und CCOE-Verantwortlichen.<\/p>\n\n\n\n

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

Denn nun kamen hochbezahlte Revisoren ins Haus, die die Importhistorie des Produktivsystems \u00f6ffneten und mit rhabdomantischer Sicherheit ihr Fingerchen auf einen Transport legten und die einfache Frage stellten, wer diese \u00c4nderung genehmigt habe, wer vom Business ihn getestet und f\u00fcr die Produktion freigegeben habe, und wer ihn in die Produktion importiert habe: Siehe da, es war ein sensibler FI-Transport. Die Revisoren freuen sich \u00fcber ihren Treffer: Ein Finding<\/em>! Die Leitung der Anwendungsentwicklung hingegen erbleicht: Das Testat ist gef\u00e4hrdet, ein Karriereknick droht. <\/p>\n\n\n\n

Das Reich des ChaRMs <\/h2>\n\n\n\n

Nach einem Interregnum von Ordnern voller gedruckter und unterschriebener Formulare, bei denen niemand so schnell etwas finden, aber mit denen wenigstens die Revision bes\u00e4nftigt werden konnte, frei nach dem Motto: Hauptsache, sie bekommen viel Papier in die Hand, wurde Anfang 2005 der ChaRM im SAP Solution Manager eingef\u00fchrt<\/a>. <\/p>\n\n\n\n

Jetzt \u00fcbernahm der ChaRM die Rolle der Projektleitung bei der Anlage und der Freigabe von Transporten. Nur die T\u00e4tigkeit, die jeweiligen Transportaufgaben freizugeben und so dem neuen elektronischen Projektleiter das Ende der Entwicklung zu signalisieren, blieb bei der Entwicklung. <\/p>\n\n\n\n

Aber was f\u00fcr Diskussionen! Denn in einem unter ChaRM-Verwaltung stehenden Quell-System kann man nicht mehr mit den antiken Transport Organizer Transaktionen SE09\/SE10<\/a> Transportantr\u00e4ge anlegen, obwohl man von alters her die Berechtigung dazu h\u00e4tte. <\/p>\n\n\n\n

Jetzt zwingt n\u00e4mlich das Transport-Attribut SAP_CTS_PROJECT f\u00fcr den Arbeits-Mandanten, so ein CTS-Projekt bei Transportanlage anzugeben, und gleichzeitig sorgt der b\u00f6se, hinterlistige ChaRM-Administrator, dass die Projektschalter f\u00fcr Anlage, Freigabe und Import von Transporten immer brav geschlossen sind, womit verhindert wird, dass man am ChaRM vorbei transportieren kann. <\/p>\n\n\n\n

Jede ChaRM-Novizin murrt und grummelt und beschimpft diesen Zwang als eine Arbeitsbehinderung. Nun ja, als ChaRM Einf\u00fchrer und Verantwortlicher lernt man, geduldig aber hartleibig<\/a> zu werden. <\/p>\n\n\n\n

Nat\u00fcrlich: Intern \u00f6ffnet der ChaRM bei transportrelevanten Statuswechsel die Projektschalter, f\u00fchrt die jeweilige Transport-Aktion aus und schliesst die Schalter schnell wieder. Manchmal verheddert sich dieser \u00d6ffnen-Schliessen-Mechanismus, wenn bei mehreren fast-gleichzeitig arbeitenden Anwendern diese Aktionen sich \u00fcberlappen, doch meistens geht es gut. <\/p>\n\n\n\n

Leider hat es sich herumgesprochen, wie einfach es sei, diese Projektschalter zu manipulieren. In der Regel begn\u00fcgen sich die Verantwortlichen vom CCOE damit, wie im SAP Hinweis 2207598 \u201eWhat log shows the user who changed CTS Project Status Switch setting for a ChaRM project? – Solution Manager\u201c<\/a> beschrieben, zu ermitteln, wer es diesmal gewesen ist, um dann mit wedelndem Du-Du-Finger eine Predigt zu halten. Doch \u2013 frei nach Hegel \u2013 der Heilige Antonius von Padova hat mehr erreicht, als er zu den Fischen predigte. <\/p>\n\n\n\n

Zu einer Reform der Berechtigungsrollen hat sich eigenartigerweise niemand durchringen k\u00f6nnen. Denn die Erfahrung lehrt, dass eine solche \u00c4nderung einer Herakles Tat gleich kommt.<\/p>\n\n\n\n

\"\"
«Herkules b\u00e4ndigt den minoischen Stier», Statue an der Orangerie am Schloss – Schwerin, 26.2.2012<\/figcaption><\/figure>\n\n\n\n

Die Zeit nach dem ChaRM <\/h2>\n\n\n\n

Der grosse, m\u00e4chtige ChaRM (und seine Sch\u00f6nwetter-Sonntagsversion Focused Build) hat jetzt einen jungen Nachfolger in Cloud ALM gefunden, das Feature. <\/p>\n\n\n\n

Da das Feature keine CTS-Projekte mehr kennt, muss man im ABAP Entwicklungssystem den Zwang zum Setzen des SAP_CTS_PROJECT Attributs zur\u00fccknehmen, womit das Tor zur w\u00e4rmenden alten Beliebigkeit und dem kalten Chaos wieder ge\u00f6ffnet wird. <\/p>\n\n\n\n

Ich habe seinerzeit in meinem \u00abALM Kaffeekr\u00e4nzchen VIII<\/a>\u00bb wegen der Fehleranf\u00e4lligkeit 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 \u00abOwner\u00bb Angabe die Transporte unter dem System-Benutzer angelegt werden, der die Synchronisationsjobs durchf\u00fchrt.<\/p>\n\n\n\n

Es gab mittlerweile eine kleine Verbesserung. Das omin\u00f6se Eingabefeld \u00abOwner\u00bb ist jetzt ein Muss-Feld, doch der Inhalt wird immer noch nicht \u00fcberpr\u00fcft.<\/p>\n\n\n\n

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

Solange das Feature keine Wertehilfe f\u00fcr den \u00abOwner\u00bb anbietet und eine beliebige Auswahl des \u00abTargets\u00bb erlaubt, befinden wir uns in einem Dilemma! <\/p>\n\n\n\n

M\u00f6chte man eher die Fehleranf\u00e4lligkeit 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. <\/p>\n\n\n\n

M\u00f6chte man hingegen das Chaos vermeiden, das gem\u00e4ss langj\u00e4hriger 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\u00e4lligkeit in Kauf nehmen. <\/p>\n\n\n\n

Doch dieses Dilemma ist nur vor\u00fcbergehend, denn SAP wird im Laufe von 2026 die L\u00fccken bei der Transportanlage im Feature schliessen, und dann kann man ohne Risiko die Anlage und Freigabe von Transporten nur aus dem Feature heraus erzwingen. <\/p>\n\n\n\n

Tuning der Berechtigungsrollen <\/h2>\n\n\n\n

Man k\u00f6nnte jetzt das Transport-Attribut CALM_CDM_FEATURE_ID, das mit Hinweis 3322679 \u00ab SAP Cloud ALM – CDM: Master Note up to ST-PI SP 24\u00bb<\/a> eingef\u00fchrt wurde, f\u00fcr den Arbeitsmandanten auf Obligatorisch setzen: <\/p>\n\n\n\n

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

Jetzt kann man ein Transport immer noch anlegen, doch nicht mehr freigeben: <\/p>\n\n\n\n

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

Doch der Langtext der Fehlermeldung verr\u00e4t, wie man hier doch noch sich am Feature vorbeischummeln kann, denn das Flag \u00abAttribute assigned externally\u00bb (siehe oben) ist nicht gesetzt: <\/p>\n\n\n\n

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

Unabh\u00e4ngig, ob man sich schon jetzt f\u00fcr den Feature-Zwang entscheidet, oder ob man lieber warten m\u00f6chte, bis die L\u00fccken geschlossen werden, man wird daher auf jeden Fall die Berechtigungsrollen anpassen m\u00fcssen. <\/p>\n\n\n\n

Die zwei Berechtigungsobjekte, die die Anlage und die Freigabe von Transporten steuern, sind S_TRANSPRT und S_SYS_RWBO, das zus\u00e4tzlich eine Feinsteuerung nach einzelnen Systemen erlaubt. <\/p>\n\n\n\n

Da S_SYS_RWBO genau die gleichen Werte f\u00fcr 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\u00e4tzlich in S_SYS_RWBO nach, ob eine Aktion f\u00fcr das jeweilige System nicht doch erlaubt sei. Man muss also immer beide pflegen. <\/p>\n\n\n\n

Zun\u00e4chst muss man mit der Transaktion SUIM alle Rollen suchen, die S_TRANSPRT mit ACTVT=01 \u00abAnlegen\u00bb oder =43 \u00abFreigeben\u00bb haben. Um die Ergebnisliste auf die tats\u00e4chlich verwendeten Rollen einzuschr\u00e4nken, kann man die eher selten in Anspruch genommenen erweiterten Selektionsm\u00f6glichkeiten einblenden: <\/p>\n\n\n\n

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

E voila!<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n
    \n
  1. Namensraum der Rollen: Wir wollen alle Rollen sehen<\/li>\n<\/ol>\n\n\n\n
      \n
    1. Wir wollen nur Einzelrollen sehen, um die geht es n\u00e4mlich <\/li>\n<\/ol>\n\n\n\n
        \n
      1. Hier sollte man passende User eintragen, die tats\u00e4chlich im Team die Rolle Entwicklerin\/Customizer haben <\/li>\n<\/ol>\n\n\n\n
          \n
        1. DTRA=Workbench, CUST=Customizing <\/li>\n<\/ol>\n\n\n\n
            \n
          1. 01=Anlage, 43=Freigabe <\/li>\n<\/ol>\n\n\n\n

            Das Ergebnis auf unserem Sandbox-System:<\/p>\n\n\n\n

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

            Einige Beschreibungen der Aktionen in der PFCG-Wertehilfe sind verwirrend. Wer w\u00fcrde zum Beispiel vermuten, dass ACTVT=75 \u00abRemove\u00bb bedeutet, dass man den Transport eines anderen Anwenders freigeben kann? Eine erg\u00e4nzende Erkl\u00e4rung der in Frage kommenden Werte f\u00fcr die Aktionen befindet sich hier<\/a>. <\/p>\n\n\n\n

            Voschlag <\/h2>\n\n\n\n

            F\u00fcr Workbench und Customizing Transporte w\u00fcrde ich diese Berechtigungen vorschlagen:<\/p>\n\n\n\n

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

            Man kann sehen, dass ich das L\u00f6schen nicht erlauben w\u00fcrde \u2013 denn Stand heute (Oktober 2025) merkt Cloud ALM es nicht, wenn Transporte wieder gel\u00f6scht wurden. Und man kann leider keine Transporte aus der Replikationsliste in Cloud ALM entfernen. <\/p>\n\n\n\n

            Bei den Transportaufgaben (TTYPE=TASK) ben\u00f6tigt man mehr Freiheiten, da w\u00fcrde ich folgende Berechtigungen vorschlagen:<\/p>\n\n\n\n

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

            Transport of Copies (ToCs) (TTYPE=TRAN) k\u00f6nnen aus dem Feature heraus erzeugt werden. Eigentlich w\u00e4ren hier keine OnPremise Berechtigungen notwendig. <\/p>\n\n\n\n

            Doch die Erfahrung lehrt, dass es oft besser ist, bei umfangreichen Transporten, die beim Import in das QA-System sehr viel Zeit ben\u00f6tigen, nur die ge\u00e4nderten Transportaufgaben per ToC in das QA-System zu transportieren. <\/p>\n\n\n\n

            Da es in Cloud ALM keine Unterst\u00fctzung f\u00fcr solche Delta-Transporte gibt, k\u00f6nnte man dieselben Berechtigungen f\u00fcr Aufgaben auch f\u00fcr die Handhabe von ToCs vergeben. <\/p>\n\n\n\n

            With a little help from my friends<\/a> <\/h2>\n\n\n\n

            Es folgen einige sehr interessante Verbesserungsvorschl\u00e4ge, die dringend notwendige aber immer noch fehlende F\u00e4higkeiten adressieren, mit der Bitte, bei Interesse sie zu \u00abvoten<\/em>\u00bb. Eine g\u00fcltige S-Nummer ist hierzu notwendig. <\/p>\n\n\n\n