HTTP Connector

Verwendung

Ein HTTP Connector erfüllt abhängig von seiner Konfiguration folgende Aufgaben:

  • Input Listener Connector

    Fungiert als HTTP-Server und wartet auf Requests von Clients.

    Dieser Konnektortyp kann synchron/asynchron kommunizieren:

    • Synchrone Kommunikation

      Der Eingang eines Request startet den Workflow hinter dem Input Listener Connector. Die Ausgangsnachricht des letzten Moduls im Workflow wird als Response an den Client zurückgesendet. Der HTTP-Status in der Response kann im Workflow mithilfe der Modulvariable httpstatus gesetzt werden.

    • Asynchrone Kommunikation

      Der HTTP Input Listener empfängt einen Request und sendet direkt eine HTTP-Statusmeldung an den Client zurück. Dann wird mit dem Request der Workflow gestartet. Das Ergebnis des Workflows wird nicht zurückgegeben.

      Alle Parameter und Header, die mit dem Request übergeben wurden, stehen während der Workflow-Ausführung als Modulvariablen zur Verfügung.

  • Input Connector

    Sendet als Client GET-Requests an einen HTTP-Server, um Daten anzufordern. Parameter werden im Anfrage-Teil der URL übergeben. Der Nachrichteninhalt der Response wird als Ausgangsnachricht des Moduls an den Workflow übergeben. Bei Statuscode < 200 oder >= 300 wird ein Fehler erzeugt.

  • Medium/Output Connector

    Diese Konnektortypen senden in der Funktion von Clients POST-Requests an einen HTTP-Server. Parameter und Eingangsnachrichten werden im Request-Body übertragen.

    Wenn die Response des HTTP-Servers ein Statuscode < 200 oder >= 300 ist, dann wird ein Fehler erzeugt. Andere Statuscodes gibt der Medium/Output Connector als Ausgangsnachricht aus.

Der HTTP Connector unterstützt die Protokolle HTTP und HTTPS.

Parameter im HTTP Connector setzen und anzeigen

Parameter setzen

Parameter sind beliebige Name/Wert-Paare und werden abhängig vom Konnektortyp wie folgt übergeben:

Konnektortyp Methode Parameterübergabe

Input Connector

GET

Als Parameter der Server-URL, z.B. https://<server>:<port>/ibis/servlet/IBISHTTPUploadServlet/HTTPinputCon?PAR1=1234&PAR2=abc

Server-URL ändern, siehe Dialog HTTP Connector Eigenschaften

Medium/Output Connector

POST

Als Parameter im Request-Body, z.B. Par1=1234&Par2=abc

Sie definieren diese Parameter beim Anlegen bzw. Bearbeiten eines Medium oder Output Connectors.

Siehe Dialog HTTP Connector Eigenschaften

Alle Parameter stehen während der Workflow-Ausführung als Modulvariablen zur Verfügung. Die Modulvariablen sind nach folgendem Muster benannt: <Key>=<Value>.

Sie können die Modulvariablen mithilfe des Variablen-Mappings dynamisch ändern.

Siehe Workflow-Variablen und Mappings

Parameter anzeigen

  • Input Connector

    URL-Parameter, die ein HTTP Input Connector an einen HTTP Input Listener übergeben hat, können Sie am Watchpoint vor dem HTTP Input Listener anzeigen:

    module guide 1079 0

  • Medium/Output Connector

    Auch die Parameter, die ein HTTP Output Connector z.B. an einen HTTP Input Listener übergeben hat, sind am Watchpoint vor dem HTTP Input Listener sichtbar:

    module guide 1079 1

Header im HTTP Connector setzen und anzeigen

Header anzeigen

Alle Request- und Response-Header stehen nach der Workflow-Ausführung als Modulvariablen zur Verfügung:

  • Request-Header können Sie z.B. am Watchpoint vor einem HTTP Input Listener Connector anzeigen:

    module guide 1079 2

  • Response-Header können Sie z.B. am Watchpoint nach einem HTTP Output Connector anzeigen:

    module guide 1080 0

Header definieren

Sie können Request- und Response-Header beim Anlegen bzw. Bearbeiten Ihres HTTP Connectors definieren.

Siehe Dialog HTTP Connector Eigenschaften:

  • Input Listener Connector: HTTP-Header-Konfiguration

  • Input Connector: HTTP-Header-Konfiguration

  • Output und Medium Connector: HTTP-Post-Konfiguration

Header dynamisch setzen und überschreiben

