Verarbeitung von Business-Daten mit dem Plain-HTTP-Adapter 

Einsatzmöglichkeiten

Der Plain-HTTP-Adapter ermöglicht das Empfangen und Verschicken von Business-Daten von Fremdsystemen über den Plain-HTTP-Eingang/Ausgang der Integration Engine.

Das Standard-Austauschformat für Daten in der Integration Engine ist XML. Mit dem Plain-HTTP-Adapter können jedoch auch Daten in HTML und ASCII verschickt und empfangen werden. In einem solchen Fall muss ein Java-Mapping verwendet werden.

Voraussetzungen

Der von SAP ausgelieferte HTTP-Service /sap/xi/adapter_plain muss dem Mandanten zugewiesen werden, in dem die Integration Engine betrieben wird.

Ablauf

Ein HTTP-Client sendet Business-Dokumente per HTTP an die Integration Engine. Daraus wird eine Message erzeugt, die an die Integration Engine übergeben wird. Ermittelt umgekehrt die Integration Engine einen Plain-HTTP-Empfänger, wird aus der Message ein Business-Dokument erzeugt und an den Empfänger versendet. Die Kommunikation erfolgt synchron (der Client erwartet eine Antwort auf seinen HTTP-Request) oder asynchron.

HTTP-Eingang der Integration Engine

Die Integration Engine wird von externen Systemen über eine HTTP-Adresse angesteuert. Hierzu existiert am HTTP-Eingang der Integration Engine der von SAP ausgelieferter HTTP-Service /sap/xi/adapter_plain.

Als Request Handler ist die Klasse CL_HTTP_PLAIN_INBOUND hinterlegt, die einen HTTP-Request synchron (Client erwartet eine Antwort) oder asynchron verarbeitet.

Multipart-Dokumente und HTTP-Requests mit einem leeren HTTP-Body werden nicht akzeptiert und erhalten eine Antwort mit Status-Code 500 bzw. 204.

Die obligatorischen Parameter der HTTP-Adresse werden analysiert und zum Aufbau der Message verwendet.

Obligatorische Parameter

Parameter	Bedeutung
service	Senderservice zur Identifikation des Absenders Beim XI-Message-Protokoll 2.0 entspricht dieser Parameter dem Parameter bs.
namespace	Namespace des sendenden Interfaces
interface	Interface der HTTP-Payload

http://sap-ag.com:8088/sap/xi/adapter_plain?service=sender&namespace=urn%3Asap-ag%2Ecom&interface=%2Fsap%2Forders

Sonderzeichen wie Schrägstrich (/), Bindestrich (-), Punkt (.) oder Doppelpunkt (:) müssen Sie mit Escape-Zeichen codieren (z. B. %2Ffür /, %2D für -, %2Efür . und %3A für :).

Die optionalen Parameter der HTTP-Adresse werden ebenfalls analysiert. Sie beeinflussen das Laufzeitverhalten der Message in der Integration Engine.

Optionale Parameter

Parameter	Bedeutung
party	Senderpartner (nur XI 3.0)
agency	Vergebende Agentur des Senders (nur XI 3.0)
scheme	Identifikationsschema des Senders (nur XI 3.0)
qos	Zustellungsart (Quality-of-Service) der Message: synchrone (BE) oder asynchrone (EO, EOIO) Verarbeitung; Voreinstellung ist die synchrone Verarbeitung
queueid	Name der Queue bei EOIO-Verarbeitung (nur XI 3.0)
msgguid	32-stellige Message-ID zur eindeutigen Identifikation einer Message in der Integration Engine; ist keine Message-ID angegeben, wird automatisch eine erzeugt

http://sap-ag.com:8088/sap/xi/adapter_plain?service=sender&namespace=urn%3Asap-ag%2Ecom&interface=%2Fsap%2Forders&qos=EO&msgguid=3C61F6C12F1E2DD1E10000000A1145AB

Sonderzeichen wie Schrägstrich (/), Bindestrich (-), Punkt (.) oder Doppelpunkt (:) müssen Sie mit Escape-Zeichen codieren (z. B. %2Ffür /, %2D für -, %2Efür . und %3A für :).

