Microsoft BizTalk Adapter for Oracle Database では、Oracle データベースをポーリングして、ポーリング ベースのデータ変更メッセージを受信できます。 アダプターは、次の方法でアプリケーションにメッセージを配信します。
SQL SELECT クエリを実行して、データがポーリングに使用できるかどうかを判断します。 SQL SELECT クエリを定期的または継続的に実行するようにアダプターを構成できます。
Oracle テーブルまたはビューに対して SQL SELECT クエリを実行するか、ストアド プロシージャ、関数、またはパッケージ化されたプロシージャと関数を実行する。
ポーリングの後に、オプションで PL/SQL コード ブロックを Oracle データベースで実行します。 このコード ブロックは、多くの場合、ターゲット内のクエリされたレコードのフィールドを更新したり、クエリされたレコードを別のテーブルまたはビューに移動したりするために使用されます。
POLLINGSTMT 操作、またはポーリング操作として公開されているストアド プロシージャ、関数、またはパッケージ化されたプロシージャおよび関数を呼び出して、クエリの結果を結果セットに返します。
アダプターは、Oracle トランザクション内でこれらすべての操作を実行します。
また、このアダプターを使用すると、接続 URI で
PollingIdパラメーターを公開することで、同じアプリケーション内の複数の Oracle 成果物のデータ変更メッセージを受信することもできます。 このパラメーターは、POLLINGSTMT 操作のターゲット名前空間を変更します。
POLLINGSTMT のターゲット名前空間を変更する
接続 URI でクエリ文字列パラメーター PollingId 設定することで、POLLINGSTMT 操作のターゲット名前空間を変更できます。 接続 URI にPollingIdが指定されている場合、Oracle Database アダプターは、 パラメーターで指定された文字列を POLLINGSTMT 操作の既定のターゲット名前空間 () に追加します。 POLLINGSTMT 操作のメッセージ アクションは変更されません。
たとえば、次の接続 URI が指定されている場合は、次のようになります。
OracleDb://User=SCOTT;Password=TIGER@Adapter?PollingId=AcctActivity
ターゲット名前空間は次のとおりです。
http:/microsoft.lobservices.oracledb/2007/03/POLLINGSTMTAcctActivity。
注意事項
この例またはガイダンスでは、接続文字列やユーザー名とパスワードなどの機密情報を参照します。 これらの値をコードにハードコーディングしないでください。また、使用可能な最も安全な認証を使用して機密データを保護してください。 詳しくは、次のドキュメントをご覧ください。
POLLINGSTMT 操作ごとに一意の名前空間を指定することで、アプリケーション内の複数の Oracle テーブルとビューのデータ変更メッセージを受信できます。
Oracle Database アダプター接続 URI の詳細については、「 Oracle Database 接続 URI の作成」を参照してください。
バインディング プロパティを使用してデータ変更メッセージを受信する
次のバインディング プロパティの一部またはすべてを設定して、データ変更メッセージを受信するように Oracle Database アダプターを構成します。
| バインディングプロパティ | 価値 | 既定値 | 必須/任意 |
|---|---|---|---|
| InboundOperationType | 値が [ポーリング] に設定されていることを確認します。 | ポーリング | 必須。 明示的に設定しない場合は、既定値が適用されます。 |
| ポーリングデータの利用可能声明 | 実行される SELECT ステートメントを指定して、特定のテーブルのポーリングに使用できるデータがあるかどうかを判断します。 指定したステートメントは、行と列で構成される結果セットを返す必要があります。 結果セットの最初のセルの値は、アダプターが PollingStatement バインディング プロパティに指定された値を実行するかどうかを示します。 結果の最初のセルに正の値が含まれている場合、アダプターはポーリング ステートメントを実行します。 たとえば、このバインド プロパティの有効なステートメントは次のようになります。Select * from <table_name>手記： このバインド プロパティにはストアド プロシージャを指定しないでください。 また、このステートメントでは、基になる Oracle データベースを変更しないでください。 |
デュアルから 1 を選択する | 必須。 明示的に設定しない場合、既定値が適用されます。これは、ポーリング対象のテーブルにデータがあるかどうかに関係なく、アダプターがポーリングを続行する必要があることを意味します。 |
| PollingAction | ポーリング操作のアクションを指定します。 アダプター サービス アドインを使用して、操作に対して生成したメタデータから、特定の操作のポーリング アクションを決定できます。 | 無効 | SELECT ステートメントを使用してテーブルとビューに対するポーリング操作を行う場合は省略可能です。 |
| PollingInterval | アダプターが Oracle データベースに対してクエリを実行する間隔を秒単位で設定します。 このプロパティは、ポーリング間隔とポーリング トランザクションタイムアウトを指定します。値は、Oracle データベースでクエリとポーリング後ステートメントを実行するのにかかる時間 (指定されている場合) に加えて、クライアントがクエリ データを処理してポーリング応答メッセージを返すのにかかる時間を超える必要があります。 | 500 | 必須。 明示的に設定しない場合は、既定値が適用されます。 |
| PollingStatement | 次のいずれかを指定します。 - Oracle データベースに対して実行する必要がある SQL SELECT ステートメント。 このステートメントには、FOR UPDATE 句を含める必要があります。 FOR UPDATE 句の詳細については、このトピックで後述 するポーリング ステートメントでの FOR UPDATE 句の指定 を参照してください。 - ポーリング対象とするパッケージ内のストアドプロシージャ、関数、またはプロシージャまたは関数のリクエストメッセージ。 |
無効 | 必須。 PollingStatement を null 以外の値に設定すると、ポーリングが有効になります。 |
| PollWhileDataFound | ポーリング対象のテーブルでデータが使用可能な場合に、Oracle Database アダプターがポーリング間隔を無視し、Oracle データベースを継続的にポーリングするかどうかを指定します。 テーブルに使用可能なデータがない場合、アダプターは指定されたポーリング間隔で SQL ステートメントを実行するように戻ります。 | いいえ | 必須。 明示的に設定しない場合は、既定値が適用されます。 |
| 投票後声明 | クエリの実行後、クエリ データがクライアントに返される前にアダプターによって実行されるオプションの PL/SQL コード ブロックに設定します。 | 無効 | 任意。 値が指定されていない場合、post poll ステートメントは実行されません。 |
注
WCF サービス モデルまたは WCF チャネル モデルを使用している場合は、 AcceptCredentialsInUri バインディング プロパティも設定する必要があります。
ポーリング ステートメントに FOR UPDATE を入力します
ポーリング ステートメントとして SELECT ステートメントを使用し、SELECT ステートメントで指定された行に影響するポーリング後ステートメントを実行する場合は、ポーリング ステートメントで FOR UPDATE 句を使用する必要があります。 FOR UPDATE 句を指定すると、ポーリング ステートメントによって選択されたレコードがトランザクション中にロックされ、ポーリング後ステートメントで必要な更新を実行できるようになります。
注意事項
ポーリングステートメントとポーリング後ステートメントの間の時間枠内で、ポーリング後ステートメントの条件を満たすレコードがテーブルに追加されるシナリオを作成できます。 このような状況では、ポーリング後ステートメントは、ポーリング ステートメントの一部として選択されたレコードだけでなく、条件を満たすすべてのレコードを更新します。
ポーリング後ステートメントが指定されていて、ポーリング ステートメントに FOR UPDATE 句が含まれていない場合は、次の 2 つの条件のいずれかが発生します。
TransactionIsolationLevel が ReadCommitted に設定されている場合、ポーリング後のクエリでは、選択した行は更新されません。
TransactionIsolationLevel が Serializable に設定されている場合、ポーリング後のステートメントの実行時に次のターゲット システム例外 (Microsoft.ServiceModel.Channels.Common.TargetSystemException) が発生します。"ORA-08177 では、このトランザクションのアクセスをシリアル化できません"。 このような場合は、 PollingRetryCount バインディング プロパティを設定して、アダプターが同じトランザクションを再試行する回数を定義する必要があります。
トランザクション分離レベルを設定する方法については、「 Oracle Database でトランザクション分離レベルとトランザクション タイムアウトを構成する」を参照してください。
ポーリングおよびポーリング後のステートメントは、アダプター クライアントがトランザクションを使用するように構成されていて、アダプターの UseAmbientTransaction バインディング プロパティの値が True に設定されている場合、トランザクションで実行されます。
FOR UPDATE オプションを使用したポーリング クエリの例を次に示します。
SELECT * from EMP WHERE FLAG = 'Y' FOR UPDATE
ポーリング ステートメントに NOWAIT 句を入力します
同時実行スレッドがポーリング対象のテーブルにアクセスし、テーブル内の競合が多すぎる場合があります。 テーブル行のロックを取得するために、ポーリングクエリがブロックされる可能性があります。 ポーリング ステートメントとして SELECT ステートメントを使用している場合は、SELECT ステートメントで FOR UPDATE キーワードと共に NOWAIT キーワードを指定できます。 これにより、ポーリング クエリが選択しようとしている行に対するロックがある場合、アダプター内のポーリング クエリの実行が直ちに返されます。 通常、このような条件下で Oracle によって例外がスローされます。 ここでも、アダプター クライアントは PollingInterval バインディング プロパティを使用して、アダプター クライアントがデータのポーリングを再試行する必要がある時間間隔を指定できます。
NOWAIT オプションを使用したポーリング クエリの例を次に示します。
SELECT * from EMP WHERE FLAG = 'Y' FOR UPDATE NOWAIT
ポーリング ステートメントにSKIP LOCKED句を追加します
ポーリング対象のテーブルに同時スレッドがアクセスするため、ポーリング クエリで指定された WHERE 句の結果セット内の一部の行がロックされている場合があります。 たとえば、ポーリング クエリはテーブルから 6 行を返します。この 6 行のうち 4 行は、他のトランザクションのために既にロックされています。 この場合は、SKIP LOCKED キーワードと FOR UPDATE キーワードを指定して、WHERE 句で指定された行をロックし、既にロックされている行をスキップするようにデータベースに指示できます。 WHERE 句のロック解除された行はトランザクション中にロックされ、ポーリング後のステートメントで必要な更新を実行して、これらの行が再度ポーリングされないようにすることができます。 これにより、WHERE 句で指定されたすべての行がロック解除されるまで、ポーリング メッセージの受信を待機する必要がないようにします。
SKIP LOCKED キーワードは、データベース内の同じテーブルをポーリングしている複数のコンピューターにアダプター クライアントがある場合に便利です。 その時点でロックが解除された WHERE 句で指定された行のポーリング ベースのデータ変更メッセージを受信するようにポーリング操作を構成し、その行を更新して、ポーリング ベースのデータ変更メッセージがアダプター クライアントによって確実に受信されるようにすることで、アダプター クライアント間で負荷分散を行うことができます。 他のクライアントは同じメッセージを受け取りません。
SKIP LOCKED オプションを使用したポーリング クエリの例を次に示します。
SELECT * from EMP WHERE FLAG = 'Y' FOR UPDATE SKIP LOCKED
順序付き配信 (FIFO) のサポート
運用環境では、ポーリングを使用して Oracle データベースのデータ変更を監視できます。 これらのデータ変更メッセージは、Oracle データベース アダプターを使用してアダプター クライアントによって受信されます。 ビジネス シナリオに基づいて、データ変更メッセージが正しい順序でアダプター クライアントによって受信される必要があります。
Oracle データベース アダプターは、Oracle データベースからメッセージを受信する順序を維持するために、順序指定された配信または先入れ先出し (FIFO) をサポートします。 Oracle データベース アダプターの受信シナリオでの FIFO のサポートに関連するいくつかの考慮事項を次に示します。
メッセージがオーケストレーションによって使用されている場合、オーケストレーションには、Oracle Database アダプターの受信ポートから送信されるメッセージの順序付けされた配信セットが必要です。
メッセージが送信ポート (コンテンツ ベースのルーティング) シナリオで使用されている場合、送信ポートには、Oracle Database アダプターの受信ポートからのメッセージに対して順序付けされた配信セットが必要です。
WCF-Custom アダプターまたは WCF-OracleDB アダプターには、受信処理に 失敗した要求メッセージ を中断するかどうかを指定する、失敗した場合に要求メッセージを中断するプロパティがあります。 このプロパティは、WCF-Custom の [ メッセージ ] タブ、または [ エラー処理 ] セクションの WCF-OracleDB 受信ポートで設定できます。 次の表に、このプロパティが設定されているかどうかとメッセージ サブスクライバーの状態 (オーケストレーションまたはポート) に基づいて受信メッセージがどのように処理されるかを説明するシナリオを示します。
| ポートの特性 | 一覧に登録されていない状態のサブスクライバー | 参加済みでも停止状態のサブスクライバー |
|---|---|---|
| 失敗した場合に要求メッセージを中断するプロパティが設定されていません | - ルーティング エラー レポートが中断された (再開できないメッセージ) として生成される - 実際のメッセージが中断されていない - ポーリング後のクエリは、トランザクションが中止されるため実行されません。 そのため、ポーリングが繰り返され、行が再度フェッチされます。 - 発生した内容を説明するためにイベント ログで報告されたエラー。 |
- 「失敗」とは見なされない。 イベント ログにエラー メッセージはありません。 - 実際のメッセージは、中断された (再開可能な) キューに入れられます。 - サブスクライブポートまたはオーケストレーションが開始されると、メッセージは自動的に再開されます。 サブスクライバーに指定された配信がある場合は、その配信が優先されます。 - メッセージは手動で再開することもできます。 |
| 障害時に要求メッセージが中断されるプロパティが設定されています | - ルーティング エラー レポートが中断された (再開できないメッセージ) として生成される - 実際のメッセージも中断されます - ポーリング後のクエリは、トランザクションが中止されるため実行されません。 そのため、ポーリングが繰り返され、行が再度フェッチされます。 - 発生した内容を説明するためにイベント ログで報告されたエラー。 |
- 「失敗」とは見なされない。 イベント ログにエラー メッセージはありません。 - 実際のメッセージは、中断された (再開可能な) キューに入れられます。 - サブスクライブポートまたはオーケストレーションが開始されると、メッセージは自動的に再開されます。 サブスクライバーに指定された配信がある場合は、その配信が優先されます。 - メッセージは手動で再開することもできます。 |
こちらも参照ください
Oracle Database アプリケーションを開発する
BizTalk Server を使用して Oracle データベースをポーリングする
WCF サービス モデルを使用して Oracle データベースでポーリング ベースのデータ変更メッセージを受信する
WCF チャネル モデルを使用して Oracle データベースでポーリング ベースのデータ変更メッセージを受信する