Sie können mithilfe des Variablen-Mappings Header dynamisch überschreiben und neue Header setzen.

  • Zum Überschreiben des Response-Headers in einem Workflow mit einem HTTP Listener:

    Setzen Sie die Workflowvariablen httpheader.<headerName> irgendwo im Workflow, aber bevor die Ausgangsnachricht als Antwort zurückgeschickt wird.

  • Zum Überschreiben des Request-Headers für die Ausgangsnachricht einer HTTP Connector-Anfrage:

    Überschreiben Sie die Moduleigenschaften httpheader.<headerName> des HTTP Connectors.

So gehen Sie vor

Definieren Sie eine Abbildungsregel nach folgendem Muster: Quellwert > Zielwert=httpheader.<headerName>

Beispiel:

module guide 1081 1

Siehe Workflow-Variablen und Mappings

Dialog HTTP Connector Eigenschaften

Dieser Dialog bietet folgende Optionen:

Für einen Listener Connector aktivieren Sie auf der Registerseite System Connector Eigenschaften die Option Auf Datenempfang warten (Listener Connector).

Grundkonfiguration

  • Server-URL

    • Input Listener Connector:

      URL des Input Listeners, unter welcher dieser auf Requests wartet. Die URL wird automatisch nach folgendem Muster erstellt:

      https://<server>:<port>/ibis/servlet/IBISHTTPUploadServlet/NameDesInputListeners

      Der Teil hinter /IBISHTTPUploadServlet/ kann angepasst werden und auch weitere Pfadbestandteile enthalten, also zum Beispiel /IBISHTTPUploadServle/X/Y/NameDesInputListeners oder /IBISHTTPUploadServlet/X/NameDesInputListeners/Y.

      Teilen Sie die Server-URL denjenigen mit, die Nachrichten zur Verarbeitung an den Input Listener senden.

    • Input Connector:

      URL des HTTP-Servers oder HTTP Input Listener Connectors, den der Input Connector aufruft.

    • Medium/Output Connector:

      URL des Servers, an den der Connector seinen POST-Request sendet, zum Beispiel Adresse eines HTTP Input Listeners.

  • SSL-Button

    (nicht verfügbar für einen Input-Listener-Connector)

    Zum Absichern der Kommunikation über SSL siehe Dialog SSL-Konfiguration.

Authentifizierung erforderlich

Für Input-Listener-Connector.

Wählen Sie diese Option, wenn der Server eine Authentifizierung erfordert. Wenn ausgewählt, werden die folgenden Daten verfügbar:

  • Statische Zugangsdaten verwenden

    • Verfahren

      • Basic

        Benutzername und Passwort sind erforderlich und unverschlüsselt übermittelt.

    • Benutzername: Benutzername für die Authentifizierung

    • Passwort: Passwort für die Authentifizierung

  • Aus dem Credentials Manager auswählen

    Für die Authentifizierung können Sie auch Zugangsdaten verwenden, die im Credentials Manager verwaltet werden. Siehe Credentials Manager für die Authentifizierung verwenden.

  • Prozessbenutzer verwenden

    Diese Option ist nur verfügbar, wenn ein Portal installiert, für INUBIT passend konfiguriert und in der INUBIT Workbench sowohl der Portalserver als auch der Prozessbenutzer-Server korrekt konfiguriert ist.

  • Process Engine Benutzer verwenden (Passwort aus Serverkonfiguration)

    Benutzt den internen Process-Engine-Benutzer (inubitISPortalUser@@@intern) und das Passwort in der Eigenschaft Verwaltung > Server > Passwort für die Process Engine auf der Registerseite Konfiguration.

  • Kerberos-Authentifizierung verwenden (nur für Medium- und Output-Connector-Module)

    Aktivieren Sie diese Checkbox, um das Kerberos-Protokoll zum Authentifizieren zu verwenden. Konfigurieren Sie die folgenden Parameter:

    • Benutzername

      Benutzername zum Authentifizieren

    • Passwort

      Passwort des Benutzers zum Authentifizieren

    • Kerberos Conf-Dateipfad

      Klicken Sie auf das Icon module guide 1082 1, um in einem Dialog die Kerberos-Konfigurationsdatei auszuwählen.

      Eine Beispieldatei ist verfügbar im INUBIT Repository unter: /Global/System/Mapping Templates/HTTPConnector/krb5.conf

      Um diese Datei als Vorlage zu verwenden, kopieren Sie diese als Administrator root in ein Verzeichnis außerhalb der Global-Verzeichnishierarchie und passen Sie diese entsprechend an.

    • Login Conf-Dateipfad

      Klicken Sie auf das Icon module guide 1082 1, um in einem Dialog die Login -Konfigurationsdatei auszuwählen.

      Eine Beispieldatei ist verfügbar im INUBIT Repository unter: /Global/System/Mapping Templates/HTTP Connector/login.conf

      Um diese Datei als Vorlage zu verwenden, kopieren Sie diese als Administrator root in ein Verzeichnis außerhalb der Global-Verzeichnishierarchie und passen Sie diese entsprechend an.

      Um verschiedene krb5.conf-Dateien ohne den Neustart der Process Engine zu nutzen, stellen Sie sicher, dass refreshKrb5Config=true in der Datei login.conf gesetzt ist.

      Standardmäßig ist refreshKrb5Config auf true gesetzt.

    • Login Modulname

      Name des Loginmoduls. Verwenden Sie denselben Modulnamen, den Sie in der Datei login.conf angegeben haben.

    • Kerberos Debug einschalten

      Aktivieren Sie diese Checkbox zum Analysieren von Fehlern und Fehlfunktionen.

