Das Profil kann entweder durch ein anderes Profil oder einen HTTP-Request getriggert werden (per GET oder POST ). Dabei handelt es sich um eine Eventsteuerung. Im Gegensatz zu normalen Profilen mit zeitgesteuerten Eingangsagenten können hier parallel mehrere Jobs pro Profil abgearbeitet werden.

Anderes Profil

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.

Einstellungen

(1) Kann auf jedem Server getriggert werden: Ist die Checkbox 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).

(2) Trigger Message Kontext, Trigger Message Queue: 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.

HTTP-Anfrage

Wird diese Option gewählt, kann das Profil per HTTP aufgerufen werden. Hinweis: Siehe auch Abschnitte Crontab-Syntax & HTTP-Trigger und HTTP.

Einstellungen

(1) Wird gestartet durch HTTP Anfrage: Gibt an, ob das Profil durch einen HTTP-Request (GET oder POST) getriggert werden kann. Ist diese Option aktiviert, funktioniert der Aufruf durch ein Profil auch weiterhin.

(2) URL Adressen-Suffix: Gibt die Zeichenkette an, mit der der HTTP-Request enden muss. Siehe Abschnitt Request-Ablauf unten für die Gesamt-URL.

(3) HTTP Antwort erst nach Ende des Cronjobs senden: Ist diese Option aktiviert, dann wird erst dann eine HTTP-Response zurück geliefert, wenn der Job für das Profil beendet wurde. Siehe auch Abschnitte Response-Ablauf, Response-Header und Response-Status unten. Achtung: Wenn der Job sehr zeitintensiv ist, kann die Gegenstelle des HTTP-Request in einen Timeout laufen.

(4) Daten zurückliefern: Diese Checkbox ist nur auswählbar, wenn (3) 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 Ausgangsdaten der Klasse geschickt. Siehe auch Abschnitt Profil-Ketten.

(5) MIME Type: Hier kann der MIME-Type der HTTP-Response angegeben werden. Hinweis: Für normalen Text können Sie den Default-Wert text/html verwenden.

(6) HTTP Parameter: Festlegung von Pflicht-Parametern von Requests. Siehe Abschnitte Request-Ablauf und Request-Parameter unten für Details.

(7) HTTP Zugangskontrolle: Wenn eine Authentifizierung notwendig ist, können hier entweder explizit Benutzer und Passwort oder alternativ ein Partner-Kanal angegeben werden, dessen Anmeldedaten (Eigener Zugang) dann verwendet werden. Siehe auch System-Variable MSG_CALL_HTTP_AUTH_USER.

(8) WWW Authentication: Die Authentifizierungs-Methode (BASIC, DIGEST, OAUTH2, SYSTEM).

Bei SYSTEM wird die Einstellung aus der Konfigurationsdatei ./etc/startup.xml (→ forceDigestAuthentication ) verwendet. Wird angezeigt auf Seite Start.
Wird OAUTH2 verwendet, muss in (7) ein HTTP-Kanal mit OAUTH2-Konfiguration angegeben werden.

Schematischer Aufbau der HTTP-Adresse

Um einem Profil Daten per HTTP zu senden oder es per HTTP zu starten, muss man eine bestimmte URL ansprechen. Der schematische Aufbau der URL ist

<Protokoll>://<Server>:<Port><URL-Kontext>/<URL-Suffix><Query>

