アダプターは、以下の 2 つの主要な操作をサポートします。
アダプターは、JMS プロバイダー (WebSphere MQ など) への接続を確立して両方の 操作を行い、次に JMS API を使用して以下のことを行います。
これらの 2 つの操作については、イベント・メッセージの処理 および 要求メッセージの処理 で詳しく説明します。
コネクターは、新しいメッセージが、1 つ以上の JMS 宛先に配信されているか定期的に検査します。 各ポーリング・サイクルで、コネクターは以下のことを行います。
これらのステップについては、図 1 に示されています。また、以下で詳しく説明されています。
各イベント・ポーリング・サイクル中に、コネクターは、コネクター・プロパティー InputDestination によって指定された宛先で、メッセージの非ブロッキング読み取りを行います (コネクター・プロパティーの詳細については、コネクター・プロパティーの構成を参照)。コネクターは、メッセージを検索してから、InterChange Server Express 統合ブローカーにそのメッセージを公表します。
コネクターは pollForEvents() メソッドを使用して、一定の間隔でポーリングしてメッセージの有無を確認します。 ポーリング・サイクルごとのメッセージ検索数は、コネクター・プロパティー PollQuantity に指定されている最大数に制限されます。 指定最大数に達する前に、すべての使用可能なメッセージを検索すると、コネクターは、それ以上のメッセージを待たずに、ポーリング・サイクルから即時に戻ります。
コネクター・プロパティー InputDestination で複数の宛先が指定されている場合、コネクターは、指定された各宛先をラウンドロビン方式でポーリングします。各宛先からの最大 PollQuanity 数のメッセージを検索し、Interchange Server Express 統合ブローカーに公表します。PollQuantity に指定されている最大数に達する前に すべての宛先が空になると、コネクターはポーリング・サイクルから即時に戻ります。
例えば、次のようなシナリオでは、
アダプターは、単一のポーリング・サイクルにおいて以下の順序でメッセージを検索します。
各キューから最大数 (PollQuanity で指定) の 2 つのメッセージ をポーリングしたので、アダプターはポーリング・サイクルから戻ります。
イベント・メッセージの検索はトランザクションの一部です。 トランザクションをコミットする前にコネクターが予期せずに終了する場合、トランザクションはロールバックされ、元のメッセージが復元されます。コネクター・フレームワークは現在分散トランザクションをサポートしていないので、コネクターは、InterChange Server Express 統合ブローカーにイベントを公表したとしても、InterChange Server Express 統合ブローカーからの確認通知を受信する前に、予期せずに終了するか通信を切断する場合があります。この場合、イベントが統合ブローカーに受信されたかどうかは、コネクターが入手できる情報からは確認できません。 イベント・メッセージを失わないようにするために、統合ブローカーからのイベントの受取を確認する応答を受信するまでは、コネクターはトランザクションをコミットしません。 コネクターがイベントを公表し、確認通知を受信するまでの間に障害が発生すると、トランザクションは自動的にロールバックされ、元のメッセージが復元されます。 メッセージが統合ブローカーによって処理されたかどうかがわからないため、そのようなイベントは未確定イベントと呼ばれます。
再始動時に、コネクターは、入力宛先からのメッセージの処理を開始し、未確定イベントを再サブミットします。この方式を使用すると、イベントを失うリスクはなくなりますが、同じイベントが 2 回公表される可能性は避けられません。
重複イベント配信のリスクを軽減したり、なくしたりする方法には、次の 2 つの方法があります。進行中の宛先の使用 (進行中の宛先によるリカバリーを参照) または 保証付きイベント・デリバリーの使用 (保証付きイベント・デリバリーによるリカバリーを参照) です。
未確定イベントの処理を制御するには、コネクター・プロパティー InProgressDestination を指定して、別個の一時宛先を作成します。
統合ブローカーにイベントを公表する前に、コネクターは、イベント・メッセージを入力宛先から進行中の宛先へ移動します。 ブローカーから確認通知を受信したら、コネクターは、進行中の宛先からメッセージを削除します。これによって、処理されていない未確定メッセージを 分離できます。始動時に進行中の宛先にメッセージがあった場合、コネクターは、これらのメッセージは、予期せずに終了したコネクターの以前のインスタンス から残されたものであるとみなすことができるため、安全です。 そのようなメッセージに、コネクターが別の処置を行うように指定できます (重複イベント通知 が受諾不能な場合)。これを行うには、以下の 4 つのオプションのいずれかを、コネクター構成プロパティー InDoubtEvents に指定します。
詳細については、InDoubtEventsを参照してください。
保証付きイベント・デリバリー機能により、コネクター・フレームワークは、イベントが逸失したり、イベントが 2 度送信されたりするのを防ぐことができます。 コネクター・フレームワークは、コンテナー管理イベント (CME) および重複イベント除去 (DEE) の、2 つの機構によって保証付きイベント・デリバリーをサポートします。
コネクターが PTP スタイル・メッセージングに構成されている場合に、CME を使用できます。CME を使用するには、WebSphere MQ を JMS プロバイダーにして、送信元キューと宛先キューを 1 つのキュー・マネージャーに置く必要があります。
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 つのルールに一致させることができる場合、コネクターは、ビジネス・オブジェクトの新しいインスタンスを作成し、それをメッセージ本文と一緒に、ルールで指定されたデータ・ハンドラーに渡すことによって、このビジネス・オブジェクトを書き取らせます。データ・ハンドラーがルールに指定されていない場合、コネクターは、コネクター構成プロパティーで指定されたデフォルトのデータ・ハンドラーを 使用します。
アダプターが、イベント・メッセージを複数のルールに一致させることができる場合、または 1 つのルールにも一致させることができない場合、コネクターは、コネクター構成プロパティーで指定されたデータ・ハンドラーにメッセージ本文のみを渡すことによって、データ・ハンドラーが、ビジネス・オブジェクト・タイプを決定できるようにします。
イベント・メッセージをビジネス・オブジェクトに変換するために、コネクターは、ビジネス・オブジェクトに関するメタデータとメッセージに関するメタデータを 比較し、それらをマッピングします。メタデータおよびメタオブジェクトで説明したように、ビジネス・オブジェクトに関するメタデータは、ビジネス・オブジェクト定義 (アプリケーション固有情報 および子動的メタオブジェクト)、コネクター・プロパティー、および静的メタオブジェクトの中にあります。 メッセージ・メタデータはメッセージ・ヘッダーの中にあります。
トランスポート固有メッセージ・ヘッダー情報へアクセスしたり、メッセージ・トランスポートの詳細情報を入手したり、それを詳細に制御したりするには、ビジネス・オブジェクト定義の子である動的メタオブジェクトに属性を追加します。 属性を追加すると、メッセージ・ヘッダーから読み取りができるようになり、オプションで書き込みもできるようになるため、メッセージ・メタデータを変更できるようになります。 そのような変更では、JMS プロパティーを変更したり、要求ごとに宛先を制御 したり (アダプター・プロパティーで指定されたデフォルトの宛先を使用せずに)、メッセージの CorrelationID を再ターゲットしたりできます。ビジネス・オブジェクト定義 の子である動的メタオブジェクトにそのようなプロパティーを指定すると、コネクターは、メッセージ・ヘッダーでそれらに対応するものをチェックし、メッセージ・ヘッダーの内容に基づいて、動的メタオブジェクトにデータを取り込みます。 1 つまたはすべてのサポートされた動的メタオブジェクト属性を定義できます。コネクターはそれに従って、メタオブジェクトにデータを取り込みます。読み取りまたは書き込み ができるメッセージ・ヘッダー・プロパティーのリストを含め、詳細については、ポーリング時の動的子メタオブジェクトの取り込みを参照してください。
コネクター固有プロパティー ArchiveDestination を指定すると、コネクターは、正常に処理されたすべてのメッセージのコピーをこの宛先に置きます。 ArchiveDestination が未定義の場合、正常に処理されたメッセージは廃棄されます。 詳細については、コネクター固有プロパティーの構成を参照してください。
入力宛先からの読み取りでエラーを検出すると、コネクターは、定数値 APPRESPONSETIMEOUT をすぐに統合ブローカーに戻します。これにより、コネクターは終了し、場合により再始動します。 一般に、そのようなリカバリー不能エラーは、JMS プロバイダーへの接続が切断されたか、あるいはコネクターが認識できないか、認識しても リカバリー不能 (トランザクションの失敗など) とみなした、JMS プロバイダーによって 報告された内部エラーかのいずれかが原因です。
インバウンド・メッセージをイベント・ビジネス・オブジェクトに変換しているときにエラーを 検出した場合 (データ・ハンドラーが無効なメッセージ・フォーマットを報告する場合など)、コネクターはイベントに失敗し、理由を説明する該当するエラー・メッセージのログを記録します。 コネクター・プロパティー ErrorDestination が定義されており、有効な場合、コネクターは、失敗したメッセージのコピーをこのエラー宛先に置きます。そうでない場合、メッセージは廃棄されます。
コネクターがイベント・ビジネス・オブジェクトを公表した後に統合ブローカーがエラーを 報告した場合、コネクターはイベントに失敗し、統合ブローカーによって報告されるエラー・メッセージ のログを記録します。 コネクター・プロパティー ErrorDestination が定義されており、有効な場合、コネクターは、失敗したメッセージのコピーをこの宛先に置きます。そうでない場合、メッセージは廃棄されます。
メッセージのビジネス・オブジェクトを決定できない場合、またはメッセージを統合ブローカーに 公表しても、統合ブローカーがそのメッセージはサポートされていないと報告した場合、コネクターは、メッセージはアンサブスクライブされているとみなします。 コネクター・プロパティー UnsubscribedDestination が定義されており、有効な場合、コネクターは、アンサブスクライブされたメッセージのコピーをこの宛先に置きます。そうでない場合、メッセージは廃棄されます。
ビジネス・オブジェクト要求がコネクターに送信されると、コネクターは、ターゲット宛先で新しいメッセージを作成します。メッセージ・ヘッダーには、要求メタオブジェクトで指定されたユーザー定義の値とコネクター・プロパティーによって 指定されたデフォルト・パラメーターを組み合わせたデータが読み込まれます。 メッセージの本文には、構成されたデータ・ハンドラーを介して要求ビジネス・オブジェクト を渡すことによって生成された結果内容のデータが取り込まれます。
図 2 に、メッセージ要求通信を示します。doVerbFor() メソッドが統合ブローカーからビジネス・オブジェクトを受信すると、コネクターはビジネス・オブジェクトをデータ・ハンドラーに渡します。 データ・ハンドラーはビジネス・オブジェクトを適切なテキストに変換し、コネクターはそれをメッセージとして宛先に発行します。
要求の処理では、コネクターは 2 つのタイプの処置を行うことができます。 1 つ目は下記で非同期処理として説明するものであり、コネクターはメッセージを ターゲット宛先に置いて、正常に戻ります。 一般に、これは「応答不要送信」と呼ばれます。 2 つ目は下記で同期処理として説明するものであり、コネクターはメッセージを 同じようにターゲット宛先に置きますが、ターゲット・アプリケーションによって応答が 戻されるのも待ちます。
処理モードは数値プロパティー ResponseTimeout によって決まります。これは、ビジネス・オブジェクト要求の動的メタオブジェクトまたは静的メタオブジェクト のいずれかで指定されます。このプロパティーが定義されていないか、-1 に設定されている場合、コネクターは要求を非同期的に配信します。このプロパティーが 0 以上の場合、アダプターは、要求を同期的に処理し、ターゲット・アプリケーションが応答メッセージを戻すのを そのミリ秒以上待ちます。図 2 に示した要求処理を、以下で詳しく説明します。
コネクターは、要求ビジネス・オブジェクトで指定される動詞にセマンティック値は置きません。 コネクターは同じ処置を行います。つまり、指定される動詞に関係なく、メッセージを JMS 宛先に置きます。
非同期処理では、コネクターは要求ビジネス・オブジェクトをメッセージに変換し、そのメッセージをターゲット宛先に置いてから、すぐに統合ブローカーに戻ります。 要求が成功するか失敗するかは、すべて、メッセージを JMS 宛先に 置くコネクターの能力に基づいています。この配信が成功しても、ターゲット・アプリケーション にメッセージがあるわけでもメッセージを受信するわけでもないことに注意してください。 メッセージング・システムが非同期的性質を持つ場合、ターゲット・アプリケーションがメッセージを処理できるようになるまで、または有効期限切れになる (そのように構成されている場合) まで、メッセージは JMS プロバイダーに無期限にとどまる場合があります。
コネクターはまず、構成されたデータ・ハンドラーを使用して、要求ビジネス・オブジェクトをテキストにシリアライズします。コネクターは、以下に指定されたデータ・ハンドラーを使用します (優先順)。
コネクターは、シリアライズされたビジネス・オブジェクト・データの入った 新しいメッセージをメッセージの本文として作成します。コネクターは、以下の表の説明に 従って、メッセージ・ヘッダーにデータを読み込みます。動的メタオブジェクトまたは静的メタオブジェクト のどちらにおいてもプロパティーを指定できるすべての場合で、動的メタオブジェクトで指定された値は、静的メタオブジェクトで指定された値に優先します。メタオブジェクトで指定できるプロパティーの 説明およびリストについては、メタオブジェクトの構成を参照してください。
メタオブジェクトの次の属性が、メッセージの配信方法を決めます。
メタオブジェクト・プロパティー | プロパティーが未定義の場合のデフォルト処置 | プロパティーが定義されている場合に行われる処置 |
OutputDestination |
値が必要 | メッセージのターゲット宛先 |
DeliveryMode |
コネクターは、JMS プロバイダーがメッセージ・パーシスタンスを 書き取らせることができるようにする | コネクターは、ユーザーの指示に従って、メッセージを永続的または非永続的に 書き込む |
コネクターが、要求メッセージを出力 (ターゲット) 宛先に正常に配信できたか どうかによって、以下のいずれかのコードが統合ブローカーに戻されます。
同期処理では、コネクターは要求をターゲット宛先へ配信してから、2 番目の宛先で応答メッセージを待ちます。要求メッセージの作成は非同期処理の場合と同じです。 ただし、コネクターは、メタオブジェクトの以下の追加属性もチェックします。
ターゲット宛先へのメッセージの配信は、以下の点を除いて、非同期処理の場合と同じです。
メタオブジェクト・プロパティー | プロパティーが未定義の場合のデフォルト処置 | プロパティーが定義されている場合に行われる処置 |
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 の値で置き換えることを知らせます。 属性 CorrelationID が 123ABC の値を持つ場合、コネクターは、次のメッセージ・セレクターを生成し、それを使用します。
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 に対応した数値を統合ブローカーに戻します。
JMS 結果プロパティーの値 | コネクターの処置 |
SUCCESS | 要求ビジネス・オブジェクトを変更せず、単に、正常に統合ブローカーに戻ります。 |
VALCHANGE
MULTIPLE_HITS 未定義の値 |
要求ビジネス・オブジェクトに応答メッセージ本文の内容を再び読み込みます。
応答メッセージ本文が空の場合、要求ビジネス・オブジェクトは変更されません。
要求ビジネス・オブジェクトの動的メタオブジェクトに、応答メッセージの JMS ヘッダー・フィールドを再び読み込みます。 |
FAIL FAIL_RETRIEVE_BY_CONTENT BO_DOES_NOT_EXIST UNABLE_TO_LOGIN VALDUPES | 応答にデータが読み込まれている場合、コネクターは応答をエラー・メッセージとみなし、それを統合ブローカーに戻します。 応答メッセージ本文が空の場合、コネクターは一般エラー・メッセージを統合ブローカーに 戻します。 |
APPRESPONSETIMEOUT | APPRESPONSETIMEOUT がブローカーに戻ると、通常、アダプター・エージェントが終了する点を除いて、上記と同じです。 |
認識されない値 | コネクターは要求に失敗します。 |
ターゲット宛先との間での要求メッセージの読み取りまたは書き込みのとき、または応答メッセージの検査のときに (該当する場合) エラーを検出すると、コネクターは、APPRESPONSETIMEOUT をすぐに統合ブローカーに戻します。これにより、アダプターは終了するか、場合により再始動します。一般に、そのようなリカバリー不能エラーは、JMS プロバイダーへの接続が切断されたか、あるいはコネクターが認識できないか、認識しても リカバリー不能 (トランザクションの失敗など) とみなした、JMS プロバイダーによって 報告された内部エラーかのいずれかが原因です。
ビジネス・オブジェクトをメッセージに変換しているとき、またはその逆の変換 のときにエラーを検出した場合 (データ・ハンドラーが無効なメッセージ・フォーマットを報告する場合など)、コネクターは要求に失敗し、理由を説明した該当するエラー・メッセージのログを記録します。
イベント失敗のシナリオを含む詳細については、エラー処理を参照してください。