Connect Solutions - REST API für den SAP Solution Manager

REST API-Konfiguration (REST API für den Solution Manager)

Mithilfe der Transaktion /GAL/SM_REST_CONFIG können folgende Einstellungen in der REST API vorgenommen werden:

Allgemeine REST API-Konfiguration

In der allgemeinen REST API-Konfiguration können Werte für vordefinierte Schlüssel belegt werden. Aktuell stehen folgende Schlüssel zur Verfügung.

Schlüssel

Datentyp

Beschreibung

REST_ACTIVE

Einstelliges Kennzeichen, “X”=True, ““=False

Dieser Schlüssel kann in BAdI Implementierungen verwendet werden, um via Customizing die Implementierung zu deaktivieren.

IS_EXT_ID_RE_ASSIGNABLE

Einstelliges Kennzeichen, “X”=True, ““=False

Kennzeichen, ob eine existierende Externe ID geändert werden darf, wenn über die REST API eine neue Externe ID gesetzt werden soll.

LONGTEXT_WO_BOL

Einstelliges Kennzeichen, “X”=True, ““=False

Kennzeichen, ob Textobjekte immer über Funktionsbausteine gelesen werden sollen und nicht über das Business Objects Interface.

DISPLAY_IMPORT_STATUS

Einstelliges Kennzeichen, “X”=True, ““=False

Kennzeichen, ob der Importstatus zu Transportaufträgen in der REST API ausgelesen werden soll.

APPROVE_STATUS

Character, Länge 5.

Genehmigt-Benutzerstatus für die Genehmigung eines Änderungsantrags, z. B. E0004. Der Wert ist nur erforderlich, wenn eine Genehmigungen über die API automatisiert ausgeführt werden sollen.

REJECT_STATUS

Character, Länge 5.

Abgelehnt-Benutzerstatus für die Genehmigung eines Änderungsauftrags, z. B. E003. Der Wert ist nur erforderlich, wenn eine Genehmigungen über die API automatisiert ausgeführt werden sollen.

RFC_AWAIT_APPROVAL_STATUS

Character, Länge 5.

Status eines Änderungsantrags, der auf Genehmigung wartet, z. B. E0012 (Es kann entweder der zugehörige Benutzer- oder Systemstatus angegeben werden). Der Wert ist nur erforderlich, wenn eine Genehmigungen über die API automatisiert ausgeführt werden sollen.

Zuordnung von Externen IDs

In dieser View kann pro Geschäftsvorgangsart oder für ein Geschäftsvorgangsart-Muster definiert werden in welcher Art und Weise Externe IDs für ChaRM Objekte abgespeichert werden sollen. Zusätzlich kann über eine Checkbox festgelegt werden, ob es zulässig ist, dass zu einem ChaRM Objekt mehrere Externe IDs zugeordnet werden dürfen.

Wenn Sie mehrere Regeln definieren, z. B. eine Regel für die spezifische Geschäftsvorgangsart ZMMJ und eine generische Regel Z*, wird erst nach einer spezifischen Zuordnung gesucht, und wenn keine spezifische Zuordnung gefunden wurde, erfolgt eine Suche nach einer generische Zuordnung.

Folgende Szenarien werden für die Speicherung für Externe IDs angeboten:

  • Externe IDs werden in einem kundeneigenem Feld gespeichert

  • Externe IDs werden in einem Standard-Feld gespeichert

  • Externe IDs werden in der Tabelle “/GAL/SM_CHARM_EX” des Addons gespeichert (Default)

Die ersten beiden Optionen stehen nur zur Verfügung, wenn die Zuordnung einer Externen ID und eines ChaRM Objekts eineindeutig ist.

Speicherung Externer IDs in einem kundeneigenem Feld

Zur Speicherung Externer IDs in einem kundeneigenem Feld, muss in der Pflege-View die Option “Ist benutzerd. Feld“ markiert und im Feld “Benutzerdef. Feld“ der technische Name des kundeneigenen Felds eingetragen werden. Die technischen Namen von kundeneigenen Feldern können Sie über die Tabelle CRMD_CUSTOMER_H einsehen.

Speicherung Externer IDs in Standard-Felder

Die Definition für Standard-Felder ist etwas komplizierter und ist nur Möglich, wenn das Feld im GenIL Model Browser in direkter Beziehung (1:1) zum Zugriffs-Objekt “BTAdminH” steht. Ob die Voraussetzung erfüllt ist, können Sie in Transaktion GENIL_MODEL_BROWSER nachvollziehen.

