メッセージ処理

アダプターは、以下の 2 つの主要な操作をサポートします。

  1. JMS 宛先からのメッセージの検索
  2. JMS 宛先へのメッセージの配信

アダプターは、JMS プロバイダーへの接続を確立して両方の 操作を行い、次に JMS API を使用して以下のことを行います。

これらの 2 つの操作については、イベント・メッセージの処理 および 要求メッセージの処理 で詳しく説明します。

イベント・メッセージの処理

コネクターは、新しいメッセージが、1 つ以上の JMS 宛先に配信されているか定期的に検査します。各ポーリング・サイクルで、コネクターは以下のことを行います。

  1. JMS API を使用して、待機メッセージを検索する。
  2. 構成済みデータ・ハンドラーを呼び出し、メッセージの内容をビジネス・オブジェクトに変換する。
  3. サブスクライブしているビジネス・プロセスが処理できるように、イベント・ビジネス・オブジェクトを構成済み統合ブローカーに配信または公表する。

これらのステップについては、図 1 に示されています。また、以下で詳しく説明されています。

図 1. イベント・メッセージ・フロー



イベント検出

各イベント・ポーリング・サイクル中に、コネクターは、コネクター・プロパティー InputDestination によって指定された宛先で、メッセージの非ブロッキング読み取りを行います (コネクター・プロパティーの詳細については、コネクター・プロパティーの構成を参照)。コネクターはメッセージを検索してから、ブローカーに公表します。

コネクターは pollForEvents() メソッドを使用して、一定の間隔でポーリングしてメッセージの有無を確認します。ポーリング・サイクルごとのメッセージ検索数は、コネクター・プロパティー PollQuantity に指定されている最大数に制限されます。指定最大数に達する前に、すべての使用可能なメッセージを検索すると、コネクターは、それ以上のメッセージを待たずに、ポーリング・サイクルから即時に戻ります。

コネクター・プロパティー InputDestination で複数の宛先が指定されている場合、コネクターは、指定された各宛先をラウンドロビン方式でポーリングします。各宛先で PollQuanity に指定してある最大数のメッセージを検索し、ブローカーに公表します。PollQuantity に指定されている最大数に達する前にすべての宛先が空になると、コネクターはポーリング・サイクルから即時に戻ります。

例えば、次のようなシナリオでは、

アダプターは以下のメッセージを検索します。

1 回のポーリング・サイクルにおいて:

  1. キュー A の次のメッセージ (メッセージが 1 つ残る)
  2. キュー B の次のメッセージ (空になる)
  3. キュー C の次のメッセージ (メッセージが 4 つ残る)
  4. キュー A の次のメッセージ (空になる)
  5. コネクターがキュー B をチェックするが、空のまま
  6. キュー C の次のメッセージ (メッセージが 3 つ残る)

各キューから最大数 (PollQuanity で指定) の 2 つのメッセージをポーリングしたので、アダプターはポーリング・サイクルから戻ります。

イベント状況およびリカバリー

イベント・メッセージの検索はトランザクションの一部です。トランザクションをコミットする前にコネクターが予期せずに終了する場合、トランザクションはロールバックされ、元のメッセージが復元されます。コネクター・フレームワークは現在、分散トランザクションをサポートしていないため、コネクターは、ブローカーにイベントを公表しても、ブローカーからの確認通知を受信する前に、予期せずに終了するか通信を切断する場合があります。この場合、イベントがブローカーに受信されたかどうかは、コネクターが入手できる情報からは確認できません。イベント・メッセージを失わないようにするために、ブローカーからイベントの受取を確認する応答をら受信するまでは、コネクターはトランザクションをコミットしません。コネクターがイベントを公表し、確認通知を受信するまでの間に障害が発生すると、トランザクションは自動的にロールバックされ、元のメッセージが復元されます。メッセージがブローカーによって処理されたかどうかがわからないため、そのようなイベントは未確定イベントと呼ばれます。

再始動時に、コネクターは、入力宛先からのメッセージの処理を開始し、未確定イベントを再サブミットします。この方式を使用すると、イベントを失うリスクはなくなりますが、同じイベントが 2 回公表される可能性は避けられません。

