2.15.15　HTTP受付を使用するときの注意

• HTTPレスポンスヘッダを応答電文（ヘッダ）のhttp-header要素で設定する場合は，有効なHTTPヘッダを設定してください。HTTP受付はHTTPヘッダが妥当かどうかを検証しません。

• HTTP受付では，HTTPのセッション管理をサポートしていません。

• HTTPリクエストにテキストデータが存在しない場合でも，受付アクティビティに設定する要求電文（ボディ）を設定してください。

• HTTPレスポンスでテキストデータを返さない場合でも，応答アクティビティに設定する要求電文（ボディ）を設定してください。設定するスキーマは製品が提供するスキーマを使用してください。

• HTTPリクエストボディをビジネスプロセスに渡すときのモードにパススルーモードを使用し，かつHTTP受付定義ファイルにhttprecp.pass-through.parameter-use=trueを指定している場合は，次の注意事項があります。また，httprecp.telegram-auto-convert=trueを指定している場合でcontent-type HTTPヘッダがapplication/xml，またはapplication/jsonのときも同様です。

  • 「msg=値」のペアは1つだけ指定してください。複数の「msg=値」のペアが指定された場合，動作を保証しません。また，msgキーの指定がない場合はエラーになります。

  • msgキーはすべて小文字で指定してください。大文字を指定した場合はエラーになります。

  • HTTPリクエストボディには有効なXML文字列を指定してください。HTTP受付ではXML文書をチェックしません。

  • 「msg=msg=abc」のように，クエリ文字列またはメッセージボディに複数の「=」が指定された場合，最初の「=」が区切り文字として使用されます。この場合，最初の「=」の前の部分はキーとして読み込まれ，最初の「=」のあとの文字列全体は値として読み込まれます。

• HTTP受付を利用してテキストデータの送受信，およびファイルのデータをアップロードまたはダウンロードする場合，次の制限があります。

  • ビジネスプロセスはHTTP受付に応答を返す必要があります。このため，HTTP受付の通信モデルは非同期にできません。

  • BPELの並行処理（FLOW）は使用できません。

  • HTTP受付に対して1リクエストで同時に処理できるファイル数の上限は1,024個です。

  • 応答電文（ヘッダ）のpartID要素およびfile-name要素にマルチバイト文字を指定した場合，動作を保証しません。

  • HTTPレスポンスでファイルのデータを送信する場合，指定できるファイル数の上限は1,024です。指定したファイル数が1,024を超えた場合は，動作を保証しません。

• HTTP受付を利用してファイルのデータを送受信する場合は，次の点を考慮して，HTTP受付ごとに作業フォルダのディスクサイズを十分に割り当ててください。

  • 同時実行数

    サイズが大きいファイルを扱うHTTPリクエストが一度に大量に送信される可能性がある場合，極端なリソース消費とならないように同時実行数を考慮してください。

  • 想定される最大のHTTPリクエストサイズ

    ファイルのデータの処理時に作成される一時ファイルは，中間ファイルと同じサイズおよび個数生成されます。このため，最大でどの程度のHTTPリクエストが送信されるか事前に見積もっておく必要があります。

  • HTTP受付に関連づいたビジネスプロセスの処理

    HTTP受付から呼び出されたビジネスプロセスで，ファイル操作アダプタを利用して作業フォルダ内にファイルを生成したり，HTTPアダプタなどで取得したファイルを作業フォルダに格納したりする場合は，その処理によって生成されるファイルのサイズも考慮しておく必要があります。また，中間ファイルおよび一時ファイルが削除されるまでの処理時間を考慮してビジネスプロセスを設計してください。

• コンテキストルートは，Component Containerの作業ディレクトリの中でディレクトリ名として使用されます。そのため，作業ディレクトリ全体のパス長がOSの上限に達しないようにコンテキストルートを指定する必要があります。OSのパス長の上限については，使用する各OSのドキュメントを参照してください。

  Component Containerの作業ディレクトリ全体の構成を次に示します。

  Component Containerの作業ディレクトリ全体の構成									備考
  Component Containerの作業ディレクトリまでのパス\									−
  	Component Containerの作業ディレクトリ\								デフォルトのパスは次のとおりです。 Windowsの場合 <サービスプラットフォームのインストールディレクトリ>\CC\server\public UNIXの場合 /opt/Cosminexus/CC/server/public コンテキストルート名にスラッシュ（/）などが指定されている場合，値が3桁の半角文字に置き換えられます。
  		web\							−
  			<J2EEサーバ名>\						−
  				<コンテキストルート名>\					−
  					WEB-INF\				−
  						classes\			−
  							HTTP受付のパッケージ名のディレクトリ階層\		ディレクトリ階層は，jp/co/Hitachi/soft/csc/msg/message/reception/http/implです。
  								HTTP受付のクラスファイル	最も長いファイル名は，"CSCMsgHTTPServletContextListener.class"です。

  （凡例）

  −：該当する説明はありません。

  Component Containerの作業ディレクトリ全体のパス長は，次の見積もり式で算出できます。このパス長がOSの最大パス長を超えないようにコンテキストルートを指定してください。

  Component Containerの作業ディレクトリ全体のパス長=A+2×B+C+D+E+F+25

  A：Component Containerの作業ディレクトリまでのパスの長さ

  B：Component Containerの作業ディレクトリ名の長さ

  C：最も長いJ2EEサーバ名の長さ

  D：コンテキストルートの長さ（「/」などを含む場合は文字×3で換算します）

  E：HTTP受付のパッケージ名のディレクトリ階層の長さ

  F：HTTP受付のクラスファイルのうち，最も長いファイル名の長さ

ページの先頭へ