Optionale HTTP-Header-Felder werden ignoriert. Die Payload im HTTP-Body wird als Binary-Dokument in die Message gehängt. Die Payload sollte als XML-Dokument mit Codepage UTF-8 gesendet werden, damit alle Services der Exchange Infrastructure das Dokument verarbeiten können.

Die instanziierte Message wird an die Integration Engine übergeben. Im Modus BE (synchrone Verarbeitung) wird auf die Antwort der Integration Engine gewartet. Ist die Verarbeitung erfolgreich, wird die Payload der Message als HTTP-Response versendet. Ansonsten wird ein Fehler zurückgegeben.

Bei erfolgreicher Verarbeitung erhält der HTTP-Client den Return Code 200, ansonsten den Return Code 500 bzw. 409. Im Fehlerfall enthält das Error-Objekt der Message eine Fehlermeldung. Diese wird im synchronen Fall in den HTTP-Body der HTTP-Response gestellt; im asynchronen Fall wird sie dem HTTP-Request als Fehlerursache mitgeteilt.

HTTP-Ausgang der Integration Engine (HTTP-Empfänger-Adapter)

Der Plain-HTTP-Adapter wird von der Integration Engine aufgerufen, wenn das technische Routing für den logischen Empfänger einen entsprechenden Kommunikationskanal ermittelt. Dieser Kommunikationskanal stammt aus dem Integration Directory. Er wird analysiert und liefert die technischen Informationen für den HTTP-Request.

Die Main Payload der Message wird per HTTP-Post an eine HTTP-Adresse gesendet. Die technischen Daten für den HTTP-Post werden aus den Parametern des Kommunikationskanals ermittelt.

Für eine logische Destination wird ein HTTP-Client instanziiert, in dem folgende Daten gepflegt sind:

·        HTTP-Adresse

·        Daten des HTTP-Proxy

·        Authentifizierungseinstellungen

·        Security-Daten

Ist keine Destination angegeben, wird mit der gegebenen HTTP-Adresse und den Proxy-Daten ein HTTP-Client instanziiert. Mit User und Password in BASE64-Codierung wird eine Basic Authentication in die HTTP-Header-Felder eingetragen.

Die optionalen Header-Felder, die in den Parametern des Kommunikationskanals gepflegt wurden, werden in den HTTP-Header gesetzt.

Die Header-Felder Content Type (wenn nicht bereits explizit gesetzt) und Content Length sowie der Host werden standardmäßig gesetzt.

In die HTTP-Adresse wird der Senderpartner als Parameter party, agency und scheme, der Senderservice als Parameter service und das verwendete Interface als Parameter namespace und interface gesetzt. Abhängig vom aktuellen Quality-of-Service (qos) der Message wird noch der Parameter qos in der HTTP-Adresse ergänzt. Bei Quality-of-Service EOIO wird zusätzlich im Parameter queueid ein Queue-Name benötigt.

Der HTTP-Body wird aus der Verknüpfung von Vorspann (Prolog), Message Payload und Nachspann (Epilog) gebildet. Vorspann und Nachspann sind optional und dienen der Anreicherung der Payload bei bestimmten Servern (beispielsweise CGI-Servern). Soll die Payload als HTML-Formular per HTTP-Post gesendet werden, wird sie vor der Verknüpfung URL-escaped.

Entspricht die angegebene Codepage für den HTTP-Body nicht der Voreinstellung UTF-8, wird der HTTP-Body in die entsprechende Codepage gewandelt, und im XML-Dokument wird das Tag encoding=UTF-8 durch das entsprechende Codepage Tag ersetzt.

Ist der Quality-of-Service auf Best Effort gesetzt, wird auf eine Antwort des HTTP-Servers gewartet. Diese Antwort wird als neue Main Payload (gegebenenfalls mit Content Type) in die Message gehängt, während die alte Main Payload gelöscht wird.

Im Fehlerfall wird der Fehler in der Message protokolliert.