重複イベント配信のリスクを軽減したり、なくしたりする方法には、次の 2 つの方法があります。進行中の宛先の使用 (進行中の宛先によるリカバリーを参照) または 保証付きイベント・デリバリーの使用 (保証付きイベント・デリバリーによるリカバリーを参照) です。

進行中の宛先によるリカバリー

未確定イベントの処理を制御するには、コネクター・プロパティー InProgressDestination を指定して、別個の一時宛先を作成します。

注:
進行中の宛先のリカバリーは、Pub/Sub スタイルのメッセージングではサポートされていません。
ブローカーにイベントを公表する前に、コネクターは、イベント・メッセージを入力宛先から進行中の宛先へ移動します。ブローカーから確認通知を受信したら、コネクターは、進行中の宛先からメッセージを削除します。これによって、処理されていない未確定メッセージを分離できます。始動時に進行中の宛先にメッセージがあった場合、コネクターは、これらのメッセージは、予期せずに終了したコネクターの以前のインスタンスから残されたものであるとみなすことができるため、安全です。そのようなメッセージに、コネクターが別の処置を行うように指定できます (重複イベント通知 が受諾不能な場合)。これを行うには、以下の 4 つのオプションのいずれかを、コネクター構成プロパティー InDoubtEvents に指定します。

詳細については、InDoubtEventsを参照してください。

保証付きイベント・デリバリーによるリカバリー

保証付きイベント・デリバリー機能により、コネクター・フレームワークは、イベントが逸失したり、イベントが 2 度送信されたりするのを防ぐことができます。コネクター・フレームワークは、コンテナー管理イベント (CME) および重複イベント除去 (DEE) の、2 つの機構によって保証付きイベント・デリバリーをサポートします。

コンテナー管理イベント (CME)

コネクターが PTP スタイル・メッセージングに構成されている場合に、CME を使用できます。Pub/Sub スタイル・メッセージング用に構成されている場合、コネクターは CME をサポートしません。 ContainerManagedEvents コネクター・プロパティーの詳細については、ContainerManagedEventsを参照してください。

重複イベント除去 (DEE)

JMS アダプターに保証付きイベント・デリバリーをインプリメントするときは、DEE 方式をお勧めします。DEE は Pub/Sub スタイルのメッセージングをサポートする唯一の方法でもあります。

DEE では、コネクターは、ブローカーに公表する各イベントに固有 ID を組み込みます。 フレームワークは、コネクターが同じイベント ID を連続してサブミットしていないかチェックします。連続してサブミットされると、フレームワークは、コネクターが同じイベントを 2 度公表しているとみなし、2 番目のサブミットを廃棄します。PTP スタイルのメッセージングに関しては、DEE は進行中の宛先から、またはその宛先へのメッセージをコピーするオーバーヘッドをかなり削減します。

このコネクターは、ビジネス・オブジェクトをブローカーに公表するときに、すべてのイベントのメッセージ ID を組み込みます。通信障害または予期せぬ終了によって、コネクターがイベントをブローカーに正常に送付できない場合は、前に説明したように、元のメッセージが入力キューにロールバックされます。コネクターは再始動時に、すべての未確定メッセージを含め、キューのイベントの再サブミットを開始します。 DEE が使用可能になっていれば、以前ブローカーに正常に到達した未確定メッセージは、すべて廃棄されます。これによって、各メッセージをブローカーに 1 度だけ送付するようにできます。

DEE を使用する場合、コネクターがオフラインの間は、宛先内のメッセージの順序を変更しないようにする必要があります。DEE は、アダプターによって検索された最後のメッセージ ID のみを記録します。アダプターが再始動する前に、高い優先順位を持った新しいメッセージが、最後の未確定メッセージの順序をキュー内で押し下げるなどの場合に、DEE は失敗します。

DuplicateEventElimination コネクター・プロパティーの詳細についは、DuplicateEventEliminationを参照してください。

イベント検索