Platzhalter	Beschreibung
<Protokoll>	*http* oder *https*. Siehe auch Abschnitt Hinzufügen eines HTTPS-Listeners.
<Server> und <Port>	Hier wird der DNS-Name oder die IP-Adresse des Integration Servers und optional die Portnummer erwartet, so wie für den HTTP-Listener und/oder HTTPS-Listener konfiguriert. Die Standard-Ports (80 bei HTTP und 443 bei HTTPS) müssen nicht angegeben werden. Falls eine Firewall externe Zugriffe nach innen über Portforwarding vermittelt, müssen bei Zugriff von außen die Parameter des externen Anschlusses verwendet werden. Bei Zugriff über einen DMZ-Server gelten die externen Anschlüsse des DMZ-Servers.
<URL-Kontext>	Hier wird beim Zugriff auf ein Profil mit einem eventgesteuerten Eingangsagenten HTTP normalerweise */dw/request* verwendet. Zum Triggern eines Profils mit einem zeitgesteuerten Eingangsagent wird normalerweise */dw/trigger* verwendet. Diese Standard-Einstellungen können aber systemweit verändert werden in der Konfigurationsdatei ./etc/startup.xml. <Call name="addServletContext"> <Arg>DW trigger</Arg> <Arg>/dw/trigger</Arg> <Arg>/</Arg>* </Call> <Call name="addServletContext"> <Arg>DW request</Arg> <Arg>/dw/Request</Arg> <Arg>/</Arg>* </Call>
<URL-Suffix>	Wird im Eingangsagent im Profil konfiguriert.
<Query>	Hier können zusätzliche Aufruf-Parameter übergeben werden. Formaler Aufbau: *?Name1=Wert1&Name2=Wert2*

Request-Ablauf

Das HTTP-Servlet reagiert per Default sowohl auf den HTTP-Kontext /dw/trigger als auch /dw/Trigger.

http://<URL/IP Integration Server>/dw/trigger/

Bei einem eingehenden Request wird vom HTTP-Servlet zunächst das korrekte Profil gesucht. Dabei werden alle aktiven Profile in Betracht gezogen, die einen zeitgesteuerten Eingangsagenten mit Zeitsteuerung Trigger/Externer Aufruf oder CronTab Syntax & HTTP Trigger haben und deren Suffix (2) dem Suffix im Request entspricht.

http://<URL/IP Integration Server>/dw/trigger/<Suffix>

Zusätzlich müssen die HTTP-Request-Parameter zur HTTP-Request-Parameter-Festlegung (6) passen. Sind z. B. in (2) der Wert myprofile und in der Parameterliste (6) zwei Parameter (p1=value1, p2=value2) eingetragen, dann muss die URL wie folgt aussehen.

http://<URL/IP Integration Server>/dw/trigger/myprofile?p1=value1&p2=value2

Das erste passende Profil wird getriggert. Verlangt das Profil eine Authentifizierung (7), wird das Profil aber erst nach erfolgreicher Authentifizierung getriggert. Falls weitere Profile den Bedingungen entsprechen, werden diese Profile nicht berücksichtigt.

Request-Parameter

Festlegung der Pflicht-Request-Parameter

Sie können festlegen, welche Parameter im jeweiligen HTTP-Request mindestens vorhanden sein müssen. Die folgende Abbildung zeigt ein Beispiel für die Festlegung der HTTP-Request-Parameter.

images/download/attachments/135168359/950-version-3-modificationdate-1742530325802-api-v2.png

(9) Parameter-Name: Name des HTTP-Request-Parameters, der vorhanden sein muss. Hinweis: Sie können System-Konstanten verwenden. Hinweis: Möchten Sie für einen Parameter mehrere Werte erlauben, können Sie den Parameter-Namen mehrfach anlegen.

(10) Wert: Wird in diesem Feld ein Wert eingetragen, dann muss der betroffene Parameter im HTTP-Request genau diesen Wert annehmen. Wird in diesem Feld statt eines Wertes das Symbol * eingegeben, dann können im HTTP-Request für den betroffenen Parameter beliebige Werte stehen. Auf diese Weise kann festgelegt werden, dass der betreffende Parameter lediglich im Request vorhanden sein muss. Hinweis: Sie können System-Konstanten verwenden und reguläre Ausdrücke mit dem Präfix regex: oder regex2:

Folgende HTTP-Requests werden im Beispiel akzeptiert.

...?param1=value1&param2=value2&param3=value3&param4=value4
...?param1=value1&param2=value2&param3=value3&param4=valueX
...?param1=value1&param2=value2&param3=value3&param4=valueX&param5=value5

