Adapter for JDBC は、非同期イベント送達を行う Inbound イベント管理をサポートします。イベントは、標準イベント・テーブルと カスタム照会の 2 つのモードを使用して処理されます。
ユーザー・テーブルで変更を行うと、アプリケーションはエンタープライズ情報システム (EIS) 内の イベント・テーブル (イベント・ストアと呼びます) にデータを取り込みます。 ユーザー・テーブルにトリガーを配置することによって更新を行います。ユーザー・テーブルは、ユーザー・テーブルへの更新に対応してイベント・テーブルにイベントを記録します。
アクティベーション・スペック・プロパティー AssuredOnceDelivery を true に設定すると、 イベント・ストアの各イベントに xid (トランザクション ID) 値が設定されます。イベントが処理対象として取得されると、イベント・テーブル内でそのイベントの xid 値が更新されます。さらに、イベントが対応するエンドポイントに送達され、その後イベント・テーブルから 削除されます。イベントがエンドポイントに送達される前に、データベース接続が失われたか、アプリケーションが停止した場合、イベントは完全に処理されない可能性があります。この場合、xid 列によって、イベントが再処理され、エンドポイントに送信されることが保証されます。 データベース接続が再確立されるか、アダプターが再び始動されると、アダプターは、イベント・テーブルで xid 列に値を持つイベントがあるかどうかをチェックします。アダプターは、まずこれらのイベントを処理してから、ポーリング周期の間にその他のイベントをポーリングします。イベント・テーブルは次のように記述されます。
アダプターは、処理するイベントをビジネス・オブジェクト・タイプでフィルターに掛けることができます。 フィルターは、アクティベーション・スペック・プロパティー EventFilterType を使用して設定します。 このプロパティーは、ビジネス・オブジェクト・タイプをコンマで区切ったリストを持ちます。プロパティーで 指定されたタイプのみが処理されます。プロパティーに値が指定されていない場合、 フィルターは適用されず、すべてのイベントが処理されます。アクティベーション・スペック・プロパティー FilterFutureEvents が true に 設定されている場合、アダプターは、タイム・スタンプに基づいてイベントを フィルターに掛けます。アダプターは、各ポーリング周期のシステム時刻を 各イベントのタイム・スタンプと比較します。イベントが将来発生するように設定されている場合は、 その時刻になるまで処理されません。
3 種類のカスタム照会について、以下に説明します。
標準の SQL
ユーザーは、1 つのポーリング数量の入力パラメーターを取る SQL select ステートメントを入力することができます。照会は、その他の入力パラメーターを持つことができますが、それらすべてのパラメーターの値が、SQL 照会自体で設定されている必要があります。SQL 照会は、ポーリング数量に相当する数のレコードを含む 結果セットを返します。この結果セットは、event_id、object_key、object_name、および object_function の列を、この順序で含んでいなければなりません。 Adapter for JDBC は、イベント・オブジェクトを生成してイベントを処理します。
ストアード・プロシージャー
カスタム照会は、結果セットを含むストアード・プロシージャーである場合があります。ストアード・プロシージャーが呼び出されたときに、アダプターはポーリング数量の値を渡します。そのため、ユーザーが入力したプロシージャーは、ポーリング数量の入力パラメーターを受け入れる必要があります。また、ストアード・プロシージャーには、結果セット型の出力パラメーターがあります。ストアード・プロシージャーによって戻される結果セットは、event_id、object_key、object_name、および object_function の列を、この順序で含んでいなければなりません。ストアード・プロシージャーを指定する際に使用される構文を、以下に示します。
call <sp_name> (?, ?)
ここで sp_name は、実行する必要のあるストアード・プロシージャーの名前です。
ストアード・プロシージャーは、その他の入力パラメーターを取ることもできますが、call ステートメント自体でそれらの入力パラメーターに値を提供する必要があります。例えば、call <sp_name> (25, ?, ?) のようにします。
ストアード関数
カスタム照会は、結果セットを戻すストアード関数である場合もあります。ストアード関数が呼び出されたときに、アダプターはポーリング数量の値を渡します。そのため、ユーザーが入力した関数は、ポーリング数量の入力パラメーターを受け入れる必要があります。また、関数の戻り値は、結果セットでなければなりません。関数によって戻される結果セットは、event_id、object_key、object_name、および object_function の列を、この順序で含んでいなければなりません。ストアード関数を指定する際に使用される構文を、以下に示します。
? = <sp_name> (?)
ここで sp_name は、実行する必要のあるストアード関数の名前です。
ストアード関数は他の入力パラメーターを取ることができますが、call ステートメント自体でそれらの入力パラメーターに値を提供する必要があります。例えば、 ? = call <sp_name> (25, ?) のようにします。
アダプターは、カスタム更新照会および削除照会のサポートを提供します。ユーザーは通常、更新照会 を使用して、 同じレコードが以降のポーリング周期中に処理対象として 取り出されないようにします。削除照会 は、各イベントの処理後にレコードを 削除する必要がある場合に使用します。更新照会と削除照会は、どちらもオプションです。
これらの照会は、アクティベーション・スペックで指定された場合、各イベントの処理後に実行されます。ユーザーは、これらの照会を 2 とおりの方法で入力することができます。標準 SQL ステートメントとして、またはストアード・プロシージャーとして入力します。 ストアード・プロシージャー構文は、カスタム照会アクティベーション・スペック・プロパティーに指定された構文と同じです。標準 SQL とストアード・プロシージャーはどちらも、イベント ID の入力パラメーターを取ります。アダプターは、実行時にイベント ID の値を提供します。照会には、追加の入力パラメーターを含めることができますが、それらは、カスタム・イベント照会について説明したように、照会構文自体で提供される必要があります。
xid 値を格納するための標準イベント・ストアを作成した場合、カスタム照会は 「送達は 1 回のみ」をサポートします。アダプターは、カスタム・イベント照会によって 返されたイベントをイベント・ストアに格納し、そのイベントを xid 値で更新します。アダプターは、標準のイベント・テーブル処理と同じ方法で イベントを処理します。標準イベント・ストアは、AssuredOnceDelivery プロパティーを true に設定したカスタム・イベント処理に使用されるため、カスタム照会は、標準イベント・テーブルで照会を行うことはできません。さらにこのシナリオでは、アダプターが、カスタム照会から取得したイベント ID 値をイベント・テーブルに取り込むため、イベント・テーブルではイベント ID 値の自動生成が行われません。カスタム照会では、イベントのフィルター処理は サポートされません。
イベント・テーブルは以下の表に記述されています。
名前 | 型 | 説明 |
---|---|---|
xid | String | 「送達は 1 回のみ」の場合の固有のトランザクション ID (xid) 値 |
event_id | Number | テーブル用の基本キーである固有のイベント ID |
object_key | String | ビジネス・オブジェクト用のキーを含む、区切り文字で区切られたストリング (NULL 以外) |
object_name | String | ビジネス・オブジェクトの名前 (NULL 以外) |
object_function | String | イベントに対応した操作 (Delete、Create、Update など) (NULL 以外) |
event_priority | Number | 任意の正整数値 (NULL 以外) |
event_time | Timestamp | イベントが生成された日時 |
event_status | Number | 値は次のとおりです。
|
event_comment | String | 説明 |
(c) Copyright IBM Corporation 2005, 2006.
(C) Copyright IBM Japan 2006
このインフォメーション・センターでは Eclipse テクノロジー (http://www.eclipse.org) が採用されています。