HTTPInput ノード

このトピックには、以下のセクションが含まれています。

目的

メッセージ・フローによって処理する Web サービス要求を受信するには、HTTPInput ノードを使用します。 HTTPInput ノードを HTTPReply ノードおよび HTTPRequest ノードと共に使用すると、ブローカーは Web サービスの仲介者として機能でき、Web サービス要求を WebSphere Business Integration Message Broker でサポートされる他のメッセージ形式と同じ方法で変換してルーティングできます。

メッセージ・フローに HTTPInput ノードを組み込む場合には、同じフローに HTTPReply ノードも組み込むか、HTTPReply ノードが組み込まれた別のノードにメッセージを受け渡す必要があります (たとえば、MQOutput ノードを介して、MQInput ノードで始まる 2 番目のフローへ)。 後者の場合、クライアントからの要求と、クライアントへの応答は、LocalEnvironment に保管された要求 ID で整合されます (後述)。

HTTPInput ノードは、次のメッセージ・ドメインのメッセージを処理します。

  • MRM
  • XML
  • XMLNS
  • JMS
  • BLOB

HTTPInput ノードは、Web サービス・クライアントからのメッセージを受信すると、適切なパーサーを起動して、メッセージのヘッダーおよび本文を解釈し、メッセージ・フローが内部で使用するメッセージ・ツリーを作成します。 このノードは入力メッセージの固有 ID を作成し、これを LocalEnvironment ツリーの LocalEnvironment.Destination.HTTP.RequestIdentifer に、24 バイトのバイナリー配列の形で保管します。 この値は HTTPReply ノードによって使用されます。この値には、一切変更を加えてはなりません。

HTTP メッセージは常に持続性を持たず、関連する順序はありません。

HTTP メッセージは、非トランザクションです。 ただし、メッセージ・フローがデータベースまたは WebSphere MQ キューなどの他の外部リソースと対話する場合、それらの対話はトランザクションとして実行されます。 HTTPInput ノードでは、メッセージ・フローの終了方法、およびエラー処理に対する構成方法 (たとえば、障害の発生したターミナルを接続する方法) に応じて、コミットまたはロールバックが提供されます。 メッセージ・フローが HTTPInput ノードによってロールバックされる場合、SOAP 障害メッセージが生成され、Web サービス・クライアントに戻されます。

このメッセージ・フローのダウンストリームで例外が発生し、キャッチされずにノードに戻された場合、このノードは呼び出し側クライアントへのエラー応答を構成します。 この応答は、例外そのものから導出された SOAP 障害メッセージです。

HTTPInput ノードで開始するメッセージ・フローに出力ノードを組み込む場合、その出力ノードはサポートされる出力ノードのいずれかにできます (ユーザー定義の出力ノードも含む)。 必要な任意の変換を提供するようにブローカーに要求するようにメッセージ・フローを構成できますので、Web サービス・クライアントからメッセージを受け取る、サポートされるトランスポートすべてを使用してブローカーに接続する クライアント用のメッセージを生成する、メッセージ・フローを作成できます。

サブフローとして使用するメッセージ・フローを作成する場合には、標準入力ノードを使用することはできず、入力ノードのインスタンスを最初のノードとして使用して、サブフロー用の in ターミナルを作成する必要があります。

ご使用のメッセージ・フローが Web サービス要求を受信しない場合には、次の入力ノードのいずれかを選択できます。

  • MQeInput
  • MQInput
  • Real-timeInput
  • SCADAInput
  • ユーザー定義の入力ノード

ワークベンチでは、HTTPInput ノードは次のアイコンで表されます。

HTTPInput ノード・アイコン

メッセージ・フロー内でのこのノードの使用