イベント検索には、コネクターによるイベントの典型的処理が含まれます。イベント検索は、着信イベントが検出されると始まり、それがターゲット・アプリケーションに適したフォーマットに変換され、指定された統合ブローカーに正常に配信されると終了します。コネクターは、すべてのイベントをブローカーに非同期的に (「応答不要送信」で) 配信します。

以下のセクションでイベント検索について説明します。

メタデータおよびメタオブジェクト

メッセージを正常にビジネス・オブジェクトに変換したり、その逆を行ったりするには、コネクターは、メタデータと呼ばれる追加情報を必要とします。メタデータは、オブジェクト、メッセージ、またはアプリケーション内のデータをどのように表現するか、またはそれらをどのように処理するかを説明します。メタデータには、コネクターが宛先 XYZ からメッセージを検索した場合、どのビジネス・オブジェクトを作成するか、または動詞 Create を持ったタイプ Customer の要求ビジネス・オブジェクトをシリアライズするときに、どのデータ・ハンドラーを使用するか、などの詳細が含くまれています。

属性、プロパティー、動詞、およびアプリケーション固有情報が、ビジネス・オブジェクト定義のメタデータを構成します。さらに、宛先、データ・フォーマット、データ・ハンドラーなどのメタデータを含んだ、1 つ以上のメタオブジェクトを指定できます。

メタオブジェクトには、静的タイプおよび動的タイプの 2 つのタイプがあります。インプリメンテーションのときには、静的メタオブジェクトを作成します。静的メタオブジェクトには、コネクターがサポートしなければならない各ビジネス・オブジェクト・タイプにメタデータを提供する属性が含まれます。静的メタオブジェクトはコネクター固有プロパティーで指定され、初期設定のときにコネクターによって読み取られます。メタオブジェクト・プロパティーの概要、およびそれらがメッセージ変換にどのような影響を与えるかについては、ビジネス・オブジェクトのマッピングおよび メッセージ・ヘッダー・マッピングの理解を参照してください。

もう一つのメタオブジェクト・タイプは動的メタオブジェクトです。このメタオブジェクトを使用すると、要求処理のときに、要求ごとに、アダプターが使用するメタデータを変更してビジネス・オブジェクトを処理できます。イベント処理のときに、動的メタオブジェクトは、イベントに関するトランスポート固有情報 (メッセージ ID、優先順位など) を保持するコンテナーとして機能します。このため、ダウンストリーム・ビジネス・プロセスはそれらのビジネス・ロジックでその情報を使用できます。動的メタオブジェクトは、イベント (または要求) のトップレベル・オブジェクトで定義される、特別にマークされた子オブジェクトとして表されます。

メタオブジェクトは、同じインプリメンテーションにおいて、どちらか 1 つを使用することも、両方を使用することもできます。一般に、動的メタオブジェクトで指定された値は、静的メタオブジェクトで指定された値に優先します。静的および動的メタオブジェクトの構成については、メタオブジェクトの構成を 参照してください。

ビジネス・オブジェクトのマッピング

メッセージの検索のときに、コネクターは、メッセージをどのビジネス・オブジェクトにマップすべきかを確認しようとします。

デフォルトでは、コネクターは、コネクター・プロパティーに設定されているデータ・ハンドラーが、ビジネス・オブジェクト・タイプを決定できるようにします。コネクターは、メッセージ本文をデータ・ハンドラーに渡し、データ・ハンドラーが戻したビジネス・オブジェクトをブローカーに公表します。データ・ハンドラーが適切なビジネス・オブジェクトを決定できない場合、コネクターはイベントに失敗します。

コネクター構成プロパティー ConfigurationMetaObject に静的メタオブジェクトが指定されている場合、コネクターはこのオブジェクトを検索して、入力フォーマットまたは入力宛先に関してメッセージに一致するルールを見付けます。メタオブジェクトで指定されたルールが入力フォーマットおよび入力宛先の両方を指定している場合、メッセージがそれらのプロパティーの両方に一致する場合にのみ、コネクターはこのルールに従います。これらのプロパティーのどちらかが欠落している場合、コネクターは指定されたプロパティーのみを使用します。

