Zum Inhalt springen

HTTP v2 Verbindung

Einführung

Eine HTTP v2 Verbindung, die mit dem HTTP v2 Connector erstellt wurde, ermöglicht den Zugriff über das HTTP- oder HTTPS-Protokoll auf einen Dienst wie eine REST-API, GraphQL-API oder ein Webformular. Sobald eine Verbindung konfiguriert ist, können Instanzen von HTTP v2 Aktivitäten erstellt werden, die mit dieser Verbindung verknüpft sind, um entweder als Quellen (um Daten in einem Vorgang bereitzustellen) oder als Ziele (um Daten in einem Vorgang zu konsumieren) verwendet zu werden.

Hinweis

Dieser Connector unterstützt die Re-Authentifizierung bei Änderung Organisationsrichtlinie. Wenn aktiviert, erfordert eine Änderung der Basis-URL, Autorisierung, Schlüssel oder Benutzername in dieser Verbindung, dass Benutzer den Wert, Bearer-Token, Client-Geheimnis oder Sitzungstoken (je nach ausgewählter Autorisierung) für die Verbindung erneut eingeben.

Erstellen oder Bearbeiten einer HTTP v2 Verbindung

Eine neue HTTP v2 Verbindung wird mit dem HTTP v2 Connector aus einem dieser Standorte erstellt:

Eine vorhandene HTTP v2 Verbindung kann von diesen Standorten bearbeitet werden:

Konfigurieren einer HTTP v2-Verbindung

Jedes Benutzeroberflächenelement des Konfigurationsbildschirms für die HTTP v2-Verbindung wird im Folgenden beschrieben.

Tipp

