Antwortweg HTTP(S)
Einstellungen
(1) Vorlage wählen: Diese Vorlagen erhalten Sie im Update-Center.
(2) Kanal-Auswahl: Hier kann ein Kanal des Typs HTTP ausgewählt werden.
(3) Zertifikats-Auswahl: Man kann ein eigenes Zertifikat als Client-Zertifikat zuordnen. Das Client-Zertifikat wird aber nur verwendet, wenn HTTPS (8) verwendet wird.
(4) HTTP-Methode: Angabe der HTTP-Methode ( GET , GET (with content) , POST , PUT , PATCH , DELETE , DELETE (with content) , HEAD ) . Hinweis: Wenn zum Beispiel die Methode GET verwendet wird, muss der Inhalt auf "Kein Inhalt" gesetzt werden.
(5) HTTP-Header anpassen: Hier können zusätzliche HTTP-Request-Header eingefügt werden. Sowohl für den Header-Namen, als auch für den Wert können Variablen ausgewertet werden. Syntax: @<Variablenname>@. Siehe auch Abschnitt Request-Header unten. Zudem ist es möglich in einer Variable mehrere Header mit Werten zu übergeben. Geben Sie dazu im Dialog den HTTP-Header dyn_header_entries ein und als Wert den Namen der Variable (umrandet mit @-Zeichen, also z. B. @var__myHeader@), die die Header und Header-Werte enthält. Hinweis: Wird ein Kanal verwendet, können Header auch dort in den Zusatzkennungen definiert werden.
Der Inhalt der Variable (hier var__myHeader) muss folgendermaßen aufgebaut sein:
|
Headername1:Headerwert + Zeilenumbruch (\n oder \r\n) |
Verwenden Sie dazu die Funktionen concat(a,b,c,d,e,f,g,h, [CR-support i]) und save variable a(b) type-safe.
(6) Ist ein SOAP-WS Aufruf: Siehe Abschnitt SOAP-Webservices.
(7) Multipart/Form-Data: Siehe Abschnitt "Multipart/Form-Data" unten.
(8) Protokoll-Auswahlfeld ("HTTP" oder "HTTPS"). Siehe auch Abschnitt Lobster Integration als HTTPS-Client.
(9) Zielrechner: Domainname oder IP-Adresse des Servers (nicht die gesamte URL).
(10) Port: Ein Wert größer 0 überschreibt den Wert, der im Kanal angegeben ist (fall einer ausgewählt ist). Bei 0 wird der Port verwendet, der im Kanal angegeben ist.
(11) HTTP URI: Der Pfad, der auf dem Server aufgerufen werden soll. Hinweis: Der Platzhalter <serverurl> wird ersetzt durch den URI-Anteil des Wertes des Kanal-Feldes "Partner Adresse", falls ein Kanal (2) ausgewählt wurde.
(12) Zauberstab-Icon links. Wizard zur Eingabe der kompletten URL.
(13) Query oder Body: Abhängig von der HTTP-Methode (4) und dem für den Antwortweg eingestellten Inhalt ("Kein Inhalt" oder andere Einstellung). Hinweis: Es können auch die kompletten, während des Mappings erzeugten Daten in eine GET-Query aufgenommen werden. Dies geschieht mit dem Platzhalter <http-data>. Beachten Sie bitte zudem, dass dann für den Inhalt des Antwortwegs nicht "Kein Inhalt" eingestellt sein darf.
Antwortweg hat als Inhalt "Kein Inhalt" eingestellt:
|
HTTP-Methode (4) |
Datenziel |
|
GET |
Feld-Daten landen in Query. |
|
GET (with content) |
Feld-Daten landen in Body. |
|
POST |
Feld-Daten landen in Body. |
|
PUT |
Feld-Daten landen in Body. |
|
PATCH |
Feld-Daten landen in Body. |
|
DELETE |
Feld-Daten landen in Query. |
|
DELETE (with content) |
Feld-Daten landen in Body. |
|
HEAD |
Feld-Daten landen in Query. |
Antwortweg hat als Inhalt nicht "Kein Inhalt" eingestellt:
|
HTTP-Methode (4) |
Datenziel |
|
GET |
Fehler, wenn nicht <http-data> im Feld verwendet wird. Mit <http-data> landet der Inhalt des Antwortweges in der Query. |
|
GET (with content) |
Wenn nicht <http-data> verwendet wird im Feld, landen die Felddaten in der Query und der Inhalt des Antwortweges im Body. Mit <http-data> landet nur der Inhalt des Antwortweges im Body. |
|
POST |
Wenn nicht <http-data> im Feld verwendet wird, landen die Felddaten in der Query und der Inhalt des Antwortweges im Body. Mit <http-data> landet nur der Inhalt des Antwortweges im Body. |
|
PUT |
Wenn nicht <http-data> im Feld verwendet wird, landen die Felddaten in der Query und der Inhalt des Antwortweges im Body. Mit <http-data> landet nur der Inhalt des Antwortweges im Body. |
|
PATCH |
Wenn nicht <http-data> im Feld verwendet wird, landen die Felddaten in der Query und der Inhalt des Antwortweges im Body. Mit <http-data> landet nur der Inhalt des Antwortweges im Body. |
|
DELETE |
Fehler, wenn nicht <http-data> im Feld verwendet wird. Mit <http-data> landet der Inhalt des Antwortweges in der Query. |
|
DELETE (with content) |
Wenn nicht <http-data> im Feld verwendet wird, landen die Felddaten in der Query und der Inhalt des Antwortweges im Body. Mit <http-data> landet nur der Inhalt des Antwortweges im Body. |
|
HEAD |
Fehler, wenn nicht <http-data> im Feld verwendet wird. Mit <http-data> landet der Inhalt des Antwortweges in der Query. |
(14) Via DMZ: In einer DMZ-Umgebung wird die Verbindung vom DMZ-Server aus aufgebaut, anstelle vom internen Server. Falls kein DMZ konfiguriert ist, wird diese Checkbox nicht angezeigt. Hinweis: Das betrifft auch den OAuth-Token-Refresh, wenn ein Kanal (2) mit konfiguriertem OAuth angegeben wurde.
(15) Benutzer/Kennwort: Optionaler Wert für Benutzername und Passwort, die mit übergeben werden können. MS-IIS mit Authentifizierung durch NTLM-v1 oder NTLM-v2:
Falls der HTTP-Server, zu dem eine Verbindung hergestellt werden soll, ein MS-IIS ist und eine integrierte Windows-Authentifizierung vom Typ NTLM Version 1 oder 2 erwartet, kann dem Usernamen ein Domänen-Name vorangestellt werden. Im Feld für den Benutzernamen wird dann folgende Syntax erwartet (bitte doppelten Backslash beachten).
|
domain\\user |
(16) Content-Type: Der MIME-Type (Header "Content-Type"). Hinweis: Per Default wird im Content-Type auch das Encoding (aus den Einstellungen des Antwortwegs) angegeben, z. B. application/octet-stream;charset=ISO-8859-1. Möchte man das unterbinden, dann kann man stattdessen im Feld den Wert application/octet-stream;raw angeben, dann wird für den Content-Type lediglich der Wert application/octet-stream verwendet.
(17) Erwartete Rückmeldung: Gibt die erwartete HTTP-Response an. Weicht die Antwort ab, wird der Aufruf als fehlerhaft und damit der Antwortweg als fehlgeschlagen bewertet. Wenn der eingetragene Wert mit regex: beginnt, wird der Wert als regulärer Ausdruck ausgewertet. Diese Einstellung wird aber ignoriert, wenn (18) oder (20) gesetzt ist.
(18) Daten zurückliefern: Wenn das Profil einen Eingangsagenten des Typs "HTTP" hat, kann mit dieser Option die Response samt HTTP-Headern an den externen Client, der den Request an das Profil gesendet hat, zurückgegeben werden. Siehe dazu auch den Abschnitt Profilketten. Alternativ kann die Response auch von einem Folge- oder Fehler-Profil erzeugt werden, siehe (20). Hinweis: Bekommt man keinen HTTP-Status-Code 2xx zurück, und die Option Gesamten Job als gescheitert melden, wenn dieser Antwortweg fehlgeschlagen ist ist nicht gesetzt, dann gilt der Antwortweg dennoch als erfolgreich. D. h. der HTTP-Status-Code und auch ein evtl. vorhandener Payload werden an den Eingangsagenten zurückgeschickt. Das klappt aber nur, wenn alle anderen Antwortwege (falls vorhanden) erfolgreich sind. Hinweis: Siehe auch Abschnitt Zustand der Phase 6 - Verhalten im Fehlerfall.
(19) Kein URL-Encode von Variablen: Wenn gesetzt, werden die Werte von Variablen im Feld (13) nicht URL-encodiert. Diese Option wirkt nicht, wenn Option (7) aktiv ist.
(20) HTTP-Antwort per Message weiterleiten: Ist die Option aktiviert, kann die Response des Requests an ein Folge-Profil über eine synchrone, asynchrone, persistente (oder direkte) Message weitergeleitet werden. In diesem Fall wird die Überprüfung der Response, wie in (17) eingestellt, nicht durchgeführt, es wird aber ein Fehler ausgelöst, wenn die Rückmeldung keine Nutzdaten (Payload) enthält. Damit kann man also erzwingen, dass die weitergeleitete Antwort Nutzdaten enthält. Die Response kann auch im Fehlerfall (HTTP-Status >= 300) an ein Fehler-Profil weitergeleitet werden. Das ist vor allem für SOAP-Webservices wichtig, weil dort die Fault-Response mit HTTP Error 500 gesendet werden muss. Hinweis: Der HTTP-Statuscode (z. B. 200, 404, ...) kann über die System-Variable MSG_CALL_VAR_RESPONSE_HTTP_HEADER_STATUS_CODE in einem Folge-/Fehler-Profil abgerufen werden. Hinweis: Wenn Sie Daten (HTTP-Response) zurück liefern möchten, siehe (18), kann dies auch über ein Folge- oder Fehler-Profil erfolgen. Der Message-Typ muss dann aber Direkt sein (Typ gibt es nur in diesem Antwortweg). Zudem muss im Folge-/Fehler-Profil dann auch eine der Antwortweg-Klassen (PassBackDataResponse, DefaultWebServiceResponse, PassBackBinaryDataResponse, DefaultWebServiceResponseBinary) verwendet werden. Siehe auch Abschnitt Profilketten.
(21) Standardantwort: Wenn die HTTP-Response keine Body-Daten enthält, führt dies zu einem Fehler im nachfolgenden Profil (20). Um dies zu vermeiden, können Sie Default-Body-Daten definieren, die in diesem Fall verwendet werden.
(22) Gesamten Job als gescheitert melden, wenn dieser Antwortweg fehlgeschlagen ist: Normalerweise gilt ein Job nicht notwendigerweise als fehlerhaft, wenn ein einzelner Antwortweg fehlschlägt (siehe Abschnitt Verhalten im Fehlerfall). Das kann hier aber mit dieser Option erzwungen werden.
(23) Zusätzlicher Text bei Fehler: Hier kann ein zusätzlicher Log-Text für den Fehlerfall angegeben werden.
Multipart/Form-Data
Zum Erzeugen eines Multipart-Requests. Es können Parts bzw. Datei-Parts eingefügt werden.
|
HTTP Methode |
Unterstützt werden nur die HTTP-Methoden (4) POST, PUT, PATCH und DELETE (with content). Wenn eine falsche Methode verwendet wird, wird automatisch die Methode POST eingestellt. |
|
Multipart mode |
Erlaubte Werte: STRICT, RFC6532, COMPATIBLE, SYSTEM. Header: STRICT (Content-Disposition, Content-Type, Content-Transfer-Encoding), RFC6532 (Content-Disposition, Content-Type, Content-Transfer-Encoding), COMPATIBLE (nur Content-Disposition und zusätzlich Content-Type bei einem Datei-Part). Der Multipart Mode bei der Verwendung des Wertes SYSTEM wird bestimmt durch die System-Property -Dhub.datawizard.multipart.browserMode. Bei -Dhub.datawizard.multipart.browserMode=true gilt COMPATIBLE. Ist die Property nicht gesetzt oder auf false, dann gilt STRICT. |
|
Ist Datei |
Wenn nicht gesetzt, wird ein Part eingefügt. Wenn gesetzt, dann ein Datei-Part. |
|
Schlüssel |
Muss gesetzt werden. Der Schlüssel ist jeweils beliebig, aber muss eindeutig sein. Hinweis: Wird hier der Wert dyn_multipart_entries angegeben (auswählbar in der Liste), dann wird der angegebene Wert in n Multiparts zerlegt zur Laufzeit. Beim Wert wird dabei in der Regel eine Variable angegeben, z. B. @MY_VAR@. Der Wert der Variable muss dabei folgendermaßen aufgebaut sein: dynPart1=1&dynPart2=2&dynPart3=3 Zur Laufzeit würden dann folgende drei Parts eingefügt werden: dynPart1=1 Ist der Wert der Variable leer, wird nichts eingefügt. Der Content-Type und das Encoding der Parts wird vom Haupteintrag übernommen. Hinweis: Der Wert der Variable darf nicht URL-encoded sein. Zudem ist zu beachten, dass das &-Zeichen als Steuerzeichen für das Splitting verwendet wird und daher mit & escaped werden muss, um es im Wert eines Parts verwenden zu können. Aus dem Variablen-Inhalt dynPart1=1&dynPart2=2&dynPart3=&3 werden also folgende drei Parts: dynPart1=1 |
|
Wert/Dateipfad |
Der Inhalt der Spalte Wert/Dateipfad wird als Part eingefügt. Wenn Sie die Checkbox Ist Datei setzen, dann wird als Datei-Part eingefügt. Wird in der Spalte Wert/Dateipfad das Präfix file: verwendet, z. B. file:./webapps/root/upload/my.pdf, dann wird zur Laufzeit die Datei ./webapps/root/upload/my.pdf geladen und als Datei-Part eingefügt. Hier ist der Haken bei Ist Datei zu setzen. Sie können mit file:<http-data> auch die Daten des Antwortweges verwenden. Beachten Sie bitte, dass dann die Spalte Encoding ignoriert wird und das Encoding des Antwortwegs verwendet wird (→ siehe Inhalts-Einstellungen). |
|
Dateiname |
Der Dateiname ist optional. Wird das Präfix file: verwendet in Wert/Dateipfad, dann ersetzt der angegebene Dateiname den Namen der hochgeladenen Datei. Wenn Sie Dateiname benutzen, dann müssen Sie die Checkbox Ist Datei setzen. Hinweis: Es können Platzhalter wie <n> und <yyyy> verwendet werden. |
|
Content-Type |
Muss gesetzt werden. Hinweis: Per Default wird im Content-Type auch das Encoding angegeben, z. B. application/octet-stream;charset=ISO-8859-1. Möchte man das unterbinden, dann kann man stattdessen im Feld den Wert application/octet-stream;raw angeben, dann wird für den Content-Type lediglich der Wert application/octet-stream verwendet. Hinweis: Im Header Content-Transfer-Encoding wird per Default der Wert binary für Datei-Parts und 8bit für Parts verwendet. Das kann im Content-Type überschrieben werden mit dem Suffix #, z. B. application/octet-stream#7bit oder application/octet-stream;raw#7bit (nur in dieser Reihenfolge). |
|
Encoding |
Das Encoding ist optional, bei Parts wird per Default UTF-8 verwendet. |
Request-Header
Zusätzliche Request-Header können über (5) eingefügt werden. Wird ein Kanal (2) verwendet, können dort ebenfalls Request-Header gesetzt werden, siehe Abschnitt Zusatzkennungen (im Kanal). Wird ein gleichnamiger Header gesetzt, hat der im Profil gesetzte Vorrang.
Hinweis: Sie können den Header Set-Cookie verwenden, um Cookies zu schreiben.
Response und Response-Header
Da wir hier im Antwortweg praktisch am Ende des Profils sind, ist eine Auswertung der Response hier nur bedingt möglich, Sie können aber über (17) den erwarteten Inhalt der Response definieren.
Zudem ist es möglich, die Response an ein Folgeprofil weiterzuleiten. Siehe hierzu Punkt (20). Dort können Sie dann auch die System-Variablen MSG_CALL_VAR_HTTP_STATUS_CODE, MSG_CALL_VAR_HTTP_STATUS_LINE und MSG_CALL_VAR_HTTP_<Name des Headers in Großbuchstaben> verwenden.
Wenn das Profil einen Eingangsagenten des Typs "HTTP" hat, kann mit der Option (18) die gesamte Response an den externen Client, der den Request an das Profil gesendet hat, zurückgegeben werden.
Raw Request/Response
Wenn Sie bei Verwendung der HTTP-Methode POST (speziell bei Multipart) den Raw Request und die Raw Response (und die jeweiligen Header) zu Testzwecken sehen möchten, finden Sie diese in der Log-Übersicht als Base64-kodierten String, wenn Sie die Trace-Meldungen für Phase 6 in der Logging-Konfiguration aktivieren. Dekodieren können Sie diesen mit dem Plugin Enkodierer/Dekodierer. Alternativ können Sie natürlich auch externe Tools wie z. B. https://requestcatcher.com/ verwenden.