Zum Inhalt springen

HTTP v2 PATCH-Aktivität

Einführung

Eine HTTP v2 PATCH-Aktivität, die ihre HTTP v2-Verbindung verwendet, wendet partielle Änderungen an einer bestehenden Ressource auf einem über das HTTP- oder HTTPS-Protokoll zugänglichen Dienst an und kann entweder als Quelle (um Daten in einer Operation bereitzustellen) oder als Ziel (um Daten in einer Operation zu konsumieren) verwendet werden.

Erstellen einer HTTP v2 PATCH-Aktivität

Eine Instanz einer HTTP v2 PATCH-Aktivität wird aus einer HTTP v2-Verbindung unter Verwendung des Aktivitätstyps PATCH erstellt.

Um eine Instanz einer Aktivität zu erstellen, ziehen Sie den Aktivitätstyp auf die Entwurfsfläche oder kopieren Sie den Aktivitätstyp und fügen Sie ihn auf der Entwurfsfläche ein. Weitere Informationen finden Sie unter Erstellen einer Aktivitäts- oder Toolinstanz in Komponentenwiederverwendung.

Eine vorhandene HTTP v2 PATCH-Aktivität kann von diesen Orten aus bearbeitet werden:

Konfigurieren einer HTTP v2 PATCH-Aktivität

Befolgen Sie diese Schritte, um eine HTTP v2 PATCH-Aktivität zu konfigurieren:

Schritt 1: Geben Sie einen Namen ein und spezifizieren Sie die Einstellungen

In diesem Schritt geben Sie einen Namen für die Aktivität ein und spezifizieren die URL, Anfrageparameter, Anfrageheader und zusätzliche Einstellungen. Jedes Benutzeroberflächenelement dieses Schrittes 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ü anzuzeigen, das vorhandene Variablen zur Auswahl auflistet.

Wichtig