このノードは、2 つの異なるシナリオで使用できます。

  1. ブローカーは、Web サービスとして動作します。

    Web サービス・クライアントは、Web サービス要求を生成します。 そのサービス要求は、ブローカーで実行されているメッセージ・フローの HTTPInput ノードに送信されます。 メッセージを何らかの方法で処理し、Web サービス応答の形式で応答を生成するようにメッセージ・フローを設計します。 ブローカーは、メッセージ・フローの HTTPReply ノードを経由して応答を Web サービス・クライアントに送信します。

    たとえば、特定の対象 (株価、または為替レートなど) に関する特定の情報を提供する Web サービスと対話する Web サービス・クライアントがあるとします。 このサービスを社内のデータベース・ルックアップ・ソリューションと取り替えますが、クライアント・アプリケーションは変更したくありません。 そこで、クライアントから要求を受信する HTTPInput ノードを組み込んだメッセージ・フローを設計します。 このノードは、データベースから必要な情報を取り出して、Web サービス応答の形式でその新しいデータを含む新規出力メッセージを生成する、Compute ノードに接続します。 Compute ノードは、メッセージを HTTPReply ノードに渡し、HTTPReply ノードは Web サービス・クライアント用の応答を生成します。

  2. ブローカーは、Web サービスへの仲介者として動作します。

    Web サービス・クライアントは、Web サービス要求を生成します。 そのサービス要求は、ブローカーで実行されているメッセージ・フローの HTTPInput ノードに送信されます。 メッセージを何らかの方法で処理し、クライアント・アプリケーションの接続相手の Web サービスと対話するようにメッセージ・フローを設計します。 メッセージ・フローに HTTPRequest ノードを組み込み、要求を Web サービスに送信して、その応答を受信します。 またメッセージ・フローは、HTTPRequest ノードで受信した応答に完全にまたは部分的に基づいて、Web サービス応答の形式でクライアントに対する応答を生成します。 ブローカーは、メッセージ・フローの HTTPReply ノードを経由して応答を Web サービス・クライアントに送信します。

    たとえば、Web サービスと対話するクライアント・アプリケーションがあるとします。 その Web サービスは別の形式の情報を必要とする別のアプリケーションに情報を送信します。 そこで、HTTPInput ノード、HTTPRequest ノード、および HTTPReply ノードが組み込まれた新しいメッセージ・フローを設計します。 HTTPInput ノードは Web サービス・クライアントからの入力を受信し、そのメッセージを Web サービスと対話する HTTPRequest ノードに渡します。

    応答を受信すると、HTTPRequest ノードはメッセージを Compute ノードに伝搬し、Compute ノードは Web サービス応答の内容から出力メッセージをレガシー形式で作成します。 メッセージ・フローは、変換されたメッセージをレガシー・アプリケーションに配送する MQOutput ノードで終了し、その後に、Web サービス・クライアントに適切な応答を提供する HTTPReply ノードが続きます。

    2 番目の例は、クライアントは Web サービスと対話しますが、Web サービスへの要求に関する情報を監査のために保存しておきたい場合です。 Warehouse ノードに接続された HTTPInput ノードを組み込んだメッセージ・フローを設計します。 Web サービス・クライアントから受信した入力メッセージはデータベースに格納され、Warehouse ノードはそのメッセージを Web サービスと対話する HTTPRequest ノードに渡します。 応答が受信されると、HTTPRequest ノードはその応答を、Web サービス・クライアント用の応答を生成する HTTPReply ノードに伝搬します。

HTTPInput ノードの構成

HTTPInput ノードのインスタンスをメッセージ・フローに入れると、HTTPInput ノードを構成することができます。 エディター・ビューでノードを右マウス・ボタンでクリックし、「プロパティー (Properties)」をクリックします。 ノードの基本プロパティーが、プロパティー・ダイアログに表示されます。

値を入力する必要のある (デフォルト値が定義されていない) すべての必須プロパティーには、プロパティー・ダイアログにアスタリスクが表示されます。

