HTTPレスポンスのステータスラインの要素は次のように応答電文に格納されます。

表2-53　ステータスラインと応答電文の対応

ステータスラインの要素	応答電文との対応
HTTPバージョン	応答電文には格納されません。
ステータスコード	応答電文（ヘッダ）のstatus-code要素に格納されます。※
理由フレーズ	応答電文（ヘッダ）のreason-phrase要素に格納されます。

注※

200以外のステータスコードはデフォルトでシステム例外となります。ただし，200以外も正常処理，またはフォルト応答としてフォルトを返すように設定することもできます。詳細は，「(4)　ステータスコードの正常処理またはフォルト処理の設定」を参照してください。

HTTPアダプタで受信したすべてのHTTPヘッダは応答電文（ヘッダ）のhttp-header要素に格納されます。同一名称のHTTPヘッダを重複して受信した場合はそのまま複数の要素として格納されます。

HTTPレスポンスヘッダの例と対応する応答電文（ヘッダ）を次に示します。

• HTTPレスポンスヘッダの例
  

  Content-Length: 51 Content-Type: image/gif Last-Modified: Fri, 21 Jul 2006 07:51:32 GMT Accept-Ranges: bytes Server: Microsoft-IIS/6.0 Date: Mon, 16 Jul 2012 09:43:57 GMT

• 対応する応答電文（ヘッダ）
  

  <http-header-response> <http-header> <Content-Length>51</Content-Length> <Content-Type>image/gif</Content-Type> <Last-Modified>Fri, 21 Jul 2006 07:51:32 GMT</Last-Modified> <Accept-Ranges>bytes</Accept-Ranges> <Server>Microsoft-IIS/6.0</Server> <Date>Mon, 16 Jul 2012 09:43:57 GMT</Date> </http-header> </http-header-response>

　

注意

HTTPヘッダの出現順がそのままXML要素の出現順になるとは限りません。なお，受信したHTTPヘッダのヘッダフィールド名にNCNameとして不正な文字が使用されていた場合，警告メッセージが出力され，該当するヘッダフィールドをスキップして処理が続行されます。

HTTPレスポンスヘッダのContent-TypeヘッダとContent-Dispositionヘッダは応答電文（ヘッダ）の次の要素にも格納されます。

表2-54　Content-TypeヘッダおよびContent-Dispositionヘッダと応答電文（ヘッダ）の対応