例えば、入力フォーマット Cust_In を持った、入力宛先 MyInputDest のメッセージは、以下の静的メタオブジェクト・ルールに一致します。

  1. InputFormat=Cust_In;InputDestination=MyInputDest
  2. InputFormat=Cust_In
  3. InputDestination=MyInputDest

イベント・メッセージを 1 つのルールに一致させることができる場合、コネクターは、ビジネス・オブジェクトの新しいインスタンスを作成し、それをメッセージ本文と一緒に、ルールで指定されたデータ・ハンドラーに渡すことによって、このビジネス・オブジェクトを書き取らせます。データ・ハンドラーがルールに指定されていない場合、コネクターは、コネクター構成プロパティーで指定されたデフォルトのデータ・ハンドラーを使用します。

アダプターが、イベント・メッセージを複数のルールに一致させることができる場合、または 1 つのルールにも一致させることができない場合、コネクターは、コネクター構成プロパティーで指定されたデータ・ハンドラーにメッセージ本文のみを渡すことによって、データ・ハンドラーが、ビジネス・オブジェクト・タイプを決定できるようにします。

メッセージ・ヘッダー・マッピングの理解

イベント・メッセージをビジネス・オブジェクトに変換するために、コネクターは、ビジネス・オブジェクトに関するメタデータとメッセージに関するメタデータを比較し、それらをマッピングします。メタデータおよびメタオブジェクトで説明したように、ビジネス・オブジェクトに関するメタデータは、ビジネス・オブジェクト定義 (アプリケーション固有情報および子動的メタオブジェクト)、コネクター・プロパティー、および静的メタオブジェクトの中にあります。メッセージ・メタデータはメッセージ・ヘッダーの中にあります。

トランスポート固有メッセージ・ヘッダー情報へアクセスしたり、メッセージ・トランスポートの詳細情報を入手したり、それを詳細に制御したりするには、ビジネス・オブジェクト定義の子である動的メタオブジェクトに属性を追加します。属性を追加すると、メッセージ・ヘッダーから読み取りができるようになり、オプションで書き込みもできるようになるため、メッセージ・メタデータを変更できるようになります。そのような変更では、JMS プロパティーを変更したり、要求ごとに宛先を制御 したり (アダプター・プロパティーで指定されたデフォルトの宛先を使用せずに)、メッセージの CorrelationID を再ターゲットしたりできます。ビジネス・オブジェクト定義の子である動的メタオブジェクトにそのようなプロパティーを指定すると、コネクターは、メッセージ・ヘッダーでそれらに対応するものをチェックし、メッセージ・ヘッダーの内容に基づいて、動的メタオブジェクトにデータを取り込みます。 1 つまたはすべてのサポートされた動的メタオブジェクト属性を定義できます。コネクターはそれに従って、メタオブジェクトにデータを取り込みます。読み取りまたは書き込みができるメッセージ・ヘッダー・プロパティーのリストを含め、詳細については、ポーリング中の動的な子メタオブジェクトの含まれるデータを参照してください。

アーカイブ

コネクター固有プロパティー ArchiveDestination を指定すると、コネクターは、正常に処理されたすべてのメッセージのコピーをこの宛先に置きます。 ArchiveDestination が未定義の場合、正常に処理されたメッセージは廃棄されます。詳細については、コネクター固有プロパティーの構成を参照してください。

エラー・リカバリー

入力宛先からの読み取りでエラーを検出すると、コネクターは、定数値 APPRESPONSETIMEOUT をすぐにブローカーに戻します。これにより、コネクターは終了し、場合により再始動します。一般に、そのようなリカバリー不能エラーは、JMS プロバイダーへの接続が切断されたか、あるいはコネクターが認識できないか、認識してもリカバリー不能 (トランザクションの失敗など) とみなした、JMS プロバイダーによって 報告された内部エラーかのいずれかが原因です。

インバウンド・メッセージをイベント・ビジネス・オブジェクトに変換しているときにエラーを検出した場合 (データ・ハンドラーが無効なメッセージ・フォーマットを報告する場合など)、コネクターはイベントに失敗し、理由を説明する該当するエラー・メッセージのログを記録します。コネクター・プロパティー ErrorDestination が定義されており、有効な場合、コネクターは、失敗したメッセージのコピーをこのエラー宛先に置きます。そうでない場合、メッセージは廃棄されます。

