Hitachi

Cosminexus V11 BPM/ESB基盤 サービスプラットフォーム 解説

2.13.4　HTTP受付のリクエスト処理

ここでは，HTTP受付を実行するときにHTTPリクエストがどのように処理されるかについて説明しています。

HTTPクライアントが送信するHTTPリクエストは，次のように分割してHTTP受付内で処理されます。

リクエストライン

HTTPリクエストメッセージの先頭行に位置し，HTTPメソッド，リクエストURL，およびHTTPバージョンが格納されます。

HTTPリクエストヘッダ

HTTPクライアントで受信する言語，認証情報などの情報がHTTPヘッダフィールドで指定されます。

HTTPリクエストボディ

POSTメソッドの場合に送信するメッセージボディが格納されます。

HTTP受付では，電文フォーマットと定義ファイルを使用してHTTPリクエストのリクエストライン，HTTPリクエストヘッダ，およびHTTPリクエストボディを処理できます。

なお，ここで説明する電文の例では，名前空間接頭辞を省略しています。

〈この項の構成〉

(1)　リクエストラインの処理

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

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

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

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

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

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

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

    注※

    WebサーバのURLです。

ただし，ユーザ定義受付（呼出先選択）として定義したHTTP受付の場合は，オペレーション名はHTTPメソッドから取得するため，コンテキストルートのあとに指定する必要はありません。

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受付の場合

ユーザ定義受付（呼出先選択）として定義したHTTP受付で，HTTP受付定義ファイルのコンテキストルートに「Test001」を指定したとき，URLは次の形式で指定します。

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

「Test001」はコンテキストルート，「type=A&size=7」はクエリ文字列を示します。

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

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

注意事項

コンテキストルートは，Component Containerの作業ディレクトリの中でディレクトリ名として使用されます。そのため，作業ディレクトリ全体のパス長がOSの上限に達しないようにコンテキストルートを指定する必要があります。詳細は，「2.13.13　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

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

ユーザ定義受付（呼出先選択）として定義したHTTP受付の場合，コンテキストルートのあとの「/」に続く文字は，URLの分析中に無視されますが，<location>タグに格納されます。

注※2

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

ページの先頭へ

(2)　HTTPリクエストヘッダの処理

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

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

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

(a)　Authorizationヘッダの変換

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

注意事項

  • HTTPヘッダ部分にユーザ名とパスワード情報の両方が指定された場合，HTTP受付では，ユーザ名だけが設定されます。

  • HTTP受付ではベーシック認証だけをサポートしています。ほかの認証タイプを指定した場合，ユーザ名は設定されません。

  • 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プロパティ値の文字コードで判断してください。

ページの先頭へ

(3)　HTTPリクエストボディの処理

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

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

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

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

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

標準モード

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

パススルーモード

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

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

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

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

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

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

モード

説明

HTTPリクエスト（メッセージボディ）

変換後の要求電文（ボディ）

標準モード

メッセージボディは「キー名=値」から「<キー名>値</キー名>」の形式に変換されます。※1

product1=uCSP&product2=HiRDB%20Single%20Server

<HTTPBody>

<product1>uCSP</product1>

<product2>HiRDB Single Server</product2>

</HTTPBody>

パススルーモード

メッセージボディ部分は「msg（固定）=値」形式で指定します。※2

値部分は，メッセージボディのままXML形式の要求電文（ボディ）に設定されます。

msg=%3cHTTPBody%3e%3cproduct1%3euCSP%3c%2fproduct1%3e%3cproduct2%3eHiRDB%20Single%20Server%3c%2fproduct2%3e%3c%2fHTTPBody%3e

<HTTPBody>

<product1>uCSP</product1>

<product2>HiRDB Single Server</product2>

</HTTPBody>
注※1

値が半角スペース1文字だけの場合，空文字として処理します。

注※2

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

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

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

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

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

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

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

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

HTTPリクエストのヘッダ

ヘッダの属性

任意/必須

説明

Content-Type

−

任意

各パートに指定されているファイルのメディアタイプです。

このヘッダは省略できます。

char-set

任意

各パートに指定されているファイルの文字コードです。

この属性は省略できます。

Content-Disposition※1

−

必須

Dispositionタイプを示すヘッダです。

必ず「form-data」を指定します。※2

name

必須

各パートの名称を示す属性です。

この属性は必ず指定します。※3

filename

任意

アップロードするファイルのデータのファイル名を示す属性です。

この属性は省略できます。この属性を省略した場合，テキストデータ扱いになります。
（凡例）

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

注※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リクエストボディのパート区分が単一パートであること

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

ページの先頭へ

商品名称に関する表示

All Rights Reserved. Copyright (C) 2020, 2021, Hitachi, Ltd.