Um die Speicherung in einem Standard-Feld zu aktivieren, muss die Option “Bestehendes Feld“ markiert werden. Zusätzlich muss in das Feld “Vorhandener Feldname“ der technische Feldname, in das Feld “Beziehungsname“ der Name der Beziehung zum Zugriffs-Objekt “BTAdminH” und in das Feld “Tabellenname” der technische Name der zugehörigen physikalischen Tabelle eingetragen werden. Das Feld “Objekttyp“ ist ebenfalls zu füllen und zwar mit dem Objekttyp des Objekts zu dem das Standard-Feld gehört. Eine Liste mit zulässigen Objekttypen kann in der Tabelle CRMC_OBJECTS gefunden werden.

Beispiel: Sie wollen eine eindeutige Externe ID in das Standard-Feld PO_NUMBER_SOLD speichern. Über die Transaktion GENIL_MODEL_BROWSER können Sie herausfinden, dass der Name der Beziehung BTHeaderSalesSet lautet. Aus Tabelle CRMC_OBJECTS leiten Sie ab, dass der Objekttyp des Objekts “SALES” dem Wert “11” zugeordnet ist und der Tabellenname setzt sich im Allgemeinem zusammen aus CRMD_<OBJECT_NAME>, wobei <OBJECT_NAME> dem Namen des Objekts aus CRMC_OBJECTS entspricht. In diesem Beispiel lautet der Tabellenname demnach CRMD_SALES.

Verknüpft sind die Kopfdaten eines ChaRM Objekts (Tabelle CRMD_ORDERADM_H) mit den Teilobjekten übrigens über die Tabelle CRMD_LINK. Die Spalte GUID_HI entspricht der GUID aus Tabelle CRMD_ORDERADM_H und GUID_SET entspricht der GUID aus der Tabelle, die über Tabelle CRMC_OBJECTS aus dem Objekttyp OBJTYPE_SET abgeleitet wird.

Webhook-Definitionen

Für die Definition eines Webhooks stehen in der Transaktion /GAL/SM_REST_CONFIG die folgenden drei Pflegeviews zur Verfügung:

  • Webhook-Defintion für die Pflege des Endpunkts und allgemeine Einstellungen des Webhooks

  • Webhook-Filter um für unterschiedliche Webhooks bestimmte Filterkriterien zu definieren

  • Webhook-Authentifizierung, falls der Endpunkt eines Webhooks eine Authentifizierung erfordert

Allgemeine Webhook-Definition

Unter den allgemeinen Webhook-Einstellungen stehen folgende Einstellungen zur Verfügung.

Name der Einstellung

Beschreibung

Name des Webhooks

Frei definierbarer Name für den Webhook

URI

Die URL des Webhook-Endpunkts. Endpunkte in Conigma Connect entsprechen dem folgendem Muster:

Release 2021: http(s)://<domain>:<connect_port>/repositories/<repository_name>/connections/<connect_name>/events/<event_name>

Release 2022: http(s)://<domain>:<connect_port>/connections/<connect_name>/events/<event_name>

Beschreibung

Eine kurze Beschreibung für den Webhook

Prozesstyp-Filter

Der technische Name der Geschäftsvorgangsart für die der Webhook ausgelöst werden soll. Mehrere Geschäftsvorgangsarten können mit einem Strichpunkt (in Zeichen “;”) getrennt werden.

Ext. ID kann leer sein

Checkbox, ob der Webhook für ChaRM Objekte ausgelöst werden kann bei denen die Externe ID keinen Wert enthält.

Beim Erstellen

Checkbox, ob der Webhook ausgelöst werden soll, wenn ein neues ChaRM Objekt angelegt wird.

Zur Aktualisierung

Checkbox, ob der Webhook ausgelöst werden soll, wenn ein bestehendes ChaRM Objekt aktualisiert wird.

Ist aktiviert

Checkbox, ob der Webhook aktiv ist.

Definition von Webhook-Filterkriterien

In der View zur Pflege von Webhook-Filterkriterien können Sie entweder ein Muster für Externe IDs definieren oder auf bestimmte Werte in der Addon-Tabelle “/GAL/SM_CHARM_EX” filtern.

Für die Definition eines Muster für Externe IDs stehen zwei Felder in der Pflegeview zur Verfügung:

  • Ext. ID-Filter: Muster für Externe IDs bei denen das Stern-Zeichen (in Zeichen “*”) als Wildcard verwendet wird

  • Ext. ID-Option: Auswahl eines Operators, der für den Vergleich einer Externen ID mit dem Filter verwendet werden soll. Die Auswahl erfolgt mit Hilfe einer Werteliste, die folgende Optionen unterstützt: <, <=, =, >=, >, Enthält Muster, Enthält nicht Muster

