Читать книгу: «Praxishandbuch SAP Cloud Platform Integration», страница 2

3 Schnittstellenentwicklung mit SAP CPI

Dieses Kapitel beschreibt den Prozess der Schnittstellenentwicklung mit SAP CPI sowie die wesentlichen Objekte und Konzepte, die dabei Anwendung finden.

Nachdem Sie sich über den Browser auf dem Tenant angemeldet haben, haben Sie die Wahl, in einen der folgenden Bereiche zu navigieren:

 Discover

 Design

 Monitor

Hinter Discover verbergen sich der SAP-Katalog, der fertigen, verwendbaren Integration Content enthält, sowie aufrufbare Schnittstellen von SAP-Anwendungen (APIs), die Sie in neu erstellten Schnittstellen bausteinartig einsetzen (»konsumieren«) können. In Kapitel 6 erläutere ich Ihnen die dazugehörigen Konzepte.

Der Monitor stellt Überwachungs- und Konfigurationsmöglichkeiten bereit, die in Kapitel 7 behandelt werden.

Der Bereich Design umfasst die Entwicklung von Schnittstellen und wird hier bzw. in Kapitel 4 ausführlich erläutert.

3.1 Architektur
3.1.1 Nodes

Sämtliche Aktivitäten hinsichtlich der Entwicklung von CPI-Schnittstellen erfolgen über den Browser, der sich wiederum mit der sogenannten Tenant Management Node verbindet. Darüber hinaus gibt es zwar vereinzelte Szenarios, die die Software Eclipse anstelle eines Browsers als Entwicklungsumgebung verwenden (siehe Abschnitt 7.6), die SAP jedoch hat alle wesentlichen Funktionen in der WebUI implementiert. Die Tenant Management Node dient der Interaktion zwischen Entwicklern bzw. Administratoren und dem CPI Tenant, um Änderungen an den Objekten vorzunehmen oder ein Monitoring zu betreiben.

Für die Laufzeit wird die Runtime Node verwendet. Dort werden die Schnittstellen bereitgestellt, und mit diesen Nodes interagieren die beteiligten Systeme. Jede Node stellt dabei eine eigene VM dar, die über Hauptspeicher (RAM), CPUs usw. verfügt. Die Skalierung der CPI erfolgt dementsprechend über die Größe und Anzahl der Nodes. Da sich das System »elastisch« verhalten soll, d.h., der Kunde sich nicht darum kümmern müssen soll, ob das System einer Belastung standhält, ist »die Dimensionierung der Laufzeitumgebung« für den Kunden nicht immer transparent. Abbildung 3.1 veranschaulicht den Aufbau der SAP-CPI-Architektur.

Abbildung 3.1: SAP-CPI-Architektur

Weitere Informationen zur SAP-CPI-Architektur

Im SAP Help Portal finden Sie unter nachfolgendem Link den Aufbau der SAP-CPI-Architektur: https://bit.ly/32lHCcE.

3.1.2 Apache Camel

SAP CPI basiert auf der Laufzeitumgebung Apache Camel; dabei handelt es sich um ein Open-Source-Projekt der Apache Software Foundation, das Java als Laufzeit verwendet und sogenannte Entwurfsmuster (Enterprise Integration Patterns) unterstützt, die für Systeme verwendet werden, die auf den Prinzipien von Enterprise Application Integration (EAI) und Message Oriented Middleware (MOM) beruhen. Einer der Vorteile von Apache Camel ist die Existenz einer Vielzahl von Components, die eine Integration zu Systemen und Anwendungen ermöglichen (siehe Abbildung 3.2) und somit die Entwicklung eines Adapters auf SAP CPI erleichtern, sofern die vorhandenen Adapter nicht bereits ausreichen, um Schnittstellen zu entwickeln. Darüber hinaus ist eine genauere Kenntnis von Apache Camel nicht erforderlich, um auf SAP CPI Schnittstellen modellieren zu können, da die mitunter sehr komplexe technische Implementierung für den Entwickler seitens der SAP abstrahiert wurde. Camel-eigene Begriffe wie »Endpoint« und »Processor« (siehe Abbildung 3.2) spielen in der SAP CPI WebUI daher keine Rolle.

Abbildung 3.2: Apache-Camel-Architektur

3.1.3 Aktualisierungskonzept

