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.

Erstellen oder Bearbeiten einer HTTP v2 Verbindung

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

• Der Registerkarte Projektendpunkte und -connectoren in der Designkomponentenpalette (siehe Designkomponentenpalette).
• Der Seite Globale Endpunkte (siehe Einen globalen Endpunkt erstellen in Globalen Endpunkten).

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

• Der Registerkarte Projektendpunkte und -connectoren in der Designkomponentenpalette (siehe Designkomponentenpalette).
• Der Registerkarte Komponenten im Projektbereich (siehe Komponentenaktionsmenü in Projektbereich Komponentenregister).
• Der Seite Globale Endpunkte (siehe Einen globalen Endpunkt bearbeiten in Globalen Endpunkten).

Konfigurieren einer HTTP v2-Verbindung

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

• 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-Verbindungs-Authentifizierungstypen 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 der Amazon Web Services (AWS) Signatur 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.

  • 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.

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

  

  • Retry Interval (Seconds): 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.

  • Max Retries: 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.

Jeder erneute Versuch 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 der Operation nach dem erneuten Versuch bis zur maximalen Anzahl an Versuchen 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.

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

    • Benutzerdefiniert: Proxy-Einstellungen werden aktiviert, indem die Eingaben verwendet werden, die in den zusätzlichen Feldern angegeben sind, die verfügbar werden, wenn diese Option ausgewählt wird. Diese Option umgeht die private Agent-Proxy-Konfiguration, falls eine vorhanden ist.

      

      • 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 zur Authentifizierung des HTTP-Proxy-Servers ein.
      • Passwort: Geben Sie das Passwort zur Authentifizierung des HTTP-Proxy-Servers ein.
      • NTLM-Domäne: Geben Sie die NTLM-Domäne zur Authentifizierung des HTTP-Proxy-Servers ein.
      • Unbestätigte Zertifikate, die vom Proxy verwendet werden, zulassen: Wählen Sie aus, um unbestätigte Zertifikate zuzulassen, die vom HTTP-Proxy-Server verwendet werden.

    • Standard: Proxy-Einstellungen sind aktiviert, wobei die private Agent-Proxy-Konfiguration verwendet wird, falls eine vorhanden ist. Wenn in der Agent-Konfiguration keine Proxy-Einstellungen angegeben sind, hat die Standard-Einstellung das gleiche Ergebnis wie die Deaktivieren-Einstellung.

    • Deaktivieren: Proxy-Einstellungen sind deaktiviert und umgehen die private Agent-Proxy-Konfiguration, falls eine vorhanden ist.

  • Erweiterte HTTP-Eigenschaften: Falls zutreffend, setzen Sie diese erweiterten Optionen:

    • Content-Type: Geben Sie den Content-Type der Anforderungsstruktur an, 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 Anforderungsheader in der Aktivitätsausführung senden 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 wird, gilt folgende Reihenfolge der Priorität:

      1. Ein Content-Type-Header, der in der Tabelle Zusätzliche Einstellungen 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 headers-Knoten der Anforderungsumwandlung bereitgestellt wird, überschreibt die verbleibenden Felder.
      4. Ein Content-Type-Header, der im Feld Anforderungsheader einer HTTP v2-Aktivität bereitgestellt wird, überschreibt das verbleibende Feld.
      5. Ein Content-Type-Header, der im Feld Anforderungsheader einer HTTP v2-Verbindung bereitgestellt wird, hat, wenn Anforderungsheader 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 Anforderung einer Aktivität gemäß der oben genannten Reihenfolge der Priorität hinzugefügt. Diese Reihenfolge basiert darauf, wie Dienste typischerweise doppelte Header in einer Anfrage behandeln.

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

      Alternativ kann dieser Header in anderen UI-Konfigurationsfeldern angegeben oder in der Anforderungsumwandlung bereitgestellt werden. Wenn dieser Header an mehreren Stellen angegeben wird, gilt folgende Reihenfolge der Priorität:

      1. Ein Accept-Encoding-Header, der im Knoten headers der Anforderungsumwandlung 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 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 in der oben genannten Reihenfolge hinzugefügt. Diese Reihenfolge basiert darauf, wie Dienste typischerweise mit doppelten Headern in einer Anfrage umgehen.

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

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

      1. Ein Transfer-Encoding-Header, der im Knoten headers der Anforderungsumwandlung 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 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 in der oben genannten 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.

    • 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 kodieren.

    • Weiterleitungen folgen: Wählen Sie diese Option, um dem Connector zu erlauben, mit allen Weiterleitungen auf der Basis-URL 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 Anfrageparameter 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 befolgt:

      1. Ein Header, der im headers-Knoten der Anforderungsumwandlung bereitgestellt wird, überschreibt alle Felder darunter.
      2. Ein Header, der im Feld Anforderungsheader einer HTTP v2-Aktivität bereitgestellt wird, überschreibt das verbleibende Feld darunter.
      3. Ein Header, der im Feld Anforderungsheader einer HTTP v2-Verbindung (dieses Feld) bereitgestellt wird, hat, wenn Anforderungsheader 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 gemäß der oben genannten Reihenfolge 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. Andernfalls führt dies 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 Request Headers-Tabelle zeigen das Variablen-Icon nur im Bearbeitungsmodus an. Damit die Variablenwerte dieser Felder zur Laufzeit befüllt werden, muss die Agenten-Version mindestens 10.75 / 11.13 sein.

      Felder in der Request Headers-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 bei der Ausführung der Aktivität senden: Wählen Sie aus, um Header, die in Request Headers definiert sind, an HTTP v2-Aktivitäten weiterzugeben. Konsultieren Sie die oben genannten 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 Autorisierung senden. Ein Test gilt als erfolgreich, wenn ein beliebiger 2xx HTTP-Statuscode zurückgegeben wird. Eine 405 Method Not Allowed-Antwort wird ebenfalls als erfolgreich betrachtet. 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 Organisation Richtlinie Disable Auto Connector Update.

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

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

• Löschen: Nachdem eine bestehende Verbindungs-Konfiguration geöffnet wurde, 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 wirklich löschen möchten.

Nächste Schritte

Nachdem eine HTTP v2-Verbindung erstellt wurde, platzieren Sie einen Aktivitätstyp auf der Entwurfsgrafik, 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 ihre Aktivitätstypen sind im Projektbereich und in der Palette der Entwurfskomponenten zugänglich. Für Details siehe Aktionsmenüs in Connector-Grundlagen.

Diese Aktivitätstypen sind verfügbar:

• PATCH: Wendet partielle Ä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 einem Vorgang 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 einem Vorgang 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 einem Vorgang 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 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 zugänglich 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 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 vorhandene 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.