以下のように、HTTPInput ノードを構成します。

  1. 「URL セレクター」に、このノードが受信する Web サービス要求の送信元の URL を入力します。
  2. 「最大クライアント待機時間 (Maximum client wait time)」タイムアウト・インターバルを秒数で入力します。 これは、Web サービス・クライアントから入力メッセージを受信した TCP/IP リスナーが、メッセージ・フローで HTTPReply ノードからの応答を待機する時間の長さです。 この時間内に応答を受信した場合、リスナーはその応答をクライアントに伝搬します。 この時間内に応答を受信しなかった場合、リスナーはタイムアウトの期限が切れたことを示す SOAP 障害メッセージをクライアントに送信します。
  3. プロパティー・ダイアログ・ナビゲーターで「デフォルト (Default)」を選択して、着信メッセージの構文解析方法を決定するのにノードが使用するメッセージ・ドメイン、メッセージ・セット、メッセージ・タイプおよびメッセージ形式を記述するプロパティーの値を設定します。
    • 「メッセージ・ドメイン (Message Domain)」フィールドでは、ドロップダウン・リストから使用するパーサーの名前を選択します。以下から選択できます。
      • MRM
      • XML
      • XMLNS
      • JMSMap
      • JMSStream
      • BLOB
    • MRM パーサーを使用する場合は、「メッセージ・セット (Message Set)」フィールドのドロップダウン・リストから、適切なメッセージ・セットを選択します。 このリストには、ドメインとして MRM を選択する場合に選択可能なメッセージ・セットが取り込まれます。

      XML、XMLNS、JMS、および BLOB パーサーの場合、「メッセージ・セット (Message Set)」フィールドはブランクのままにしてください。

    • MRM パーサーを使用する場合は、「メッセージ・タイプ (Message Type)」フィールドのドロップダウン・リストから、適切なメッセージ・タイプを選択します。 このリストには、選択したメッセージ・セットで定義されたメッセージが取り込まれます。

      XML、XMLNS、JMS、および BLOB パーサーの場合、「メッセージ・タイプ (Message Type)」フィールドはブランクのままにしてください。

    • 「メッセージ形式 (Message Format)」フィールドのドロップダウン・リストから、メッセージの形式を選択します。 このリストには、このメッセージ・セット用に定義されたすべての物理形式が含まれます。 物理形式にデフォルト名を使用している場合には、以下の名前がリストに含まれます。
      • CWF1 (デフォルト・カスタム・ワイヤー形式 ID)
      • XML1
      • TDS1
      これらの形式のいずれかに対して別の (デフォルトではない) 名前を指定した場合には、その名前がリストに表示されます。

      XML、XMLNS、JMS、および BLOB パーサーの場合、「メッセージ形式 (Message Format)」フィールドはブランクのままにしてください。

  4. MRM パーサーの場合、メッセージ・セットから生成されたディクショナリーに対してメッセージ本文の妥当性検査を行いたいのであれば、プロパティー・ダイアログ・ナビゲーターの「妥当性検査 (Validation)」を選択します。 (メッセージが障害の発生したターミナルのノードに伝搬される場合には、妥当性検査は行われません。)
    • 「妥当性検査 (Validate)」は、最初は「なし (None)」に設定されています。 内容妥当性検査 (タイプ内容検査およびタイプ構成検査) と値妥当性検査 (値データ・タイプ検査、ヌル許可検査、長さ検査、範囲検査、列挙型検査など) の両方を要求するには、この設定を「内容および値 (Content and Value)」に変更します。
    • 妥当性検査で障害が発生する場合の処理を決定するには、「障害アクション (Failure Action)」の次のオプションのいずれかを選択します。
      • 「ユーザー・トレース (User Trace)」: すべての妥当性検査障害をユーザー・トレースに書き込み、処理を継続します。
      • 「ローカル・エラー・ログ (Local Error Log)」: すべての妥当性検査障害をイベント・ログに書き込み、処理を継続します。
      • 「例外 (Exception)」: 最初の妥当性検査障害で例外をスローします。 これがデフォルトの動作です。
      妥当性検査を最初に起動する場合には、最初の 2 つのオプションが有用です。 最初に発生した妥当性検査障害だけでなく、すべての障害を確認できるからです。 障害を既に分析した場合には、一般にその後の使用に関しては「例外 (Exception)」を選択できます。

      障害宛先は、トレース・ノード出力の障害宛先のように動作します。 したがって、たとえば「ユーザー・トレース (User Trace)」が選択された場合には、メッセージ・フローのユーザー・トレース・フラグの設定にかかわりなく、トレース・エントリーが書き込まれます。

    • 以下の中から、「タイミング (Timing)」の値を設定します。
      • 「据え置き (Deferre)」: 各フィールドを構文解析するときにメッセージを妥当性検査します。 これがデフォルトの動作です。
      • 「即時 (Immediate)」: メッセージが直ちに妥当性を検査されますが、サブセットは未解決のままの状態を許可されます (これにより、エレメントがまだ解決されていない状況で「構成 (Composition)」の値の「選択 (Choice)」および「メッセージ (Message)」がサポートされます)。
      • 「完全 (Complete)」: すべてのメッセージが直ちに妥当性を検査されます。
      このプロパティーで使用可能なオプションはパーサーの部分解析能力を利用して、アクセスするフィールドだけを妥当性検査するか (「据え置き (Deferred)」)、すべてのメッセージの妥当性検査を行うか (「即時 (Immediate)」および「完全 (Complete)」) を選択できます。 前者はパフォーマンスを改善し、後者はセキュリティーを高めます。
    • 「値制約すべてを組み込む (Include All Value Constraints)」チェック・ボックス・プロパティーは選択されており、デフォルト設定から変更できません。 この設定の場合、全データ・タイプ検査および値検査が行われます。
    • 「修正 (Fix)」プロパティーは、デフォルト設定の「なし (None)」から変更することはできません。 「障害アクション (Failure Action)」「例外 (Exception)」に設定されていない場合、妥当性検査障害が発生すると、限定的な修復アクションが行われます。 「障害アクション (Failure Action)」「例外 (Exception)」に設定した場合、修復アクションは行われず、妥当性検査で最初に発生した障害で例外がスローされます。
  5. 簡略説明または詳細説明 (あるいはその両方) を入力するには、プロパティー・ダイアログ・ナビゲーターの「説明 (Description)」を選択します。
  6. 「適用」をクリックすると、プロパティー・ダイアログを閉じずに HTTPInput ノードが変更されます。 「OK」をクリックすると、変更を適用してプロパティー・ダイアログを閉じます。

    「キャンセル (Cancel)」をクリックすると、ダイアログを閉じてプロパティーの変更をすべて破棄します。