Felder in den Tabellen zeigen das Symbol für Variablen nur im Bearbeitungsmodus an. Damit die Variablenwerte dieser Felder zur Laufzeit befüllt werden, muss die Agentenversion mindestens 10.75 / 11.13 sein.

  • Name: Geben Sie einen Namen ein, um die Aktivität zu identifizieren. Der Name muss für jede HTTP v2 PATCH-Aktivität eindeutig sein und darf keine Schrägstriche / oder Doppelpunkte : enthalten.

  • Pfad: Geben Sie eine URL an, die für die Aktivität verwendet werden soll:

    • Wenn das Feld leer gelassen wird, wird die Basis-URL, die in der HTTP v2-Verbindung konfiguriert ist, zur Laufzeit verwendet.
    • Wenn ein Teilpfad angegeben wird, wird er an die Basis-URL, die in der HTTP v2-Verbindung konfiguriert ist, angehängt.
    • Wenn eine vollständige URL angegeben wird, überschreibt sie die Basis-URL, die in der HTTP v2-Verbindung konfiguriert ist.

    Anforderungsparameter können eingeschlossen werden, indem sie in geschweifte Klammern { } gesetzt werden. Abfrageparameter (wie /queryrecord?id=10) können ebenfalls verwendet werden.

    • URL: Zeigt die vollständige URL an, die zur Laufzeit verwendet werden soll.

  • Anforderungsparameter: Klicken Sie auf das Hinzufügen-Symbol , um eine Zeile in der Tabelle unten hinzuzufügen und einen Namen sowie einen Wert für jeden Anforderungsparameter einzugeben. Die bereitgestellten Anforderungsparameter werden automatisch URL-kodiert.

    Alternativ können Anforderungsparameter in der Anforderungsumwandlung bereitgestellt werden. Anforderungsparameter, die keinen gemeinsamen Schlüssel haben, werden kumulativ gesendet, unabhängig davon, wo sie angegeben sind. Wenn derselbe Parameter-Schlüssel sowohl in diesem Feld als auch in der Anforderungsumwandlung angegeben ist, hat der in der Umwandlung angegebene Vorrang.

    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.

    Wichtig

    Felder in der Tabelle Anforderungsparameter zeigen das Symbol für Variablen nur im Bearbeitungsmodus an. Damit die Variablenwerte dieser Felder zur Laufzeit ausgefüllt werden, muss die Agenten-Version mindestens 10.75 / 11.13 sein.

    Felder in der Tabelle Anforderungsparameter 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: Klicken Sie auf das Hinzufügen-Symbol , um eine Zeile in der Tabelle unten hinzuzufügen und einen Namen sowie einen Wert für jeden Anforderungsheader einzugeben.

    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 bereitgestellter Header überschreibt alle nachfolgenden Felder.
    2. Ein in dem Request Headers-Feld einer HTTP v2 PATCH-Aktivität (dieses Feld) bereitgestellter Header überschreibt die verbleibenden Felder darunter.
    3. Ein in dem Request Headers-Feld einer HTTP v2-Verbindung, 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-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.

    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.

    Wichtig

    Felder in der Request Headers-Tabelle zeigen das Symbol für Variablen nur im Bearbeitungsmodus an. Damit die Variablenwerte dieser Felder zur Laufzeit befüllt werden, muss die Agenten-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\"};.

  • Zusätzliche Einstellungen: Klicken Sie auf das Hinzufügen-Symbol , um eine Zeile in der Tabelle unten hinzuzufügen und einen Namen und Wert für jede zusätzliche Einstellung einzugeben.

    Diese zusätzlichen Einstellungen werden unterstützt:

    Schlüssel
    		 Standardwert Datentyp Beschreibung
    connection-timeout 30000 Ganzzahl Das Übertragungs-Timeout in Millisekunden. Wenn diese Einstellung nicht angegeben ist, beträgt das Standardübertragungs-Timeout 30000 Millisekunden (30 Sekunden). Setzen Sie es auf 0 für ein unbegrenztes Timeout.
    content-type — Zeichenkette Der Inhaltstyp der Anforderungsstruktur, die von der jeweiligen API erwartet wird. Zum Beispiel text/plain, application/json, application/x-www-form-urlencoded usw. Wenn diese Einstellung nicht angegeben ist, gibt es keinen Standardwert.
    max-redirect 50 Ganzzahl Die maximale Anzahl von Weiterleitungen, denen gefolgt werden soll. Wenn diese Einstellung nicht angegeben ist, beträgt der Standardwert 50 Weiterleitungen. Setzen Sie es auf 0 oder eine negative Zahl, um das Folgen von Weiterleitungen zu verhindern.
    trailing-linebreaks false Zeichenkette Entfernt führende und nachfolgende Leerzeichen und Zeilenumbrüche, wenn auf true gesetzt. Wenn diese Einstellung nicht angegeben oder auf false gesetzt ist, bleibt die Daten unverändert.

    Alternativ können zusätzliche Einstellungen in der Anforderungsumwandlung bereitgestellt werden. Zusätzliche Einstellungen, die keinen gemeinsamen Schlüssel haben, werden kumulativ gesendet, unabhängig davon, wo sie angegeben sind. Für alle Einstellungen, mit Ausnahme des Inhalts-Typs, hat der Schlüssel, der sowohl in diesem Feld als auch in der Anforderungsumwandlung angegeben ist, die höchste Priorität.

    Für content-type hat ein hier angegebener Wert Vorrang vor allen anderen Stellen in der Benutzeroberfläche, an denen der Inhalts-Typ angegeben werden kann. Wenn der Inhalts-Typ an mehreren Stellen angegeben ist, wird folgende Reihenfolge der Priorität befolgt:

    1. Ein Content-Type-Header, der in der Zusätzliche Einstellungen-Tabelle einer HTTP v2 PATCH-Aktivität (dieser Tabelle) bereitgestellt wird, überschreibt alle untenstehenden Felder.
    2. Das bodyContentType-Feld, das in einer Anforderungsumwandlung angegeben ist, überschreibt die verbleibenden Felder unten.
    3. Ein Content-Type-Header, der im headers-Knoten der Anforderungsumwandlung bereitgestellt wird, überschreibt die verbleibenden Felder unten.
    4. Ein Content-Type-Header, der im Anforderungsheader-Feld einer HTTP v2 PATCH-Aktivität bereitgestellt wird, überschreibt das verbleibende Feld unten.
    5. Ein Content-Type-Header, der im Anforderungsheader-Feld einer HTTP v2-Verbindung bereitgestellt wird, hat, wenn Anforderungsheader bei 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 mit doppelten Headern in einer Anfrage umgehen.

    Um die Zeile zu speichern, klicken Sie auf das Symbol zum Einreichen 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 Bearbeitungssymbol oder das Löschsymbol .

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

    Wichtig

    Felder in der Zusätzliche Einstellungen-Tabelle zeigen das Symbol für Variablen 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 Zusätzliche Einstellungen-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\"};.

  • Multipart: Wählen Sie aus, um multipart/form-data-Anfragen bei der Verwendung von Standard-Schemas zu unterstützen. Dies ist erforderlich für Anfragen, die RFC 1867 Formular-Uploads enthalten.

    Hinweis

    Bei der Verwendung von benutzerdefinierten Schemas wird multipart/form-data nicht unterstützt.

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

    • Betriebsfehler bei nicht erfolgreichem Statuscode ignorieren: Wählen Sie aus, damit Operationen einen erfolgreichen Status melden, auch wenn ein nicht erfolgreicher Statuscode von der API zurückgegeben wird, die der Connector aufruft. Der Standardwert ist nicht ausgewählt.

    • HTTP-Statuscode auswählen, der während der Ausführung der Operation als erfolgreich betrachtet werden soll: Wählen Sie entweder Nach Klasse gruppiert oder Granular (Manuelle Eingabe), um die angegebenen Statuscodes in den Betriebsprotokollen als erfolgreich zu betrachten.

      • Nach Klasse gruppiert: Wenn ausgewählt, wird ein Dropdown angezeigt mit Klassen von nicht erfolgreichen Statuscodes, die als erfolgreich behandelt werden sollen. Die Dropdown-Optionen umfassen 3xx Umleitung, 4xx Client-Fehler und 5xx Server-Fehler. Der Standardwert des Dropdowns ist nicht ausgewählt.

      • Granular (Manuelle Eingabe): Wenn ausgewählt, wird ein Feld angezeigt, um manuell eine durch Kommas getrennte Liste von nicht erfolgreichen Statuscodes einzugeben, die als erfolgreich behandelt werden sollen. Diese Liste kann gleichzeitig verschiedene Klassen von Statuscodes enthalten. Der Standardwert des Feldes ist leer.

  • Speichern & Beenden: Wenn aktiviert, klicken Sie, um die Konfiguration für diesen Schritt zu speichern und die Aktivitätskonfiguration zu schließen.

  • Weiter: Klicken Sie, um die Konfiguration für diesen Schritt vorübergehend zu speichern und zum nächsten Schritt fortzufahren. Die Konfiguration wird nicht gespeichert, bis Sie die Schaltfläche Fertig im letzten Schritt klicken.

  • Änderungen verwerfen: Nach dem Vornehmen von Änderungen klicken Sie, um die Konfiguration zu schließen, ohne die an einem Schritt vorgenommenen Änderungen zu speichern. Eine Nachricht fordert Sie auf, zu bestätigen, dass Sie die Änderungen verwerfen möchten.

