Stapelverarbeitungsanforderungen

Eine Unteranforderung kann optional Abfrageparameter haben, die die entsprechende Unterantwort-Nutzdaten verfeinern.

Standardmäßig übernimmt jede Unteranforderung die Informationen in den Header des Hauptanforderungsobjekts. Die einzige Ausnahme hiervon ist der Header GW-Checksum. Dieser Header wird nicht übernommen, da es unwahrscheinlich ist, dass ein einzelner Prüfsummenwert mehreren Unteranforderungen entspricht. Optional können Sie Header-Werte für eine einzelne Unteranforderung angeben, die die entsprechenden Werte im Hauptanforderungsheader überschreiben.

Wenn eine Unteranforderung fehlschlägt, wird standardmäßig die Verarbeitung der verbleibenden Unteranforderungen fortgesetzt. Für jede Unteranforderung können Sie optional festlegen, dass die verbleibenden Unteranforderungen von ClaimCenter übersprungen werden müssen, wenn die Unteranforderung fehlschlägt.

Eine vollständige Liste der Optionen und weitere Informationen zu ihrer Funktionsweise finden Sie in der Datei batch_pl-1.0.schema.json.

Syntax für Stapelanforderungsaufrufe

Die Syntax für den Aufruf der Stapelanforderung lautet:

POST <applicationURL>/rest/<apiWithVersion>/batch

Wenn Sie beispielsweise einen Claim-API-Stapel aus einer Instanz von ClaimCenter auf Ihrem lokalen Computer ausführen, lautet der Aufruf:

POST http://localhost:8080/cc/rest/claim/v1/batch

Syntax für Nutzdaten einer Stapelanforderung

Die grundlegende Syntax für Nutzdaten einer Stapelanforderung lautet:

{
  "requests": [
    {
      "method": "<method>",
      "path": "<path>",
      "query": "<queryParameters>",
      "data":
        {
          "attributes": {
            "<field1>": "<value1>",
            "<field2>": "<value2>",
            ...
          }
        }
    },
    {
      "method": "<method>",
      "path": "<path>",
      "query": "<queryParameters>",
      "data":
        {
          "attributes": {
            "<field1>": "<value1>",
            "<field2>": "<value2>",
            ...
          }
        }
    },
    ...
  ]
}

Wobei gilt:

• <method> ist der Vorgang in Kleinbuchstaben, z. B. "get", "post", "patch" oder "delete".
• <path> ist der Endpunktpfad.
  • Dieser Pfad beginnt, als ob er unmittelbar dem API-Pfad folgt (einschließlich der Hauptversion, z. B. "/v1"). Beispiel: Angenommen, der Pfad für einen Befehl, der isoliert ausgeführt wird, lautet: http://localhost:8080/cc/rest/claim/v1/claims/cc:22/activities/cc:55. Der Pfad innerhalb eines Stapels lautet: /claims/cc:22/activities/cc:55
• <queryParmaters> ist eine optionale Zeichenfolge von Abfrageparametern. Starten Sie diese Zeichenfolge ohne ein "?".
• <field1/<value> sind die Feld- und Wertepaare des Anforderungstextes.

Die folgenden Abschnitte enthalten Beispiele für die Verwendung dieser Syntax.

Die einfachste Stapelanforderung besteht aus den standardmäßigen GET-Unteranforderungen. Dies beinhaltet keine Abfrageparameter und keine Anforderungs-Nutzdaten.

In diesem Beispiel besteht die Antwort aus drei Unterantworten. Jede Teilantwort besteht aus den Standardfeldern für jeden Schadenfall.

{
  "requests": [
    {
      "method": "get",
      "path": "/claims/demo_sample:1"
    },
    {
      "method": "get",
      "path": "/claims/demo_sample:2"
    },
    {
      "method": "get",
      "path": "/claims/demo_sample:3"
    }
  ]
}

Das folgende Beispiel zeigt eine Stapelanforderung mit mehreren GET-Unteranforderungen. Dieses Beispiel enthält Abfrageparameter für einige der GETs. Wie im Beispiel gezeigt, ist es möglich, dass einige Unteranforderungen Abfrageparameter verwenden, andere nicht. Die Unteranforderungen, die Abfrageparameter verwenden, können unterschiedliche Abfrageparameter verwenden.

Die Antwort besteht aus drei Teilantworten. Die Felder in den einzelnen Unterantworten variieren je nach Abfrageparametern.

{
  "requests": [
    {
      "method": "get",
      "path": "/claims/demo_sample:1",
      "query": "sort=lossDate"
    },
    {
      "method": "get",
      "path": "/claims/demo_sample:2",
      "query": "fields=*all"
    },
    {
      "method": "get",
      "path": "/claims/demo_sample:3"
    }
  ]
}

Das folgende Beispiel zeigt eine Stapelanforderung mit mehreren POST-Unteranforderungen. Dieses Beispiel enthält Anforderungs-Nutzdaten für jede Unteranforderung.

In diesem Beispiel werden zwei Notizen über POST an verschiedene Aktivitäten gesendet. Es wäre jedoch auch möglich, jede Notiz über POST an dieselbe Aktivität zu senden.