Ein CPI Tenant wird, wie jedes echte Cloud-Produkt (SaaS – Software as a Service), regelmäßig und derzeit ungefähr monatlich aktualisiert. Hierfür erhält der Tenant-Administrator eine Informations-E-Mail mit den Angaben zu den betroffenen Tenants (siehe Abbildung 3.3).

Abbildung 3.3: SAP-CPI-Update-E-Mail

Dabei gilt es zu beachten, dass die SAP im Vorfeld diverse technische Kombinationen erprobt und eine Vielzahl an Szenarios (vor allem den von SAP ausgelieferten Standard Integration Content) ausführlich testet (siehe auch Kapitel 6). Die SAP hat in einem Blogeintrag zusammengefasst, wie bei den Tests vorgegangen und eine störungsfreie Aktualisierung sichergestellt wird: https://bit.ly/32ku7tR. Dort wird auch die Möglichkeit erwähnt, ausgewählte eigene Integration Flows testweise an die SAP zu liefern, um diese mit jedem neuen Update (kostenpflichtig) mittesten zu lassen.

Der Status der CPI pro Data Center lässt sich im SAP Trust Center ermitteln: https://www.sap.com/germany/about/trust-center/cloud-service-status.html (siehe Abbildung 3.4). Dort können Sie vergangene Ereignisse nachverfolgen (z.B. eine erfolgte Wartung/ein erfolgtes Update oder eine außerplanmäßige Störung, siehe Abbildung 3.5).

Abbildung 3.4: SAP Trust Center

Abbildung 3.5: SAP-CPI-Statushistorie

Wenn Sie über aktuelle Störungen bzw. Alert-E-Mails zum Status einer Anwendung im Data Center informiert werden möchten (nur zur Verfügbarkeit, nicht auf Schnittstellenebene), können Sie sich für Status-Updates registrieren: https://sapcp.statuspage.io/ (siehe Abbildung 3.6).

Abbildung 3.6: SAP-Cloud-Platform-Status

3.2 Integration Content

Integration Content bezeichnet eine Software, die für die Funktionsweise einer Schnittstelle benötigt wird. Damit sind sämtliche Elemente gemeint, die eine Schnittstelle repräsentieren. Umgangssprachlich spricht man auch von »digitalem Klebstoff«, mit dem Systeme, Anwendungen, Geschäftspartner und Behörden miteinander verbunden werden können. Nachfolgende Objekte, die besondere Arten von Integration Content darstellen, werden hinsichtlich ihrer Bedeutung und Funktionalität erläutert.

3.2.1 Integration Package

Ein Integration Package ist eine Art Verzeichnis bzw. Archiv, das mehrere, typischerweise zusammengehörige Schnittstellen bündelt. Mit diesem können Sie, neben einer Kurzbeschreibung, eine Dokumentation als Text erfassen (siehe Abbildung 3.8) bzw. vorhandene Dokumente unter Documents importieren oder als Hyperlink auf ein freigegebenes Dokument (z.B. in der Anwendung SharePoint) verweisen.

Abbildung 3.7: Integration Package anlegen

Abbildung 3.8: Dokumentation im Integration Package

Die eigentlichen Schnittstellen werden unter Artifacts angelegt. Sie können nun eine Auswahl aus drei Objekten treffen, die ich Ihnen in den nachfolgenden Abschnitten erläutern werde:

 Integration Flow

 OData-Service

 Value Mapping

Transporte

Beachten Sie, dass bei der Entwicklung von Schnittstellen der Transport zwischen den Tenants auf der Ebene der gesamten Integration Packages erfolgt, d.h., sämtliche Artefakte werden z.B. vom Entwicklungstenant zum Testtenant transportiert. Wie dies geschieht und welche Konzepte dabei relevant sind, betrachtet Abschnitt 3.6.

3.2.2 Integration Flow

Ein Integration Flow (auch: iFlow) stellt das wichtigste Element in der Schnittstellenentwicklung mit SAP CPI dar. Hier werden z.B. zwei Anwendungen durch Konnektivität (Übertragen von Nachrichten) und Transformation (Umwandeln von Nachrichten hinsichtlich Struktur, Format und Inhalt) miteinander verknüpft. Bei der Anlage eines Integration Flow geben Sie neben dem Namen auch eine Kurzbeschreibung an, die anschließend in der Paketübersicht angezeigt wird (siehe Abbildung 3.9). Zudem können Sie bei Bedarf einen Sender und Empfänger benennen; dies hätte jedoch eine rein dokumentierende Funktion und würde sich nicht auf das Design des grafischen Objektes auswirken.

