Systemaufrischung, ChaRM, Arbeitsmodus und Lebenszyklusstatus

Frage: Es ist bei uns eine Systemaufrischung mittels Systemkopie PRD -> QAS geplant. Laut SAP-Hinweis 885343 ist in der LMDB der Lebenszyklusstatus von „Aktiv“ auf „Inaktiv“ zu ändern. Laut Dokumentation zum Lebenszyklusstatus soll stattdessen der Arbeitsmodus im Work Mode Management geändert werden. Was denn nun? Reicht eines oder besser beides?

Antwort: Beides.

Details:

Der SAP Solution Manager bestand früher aus vielen einzelnen Funktionalität die gar nicht oder schlecht miteinander integriert waren. Teilweise ist das ja immer noch so.

‎Das Work Mode Management hieß früher Downtime Management und war ein Bestandteil der Technical Administration (früher Central System Administration). Diese Funktionalität nutzte schon immer den IT-Kalender und gehörte thematisch zum ALM-Prozess Technical Operation. Dort ist auch das Technical Monitoring angesiedelt. Später kamen noch weitere Monitorings, das Job Scheduling Management, das Service Level Management etc. hinzu, welche teilweise willkürlich dem Business Process Operations zugeordnet wurden (warum gehört das Job Scheduling Management zum BPO aber das End-User Experience Monitoring zum TO?). Später wurden die verschiedenen Monitore in der Monitoring und Alerting Infrastructure (MAI) vereinheitlicht. Aus dieser Historie heraus ist auch verständlich, dass das Monitoring und SLA-Management die Work Modes berücksichtigt, um das Auslösen von Alerts temporär zu unterbinden, Jobs temporär auszuplanen oder geplante Downtimes in der SLA-Berechnung zu berücksichtigen.

Ein völlig unabhängiger Solman-Zweig ist das ChaRM. Dieses hat schon immer eine hohe Integration in das TMS und das Landscape Management. Vor der LMDB gab es ja die SMSY (Solution Manager System ‎Administration Database oder so ähnlich). Dort gab es ein Flag „Temporary Inactive“ welches beim Umbau zur LMDB durch den Lifecyclestatus abgelöst wurde. Aus dieser Historie heraus ist verständlich, dass ChaRM den Lifecyclestatus verwendet, um zu erkennen, dass ein Nutzen der RFC-Verbindungen (READ, TWM, TRUSTED) temporär nicht möglich ist und folglich alle Funktionen mit Bezug zum Managed System nicht ausführbar sind.

Tatsächlich wird der Lifecyclestatus benötigt. Ich habe Fälle erlebt, in denen ein System nicht verfügbar war und eine RFC-Destination echt eingefroren ist, statt einen Fehler zu werfen. Das würde dann dazu führen, dass ChaRM einfriert, also hängen bleibt. Und genau das verhindert der Lifecycle-Status.

Der Lifecyclestatus hat übrigens noch eine weitere Funktion. Wenn eine Systemlandschaft aufgebaut wird, dann sind ja einige Systeme nicht von Anfang an da. Da man aber diese Systeme bereits für verschiedene Funktionen wie Transportwesen (Sammeln von Transporten in Importqueue) oder Solution Dokumentation (Dokumentieren von Testfällen) benötigt, legt man die im TMS als virtuelles System und in der LMDB mit Lifecyclestatus „Planned“ an. Die Wirkung ist die selber wie Inaktiv: RFC-Destinationen werden sofern überhaupt existent, nicht genutzt und das Fehlen der RFC-Destinationen‎ wird nicht angemeckert. Eine äquivalente Funktion im Work Mode Management gibt es nicht.

Mittlerweile werden die Features immer mehr integriert. Der IT-Kalender wird mittlerweile von ChaRM genutzt und die Guided Procedure welche ursprünglich für SOLMAN_SETUP entwickelt wurde, dann für das Monitoring entdeckt wurde, wird mittlerweile auch von ITSM verwendet.

Eine Zusammenführung‎ von Work Mode und Lifecyclestatus ist mir jedoch nicht bekannt. Und wie ich SAP SE kenne finden die dafür eine super Begründung: Ein Administrator möchte eine Wartung durchführen. Hierfür plant er im Work Mode Management eine Downtime, um während dieser Zeit Jobs zu suspendieren, Alerts abzuschalten, User-Logins zu deaktivieren und vor allem um die Downtime für das SLA-Management als geplante Downtime zu dokumentieren. Teil der Wartung ist auch das Einspielen von Support Packages und das Transportieren von Transporten. Hierfür wird ChaRM genutzt. Während eines kleinen Zeitfensters wird das System dann tatsächlich technisch nicht verfügbar sein. Hier wird temporär der Lifecyclestatus gesetzt um technische Fehlfunktionen aufgrund der Nichterreichbarkeit zu vermeiden. Folglich können Workmode „Planned Downtime“ und Lifecyclestatus nicht zusammen geführt werden.

Natürlich ist das quatsch. Eine Zusammenführung macht sehr wohl Sinn, allerdings in Form einer Unterscheidung zwischen Business Downtime und Technical Downtime. Mir ist jedoch bis zum heutigen Tag nicht bekannt, dass dies von einem Kunden vorgeschlagen und von SAP umgesetzt wurde. Möglicherweise gibt es diese Integration, aber bereits und keiner (oder ich) weiß es nicht.

Machen Sie sich bewusst, dass es Unterschiede zwischen beiden Schaltern gibt und nutzen Sie beide. Wenn Sie den Lifecyclestatus nicht setzen, wird der Solman im schlimmsten Fall ‎bei ein paar Aktionen hängen bleiben oder merkwürdige Fehler auslösen. Es wird aber nichts schlimmes passieren, nichts kaputt gehen und keine aufwendigen Nacharbeiten/Datenbereinigungen erforderlich machen. Wenn Sie den Work Mode nicht setzten, werden Sie nur von tausenden Alerts überschwemmt und Ihre Endkunden freuen sich über die Strafzahlungen wegen den gerissenen SLAs ;-). Wenn Sie eine Landschaft neu aufbauen, gibt es keine Alternative zum Lifecyclestatus, da das Work Mode Management erst im laufenden Betrieb relevant wird.