Ein Filter auf Externe ID kann dann sinnvoll sein, wenn die Externe ID einen Konstanten Wert enthält, der eine Organisationseinheit, ein Projekt oder etwas ähnliches abgrenzt. Die IDs von Jira-Vorgängen enthalten beispielsweise ein Präfix, das dem zugehörigen Jira-Projekt entspricht.

Die Tabelle “/GAL/SM_CHARM_EX” enthält 8 Spalten (CUSTOM_FIELD1 - CUSTOM_FIELD8) in denen kundenspezifische Inhalte zu einem ChaRM Objekt gespeichert werden können. Für den Fall, dass ChaRM Objekte mit Externen Objekten aus unterschiedlichen Quellsystemen verknüpft sein können, kann in einer der zur Verfügung stehenden Spalten beispielsweise ein Kürzel des Quellsystems gespeichert werden, z. B. SNOW, ADO oder JIRA. In den Filterkriterien kann dann definiert werden, dass ein Webhook nur dann ausgelöst wird, wenn das ChaRM Objekt einem bestimmten Kürzel, z. B. SNOW, zugeordnet ist.

Folgende Felder stehen in der Pflegeview zur Definition eines kundeneigenes Filters zur Verfügung:

  • Kund. Filter-ID: Über eine Werteliste kann das kundenspezifische Feld aus Tabelle “/GAL/SM_CHARM_EX” ausgewählt werden in den der Filterwert gespeichert ist.

  • Kund. Filter-Wert: Der kundeneigene Filter-Wert

  • Kund. Filter-Option: Auswahl eines Operator, der für den Vergleich des Filter-Werts verwendet werden soll.

Definition einer Webhook-Authentifizierung

Sofern ein Endpunkt eine Authentifizierung erwartet, kann in der Pflegeview für die Webhook-Authentifizierung entweder Benutzername und Passwort für eine Basic Authentifizierung oder ein Client-Zertifikat ausgewählt werden, das vorab über die Transaktion STRUST angelegt wurde.

Default-Textobjekte für eine Geschäftsvorgangsart

In dieser View kann pro Geschäftsvorgangsart eine Text-ID ausgewählt werden, die den Langtext bzw. Beschreibung eines ChaRM Objekts enthält. Ist eine Zuordnung vorhanden, kann in der REST API die Eigenschaft “longtext” verwendet werden, um einfach die Beschreibung zu lesen oder zu schreiben. Andernfalls müsste die Beschreibung mithilfe eines Text-Arrays, der die Text-ID und den Text enthält, gelesen oder geschrieben werden.

Ein Beispiel für die Verwendung der Eigenschaft “longtext” finden Sie unter folgendem Link.

https://galileogroup.atlassian.net/wiki/spaces/CONNECTDOCDE/pages/622428169/Endpunkte+REST+API+f+r+den+SAP+Solution+Manager#Langtext

Aktionen mit Einfluss auf übergeordnete Objekte

Sofern Statusübergänge von ChaRM Objekten über die REST API ausgeführt werden sollen, sollte vorab geprüft werden, ob Statusübergänge ausgeführt werden sollen, die ein Übergeordnetes Objekt ändern können. Wenn Beispielsweise zu einem Änderungsantrag ein oder mehrere Änderungsdokumente existieren und alle Änderungsdokumente zurückgezogen werden, wird der Änderungsantrag im Standardprozess automatisch in den Status “Überprüfung” gesetzt. Um diesen Automatismus zu ermöglichen, darf sich der Änderungsantrag nicht durch einen Benutzer im Änderungsmodus befinden.

In dieser View werden deswegen PPF-Aktionen gepflegt bei denen die REST API prüfen muss, ob nicht nur das zugehörige Objekt gegen Änderung gesperrt ist, sondern ebenfalls das Übergeordnete Objekt. Die Namen der PPF-Aktionen können im SAP Customizing oder in der Tabelle PPFTTTCU eingesehen werden. Die Namen der PPF-Aktionen beginnen in der Regel mit dem technischen Namen der zugehörigen Geschäftsvorgangsart, z. B. ZMMJ_WITHDRAW_MJ.

Für die REST API erlaubte Tabellen

Über die REST API ist es möglich SAP Tabellen zu lesen. Damit können die Inhalte kundeneigener SAP Tabellen in Conigma Connect verwendet werden, um z. B. Quelldaten zu transformieren. Wenn Beispielsweise die Zuordnung von ServiceNow Configuration Items zu ChaRM Konfigurationselemente in SAP gepflegt werden soll, muss der Name der Tabelle in dieser Pflegeview eingetragen werden, um der REST API den Zugriff auf diese Tabelle zu erlauben. Aktuell ist es nur möglich Inhalte von Tabellen zu lesen aber nicht zu schreiben.