提供: Bright Pattern Documentation
移動先: 案内検索
• English

URLの取得

HTTP/HTTPS 経由で URL から GET、POST、PUT、PATCH、または削除メソッドを使用して Web コンテンツをリクエストし、受信したデータをワークフロー変数に解析します。


HTTP、HTTPS 基本認証、Bearer トークン、および OAuth 2.0 クライアント認証情報がサポートされています。作成 Webクライアント認証情報 アカウントを作成すると、認証情報を保存して、複数の「URLの取得」ブロック間で再利用できます。サポートされている CRM(ServiceNow, ServiceNow, MS Dynamics、または Zendesk)の場合、設定済みの 統合アカウント.



Fetch URL ワークフローブロック

条件付き終了

「Fetch URL」ブロックには、以下の3つの条件付き終了のいずれかが適用される場合があります:

失敗

HTTPメソッドの実行中にエラーが発生した場合、「失敗」という条件付き出口が選択されます。詳細については、以下の「HTTPレスポンスコード」をご参照ください。

データなし

HTTPレスポンスの本文にデータが返されない場合、「データなし」の条件付き終了が実行されます。

タイムアウト

「タイムアウト」条件分岐は、処理時間が設定した値を超過したときに実行されます。 「リクエストタイムアウト」 フィールドに入力された値を超えた場合に実行されます。

設定

「Fetch URL」ワークフローブロックの設定。

タイトルテキスト

タイトルテキストは、フローチャートに表示されるブロックインスタンスの名前です。

リクエストタイプ

フェッチで使用されるHTTPメソッドです。

リクエストタイプ(HTTPメソッド) コンテンツタイプ メモ
GET
  • application/json
  • application/x-www-form-urlencoded
  • application/soap+xml; charset=utf-8
GET、POST
  • application/json
  • application/x-www-form-urlencoded
  • application/soap+xml; charset=utf-8
  • multipart/form-data
  • 単一ファイルのアップロード。コンテンツタイプは以下に設定されています
  • 複数の添付ファイルやテキストパーツの追加が可能です
  • コンテンツタイプは任意です。特定されていませんが、システムは添付ファイルのコンテンツタイプを使用します
PUT
  • application/json
  • application/x-www-form-urlencoded
PATCH
  • application/json
  • application/x-www-form-urlencoded
削除
  • application/json
  • application/x-www-form-urlencoded


LINEおよびWhatsAppのメッセンジャー連携では、ユーザーが同じ名前の添付ファイルを複数同時にアップロードすることが可能です。ベストプラクティスとして、ユーザーは一意の名前を付けて、ファイルを1つずつアップロードすることをお勧めします。


取得対象のURL

取得するWebコンテンツのHTTP/HTTPS URLです。クエリ文字列のパラメータは別途指定します。

追加ヘッダー

リクエストに追加する HTTP ヘッダー(例:認証目的など)。関数は、値として挿入することで使用できます。「追加」をクリックしてヘッダーを定義し、名前と値を入力してください。

たとえば、決済ゲートウェイには、「Authorization」ヘッダーと、時刻、ユーザー名、パスワードの SHA-256 ハッシュ経由で認証を必須とする RESTful インターフェースがある場合があります。 認証を有効にするには、名前を Authorization、値を bearer $(accessid) のような形式でリクエストヘッダーに指定します。ここで、「accessid」には =hmac('SHA-256', '<KEY>', '<ユーザー>:<SECRET>')のような値に設定されます。

OAuth 2.0 エンドポイントでの認証も、通常は同様のパターンに従います。 アクセストークンを取得したら(例:別の Fetch URL ブロックがトークンエンドポイントをコールし、その結果を accessToken に保存するなど)、そのトークンを値 bearer $(accessToken) として Authorization ヘッダーに指定できます。

ワークフロービルダーの関数に関する詳細については、 組み込み関数.


URL パラメータ

ここに URL パラメータを指定してください。これらは URL エンコードされ、リクエスト URL に追加されます。ワークフロー変数は、$(varname) の形式で挿入することで使用できます。「追加」をクリックして URL パラメータを定義し、名前と値を入力してください。

コンテンツタイプ

リクエストでサポートされるデータのタイプです。

