機械翻訳について

トリガー接続と呼出し接続に対するマルチパート添付ファイル・サポート

「RESTアダプタ」は、トリガー(インバウンド)リクエストと起動(アウトバウンド)リクエストのマルチパート添付をサポートしています。

たとえば、トリガー(インバウンド)の「RESTアダプタ」を含むレビュー書類の添付ファイルを、起動(アウトバウンド) Adobe eSignまたはDocuSignにアウトバウンドして、署名用のダウンストリーム・エンドポイントに配信することができます。

添付ファイルをインバウンドからアウトバウンドに(リクエスト・メッセージで)送信する場合、またはアウトバウンドからインバウンドに(レスポンス・メッセージで)添付ファイルをダウンロードする場合は、各添付ファイルに対して、マッパー内のソースからターゲットにattachmentReferenceをマップする必要があります。
「oic3_attach_ref.pngの説明は以下のとおりです
図oic3_attach_ref.pngの説明」

リクエストのマッパーでattachmentReferenceをマップしないと、アウトバウンド「RESTアダプタ」はインバウンド方向からの添付ファイルをインバウンドしません(マルチパート要求)。 同様に、マッパーでattachmentReferenceをレスポンス用にマップしないと、インバウンド「RESTアダプタ」はアウトバウンド「RESTアダプタ」 (マルチパート・レスポンス)から添付ファイルを受信しません。

「RESTアダプタ」またはREST APIを公開する(トリガーとして使用する)アプリケーションAPIを使用する(REST APIを使用する(起動として使用される))さまざまなタイプの構成のデータ構造を理解します。

マルチパート・リクエストとレスポンスには2つの構成カテゴリがあります:

  • A - JSONサンプルまたはXMLサンプルで構成されたマルチパート/混合またはマルチパート/フォーム・データ

    この構成では、添付ファイル・スキーマとペイロード・スキーマが使用されます。 ペイロード・スキーマは、Adapter Endpoint Configuration Wizardで設定中に提供されたサンプルJSON/XMLスキーマに基づいて導出されます。

  • B - HTML形式のペイロードを使用したマルチパート/フォーム・データ

    この構成では、添付ファイル・スキーマとParameterList要素を持つ汎用スキーマを使用します。 ParameterList要素は、無制限のparameter要素で構成されています。 各parameterにはname属性があります。 パラメータの値は、parameter要素に直接設定されます。 複数のパラメータがある場合、parameter要素はマッパーで繰り返すことができます。 parameterのデータ型はstringです。

    ノート:

    このカテゴリは、Adapter Endpoint Configuration WizardのRequestページで「リクエストはHTMLフォームです」を選択したときに使用されます。 これは、Adapter Endpoint Configuration WizardのResponseページで「レスポンスはHTML形式です」を選択した場合のレスポンスと同様です。
両方の構成カテゴリについて次の詳細に注意してください:

  • 添付ファイル・スキーマ

    attachments要素には、無制限のattachment要素があります。 この構成では、複数の添付ファイルの受信(送信元での送信)または送信(送信先での送信)がサポートされます。 各attachment要素には、attachmentReferenceおよびattachmentPropertiesがあります。

  • AttachmentReference要素には、アクセスのために添付ファイルがステージングされたロケーションが含まれます。

    AttachmentProperties要素は、単一の添付ファイルに関するメタデータを提供します:

    • contentIdプロパティは、本文部分のContent-IDヘッダーを設定します。 Content-IDヘッダーは本文部分の一意のIDを設定します。

    • contentTypeプロパティは、本文部分のContent-Typeヘッダーを設定します。 たとえば、PDFファイルが送信された場合、contentTypeプロパティはapplication/pdfである必要があります。 ソースがマルチパート添付ファイルを提供している場合、これは自動的に決定されます。 マッパーはこれらの値を設定/上書きできます。

    • transferEncodingプロパティは、本文部分のContent-Transfer-Encodingヘッダーを設定します。 このヘッダーの値は、エンコーディングのタイプを指定する単一のトークンです: 

      Content-Transfer-Encoding := "BASE64" / "QUOTED-PRINTABLE" / 
                             "8BIT"   / "7BIT" / 
                             "BINARY" / x-token

      これらの値では、大/小文字は区別されません。 つまり、Base64、BASE64およびbAsE64はすべて同等です。 7BITのエンコーディング・タイプでは、本文がすでに7ビットのメール可能な表現形式になっている必要があります。 これがデフォルト値です(つまり、Content-Transfer-Encodingヘッダー・フィールドが存在しない場合は、Content-Transfer-Encoding: 7BITが仮定されます)。 https://www.w3.org/Protocols/rfc1341/5_Content-Transfer-Encoding.htmlを参照してください。

    • partNameプロパティは、本文パートのfileNameを設定します。 添付ファイル/本文部分は、ターゲット・システムによってこの名前で保存されます。

    • contentDispositionプロパティは、本文部分のContent-Dispositionヘッダーを設定します。

      マルチパート/フォーム・データ本文では、HTTP Content-Dispositionは、マルチパート本文のサブパート(つまり、添付ファイル)に適用されるフィールドに関する情報を提供するヘッダーです。 Content-Dispositionヘッダー値は通常、form-dataに設定されます。 オプションのディレクティブ名とファイル名も使用できます。 たとえば: 

      Content-Disposition: form-data