コネクターがイベント・ビジネス・オブジェクトを公表した後にブローカーがエラーを報告する場合、コネクターはイベントに失敗し、ブローカーによって報告されるエラー・メッセージのログを記録します。 コネクター・プロパティー ErrorDestination が定義されており、有効な場合、コネクターは、失敗したメッセージのコピーをこの宛先に置きます。そうでない場合、メッセージは廃棄されます。

メッセージのビジネス・オブジェクトを決定できない場合、またはメッセージをブローカーに公表しても、ブローカーがそのメッセージはサポートされていないと報告する場合、コネクターは、メッセージはアンサブスクライブされているとみなします。コネクター・プロパティー UnsubscribedDestination が定義されており、有効な場合、コネクターは、アンサブスクライブされたメッセージのコピーをこの宛先に置きます。そうでない場合、メッセージは廃棄されます。

要求メッセージの処理

ビジネス・オブジェクト要求がコネクターに送信されると、コネクターは、ターゲット宛先で新しいメッセージを作成します。メッセージ・ヘッダーには、要求メタオブジェクトで指定されたユーザー定義の値とコネクター・プロパティーによって指定されたデフォルト・パラメーターを組み合わせたデータが読み込まれます。メッセージの本文には、構成されたデータ・ハンドラーを介して要求ビジネス・オブジェクトを渡すことによって生成された結果内容のデータが取り込まれます。

図 2 に、メッセージ要求通信を示します。doVerbFor() メソッドがブローカーからビジネス・オブジェクトを受信すると、コネクターはビジネス・オブジェクトをデータ・ハンドラーに渡します。データ・ハンドラーはビジネス・オブジェクトを適切なテキストに変換し、コネクターはそれをメッセージとして宛先に発行します。

図 2. 要求フロー



要求の処理では、コネクターは 2 つのタイプの処置を行うことができます。 1 つ目は下記で非同期処理として説明するものであり、コネクターはメッセージをターゲット宛先に置いて、正常に戻ります。一般に、これは「応答不要送信」と呼ばれます。 2 つ目は下記で同期処理として説明するものであり、コネクターはメッセージを同じようにターゲット宛先に置きますが、ターゲット・アプリケーションによって応答が戻されるのも待ちます。

処理モードは数値プロパティー ResponseTimeout によって決まります。これは、ビジネス・オブジェクト要求の動的メタオブジェクトまたは静的メタオブジェクトのいずれかで指定されます。このプロパティーが定義されていないか、-1 に設定されている場合、コネクターは要求を非同期的に配信します。このプロパティーが 0 以上の場合、アダプターは、要求を同期的に処理し、ターゲット・アプリケーションが応答メッセージを戻すのをそのミリ秒以上待ちます。図 2 に示した要求処理を、以下で詳しく説明します。

動詞サポート

コネクターは、要求ビジネス・オブジェクトで指定される動詞にセマンティック値は置きません。コネクターは同じ処置を行います。つまり、指定される動詞に関係なく、メッセージを JMS 宛先に置きます。

非同期処理

非同期処理では、コネクターは要求ビジネス・オブジェクトをメッセージに変換し、そのメッセージをターゲット宛先に置いてから、すぐブローカーに戻ります。要求が成功するか失敗するかは、すべて、メッセージを JMS 宛先に置くコネクターの能力に基づいています。この配信が成功しても、ターゲット・アプリケーションにメッセージがあるわけでもメッセージを受信するわけでもないことに注意してください。メッセージング・システムが非同期的性質を持つ場合、ターゲット・アプリケーションがメッセージを処理できるようになるまで、または有効期限切れになる (そのように構成されている場合) まで、メッセージは JMS プロバイダーに無期限にとどまる場合があります。