Felder mit einem Symbol für Variablen unterstützen die Verwendung von globalen Variablen, Projektvariablen und Jitterbit-Variablen. Beginnen Sie entweder, indem Sie eine öffnende eckige Klammer [ in das Feld eingeben, oder indem Sie auf das Symbol für Variablen klicken, um ein Menü mit vorhandenen Variablen anzuzeigen, aus dem Sie auswählen können.

  • Verbindungsname: Geben Sie einen Namen ein, um die Verbindung zu identifizieren. Der Name muss für jede HTTP v2-Verbindung eindeutig sein und darf keine Schrägstriche / oder Doppelpunkte : enthalten. Dieser Name wird auch verwendet, um den HTTP v2-Endpunkt zu identifizieren, der sich sowohl auf eine bestimmte Verbindung als auch auf deren Aktivitäten bezieht.

  • Basis-URL: Geben Sie die Basis-URL ein. Die Basis-URL wird zum Testen der Verbindung verwendet. Ob dieses Feld zur Laufzeit verwendet wird, hängt davon ab, ob das Feld HTTP-Aktivitäts-URL einer HTTP v2-Aktivität ausgefüllt ist:

    • Wenn eine partielle URL oder keine URL im Feld HTTP-Aktivitäts-URL angegeben ist, wird die zur Laufzeit verwendete URL aus der Basis-URL und der HTTP-Aktivitäts-URL zusammengefügt.

    • Wenn eine vollständige URL im Feld HTTP-Aktivitäts-URL angegeben ist, wird die Basis-URL zur Laufzeit nicht verwendet.

  • Autorisierung: Verwenden Sie das Menü, um den Authentifizierungstyp auszuwählen, der im Folgenden zusammengefasst ist. Die Konfiguration jedes Authentifizierungstyps wird in HTTP v2-Verbindungsauthentifizierungstypen beschrieben.

    • API-Schlüssel: Geben Sie ein API-Schlüssel-Wert-Paar an, das in Headern oder Abfrageparametern gesendet werden soll.

    • AWS-Signatur: Geben Sie eine AWS-Zugangs-ID, einen geheimen Zugriffsschlüssel, eine Region, einen Dienst und ein Sitzungstoken an, die mit Amazon Web Services (AWS) Signature Version 2 in Headern oder Abfrageparametern gesendet werden sollen.

    • Basic Auth: Geben Sie einen Benutzernamen und ein Passwort an, die in den Headern gesendet werden.

    • Bearer Token: Geben Sie ein Bearer-Token an, das in den Headern gesendet wird.

    • Digest Auth: Geben Sie einen Benutzernamen, ein Passwort, einen Realm, ein Nonce, einen Algorithmus, QOP, die Nonce-Zählung, ein Client-Nonce und ein Opaque an, die in den Headern gesendet werden.

    • Hawk Authentication: Geben Sie eine Hawk-Authentifizierungs-ID, einen Authentifizierungsschlüssel, anwendungsspezifische Informationen, eine App-ID und DLG an, die in den Headern gesendet werden.

    • No Auth: Wählen Sie diese Option, um anonym ohne Autorisierung auf den Dienst zuzugreifen.

    • NTLM Authentication: Geben Sie einen Benutzernamen, ein Passwort, eine Domäne und einen Arbeitsplatz an, die in Headern gesendet werden, die mit dem Microsoft NTLM-Protokoll kompatibel sind.

    • OAuth 2.0: Geben Sie den Grant-Typ an und stellen Sie den OAuth-Token-Endpunkt, die Client-ID, das Client-Geheimnis und den Scope zur Verfügung, die in den Headern oder im Anfragekörper gesendet werden.

  • Retry: Funktioniert nur, wenn eine Umgebung verwendet wird, die mit einer privaten Agentengruppe verbunden ist. Diese Einstellung wird verwendet, um eine Anfrage erneut zu versuchen, wenn ein HTTP v2-Endpunkt einen dieser Statuscodes zurückgibt: 500, 502, 503 oder 504.

    Diese Einstellung tritt in Kraft, wenn sie mit privaten Agenten der Version 10.34 oder höher verwendet wird.

    Wählen Sie das Kontrollkästchen Retry aus, um zusätzliche Konfigurationsoptionen zu erweitern.

    • Wiederholungsintervall (Sekunden): Geben Sie die Anzahl der Sekunden (maximal 5 Sekunden) an, die zwischen dem erneuten Senden einer Anfrage an den HTTP v2-Endpunkt gewartet werden soll.

    • Maximale Wiederholungen: Geben Sie die maximale Anzahl an Wiederholungen (maximal 5 Wiederholungen) an, die eine Anfrage an den HTTP v2-Endpunkt erneut gesendet wird. Wenn die Anfrage nach der maximalen Anzahl an Wiederholungen weiterhin fehlschlägt, wird eine Ausnahme mit einer Fehlermeldung im Betriebsprotokoll zurückgegeben. Darüber hinaus protokolliert der private Agent jede Wiederholung in der jitterbit.log-Protokolldatei.

      Jede Wiederholung wird als Teil des gleichen Betriebsablaufs behandelt, wobei nur ein einzelner Datensatz im Betriebsprotokoll erscheint. Alle Betriebsaktionen, die konfiguriert sind, um nachgelagerte Operationen auszuführen, werden basierend auf dem Endstatus des Betriebs nach dem Wiederholen bis zur maximalen Anzahl an Wiederholungen ausgelöst.

  • Optionale Einstellungen: Klicken Sie, um zusätzliche optionale Einstellungen zu erweitern.

    • Antwortinhalt als base64-String abrufen: Wählen Sie aus, um den base64-kodierten responseContent aus HTTP v2-Aktivitäten zurückzugeben.

    • Chiffren hinzufügen: Wählen Sie aus, um Chiffren anzugeben, die mit der Verbindung in der Tabelle Chiffersuiten eingeben verwendet werden sollen. Klicken Sie auf das Hinzufügen-Symbol , um eine Chiffren-Definition zur Tabelle hinzuzufügen. Zum Beispiel TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256.

      Hinweis

      Wenn Chiffren hinzufügen deaktiviert ist oder wenn die Tabelle Chiffersuiten eingeben leer gelassen wird, verwendet die HTTP v2-Verbindung eine Reihe von Standard-Chiffren. Die in der Tabelle Chiffersuiten eingeben definierten Chiffren überschreiben die Standardreihe.

      Um die Zeile zu speichern, klicken Sie auf das Senden-Symbol in der rechten Spalte.

      Um eine einzelne Zeile zu bearbeiten oder zu löschen, fahren Sie mit der Maus über die rechte Spalte und verwenden Sie das Bearbeiten-Symbol oder das Löschen-Symbol .

      Um alle Zeilen zu löschen, klicken Sie auf Alle löschen.

    • Proxy-Einstellungen: Verwenden Sie das Menü, um die Proxy-Einstellungen auszuwählen, eine dieser Optionen:

      • Benutzerdefiniert: Die Proxy-Einstellungen werden aktiviert, indem die Eingaben in den zusätzlichen Feldern verwendet werden, die verfügbar werden, wenn diese Option ausgewählt ist. Diese Option umgeht die Proxy-Konfiguration des privaten Agents, falls eine vorhanden ist.

        • Host: Geben Sie den Hostnamen des HTTP-Proxyservers ein.
        • Port: Geben Sie den Port des HTTP-Proxyservers ein.
        • User: Geben Sie den Benutzernamen für die Authentifizierung am HTTP-Proxyserver ein.
        • Password: Geben Sie das Passwort für die Authentifizierung am HTTP-Proxyserver ein.
        • NTLM Domain: Geben Sie die NTLM-Domain für die Authentifizierung am HTTP-Proxyserver ein.
        • Allow Unverified Certs Used by Proxy: Wählen Sie aus, um unbestätigte Zertifikate zuzulassen, die vom HTTP-Proxyserver verwendet werden.
      • Default: Die Proxy-Einstellungen sind aktiviert und verwenden die private Agent-Proxy-Konfiguration, falls vorhanden. Wenn in der Agent-Konfiguration keine Proxy-Einstellungen angegeben sind, hat die Einstellung Default das gleiche Ergebnis wie die Einstellung Disable.

      • Disable: Die Proxy-Einstellungen sind deaktiviert, wodurch die private Agent-Proxy-Konfiguration umgangen wird, falls vorhanden.

    • Advanced HTTP Properties: Wenn zutreffend, legen Sie diese erweiterten Optionen fest:

      • Content-Type: Geben Sie den Content-Type der Anforderungsstruktur ein, die von der jeweiligen API erwartet wird. Zum Beispiel text/plain, application/json, application/x-www-form-urlencoded usw. Wenn die verwendete Methode keine strukturierten Daten akzeptiert oder die API nicht erfordert, dass der Content-Type angegeben wird, lassen Sie dieses Feld leer. Dieses Feld wird nicht von der Einstellung Send request headers in activity execution beeinflusst.

        Alternativ kann der Content-Type in anderen UI-Konfigurationsfeldern angegeben oder in der Anforderungsumwandlung bereitgestellt werden. Wenn der Content-Type an mehreren Stellen angegeben ist, wird folgende Reihenfolge der Priorität beachtet:

        1. Ein Content-Type-Header, der in der Tabelle Additional Settings einer HTTP v2-Aktivität bereitgestellt wird, überschreibt alle nachfolgenden Felder.
        2. Das Feld bodyContentType, das in einer Anforderungsumwandlung angegeben ist, überschreibt die verbleibenden Felder.
        3. Ein Content-Type-Header, der im Knoten headers der Anforderungsumwandlung bereitgestellt wird, überschreibt die verbleibenden Felder.
        4. Ein Content-Type-Header, der im Feld Request Headers einer HTTP v2-Aktivität bereitgestellt wird, überschreibt das verbleibende Feld.
        5. Ein Content-Type-Header, der im Feld Request Headers einer HTTP v2-Verbindung bereitgestellt wird, hat die geringste Priorität, wenn Send Request Headers in Activity Execution aktiviert ist.

        Hinweis

        Wenn ein Header an mehreren Stellen definiert ist, wird jede Instanz des Headers der Anfrage einer Aktivität gemäß der oben genannten Reihenfolge hinzugefügt. Diese Reihenfolge basiert darauf, wie Dienste typischerweise mit doppelten Headern in einer Anfrage umgehen.

      • Inhalt-Encoding aktivieren: Wählen Sie aus, um den Accept-Encoding-Header mit Gzip-Codierung zu senden. Dieses Feld wird nicht von der Einstellung Request-Header in der Aktivitätsausführung senden beeinflusst.

        Alternativ kann dieser Header in anderen UI-Konfigurationsfeldern definiert oder in der Anfrage-Transformation bereitgestellt werden. Wenn dieser Header an mehreren Stellen angegeben ist, wird folgende Reihenfolge eingehalten:

        1. Ein Accept-Encoding-Header, der im headers-Knoten der Anfrage-Transformation bereitgestellt wird, überschreibt alle nachfolgenden Felder.
        2. Ein Accept-Encoding-Header, der im Feld Request Headers einer HTTP v2-Aktivität bereitgestellt wird, überschreibt das verbleibende Feld darunter.
        3. Ein Accept-Encoding-Header, der im Feld Request Headers einer HTTP v2-Verbindung bereitgestellt wird, hat, wenn Request-Header in der Aktivitätsausführung senden aktiviert ist, die geringste Priorität.

        Hinweis

        Wenn ein Header an mehreren Stellen definiert ist, wird jede Instanz des Headers der Anfrage einer Aktivität gemäß der oben genannten Reihenfolge hinzugefügt. Diese Reihenfolge basiert darauf, wie Dienste typischerweise mit doppelten Headern in einer Anfrage umgehen.

      • Chunked-Transfer-Encoding aktivieren: Wählen Sie aus, um den Transfer-Encoding: chunked-Header zu senden. Verwenden Sie diese Option, wenn Sie große Datensätze übertragen. Dieses Feld wird nicht von der Einstellung Request-Header in der Aktivitätsausführung senden beeinflusst.

        Alternativ kann dieser Header in anderen UI-Konfigurationsfeldern definiert oder in der Anfrage-Transformation bereitgestellt werden. Wenn dieser Header an mehreren Stellen angegeben ist, wird folgende Reihenfolge eingehalten:

        1. Ein Transfer-Encoding-Header, der im headers-Knoten der Anfrage-Transformation bereitgestellt wird, überschreibt alle nachfolgenden Felder.
        2. Ein Transfer-Encoding-Header, der im Feld Request Headers einer HTTP v2-Aktivität bereitgestellt wird, überschreibt das verbleibende Feld darunter.
        3. Ein Transfer-Encoding-Header, der im Feld Request Headers einer HTTP v2-Verbindung bereitgestellt wird, hat, wenn Request-Header in der Aktivitätsausführung senden aktiviert ist, die geringste Priorität.

        Hinweis

        Wenn ein Header an mehreren Stellen definiert ist, wird jede Instanz des Headers in die Anfrage einer Aktivität in der oben angegebenen Reihenfolge hinzugefügt. Diese Reihenfolge basiert darauf, wie Dienste typischerweise mit doppelten Headern in einer Anfrage umgehen.

      • Schwache Chiffren zulassen: Diese Option ist derzeit nicht funktionsfähig. Stattdessen können Sie schwache Chiffren manuell mit der Option Chiffren hinzufügen oben definieren.

      • Keep alive: Wählen Sie diese Option, um eine einzelne TCP-Verbindung für mehrere HTTP-Anfragen und -Antworten offen zu halten.

      • SSL-Zertifikatüberprüfung: Wählen Sie diese Option, um den Dienst zu überprüfen, indem das während des Handshake-Prozesses präsentierte SSL-/TLS-Zertifikat validiert wird.

      • Anforderungs-URL codieren: Wählen Sie diese Option, um die Anforderungs-URL URL zu codieren.

      • Weiterleitungen folgen: Wählen Sie diese Option, um dem Connector zu erlauben, mit allen auf der Basis-URL vorhandenen Weiterleitungen umzugeleiten. Wenn die Basis-URL umleitet und diese Einstellung nicht ausgewählt ist, tritt ein Fehler auf, wenn die Verbindung getestet wird und beim ersten Ausführen einer Operation. Wenn diese Option ausgewählt ist, wird das folgende Feld sichtbar:

        • Maximale Anzahl von Weiterleitungen: Geben Sie die Anzahl der Weiterleitungen ein, die die Verbindung folgen wird, bevor ein Fehler zurückgegeben wird.
      • Nur anwendbar bei Verwendung von HTTPS: Verwenden Sie das Menü, um die Auswahl von Negotiate (Standard) auf eine spezifische TLS-Version zu ändern, falls erforderlich, und wählen Sie aus TLSv1.0, TLSv1.1, TLSv1.2 oder TLSv1.3.

      • Anforderungsheader: Definieren Sie HTTP-Header für die Verbindung. Klicken Sie auf das Hinzufügen-Symbol , um einen Header zur Tabelle unten hinzuzufügen, und geben Sie ein Schlüssel-Wert-Paar für jeden Anforderungsparameter ein.

        Um die Zeile zu speichern, klicken Sie auf das Senden-Symbol in der rechten Spalte.

        Um eine einzelne Zeile zu bearbeiten oder zu löschen, fahren Sie mit der Maus über die rechte Spalte und verwenden Sie das Bearbeiten-Symbol oder das Löschen-Symbol .

        Um alle Zeilen zu löschen, klicken Sie auf Alle löschen.

        Alternativ können Header in anderen UI-Konfigurationsfeldern definiert oder in der Anforderungsumwandlung bereitgestellt werden. Header, die keinen gemeinsamen Schlüssel haben, werden kumulativ gesendet, unabhängig davon, wo sie angegeben sind.

        Wenn derselbe Header-Schlüssel an mehreren Stellen angegeben ist, wird folgende Reihenfolge der Priorität beachtet:

        1. Ein Header, der im headers-Knoten der Anforderungsumwandlung bereitgestellt wird, überschreibt alle nachfolgenden Felder.
        2. Ein Header, der im Feld Request Headers eines HTTP v2-Aktivität bereitgestellt wird, überschreibt das verbleibende Feld darunter.
        3. Ein Header, der im Feld Request Headers einer HTTP v2-Verbindung (dieses Feld) bereitgestellt wird, hat, wenn Send Request Headers in Activity Execution aktiviert ist, die geringste Priorität.

        Hinweis

        Wenn ein Header an mehreren Stellen definiert ist, wird jede Instanz des Headers der Anforderung einer Aktivität gemäß der oben genannten Reihenfolge der Priorität hinzugefügt. Diese Reihenfolge basiert darauf, wie Dienste typischerweise mit doppelten Headern in einer Anfrage umgehen.

        Warnung

        Definieren Sie keine Authorization-Anforderungsheader manuell in HTTP v2-Aktivitäten, wenn die HTTP v2-Verbindung so konfiguriert ist, dass sie ihre eigenen Authorization-Anforderungsheader je nach ausgewähltem Authentifizierungstyp sendet. Dies führt zu einer Beendigung der Operation und einem Fehler, bevor der Zielendpunkt erreicht wird, und wird als 400 Bad Request-Fehler protokolliert.

        Wenn auf Aktivitätsebene eine dynamische Authentifizierung erforderlich ist, setzen Sie den Authentifizierungstyp der Verbindung auf No Auth und konfigurieren Sie die Authorization-Anforderungsheader der Aktivität nach Bedarf.

        Wichtig

        Felder in der Tabelle Request Headers zeigen das Symbol für Variablen nur im Bearbeitungsmodus an. Damit die Variablenwerte dieser Felder zur Laufzeit befüllt werden, muss die Agent-Version mindestens 10.75 / 11.13 betragen.

        Felder in der Anforderungsheader-Tabelle unterstützen nicht die Verwendung von Variablen, um rohes JSON zu übergeben. Wenn Ihr Anwendungsfall nicht unterstützt, rohes JSON direkt in den Feldern zu definieren, entkommen Sie den JSON-Inhalt, bevor Sie ihn mit einer Variablen übergeben. Zum Beispiel wird das Entkommen von {"success": "true"}; zu {\"success\": \"true\"};.

      • Anforderungsheader in der Aktivitätsausführung senden: Wählen Sie aus, um Header, die in Anforderungsheader definiert sind, an HTTP v2-Aktivitäten zu übergeben. Konsultieren Sie die oben genannten Prioritäten, um zu bestimmen, wie Header, die in einer HTTP v2-Verbindung definiert sind, mit Headern in anderen Orten interagieren.

  • Test: Klicken Sie, um die Verbindung zu überprüfen, indem Sie eine HTTP GET-Anforderung mit der konfigurierten Autorisierung senden. Ein Test wird als erfolgreich betrachtet, wenn ein beliebiger 2xx HTTP-Statuscode zurückgegeben wird. Eine 405 Method Not Allowed-Antwort wird ebenfalls als erfolgreich behandelt. Wenn die Verbindung getestet wird, wird die neueste Version des Connectors von den Agenten in der Agentengruppe heruntergeladen, die mit der aktuellen Umgebung verbunden ist. Dieser Connector unterstützt das Aussetzen des Downloads der neuesten Connector-Version durch die Verwendung der Automatische Connector-Aktualisierung deaktivieren Organisationsrichtlinie.

  • Änderungen speichern: Klicken Sie, um die Konfiguration der Verbindung zu speichern und zu schließen.

  • Änderungen verwerfen: Nachdem Sie Änderungen an einer neuen oder bestehenden Konfiguration vorgenommen haben, klicken Sie, um die Konfiguration ohne Speichern zu schließen. Eine Nachricht fragt Sie, ob Sie die Änderungen verwerfen möchten.

  • Löschen: Nachdem Sie eine bestehende Verbindungs-Konfiguration geöffnet haben, klicken Sie, um die Verbindung dauerhaft aus dem Projekt zu löschen und die Konfiguration zu schließen (siehe Komponentenabhängigkeiten, Löschung und Entfernung). Eine Nachricht fragt Sie, ob Sie die Verbindung löschen möchten.

Nächste Schritte

Nachdem eine HTTP v2-Verbindung erstellt wurde, platzieren Sie einen Aktivitätstyp auf der Entwurfstafel, um Aktivitätsinstanzen zu erstellen, die entweder als Quellen (um Daten in einem Vorgang bereitzustellen) oder als Ziele (um Daten in einem Vorgang zu konsumieren) verwendet werden.

Menüaktionen für eine Verbindung und deren Aktivitätstypen sind im Projektbereich und in der Designkomponentenpalette zugänglich. Für Details siehe Aktionsmenüs in Connector-Grundlagen.

Diese Aktivitätstypen sind verfügbar:

  • PATCH: Wendet teilweise Änderungen an einer bestehenden Ressource auf einem Dienst an, der über das HTTP- oder HTTPS-Protokoll zugänglich ist, und kann als Quelle oder Ziel in einer Operation verwendet werden.

  • HEAD: Ruft die Statuszeile und den Header-Bereich einer Ressource auf einem Dienst ab, der über das HTTP- oder HTTPS-Protokoll zugänglich ist, und kann als Quelle oder Ziel in einer Operation verwendet werden.

  • POST: Erstellt eine neue Ressource auf einem Dienst, der über das HTTP- oder HTTPS-Protokoll zugänglich ist, und kann als Quelle oder Ziel in einer Operation verwendet werden.

  • GET: Ruft Informationen über eine Ressource auf einem Dienst ab, der über das HTTP- oder HTTPS-Protokoll zugänglich ist, und kann als Quelle oder Ziel in einer Operation verwendet werden.

  • OPTIONS: Ruft Informationen über die Kommunikationsoptionen für eine Ressource auf einem Dienst ab, der über das HTTP- oder HTTPS-Protokoll zugänglich ist, und kann als Quelle oder Ziel in einer Operation verwendet werden.

  • BULK: Sendet mehrere Anfragen an einen Dienst, der über das HTTP- oder HTTPS-Protokoll zugänglich ist, und kann als Quelle oder Ziel in einer Operation verwendet werden.

  • DELETE: Löscht eine Ressource auf einem Dienst, der über das HTTP- oder HTTPS-Protokoll zugänglich ist, und kann als Quelle oder Ziel in einer Operation verwendet werden.

  • PUT: Ersetzt eine bestehende Ressource auf einem Dienst, der über das HTTP- oder HTTPS-Protokoll zugänglich ist, und kann als Quelle oder Ziel in einer Operation verwendet werden.