Schritt 1 - Profil erstellen und Konfigurationen anpassen

Erstellen Sie zuerst ein zusätzliches Profil, welches im Mapping eine JSON-Anfrage aufbaut, die an das Profil aus dem vorigen Beispiel übertragen wird:

• Geben Sie dem Profil einen aussagekräftigen Namen, z. B. Lobster_Tutorial_HTTP_calculator_call_json

• Stellen Sie den Mapping-Typ auf Daten-Routing.

• In Phase 1 verwenden wir einen zeitgesteuerten Eingangsagenten des Typs Eigene Klasse → DummyDataCron.

Hinweis: Der zeitgesteuerter Eingangsagent des Typs Eigene Klasse → DummyDataCron ist eine schnelle und unkomplizierte Möglichkeit ein Profil manuell zu starten, ohne bestimmte Eingangsdaten zu erwarten. Im Gegensatz zum eventbasierten Eingangsagenten Manuelles Hochladen brauchen Sie hierbei keine Testdatei zu übergeben.

Schritt 2 - Mapping

In Phase 3 wird folgender Aufbau erwartet:

• Neuer Knoten RequestNode in Zielstruktur.

• Knoteneigenschaften Maximum und Minimum = 1 (somit wird dieser Knoten nicht als Array angezeigt).

• XML/JSON Behandlung in Eigenschaft für Zielknoten = Transparent (verhindert, dass der Name des obersten Knotens mit ausgegeben wird).

• Erstellen Sie drei Felder mit den Namen

  • OP1 mit Fixwert 42 und Datentyp Integer.

  • OP2 mit Fixwert 24 und Datentyp Integer.

  • OPR mit Fixwert + und Datentyp String.

Schritt 3 - Ausgangsdatei vorbereiten

In Phase 5 wird die ExtendedJsonCreationUnit verwendet, um ein valides JSON zu erzeugen. Die Standardeinstellungen sind für diesen Fall ausreichend, lediglich den Parameter Start at node müssen Sie angeben, in unserem Falle ist das RequestNode.

Schritt 5 - Ausgangsdatei erstellen

Ausgegeben und versendet wird das erzeugte JSON über die Phase 6 unter Erstellung eines Antwortweges des Typs HTTP. Hinterlegen Sie die Zieladresse, Credentials u.a. im Antwortweg oder wählen Sie einen passenden Partnerkanal.

• Zielrechner erwartet die tatsächliche Adresse des Remote-Systems (DNS-Name oder IP-Adresse; der Protokollzusatz http: bzw. https: kann entfallen).

• Haben Sie einen DMZ-Server im Einsatz, dann aktivieren Sie die Option Via DMZ.

• Den Port müssen Sie hier nur angeben, wenn kein Standardwert auf dem Remote-System verwendet wird (HTTP - Port 80 und HTTPS - Port 443).

• Benutzer bzw. Kennwort muss bei evtl. vorhandener Zugangskontrolle gefüllt werden.

• HTTP URI benötigt die Angabe der tatsächlichen Ressource auf dem Zielsystem an, z.B. /dw/Request/calculator_json_body.

• Falls ein HTTP-Header gesendet werden soll, kann mit Ausnahme von "Content-Length" ein beliebiger Header angeben werden.

• HTTP Methode = POST

• Im Feld Query/Body können Sie zusätzliche Query-Parameter angeben. Im Falle von Multipart-Aufrufen auch den Bezeichner für den Teilabschnitt.

• Das Feld MIME-Type ist vor allem für Methoden wie POST, PUT und PATCH interessant, da Sie darüber dem empfangenden Server mitteilen, mit welcher "Dokumentenart" übertragen wurde.

• Um die Antwort der Gegenstelle zu prüfen, steht Ihnen das Feld Erwartete Rückmeldung zur Verfügung.

• Weitere Optionen können für die TLS-Verbindung, Web-Service und Multipart-Aufrufe bzw. dem Encoding für Variablen gesetzt werden.

Wichtiger Hinweis: Die Option SSL verwenden müssen Sie immer setzen, wenn die Zieladresse HTTPS erwartet. Es reicht nicht hier den Port 443 anzugeben oder für den Zielrechner https://.... zu setzen. Kann die Zielseite nur HTTPS und die Option ist nicht aktiv, wird es mit Sicherheit zu einem Fehler kommen.

Normalerweise ist mit Abschluss der Phase 6 der Lauf des Profils beendet. Im Fall von HTTP wird beim Aufruf eines Zielrechners aber stets eine Antwort zurück geliefert.

Mit der Option HTTP-Antwort per Message weiterleiten in Phase 6 des Antwortweges HTTP können Sie die Antwort vom Server gezielt an ein Folgeprofil weitergeleiten. So können z. B. Status- oder Fehlermeldungen des Aufrufs bewusst ausgewertet werden.

Setzen Sie im Antwortweg die Inhaltseinstellungen auf Ausgabe von IU und das Encoding auf UTF-8. Speichern Sie das Profil ab und starten Sie es über "Neustart" - "Cron starten". Im Control Center prüfen Sie den Profillauf und die Daten.

Hinweis: Sie sollten immer ein zusätzliches, simples Profil erstellen, welches die Fehlerantworten eines HTTP-Ausgangswegs aufnehmen kann. Damit wird jegliche Analyse erheblich vereinfacht, wenn es denn mal zu einem Fehler kommt. Weiterhin ist ein solches Profil auch sehr hilfreich, wenn Sie einen neuen Antwortweg für HTTP implementieren. Dabei müssen Sie nicht für jeden Antwortweg ein eigenes Fehlerprofil definieren, vielmehr können Sie ein einzelnes Profil sozusagen als Sammelstelle für Fehlermeldungen verwenden. Ein solches Profil benötigt lediglich in den Basis-Daten einen aussagekräftigen Namen (bspw. HTTP_ERR_COLLECTOR). In Phase 1 wird der Eingangsagent des Typs Message erwartet. Ein Mapping ist nicht relevant.

Zur besseren Überprüfung einer erfolgreichen Übertragung ist es hilfreich ein ausführliches Logging für den HTTP-Antwortweg zu aktivieren. Im Control Center → Logs → Konfiguration → Profil-Logging navigieren Sie zum gewünschten Profil und aktivieren die Optionen Trace und HTTP für Phase 6.