コネクターはまず、構成されたデータ・ハンドラーを使用して、要求ビジネス・オブジェクトをテキストにシリアライズします。コネクターは、以下に指定されたデータ・ハンドラーを使用します (優先順)。

  1. 動的メタオブジェクト
  2. 静的メタオブジェクト
  3. コネクター構成プロパティー

コネクターは、シリアライズされたビジネス・オブジェクト・データの入った新しいメッセージをメッセージの本文として作成します。コネクターは、以下の表の説明に従って、メッセージ・ヘッダーにデータを読み込みます。動的メタオブジェクトまたは静的メタオブジェクトのどちらにおいてもプロパティーを指定できるすべての場合で、動的メタオブジェクトで指定された値は、静的メタオブジェクトで指定された値に優先します。メタオブジェクトで指定できるプロパティーの説明およびリストについては、メタオブジェクトの構成を参照してください。

表 1. 非同期要求処理での JMS メッセージ・ヘッダーの読み込み
メタオブジェクト・プロパティー プロパティーが未定義の場合のデフォルト処置 プロパティーが定義されている場合に行われる処置
OutputFormat
 
コネクターはメッセージ・フォーマットを指定しない コネクターはメッセージ・フォーマットにこの値を指定する
CorrelationID
 
コネクターはメッセージ・ヘッダーでこの値をブランクにする コネクターは、要求メッセージ・ヘッダーで相関 ID にこの値を指定する
ReplyToDestination
 
コネクターはメッセージ・ヘッダーでこの値をブランクにする コネクターは、要求メッセージ・ヘッダーで応答宛先にこの値を指定する
Priority
 
コネクターは、JMS プロバイダーがデフォルト優先順位を使用できるようにする コネクターは、この値を使用してメッセージ優先順位の数値を設定する
JMSProperties なし コネクターは、指定された JMS プロパティーをメッセージ・ヘッダーの JMS プロパティー にマップする

メタオブジェクトの次の属性が、メッセージの配信方法を決めます。

表 2. 宛先への非同期配信
メタオブジェクト・プロパティー プロパティーが未定義の場合のデフォルト処置 プロパティーが定義されている場合に行われる処置
OutputDestination
 
値が必要 メッセージのターゲット宛先
DeliveryMode
 
コネクターは、JMS プロバイダーがメッセージ・パーシスタンスを書き取らせることができるようにする コネクターは、ユーザーの指示に従って、メッセージを永続的または非永続的に書き込む

コネクターが、要求メッセージを出力 (ターゲット) 宛先に正常に配信できたかどうかによって、以下のいずれかのコードがブローカーに戻されます。

表 3. 非同期戻りコード
コネクターの処置 ブローカーへの戻りコード
メッセージを正常にターゲット宛先へ配信 SUCCEED
不適切または不完全なメタデータ、データ・ハンドラーの失敗、または一般的な処理問題などのリカバリー可能エラーにより、配信が失敗 FAIL
JMS プロバイダーによって報告される、接続の失敗などのリカバリー不能エラーにより、配信が失敗 APPRESPONSETIMEOUT

同期処理

同期処理では、コネクターは要求をターゲット宛先へ配信してから、2 番目の宛先で応答メッセージを待ちます。要求メッセージの作成は非同期処理の場合と同じです。ただし、コネクターは、メタオブジェクトの以下の追加属性もチェックします。

表 4. 同期メタオブジェクト・プロパティー
メタオブジェクト・プロパティー プロパティーが未定義の場合のデフォルト処置 プロパティーが定義されている場合に行われる処置
ResponseTimeout
 
値が必要 アダプターが、応答メッセージが戻るのを待つ最小時間 (ミリ秒単位)
TimeoutFatal
 
ResponseTimeout で指定された時間までに応答を受信できない場合、コネクターは APPRESPONSETIMEOUT をブローカーに戻す。これにより、通常、コネクターは終了する。 応答を受信できない場合、コネクターは要求に失敗するが (FAIL をブローカーに戻す)、終了はしない。

ターゲット宛先へのメッセージの配信は、以下の点を除いて、非同期処理の場合と同じです。

表 5. 宛先への同期配信
メタオブジェクト・プロパティー プロパティーが未定義の場合のデフォルト処置 プロパティーが定義されている場合に行われる処置
ReplyToDestination
 