HTTPレスポンスヘッダ	属性	応答電文（ヘッダ）に格納される要素
Content-Type	−	http-header-Content-Type要素にContent-Typeヘッダフィールドのメディアタイプ部分(*/*)が格納されます。
	charset	http-header-Content-Type要素のcharset属性に属性値が格納されます。charset属性の指定がない場合は格納されません。
Content-Disposition	−	HTTPレスポンスで指定があった場合，HTTPレスポンスはファイルデータとして扱われます。Dispositionタイプの値は無視されます。
	filename	file要素の子要素のfilename要素として値が格納されます。指定値はデコードなどの変換は行われません。

（凡例）

−：該当しません。

応答電文（ヘッダ）に格納される要素は次に示す値だけです。これ以外の値はすべて無視されます。

• Content-Typeヘッダのメディアタイプ
• Content-Typeヘッダのcharset属性
• Content-Dispositionヘッダのfilename属性

　

注意

応答電文（ヘッダ）を省略した場合，HTTPレスポンスから応答電文（ヘッダ）に格納された要素はビジネスプロセスで使用できなくなります。

HTTPレスポンスボディは，HTTPレスポンスヘッダにContent-Dispositionヘッダが指定されているかどうかによって次のように扱われます。

• ファイルデータ
  HTTPレスポンスヘッダにContent-Dispositionヘッダが指定されている場合，HTTPレスポンスボディに指定された任意のデータがファイルに出力されます。出力ファイルのメタ情報は応答電文（ヘッダ）に格納されます。
  
• ローデータ（パススルーモード）
  HTTPレスポンスヘッダにContent-Dispositionヘッダが指定されていない場合，HTTPレスポンスボディに指定された任意のデータがそのまま応答電文（ボディ）に格納されます。応答電文（ボディ）の電文フォーマットはユーザが作成します。
  

(a)　ファイルデータ

ファイルデータを受信する場合，出力先のディレクトリを要求電文（ヘッダ），HTTPアダプタ実行環境プロパティファイル，またはHTTPアダプタ実行環境共通プロパティファイルで指定する必要があります。プロパティファイルで指定する場合は共通フォルダだけ使用できます。

要求電文（ヘッダ），HTTPアダプタ実行環境プロパティファイル，およびHTTPアダプタ実行環境共通プロパティファイルでのファイルデータの指定個所を次に示します。

表2-55　ファイルデータの指定個所

指定方法	指定する要素またはプロパティ	説明
要求電文（ヘッダ）	request-id要素	作業フォルダ用のリクエストIDを設定します。作業フォルダを使用しない場合は省略できます。
	output-folder-name要素のcommon属性	ファイルデータの出力先として共通フォルダまたは作業フォルダのどちらかを指定します。
	output-folder-name要素	ファイルデータを出力する共通フォルダ定義名を指定します。作業フォルダを使用する場合は指定を省略できます。
	output-sub-folder要素	ファイルデータの出力先として共通フォルダのサブフォルダを使用する場合に，共通フォルダルートからサブフォルダまでの相対パスを指定します。
HTTPアダプタ実行環境プロパティファイル，HTTPアダプタ実行環境共通プロパティファイル	adphttp.request.output-folder-nameプロパティ	ファイルデータを出力する共通フォルダ定義名を指定します。
	adphttp.request.output-sub-folderプロパティ	ファイルデータの出力先として共通フォルダのサブフォルダを使用する場合に，共通フォルダルートからサブフォルダまでの相対パスを指定します。

要求電文（ヘッダ），HTTPアダプタ実行環境プロパティファイル，およびHTTPアダプタ実行環境共通プロパティファイルのどれにも出力先ディレクトリの指定がなかった場合はエラーになります。

応答電文（ヘッダ）には，出力先ディレクトリおよび出力ファイル名などの情報が格納されます。

応答電文（ヘッダ）に格納されるファイル情報を次に示します。

表2-56　応答電文（ヘッダ）に格納されるファイル情報

応答電文（ヘッダ）の要素	説明
output-folder-name要素のcommon属性	ファイルデータを出力したフォルダの種類として共通フォルダまたは作業フォルダのどちらかが格納されます。
output-folder-name要素	ファイルデータを出力したフォルダの定義名が格納されます。共通フォルダに出力した場合は共通フォルダ定義名が格納されます。作業フォルダに出力した場合は，常に空（空文字列）になります。
file-name要素	HTTPレスポンスに指定されたContent-Dispositionヘッダのfilename属性の値が格納されます。ただし，HTTPアダプタでデコードなどの処理はしません。filename属性が省略された場合は要素が生成されません。
local-file-name要素	出力先フォルダに保存した中間ファイルの名称が格納されます。

注1

HTTPアダプタが共通フォルダに出力するファイル名称は，システム内で採番した一意のIDを使用したファイル名となります。次の点に注意してください。

• 一意のIDの生成にサーバのタイムスタンプを利用しているため，時刻の戻りが発生しないようにしてください。NTPソフトウェアを使用して時刻補正をする場合は，必ずslewモードを使用するようにしてください。時刻補正をする場合の注意事項については，マニュアル「サービスプラットフォーム システム構築・運用ガイド」の「1.4　運用方針の決定」を参照してください。
• 一意のIDの生成にHCSCサーバ名とクラスタ名を使用しているため，同一の共通フォルダに複数のHCSCサーバからアクセスする場合は，これらの名称の組み合わせが重複しないようにシステムを設計してください。
  HCSCサーバをロードバランスクラスタ構成やHAクラスタ構成にする場合にも，各HCSCサーバのHCSCサーバ名やクラスタ名の組み合わせが重複しないようにする必要があります。
  例：HCSCサーバ1のHCSCサーバ名=HCSC1，クラスタ名=CLS1の場合
  ・HCSCサーバ2のHCSCサーバ名=HCSC1，クラスタ名=CLS1 → 重複あり
  ・HCSCサーバ2のHCSCサーバ名=HCSC2，クラスタ名=CLS1 → 重複なし
  ・HCSCサーバ2のHCSCサーバ名=HCSC1，クラスタ名=CLS2 → 重複なし
  ・HCSCサーバ2のHCSCサーバ名=HCSC2，クラスタ名=CLS2 → 重複なし
  

上記の条件を満たすことができない場合は，作業フォルダだけを使用してください。共通フォルダを使用した場合，ファイル名の重複が発生してファイルが上書きされるおそれがあります。

注2

ファイルデータの出力先に共通フォルダを使用する場合は，HTTPアダプタだけが利用する専用の共通フォルダを必ず使用してください。ほかの用途で使用する共通フォルダと共用しないでください。

　

HTTPアダプタを利用したファイル受信の例を次に示します。

図2-118　HTTPアダプタを利用したファイル受信の例（共通フォルダを使用する場合）

　

次に，共通フォルダのサブフォルダを使用して，HTTPレスポンスでファイルをダウンロードする場合の指定例を示します。

HTTPアダプタ要求電文（ヘッダ）の/http-header-request/output-sub-folder，またはHTTPアダプタ実行環境プロパティファイルのadphttp.request.output-sub-folderに共通フォルダルートからサブフォルダまでの相対パスを指定します。

• 要求電文（ヘッダ）指定例
  

  <http-header-request> ： <output-folder-name common="true">com</output-folder-name> <output-sub-folder>/folder1/folder2</output-sub-folder> ： </http-header-request>

• HTTPアダプタ実行環境（共通）プロパティファイルの指定例
  

  adphttp.request.output-folder-name=com adphttp.request.output-sub-folder=/folder1/folder2

HTTPアダプタ応答電文（ヘッダ）の/http-headerresponse/http-part/files/file/local-file-nameに共通フォルダルートからファイル名までの相対パスが設定されます。

• 応答電文（ヘッダ）の内容
  

  <http-header-response> ： <output-folder-name common="true">com</output-folder-name> ： <file-name>file1.doc</file-name> <local-file-name>folder1/folder2/SRV1CLS1----HCSC1---0000000000001000d6j93dx74g0001</local-file-name> ： </http-header-response>

　

(b)　ローデータ（パススルーモード）

HTTPレスポンスボディのデータをHTTPアダプタの応答電文（ボディ）にそのまま格納する場合，応答電文（ボディ）の電文フォーマットはユーザが任意に作成する必要があります。

必要に応じて，受信したデータをJava呼出アクティビティやコンポーネント共通UOCなどで加工することもできます。

HTTPアダプタでは，HTTPレスポンス時に指定したステータスコードを正常処理またはフォルト処理として扱うように設定することができます。

どのステータスコードを正常処理およびフォルト処理として扱うかはHTTPアダプタ定義ファイルで設定できます。

表2-57　ステータスコードの処理に関する設定

プロパティ名	説明
adphttp.response-code.normal	正常処理として扱うステータスコードを正規表現で指定します。デフォルトは200です。
adphttp.response-code.fault	フォルト処理として扱うステータスコードを正規表現で指定します。デフォルトは空文字列です。

なお，ステータスコードが正規表現に完全一致しない場合は，HTTPレスポンスでステータスコードが返らないため，システム例外として処理されます。

注意

フォルト処理として扱う場合，ビジネスプロセス上でキャッチできますが，再実行ができなくなります。このため，フォルト処理を設定する場合はビジネスプロセスへの影響を考慮してから設定してください。

ステータスコードの処理フローを次の図に示します。

図2-119　ステータスコードの処理フロー

HTTPアダプタでは，非常に大きなサイズのHTTPレスポンスを受信した場合のメモリ不足およびディスクの圧迫を制御するために，HTTPレスポンスボディのサイズ閾値を設定して，受信サイズを制限することができます。

HTTPレスポンスボディのサイズ閾値はHTTPアダプタ定義ファイルで設定できます。設定するプロパティを次に示します。

表2-58　HTTPレスポンスボディのサイズ閾値の設定

項目	プロパティ名
パススルーモードでHTTPレスポンスを応答電文（ボディ）に設定する際に許容するデータの最大サイズ	adphttp.data-size-limit.body-message
HTTPレスポンスをファイルに書き出す際に許容するデータの最大サイズ	adphttp.data-size-limit.file

閾値を設定したあとは，HTTPアダプタでは，次の順序でレスポンスサイズの判定をしています。

1. HTTPヘッダにContent-Lengthヘッダがある場合は，ヘッダフィールド値が閾値を超えていないか判定をします。閾値を超えている場合は，HTTPレスポンスボディを受信しないで，ただちにシステム例外となります。
2. HTTPヘッダにContent-Lengthヘッダがない場合（チャンクエンコーディングされたデータを受信する場合など）は，HTTPレスポンスボディの受信処理をし，閾値を超えた時点で受信処理を打ち切り，システム例外となります。

HTTPアダプタでファイルを受信中に，ネットワーク障害やI/Oエラー，データサイズ制限の超過などが発生した場合，共通フォルダや作業フォルダに不完全な受信ファイルが生成されますが，この不完全な受信ファイルを自動的に削除することができます。

この機能はHTTPアダプタ定義ファイルのadphttp.auto-delete-incomplete-fileプロパティで設定できます。

不完全な受信ファイルの削除に失敗した場合は，メッセージログ（KDEC81403-W）が出力されます。なお，この場合，削除に失敗したファイルは手動で削除する必要があります。削除方法については，マニュアル「サービスプラットフォーム システム構築・運用ガイド」の「5.4.20　作業フォルダを削除する」，および「5.4.22　共通フォルダ内のファイルを削除する」を参照してください。