Schritt 2: Bereitstellung des Anforderungsschemas

In diesem Schritt können Sie ein benutzerdefiniertes Anforderungsschema bereitstellen. Wenn Sie kein benutzerdefiniertes Anforderungsschema bereitstellen, wird das Standardanforderungsschema des Connectors verwendet.

  • Anforderungsschema bereitstellen: Das Anforderungsschema definiert die Struktur der Anforderungsdaten, die von der HTTP v2 PATCH-Aktivität verwendet werden. Für Anweisungen zum Ausfüllen dieses Abschnitts der Aktivitätskonfiguration verweisen Sie auf Schemas defined in an activity.

  • Zurück: Klicken Sie, um die Konfiguration für diesen Schritt vorübergehend zu speichern und zum vorherigen Schritt zurückzukehren.

  • Weiter: Klicken Sie, um die Konfiguration für diesen Schritt vorübergehend zu speichern und zum nächsten Schritt fortzufahren. Die Konfiguration wird nicht gespeichert, bis Sie auf die Schaltfläche Fertig im letzten Schritt klicken.

  • Änderungen verwerfen: Nach dem Vornehmen von Änderungen klicken Sie, um die Konfiguration zu schließen, ohne die an einem Schritt vorgenommenen Änderungen zu speichern. Eine Nachricht fordert Sie auf, zu bestätigen, dass Sie die Änderungen verwerfen möchten.