コンテンツタイプのドロップダウンには、一般的な候補が表示されます。ドロップダウンボックスの候補の代わりに、カスタムコンテンツタイプを手動で入力することも可能です。

コンテンツタイプ リクエストタイプ(HTTPメソッド) メモ
application/json GET、POST、PUT、PATCH、削除
application/x-www-form-urlencoded GET、POST、PUT、PATCH、削除
application/soap+xml GET、POST
multipart/form-data POST 複数の添付ファイルまたはテキストパーツの追加が可能です
単一ファイルのアップロード、コンテンツタイプは以下に設定されています POST コンテンツタイプは任意です。特定されていません。この場合、システムは添付ファイルのコンテンツタイプを使用します。

本文

本文とは、リクエスト本文として送信されるデータのことです。この設定は、リクエストタイプとして「POST」が選択されている場合にのみ表示されます。データのフォーマットは、上記のコンテンツタイプと一致している必要があります。ワークフロー変数の置換は可能です。

認証

以下を選択してください Webクライアント認証情報 アカウント、または設定済みのCRM連携アカウント(Salesforce, ServiceNow, MS Dynamics、または Zendesk)のいずれかを使用して認証を行います。

レスポンス本文のコンテンツは

レスポンス本文の期待されるフォーマットで、テキスト、XML、JSONのオプションがあります。

結果のJSON内の初期パス

レスポンス本文に JSON が含まれている場合、この設定を使用して、データの一部をワークフロー変数に保存することができます。例:myobject.node.list[4]。既定値は「なし」です。

パスは、返された JSON のルートから始まります。

JSON データのシナリオ変数プレフィックス

この文字列は、解析されたJSONデータを受け取る変数の名前として使用されます。なお、上記の初期パスが配列を指している場合、「GetNextブロックを使用してデータをループ処理する」オプションの値に応じて、この変数には配列全体、またはその最初のエレメント(およびそれ以降のエレメント)が含まれることになります。詳しくは 「レスポンスデータの処理」 」を参照してください。

リクエストタイムアウト

ブロックが応答を待ち、その後 タイムアウト 条件付き終了を行うまでの待機時間(秒単位)です。

「GetNext」ブロックを使用してデータをループ処理する

(初期パスにある)JSON レスポンスデータが配列である場合は、このチェックボックスを選択してください。シナリオ変数は配列の最初のエレメントに設定され、 Get 次へ ブロックを使用して配列のエレメントを順に処理し、変数を次のエレメントに設定することができます。


このオプションを有効にすると、「Fetch URL」ブロックの動作は、Bright Pattern Contact Center バージョン 3.13 以前と同じになります。


変数の抽出

「レスポンス本文のコンテンツ」の設定が XML レスポンスを示している場合、「変数の抽出」の内容によって、レスポンスからどの特定のデータをシナリオ変数に解析して割り当てるかが決まります。変数名が関連付けられた XPath 式は、いくつでも定義できます。

各XPath式はXMLレスポンスの解析に使用され、その結果は対応する変数に保存されます。式が複数の値や子ノードを持つノードを指している場合、「GetNextブロックを使用してデータをループ処理する」オプションによって、変数に値の配列が含まれるか、最初の値のみが含まれるかが決定されます。詳しくは 「レスポンスデータの処理」 を参照してください。

レスポンスデータの処理

レスポンスデータのサイズは、コンテンツタイプを問わず 100 KB に制限されています。

レスポンスデータが JSON または XML としてエンコードされていない場合は、シナリオ変数 $(integrationResultBody) 経由でアクセスできます。 HTML レスポンスコード で説明されているシナリオ変数 $(integrationResultBody) を通じて、文字列としてアクセスできます。

JSON エンコードされたレスポンス

レスポンスデータが JSON の場合、以下の処理が行われます。

  1. データが解析されます。
  2. 「GetNext」オプションが有効になっており、初期パスが指している項目が通常の(非連想)配列である場合:
    1. ワークフロー変数には、配列の最初の項目が設定されます。
    2. 「GetNext」ブロックを使用することで、変数を次の項目やそれ以降の項目に初期化することができます。
  3. それ以外の場合は、ワークフロー変数は、初期パスが指している項目に設定されます。