非同期の場合と同じ コネクターは、要求メッセージのこのフィールドに、コネクター固有プロパティー ReplyToDestination の値を読み込む

コネクターは、メタオブジェクト属性 ResponseTimeout で指定された時間以上、ReplyToDestination で指定されたターゲット・アプリケーションからの応答メッセージを待ちます。応答がその時間内に戻らない場合、コネクターはタイムアウトになり、エラーを報告します。

応答基準

コネクターは、応答宛先の最初のメッセージが正しい応答メッセージであるとはみなしません。その代わり、JMS 要求応答規則に従って、要求のメッセージ ID に一致する相関 ID を持つ最初のメッセージを探します。つまり、要求メッセージを受信するアプリケーションは、要求メッセージ ID に等しい相関 ID を持つ応答メッセージを作成し、そのメッセージを、要求メッセージによって指定された応答宛先に置く必要があります。

すべてのアプリケーションが相関 ID を使用する規則に従って、要求メッセージと応答メッセージをマップするわけではありません。その場合、コネクターは、応答メッセージを識別するカスタム基準を受け入れます。

コネクターは、同期要求処理の対象となるビジネス・オブジェクトを受信するときに、動詞のアプリケーション固有情報に、名前と値のペア response_selector= が存在するかどうかを検査します。そのような名前と値のペアが存在しない場合、コネクターは、既に説明したように、メッセージ相関 ID を使用して応答メッセージを識別します。

応答セレクターの名と値のペアが定義されている場合、コネクターは、応答メッセージを識別できる、JMS メッセージ・セレクター・ストリングを表す値とみなします。以下にいくつかの使用例を示します。JMS メッセージ・セレクター構文の詳細については、JMS API 仕様を参照してください。JMS メッセージ・セレクター構文はコネクターによって解析されないことに注意してください。その代わり、構文は JMS プロバイダーによって解釈されます。 コネクターは、JMS プロバイダーが、メッセージをフィルタリングする手段としてセレクターを使用できるようにします (データベースのクエリーに類似)。

例えば、名前と値のペアが入った、次の動詞アプリケーション固有情報は、

response_selector=JMSType = 'xmlResponse'
 

応答メッセージが、セレクター・ストリング JMSType = 'xmlResponse' に一致しなければならないことをコネクターに知らせます。コネクターはこのセレクターを JMS プロバイダーに提供します。次に JMS プロバイダーは、配信された最初のメッセージを、メッセージの JMS タイプ・フィールド が xmlResponse に等しい応答宛先に戻します。

すべての場合で、メッセージ・セレクター・ストリングは、1 つだけの応答を一意に識別できなければなりません。応答セレクターの基準を満たした応答宛先に複数のメッセージが配信されると、アダプターは最初のメッセージのみを検索します。基準に一致する可能性のあるその他の応答メッセージは無視されます。

実行時にメッセージ・セレクターが固有なものになるように、コネクターは、メッセージ・セレクター自身への属性値の動的置換をサポートしています。これを行うには、応答セレクターで、整数を中括弧で囲んだ形式 ("{1}") のプレースホルダーを指定する必要があります。この後にコロンを置き、置換に使用する属性をコンマで区切ってリストしてください。プレースホルダーの整数は、置換に使用する属性に対する指標として機能します。

例えば、以下のメッセージ・セレクターでは、

response_selector=JMSCorrelationID LIKE '{1}':MyDynamicMO.CorrelationID
 

コネクターは、トークン {1} を、子オブジェクト MyDynamicMO の属性 CorrelationID の値で置き換えることを知らせます。 属性 CorrelationID123ABC の値を持つ場合、コネクターは、次のメッセージ・セレクターを生成し、それを使用します。

JMSCorrelation LIKE '123ABC'
 

下に示すように、複数の置換を指定することもできます。

response_selector=Name LIKE '{1}'AND Zip LIKE '{2}':PrimaryID,Address[4].AddressID
 