Schritt 3: Bereitstellung des Antwortschemas

In diesem Schritt können Sie ein benutzerdefiniertes Antwortschema bereitstellen. Wenn Sie kein benutzerdefiniertes Antwortschema bereitstellen, wird das Standardantwortschema des Connectors verwendet.

  • Antwortschema bereitstellen: Das Antwortschema definiert die Struktur der Antwortdaten, die von der HTTP v2 PATCH-Aktivität verwendet werden. Für Anweisungen zum Ausfüllen dieses Abschnitts der Aktivitätskonfiguration verweisen Sie auf Schemas defined in an activity.

  • Zusätzliche Eigenschaften aus der HTTP-Antwort im Schema einbeziehen: Wenn Ja, gespeichertes Schema verwenden oder Ja, neues Schema bereitstellen ausgewählt ist und das verwendete Schema einen XML- oder JSON-Dateityp hat, wird das Kontrollkästchen Zusätzliche Eigenschaften aus der HTTP-Antwort im Schema einbeziehen angezeigt. Wenn ausgewählt, wird das Schema in eine von Jitterbit definierte Struktur eingebettet, die es ermöglicht, zusätzliche Parameter im Schema zugänglich zu machen.

    {
  "__jitterbit_aditional_properties__": {
    "__jitterbit_api_headers__": [
      {
        "key": "",
        "value": ""
      },
      {
        "key": "",
        "value": ""
      }
    ],
    "__jitterbit_api_statuscode__": 200,
    "__jitterbit_api_errorbody__": ""
  },
  "root": {
    // Original JSON
  }
}

    <__jitterbitResponse__>
    <__jitterbit_aditional_properties__>
        <__jitterbit_api_headers__>
            <key>headerKey1</key>
            <value>headerValue1</value>
        </__jitterbit_api_headers__>
        <__jitterbit_api_headers__>
            <key>headerKey2</key>
            <value>headerValue2</value>
        </__jitterbit_api_headers__>
        <__jitterbit_api_statuscode__>200</__jitterbit_api_statuscode__>
        <__jitterbit_api_errorbody__>
        </__jitterbit_api_errorbody__>
    </__jitterbit_aditional_properties__>
    <root>
        <!-- Original XML -->
    </root>