Authentifizierung verwenden

Für Nicht-Listener-Connector.

Wählen Sie diese Option, wenn der Server eine Authentifizierung erfordert. Wenn ausgewählt, werden die folgenden Daten verfügbar:

  • Folgende Zugangsdaten verwenden

    • Verfahren

      • Basic

        Benutzername und Passwort sind erforderlich und unverschlüsselt übermittelt.

        Benutzen Sie die Basic-Authentifizierung nur, wenn die Verbindung zwischen dem Client und dem Server als sicher angesehen werden kann.

      • Digest

        Benutzername und Passwort sind erforderlich. Das Passwort wird verschlüsselt übertragen.
        Sie können die Digest-Authentifizierung zum Verschlüsseln verschiedener Parameter benutzen, einschließlich zufällig generierter Werte.

      • NTLM

        Benutzername und Passwort sind erforderlich. Das Passwort wird verschlüsselt übertragen. Sie können die *NTLM+-Authentifizierung zum Verschlüsseln verschiedener Parameter benutzen, einschließlich zufällig generierter Werte.

    • Statische Zugangsdaten verwenden

      • Benutzername: Benutzername für die Authentifizierung

      • Passwort: Passwort für die Authentifizierung

  • Aus dem Credentials Manager auswählen

    Für die Authentifizierung können Sie auch Zugangsdaten verwenden, die im Credentials Manager verwaltet werden. Siehe Credentials Manager für die Authentifizierung verwenden.

    • Domäne: Domainname des NTLM-Servers

      Diese Option ist nur dann aktiviert, wenn die NTLM-Authentifizierung ausgewählt ist.

  • Authentifizierung für Zugriff auf Process Engine verwenden (Passwort aus Serverkonfiguration)

    Verwenden Sie diese Option für den Zugriff auf die INUBIT Process Engine.

Autorisierung

(nur wenn IMAP oder IMAPS als Protokoll gewählt wurde)

  • OAuth2-Autorisierung verwenden

    Aktivieren Sie diese Option, um die OAuth2-Autorisierung zu verwenden

    Wenn die Option OAuth2-Autorisierung verwenden ausgewählt ist, hat die OAuth2-Autorisierung Vorrang vor den Einstellungen im Bereich Authentifizierung verwenden.

    • Grant-Typ (Gewährungstyp)

      • Client Credentials: Empfohlene Option für INUBIT, da keine Benutzerinteraktion erforderlich ist.

      • Password Credentials

      • Benutzerdefiniert: Wählen Sie diese Option, um andere Grant-Typen zu konfigurieren (z.B. Refresh Token Flow, Implicit Flow)

    • URL des Zugriffs-Tokens

      Fügen Sie die URL des OAuth Servers ein. Zusätzlich können Sie festlegen, ob der HTTP-Zugriff via GET oder POST erfolgen soll.

    • Parameter

      Jeden Grant-Typ erfordert die Angabe bestimmter Parameter. Welche das sind, entnehmen Sie der Dokumentation des verwendeten OAuth Servers.

      Die Parametertabelle kann beliebig viele Einträge aufnehmen.

      Alle im Modulassistenten konfigurierten Parameter sind als Moduleigenschaften mit dem Präfix OAUTH_PROPERTY für die Verwendung im Variablen-Mapping verfügbar.

      Via Variablen-Mapping können nur Eigenschaften überschrieben werden, die vorher im Assistent gesetzt wurden. Sollen weitere Parameter via Variablen-Mapping gesetzt werden, müssen diese zuvor über den Modulassistenten in der Tabelle eingetragen werden (mit leerem oder Platzhalterwert).

Verbindungstest

Für Nicht-Listener-Connector.

  • Verbindung testen

    Zum Testen, ob die Verbindung mit Ihren Angaben erfolgreich aufgebaut werden kann.

HTTP Header-Konfiguration

