使用するノードの決定

IBM Integration Bus には、ユーザー定義ノードと呼ばれる独自のノードを定義するために使用できるインターフェースも用意されています。

統合ノードが動作している モード は、使用できるノードのタイプに影響を与える可能性があります。 各動作モードに適用される制約事項を参照してください。

どのノードを使用するかは、メッセージに対して実行する処理によって異なります。

入力、出力、および要求ノード

入出力ノードは、クライアント・アプリケーションがメッセージを送信する先のメッセージ・フロー内のポイント ( MQ 入力などの入力ノード)、およびクライアント・アプリケーションがメッセージを受信する元のメッセージ・フロー内のポイント ( MQOutputなどの出力ノード) を定義します。 クライアント・アプリケーションは、ノードがメッセージの送信元または宛先として指定した I/O リソースとの間でメッセージの書き込みと読み取りを行うことにより、これらのノードと相互作用します。 メッセージ・フローには少なくとも 1 つの入力ノードが組み込まれていなければなりませんが、出力ノードや要求ノードが組み込まれている必要はありません。

入力ノードは、その他のメッセージ・フローを起動してその処理を行う時期を制御するため、他のノードとは異なります。 入力ノードは、メッセージ・フローで処理するデータがあることをチェックし、トランスポートまたはサーバーからそのデータを読み取り、後のフローにそのデータを渡して処理するように設計されています。 その他のノードは処理を行いますが、フローを起動する時期の制御は行いません。

Reply、要求、および応答ノードを使用して、メッセージ・フロー内から他のアプリケーションと対話することができます。これらのタイプのノードは、プロトコルのサブセットに対してのみ提供されます。

• 統合ノードへのデプロイメントのためにメッセージ・フローを作成する場合は、メッセージを受信するために少なくとも 1 つの 入力ノード を組み込む必要があります。 選択する入力ノードは、入力メッセージの送信元、およびメッセージを受け取りたいフロー内の場所によって異なります。
• メッセージ・フローによって生成されたメッセージをターゲット・アプリケーションに送信する場合は、1 つ以上の 出力ノードを組み込むことができます。 選択する出力ノードは、次のように、そのメッセージのターゲット・アプリケーションでの受け取りの際に予定されているトランスポートによって決まります。
• フローの途中で、外部システムに対して要求を行い、その結果をメッセージ・ツリーに入れる場合は、 要求ノードを使用します。

メッセージの操作、拡張、および変換を行うためのノード

たいていどの企業でも、さまざまなシステム上で、さまざまなプログラム言語とさまざまな通信方法を使って、長年に渡って開発されてきた複数のアプリケーションがあるものです。 IBM Integration Bus では、ある形式から別の形式にメッセージを変換するメッセージ・フローを構成する機能を提供することにより、アプリケーションがこれらの違いを理解する必要がなくなります。

例えば、個人名を保持する形式は多数あり、アプリケーションごとに異なります。 姓を最初と最後のどちらに置くか、ミドルネームのイニシャルを含めるか、大文字表記か小文字表記かは、順列の一部にすぎません。 各アプリケーションの要件を認識するようにメッセージ・フローを構成できるので、送信または受信アプリケーションには変更を加えることなく、各メッセージを正しい形式に変換できます。

メッセージの内容を処理し、いくつかの方法でそれを更新することができます。 ここでのユーザーの選択は、メッセージ・フローが処理するのが、事前定義 (モデル化) メッセージなのか、自己定義メッセージ (例えば XML) なのか、またはその両方なのかによって異なります。

メッセージ・フローでは、メッセージを完全に再作成することも、その形式を別の形式に変換する (例えば、フィールドの順序、バイト・オーダー、または言語を変更する) ことも、メッセージから内容を削除することも、メッセージに特定のデータを挿入することもできます。 例えば、あるノードでは、データベースと対話して追加情報を検索すること、あるいはメッセージのコピー (全体または一部) をデータベースに保管して、オフライン処理を可能にすることができます。