</__jitterbitResponse__>

    • __jitterbit_api_headers__: Gibt die von der Anfrage bereitgestellten Header zurück.

    • __jitterbit_api_statuscode__: Gibt den Statuscode der Anfrage zurück.

    • __jitterbit_api_errorbody__: Gibt den Antwortinhalt der Anfrage im String-Format zurück, wenn die Anfrage einen erfolglosen Statuscode zurückgibt.

    • root: Beherbergt die ursprüngliche Struktur des Antwortschemas.

    Hinweis

    Wenn ausgewählt, wird ein neues Schema mit dem Wrapper generiert. Die Struktur des ursprünglichen Schemas bleibt innerhalb von root erhalten. Da zu diesem Zweck ein neues Schema generiert wird, kann das ursprüngliche Schema ohne den Wrapper später bei Bedarf verwendet werden.

  • Zurück: Klicken Sie, um die Konfiguration für diesen Schritt vorübergehend zu speichern und zum vorherigen Schritt zurückzukehren.

  • Weiter: Klicken Sie, um die Konfiguration für diesen Schritt vorübergehend zu speichern und zum nächsten Schritt fortzufahren. Die Konfiguration wird nicht gespeichert, bis Sie die Schaltfläche Fertig im letzten Schritt klicken.

  • Änderungen verwerfen: Klicken Sie, um die Konfiguration zu schließen, ohne die Änderungen an einem Schritt zu speichern. Eine Nachricht fordert Sie auf, zu bestätigen, dass Sie die Änderungen verwerfen möchten.

Schritt 4: Überprüfen der Datenschemas

Die konfigurierten Anfrage- und Antwortschemas werden angezeigt.

  • Datenschemas: Diese Datenschemas werden von benachbarten Transformationen geerbt und während der Transformation Mapping erneut angezeigt.

    Wenn in den vorherigen Schritten benutzerdefinierte Schemas bereitgestellt wurden, werden diese angezeigt. Wenn keine benutzerdefinierten Schemas bereitgestellt wurden, werden die Standard-Schemas, die mit dem Connector geliefert werden, angezeigt.

    Für HTTP v2-Aktivitäten regenerieren sich die Datenschemas automatisch basierend auf den Aktualisierungen, die an den in den vorherigen Schritten definierten Schemas vorgenommen wurden.

    Vorsicht

    HTTP v2-Aktivitäten, die vor der Harmony-Version 10.85 / 11.23 erstellt wurden, können eine manuelle Schaltfläche Aktualisieren aufweisen, die aufgrund zuvor definierter Projektmetadaten vorhanden ist. Wenn vorhanden, interagieren Sie nicht mit dieser Schaltfläche. Erstellen Sie eine neue Instanz einer betroffenen Aktivität, um sie zu entfernen.

    Die Standardanfrage- und Antwortschemata bestehen aus diesen Knoten und Feldern:

    • Anfrage:

      Anfrage-Schema Knoten/Feld Hinweise
      json Format des Anfrage-Schemas
      request Anfrage-Knoten
      root Wurzelknoten
      headers Knoten der Header
      item Knoten eines spezifischen Headers
      key Schlüssel des Headers
      value Wert des Headers
      requestParameters Knoten der Anfrageparameter
      item Knoten eines spezifischen Anfrageparameters
      key Schlüssel des Anfrageparameters
      value Wert des Anfrageparameters
      multipart Knoten eines Multipart (nur enthalten, wenn Multipart in der Aktivitätskonfigurations-UI ausgewählt ist und Standard-Schemata verwendet werden)
      plainText Knoten der Klartextteile eines Multiparts
      item Knoten eines spezifischen Klartextteils im Multipart
      key Schlüssel des Klartextteils, der auf sein name-Attribut im Anfragepayload abgebildet wird
      value Wert des Klartextteils, der auf seinen Inhalt im Anfragepayload abgebildet wird
      contentType Content-Type des Klartextteils

      Hinweis

      Dieses Feld hat Vorrang vor einem Content-Type-Header, der im headers-Knoten angegeben ist.
      fileData Knoten der Dateidaten eines Multiparts
      item Knoten eines spezifischen Dateidatenparts im Multipart
      key Schlüssel des Dateidatenparts, der auf seine name- und filename-Attribute im Anfragepayload abgebildet wird. Er sollte die Dateierweiterung enthalten, wenn bekannt

      Hinweis

      Wenn ein Pfad für diesen Schlüssel angegeben wird und das Feld fileName leer gelassen wird, enthält das Attribut filename nur den Namen und die Erweiterung der Datei.
      value Wert des Dateidatenparts, der auf seinen Inhalt im Anfragepayload abgebildet wird

      Wichtig

      Der für diesen Wert angegebene String stellt die Datei selbst dar und muss im Base64-Format kodiert sein. Siehe Base64encodefile in Kryptografischen Funktionen für Informationen zur Kodierung einer Datei mit einem Skript.
      fileName String, der den Dateinamen des Dateidatenparts darstellt, der auf sein filename-Attribut im Anfragepayload abgebildet wird. Er sollte die Dateierweiterung enthalten, wenn bekannt. Dieses Feld hat Vorrang vor dem, was im key-Feld für das filename-Attribut definiert ist.
      mimeType String, der den MIME (Medien)-Typ des Dateidatenparts darstellt, unabhängig von den in den key- oder fileName-Feldern angegebenen Dateierweiterungen
      additionalSettings Knoten zusätzlicher Einstellungen
      item Knoten einer spezifischen zusätzlichen Einstellung
      key Schlüssel der zusätzlichen Einstellung
      value Wert der zusätzlichen Einstellung
      body Anfragekörper
      bodyContentType Content-Type des Anfragekörpers

      Hinweis

      Dieses Feld hat Vorrang vor einem Content-Type-Header, der im headers-Knoten angegeben ist.

    • Antwort:

      Antwort-Schema Knoten/Feld Hinweise
      json Format des Antwortschemas
      response Antwortknoten
      responseItem Knoten des Antwortelements
      status Ein Boolean, der angibt, ob eine Antwort zurückgegeben wurde
      properties Eigenschaften der Antwort
      headers Knoten der Header
      item Knoten eines spezifischen Headers
      key Schlüssel des Headers
      value Wert des Headers
      responseContent Der Antwortkörper oder Inhaltspayload
      error Fehlerknoten
      statusCode HTTP-Statuscode der Antwort
      statusMessage Statusnachricht der Antwort
      details Einzelheiten zur Antwort

  • Zurück: Klicken Sie, um die Konfiguration für diesen Schritt vorübergehend zu speichern und zum vorherigen Schritt zurückzukehren.

  • Fertig: Klicken Sie, um die Konfiguration für alle Schritte zu speichern und die Aktivitätskonfiguration zu schließen.

  • Änderungen verwerfen: Nach Änderungen klicken Sie, um die Konfiguration zu schließen, ohne die vorgenommenen Änderungen an einem Schritt zu speichern. Eine Nachricht fragt Sie, ob Sie die Änderungen wirklich verwerfen möchten.

