{"id":39397,"date":"2025-03-21T13:40:38","date_gmt":"2025-03-21T12:40:38","guid":{"rendered":"https:\/\/www.blue.works\/?p=39397"},"modified":"2026-02-18T16:01:26","modified_gmt":"2026-02-18T15:01:26","slug":"alm-kaffeekranzchen-ix-features-mit-neuen-features-downgrade-protection","status":"publish","type":"post","link":"https:\/\/www.blue.works\/de\/alm-kaffeekranzchen-ix-features-mit-neuen-features-downgrade-protection\/","title":{"rendered":"ALM Kaffeekr\u00e4nzchen IX: Downgrade Protection\u00a0"},"content":{"rendered":"\n

Einleitung<\/h2>\n\n\n\n

Es ist eine hehre Aufgabe, den riesigen, in seiner breiten Funktionalit\u00e4t einmaligen, \u00fcber mehr als zwanzig Jahren gewachsenen SAP Solution Manager, liebevoll SolMan genannt, mit SAP Cloud ALM zu ersetzen.<\/p>\n\n\n\n

Ein Leuchtturm-Szenario des SolMans ist der ChaRM (Change Request Management). Als ChaRM-Experte beobachte ich nat\u00fcrlich das Werden der analogen Cloud ALM \u00abFeatures\u00bb, einen ersten Rundgang habe ich hier beschrieben<\/a>\u00a0. Und wie in der am Ende zitierten Roadmap angek\u00fcndigt, sind jetzt mit 2025\/Q1 zwei Transport-Checks, n\u00e4mlich die DGP (Downgrade Protection) und der Cross-Reference-Check geliefert worden.<\/p>\n\n\n\n

Wie wertvoll die DGP ist, falls man nicht dem industriellen Paradigma des ABAP CTS (Change and Transport System) Folge leisten kann, habe ich hier<\/a>\u00a0 verdeutlicht. Wir wollen uns daher auf diese neue Cloud ALM Funktionalit\u00e4t konzentrieren.<\/p>\n\n\n\n

Ich werde dabei an passenden Stellen den Cloud DGP mit dem DGP im Solution Manager vergleichen.<\/p>\n\n\n\n

Hier eine kurze Gegen\u00fcberstellung der \u00dcberpr\u00fcfungen in Cloud ALM und SolMan:<\/p>\n\n\n\n

SAP Solution Manager<\/mark><\/strong><\/td>Cloud ALM<\/mark><\/strong><\/td><\/tr>
CSOL Check<\/td>.\/.<\/td><\/tr>
Release Check<\/td>.\/.<\/td><\/tr>
 Predecessor Check<\/td>Potential Downgrade<\/td><\/tr>
Imminent Check<\/td>Imminent Downgrade<\/td><\/tr>
.\/.<\/td>Intrinsic Downgrade<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

Wie man sehen kann, fehlen noch die Cross System Object Lock (CSOL) \u00dcberpr\u00fcfungen. Neu ist der \u00abIntrinsic Downgrade\u00bb, der dann feuert, wenn mehr als ein Transport in einem Feature vorhanden ist, eins dieser Transporte aber ausserhalb vom Feature, manuell, in eine falsche Reihenfolge gebracht wurde (z.B. durch einen direkten Import in der STMS). Dazu sp\u00e4ter mehr.<\/p>\n\n\n\n

Die Einrichtung dieser wichtigen \u00dcberpr\u00fcfungen wird ausf\u00fchrlich in der SAP Hilfe<\/a> dokumentiert, sie soll daher hier nicht wiederholt werden.<\/p>\n\n\n\n

Die Implementierung der dort als Voraussetzung vorgegebenen Hinweise gestaltete sich bei dem ST-PI Stand 740 SP28 v\u00f6llig problemlos.<\/p>\n\n\n\n

Einschr\u00e4nkungen<\/h2>\n\n\n\n

Die oben zitierte SAP Help Seite erw\u00e4hnt, dass die zwei neuen Checks nur f\u00fcr Transporte durchgef\u00fchrt werden, die auf den Import in das Produktivsystem (hier production tenant genannt) warten oder bereits importiert worden sind (?!). Das ist eine gewichtige Einschr\u00e4nkung, denn es ist bekannt, dass die Kosten der Fehlerbehebung niedriger sind, wenn diese fr\u00fch erkannt werden (\u00ab10er-Regel der Fehlerkosten<\/a> \u00bb).<\/p>\n\n\n\n

Zu den Freuden der agilen Software-Entwicklung geh\u00f6rt, dass Funktionen nur scheibchenweise geliefert werden. Daher setzte ich meine ganze Hoffnung auf das von mir gr\u00fcn markierte Adverb aus dem SAP Help Text: «Transport checks are only possible for production systems. Pre-production and quality assurance systems are currently<\/mark><\/strong> <\/mark>not supported<\/em>.». Ich deduziere daher, dass bald auch das PreProd System in den Genuss dieser \u00dcberpr\u00fcfungen kommen wird (Eigentlich bin ich fast sicher, denn – ich gebe es zu -, ich habe einfach den Produktmanager gefragt<\/em>).<\/p>\n\n\n\n

Eine weitere Einschr\u00e4nkung, dass n\u00e4mlich das Produktivsystem das letzte System eines Transportweges sein muss, k\u00f6nnte eine \u00c4nderung der bestehenden Transportlandschaft erzwingen, es ist n\u00e4mlich beliebt, ein Schulungssystem als Belieferung durch das Produktivsystem einzurichten.<\/p>\n\n\n\n

Schlie\u00dflich, die Einschr\u00e4nkung, dass Quell-System und Ziel-System auf unterschiedlichen physischen Systemen residieren sollen, macht mir etwas Sorgen, denn ich habe nun mal nur ein einziges Sandbox-System mit unterschiedlichen Mandanten zum Spielen. Wir werden sehen\u2026. (Spoiler: es hat trotzdem alles funktioniert, zum Gl\u00fcck!)<\/p>\n\n\n\n

Ausblick<\/h2>\n\n\n\n

Zurzeit (Anfang M\u00e4rz 2025) sind diese \u00dcberpr\u00fcfungen nur innerhalb eines Features m\u00f6glich, doch ich kann in der Roadmap<\/a> sehen, dass sie bald f\u00fcr mehrere Features gleichzeitig m\u00f6glich sein werden:<\/p>\n\n\n\n

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

Ich bin mir fast sicher [auch hierzu habe ich einfach den Produktmanager gefragt<\/em>], dass so eine Block-\u00dcberpr\u00fcfung auch im Rahmen der frischen «Deployment» App<\/a> m\u00f6glich sein wird! Vermutlich verbirgt sie sich hinter dieser geheimnisvollen Roadmap-Ank\u00fcndigung f\u00fcr Q1 2026<\/a>.<\/p>\n\n\n\n

Praxis<\/a><\/h2>\n\n\n\n

Wir testen wie \u00fcblich auf unserem Sandbox-System BSS mit unterschiedlichen Mandanten:<\/p>\n\n\n\n

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

Erster DGP Test<\/h2>\n\n\n\n

Wir m\u00f6chten eine DGP Kollision innerhalb eines Feature erzeugen. Dazu legen wir ein Feature mit zwei Customizing Transporten an:<\/p>\n\n\n\n

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

Jetzt kitzeln wir etwas die Transporte.<\/p>\n\n\n\n

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

Diese Neuanlage wird in Transport BSSK901969 «6-60: RE DGP Check 1 – Two Transports: Older» aufgezeichnet:<\/p>\n\n\n\n

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

Wir exportieren diesen Transport, womit er nicht mehr \u00e4nderbar ist. Ergebnis:<\/p>\n\n\n\n

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

Jetzt \u00e4ndern wir den Eintrag und zeichnen diese \u00c4nderung in den Transport BSSK901967<\/a> «6-60: RE DGP Check 1 – Two Transports: Newer» auf:<\/p>\n\n\n\n

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

\u00dcbrigens taucht kein Warnungs-Popup auf, wie er sonst bei aktivem SolMan CSOL beim Speichern die Customizer informiert, in welchen weiteren Transporten derselbe Eintrag bereits aufgezeichnet ist. Wir sind gespannt, was in Q4 2005 als «Cross-system object lock foundation for retrofit»<\/a> kommen wird!<\/p>\n\n\n\n

Wir exportieren BSSK901967.<\/p>\n\n\n\n

Die Import-Reihenfolge f\u00fcr das QA-System BSS.803 ist korrekt:<\/p>\n\n\n\n

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

Da wir es sehr eilig haben, importieren wir BSSK901967 direkt in der STMS Import Queue \u2013 es gibt ja keine CTS Projektschalter mehr, die dies verhindern! Damit verletzen wir die Import-Reihenfolge auch der Folgesysteme!<\/p>\n\n\n\n

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

Man kann nat\u00fcrlich vertrauen, dass niemand einen solchen manuellen Eingriff vornimmt. Doch vielleicht sollte man es sich genau \u00fcberlegen, ob man nicht doch per Berechtigungskonzept die M\u00f6glichkeit stark einschr\u00e4nkt, direkt in der STMS Import Queue Importe zu starten.<\/p>\n\n\n\n

Wir deployen das Feature zwei Mal, es hat damit das PreProd System BSS.804 erreicht und wartet, in das Prod System BSS.805 importiert zu werden:<\/p>\n\n\n\n

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

Die DGP Falle steht bereit:<\/p>\n\n\n\n

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

Wir f\u00fchren den DGP-Check aus dem einzelnen Feature aus:<\/p>\n\n\n\n

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

Tadaa!<\/p>\n\n\n\n

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

Klickt man als feinmotorisch begabter Mensch genau auf die Zahl \u00ab2\u00bb (es befinden sich ja zwei Tabellen-Eintr\u00e4ge in den Transporten), so navigiert man in ein neues Fenster, das m.E. auf sehr gelungene Weise \u00fcber die Probleme informiert:<\/p>\n\n\n\n

<\/a><\/p>\n\n\n\n

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

Wie erwartet, wird hier der \u00abIntrinsic Downgrade\u00bb Fehler gemeldet.<\/p>\n\n\n\n

Zweiter DGP Test<\/h2>\n\n\n\n

Wir m\u00f6chten eine DGP Kollision zwischen zwei Features erzeugen. Dazu legen wir zwei Features mit je einem Customizing-Transport an:<\/p>\n\n\n\n

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

Wie vorhin, zeichnen wir unterschiedliche \u00c4nderungen mit dem gleichen Transportschl\u00fcssel in die zwei unterschiedlichen Transporte mit unterschiedlichen Inhalten.<\/p>\n\n\n\n

Hier nur ein Beispiel f\u00fcr die erste \u00c4nderung.<\/p>\n\n\n\n

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

Ich \u00fcberspringe jetzt die weiteren \u00c4nderungen, sie sind fast analog zum vorherigen Kapitel und komme zur entscheidenden Stelle, die die DGP \u00dcberpr\u00fcfung gestattet, diesmal verwenden wir die sch\u00f6ne \u00abTransport Analysis\u00bb App:<\/p>\n\n\n\n

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

Der \u00dcberholer (Transport BSSK901965) steht bereit:<\/p>\n\n\n\n

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

Wir starten den DGP Check in beiden Features fast gleichzeitig.<\/p>\n\n\n\n

Dieser Zustand als auch das Check-Ergebnis wird leider weder in der \u00abFeature Overview\u00bb, noch in der \u00abTransport Analysis\u00bb, noch in der ansonsten sehr ansprechenden \u00abFeature Traceability\u00bb angezeigt.<\/p>\n\n\n\n

Wir m\u00fcssen eins der zwei Features ausw\u00e4hlen und Refreshen st\u00e4ndig mit Geduld gewappnet den \u00abTransport Checks\u00bb Abschnitt mit dem Button \u00abrefresh\u00bb, bis der Job im ABAP System endlich gestartet ist und seinen Arbeitsauftrag durchgef\u00fchrt hat:<\/p>\n\n\n\n

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

Das Ergebnis ist interessant. Das Feature mit dem \u00dcberholer-Transport zeigt n\u00e4mlich keine Probleme an. Eigentlich h\u00e4tte ich hier erwartet, dass es den Fehler «Potential Downgrade» anzeigen w\u00fcrde.<\/p>\n\n\n\n

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

Nur im Feature, das einen Downgrade tats\u00e4chlich produzieren k\u00f6nnte, existiert eine rote Meldung, hier die entscheidenden Details:<\/p>\n\n\n\n

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

Doch so schlimm, wie es der \u00abImminent Downgrade\u00bb Langtext sagt, ist es nicht, denn beide Transporte sind ja noch nicht produktiv importiert worden. Wir k\u00f6nnen immer noch durch Einzel-Deploy der Features den korrekten Import durchf\u00fchren.<\/p>\n\n\n\n

Wir starten also den Deploy des Features \u00abRE DGP Check 2 – Older Transport\u00bb zuerst, warten bis der Import fertig ist, und starten dann den Deploy des neueren.<\/p>\n\n\n\n

So sah der Eintrag im PreProd System BSS.804 aus:<\/p>\n\n\n\n

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

Eindeutig ein Downgrade!<\/p>\n\n\n\n

Und so sieht der Eintrag im Produktivsystem BSS.805 aus, dank unseres vorsichtigen Verhaltens:<\/p>\n\n\n\n

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

Nat\u00fcrlich fragt man sich, was denn im PreProd System getestet wurde, aber das steht auf einem anderen Blatt.<\/p>\n\n\n\n

Bewertung<\/h2>\n\n\n\n

Der DGP Check funktioniert im Grossen und Ganzen gut. Wir fragen uns, ob das Ausfallen der Fehlermeldung \u00abPotential Downgrade\u00bb bei dem Feature \u00abRE DGP Check 2 – Newer Transport\u00bb eher ein Bug sein k\u00f6nnte.<\/p>\n\n\n\n

Das lange Warten auf die Ergebnisse des asynchronen Aufrufs k\u00f6nnte die Akzeptanz mindern. Ich habe noch nicht die Hoffnung aufgegeben, dass mein Verbesserungsvorschlag \u00abDirect CTS Transport Handling by Feature via Cloud Connector<\/a>\u00bb, endlich angenommen wird.<\/p>\n\n\n\n

Zwei SAP Solution Manager F\u00e4higkeiten fehlen noch:<\/p>\n\n\n\n