Abbildung 3.9: Integration Flow anlegen

Weil es die gängigste Form einer Schnittstelle darstellt, wird das generierte Objekt zwar nicht zwangsläufig, aber in der Regel mit einem Sender, einem Integrationsprozess und einem Empfänger (Receiver) angelegt (siehe Abbildung 3.10); nach dem EVA-Prinzip (Eingabe, Verarbeitung, Ausgabe) der EDV wird auf diese Weise typischerweise eine Nachricht behandelt. Dennoch kann ein Integration Flow z.B. nur aus einem Integrationsprozess bestehen, der nicht durch eine eintreffende Nachricht gestartet wird, sondern durch ein zeitgesteuertes Ereignis, den Timer (siehe Events in Abschnitt 4.1), und keinen weiteren Empfänger aufruft, da nur eine CPI-interne Aktivität ausgeführt wird.

Abbildung 3.10: Integration Flow Template

Sie können eine Beschreibung hinterlegen, die den Ablauf der Schnittstelle im Detail erläutert. Häufig ist dies jedoch nicht notwendig, wenn die grafische Darstellung aussagekräftig genug ist. Letztere basiert dabei auf dem Modellierungsstandard BPMN 2.0 (Business Process Model and Notation). Wenn Sie die Elemente bereits kennen, ist dies sicherlich hilfreich. Falls nicht, werden Sie das Konzept schnell verinnerlichen. In Abschnitt 3.3 werden wir es näher betrachten.

Auf der Ebene des Integration Flow legen Sie zudem das Laufzeitverhalten (Runtime Configuration) fest. Hier können Sie auswählen, auf welcher Umgebung das Objekt »installiert« (deployed) werden soll (SAP CPI oder SAP Process Orchestration, siehe Abschnitt 8.4) oder ob z.B. HTTP Sessions aus Performancegründen wiederverwendet oder die Anmeldung bei einem auf dem HTTP-Protokoll basierten Empfänger immer vollständig durchlaufen werden soll (siehe Abbildung 3.11). On Exchange wird dabei für zustandsbehaftete Services verwendet, On Integration Flow für zustandslose (stateless) Services.

Abbildung 3.11: Wiederverwendung von HTTP-Sessions

Ein Integration Flow kann aus jeweils mehreren Integrationsprozessen, Sendern und Empfängern bestehen. Der Austausch von Nachrichten zwischen den Komponenten erfolgt hier grafisch durch das Verbinden der rechteckigen Kästen, indem per Drag-and-drop eine Linie gezogen wird. In Abbildung 3.12 wurde eine Verbindung vom Sender zum Start-Event des Integrationsprozesses hergestellt. Dabei erscheint ein Auswahlfenster, auf dem der zu verwendende Adapter (hier: HTTPS) zu selektieren ist. Anschließend können Sie die Adapter-spezifischen Eigenschaften des sogenannten Kommunikationskanals konfigurieren.

Abbildung 3.12: Integration Flow – Sender-Verbindung

Entsprechend ähnlich verfahren Sie bei der Konfiguration einer Verbindung hin zu einem Empfänger, indem Sie eine Linie vom End-Event zum Receiver ziehen (siehe Abbildung 3.13).

Abbildung 3.13: Integration Flow – Receiver-Verbindung

Abbildung 3.14 zeigt einen Integration Flow mit zwei Integrationsprozessen, die durch unterschiedliche Ereignisse gestartet werden. Beide rufen einen lokalen Integrationsprozess auf, der eine Wiederverwendung ermöglicht.

Abbildung 3.14: Integration Flow mit zwei Integrationsprozessen

Während der obere Integrationsprozess eine Nachricht via HTTPS vom Sender empfängt, ein Mapping ausführt und ein IDoc an den Empfänger sendet, startet der untere Integrationsprozess über einen Timer. Anschließend wird der sogenannte Data Store aufgerufen, um eine Nachricht zu lesen, das Mapping wird abgefragt und das Ergebnis in den Data Store geschrieben. Diese Darstellung soll Ihnen nur einen ersten Eindruck hinsichtlich der möglichen Komplexität und Interaktion der Elemente innerhalb eines Integration Flow vermitteln. Die einzelnen Elemente und Komponenten werden ausführlich in Kapitel 4 behandelt.