初期パスの設定およびワークフロー変数に保存されたデータへのアクセスに関する構文:

  • item.Subitem
  • item[index]
  • item[attr1=値].attr2
  • 組み合わせ(例:item.subitem.array[index].値. Array[attr=x].値)

XML エンコードされたレスポンス

応答データが XML フォーマットの場合(かつ「応答本文のコンテンツ」が XML であることを示している場合)、「変数の抽出」で定義された各 XPath 式が、応答を解析し、関連する変数の値を次のように設定するために使用されます:

  • XPath が特定の値を指している場合:その値が <VARIABLENAME> に割り当てられます
  • XPathが子要素を持つXMLノードを指している場合:
    • ノードの各属性について、変数 <VARIABLENAME>.<ATTRIBUTENAME> にその属性の値が割り当てられます
    • 各子ノードについて、そのノードの値が <VARIABLENAME>.<CHILDNODENAME> に割り当てられます これは再帰的に適用されます。子ノードにさらに子ノードがある場合、その値は <変数名>.<子ノード名>.<子の子> に割り当てられ、以下同様に処理されます。
    • 属性と子ノードの間で名前が重複している場合、子ノードの値が割り当てられ、属性の値は無視されます。
  • XPathがレスポンスXML内のどのエレメントも指していない場合、対応する変数には空の文字列が割り当てられます。
  • XPath式が配列を指している場合:
    • GetNextブロックを使用してデータをループ処理する」が有効になっている場合、変数には最初に、XPath式で指定された配列の最初のエレメントが割り当てられます。 「次へ」 ブロックを使用して、残りの値を順次処理することができます。
    • 「GetNextブロックを使用してデータをループ処理する」が無効になっている場合、変数には配列の全値が割り当てられ、シナリオ内の他の場所で $(<変数名>[インデックス]) を使用して参照することができます。

HTTP レスポンスコード

受信したHTTPレスポンスのステータスコードと本文は、それぞれローカル変数 $(integrationResultCode) および $(integrationResultBody) に格納されます。

トラブルシューティングでは、使用します。 メール または 内線メッセージ ブロックを使用して、失敗した試行を示すレスポンスのコンテンツを取得することができます。

詳細については、変数 $(integrationResultBody) の説明を参照してください。

下位互換性を確保するため、受信した HTTP レスポンスのステータスコードと本文は、ローカル変数 $(fetchURLResultCode) および $(fetchURLResultBody) にも格納されます。

変数 $(fetchURLResultCode) の取り得る値は以下の通りです:

  • 0: 200 OK レスポンス(つまり、HTTP リクエストが成功したレスポンス)
  • -1: 200 OK レスポンスですが、本文を変数にパースできませんでした(JSON または XML でエンコードされたレスポンス)
  • -2: 200 OK レスポンスですが、本文の長さが 100 KB を超えています
  • -3: HTTP サーバーへの接続に失敗した、またはその他の接続エラーが発生しました
  • -4: PUT または POST リクエストを使用する際、リクエスト本文の JSON 構文が不正です
  • その他: 200 以外の実際のレスポンスコード

HTTPリダイレクト応答の処理

「Fetch URL」ブロックは、3xx ハイパーテキスト転送プロトコル(HTTP)レスポンスコードを以下の方法で処理します。 以下のコードを受信した場合、ブロックは GET リクエストメソッドを使用して、指定されたリダイレクト URL へのリクエストを再試行します:

  • 301 永久移動
  • 302 見つかりました
  • 303 その他(HTTP/1.1 以降)


以下のコードを受信した場合、このブロックは、当初指定されたリクエストメソッドを使用して、指定されたリダイレクト URL へのリクエストを再試行します:

  • 307 一時的なリダイレクト (HTTP/1.1 以降)
  • 308 恒久的なリダイレクト (RFC 7538)


以下のステータスコードを受信した場合、条件付き終了「失敗」が選択されます:

  • 300 複数の選択肢
  • 304 修正なし (RFC 7232)
  • 305 プロキシを使用 (HTTP/1.1 以降)
  • 306 プロキシを切り替え
    < 前へ | 次へ >