ターミナルの接続

HTTPInput は、out ターミナルに正常に取り出される各メッセージをルーティングします。 メッセージの妥当性検査が失敗すると、メッセージは failure ターミナルにルーティングされます。 ノードをこのターミナルに接続し、この状態を処理することができます。 failure ターミナルに接続していない場合、メッセージは破棄され、「最大クライアント待機時間 (Maximum client wait time)」が満了して、TCP/IP リスナーはエラーをクライアントに戻します。 他のいかなる状況にあっても、メッセージが failure ターミナルにルーティングされることはありません。

メッセージ・フロー内でさらに例外が出された後、このノードによってメッセージがキャッチされる場合、メッセージは catch ターミナルにルーティングされます。 catch ターミナルに接続していない場合、メッセージは破棄され、「最大クライアント待機時間 (Maximum client wait time)」が満了して、TCP/IP リスナーはエラーをクライアントに戻します。

ターミナルおよびプロパティー

HTTPInput ノード・ターミナルについては、次の表に説明されています。

ターミナル 説明
Failure エラーが発生した場合にメッセージがルーティングされる出力ターミナル。
Out 正常に取り出された場合に、メッセージがルーティングされる出力ターミナル。
Catch 例外がダウンストリームで発生し、ノードによってキャッチされた場合に、メッセージがルーティングされる出力ターミナル。

