BTP - Inbound und Outbound Kommunikation
In diesem Artikel gehen wir im Detail auf die Anbindung des SAP BTP ABAP Environment ein und wie die einzelnen Verbindungen erzeugt werden.
Inhaltsverzeichnis
Wie nutzt du das ABAP Environment in der BTP um die Kommunikation nach außen herzustellen oder auch selbst APIs im ABAP Environment zu konsumieren? In diesem Artikel einige Details mehr.
Einleitung
Wenn du mit dem ABAP Environment in der BTP arbeitest wirst du an einen Punkt kommen, da möchtest du eine Kommunikation zu einem anderen System aufbauen oder eine API zur Verfügung stellen, die ein anderes System konsumieren soll. Im Falle des ABAP Environment gibt es hier zwei gängige Szenarien: Inbound und Outbound Kommunikation. Dabei schauen wir aus der Sicht des ABAP Environment, wenn wir uns die beiden Szenarien anschauen.
Für die Szenarien verwenden wir die folgenden Ikonen mit der folgenden Legende. Dabei unterschieden wir zwischen Objekten die über die ADTs angelegt werden oder die nur Customizing im System sind. Hierbei handelt es sich nicht u genormte BTP Solution Diagrams, sondern wir verwenden nur die Layouts und Ikonen.
Outbound
Die Outbound Kommunikation geht vom ABAP Environment aus und baut Kontakt zu On-Premise oder einem Web-Service auf. Dabei benötigen wir in den meisten Fällen einen Zugang zu einem anderen System. Dazu die folgende Übersicht zum Aufbau.
Ablauf
Vom Ablauf her legen wir zuerst die nötigen Entwicklungsobjekte im ABAP Environment an, um im Abschluss dann das Customizing über die Fiori Apps durchführen zu können, um eine Verbindung Richtung Zielsystem aufbauen zu können. Die Freigaben und Ressourcen sollten bereits im Cloud Connector vorhanden sein.
Entwicklungsobjekt
Für dieses Szenario müssen wir einen Outbound Service anlegen, diesen können wir dann entsprechend einem Protokoll zuordnen. So gibt es aktuell die folgenden Protokolle für die Kommunikation.
Im Anschluss können wir dann das Communication Scenario im System anlegen. Dort ordnen wir im Bereich "Outbound" unseren Service zu. Im Bereich "Overview" können wir noch weitere Attribute erzeugen, wenn wir zwischen verschiedenen Services und Zielsystemen unterscheiden wollen.
Hinweis: Über "Publish Locally" muss das Objekt freigegeben werden, da es sonst in den Apps und dem Customizing nicht sichtbar ist.
Customizing
Sind alle erforderlichen Objekte angelegt und auch freigegeben, können wir das Customizing anlegen. Dazu benötigen wir die beiden Anwendungen "Communication Systems" (F1762) und "Communication Arrangements" (F1763), um die nötigen Einstellungen zu definieren.
Über "Communication Systems" definieren wir das System, auf das wir zugreifen wollen, hier können wir über die unterschiedlichen Einstellungen direkt Systeme auf der BTP einbinden. In unserem Beispiel verwenden wir den Destination Service im BTP Subaccount. Der Vorteil des Destination Service ist die zentrale Konfiguration im Subaccount, vor allem wenn du hier noch ein Business Application Studio (BAS) oder andere Services hast, die die Verbindung zum Zugriff und für das Deployment benötigen. Entsprechende User, Passwörter und Einstellungen sind daher im Destination Service hinterlegt.
Zum Abschluss legen wir über "Communication Arrangements" die Konfiguration zum Communication Scenario an und ordnen das angelegt Communication System zu oder nutzen ein bereits vorhandenes System.
Cloud Connector
Um aus der BTP dann auf dein On-Premise System zugreifen zu können, muss das virtuelle System im Cloud Connector auf das On-Premise System gemappt sein. Entsprechende Konfigurationen, Firewall-Freigaben und Servicefreigaben sind hier inbegriffen. Hier empfehlen wir eine explizite Freigabe von Ressourcen und keine Freigabe von Ressourcen mit Wildcard (*), damit wird genau gesteuert, wer von außen auf welchen Service zugreifen kann.
Beispiel
In dem Blog zur Anbindung eines On-Premise OData Service findest du eine Schritt-für-Schritt Anleitung zur Anlage der Objekte.
Inbound
Bei der Inbound Kommunikation werden wir als ABAP Environment von außen gerufen. Dazu benötigt der Aufrufer einen technischen Zugriff auf das System und eine Möglichkeit zur Anmeldung. Als Entwickler stellen wir verschiedene Objekte zur Verfügung, damit Services im System aufgerufen werden können.
Ablauf
Im ersten Schritt müssen wir als Entwickler wieder ein entsprechendes Szenario zur Verfügung stellen, damit das Customizing dafür angelegt werden kann. Zum Abschluss erhält dann der Aufrufer die Zugangsdaten, um sich am ABAP Environment anzumelden und die Ressourcen nutzen zu können.
Entwicklungsobjekt
Zuerst einmal müssen wir einen OData Service oder einen RFC Funktionsbaustein im System anlegen, ein Service der von außen konsumiert werden kann. Hier bietet sich die Web-API OData v2 oder v4 an. Im Anschluss benötigen wir ein Communication Scenario, wo wir im Reiter "Inbound" alle Objekte zuordnen können. Im Reiter "Authorization" ordnen wir Berechtigungen zu, die der User später benötigt, um mit dem Service und den Daten zu arbeiten. Damit geben wir dem technischen User später die Berechtigungen, die er braucht.
Hinweis: Über "Publish Locally" muss das Objekt freigegeben werden, da es sonst in den Apps und dem Customizing nicht sichtbar ist.
Customizing
Sind alle erforderlichen Objekte angelegt und auch freigegeben, können wir das Customizing anlegen. Dazu benötigen wir die drei Anwendungen "Maintain Communication Users" (F1338), "Communication Systems" (F1762) und "Communication Arrangements" (F1763), um die nötigen Einstellungen zu definieren. Die Reihenfolge ist so weit egal, wie wir die Konfigurationen anlegen.
Über "Maintain Communication Users" können wir einen technischen User (CC*-BP-User) anlegen und ein Passwort vergeben. Den User müssen wir der aufrufenden Seite zur Verfügung stellen, ebenso das Passwort.
Dann legen wir über "Communication Systems" ein System an, welches wir als "Inbound Only" deklarieren. Hier können wir dann den technischen User zuordnen.
Im letzten Schritt legen wir "Communication Arrangements" die Konfiguration für das Communication Scenario an und ordnen das Communication System zu. Der technische User sollte nun in den Details auftauchen, ebenso die freigegebenen Services auf die der technische User dann Zugriff hat.
Beispiel
Ein ausführliches Beispiel zum Aufruf eines Services auf dem ABAP Environment findest du im Detail in einem Blog von uns. Dabei greifen wir aus On-Premise auf das ABAP Environment zu.
Fazit
Mit dem Artikel wollten wir die Begriffe Inbound und Outbound etwas genauer beschreiben und wie du die beiden Szenarien für deine Entwicklung nutzen kannst. Damit sollten dir die beiden Kommunikationswege für das ABAP Environment etwas klarer sein.
