コンポジット要求の管理

requests セクションのいずれかのサブ要求が失敗すると、Cloud API は以下のようになります。

• いずれのデータもコミットしない。
• selections セクションのいずれの GET も実行しない。
• 400 エラーを返す。

Cloud API も応答を返します。

• 応答の先頭は、「"requestFailed": true」になります。これにより、コンポジット要求がデータをコミットしなかったことが容易に識別されます。
• 最初のサブ要求が失敗しなかった場合（サブ要求がある場合）、応答が返されます。
  • これは、関連エンドポイント（およびクエリパラメータ）で指定された応答か、「"responseIncluded": false」のテキストかのいずれかになります。
  • 失敗したサブ要求の前に成功したオブジェクトの状態を確認できるので、標準の応答はデバッグ目的で役立てることができます。
• 失敗したサブ要求には、エラーメッセージが返されます。
• 失敗したサブ要求の後のサブ要求には、「"skipped": true」のテキストが返されます。
• selections セクションが含まれていた場合、各サブ選択に対して「"skipped": true」のテキストが返されます。

例えば、5 つのサブ要求とクエリのセットを含むコンポジット要求の応答は以下のとおりです。すべてのサブ要求で、responseIncluded が false に設定されます。3 つ目のサブ要求は、dueDate 属性のスペルが誤って ueDate となっていたため、失敗しています。

{
  "requestFailed": true,
  "responses": [
    {
      "responseIncluded": false
    },
    {
      "responseIncluded": false
    },
    {
      "requestError": {
        "details": [
          {
            "message": "Schema definition 'ext.common.v1.common_ext-
                1.0#/definitions/Note' does not define any property
                named 'ueDate'",
            "properties": {
              "lineNumber": 1,
              "parameterLocation": "body",
              "parameterName": "body"
            }
          }
        ],
        "developerMessage": "The request parameters or body had issues. 
           See the details elements for exact details of the problems.",
        "errorCode": "gw.api.rest.exceptions.BadInputException",
        "status": 400,
        "userMessage": "The request parameters or body had issues"
      },
      "status": 400
    },
    {
      "skipped": true
    },
    {
      "skipped": true
    }
  ],
  "selections": [
    {
      "skipped": true
    }
  ]
}

selections セクションのみにエラーがある場合、requests セクションのサブ要求が実行され、データがコミットされ、コンポジット要求では成功を示す応答コードの 200 が返されます。また、Cloud API では各サブ選択を可能な限り実行しようと試行します。

Cloud API では、コンポジット要求についての情報を、コンポジット要求レベルとサブ要求／サブ選択レベルの両方でログに記録します。この情報はログの CompositeSubRequest マーカーの下に表示されます。このマーカーは、通常の RestRequest マーカーの子となります。

サブ要求およびサブ選択のログメッセージにはそれぞれ、実際のパス、HTTP メソッド、apiFqn など、そのサブ要求／サブ選択についての詳細情報が記載されます。親要求のログとサブ要求のログの両方で、同じログパラメータ名と規則が使用されます。例えば、特定の値が空白の文字列でログに記録されるかどうかや、省略されるかどうかなどです。ただし、以下の点に注意が必要です。

• 一部のパラメータは、親要求に対してのみ意味を持つので、サブ要求レベルでは常に省略されます。
• コンポジット固有のパラメータがいくつか追加されます。

例えば、アクティビティ xc:202 に対する備考・経緯を 2 つ作成する例を前述のコンポジット要求が実行したとします。対応するログエントリは以下のように表示される場合があります。以下のように、1 つ目のメッセージは親要求に対するものであり、次の 2 つのメッセージは、2 つのサブ要求に対するものであることに注意してください。

server-id-207          749bdc4c-34b9-4f63-9b54-d1b0442af2c5 2021-12-13 
14:40:30,803 INFO <RestService[ GW.PL ]> Operation started 
{path="/composite/v1/composite", from="[0:0:0:0:0:0:0:1]", method="POST", 
query="", startTime=1227026673066900, message="", eventType="START", 
serverID="server-id-207"}

server-id-207 aapplegate 749bdc4c-34b9-4f63-9b54-d1b0442af2c5 2021-12-13 
14:40:30,894 INFO <CompositeSubRequest[ RestRequest ]> Operation status 
{path="/common/v1/activities/xc:202/notes", query="", method="POST", 
pathTemplate="/common/v1/activities/{activityId}/notes", 
apiFqn="ext.common.v1.common_ext-1.0", status=201, error="", userMessage="", 
devMessage="", elapsedTimeMs=53, message="Composite API subrequest 
succeeded", eventType="STATUS", serverID="server-id-207"}

server-id-207 aapplegate 749bdc4c-34b9-4f63-9b54-d1b0442af2c5 2021-12-13 
14:40:30,899 INFO <CompositeSubRequest[ RestRequest ]> Operation status 
{path="/common/v1/activities/xc:202/notes", query="", method="POST", 
pathTemplate="/common/v1/activities/{activityId}/notes", 
apiFqn="ext.common.v1.common_ext-1.0", status=201, error="", userMessage="", 
devMessage="", elapsedTimeMs=4, message="Composite API subrequest 
succeeded", eventType="STATUS", serverID="server-id-207"}

各サブ要求またはサブ選択では必ず、ログ記録文が生成され、サブ要求が成功したか、失敗したか、または前の失敗によりスキップされたかが示されます。また、ログ記録文が個別に追加され、コンポジット要求のコミットに対しては、コミットが成功したか、失敗したか、またはスキップされたかが示されます。

コンポジット要求の数は、サブ要求とサブ選択の最大数までに制限されています。最大数は、MaximumAllowedNumberOfCompositeSubRequests コンフィギュレーションパラメータで指定されます。ベースコンフィギュレーションでは、このパラメータは 100 に設定されています。コンポジット要求の数が最大数よりも多いと、BadInputException により失敗します。（この最大数は、サブ要求の数とサブ選択の数の合計です）。

コンポジット要求内のサブ要求の数が多いほど、パフォーマンスが低下する可能性が高くなります。コンポジット要求に最大数のサブ要求が含まれている場合は、最大数やそのサブ要求の実行内容に応じて、応答が遅くなる可能性があります。

サブ要求の最大数は、100 よりも大きい値に増やすことができます。ただし、コンポジット要求でサブ要求の数が非常に多いと、次のような悪影響を及ぼす可能性があります。

• 要求で大量のサービスリソースが利用される。これには、メモリとデータベースの両方のリソースが含まれる可能性があります。
• 要求の完了に長時間かかるため、応答が呼び出し元に送信される前にタイムアウトになる可能性があります。

したがって、Guidewire では、サブ要求の最大数を必要最小限の値に設定することをお勧めします。100 を超える値に最大数を変更するのにビジネス上正当な必要性がある場合、Guidewire では、上限を必要最小限だけ上げることをお勧めします。

また、コンポジット要求は、要求本文の最大サイズに関するアプリケーションサーバー制限に従うことに注意してください。したがって、サブ要求の数が許容最大数以下であっても、コンポジット要求が大きすぎて処理できない可能性もあります。