Kategorie: SAP Solution Manager

Alles Wissenswertes rund um den SAP Solution Manager.

SAP Solution Manager 7.2 ChaRM Content Activation

Sie hatten SAP Solution Manager 7.1 ChaRM im Einsatz, haben erfolgreich auf SAP Solution Manager 7.2 geupgradet und im Rahmen des Upgrades die Content Activation durchgeführt?

Super gemacht. Herzlichen Glückwunsch.

Und jetzt stellen Sie fest, dass die Zuordnungsblöcke „Landschaftsverwaltung“ und „Transportverwaltung“ für einige alte Vorgänge keine Daten mehr anzeigen? Und dass Sie ganz alte Vorgänge im schlimmsten Fall gar nicht mehr in der Vorgangssuche finden?

Ja das kommt davon, wenn man die Content Activation nicht auch für alle alten (schon lange abgeschlossenen) Projekte durchführt. Tja, hätte SAP SE Ihnen mal sagen sollen, oder?

Und nun?

Lösung 1: Mittels Report AIC_CM_72_POST_MIGRATION können Sie die Content Activation auch nachträglich durchführen. Details finden Sie hier: 2596470 – How to Activate SOLAR Projects after Content Activation (from SAP Solution Manager 7.1 to 7.2) has been completed

Lösung 2: Mittels Report AIC_CM_POST_MIG_TR_TO_72 können Sie zumindest die Transportverwaltung reparieren (Migration von Tabelle /TMWFLOW/TRORDHC zu /TMWFLOW/TRORD_N). Leider gibt es noch keinen Reparaturreport für die Landschaftsverwaltung (hier wäre Tabelle /TMWFLOW/TTRCKHC to /TMWFLOW/TTRCKHN zu migrieren). Details finden Sie hier: 2506007 – Content-Aktivierung: Werkzeug zur Migrationsnachbearbeitung zum Registrieren der Transportaufträge für ein Projekt für SAP Solution Manager 7.2

Lösung 3: Dass Sie Ihre alten Vorgänge unter Umständen gar nicht mehr finden liegt daran, dass ab SAP Solution Manager 7.2 Einträge in der Tabelle TSOCM_CR_CONTEXT (direkte Projekt-/Zykluszuordnung) vorausgesetzt werden. Für alte Vorgänge (speziell aus der Zeit von SAP Solution Manager 7.0) trifft das aber nicht immer zu. Ein SAP-Standard-Report zum nachträglichen Aufbauen der Tabelle gibt es meines Wissens nach nicht. Natürlich kann man sowas programmieren… (siehe Blog zum Upgrade SM 7.0 zu 7.2).

Zuordnungsblöcke bzw. Tabs im SAP Web Client UI dynamisch ausblenden

Mittels UI-Konfiguration lassen sich Zuordnungsblöcke in der Vorgangsbearbeitung flexibel konfigurieren. Teilweise kann die Konfiguration abhängig von der Vorgangsart oder dem Status gestaltet werden, sofern dies von der UI-Komponente vorgesehen ist.

Ein dynamisches Ausblenden von Zuordnungsblöcken, z.B. bei fehlender Berechtigung, ist jedoch nicht vorgesehen. Mit einer kleinen Erweiterung des SAP-Standards ist das aber kein Problem. Diese Erweiterung funktioniert sowohl für SAP CRM als auch für SAP Solution Manager ITSM und SAP Solution Manager ChaRM.

Erweiterung am Ende von Methode cl_crm_uiu_bt_tools=>get_ovviews_header:

*Here we hide one customer_h assignment block according to authority.

data:
  ls_deactive_views like line of lt_deactive_views.

*Perform authority check
AUTHORITY-CHECK OBJECT ...

IF sy-subrc NE 0.
  ls_deactive_views-component = 'BTCUSTOMER_H'.
  ls_deactive_views-viewname = 'ZUBTCustomerH_01.BTCUSTOMER_H/MainWindow'.
  append ls_deactive_views to lt_deactive_views.
endif.

*Compare on component name and view name is not enough, because we need to compare on component usage in case we have more than one BTCUSTOMERH assignment blocks.
data(lt_static_views) = it_static_views.
loop at lt_static_views assigning field-symbol(<fs_static_views>) where viewid cp 'ZUBTCustomerH*'.
  <fs_static_views>-VIEWNAME = <fs_static_views>-viewid.
endloop.

