Infuencing SAP ChaRM 2019

Hello, I just want to inform you about two important SAP Customer Influencing programs which are improving and rounding up the current SAP products of SAP CRM, SAP Web Client UI and SAP ChaRM. If you have any improvement or round-up ideas please use the programs, share your ideas and influence the products!

SAP Customer Connect „CRM 2019“:

https://influence.sap.com/crm2019 https://influence.sap.com/sap/ino/#/campaign/1425

23.10.2018 collection start
03.12.2018 collection end
Current status at 19.02.2019: Active, In discussion, In development

SAP Customer Connect „Change and Release Management 2019 in SAP Solution Manager“:

https://influence.sap.com/solman-charm2019
https://influence.sap.com/sap/ino/#/campaign/1717

08.01.2019 collection started
08.03.2019 collection end
Current status at 19.02.2019: Active, In Collection of improvement requests

My involvement (on ChaRM 2019, till 19.02.2019):

114 improvement requests at all
72 comments from Peter Weigel
19 improvement requests from Peter Weigel
10 improvement requests from Peter Weigel already scoped (more than 10 votes)

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.

TSOCM_CR_CONTEXT

One of the most important and at the same time one of the worst designed tables in ChaRM is TSOCM_CR_CONTEXT. This table is used to store cycle assignment of CR and CD. At the same time it is used to plan the scope of a CR. There is no proper API existing, there are a lot of code snippets which are manipulating or evaluating the entries of this table mostly without sense.

This blog should help you to understand this table from technical point of view.

Code snippets / Reference:

  • CL_IM_AI_CRM_COPY_BADI->IF_EX_CRM_COPY_BADI~ORDERADM_H
  • cl_al_crm_cm_utility=>get_sub_docs_4_cyc_by_cr_ctxt (SAP note 2592607)
  • cl_wdcm_extchreq_scoping_asst=>GET_CR_PROJECT_BY_FOLLOW_ON (SAP note 2581812)

API:

  • CL_AI_CRM_CM_CR_CONT_RUN_BTIL=>GET_CR_CONTEXT
  • cl_ai_crm_cm_cr_cont_run_btil=>update_cr_context
  • cl_wdcm_extchreq_scoping_asst=>read_context_db
  • cl_wdcm_extchreq_scoping_asst=>update_context_db
  • cl_aic_cm_scope_backend_api=>read
  • cl_aic_cm_scope_backend_api=>UPDATE
  • cl_aic_cm_scope_backend_api=>SAVE_INTO_DB

Header Context:

  • GUID: GUID of Transaction
  • ITEM_GUID: = GUID
  • CREATED_GUID: Empty for CR, = GUID for CD
  • CREATED_BY: Empty
  • CREATED_ON: Empty
  • PROCESS_TYPE: Process Type of Transaction (CR and CD)
  • IBASE: Empty
  • IBASE_INSTANCE: Empty
  • PRODUCT_ID: Empty
  • SID: Empty
  • MANDT: Empty
  • PROJECT_ID: Assigned change cycle (SM 7.0/7.1: ID of assigned Project)
  • SOLUTION_ID: Empty (SM 7.0/7.1: ID of assigned Solution)
  • SLAN_ID: Change Control landscape or Solution
  • SBRA_ID: Branche
  • APPR_RESULT: Empty
  • APPROVED: Empty
  • APPROVE_STATUS: Empty
  • OBJECT_ID_DESCR: Empty

Scope Context:

  • GUID: GUID of CR Transaction
  • ITEM_GUID: = Unique GUID (can be GUID of CD if scope context was created after CD creation)
  • CREATED_GUID: Empty if CD is not created yet, otherwise GUID of CD
  • CREATED_BY: Creator of CD (see CRMD_ORDERADM_H-CREATED_BY of CD)
  • CREATED_ON: Creation Timestamp (see CRMD_ORDERADM_H-CREATED_AT of CD)
  • PROCESS_TYPE: Process Type of CD Transaction (see CRMD_ORDERADM_H-PROCESS_TYPE of CD)
  • IBASE: Ibase (will be transferred to REFOBJ on CD creation)
  • IBASE_INSTANCE: IBase Instance (will be transferred to REFOBJ on CD creation)
  • PRODUCT_ID: Product ID of IBase Component
  • SID: System ID of IBase Component (if LMDB object)
  • MANDT: Client of IBase Component (if LMDB object)
  • PROJECT_ID: Assigned change cycle
  • SOLUTION_ID: Empty
  • SLAN_ID: Change Control landscape or Solution
  • SBRA_ID: Branche
  • APPR_RESULT: „A“ or „F“ for approved, „“ for unapproved
  • APPROVED: Empty
  • APPROVE_STATUS: Used to store user status of CR in case of scope extension process
  • OBJECT_ID_DESCR: Description of CD (see CRMD_ORDERADM_H-DESCRIPTION of CD)

How to get configuration item system data fresh from CR/CD (maybe to update TSOCM_CR_CONTEXT)?

Solution 1 (working for LMDB and CMDB objects but not for text components):

  1. cl_ai_crm_object_api=>get_object_id_from_order
  2. cl_hf_helper=>get_sys_data
  3. cl_hf_helper=>get_ibase_comp_4_product
  4. CRM_IBASE_COMP_GET_DETAIL

Solution 2 (working for text components as well):

  1. cl_hf_helper=>get_ibase_instance_of_chng_doc
  2. CRM_IBASE_COMP_GET_DETAIL
  3. Extract OBJECT_ID (not PRODUCT_ID!)
  4. cl_hf_helper=>get_sys_data

