コンテンツ・タイプとしてmultipart/form-dataを受け入れる外部REST APIのペイロードを作成するためにマップ

このセクションでは、「RESTアダプタ」またはREST APIを公開する(トリガー接続として使用される)、REST APIを使用する(起動接続として使用される)任意のアプリケーション・アダプタを使用して行われるさまざまなタイプの構成に関するデータ構造について説明します。

カテゴリ

マルチパート・リクエスト(およびレスポンス)には2つのカテゴリがあります:

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

このカテゴリは、添付ファイル・スキーマとペイロード・スキーマを示します。ペイロード・スキーマは、Adapter Endpoint Configuration Wizardの設定時に提供されるサンプルJSON/XMLスキーマに基づいて導出されます。
multipart/form-dataとHTML形式のペイロード

これは、Adapter Endpoint Configuration WizardのRequestページで「マルチパート・リクエストのタイプはmultipart/form-dataで、HTMLフォーム・ペイロードがあります」を選択した場合、またはレスポンス・ページで「マルチパート・リクエストのタイプはmultipart/form-dataで、HTMLフォーム・ペイロードがあります」を選択した場合に使用されます。この構成では、添付ファイル・スキーマとParameterList要素を持つ汎用スキーマを示しています。 ParameterList要素は、無制限の要素パラメータで構成されます。各パラメータには、name属性があります。パラメータの値は、parameter要素に直接設定されます。複数のパラメータがある場合、parameter要素はマッパーで繰り返すことができます。

添付ファイル・スキーマ

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

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

AttachmentProperties要素は、単一の添付ファイルに関するメタデータを提供します。 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を設定するために使用されます。接続されたfile/bodypartは、この名前のターゲット・システムによって保存される必要があります。
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プロパティは、指定された本文部分に説明的な情報を設定するために使用されます。たとえば、「イメージ」本文を「スペース・シャトル・エンデバー号の写真」とマークすると便利です。そのようなテキストは、Content-Descriptionヘッダー・フィールドに置くことができます。
fileInputHtmlFieldNameプロパティを使用すると、サーバーがファイルを読み取る必要があるパーツの名前を設定できます。これは一般に、ファイルをアップロードするHTMLフォームがある場合に使用されます。ファイル・アップロード入力フィールド名は、本文パート名として使用されます。

シナリオ2 - ソースは、JSON/XMLペイロード(カテゴリA)を使用したマルチパート/混合またはマルチパート/フォーム・データです。フォーム・フィールドを持つアウトバウンド・リクエストのマルチパート/フォーム・データ(カテゴリB)

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

ノート:

ソースがマルチパートでなく、ターゲットがフォーム・フィールドを持つmultipart/form-dataでなければならない場合は、ターゲット側のcontentTypeおよびpartName要素の値を指定する必要があります。

fileInputHtmlFieldName要素は、ターゲット・エンドポイントが特定の本文パーツ名で添付ファイルを要求するかどうかを検討する上で重要です。本文部分の名前をここで指定する必要があります。

シナリオ3 - base64でエンコードされたコンテンツから参照を作成

このシナリオでは、ソースはbase64でエンコードされた文字列を持ち、ターゲットは3つの:JSON/XMLペイロードを使用したマルチパート/混合またはマルチパート/フォーム・データ、またはHTMLフォーム・ペイロードを使用したマルチパート/フォーム・データ。

インバウンド・ペイロードでは、content要素はbase64でエンコードされた文字列です。これは、アウトバウンド・リクエストの添付ファイルとして送信できます。 base64文字列は、XSL関数decodeBase64ToReferenceを使用して参照に変換することができ、参照を以下に示すようにattachmentReference要素に割り当てることができます。インバウンド・リクエストはマルチパートではないが、アウトバウンドはマルチパートでなければならないため、マルチパート固有のプロパティをアウトバウンドのマッパーに設定する必要があります。 contentTypeがimage/pngに設定され、partNameがpicture.pngに設定され、fileInputHtmlFieldNameが「イメージ」に設定されています。想定されるのは、ターゲット・システムが、name="image"を持つ本文部分からコンテンツの内容を読み取るように構成されていることです。これはfileInputHtmlFieldName要素で行います。

ノート:

ターゲットがJSON/XMLペイロードを使用してmultipart/mixedまたはmultipart/form-dataである場合、シナリオ1に示すように、ターゲットのスキーマにはJSON/XMLのスキーマもあります。アウトバウンド・リクエスト・ペイロードを構築するアプローチは同じです。