{
  "requests": [
    {
      "method": "post",
      "path": "/activities/xc:11/notes",
      "data":
        {
          "attributes": {
            "body": "Batch note 1"
          }
        }
    },
    {
      "method": "post",
      "path": "/activities/xc:73/notes",
      "data":
        {
          "attributes": {
            "body": "Batch note 2"
          }
        }      
    }
  ]
}

Jede Unteranforderung in einer Stapelanforderung unterscheidet sich von den anderen Unteranforderungen. Es ist nicht erforderlich, dass eine Unteranforderung ein Attribut mit einer anderen Unteranforderung teilt. Das folgende Beispiel zeigt eine Stapelanforderung mit mehreren Unteranforderungen, bei der jede Unteranforderung einen anderen Vorgang verwendet.

{
  "requests": [
    {
      "method": "post",
      "path": "/activities/xc:21/notes"
      "body": {
        "data": {
          "attributes": {
            "body": "Batch activity 1",
            "subject": "Batch activity 1",
            "topic": {
              "code": "general",
              "name": "General"
            }
          }
        }
      }
    },
    {
      "method": "patch",
      "path": "/notes/xc:22",
      "body": {
        "data": {
          "attributes": {
            "body": "PATCHed note body"
          }
        }
      },
    },
    {
      "method": "delete",
      "path": "/notes/xc:23"
    },
    {
      "method": "get",
      "path": "/activities/xc:24/notes",
      "query": "sort=subject&fields=id,subject"
    }
  ]
}

Im Folgenden finden Sie ein Beispiel für eine Stapelanforderung, bei der jede Unteranforderung eine Kopfzeile hat, die die Kopfzeile der Hauptanforderung überschreibt.

{
  "requests": [
    {
      "method": "delete",
      "path": "/activities/xc:55",
      "headers": [
        {
          "name": "GW-Checksum",
          "value": "2"
        }
      ]
    },
    {
      "method": "delete",
      "path": "/activities/xc:57",
      "headers": [
        {
          "name": "GW-Checksum",
          "value": "4"
        }
      ]
    }
  ]
}

Das folgende Beispiel zeigt eine Stapelanforderung, die onFail verwendet, um anzugeben, dass die verbleibenden Unteranforderungen übersprungen werden müssen, wenn eine der Unteranforderungen fehlschlägt.

{
  "requests": [
    {
      "method": "patch",
      "path": "/activities/xc:93",
      "body": {
        "data": {
          "attributes": {
            "subject": "PATCH body 1"
          }
        }
      },
      "onFail": "abort"
    },
    {
      "method": "patch",
      "path": "/activities/xc:94",
      "body": {
        "data": {
          "attributes": {
            "subject": "PATCH body 2"
          }
        }
      },
      "onFail": "abort"
    },
    {
      "method": "patch",
      "path": "/activities/xc:95",
      "body": {
        "data": {
          "attributes": {
            "subject": "PATCH body 3"
          }
        }
      }
    }
  ]
}

Stapelverarbeitungsanforderungen sind auf eine maximale Anzahl von Unteranforderungen begrenzt. Das Maximum wird durch den Konfigurationsparameter MaximumAllowedNumberOfBatchSubRequests angegeben. In der Basiskonfiguration hat dieser Parameter den Wert 100. Stapelverarbeitungsanforderungen mit mehr als der maximalen Anzahl von Unteranforderungen schlagen mit einer BadInputException fehl.

Je größer die Anzahl der Unteranforderungen in einer Stapelanforderung ist, desto größer ist die Wahrscheinlichkeit, dass die Leistung beeinträchtigt wird. Eine Stapelanforderung mit der maximalen Anzahl von Unteranforderungen kann zu einer langsamen Antwort führen, je nachdem, wie hoch das Maximum ist und was diese Unteranforderungen tun.

In der Basiskonfiguration beträgt die maximale Anzahl der Unteranforderungen 100. Dieser kann auf einen höheren Wert angehoben werden. Stapelverarbeitungsanforderungen mit einer erheblichen Anzahl von Unteranforderungen können jedoch negative Auswirkungen haben, z. B.:

• Die Anforderung beansprucht eine erhebliche Menge an Service-Ressourcen. Dies kann sowohl Speicher- als auch Datenbankressourcen umfassen.
• Die Anforderung dauert so lange, bis sie abgeschlossen ist, bis dem Anrufer eine Antwort zugestellt werden kann.

Daher empfiehlt Guidewire, die maximale Anzahl an Unteranforderungen auf den niedrigsten benötigten Wert zu setzen. Wenn ein berechtigtes geschäftliches Bedürfnis besteht, den Höchstwert über 100 anzuheben, empfiehlt Guidewire, das Limit nur so viel anzuheben, wie unbedingt erforderlich ist.

Beachten Sie außerdem, dass Stapelverarbeitungsanforderungen hinsichtlich der maximalen Größe eines Anforderungstextes Beschränkungen des Anwendungsservers unterliegen. Daher ist es möglich, dass eine Stapelanforderung zu groß für die Verarbeitung ist, selbst wenn die Anzahl der Unteranforderungen dem zulässigen Maximum entspricht oder darunter liegt.