CCM - Standard APIs
Wenn wir eine Anbindung an das Central ATC (ABAP Test Cockpit) machen, welche APIs brauchen wir dann eigentlich um Informationen zu erhalten? Hier schauen wir uns die verschiedenen Use-Cases und APIs an.
Inhaltsverzeichnis
In diesem Artikel schauen wir uns verschiedene Standard-APIs an, die wir benötigen, um das Clean Core Measurement (CCM) Projekt umzusetzen.
Einleitung
Im letzten Artikel dieser Serie hatten wir uns angeschaut, wie wir an die Level-A Objekte eines On-Prem Systems kommen und diese für uns zählen können. Nun haben wir die erste Kennzahl im System und brauchen noch die anderen Kennzahlen für Level B bis D. Diese würden wir dann aus den Findings des ABAP Test Cockpits ableiten und errechnen. Dazu benötigen wir einige APIs, um die Findings lesen zu können, aber später auch, um zum Beispiel Konfigurationen vorzunehmen oder bestimmte Felder in unserem System wiederzuverwenden.
Konfiguration
Die Konfiguration für das Cockpit bezieht sich vor allem auf den Objektprovider, der im ABAP Test Cockpit verwendet wird. In diesem Kapitel schauen wir uns deshalb die Wiederverwendung des Objektproviders an und wie wir an die Informationen der Konfiguration kommen.
Object Provider
Der Objekt Provider wird, wie in der On-Prem Version des ABAP Test Cockpits definiert, um ein System zu klassifizieren und diesem eine eindeutige ID zu geben, über die man Informationen über Objekte erhalten kann. Dieser wird im Central ATC auf dem ABAP Environment vor allem in dem zugehörigen Communication Arrangement definiert. Die Vergabe der ID ist deshalb sehr dynamisch und kann durch den Kunden jeweils selbst bestimmt werden. In vielen Fällen wird hier die System-ID verwendet, um eine Identifizierung des Systems möglich zu machen.
Grundkonfiguration
Hierbei wollen wir eine Grundkonfiguration in unserer Business Configuration zur Verfügung stellen. Diese soll per Knopfdruck alle konfigurierten Objekt Provider aus dem System lesen und direkt ins Customizing übernehmen, wodurch der manuelle Aufwand bei der Anlage und beim Suchen der Items entfällt. Dazu definieren wir uns erst einmal eine Zielstruktur, bei der wir die Provider-ID und die Gruppen-ID auslesen. Zusätzlich benötigen wir noch eine Konstante, die unser Szenario enthält, welches wir auslesen wollen. In diesem Fall brauchen wir das Custom-Code-Szenario, welches im System konfiguriert sein sollte, um aus dem Cloud-System auf ein On-Prem System zuzugreifen.
TYPES: BEGIN OF provider,
provider_id TYPE sca_ds_object_provider_id,
group_id TYPE zbc_ccm_group_id,
END OF provider.
TYPES providers TYPE SORTED TABLE OF provider WITH UNIQUE KEY provider_id.
CONSTANTS custom_code_scenario TYPE string VALUE 'SAP_COM_0464'.
Im nächsten Schritt verwenden wir die freigegebene API für die Communication Arrangements, um eine Query abzusetzen und die verschiedenen Objekte lesen zu können. Dazu befüllen wir unsere Struktur, in der wir gegen das Custom-Code-Szenario prüfen, und übergeben diese an die Query-Methode, um dann alle konfigurierten Systeme zu erhalten.
DATA(query) = VALUE if_com_arrangement_factory=>ty_query(
cscn_id_range = VALUE #( ( sign = 'I' option = 'EQ' low = custom_code_scenario ) ) ).
DATA(arrangement) = cl_com_arrangement_factory=>create_instance( ).
arrangement->query_ca( EXPORTING is_query = query
IMPORTING et_com_arrangement = DATA(systems) ).
Danach verarbeiten wir alle Systeme und lesen uns pro System die konfigurierten Eigenschaften aus. Das sind die zusätzlichen Kriterien, wo wir den Objekt Provider und die Systemgruppe hinterlegt haben. Über die zurückerhaltene Tabelle können wir dann die Informationen auslesen und befüllen damit unsere Ergebnistabelle. Damit erhalten wir eine Liste aller definierten Objektprovider und der entsprechenden Gruppen aus dem System.
LOOP AT systems INTO DATA(system).
DATA(properties) = system->get_properties( ).
TRY.
INSERT VALUE #( provider_id = properties[ name = 'OBJECT_PROVIDER' ]-values[ 1 ]
group_id = properties[ name = 'SYSTEM_GROUP' ]-values[ 1 ] )
INTO TABLE result.
CATCH cx_sy_itab_line_not_found.
CONTINUE.
ENDTRY.
ENDLOOP.
Wertehilfe
Zusätzlich wollen wir ein Communication Scenario anlegen, in dem wir alle Level-A Objekte aus dem On-Prem System lesen. Dieses haben wir uns bezogen auf den Funktionsbaustein definiert, den wir ebenfalls ausliefern, um an die Kennzahlen zu kommen. Da wir nun auch pro definiertes Backend-System eine Konfiguration benötigen, legen wir ebenfalls einen Parameter an, der den Objektprovider widerspiegelt. Um hier möglichst nah am Standard zu bleiben, verwenden wir das gleiche Element (SCA_DS_OBJECT_PROVIDER_ID) wie im Standard, welches auch im Standardszenario verwendet wird, und können hier auch die Value Help aktivieren. So erhalten wir sehr einfach und flexibel die Möglichkeit, in der Konfiguration dann auf Objektprovider zuzugreifen, die definiert sind, und müssen diese nicht manuell eintragen.
ABAP Test Cockpit
Nun benötigen wir noch weitere APIs aus dem ABAP Test Cockpit Umfeld, um die Findings nach einem Lauf zu lesen, auf die Exemptions zuzugreifen und vielleicht auch eine Jobeinplanung vornehmen zu können.
Findings
Um an die letzten Läufe aus der Custom Code Migration App zuzugreifen, gibt es den bereitgestellten View SYCM_APS_PROJECT. Diesen und die verwendeten Assoziationen können wir dann nutzen, um auf die letzten Läufe zuzugreifen. Die hier vorhandenen Header benötigen wir, um zu prüfen, ob der Lauf aktuell ist, ob das richtige System und die richtige Variante hinterlegt wurden. Sozusagen wollen wir erst noch eine Validierung auf den Daten durchführen, bevor wir die Ergebnisse ins Cockpit laden.
Haben wir dann die Projekt-ID ermittelt, können wir die Ergebnisse aus dem View darunter lesen. Wir erhalten Informationen zu den verschiedenen Findings, Fehlerklassifizierungen und Meldungen, die wir später brauchen, um Kennzahlen pro Objekt berechnen zu können.
Exemptions
Eine Option, die aktuell noch nicht eingebaut wurde, ist das Thema Exemptions. Dabei geht es darum, bei der Berechnung Objekte herauszunehmen, für die bereits eine Exemption beantragt wurde. Dabei soll unterschieden werden zwischen dauerhaften Exemptions oder nur temporären Exemptions, die vielleicht abgelaufen sind oder nur eine gewisse Zeit gültig sind. Dazu müssen wir allerdings erst einmal an alle erstellen Exemptions zu den verschiedenen Objekten kommen. Diese befinden sich im View SATC_EXEMPTIONS_DDLV_EC1. Dieser ist ebenfalls als API verfügbar. Es gibt noch eine andere Version, mit der zum Beispiel lokale Exemptions geprüft werden können. Wir benötigen allerdings die zentralen Exemptions, wie sie auch in einem zentralen Szenario zum Einsatz kommen.
Jobplanung
Beim letzten Schritt wollten wir die Jobeinplanung automatisieren, denn wir haben alle Informationen wie den Objekt Provider, die ATC-Variante und die Objekte, die wir abgrenzen wollen. Allerdings fehlt hier aktuell die passende API, um solche zentralen Läufe anlegen zu können. Deshalb ist es nur möglich, die Läufe vorher manuell im System anzulegen und dann in der Konfiguration zu hinterlegen. Ebenfalls nicht möglich ist es aktuell, einen Job einzuplanen, um das Projekt automatisiert starten zu können, diesen musst du auch manuell im System einplanen. Das Problem ist hier, dass das Job-Template SYCM_START_PROJECT_RUN aktuell keine Freigabe bekommen hat und somit nicht über die Standard-API CL_APJ_RT_API eingeplant werden kann.
GitHub
Hier findest du das Open Source Projekt und weitere Informationen auf GitHub. Weitere Informationen zur Installation und zur Verwendung des Projekts findest du im Projekt und den verlinkten Ressourcen. Die gezeigten Beispiele aus dem Artikel findest du ebenfalls im Source Code des Projekts.
Fazit
Die wichtigsten APIs stehen für unser Projekt zur Verfügung, um die Daten zu extrahieren und in Teilen auch zu automatisieren. Grundsätzlich besteht hier noch Verbesserungspotenzial, wenn es um die vollständige Automatisierung und Konfiguration der Anwendungen geht. Weitere Informationen zu APIs im ATC Context findest du im unten verlinkten Blog, welcher uns auch als Grundlage gedient hat, um an alle nötigen Informationen zu kommen.
Weitere Informationen:
SAP Community - How to extend ABAP Test Cockpit on SAP BTP for custom use cases