*Rebuild result.
get_ovviews_return_tables( EXPORTING it_static_views = lt_static_views it_deactive_views = lt_deactive_views IMPORTING et_views_to_detach = et_views_to_detach et_views_to_reattach = et_views_to_reattach ).

*Here we hide all unauthorized assignment blocks (tabs).

data:
  ls_deactive_views like line of lt_deactive_views.

loop at it_static_views assigning field-symbol(<fs_static_views>).

*Perform authority check
AUTHORITY-CHECK OBJECT ...

IF sy-subrc NE 0.
  ls_deactive_views-component = <fs_static_views>-component.
  ls_deactive_views-viewname = <fs_static_views>-viewname.
  append ls_deactive_views to lt_deactive_views.
endif.

endloop.

*Rebuild result.
get_ovviews_return_tables( EXPORTING it_static_views = lt_static_views it_deactive_views = lt_deactive_views IMPORTING et_views_to_detach = et_views_to_detach et_views_to_reattach = et_views_to_reattach ).

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.

Filterung der Systeme in „Create Transport Request“ Popup abhängig von Berechtigungen und bereits angelegten Transporten

Hintergrund:

Beim Anlegen von Transportaufträgen stehen alle zum Projekt gehörenden Entwicklungssysteme zur Auswahl. Eine Einschränkung erfolgt nicht. Durch Ausprägung der Beispielimplementierung AIC_ONLY_DEV_IBASE_SYSTEM des BADIs AIC_CREATE_TRANSPORT_WINDOW kann eine Einschränkung gemäß IBase-Komponente aktiviert werden.

Problem:

Das hilft uns nicht weiter, da die Transportwege wie folgt sind:

  • EXX.900 -> PXX.900
  • EXX.100 -> PXX.100
  • EXX.910 -> PXX.900 + PXX.100

Es sind also zwei IBase-Komponenten auswählbar. Bei Auswahl von PXX.900 kann bei aktiver Beispielimplementierung im EXX.900 und EXX.910 implementiert werden. Bei Auswahl von PXX.100 kann in EXX.100 und EXX.910 implementiert werden. Es ist somit also nicht möglich die Implementierung ausschließlich in EXX.100 oder EXX.910 zu erzwingen.

Lösung:

  • Eigene BADI-Implementierung ZSM_AIC_CREATE_TRANSPORT_LIST.
  • Change Manager dürfen Transporte in allen Systemen anlegen. (Identifizierung anhand der Genehmigungs-Aktivität im Approval Management – SM_APP_AP)
  • Entwickler dürfen jedoch nur Transporte zu Entwicklungssystemen anlegen, in denen bereits Transporte angelegt wurden.
  • User dürfen generell Transporte in allen Systemen anlegen, wenn noch keine Transportaufträge angelegt und damit der Scope noch nicht festgelegt wurde.

Code-Schnipsel:

METHOD cl_aic_create_transport_window~filter_systems.

DATA:
lt_transp_req TYPE socmt_trordhc_type.

FIELD-SYMBOLS:
<fs_system_list> LIKE LINE OF ct_system_list.

*Valid parameters?
CHECK iv_header_guid IS NOT INITIAL AND ic_header_bol IS BOUND.

*If only one source system is available we want to keep it.
*Therefore all old unharmonized projects will run as before.
CHECK lines( ct_system_list ) > 1.

*Check authority. (User has authority to approve a step in approval management?)
AUTHORITY-CHECK OBJECT 'SM_APP_AP'
*          ID 'AIC_PROC' FIELD lv_process_type
ID 'AIC_PROC' DUMMY
ID 'ACTVT' FIELD '37'.

*Authority given. Allow everything.
CHECK sy-subrc <> 0.

*Get all already created transport requests.
CALL METHOD /tmwflow/cl_transport=>get_chng_doc_transp_req
EXPORTING
iv_header_guid = iv_header_guid
IMPORTING
et_transp_req  = lt_transp_req.

*No transport created yet. Allow everything.
CHECK lt_transp_req IS NOT INITIAL.

*Check systems and delete all systems which are not already used.
LOOP AT ct_system_list ASSIGNING <fs_system_list>.
READ TABLE lt_transp_req TRANSPORTING NO FIELDS WITH KEY
trorder_system = <fs_system_list>-sysname
trorder_client = <fs_system_list>-client.
IF sy-subrc <> 0.
DELETE ct_system_list.
ENDIF.
ENDLOOP.

ENDMETHOD.