Nächste Schritte

Nachdem Sie eine HTTP v2 PATCH-Aktivität konfiguriert haben, vervollständigen Sie die Konfiguration der Operation, indem Sie andere Aktivitäten oder Werkzeuge als Operation Schritte hinzufügen und konfigurieren. Sie können auch die Betriebseinstellungen konfigurieren, die die Möglichkeit umfassen, Operationen zusammenzuführen, die sich in denselben oder unterschiedlichen Workflows befinden.

Menüaktionen für eine Aktivität sind im Projektbereich und auf der Entwurfsgrafik zugänglich. Für Details siehe Aktivitätsaktionsmenü in Connector-Grundlagen.

HTTP v2 PATCH-Aktivitäten, die als Quelle verwendet werden, können mit diesen Betriebsmustern verwendet werden:

HTTP v2 PATCH-Aktivitäten, die als Ziel verwendet werden, können mit diesen Betriebsmustern verwendet werden:

Um die Aktivität mit Skriptfunktionen zu verwenden, schreiben Sie die Daten an einen temporären Speicherort und verwenden Sie dann diesen temporären Speicherort in der Skriptfunktion.

Wenn Sie bereit sind, setzen Sie die Operation ein und führen Sie sie aus und validieren Sie das Verhalten, indem Sie die Betriebsprotokolle überprüfen.