3.2.3 OData-Service

Ein OData-Service ermöglicht die Bereitstellung aufrufbarer Schnittstellen (APIs), die auf dem Open-Data-Protokoll basieren. Hierbei kann eine Senderanwendung (typischerweise eine UI5-HTML-Applikation) das Artefakt aufrufen. Ein Integration Flow kann zwar ebenfalls einen Sender via OData-Adapter anbinden, jedoch nur für eine einzelne Methode einer spezifischen Operation.

Der OData-Service von SAP CPI bietet die Option einer umfassenden Integration, deren Grundlage eine EDMX-Definition (Entity Data Model XML) darstellt und verschiedene Operationen gestattet. Der Service kann dabei basierend auf einem vorhandenen OData-Service oder einer SOAP (Simple Object Access Protocol) API generiert oder gänzlich neu angelegt werden. Zu jeder Methode werden sodann automatisch einzelne Integration Flows erstellt, die die tatsächliche Anbindung an ein Empfängersystem durchführen.

Abbildung 3.15: OData-Service – Definition

Abbildung 3.15 zeigt den Ablauf der Service-Definition mit den Optionen, ein OData-Modell aus einer Datenquelle zu importieren oder neu zu erstellen, indem die Metadaten (EDMX) manuell editiert werden.

Abbildung 3.16: OData-Service – Modell

In dem Beispiel aus Abbildung 3.16 wird eine EDMX mit zwei Entitäten verwendet: StockSet und PlantSet. Beide Entitäten bieten mehrere Operationen, um Daten aufzulisten (Query), anzulegen (Create), zu lesen (Read), zu ändern (Update) und zu löschen (Delete). Zu jeder Operation kann ein Integration Flow generiert werden, der via SOAP, REST oder OData eine Empfänger-Anwendung aufruft.

Abbildung 3.17: OData-Service – generierter Integration Flow

Abbildung 3.17 stellt einen generierten Integration Flow dar, der mit dem HTTP-Adapter erreicht wird. Er führt für die Query-Operation der Entität StockSet einen REST-Service im Zielsystem aus. Vor und nach diesem Aufruf ist zu erkennen, dass Skripte durchlaufen werden, die eine Nachricht jeweils verändern können. Hierbei handelt es sich um eine Vorlage, die Sie bei jedem neu angelegten Integration Flow Ihren Anforderungen entsprechend modifizieren können.

Im Grunde können Sie einen OData-Service als Gruppierung einzelner Integration Flows verstehen, die zueinander in Beziehung gesetzt werden können.

So sind auch komplexere Kombinationen möglich, z.B. indem ein generierter Integration Flow einen anderen Integration Flow aufruft. Diese Art der internen Kommunikation stelle ich Ihnen in Abschnitt 3.4.2 näher vor.

3.2.4 Value Mapping

Value Mappings ermöglichen die Konvertierung von Werten (typischerweise Codelisten) und werden innerhalb von Mapping-Programmen (Message Mappings) aufgerufen. Sie können sich ein Value-Mapping-Objekt wie eine Datenbanktabelle vorstellen, die Sie abfragen, um zu einem gegebenen Eingabewert einen Ausgabewert zurückzuerhalten. Beispiele hierfür sind etwa Währungsschlüssel oder Mengeneinheiten, die nicht immer nach ein und demselben ISO-Standard verwendet werden. Damit also z.B. ein proprietärer Währungsschlüssel »weuro1« in den ISO-Code »EUR« (nach ISO 4217) umgewandelt werden kann, erfassen Sie diesen Eintrag in einem Value Mapping. Dazu definieren Sie die Agency (den Herausgeber), den Identifier (das Objekt) und nehmen die entsprechenden Werte auf. Abbildung 3.18 zeigt Ihnen, wie das Artefakt angelegt wird. Pro Value Mapping können mehrere Zuordnungen für unterschiedliche Objekte erfasst werden, hier exemplarisch für die Währungsschlüssel und Mengeneinheiten dargestellt.

Abbildung 3.18: Value Mapping anlegen

