WebSphere Message Broker バージョン 8.0.0.5 オペレーティング・システム: AIX、HP-Itanium、Linux、Solaris、Windows、z/OS

製品の最新バージョンについては、IBM Integration Bus バージョン 9.0 をご覧ください。

イベントに基づくデータベース統合

データベース内のイベントに応答するには、DatabaseInput ノードを使用します。 例えば、ブローカーは、外部システムとデータベースの同期処理を行うために、データベースでデータが変更されるたびに、ターゲット・システムに更新内容を送信できます。

データベースでは、データが変更されたという事実をイベント・ストア (通常はデータベース表) に記録する必要があります。 イベント・ストアは、アプリケーション・データと同じではありません。 データベース、イベント・ストア、ブローカーの相互作用を以下の図にまとめます。

このイメージの後に説明文があります。
  1. データベース・アプリケーションがデータベース表を変更します。
  2. データベース管理システム (DBMS) がその変更をイベント・ストアに記録します。
  3. ブローカーが「ポーリング間隔」構成設定で指定されている間隔の経過後にイベント・ストアをポーリングします。
  4. WebSphere® Message Broker が新しいデータまたは変更されたデータを取得し、イベント・ストアを更新することによって、データの処理が 1 回だけになるようにします。
  5. WebSphere Message Broker がデータを処理し、最終的にそのデータをターゲット・アプリケーション (SAP、Web サービス、CICS® Transaction Server for z/OS® など) に提供します。 必要に応じて、データを別の論理/物理形式で提供することも可能です。

実装

このシナリオを実装するには、次のような手順が必要です。
  1. イベントを記録するようデータベースを構成します。
  2. ターゲット・システムがそれらの新しいイベントからデータを受け取るための形式を指定します。
  3. DatabaseInput ノードを使用してそれらのイベントを検出するようにブローカーを構成します。 DatabaseInput ノードを構成するには、DatabaseInput ノードの構成を参照してください。
  4. ターゲット・システムにデータを正しい形式で提供するようにメッセージ・フローの残りの部分を構成します。

DatabaseInput ノード

DatabaseInput ノードのしくみを以下の図にまとめます。

プロセスが開始されると、ReadEvents がイベント・ストアをチェックして新しいイベントがあるかどうかを確認します。新しいイベントがあると、BuildMessage がそれらのイベントを使用してメッセージを作成します。 そのメッセージがメッセージ・フローに伝搬すると、EndEvent がイベント・ストアを更新して、イベントが再び処理されないようにします。

プロセスが開始されると、ReadEvents がイベント・ストアをチェックして新しいイベントがあるかどうかを確認します。新しいイベントがあると、BuildMessage がそれらのイベントを使用してメッセージを作成します。 そのメッセージがメッセージ・フローに伝搬すると、EndEvent がイベント・ストアを更新して、イベントが再び処理されないようにします。 すべてのイベントが処理されると、ブローカーが ReadEvents を呼び出して、前のチェック時以降に追加されたイベントを取得します。 イベント・ストアが空であれば、ブローカーは、ポーリング間隔が満了するまで待って、ReadEvents を再び呼び出します。 競合を避けるために、イベント・ストアのチェックは単一スレッドになっています。

ReadEvents が読み取るイベントごとに、BuildMessage がメッセージを作成します (そのメッセージは、メッセージ・フローに伝搬します)。 通常、メッセージを作成するときには、イベント・データを使用して、アプリケーション表のデータを検索し、そのアプリケーション表のデータに基づいてメッセージを構成します。 BuildMessage の処理が終了すると、メッセージがメッセージ・フローに自動的に伝搬します。 メッセージが伝搬すると、ブローカーがメッセージの処理に必要な下流のノードを開始します。

メッセージがメッセージ・フローに伝搬すると、EndEvent がイベント・ストアを更新して、その処理が済んだばかりのイベントが再び処理されないようにします。

ReadEvents、BuildMessage、EndEvent の詳細な操作を制御するのは、ESQL コードです。 DatabaseInput ノードには、サンプル・コードとコメントが含まれている ESQL モジュールが用意されています。それぞれの要件に合わせて、その ESQL モジュールを変更する必要があります。 ESQL を変更するための詳細については、DatabaseInput ノードの構成を参照してください。

トランザクションと規模の拡大縮小

DatabaseInput ノードで完了するプロセスは、いくつかのトランザクションに分割されています。 ReadEvents が処理を開始すると、新しいトランザクションが開始されます。 ReadEvents が処理を終了すると、そのトランザクションがコミットされ、新しいイベントに処理のためのマークが設定されます。 そのトランザクションがコミットされると、ReadEvents から実行される ESQL コードによってデータベースに設定されたロックが解除されます。 その後、BuildMessage が受け取るイベントごとに、新しいトランザクションが開始されます。 その新しいトランザクションは、EndEvent の処理の終了後にコミットされます。

多数のイベントに対応できるように DatabaseInput ノードの規模を拡大するには、「インスタンス」タブの「追加インスタンス」プロパティーをデフォルト値の 0 からインスタンスの必要数に変更します。 追加インスタンスを使用する場合は、複数のアプリケーションがアプリケーション表の別々の行を同時に読み取ることができるようにデータベースを構成する必要があります。 追加インスタンスを使用する場合でも、データベースの競合を避けるために、ReadEvents は常に、単一スレッド・モードで実行されます。 パフォーマンスを改善するために、ReadEvents は、実行のたびに複数のイベントを読み取ることができるようになっており、それらのイベントを BuildMessage の複数のインスタンスが同時に処理できるようになっています。 イベント・ストアには主キーが必要です。ReadEvents は、その主キーに基づいて、現在処理中のイベントを識別します。 メッセージ・フローで現在処理されているイベントをフィルターに掛けるために、ReadEvents で ESQL を記述する必要はありません。

特記事項 | 商標 | ダウンロード | ライブラリー | サポート | フィードバック

Copyright IBM Corporation 1999, 2014Copyright IBM Corporation 1999, 2014.

        
        最終更新:
        
        最終更新: 2015-02-28 17:48:47


概念トピック概念トピック | バージョン 8.0.0.5 | bc34040_