以下の例は、メッセージ変換の重要性を示しています。

• ある受注入力アプリケーションでは、パーツ ID がメッセージの本文に含まれるのに対し、それに関連付けられている在庫アプリケーションでは、パーツ ID がメッセージ・ヘッダーに入っていることを期待しています。 メッセージをあるメッセージ・フローに送ります。 このメッセージ・フローは、これらの 2 種類の形式が分かっているので、必要に応じて情報を形式設定し直すことができます。
• あるデータ入力アプリケーションは、株式取引情報の入ったメッセージを作成します。 このメッセージを受信するアプリケーションによっては、そのままの情報を必要とする場合も、メッセージに株価収益 (PE) 率の情報を追加する必要がある場合もあります。 株式取引メッセージをあるメッセージ・フローに送ります。 このメッセージ・フローは、ある出力ノードへはメッセージに変更を加えずに渡し、他の出力ノードへは付加的な情報を計算して追加します。 この計算を行うため、このメッセージ・フローでは、データベースで現在の株価を検索し、この値と元のメッセージの取引情報を使用して PE 値を計算してから、更新したメッセージを渡します。

また、以下のノードを使って相互に対話するメッセージ・フローを作成することもできます。 あるメッセージ・フローのデフォルト操作が他のメッセージ・フローの操作に影響を与えることはありませんが、データベースなどの外部ソースで情報の保管や検索を行うようにメッセージ・フローを構成すれば、このアクションを強制的に起こすことができます。

これらのノード は、メッセージを変換するために提供されています。

決定を下すためのノード

メッセージ・フロー内の制御の順序とフローに関するさまざまなことを判別するノードを使用して、フローによるメッセージの処理を決定できます。 また、メッセージ・フロー内のイベントの時刻と発生頻度を決定するノード (制御のタイムアウト および タイムアウト通知) を使用することもできます。 ルーティングはメッセージ変換には依存しません。ただし、メッセージがたどる経路によって、メッセージに対してどのような変換が実行されるかが正確に決定されることはあります。

例えば、ある振替アプリケーションが、常にもう 1 つのアプリケーションにメッセージを送信するとします。 振替額が 10,000 ドルを上回るメッセージについては、もう 1 つ別のアプリケーションにも送信して、高額の取引をすべて記録できるようにします。

別の例として、ある全国規模の自動車クラブでは、特定のメンバーに対し、しきい値を超える注文について特別サービスを提供します。 大部分の注文は通常のチャネルへルーティングされますが、メンバーシップ番号と注文額が特定の基準にかなう場合は特殊な処理が適用されます。

メッセージを処理する時点で追加のルーティング情報をメッセージに組み込むことにより、さらに動的なルーティング・オプションも設定できます。 オプションの規則セットをセットアップし、メッセージに設定された値 (宛先) に基づいてメッセージ受信が行えるようにします。 こうした規則を設定するにあたっては、追加したメッセージ内容で決めた順番に従って、1 つ以上のオプションの規則セットでメッセージを処理するようにできます。

メッセージ・フロー内でメッセージがたどる経路を決定するために、 これらのノード が用意されています。

時間に制約される操作を制御するためのノード

毎日特定の時刻にバッチ・アプリケーション・プロセスを実行したり、一定間隔で情報を処理してパブリッシュしたり (例えば通貨の為替レートを計算して銀行に送るなど)、または既定時間内で特定のトランザクションが完了しない場合に、指定のリカバリー・アクションを取りたいことがあります。 これらのすべてのケースについて、2 つのタイムアウト・ノード (制御のタイムアウト および タイムアウト通知) が用意されています。 時間依存操作を制御するためのノードを参照してください。

その他のノード

以下のタスクを実行するための、その他のノードがあります。

• 要求の照合
• メッセージ・コレクションの作成
• メッセージのシーケンスの制御
• エラーの処理と報告
• メッセージ・フロー・セキュリティー・マネージャーの起動

詳しくは、 その他のノード を参照してください。