Die Werte fügen Sie je erfasster und ausgewählter Zeile hinzu (siehe Abbildung 3.19).

Abbildung 3.19: Value Mapping – Werte zuordnen

Dabei sind auch Zuordnungen von N:1 möglich (wenn z.B. »weur1« oder »weur2« beide in den Wert »EUR« konvertiert werden), wobei die Zuordnungen grundsätzlich direktional funktionieren.

Falls Sie also einen Wert haben, dem mehrere Ergebnisse folgen können, wählen Sie den sogenannten Default Value aus (siehe Abbildung 3.20).

Abbildung 3.20: Value Mapping – Default Value

Der Aufruf erfolgt dann typischerweise aus einem grafischen Message Mapping, das ich Ihnen in Abschnitt 4.3.1 näher vorstelle.

3.3 Entwicklungsprozess

Die Entwicklung einer Schnittstelle sollte einem standardisierten Muster folgen; Sie sollten sich also folgende Fragen stellen:

 Wer sind die beteiligten Systeme/Anwendungen/Partner?

 Welche Kommunikationsprotokolle werden unterstützt?

 Welche Authentifizierung ist möglich?

 Welche Nachrichtenformate werden verwendet?

 Ist eine Transformation der Nachricht(en) notwendig?

 Gibt es besondere Anforderungen an die Verarbeitung?

 Wie soll mit Fehlersituationen umgegangen werden?

Je mehr Fragen Sie beantworten können, desto einfacher fällt Ihnen die Implementierung bzw. die (grafische) Modellierung eines Integration Flow.

3.3.1 Modellierung eines einfachen Integration Flow

Die beteiligten Akteure werden (analog zum BPMN-Standard) als »Pools« dargestellt, also als rechteckige Kästen, die eine Bezeichnung tragen. Im Integration Flow sind dies die Sender, Empfänger und Integrationsprozesse. Diese Pools interagieren miteinander durch Nachrichten, die ausgetauscht und durch Verbindungslinien visualisiert werden. Wir konzentrieren uns bei der Entwicklung auf das, was sich innerhalb der Integrationsprozesse abspielt bzw. beim Integrationsprozess zum Empfänger oder vom Sender hin zum Integrationsprozess (siehe Abbildung 3.21).

Abbildung 3.21: Integration Flow – Grundstruktur

Innerhalb eines Prozesses werden folgende Objekttypen verwendet:

 Ereignis (visualisiert durch einen Kreis)

 Aktivität (visualisiert durch einen rechteckigen Kasten)

 Gateway (Verzweigung, visualisiert durch eine Raute)

Ein Startereignis sorgt dafür, dass die Verarbeitung beginnt. Dies kann das Eintreffen einer Nachricht sein (Start-Event Message) oder auch nur ein Zeitpunkt (Start-Event Timer).

Im besten Fall nimmt das System keine Änderung der Nachricht vor, und dem Empfänger wird die Nachricht zugestellt. In diesem einfachen Beispiel werden lediglich ein Startereignis (Timer), ein Endereignis (Message) und ein Empfänger mit Mail-Adapter konfiguriert (siehe Abbildung 3.22).

Abbildung 3.22: Einfacher Integration Flow

Durch das Selektieren eines Objekts erscheint im unteren Bereich des Bildschirms eine Konfigurationsmöglichkeit. Der Timer kann z.B. hinsichtlich des Aufrufintervalls konfiguriert werden (hier wochentags zweistündlich zwischen 8 und 18 Uhr, siehe Abbildung 3.23).

Abbildung 3.23: Timer-Event-Konfiguration

Ebenso verfahren Sie mit den Verbindungslinien zwischen Event und System (hier E-Mail), um eine Verbindung zum E-Mail-Server herzustellen (siehe Abbildung 3.24).

Abbildung 3.24: Mail-Adapter-Konfiguration

Dabei müssen Sie berücksichtigen, dass der E-Mail-Server erreichbar sein muss, also im Internet oder On-Premise über einen Cloud Connector verfügbar gemacht wurde (siehe Abschnitt 3.7.4). Die Authentifizierung erfolgt hier über sogenannte Credentials, die hier nur als Alias angegeben werden und im Bereich Monitoring • Manage Security • Security Material angelegt werden (Details hierzu finden Sie in Abschnitt 3.7.1).