Trigger/Externer Aufruf
Einführung: Eine Beschreibung dieser Phase finden Sie im Abschnitt Phase 1 (Einführung).
Das Profil kann entweder durch ein anderes Profil oder einen HTTP-Request (über ein HTTP-Servlet in Lobster_data) getriggert werden (per GET oder POST). Dabei handelt es sich um eine Eventsteuerung. Im Gegensatz zu den normalen Profilen mit zeitgesteuerten Eingangsagenten können hier parallel mehrere Jobs pro Profil abgearbeitet werden.
Die folgende Abbildung zeigt die Konfigurationsmaske für die Einstellung eines Triggers per HTTP-Request in einem zeitgesteuerten Eingangsagent.
(1) Wird diese Option gewählt, kann das Profil durch ein beliebiges anderes Profil getriggert werden. Hinweis: Siehe auch Abschnitt Zweite Möglichkeit - Message und Trigger zum Thema Profil-Ketten. Hinweis: Ist die Checkbox Kann auf jedem Server getriggert werden nicht gesetzt und ist zudem die Checkbox Profil darf nur in einer Instanz laufen nicht gesetzt und ist kein Wert in Feld Nur auf IS starten eingetragen, dann wird in einem Load-Balancing-System erzwungen, dass ein getriggerter Cronjob auf dem Working Node verbleibt, auf dem er getriggert wurde. Siehe auch Abschnitt Einstellungen für Profile (Load Balancing). Hinweis: Es kann hier ein optionaler Kontext (Default: System) und eine optionale Queue (Default: DWForwardReceiver) angegeben werden. Allerdings müssen diese Werte dann auch beim aufrufenden Profil angegeben werden, sonst läuft die Kommunikation weiterhin über die Default-Werte.
(2) Gibt an, ob das Profil durch einen HTTP-Request (GET oder POST) getriggert werden kann, siehe auch (3), (4), (5). Ist diese Option aktiviert, funktioniert der Aufruf durch ein vorgeschaltetes Profil auch weiterhin. Hinweis: Siehe auch die System-Variablen MSG_CALL_HEADER_HTTP_(...).
(3) Gibt die Zeichenkette an, mit der der HTTP-Request enden muss. Siehe weiter unten. Hinweis: Wurde eine Datei <URL suffix>.ok oder <URL suffix>.err angelegt (siehe unten), dann erscheinen hier Icons für diese, über die man die Dateien editieren kann. Erzeugt werden können diese Dateien direkt über das Bleistift-Icon.
(4) Ist diese Option aktiviert, dann wird erst dann eine HTTP-Response zurück geliefert, wenn der Job für das Profil beendet wurde. Achtung: Wenn der Job sehr zeitintensiv ist, kann die Gegenstelle des HTTP-Request in einen Timeout laufen.
(5) Diese Checkbox ist nur auswählbar, wenn (4) gesetzt ist. Ist diese Checkbox gesetzt und im Antwortweg wird eine der eigenen Klassen PassBackDataResponse, PassBackBinaryDataResponse, DefaultWebserviceResponse oder DefaultWebserviceResponseBinary verwendet, dann werden in der HTTP-Response die Daten der Klasse geschickt. Siehe auch Abschnitt Profil-Ketten. Hinweis: Sind zusätzlich Variablen der Form VAR_RESPONSE_HTTP_HEADER_<HEADERNAME> angelegt, dann werden entsprechende Response-Header mit den Initialwerten der Variablen gesetzt. Beispiel: Die Variable VAR_RESPONSE_HTTP_HEADER_TEST mit dem Initialwert mytest erzeugt den HTTP-Response-Header TEST mit dem Wert mytest.
(6) Hier kann der MIME-Type der HTTP-Response angegeben werden. Hinweis: Für normalen Text können Sie den Default-Wert text/html verwenden.
(7) Festlegung von Pflicht-Parametern von Requests. Eine detaillierte Beschreibung finden Sie in Abschnitt HTTP-Request-Parameter und HTTP-Header. Beim Wert können auch System-Konstanten ausgewählt werden. Hinweis: Ist auch bei POST-Requests möglich, allerdings müssen hier dann die Parameter wie bei GET in der URL übergeben werden.
(8) Wenn eine Authentifizierung notwendig ist, können hier entweder explizit Benutzer und Passwort oder alternativ ein Partner-Kanal angegeben werden, dessen Anmeldedaten dann verwendet werden. Siehe auch System-Variable MSG_CALL_HTTP_AUTH_USER.
Ablauf
Bei einem eingehenden Request wird vom HTTP-Servlet zunächst das korrekte Profil gesucht. Dabei werden alle Profile durchsucht, die einen zeitgesteuerten Eingangsagenten mit Option Trigger/HTTP-Anfrage eingestellt haben und deren URL mit (3) endet. Zusätzlich müssen die HTTP(S)-Request-Parameter zur HTTP(S)-Request-Parameter-Festlegung (7) passen (siehe Abschnitt HTTP-Request-Parameter und HTTP-Header). Das erste passende Profil wird ausgewählt und die Verarbeitung angestoßen. Falls weitere Profile den Bedingungen entsprechen, werden diese Profile nicht berücksichtigt.
Das HTTP-Servlet wird beim Start von Lobster_data gestartet und reagiert per Default sowohl auf den HTTP-Kontext /dw/trigger als auch /dw/Trigger. Bitte beachten Sie auch Abschnitt URL-Kontext systemweit definieren.
Sind z. B. in (3) der Wert myprofile und in der Parameterliste (7) zwei Parameter (p1=value1, p2=value2) eingetragen, dann muss die URL wie folgt aussehen.
|
http://servername[:port]/dw/trigger/myprofile?p1=value1&p2=value2 |
Sind im Profil auch Benutzer und Kennwort eingetragen, wird das Profil erst nach erfolgreicher Anmeldung getriggert.
Bei Trigger durch HTTP wird an den Client im Erfolgsfall der Text OK zurückgegeben. Es ist aber auch möglich die Response für Erfolg und für Fehler jeweils als Textdatei zu hinterlegen. Folgende Datei wird gesucht und wenn sie existiert, lesbar ist und nicht leer ist, wird der Dateiinhalt als Response an den HTTP-Client zurückgegeben. Wobei <URL suffix> hier für den Wert in (3) steht und ein vorhandener Pfadtrenner / durch _ ersetzt werden muss. Diese Dateien können in (3) direkt über das Bleistift-Icon erzeugt werden.
|
Erfolg |
./conf/http_trigger/<URL suffix>.ok |
|
Fehler |
./conf/http_trigger/<URL suffix>.err |
Response Status
Wurde das Profil erfolgreich angestoßen und (4) und (5) sind nicht gesetzt, ist der Response Status 200, auch wenn im Profil ein Fehler auftritt.
Werden (4) und (5) gesetzt, dann ist der Response Status 200, wenn das Profil erfolgreich lief. Bei einem Fehler im Profil ist der Response Status immer 500.
In beiden Fällen kann im Erfolgsfall der Response Status 200 auch überschrieben werden mit der System-Variable VAR_RESPONSE_HTTP_HEADER_RESP_STATUS. Allerdings wird dabei immer nur der Initialwert der Variable verwendet. Spätere Änderungen des Variablenwertes werden nicht berücksichtigt.
Variablen setzen im getriggerten Profil
Sie können über HTTP Request Header Variablen im Profil setzen. Enthält der HTTP Request z. B. den Header VAR_TEST, dann setzen Sie damit im Profil die Variable MSG_CALL_HEADER_HTTP_VAR_TEST (muss angelegt werden).