Zum Inhalt springen

HTTP v2-Verbindung in Jitterbit Studio

Einführung

Eine HTTP v2-Verbindung, die mit dem HTTP v2-Connector erstellt wird, stellt Zugriff über das HTTP- oder HTTPS-Protokoll auf einen Service wie eine REST-API, GraphQL-API oder ein Webformular her. Nach der Konfiguration einer Verbindung können Sie HTTP v2-Aktivitäten erstellen, die dieser Verbindung zugeordnet sind und entweder als Quellen (um Daten in einem Vorgang bereitzustellen) oder als Ziele (um Daten in einem Vorgang zu verarbeiten) verwendet werden.

Hinweis

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

HTTP v2-Verbindung erstellen oder bearbeiten

Eine neue HTTP v2-Verbindung wird mit dem HTTP v2-Connector von einem dieser Orte aus erstellt:

Eine vorhandene HTTP v2-Verbindung kann von diesen Orten aus bearbeitet werden:

HTTP v2-Verbindung konfigurieren

Nachfolgend wird jedes Benutzeroberflächenelement des HTTP v2-Verbindungskonfigurationsbildschirms beschrieben.

Tipp

Felder mit einem -Variablensymbol unterstützen die Verwendung von globalen Variablen, Projektvariablen und Jitterbit-Variablen. Beginnen Sie entweder mit der Eingabe einer öffnenden eckigen Klammer [ in das Feld oder klicken Sie auf das -Variablensymbol, um ein Menü mit vorhandenen Variablen anzuzeigen, aus denen 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 auf eine bestimmte Verbindung und ihre 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 Pfad einer HTTP v2-Aktivität ausgefüllt ist:

    • Wenn ein Teilpfad oder keine URL im Feld Pfad einer Aktivität angegeben ist, wird die zur Laufzeit verwendete URL aus der Basis-URL und dem Pfad zusammengesetzt.

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

    Wichtig

    Um Variablen in Aktivitätsfeldern Pfad zu verwenden, geben Sie einen Teilpfad ein. Variablen werden in vollständigen URLs nicht unterstützt.

  • Autorisierung: Verwenden Sie das Menü, um den Authentifizierungstyp auszuwählen, der nachfolgend zusammengefasst ist. Die Konfiguration der einzelnen Authentifizierungstypen 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 Signature: Geben Sie eine AWS-Zugriffschlüssel-ID, einen geheimen Zugriffschlüssel, eine Region, einen Service und ein Sitzungstoken an, um diese mit Amazon Web Services (AWS) Signature Version 4 in Headern oder Abfrageparametern zu senden.

    • Basic Auth: Geben Sie einen Benutzernamen und ein Passwort an, um diese in Headern zu senden.

    • Bearer Token: Geben Sie ein Bearer-Token an, um es in Headern zu senden.

    • Digest Auth: Geben Sie einen Benutzernamen, ein Passwort, einen Realm, einen Nonce, einen Algorithmus, QOP, eine Nonce-Anzahl, einen Client-Nonce und einen Opaque-Wert an, um diese in Headern zu senden.

    • Hawk Authentication: Geben Sie eine Hawk-Authentifizierungs-ID, einen Authentifizierungsschlüssel, anwendungsspezifische Informationen, eine App-ID und DLG an, um diese in Headern zu senden.

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

    • NTLM Authentication: Geben Sie einen Benutzernamen, ein Passwort, eine Domäne und eine Workstation an, um diese in Headern zu senden, 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-Secret und den Scope bereit, um diese in Headern oder im Request-Body zu senden.

  • Retry: Diese Einstellung funktioniert nur bei Verwendung einer Umgebung, die einer Private-Agent-Gruppe zugeordnet ist. Sie wird verwendet, um eine Anfrage erneut zu senden, wenn ein HTTP v2-Endpunkt einen dieser Status-Codes zurückgibt: 500, 502, 503 oder 504.

    Diese Einstellung wird wirksam, wenn sie mit Private Agents Version 10.34 oder später verwendet wird.

    Aktivieren Sie das Kontrollkästchen Retry, um zusätzliche Konfigurationsoptionen zu erweitern.

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

    • Max Retries: Geben Sie die maximale Anzahl der Wiederholungen (maximal 5 Wiederholungen) ein, bei denen eine Anfrage an den HTTP v2-Endpunkt erneut gesendet wird. Wenn die Anfrage nach der maximalen Anzahl von Wiederholungen immer noch fehlschlägt, wird eine Ausnahme mit einer Fehlermeldung im Operationsprotokoll zurückgegeben. Darüber hinaus protokolliert der Private Agent jede Wiederholung in der Protokolldatei jitterbit.log.

      Jede Wiederholung wird als Teil desselben Operationslaufs behandelt, wobei nur ein einzelner Datensatz im Operationsprotokoll angezeigt wird. Alle Operationsaktionen, die für die Ausführung nachgelagerter Operationen konfiguriert sind, werden basierend auf dem Endstatus der Operation nach Wiederholungen bis zur maximalen Anzahl ausgelöst.

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

    • Get response content in base64 string: Wählen Sie diese Option, um base64-codierte responseContent von HTTP v2-Aktivitäten zurückzugeben.

    • Add Ciphers: Wählen Sie diese Option, um Cipher anzugeben, die mit der Verbindung in der Tabelle Enter Cipher Suites verwendet werden sollen. Klicken Sie auf das Hinzufügen-Symbol , um eine Cipher-Definition zur Tabelle hinzuzufügen. Beispiel: TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256.

      Hinweis

      Wenn Add Ciphers deaktiviert ist oder wenn die Tabelle Enter Cipher Suites leer gelassen wird, verwendet die HTTP v2-Verbindung einen Standardsatz von Cipher Suites. Die in der Tabelle Enter Cipher Suites definierten Cipher überschreiben den Standardsatz.

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

      Um eine einzelne Zeile zu bearbeiten oder zu löschen, bewegen Sie den Mauszeiger über die rechte Spalte und verwenden Sie das Bearbeitungs-Symbol oder das Lösch-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. Folgende Optionen stehen zur Verfügung:

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

      • Host: Geben Sie den Hostnamen des HTTP-Proxy-Servers ein.
      • Port: Geben Sie den Port des HTTP-Proxy-Servers ein.
      • Benutzer: Geben Sie den Benutzernamen für die HTTP-Proxy-Server-Authentifizierung ein.
      • Passwort: Geben Sie das Passwort für die HTTP-Proxy-Server-Authentifizierung ein.
      • NTLM-Domäne: Geben Sie die NTLM-Domäne für die HTTP-Proxy-Server-Authentifizierung ein.
      • Nicht verifizierte Zertifikate vom Proxy zulassen: Wählen Sie diese Option, um nicht verifizierte Zertifikate vom HTTP-Proxy-Server zu akzeptieren.
    • Standard: Proxy-Einstellungen werden aktiviert und verwenden die Proxy-Konfiguration des privaten Agenten, falls vorhanden. Wenn Proxy-Einstellungen nicht in der Agent-Konfiguration angegeben sind, hat die Einstellung Standard das gleiche Ergebnis wie die Einstellung Deaktivieren.

    • Deaktivieren: Proxy-Einstellungen sind deaktiviert und umgehen die Proxy-Konfiguration des privaten Agenten, falls vorhanden.

  • Erweiterte HTTP-Eigenschaften: Legen Sie diese erweiterten Optionen fest, falls zutreffend:

    • Content-Type: Geben Sie den Content-Type der Anforderungsstruktur ein, die von der jeweiligen API erwartet wird. Beispiele: 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 durch die Einstellung Anforderungsheader bei der Aktivitätsausführung senden nicht beeinflusst.

      Alternativ kann der Content-Type in anderen UI-Konfigurationsfeldern angegeben oder in der Anforderungstransformation bereitgestellt werden. Wenn der Content-Type an mehreren Stellen angegeben ist, gilt folgende Prioritätsreihenfolge:

      1. Ein Content-Type-Header in der Tabelle Zusätzliche Einstellungen einer HTTP-v2-Aktivität überschreibt alle folgenden Felder.
      2. Das Feld bodyContentType in einer Anforderungstransformation überschreibt die folgenden Felder.
      3. Ein Content-Type-Header im Knoten headers einer Anforderungstransformation überschreibt die folgenden Felder.
      4. Ein Content-Type-Header im Feld Anforderungsheader einer HTTP-v2-Aktivität überschreibt das folgende Feld.
      5. Ein Content-Type-Header im Feld Anforderungsheader einer HTTP-v2-Verbindung hat die niedrigste Priorität, wenn Anforderungsheader bei der Aktivitätsausführung senden aktiviert ist.

      Hinweis

      Wenn ein Header an mehreren Stellen definiert ist, wird jede Instanz des Headers der Anforderung einer Aktivität gemäß der obigen Prioritätsreihenfolge hinzugefügt. Diese Reihenfolge basiert darauf, wie Services typischerweise doppelte Header in einer Anforderung verarbeiten.

    • Content-Encoding aktivieren: Wählen Sie diese Option, um den Accept-Encoding-Header mit Gzip-Codierung zu senden. Dieses Feld wird durch die Einstellung Anforderungsheader bei der Aktivitätsausführung senden nicht beeinflusst.

      Alternativ kann dieser Header in anderen UI-Konfigurationsfeldern definiert oder in der Anforderungstransformation bereitgestellt werden. Wenn dieser Header an mehreren Stellen angegeben ist, gilt folgende Prioritätsreihenfolge:

      1. Ein Accept-Encoding-Header im Knoten headers einer Anforderungstransformation überschreibt alle folgenden Felder.
      2. Ein Accept-Encoding-Header im Feld Anforderungsheader einer HTTP-v2-Aktivität überschreibt das folgende Feld.
      3. Ein Accept-Encoding-Header im Feld Anforderungsheader einer HTTP-v2-Verbindung hat die niedrigste Priorität, wenn Anforderungsheader bei der Aktivitätsausführung senden aktiviert ist.

      Hinweis

      Wenn ein Header an mehreren Stellen definiert ist, wird jede Instanz des Headers der Anforderung einer Aktivität gemäß der obigen Prioritätsreihenfolge hinzugefügt. Diese Reihenfolge basiert darauf, wie Services typischerweise doppelte Header in einer Anforderung verarbeiten.

  • Chunked Transfer Encoding aktivieren: Wählen Sie diese Option, um den Header Transfer-Encoding: chunked zu senden. Verwenden Sie diese Option, wenn Sie große Datenmengen übertragen. Dieses Feld wird durch die Einstellung Request Headers in Activity Execution senden nicht beeinflusst.

    Alternativ kann dieser Header in anderen UI-Konfigurationsfeldern definiert oder in der Request-Transformation bereitgestellt werden. Wenn dieser Header an mehreren Stellen angegeben ist, gilt folgende Prioritätsreihenfolge:

    1. Ein Transfer-Encoding-Header, der im Knoten headers der Request-Transformation bereitgestellt wird, überschreibt alle nachfolgenden Felder.
    2. Ein Transfer-Encoding-Header, der im Feld Request Headers einer HTTP v2-Activity bereitgestellt wird, überschreibt das nachfolgende Feld.
    3. Ein Transfer-Encoding-Header, der im Feld Request Headers einer HTTP v2-Verbindung bereitgestellt wird, hat die niedrigste Priorität, wenn Request Headers in Activity Execution senden aktiviert ist.

    Hinweis

    Wenn ein Header an mehreren Stellen definiert ist, wird jede Instanz des Headers gemäß der oben beschriebenen Prioritätsreihenfolge zur Request einer Activity hinzugefügt. Diese Reihenfolge basiert darauf, wie Services typischerweise doppelte Header in einer Request verarbeiten.

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

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

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

  • Request-URL codieren: Wählen Sie diese Option, um die Request-URL zu URL-codieren. Standardmäßig (nicht ausgewählt) wird die Request-URL nicht prozentual codiert, sodass Leerzeichen als + gesendet werden. Wählen Sie diese Option, um die URL stattdessen prozentual zu codieren, sodass Leerzeichen als %20 gesendet werden.

    Wichtig

    Wenn diese Option aktiviert ist, muss die Request-URL vollständig uncodiert sein. Bereits codierte Zeichen werden doppelt codiert. Beispiel: example+string%20value wird zu example%20string%2520value codiert.

  • Umleitungen folgen: Wählen Sie diese Option, um dem Connector zu ermöglichen, Umleitungen auf der Basis-URL zu folgen. Wenn die Basis-URL umgeleitet wird und diese Einstellung nicht ausgewählt ist, tritt beim Testen der Verbindung und beim ersten Ausführen einer Operation ein Fehler auf. Wenn diese Option ausgewählt ist, wird das folgende Feld sichtbar:

    • Maximale Anzahl von Umleitungen: Geben Sie die Anzahl der Umleitungen ein, denen die Verbindung folgt, bevor ein Fehler zurückgegeben wird.
  • Nur anwendbar bei Verwendung von HTTPS: Verwenden Sie das Menü, um die Auswahl von Negotiate (Standard) bei Bedarf auf eine bestimmte TLS-Version zu ändern. Wählen Sie aus TLSv1.0, TLSv1.1, TLSv1.2 oder TLSv1.3.

  • Request Headers: Definieren Sie HTTP-Header für die Verbindung. Klicken Sie auf das Hinzufügen-Symbol , um der nachfolgenden Tabelle einen Header hinzuzufügen, und geben Sie für jeden Request-Parameter ein Schlüssel-Wert-Paar ein.

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

    Um eine einzelne Zeile zu bearbeiten oder zu löschen, bewegen Sie den Mauszeiger über die rechte Spalte und verwenden Sie das Bearbeitungs-Symbol oder das Lösch-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 Request-Transformation bereitgestellt werden. Header, die keinen gemeinsamen Schlüssel haben, werden kumulativ gesendet, unabhängig davon, wo sie angegeben sind. Request-Header-Werte sind nicht in Runtime-Protokollen enthalten.

    Wenn derselbe Header-Schlüssel an mehreren Stellen angegeben ist, gilt folgende Prioritätsreihenfolge:

    1. Ein Header, der im Knoten headers der Request-Transformation bereitgestellt wird, überschreibt alle nachfolgenden Felder.
    2. Ein Header, der im Feld Request Headers einer HTTP v2-Activity bereitgestellt wird, überschreibt das nachfolgende Feld.
    3. Ein Header, der im Feld Request Headers einer HTTP v2-Verbindung (dieses Feld) bereitgestellt wird, hat die niedrigste Priorität, wenn Request Headers in Activity Execution senden aktiviert ist.

Hinweis

Wenn ein Header an mehreren Stellen definiert ist, wird jede Instanz des Headers der Anfrage einer Aktivität gemäß der oben angegebenen Reihenfolge hinzugefügt. Diese Reihenfolge basiert darauf, wie Services typischerweise doppelte Header in einer Anfrage verarbeiten.

Warnung

Definieren Sie in HTTP v2-Aktivitäten nicht manuell Authorization-Request-Header, wenn die HTTP v2-Verbindung so konfiguriert ist, dass sie ihre eigenen Authorization-Request-Header je nach ausgewähltem Authentifizierungstyp sendet. Dies führt zur Beendigung und zum Fehlschlag des Vorgangs, bevor der Zielendpunkt erreicht wird, und wird als 400 Bad Request-Fehler protokolliert.

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

Wichtig

Felder in der Tabelle Request Headers zeigen das Variablensymbol nur im Bearbeitungsmodus an. Damit die Variablenwerte dieser Felder zur Laufzeit gefüllt werden, muss die Agent-Version mindestens 10.75 / 11.13 sein.

Felder in der Tabelle Request Headers unterstützen nicht die Verwendung von Variablen zum Übergeben von Raw JSON. Wenn Ihr Anwendungsfall das direkte Definieren von Raw JSON in den Feldern nicht unterstützt, maskieren Sie den JSON-Inhalt, bevor Sie ihn mit einer Variablen übergeben. Beispielsweise wird {"success": "true"}; zu {\"success\": \"true\"}; maskiert.

  • Request-Header in der Aktivitätsausführung senden: Wählen Sie diese Option, um Header, die in Request Headers definiert sind, an HTTP v2-Aktivitäten zu übergeben. Beachten Sie die oben angegebenen Reihenfolgen, um zu bestimmen, wie Header, die in einer HTTP v2-Verbindung definiert sind, mit Headern interagieren, die an anderen Stellen definiert sind.

  • Test: Klicken Sie, um die Verbindung zu überprüfen, indem Sie eine HTTP GET-Anfrage mit der konfigurierten Authentifizierung senden. Ein Test gilt als erfolgreich, wenn ein beliebiger HTTP-Statuscode der Serie 2xx zurückgegeben wird. Eine 405 Method Not Allowed-Antwort wird ebenfalls als erfolgreich behandelt. Wenn die Verbindung getestet wird, lädt der Agent die neueste Version des Connectors herunter. Diese Connector-Version wird von den Agents in der Agentgruppe heruntergeladen, die der aktuellen Umgebung zugeordnet ist. Dieser Connector unterstützt das Aussetzen des Downloads der neuesten Connector-Version durch die Organisationsrichtlinie Disable Auto Connector Update.

  • Speichern: Klicken Sie, um die Verbindungskonfiguration zu speichern und zu schließen.

  • Änderungen verwerfen: Nachdem Sie Änderungen an einer neuen oder vorhandenen Konfiguration vorgenommen haben, klicken Sie, um die Konfiguration ohne Speichern zu schließen. Eine Meldung fordert Sie auf, zu bestätigen, dass Sie die Änderungen verwerfen möchten.

  • Löschen: Nachdem Sie eine vorhandene Verbindungskonfiguration 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 Meldung fordert Sie auf, zu bestätigen, dass Sie die Verbindung löschen möchten.

Nächste Schritte

Nach dem Erstellen einer HTTP v2-Verbindung platzieren Sie einen Aktivitätstyp auf der Design-Canvas, um Aktivitätsinstanzen zu erstellen, die entweder als Quellen (um Daten in einem Vorgang bereitzustellen) oder als Ziele (um Daten in einem Vorgang zu verarbeiten) verwendet werden.

Menüaktionen für eine Verbindung und ihre Aktivitätstypen sind über den Projektbereich und die Design-Komponentenpalette zugänglich. Weitere Informationen finden Sie unter Aktionsmenüs in Connector-Grundlagen.

Diese Aktivitätstypen sind verfügbar:

  • PATCH: Wendet Teiländerungen auf eine vorhandene Ressource auf einem Service an, auf den über das HTTP- oder HTTPS-Protokoll zugegriffen werden kann, und kann als Quelle oder Ziel in einem Vorgang verwendet werden.

  • HEAD: Ruft die Statuszeile und den Header-Bereich einer Ressource auf einem Service ab, auf den über das HTTP- oder HTTPS-Protokoll zugegriffen werden kann, und kann als Quelle oder Ziel in einem Vorgang verwendet werden.

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

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

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

  • BULK: Sendet mehrere Anfragen an einen Dienst, der über das HTTP- oder HTTPS-Protokoll erreichbar ist, und kann als Quelle oder Ziel in einem Vorgang verwendet werden.

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

  • PUT: Ersetzt eine vorhandene Ressource auf einem Dienst, der über das HTTP- oder HTTPS-Protokoll erreichbar ist, und kann als Quelle oder Ziel in einem Vorgang verwendet werden.