Die folgenden HTTP-Requests werden hingegen nicht akzeptiert.

...?param1=value1&param2=value2&param3=value3
...?param1=value1&param2=value2&param3=valueX&param4=valueY

Existieren für einen eingehenden HTTP-Request mehrere Profile mit gleichem URL-Suffix und zutreffender HTTP-Request-Parameter-Festlegung, dann sind diese Profile gleichermaßen bereit, den Request zu akzeptieren. In diesem Fall wird das erstbeste Profil verwendet, das passt.

HTTP-Request-Parameter auslesen

Sie können auf die Werte der HTTP-Request-Parameter über Variablen mit folgender Syntax zugreifen.

MSG_CALL_<Name des Parameters in Großbuchstaben>

Beispielsweise kann auf die Parameter param1 und param2 des folgenden HTTP-Requests über die Variablen MSG_CALL_PARAM1 und MSG_CALL_PARAM2 innerhalb des Profils zugegriffen werden.

http://192.168.213.64:8080/dw/trigger/example?param1=value1&param2=value2

Request-Header

Request-Header können ausgelesen werden mit den System-Variablen MSG_CALL_HEADER_HTTP_<Name des Headers in Großbuchstaben>.

Weitere System-Variablen: MSG_CALL_HEADER_HTTP_METHOD, MSG_CALL_HEADER_HTTP_PROTOCOL, MSG_CALL_HEADER_HTTP_REMOTE_HOST, MSG_CALL_HEADER_HTTP_URI, MSG_CALL_HTTP_AUTH_USER, MSG_CALL_HEADER_HTTP_QUERY.

Response-Ablauf

Für die Response gibt es mehrere Möglichkeiten.

Per Default, wenn (3) nicht gesetzt ist, wird im Erfolgsfall als Response der Text OK zurück gegeben. Das bedeutet nur, dass das Profil erfolgreich angestoßen wurde. Tritt im Profil ein Fehler auf, ist das nicht ersichtlich. Konnte das Profil nicht angestoßen werden, bekommen Sie eine Meldung zurück, dass kein passendes Profil gefunden wurde.

Ist (3) gesetzt, wird nach einem erfolgreichen Profillauf als Response der Text OK zurück gegeben, gefolgt von einem Doppelpunkt und der Jobnummer. Bei einem Fehler im Profil wird die Fehlermeldung des Profils zurück gegeben. Ist auch (4) gesetzt, wird nach erfolgreichem Profillauf die Response von der Klasse geliefert (siehe dort).

Es ist aber auch möglich die Response für Erfolg und für Fehler jeweils als Textdatei zu hinterlegen. Diese Dateien können in (2) direkt über das Bleistift-Icon erzeugt werden. Falls die jeweilige Datei existiert, lesbar ist und nicht leer ist, wird der Datei-Inhalt als Response an den HTTP-Client zurückgegeben. Wollen Sie diese Dateien manuell bearbeiten, finden Sie diese unter folgendem Pfad. Der Platzhalter <URL suffix> steht für den Wert in (2). Wird in (2) ein Pfadtrenner / verwendet, also z. B. path/myprofile, dann muss der Pfadtrenner durch _ ersetzt werden, also z. B. path_myprofile.ok.

Erfolg	./conf/http_trigger/<URL suffix>.ok
Fehler	./conf/http_trigger/<URL suffix>.err

Response-Header

Werden (3) oder (4) gesetzt und sind System-Variablen der Form VAR_RESPONSE_HTTP_HEADER_<Name des Response-Headers> 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. Hinweis: Der Response-Header Content-Length wird ignoriert, d. h. er kann nicht überschrieben werden.

Response-Status

Wurde das Profil erfolgreich angestoßen und (3) und (4) sind nicht gesetzt, ist der Response Status 200, auch wenn im Profil ein Fehler auftritt.

Werden (3) oder (4) 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 (Phase 3 muss aktiv sein). Spätere Änderungen des Variablenwertes werden nicht berücksichtigt.