イベント・ストアは、ポーリング・アダプターがそれらを処理できるまで、データの変更を表すイベントを保持するテーブルです。 アダプターは、イベント・エンティティーを追跡するために、イベント・ストアを使用します。
インバウンド処理を使用するためには、PeopleTools Application Designer を使用して、イベント通知用のカスタム・プロジェクトを作成する必要があります。カスタム・プロジェクトは 将来のイベントの処理方法を決める 2 つの PeopleCode 関数を使用します。 さらに、カスタム・プロジェクトはインバウンド処理のためにアダプターが必要とするイベント・ストアを作成します。 ビジネス・オブジェクトが作成、更新、または削除されるたびに、 プロジェクト内で使用されてからコンポーネント・インターフェースに追加された PeopleCode 関数は、 新しいレコードを適切なオブジェクト名、キー、および状況値と共にイベント・ストアに挿入します。
インバウンド処理では、アダプターは構成されたポーリング間隔でイベント・ストアからイベント・エンティティーをポーリングします。 各々のポーリング呼び出しの際に、構成された数のイベントがアダプターによって処理されます。 イベント処理の順番は、優先順位の昇順およびイベント・タイム・スタンプの昇順に基づいています。ポーリング準備完了 (0) の状況にあるイベントが、各ポーリング周期にポーリングのために選出されます。 アダプターは、対応するビジネス・オブジェクトを取り出すために、オブジェクト名とオブジェクト・キーを使用します。
アクティベーション指定プロパティー AssuredOnceDelivery を true に設定すると、イベント・ストア中の各イベントに対して XID (トランザクション ID) 値が設定されて、 それはイベントがターゲット・アプリケーションに対して 1 回だけ送信されることを保証するために使用されます。 処理するためにイベントが取得された後、イベント・ストア中のそのイベントの XID 値は更新されます。 次いで、そのイベントは対応するエクスポート・コンポーネントに配信され、イベント配信が完了したことを示すように状況が更新されます。 イベントがエクスポート・コンポーネントに配信される前にアプリケーションが停止した場合、 または配信が失敗した場合には、イベント処理が完了していない可能性があります。 この場合、XID 値は処理中の状況を表し、XID 列があるために、そのイベントが確実に再処理されてエクスポート・コンポーネントに送信されることになります。 データベース接続が再確立するかアダプターが再始動すると、イベント表中の XID 列にポーリング準備完了 (0) の値を持つイベントを、アダプターが検査します。 アダプターはこれらのイベントをまず処理し、次いでポーリング周期の際に他のイベントをポーリングします。
アダプターは、将来に生じる予定であることを示す状況コード (99) を持つイベントに対して、特別な処理を使用します。 ポーリング周期の期間中に、アダプターが将来状況を持つイベントを取り出すと、 アダプターはシステム時刻と各イベントのタイム・スタンプとを比較します。 イベント時刻がシステム時刻よりも前であるか、または等しい場合、 アダプターはイベントを処理して、イベント状況をポーリング準備完了 (0) に変更します。
アダプターが将来状況のイベントを現在時刻で処理するようにするには、 関数 IBM_PUBLISH_EVENT を IBM_FUTURE_PUBLISH_EVENT の代わりに使用します。 これにより、イベントは将来 (99) ではなくポーリング準備完了 (0) として識別されます。
イベントがイベント・ストアから取り出され、処理されるにつれて、そのサイクルを反映するように、イベントの状況が次の表に示すように変更されます。
状況の短縮名 | 説明 | イベント表の値 |
---|---|---|
イベント処理エラー | イベント処理の際にエラーが発生しました。 | -1 |
ポーリング準備完了 | イベントはまだアダプターによって選出されていません。 イベントは選出される準備が整っています。 | 0 |
成功 | イベントはイベント・マネージャーに配信されました。 | 1 |
削除済み | イベントは、正常に処理され、イベント・ストアから除去されています。 | 4 |
将来イベント | これらのイベントは、将来の日に処理される必要があります。 | 99 |