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

データベース内のデータが変更されるたびにシステムに更新を送信することにより、統合ノードが外部システムをデータベースと同期できるようにするために、データベース内のイベントに応答します。

イベント・ベースのデータベース統合は、以下の 2 つの方法で実現できます。
  • DatabaseInput ノードを使用すると、データベース内でトリガー機能を使用できます。 トリガーは、トランザクション境界内で実行され、元のトランザクションに遅延をもたらす可能性があります。 ただし、トリガーされた実行を元のトランザクションに結び付ける必要がある場合は、これが利点となります。 この方法を使用するには、このトピックの残りの部分のアドバイスに従ってください。
  • 元のトランザクションとは別のスレッド (または別のプロセス) にあるデータベース・ログを使用することができます。 この方法を使用するには、 Change Data Capture ノードをメッセージ・フローに追加し、変更されたデータをデータベースから IBM® App Connect Enterpriseにキャプチャーするようにこのノードを構成します。 詳しくは、 Change Data Capture ノード および Change Data Capture ノードの構成を参照してください。

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

このイメージについては、後に続く本文で説明します。
  1. データベース・アプリケーションがデータベース表を変更します。
  2. データベース管理システム (DBMS) がその変更をイベント・ストアに記録します。
  3. 統合ノードが「ポーリング間隔」構成設定で指定されている間隔の経過後にイベント・ストアをポーリングします。
  4. IBM App Connect Enterprise は、新規または変更されたデータを取得し、データが 1 回だけ処理されるようにイベント・ストアを更新します。
  5. IBM App Connect Enterprise はデータを処理し、最終的にそれをターゲット・アプリケーション (例えば、 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 モジュールが含まれています。このモジュールは、要件に合わせて変更する必要があります。 ReadEvents は、イベント表から読み取ったイベント・データを NewEvents 構造に取り込みます。 生成される各イベント・データ行には、Key と Usr フィールド名の NewEvents.Event[].Key と NewEvents.Event[].Usr が含まれます。 Key フィールドはイベントの固有キーを含み、重複イベント処理を回避するために使用されます。 Usr フィールドは通常、イベントに関連付けられたユーザー定義データを含むサブツリーです。 ESQL の変更について詳しくは、 DatabaseInput ノードの構成を参照してください。

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

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

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

失敗および再試行のメカニズム

  • ReadEvents 中にエラーが発生した場合、エラーはシステム・ログに記録されます。 ポーリング間隔が次に期限切れになった後で再試行します。 メッセージは Failure ターミナルに伝搬されません。
  • BuildMessage の処理中にエラーが発生した場合、例外が Failure ターミナル (接続されている場合) に伝搬されます。 例外が Failure ターミナルで処理されない場合 (つまり、このターミナルは接続されていないか、例外が Failure ターミナルからスローされた場合)、トランザクションがロールバックされます。 それ以外の場合は、トランザクションがコミットされます。 いずれの場合も、例外が処理されるかどうかに関係なく、メッセージは Out ターミナルに伝搬されず、EndEvent は呼び出されません。
  • 例外が Out ターミナルからダウンストリームにスローされた場合、Catch ターミナルによって処理されない例外があるとトランザクションはロールバックされ、EndEvent は呼び出されません。 例外が Catch ターミナルで処理される場合、EndEvent が呼び出され、トランザクションがコミットされます。
再試行処理では、アプリケーション開発者は、キャッチ処理によって正常に処理されていない、ダウンストリーム・ノードで発生した一時的エラーに対処できます。 入力ノードは、以下の 3 つの再試行メカニズムのいずれかを使用して構成できます。
  1. Failure
  2. Short retry then failure
  3. Short then long retry

「Failure」を選択すると、イベントは「Failed」状態に移行し、トランザクションはロールバックされます。 失敗したイベントが検出され、作動可能イベントをディスパッチする前に処理されます。 失敗したイベントは、例外リストとともに Failure ターミナル (接続されている場合) に伝搬されます。

'Short retry then failure' の場合、メッセージ・フローは Retry Threshold プロパティーに等しい数の再試行を実行し、'Short retry interval' に等しい各再試行間隔でメッセージを Out ターミナルに伝搬します。 トランザクションが正常に完了せずに再試行しきい値に達した場合、メッセージは Failure ターミナルに伝搬されます。

'Short then long retry' の場合、再試行ロジックは、再試行しきい値に達したポイントまでは 'short retry then failure' と同じです。 その後、再試行を終了して Failure ターミナルに伝搬する代わりに、無期限に再試行を続行しますが、「Long retry interval」と等しい各再試行の間に遅延が生じます。

トランザクションがロールバックされた場合、またはメッセージが Failure ターミナルに伝搬された場合、EndEvent 操作は自動的に呼び出されません。 これらの状況では、イベントを再処理したくない場合に、イベント・ストアでそのイベントを除去したり更新したりするかどうかはユーザー次第です。

Database Input ノードのダウンストリームで例外が発生したが、その例外が Catch ターミナルで正常に処理されたときを含め、トランザクションが正常に完了した場合、EndEvent 操作は自動的に呼び出されます。