Content-Disposition: form-data; name="fieldName"
Content-Disposition: form-data; name="fieldName"; filename="filename.jpg"

    • contentDescriptionプロパティは、特定の本文部分について説明的な情報を設定します。 たとえば、「イメージ」本文をa picture of the Space Shuttle Endeavorとしてマークすることができます。 このようなテキストは、Content-Descriptionヘッダー・フィールドに置くことができます。

    • fileInputHtmlFieldNameプロパティは、サーバーがファイルを読み取る必要がある部分の名前を設定します。

Mapper構成シナリオ:

  • ソースとターゲットの両方に、JSON/XMLペイロード(カテゴリA)のマルチパート・リクエストがあります

    次のサンプル・マップは、attachmentReferenceのターゲットへのマッピングにのみ焦点を当てています。 このシナリオでは、ソースからの添付ファイルが1つだけターゲットにマップされているという前提があります。 ソースとターゲットとの間のペイロード(リクエスト・ラッパー・ノード)のマッピングは示されていません。 そのタスクを実行する必要があります。


    rest_multipart_1.pngの説明は以下のとおりです
    「図rest_multipart_1.pngの説明」

  • ソースは、JSON/XMLペイロード(カテゴリA)でmultipart/mixedまたはmultipart/form-dataです。 ターゲットは、フォーム・フィールド(カテゴリB)を持つマルチパート/フォーム・データです

    次のマップは、HTMLフォーム上の属性のマッピングに焦点を当てています。 parameterListには、HTMLフォームのフィールドと同じ数のパラメータが必要です。


    rest_multipart_2.pngの説明は以下のとおりです
    「図rest_multipart_2.pngの説明」

  • base64でエンコードされたコンテンツから参照を作成します。 ソースはbase64でエンコードされた文字列を持ち、ターゲットは3つの: JSON/XMLペイロードによるマルチパート/混合、マルチパート/フォーム・データ、またはHTMLフォーム・ペイロードによるマルチパート/フォーム・データ。

    インバウンド・ペイロードでは、content要素はbase64でエンコードされた文字列です。 これは、アウトバウンド・リクエストの添付ファイルとして送信できます。

    インバウンド・リクエストはマルチパートではないが、アウトバウンドはマルチパートでなければならないため、アウトバウンド方向のマッパーでマルチパート固有のプロパティを設定する必要があります。 contentTypeは、ここでimage/pngに設定され、partNameはpicture.pngに設定され、fileInputHtmlFieldNameは「イメージ」に設定されます。 ターゲット・システムが、コンテンツの処理においてname="image"を持つ本文部分から読み取るように構成されていると仮定します。 これは、要素fileInputHtmlFieldNameを使用して行います。
    rest_multipart_3.pngの説明は以下のとおりです
    「図rest_multipart_3.pngの説明」

    base64文字列は、XSL関数decodeBase64ToReferenceを使用して参照に変換でき、参照をattachmentReference要素に割り当てることができます。

    rest_multipart_4.pngの説明は以下のとおりです
    図rest_multipart_4.pngの説明

  • インバウンドはFTPファイルの読み取り操作(非マルチパート)で、アウトバウンドはJSONまたはXMLペイロードとのマルチパート/混合です。


    rest_multipart_5.pngの説明は以下のとおりです
    「図rest_multipart_5.pngの説明」

ノート:

  • ソースがマルチパートではないがターゲットがマルチパートでなければならない場合は、マッパーを使用してターゲットに対してcontentTypeとpartNameを指定する必要があります。

  • レスポンス・マッパーの説明は、リクエスト・マッパーに似ています。

いくつかの実装パターンが用意されています。 「RESTアダプタを使用した共通パターンの実装」を参照してください。