以下の表でノードのプロパティーを説明します。M の見出しの列は、プロパティーが必須 かどうかを示します (デフォルトが定義されていない場合に値を入力することが必要なら、プロパティー・ダイアログにアスタリスクのマークが付きます)。 C の見出しの列は、プロパティーが構成可能 かどうかを示します (メッセージ・フローを bar ファイルに追加してデプロイするとき、値を変更できます)。

HTTPInput ノードの「基本 (Basic)」プロパティーについては、次の表に説明されています。

プロパティー M C デフォルト 説明
URL セレクター はい はい   Web サービス要求が取り出される位置。 これは、以下のいずれかの方法で提供する必要があります。
http://<hostname>[:<port>]/[<path>]
または
/<path fragment>/*
(* は、あらゆるものと一致することを示すために使用できるワイルドカード)
最大クライアント待機時間 (Maximum client wait time) はい いいえ 180 リスナーがエラー・メッセージをクライアントに戻すまでに待機する時間 (秒単位)。 有効範囲は、0 (無期限待機を表す) から (231)-1 です。

HTTPInput ノードの「デフォルト (Default)」プロパティーについては、次の表に説明されています。

プロパティー M C デフォルト 説明
メッセージ・ドメイン (Message Domain) いいえ いいえ   着信メッセージのドメイン。
メッセージ・セット (Message Set) いいえ いいえ   着信メッセージのメッセージ・セット。
メッセージ・タイプ (Message Type) いいえ いいえ   着信メッセージのタイプ。
メッセージ形式 (Message Format) いいえ いいえ   着信メッセージの形式。

HTTPInput ノードの「妥当性検査 (Validation)」プロパティーについては、次の表に説明されています。

プロパティー M C デフォルト 説明
妥当性検査 (Validate) はい いいえ 「なし (None)」 妥当性検査が行われるかどうか。 有効な値は、「なし (None)」および「内容および値 (Content and Value)」です。
障害アクション (Failure Action) はい いいえ ユーザー・トレース (User Trace) 妥当性検査に障害が発生した場合の動作。 「妥当性検査 (Validate)」「内容および値 (Content and Value)」に設定した場合にのみ、このプロパティーを設定できます。 有効な値は、「ユーザー・トレース (User Trace)」「ローカル・エラー・ログ (Local Error Log)」および「例外 (Exception)」です。
タイミング (Timing) はい いいえ 据え置き (Deferred) 妥当性検査が行われるとき。「妥当性検査 (Validate)」「内容および値 (Content and Value)」に設定した場合にのみ、このプロパティーを設定できます。 有効な値は、「据え置き (Deferred)」「即時 (Immediate)」および「完全 (Complete)」です。
値制約すべてを組み込む (Include All Value Constraints) はい いいえ 選択されている このプロパティーは変更できません。
修正 (Fix) はい いいえ 「なし (None)」 このプロパティーは変更できません。

HTTPInput ノードの「説明 (Description)」プロパティーについては、次の表に説明されています。

プロパティー M C デフォルト 説明
簡略説明 (Short Description) いいえ いいえ   ノードの簡単な説明
詳細説明 (Long Description) いいえ いいえ   メッセージ・フロー内のノードの目的を説明するテキスト

関連概念
WebSphere MQ Web Services Transport
メッセージ・フロー
ユーザー定義拡張機能

関連タスク
使用するノードの決定
複数の入力ノードの使用
メッセージ・フローのエラー処理
構成可能プロパティーの編集

関連資料
Compute ノード
HTTPReply ノード
HTTPRequest ノード
Input ノード
MQeInput ノード
MQInput ノード
MQOutput ノード
Real-timeInput ノード
SCADAInput ノード