HTTP受付のリクエストラインの処理について説明します。

(a)　コンテキストルート

URLのコンテキストルートは，HTTP受付定義ファイルのurecp-http.context-rootプロパティで指定できます。

urecp-http.context-rootプロパティの指定がない場合，ユーザ定義受付定義画面で設定するHTTP受付の受付IDがコンテキストルートとして使われます。HTTP受付定義ファイルの詳細は，マニュアル「サービスプラットフォーム リファレンス」の「HTTP受付定義ファイル」を参照してください。

HTTPリクエストの送信時，URLは次の形式で指定します。

• http://<ホスト名>:<ポート番号>^※/<コンテキストルート>/<HTTP受付のオペレーション名>
• https://<ホスト名>:<ポート番号>^※/<コンテキストルート>/<HTTP受付のオペレーション名>
  

  注※

  WebサーバのURLです。

URLの指定例を次に示します。

GETメソッドの場合

urecp-http.context-rootプロパティが「Test001」のとき，URLは次の形式で指定します。

http://<ホスト名またはIPアドレス>/Test001/get?type=A&size=7

「get」はオペレーション名，「type=A&size=7」はクエリ文字列を示します。

POSTメソッドの場合

urecp-http.context-rootプロパティが「Test002」のとき，URLは次の形式で指定します。

http://<ホスト名またはIPアドレス>/Test002/post

「post」はオペレーション名を示します。

オペレーション名とは，ユーザ定義受付定義画面で設定するHTTP受付のオペレーションの名称です。オペレーション名はビジネスプロセスを呼び出すときに使用されます。

なお，オペレーション名のあとに「/」が指定された場合，「/」の後ろに文字列があるときは，「/」の後ろの部分もパスとして扱われます。例えば，URLに「http://localhost/contextroot/get/abc123?type=A&size=7」が指定された場合，「/contextroot/get/abc123」がロケーション情報（<location>）にパスとして格納されます。

注意

コンテキストルートは，Component Containerの作業ディレクトリの中でディレクトリ名として使用されます。そのため，作業ディレクトリ全体のパス長がOSの上限に達しないようにコンテキストルートを指定する必要があります。詳細は，「2.13.11　HTTP受付を使用するときの注意」を参照してください。

(b)　ロケーション情報とクエリ文字列部

リクエストラインで指定されたURLは，次の要素に分割して要求電文（ヘッダ）に格納されます。

• ロケーション情報（<location>）^※1
• クエリ文字列部（<query>）^※2

例えば，リクエストラインが「http://localhost/httprecp/get?type=A&size=7」の場合，要求電文には次のように変換されます。

 
<url>
　<location>/httprecp/get</location>
　<query>type=A&amp;size=7</query>
</url>
 

注※1

ロケーション情報とは，コンテキストパスから拡張パスまでのパスです。

注※2

クエリ文字列に複数の「?」が存在する場合，最初の「?」がクエリ文字列の区切り文字として使用されます。

HTTP受付で受け付けられたHTTPヘッダ部分のすべての情報は，any型で定義されたhttp-header要素に格納して，ビジネスプロセスに渡されます。

HTTPヘッダ部分の変換例を次に示します。

• 変換前のHTTPリクエストヘッダ
  

  Accept-Language: ja Host: aaa.bbb.ccc.ddd Connection: Keep-Alive Authorization: Basic aG9nZTpmdWdh

• 変換後の要求電文（ヘッダ）
  

  <http-header> <content-type>application/x-www-form-urlencoded; charset=utf-8</content-type> <Accept-Language> ja</Accept-Language> <Host> aaa.bbb.ccc.ddd </Host> <Connection> Keep-Alive</Connection> <Authorization> Basic aG9nZTpmdWdh</Authorization> </http-header>

HTTP受付で変換されたHTTPヘッダ部分のXML要素は，SOAPアダプタのHTTPヘッダ部とany種別同士でマッピングできます。

(a)　Authorizationヘッダの変換

ユーザの認証情報を格納するHTTPリクエストヘッダのAuthorizationヘッダフィールドは，Base64形式にエンコーディングされます。このため，HTTP受付は，AuthorizationヘッダフィールドをBase64形式からプレーン形式にデコードし，要求電文のXML要素に設定します。

注意事項

• HTTPヘッダ部分にユーザ名とパスワード情報の両方が指定された場合，HTTP受付では，ユーザ名だけが設定されます。
• HTTP受付ではBASIC認証だけをサポートしています。ほかの認証タイプを指定した場合，ユーザ名は設定されません。
• HTTPヘッダ部分のAuthorizationヘッダフィールドを指定して値を指定しなかった場合，要求電文としてAuthorizationの空要素だけ生成され，auth要素およびusername要素は作成されません。
• HTTPヘッダ部分のAuthorizationヘッダフィールドでパスワードを指定してユーザ名を指定しなかった場合，auth要素およびusername要素が作成されますが，username要素の値は空となります。

(b)　Content-Typeヘッダの変換

受信したContent-Typeヘッダの値のメディアタイプをcontent-type要素として要求電文（ヘッダ）に格納します。このとき，charset属性がある場合は，content-type要素のcharset属性として格納します。

Content-Typeヘッダがない場合は，content-type要素は生成しません。また，Content-Typeヘッダのメディアタイプの指定だけがあって，charset属性がない場合は，属性を生成しません。

Content-Typeヘッダのcharset属性は，クエリまたはフォームデータのテキストデータの文字コードとして使用します。Content-Typeヘッダのcharset属性が存在しない場合，またはContent-Typeヘッダがリクエストに存在しない場合は，HTTP受付定義ファイルのhttprecp.http.charsetプロパティの値によって処理されます。ただし，この場合も，charset属性がないため，content-type要素のcharset属性を生成しません。