How to get transaction data (needed to build context entries)?

  • cl_hf_helper=>get_header_of_chng_doc
  • cl_hf_helper=>get_proc_type_of_chng_doc
  • cl_hf_helper=>get_predoc_of_chng_doc
  • cl_hf_helper=>get_sucdocs_of_chng_doc
  • cl_hf_helper=>get_bo_links_of_chng_doc (to get assigned cycle of CD)
  • cl_hf_helper=>get_bo_tasklist_of_chng_doc (to get assigned tasklist of CD)
  • cl_al_crm_cm_utility=>get_smi_project_by_tasklist (to get cycle id or SM 7.0/7.1 project id of task list)

 

Note: These information are taken from my ABAP report which was developed to create entries in TSOCM_CR_CONTEXT table for old SM 7.0/7.1 change transactions after upgrade to SM 7.2. These information are not sufficient to re-implement this report. However I hope it will help you to understand the technical dependencies.

 

 

 

ChaRM Hilfsfunktionen API

Wer als ABAP Entwickler im Umfeld SAP Solution Manager Change Request Management unterwegs ist, wird sehr häufig auf grundlegende Funktionalitäten der Vorgangsbearbeitung oder des Transportwesens zugreifen wollen. Sehr häufig finden sich entsprechende Methoden in folgenden ABAP-OO-Klassen. Eigentlich kennt die jeder ChaRM-Entwickler, aber manchmal überlege auch ich: „Wie hieß die Klasse nochmal?“.

Hier mein Spickzettel:

  • CL_HF_HELPER
  • CL_AL_CRM_CM_UTILITY
  • /TMWFLOW/CL_TRANSPORT_UTIL

Neu seit Solution Manager 7.2:

  • CL_AIC_CM_SCOPE_BACKEND_API
  • CL_AIC_CM_TRANS_BACKEND_API
  • CL_AIC_TWB_CONT_BACKEND_API

Und zum nachschauen, wie es der SAP-Standard tut:

  • Proxy-Klassen: CL_CHM1_INSTANCE (und verwandte Klassen CL*CHM1*INSTANCE*), hier speziell Methoden IF_EX_SOCM_PROCESS_ACTION~PROCESS_ACTION und IF_EX_SOCM_CHECK_CONDITION~CHECK_CONDITION
  • Kopiersteuerung: CL_IM_AI_CRM_COPY_BADI
  • BOL/GenIL: CL*AI*RUN_BTIL (z.B. Transportverwaltung, Landschaftsverwaltung etc.)

Die wichtigste Tabelle ist und bleibt für immer und ewig [bis 2025 😉 ] CRMD_ORDERADM_H.

SAP Solution Manager 7.2 ChaRM Upgrade mit Erhalt und Weiterverwendung der Änderungsprozesse aus SAP Solution Manager 7.0

Frage: Gibt es die Möglichkeit, einen Upgrade von SAP Solution Manager 7.0 (SAP GUI) nach SAP Solution Manager 7.2 (Web UI) durchzuführen und hierbei die kundeneigenen Änderungsprozesse zu erhalten und weiterzuverwenden?

Antwort 1: Laut offizieller Aussage der SAP SE gibt es keinen Migrationspfad. Das heißt, es müssen neue Änderungsvorgänge konfiguriert werden, wobei einige Teile wiederverwendet werden können. Hierzu gibt es von SAP SE bereitgestellte Leitfäden für den Upgrade SM 7.0 nach 7.1 und für den Upgrade SM 7.1 nach 7.2.

Antwort 2: Nach meiner Erfahrung aus konkreten Projekteinsätzen ist es möglich. Da diese Form des Upgrades von SAP SE nicht vorgesehen ist, sind jedoch einige manuelle Konfigurations- und Entwicklungsaktivitäten durchzuführen. Der Upgradeaufwand liegt je nach Komplexität der Kundenlösung bei ca. 18 PT.

Die wichtigsten Aktivitäten im Überblick:

  • Customizing migrieren (SAP GUI -> Web UI, z.B. Proxyklassen)
  • Customizing migrieren (alte Tabellen -> neue Tabellen, z.B. Kopiersteuerung, PPF-Aktionen -> Drucktasten in Landschafts- und Transportverwaltung)
  • Customizing für neue Funktionalitäten ausprägen (z.B. Transportrisiko, Downgrade-Protection)
  • SAP Web Client UI konfigurieren
  • Sachverhalt + IBase-Komponente mittels Entwicklung im Änderungsantrag bereitstellen
  • Kontext (direkte Projektzuordnung) mittels Entwicklung einmalig nachgenerieren
  • Optional: Kontext (direkte Projektzuordnung + Umfang) anhand Sachverhalt und IBase-Komponente im Änderungsantrag mittels Entwicklung automatisch finden
  • Optional: Kundeneigene Entwicklungen migrieren (z.B. Wertehilfen für kundeneigene Felder)

Ich habe u.a. ein Upgrade SM 7.0 -> SM 7.1 im Jahr 2013 und ein Upgrade SM 7.0 -> SM 7.2 im Jahr 2018 durchgeführt und kann hierdurch bezeugen: Es funktioniert wirklich.

Bei Fragen zu den Details kommen Sie gern auf mich zu. Wenn Sie Unterstützung bei Ihrem Upgrade benötigen, dann melden Sie sich bitte bei mir. Ich helfe Ihnen gern.

PS: Seit dem Upgrade auf SAP Solution Manager 7.2 sind die alten Änderungsvorgänge aus dem SAP Solution Manager 7.0 im SAP Web Client UI nicht mehr auffindbar. Eine nachträgliche Mini-Migration SM 7.0 -> SM 7.2 für abgeschlossene Vorgänge ist möglich. Aufwand: ca. 5 PT.