---

Einführung: Eine Beschreibung dieser Phase finden Sie im Abschnitt Phase 6 (Einführung). Siehe auch Abschnitt HTTP und Lobster_data.

---

Hinweis: Siehe auch Abschnitt Dateinamen, Dateimuster, Pfade, System-Konstanten und Variablen.

(1) Hier kann ein Kanal des Typs HTTP(S) ausgewählt werden. Hinweis: Wenn möglich, sollten immer Kanäle verwendet werden, damit Verbindungsparameter zentral verwaltet werden können. Neben der erhöhten Übersichtlichkeit erleichtert das auch die Pflege. Ändern sich die Verbindungsparameter, müssen Sie nur an einer Stelle nachpflegen und vergessen zudem auch kein Profil.

(2) Man kann ein eigenes Zertifikat als Client-Zertifikat zuordnen. Das Client-Zertifikat wird aber nur verwendet, wenn gleichzeitig die Option (12) aktiv ist.

(3) Rechnername oder IP-Adresse des Rechners (nicht die gesamte URL), auf dem der anzusprechende Webserver läuft und die zugehörige Portnummer. Ein Wert größer 0 beim Port, überschreibt den Wert, der im Kanal angegeben ist. Bei 0 wird der Port verwendet, der im Kanal angegeben ist. Hinweis: Gehen wir von dem kompletten HTTP-GET-Request-String http://www.google.com/search?q=test aus. Dann müssen Sie den Wert www.google.com in (3) angeben, den Wert search in (6) und den Wert q=test in (9).

(4) In einer DMZ-Umgebung wird die Verbindung vom DMZ-Server aus aufgebaut, anstelle vom internen Server. Hinweis: Das betrifft auch den OAuth-Token-Refresh, wenn ein Kanal (1) mit konfiguriertem OAuth angegeben wurde.

(5) Optionaler Wert für Benutzername und Passwort, die mit übergeben werden können. Für Windows-Benutzer mit NTLMv1- oder NTLMv2-Authentifizierung siehe auch Abschnitt Windows-Authentifizierung an einem HTTP-Server.

(6) Der Link, der auf dem Webserver (3) aufgerufen werden soll, ohne Query (9). Hinweis: Siehe Beispiel in (3).

(7) Hier können zusätzliche HTTP-Header eingefügt werden. Hinweis: Siehe auch Abschnitt Zusatzkennungen (im Kanal).

(8) Angabe der HTTP-Methode (GET, POST, PUT, PATCH, HEAD, DELETE). Hinweis: Wenn zum Beispiel die Methode GET verwendet wird, muss der Inhalt auf Kein Inhalt gesetzt werden.

(9) Query oder Message (Body), siehe Abschnitt Methode GET/Methode POST. Hinweis: Siehe Beispiel in (3).

(10) 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.

(11) Wenn das Profil einen Eingangsagenten des Typs HTTP(S) 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. 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.

(12) Bestimmt, ob der Webserver über SSL angesprochen werden soll. In diesem Fall wird HTTPS benutzt. Der Antwortweg arbeitet dann also als HTTPS-Client. Die Standard-Portnummer ist hier 443 anstelle 80

(13) Siehe Abschnitt Webservices.

(14) Siehe Abschnitt Multipart/Form-Data. Hinweis: Mit der System-Property -Dhub.datawizard.multipart.browserMode=true wird "browser compatible mode" erzwungen. Ist die Property nicht gesetz oder auf false, dann gilt "strict".

(15) Dateimuster, das den Namen der erstellten Datei angibt. Siehe (14).

(16) Wenn gesetzt, werden die Werte von Variablen im Feld (9) nicht URL-encodiert. Diese Option wirkt nicht, wenn Option (14) aktiv ist.

(17) Ist die Option aktiviert, kann die Response des Requests an ein Folge-Profil über eine synchrone, asynchrone oder persistente Message weitergeleitet werden. In diesem Fall wird die Überprüfung der Response, wie in (10) 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 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.

(18) Gibt im HTTP-Header den Content-Type an. 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.

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