この例では、コネクターは、'{1}' を、トップレベル・ビジネス・オブジェクト の属性 PrimaryID の値で置き換え、'{2}' を、子コンテナー・オブジェクト Address の 5 番目 (ベース 0) にある AddressID の値で置き換えます。この方法では、応答メッセージ・セレクターでビジネス・オブジェクトおよびメタオブジェクトの任意の属性を参照できます。

メッセージ・セレクターでリテラル値「{」を指定するには、その代わりに「{{」を使用します。例えば、以下のセレクターでは、

response_selector=PrimaryID LIKE {{1}
 

アダプターは、これを以下のリテラル値として認識します。

PrimaryID LIKE {1}
 

この場合、コネクターは、値 '{1}' での置換は行いません。

コネクターは、属性値で「{」、「}」、「:」、「;」などの特殊文字を検出した場合は、それらの文字を照会ストリングに直接挿入します。これにより、アプリケーション固有情報の区切り文字としても機能する特殊文字を照会ストリングに含めることができます。例えば、以下のセレクターでは、

Response_selector=PrimaryID = '{1}':Foo
 

属性 Foo{A:B};{C:D} の値を持つ場合、以下のようなリテラル・メッセージ・セレクターに変換されます。

PrimaryID = '{A:B};{C:D}'
 

応答処理

応答メッセージを受け取ったときに行う処置を確認するために、コネクターは、コネクター・プロパティー MessageResponseResultProperty によって 指定された JMS 結果プロパティーを検査します。この JMS プロパティーの値によって、コネクターは、メッセージ本文にビジネス・オブジェクトとエラー・メッセージのどちらが含まれているかを予想します (下の表を参照)。すべての場合に、コネクターは対応する戻りコードをブローカーに戻します。メッセージで JMS 結果プロパティーが VALCHANGE に等しい場合、コネクターは、この表で説明された VALCHANGE についての処置を行い、ブローカー定数 VALCHANGE に対応した数値をブローカーに戻します。


表 6. 応答メッセージの処理
JMS 結果プロパティーの値 コネクターの処置
SUCCESS 要求ビジネス・オブジェクトを変更せず、単に、正常にブローカーに戻ります。
VALCHANGE
MULTIPLE_HITS
要求ビジネス・オブジェクトに応答メッセージ本文の内容を再び読み込みます。応答メッセージ本文が空の場合、要求ビジネス・オブジェクトは変更されません。
要求ビジネス・オブジェクトの動的メタオブジェクトに、応答メッセージの JMS ヘッダー・フィールドを再び読み込みます。
FAIL FAIL_RETRIEVE_BY_CONTENT BO_DOES_NOT_EXIST UNABLE_TO_LOGIN VALDUPES 応答にデータが読み込まれている場合、コネクターは応答をエラー・メッセージとみなし、それをブローカーに戻します。応答メッセージ本文が空の場合、コネクターは一般エラー・メッセージをブローカーに戻します。
APPRESPONSETIMEOUT APPRESPONSETIMEOUT がブローカーに戻ると、通常、アダプター・エージェントが終了する点を除いて、上記と同じです。
未定義または認識できない値 コネクターは要求に失敗します。

エラー処理

ターゲット宛先との間での要求メッセージの読み取りまたは書き込みのとき、または応答メッセージの検査のときに (該当する場合) エラーを検出すると、コネクターは、APPRESPONSETIMEOUT をすぐにブローカーに戻します。これにより、アダプターは終了するか、場合により再始動します。一般に、そのようなリカバリー不能エラーは、JMS プロバイダーへの接続が切断されたか、あるいはコネクターが認識できないか、認識してもリカバリー不能 (トランザクションの失敗など) とみなした、JMS プロバイダーによって 報告された内部エラーかのいずれかが原因です。

ビジネス・オブジェクトをメッセージに変換しているとき、またはその逆の変換のときにエラーを検出した場合 (データ・ハンドラーが無効なメッセージ・フォーマットを報告する場合など)、コネクターは要求に失敗し、理由を説明した該当するエラー・メッセージのログを記録します。

イベント失敗のシナリオを含む詳細については、エラー処理を参照してください。

Copyright IBM Corp. 2004