---

Einführung: Eine Beschreibung dieser Phase finden Sie im Abschnitt Phase 1 (Einführung).

---

Basis-URL: http(s)://<URL oder IP des Integration Servers>/dw/Request (Details in Punkt 1 unten).

(1) Der URL-Suffix. Die URL für dieses Profil ist dann http(s)://<URL oder IP des Integration Servers>/dw/Request/example. Siehe mehr Details in Abschnitt HTTP-Adresse von Lobster_data.

(2) Die erlaubten HTTP-Methoden. Hinweis: Siehe auch die System-Variablen MSG_CALL_HEADER_HTTP_(...).

(3) Der Eingangsagent fungiert als REST-Schnittstelle (HTTP-Methode GET verwenden). D. h., ist die URL des Eingangsagenten wie hier z. B. https://localhost/dw/Request/example, dann würde auch ein Request https://localhost/dw/Request/example/orders angenommen werden. Der zusätzliche Request-Suffix /orders wird dann in der System-Variable MSG_CALL_HTTP_PATH_DATA gespeichert. Ansonsten verhält sich der Eingangsagent wie bei einem "normalen" Request. Siehe auch (5).

(4) Erlaubt dem Profil als Webservice zu agieren. Siehe dazu die Abschnitte Profil als Webservice betreiben (ohne Rückmeldung) und Profil als Webservice betreiben (mit Rückmeldung). Setzen Sie auch die Checkbox Veröffentliche Schnittstelle für eine automatische WSDL-Erstellung.

(5) Ist diese Checkbox gesetzt und (3), aber nicht (4) und das Mapping ist aktiv, dann wird eine Swagger-/OpenAPI-Schnittstellenbeschreibung im JSON- oder YAML-Format bereitgestellt. Zudem kann in (6) der Name einer hinterlegten Testdatei angegeben werden, deren Daten dann mit angezeigt werden. Beispiel: https://localhost/dw/Request/example?api bzw. https://localhost/dw/Request/example?api&yaml

Zudem wird Ihnen in einem graphischen Tool eine Swagger-/OpenAPI-Schnittstellenbeschreibung im YAML-Format bereitgestellt. Dort können Sie Requests an die Schnittstelle senden. URL: http(s)://<URL oder IP des Integration Servers>/api/?endpoint=<URL-Suffix>

Beispiel: https://localhost/api/?endpoint=example

Siehe allgemein Abschnitt System-Interaktion per HTTP (REST API) (Anleitung dort).

(6) Siehe (5).

(7) Content-Type der Antwort.

(8) Optionaler Name des Multiparts für die Hauptdaten. Normalerweise wird immer nach dem Part mit dem Namen file gesucht. Sollte der Name aber nicht file sein, kann man den alternativen Part-Namen hier eintragen. Hinweis: Dies gilt nur für Multipart-Requests und wenn kein Part mit dem Namen file gefunden wurde! Siehe auch den Abschnitt unten.

(9) Ein leerer HTTP-Body wird nicht als Fehler gesehen.

(10) und (11) Die Antwort im Erfolgsfall kann auf zwei verschiedene Arten gesendet werden:

• Durch festen Wert (11): Es soll hier eine statische Antwort gesendet werden.

• Alternativ kann die Antwort dynamisch durch eine eigene Klasse im Antwortweg (10) erzeugt werden oder durch die Option Daten zurückliefern in den Antwortwegen HTTP und Message. Siehe hierzu speziell Abschnitt HTTP-Response-Kette.

Wichtiger Hinweis: Mit der System-Variable VAR_RESPONSE_HTTP_HEADER_RESP_STATUS kann der HTTP-Response-Status gesetzt werden. Bei gesetzter Option (10) wird diese Variable ausgewertet und der HTTP-Response-Status von der Klasse gesetzt. Siehe allgemein auch VAR_RESPONSE_HTTP_HEADER_<Name des Response-Headers>.

Hinweis: Zeilenumbrüche können eingefügt werden mit <br>.

(12) Antwort, die im Fehlerfall gesendet wird. Hinweis: Es kann hier auch der Platzhalter {--Exception--} verwendet werden, um eine aufgetretene Exception zurück zu geben. Enthält die Exception-Meldung einen Teilstring §...§, dann wird der Platzhalter durch den Teilstringtext ersetzt. Beispiel: Wenn Sie in Phase 3 des Profils die Funktion throw exception("§Sorry!§") aufrufen, dann wird der Platzhalter {--Exception--} durch den String Sorry! ersetzt. Alternativ kann der Platzhalter {--FullStackTraceException--} verwendet werden, um den vollen Stacktrace auszugeben.

(13) Der HTTP-Status-Code, der im Fehlerfall zurückgeschickt wird.

(14) Entweder ohne Zugangskontrolle oder mit Zugangskontrolle über einen oder mehrere ausgewählte HTTP-Kanäle oder mit direkt angegebenen Zugangsdaten. Siehe auch System-Variable MSG_CALL_HTTP_AUTH_USER.

(15) Festlegung der Request-Parameter. Zum Zugriff auf die Parameter im Profil über Variablen siehe Abschnitt HTTP-Request-Parameter und HTTP-Header.

(16) Diese Vorlagen erhalten Sie im Update-Center.

Hinweis: Die System-Variable MSG_CALL_HEADER_HTTP_METHOD wird gefüllt mit der Methode des HTTP-Requests (z. B. GET, POST, ...), um dem Profil das Erkennen der Aufrufmethode zu ermöglichen. Das HTTP-Servlet, das den Request an das Profil weiterleitet, wird beim Start von Lobster_data automatisch gestartet und reagiert per Default auf den HTTP-Kontext /dw/Request bzw. /dw/request. Die nachfolgende Komponente /<suffix> in der URL ergibt sich aus dem URL-Adressen-Suffix (1). Das Servlet sucht zunächst das korrekte Profil zum eingegangenen Request. Dabei werden alle Profile durchsucht, die einen HTTP-Eingangsagent haben und deren URL mit dem Wert aus (1) endet.

Zusätzlich müssen die HTTP(S)-Request-Parameter zur HTTP(S)-Request-Parameter-Festlegung (15) passen. Das erste zutreffende Profil wird vom Servlet ausgewählt und die Verarbeitung angestoßenen. Falls weitere Profile die Bedingungen erfüllen, werden diese Profile nicht berücksichtigt.

Beispiel: HTTP-Requests mit der folgenden URL führen zu einem Aufruf des Profils mit dem Eingangsagenten oben und folgender Request-Parameter-Konfiguration.

Dabei bezeichnet host den DNS-Namen oder die IP-Adresse des Rechners, auf dem Lobster_data (bzw. der Integration Server) läuft und port den Port, an dem der HTTP(S)-Service von Lobster_data hört.

Hinweis: Bitte beachten Sie auch den Abschnitt URL-Context systemweit definieren.