注意事項

Content-Typeヘッダのcontent-type要素が存在しない，またはcontent-type要素のcharset属性が生成されていないデータを受信した場合に，テキストデータの文字コードを確認する必要があるときは，httprecp.http.charsetプロパティ値の文字コードで判断してください。

HTTPリクエストのパート区分およびデータ形式は，HTTPリクエストヘッダの指定に応じて次のようにHTTP受付で処理されます。

• HTTPリクエストのパート区分
  HTTPリクエストヘッダのContent-Typeヘッダがmultipart/form-dataの場合は，マルチパート型として扱われます。それ以外の場合は単一パート型（テキストデータまたはバイナリデータ）として扱われます。なお，HTTP受付で処理できるマルチパート型の上限数は1,024です。
  
• HTTPリクエストのデータ形式
  各パート内のContent-Dispositionヘッダのfilename属性が存在する場合はファイルのデータがアップロードされたものとして扱います。filename属性がない場合はテキストデータまたはバイナリデータとして扱います。
  

HTTP受付で扱うデータ形式ごとに，HTTPリクエストボディの処理について説明します。

(a)　テキストデータとして扱う場合

HTTP受付は，クエリ，フォームデータ，マルチパート型の形式でContent-Dispositionヘッダのfilename属性がないパート部分をテキストデータとして扱います。テキストデータとして扱う場合，XML形式の要求電文（ボディ）に格納されたあと，ボディ変数としてビジネスプロセスに渡されます。

HTTPリクエストのデータ形式がテキストデータだけの場合は，メッセージボディをビジネスプロセスに渡すときのモードとして，次のどちらかを選択できます。

標準モード

標準モードでは，メッセージボディは要求電文の要素に変換されてビジネスプロセスに渡されます。メッセージボディを格納するXML形式の要求電文フォーマット（ボディ変数用（詳細））は任意にカスタマイズできます。

パススルーモード

パススルーモードでは，メッセージボディ中でmsgキーに対応する値がそのままビジネスプロセスに渡されます。XML形式の要求電文フォーマットはメッセージボディの形式に応じてユーザが作成する必要があります。

パススルーモードは，ビジネスプロセスをテストする場合，SOAP受付のダミーとしてHTTP受付を使用するときなどに使用します。

なお，HTTPリクエストがマルチパート型の場合，パススルーモードを指定しても無効になります。

メッセージボディをビジネスプロセスに渡すときのモードは，HTTP受付定義ファイルのhttprecp.switchover.pass-through.modeプロパティで選択できます。HTTP受付定義ファイルの詳細は，マニュアル「サービスプラットフォーム リファレンス」の「HTTP受付定義ファイル」を参照してください。

標準モードとパススルーモードの変換例を次の表に示します。

表2-29　標準モードとパススルーモードの変換例

注※

HTTP受付定義ファイルのhttprecp.pass-through.parameter-useプロパティで，msgキーの指定を省略するかどうかを設定できます。

msgキーを複数指定した場合の動作は保証されません。

標準モードの場合，HTTPリクエストは要求電文の変換時にHTTP受付でサニタイズされてビジネスプロセスに渡されます。

パススルーモードの場合，HTTPリクエストはサニタイズされません。このため，あらかじめユーザ自身でサニタイズする必要があります。

(b)　ファイルのデータとして扱う場合

HTTPリクエストのパート区分がマルチパート型で，かつパート内のContent-Dispositionヘッダのfilename属性が存在するパートのデータは，HTTP受付で各パートに分割され，パートごとに中間ファイルとして作業フォルダに格納されます。

なお，ファイルのデータとして処理した場合，各パートのヘッダ情報は，次の表に示すように要求電文（ヘッダ）のfile要素にファイルのメタ情報として格納されます。

表2-30　要求電文（ヘッダ）に格納される各パートのヘッダ情報

（凡例）

−：該当する項目はありません。

注※1

Content-Dispositionヘッダにsize属性，modification-date属性など，表2-30に示した属性以外の属性が指定されている場合，それらの属性値は無視されます。

注※2

マルチパート型としてファイルのデータをアップロードする場合，Content-Dispositionヘッダには必ずform-dataを指定してください。form-data以外の場合，HTTP受付では処理の対象となりません。

注※3

name属性を省略した場合，省略したパートのデータは，HTTP受付では処理の対象となりません。

注意

• Content-Dispositionヘッダのname属性およびfilename属性にマルチバイト文字を使用した場合，動作を保証しません。
• Content-Dispositionヘッダの属性に「filename」で始まる任意の属性を指定した場合，およびfilename属性の値に「"」が含まれるファイル名（パス部分は除く）を指定した場合は，動作を保証しません。

なお，複数のファイルのデータをアップロードする場合，これらのメタ情報はファイルごとに要求電文のfile要素に繰り返して格納されます。

(c)　バイナリデータとして扱う場合

HTTPリクエストボディにバイナリデータを設定することで，バイナリ形式の要求電文をビジネスプロセスに送信できます。CSV形式のデータをビジネスプロセスで処理したい場合などに活用できます。

HTTP受付でバイナリデータとして扱うには，次の条件をすべて満たす必要があります。

• パススルーモードを使用していること（HTTP受付定義ファイルにhttprecp.switchover.pass-through.mode=trueを指定していること）
• パススルーモードでmsgキーを省略する設定にしていること（HTTP受付定義ファイルにhttprecp.pass-through.parameter-use=falseを指定していること）
• HTTP受付の要求電文の電文フォーマットにバイナリ形式（拡張子：fdx），または任意形式（any形式）を指定していること
• HTTPリクエストボディのパート区分が単一パートであること

バイナリ形式の要求電文の文字エンコーディングは，ビジネスプロセスのデータ変換時に行われます。