データベース内のイベントに応答するには、DatabaseInput ノードを使用します。 例えば、ブローカーは、外部システムとデータベースの同期処理を行うために、データベースでデータが変更されるたびに、ターゲット・システムに更新内容を送信できます。
データベースでは、データが変更されたという事実をイベント・ストア (通常はデータベース表) に記録する必要があります。 イベント・ストアは、アプリケーション・データと同じではありません。 データベース、イベント・ストア、ブローカーの相互作用を以下の図にまとめます。
DatabaseInput ノードのしくみを以下の図にまとめます。
プロセスが開始されると、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 を記述する必要はありません。