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 und entweder als Quellen (um Daten in einem Vorgang bereitzustellen) oder als Ziele (um Daten in einem Vorgang zu konsumieren) verwendet 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 Globale Endpunkte).

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

• Der Registerkarte Projektendpunkte und -connectoren in der Designkomponentenpalette (siehe Designkomponentenpalette).
• Der Registerkarte Komponenten im Projektbereich (siehe Menü für Komponentenaktionen in Projektbereich Komponentenregister).
• Der Seite Globale Endpunkte (siehe Einen globalen Endpunkt bearbeiten in Globale Endpunkte).

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 verwendet, um die Verbindung zu testen. 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 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 aus, 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 erhalten: 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 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-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 und verwenden die private Agent-Proxy-Konfiguration, falls vorhanden. 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, wodurch die private Agent-Proxy-Konfiguration umgangen wird, falls vorhanden.

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

    • 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 bodyContentType-Feld, 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 definiert oder in der Anforderungsumwandlung bereitgestellt werden. Wenn dieser Header an mehreren Stellen angegeben ist, gilt folgende Reihenfolge:

      1. Ein Accept-Encoding-Header, der im headers-Knoten der Anforderungsumwandlung bereitgestellt wird, überschreibt alle nachfolgenden Felder.
      2. Ein Accept-Encoding-Header, der im Feld Anforderungsheader einer HTTP v2-Aktivität bereitgestellt wird, überschreibt das verbleibende Feld darunter.
      3. Ein Accept-Encoding-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 in die Anforderung einer Aktivität gemäß der oben genannten Reihenfolge hinzugefügt. Diese Reihenfolge basiert darauf, wie Dienste typischerweise doppelte Header in einer Anfrage behandeln.

    • 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 Anforderungsheader in der Aktivitätsausführung senden beeinflusst.

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

      1. Ein Transfer-Encoding-Header, der im headers-Knoten der Anforderungsumwandlung bereitgestellt wird, überschreibt alle nachfolgenden Felder.
      2. Ein Transfer-Encoding-Header, der im Feld Anforderungsheader einer HTTP v2-Aktivität bereitgestellt wird, überschreibt das verbleibende Feld darunter.
      3. Ein Transfer-Encoding-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 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.

    • Schwache Chiffren zulassen: Diese Option ist derzeit nicht funktionsfähig.

    • Verbindung offen halten: 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 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 der gleiche Header-Schlüssel an mehreren Stellen angegeben ist, wird folgende Reihenfolge der Priorität beachtet:

      1. Ein in der Anfrage-Transformation im headers-Knoten bereitgestellter Header überschreibt alle nachfolgenden Felder.
      2. Ein in dem Feld Request Headers einer HTTP v2-Aktivität bereitgestellter Header überschreibt die verbleibenden Felder.
      3. Ein in dem Feld Request Headers einer HTTP v2-Verbindung (dieses Feld), wenn Send Request Headers in Activity Execution aktiviert ist, hat 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 der Priorität aufgenommen. Diese Reihenfolge basiert darauf, wie Dienste typischerweise mit doppelten Headern in einer Anfrage umgehen.

      Warnung

      Definieren Sie keine Authorization-Anfrageheader manuell in HTTP v2-Aktivitäten, wenn die HTTP v2-Verbindung so konfiguriert ist, dass sie ihre eigenen Authorization-Anfrageheader 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-Anfrageheader der Aktivität nach Bedarf.

      Wichtig

      Felder in der Tabelle Request Headers zeigen das Variablen-Symbol nur im Bearbeitungsmodus an. Damit die Variablenwerte dieser Felder zur Laufzeit befü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, 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 von Aktivitäten senden: Wählen Sie aus, um die in Anforderungsheadern definierten Header 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 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 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 fordert Sie auf, zu bestätigen, dass 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 fordert Sie auf, zu bestätigen, dass 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 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 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.