Über den Header können Informationen wie zum Beispiel Dateigröße, HTTP-Server- und User-Agent-Kennung oder MIME-Typ zwischen Client und HTTP-Server übertragen werden.

Der Button Header-Liste…​ öffnet einen Dialog, in dem Sie manuell Name-Wert-Paare als Header definieren können.

Informationen über Header finden Sie in der HTTP Header-Spezifikation siehe https://tools.ietf.org/html/rfc7231.

Wenn im Request bereits gleichnamige Request-Header vorhanden sind, dann werden diese Header mit den hier angegebenen Werten überschrieben!

Kodierung

  • Kodierung/Dekodierung Base64

    Wenn markiert, dann werden die Eingangsnachrichten des Connectors vor dem Versand Base64-kodiert. Diese Option ist sinnvoll für Binärdaten.

Konvertierung

Für Input-Listener-Connector.

  • AJAX/XML-Konvertierung

    Wenn markiert, dann werden eingehende AJAX-Requests, die von einem Task Generator erzeugt wurden, nach XML konvertiert, so wie es im Ausgangsmapping zur Verfügung steht.

    Wenn die Option nicht markiert ist, dann werden diese Requests als Byte-Strom übergeben.

  • Eingabefelder gruppieren:

    Wenn markiert, dann werden alle Eingabefelder in der Eingangsnachricht, die denselben Index haben, bei der Ausgabe von einem Group-Element umschlossen. So ist es möglich, in einem nachfolgenden XSLT Converter über die Gruppen von Eingabefeldern mit xsl:for-each zu iterieren.

    Beispiel:

    IN: Eingabefeldliste Out: Gruppenliste

    Vorname.1

    		 
    <Group>
  <Firstname/>
  <Surname/>
  <Street/>
  <City/>
</Group>

    Nachname.1

    Straße.1

    Ort.1

    Vorname.2

    		 
    <Group>
  <Firstname/>
  <Surname/>
  <Street/>
  <City/>
</Group>

    Nachname.2

    Straße.2

    Ort.1

    Eingabefelder haben einen Index, wenn sie durch Kopieren mit der JavaScript-Funktion copyComponentIS() entstanden sind. Diese Funktion ist in allen Formularen verfügbar, die mit dem Task Generator erstellt wurden.

  • HTTP-Eingangsnachricht in XML wandeln

    Wenn markiert, dann werden eingehende HTTP- bzw. Multipart/form-Requests (inkl. Header etc.) in XML konvertiert. Wenn die Option nicht markiert ist, wird der Body des HTTP-Requests ohne Konvertierung in die Ausgangsnachricht geschrieben. Multipart-MIMEs müssen dann geparst werden.

Synchrone HTTP Antwort

Für Input-Listener-Connector.

  • Aktivieren

    Wenn aktiviert, dann empfängt der Input Listener den Request, startet den Workflow und wartet auf dessen Ergebnis. Das Ergebnis ist die Ausgangsnachricht des letzten Moduls im Workflow.
    Sobald das Ergebnis vorliegt, sendet der Input Listener es zusammen mit einer Status-Meldung an das aufrufende Modul zurück.

    Wenn die Option nicht aktiviert ist, dann empfängt der Input Listener einen Request, sendet sofort die Status-Meldung zurück und startet dann den Workflow. Es wird kein Ergebnis zurückgegeben.

  • Fehlermeldung zurückliefern

    Wenn aktiviert, dann wird im Falle eines internen Serverfehlers (Fehlercode 500) eine detaillierte Fehlermeldung an den Client zurückgeschickt.

    Wenn die Option nicht aktiviert ist, dann wird lediglich der Fehlercode 500 ohne Details zurückgesendet.

Formatierung der Ausgabe als HTTP Post-Mitteilung

Für Medium/Output-Connector.

Wählen Sie diese Option, um Parameter übergeben zu können. Wenn ausgewählt, dann werden die Eingangsnachrichten im Request-Body URL-kodiert und so formatiert, als ob diese von einem Browser über ein HTML-Formular geschickt wurden, zum Beispiel:

module guide 1086 1

  • Post-Feldname der Daten

    Sie können das POST-Feld xml (s. Abb. oben) durch einen beliebigen Namen ersetzen, zum Beispiel durch Eingangsdaten:

    module guide 1086 2

  • HTTP Post-Wertepaar hinzufügen

    Öffnet einen Dialog, in dem Sie Parameter als Name/Wert-Paare definieren können. Die Parameter werden an das Ende des Request-Body gehängt, zum Beispiel:

    module guide 1086 3

Press Esc to exit full screen
Modal image placeholder
Press Esc to exit full screen