アダプターでの処理の概要

アダプターは、Java Message Service (JMS) の IBM による WebSphere MQ インプリメンテーションを使用します。 JMS は、エンタープライズ・メッセージング・システムにアクセスするためのオープン・スタンダード API です。JMS は、ビジネス・アプリケーションがデータとイベントを非同期的に送受信できるように設計されています。

アダプターは、WebSphere Business Integration Message Broker と直接相互作用しません。 コネクターを構成する際には、WebSphere Business Integration Message Broker メッセージ・フローの入力ノードおよび出力ノードとして WebSphere MQ キューをセットアップします。アダプターは、このメッセージ・フローが配置されているメッセージ・ブローカーをホスティングしている WebSphere MQ キュー・マネージャーと通信します。

メッセージ要求

図 2 に、アダプターのランタイム・コンポーネントであるコネクターが行うメッセージ要求の通信を示します。doVerbFor() メソッドがコラボレーションからビジネス・オブジェクトを受け取ると、コネクターはそのビジネス・オブジェクトをデータ・ハンドラーに渡します。 データ・ハンドラーはそのビジネス・オブジェクトを適したメッセージに変換し、キューに送ります。 このとき、JMS 層は適切な呼び出しを実行してキュー・セッションを開き、メッセージの経路を指定します。コネクターは、要求を非同期的に送出する (応答不要送信を行う) ように構成できます。 また、要求を同期的に処理できるようにコネクター・プロパティーを構成することもできます。

図 2. メッセージ要求の処理

コネクターは、コラボレーションから渡されたビジネス・オブジェクトを、各ビジネス・オブジェクトの動詞に基づいて処理します。 コネクターはビジネス・オブジェクト・ハンドラーと doVerbFor() メソッド を使用して、コネクターがサポートするビジネス・オブジェクトを処理します。コネクターは、以下のビジネス・オブジェクトの動詞をサポートします。

注:
Create 動詞、Update 動詞、および Delete 動詞を持つビジネス・オブジェクトは、非同期的にも同期的にも送信できます。デフォルト・モードは非同期送信です。コネクターは、Retrieve 動詞、Exists 動詞、Retrieve by Content 動詞のビジネス・オブジェクトの非同期送信をサポートしません。 したがって、Retrieve 動詞、Exists 動詞、または Retrieve by Content 動詞のデフォルト・モードは同期送信です。

Create、Update、および Delete

Create 動詞、Update 動詞、および Delete 動詞を持つビジネス・オブジェクトの処理は、ビジネス・オブジェクトが非同期的に送信されたか同期的に送信されたかによって決まります。

非同期送達

これは、Create 動詞、Update 動詞、および Delete 動詞を持つビジネス・オブジェクトのデフォルト送信モードです。 データ・ハンドラーを使用して、ビジネス・オブジェクトからメッセージが作成され、出力キューに書き込まれます。メッセージがデリバリーされると、コネクターは SUCCESS を戻します。それ以外の場合は FAIL を戻します

注:
コネクターには、メッセージが受信されたかどうか、または、処置が行われたかどうかを確認する方法はありません。
同期送達

コネクター固有のプロパティーで ReplyToQueue が定義されており、かつビジネス・オブジェクトの メタオブジェクト変換プロパティーに responseTimeout が存在する場合、コネクターは同期モードで要求を送信します。 続いて、コネクターは、受信側のアプリケーションで適切な処置が行われたかどうかを確認するために応答を待ちます。

WebSphere Integration Message Broker の場合、コネクターは最初に、表 2 に示すヘッダーを持つメッセージを発行します。

表 2. 要求メッセージ記述子ヘッダー (MQMD)
フィールド 説明
Format フォーマット名 メタオブジェクト変換プロパティーに定義されている出力フォーマット。IBM の要件に合わせて、8 文字を超える部分が切り捨てられます (例 : MQSTR)
MsgType メッセージ・タイプ MQMT_DATAGRAM*
Report 要求されたレポート・メッセージのオプション 応答メッセージの返送が予測される場合、このフィールドには次の値が取り込まれます。処理が成功したときに肯定処理レポートが必要な場合は、MQRO_PAN*。処理が失敗したときに否定処理レポートが必要な場合は、MQRO_NAN*。生成されるレポートの相関 ID が最初に発行された要求のメッセージ ID と同じになる必要がある場合は、MQRO_COPY_MSG_ID_TO_CORREL_ID*
ReplyToQ 応答キューの名前 応答メッセージの返送が予測される場合、このフィールドにはコネクター・プロパティー ReplyToQueue の値が取り込まれます。
Persistence メッセージのパーシスタンス MQPER_PERSISTENT*
Expiry メッセージの存続時間 MQEI_UNLIMITED*

* は、IBM によって定義される定数を示します。

表 2 に示すメッセージ・ヘッダーの後に、メッセージ本文が続きます。メッセージの本文は、データ・ハンドラーを使用して直列化されたビジネス・オブジェクトです。

Report フィールドは、受信側アプリケーションから肯定処理レポートと否定処理レポートの両方の返送が予測されることを示すために設定されます。メッセージを発行したスレッドは、受信側アプリケーションが要求を処理できたかどうかを示す応答メッセージを待ちます。

アプリケーションがコネクターから同期要求を受け取ると、アプリケーションはビジネス・オブジェクトを処理し、表 3表 4、および 表 5 に示すレポート・メッセージを発行します。

表 3. 応答メッセージ記述子ヘッダー (MQMD)
フィールド 説明
Format フォーマット名 変換プロパティー内で定義された busObj の入力フォーマット
MsgType メッセージ・タイプ MQMT_REPORT*

* は、IBM によって定義される定数を示します。

表 4. 応答メッセージに含まれるデータ
動詞 Feedback フィールド メッセージの本文
Create、Update、または Delete

SUCCESS

VALCHANGE

(オプション) 変更を反映する、直列化されたビジネス・オブジェクト。

VALDUPES

FAIL

(オプション) エラー・メッセージ。

表 5. WebSphere Integration Message Broker フィードバック・コードと WebSphere Business Integration システムの応答値
WebSphere Integration Message Broker フィードバック・コード 対応する WebSphere Business Integration システムの応答*
MQFB_PAN または MQFB_APPL_FIRST SUCCESS
MQFB_NAN または MQFB_APPL_FIRST + 1 FAIL
MQFB_APPL_FIRST + 2

VALCHANGE

MQFB_APPL_FIRST + 3

VALDUPES

MQFB_APPL_FIRST + 4

MULTIPLE_HITS

MQFB_APPL_FIRST + 5

FAIL_RETRIEVE_BY_CONTENT

MQFB_APPL_FIRST + 6

BO_DOES_NOT_EXIST

MQFB_APPL_FIRST + 7 UNABLE_TO_LOGIN (この応答後、コネクター・エージェントは即時に終了します)
MQFB_APPL_FIRST + 8 APP_RESPONSE_TIMEOUT

* 詳細については、「コネクター開発ガイド」を参照してください。

ビジネス・オブジェクトを処理できる場合、アプリケーションは、feedback フィールドが MQFB_PAN (または特定の WebSphere Business Integration システムの値) に設定されたレポート・メッセージを作成します。また、オプションで、アプリケーションはすべての変更を含む直列化されたビジネス・オブジェクトをメッセージ本文に取り込みます。 ビジネス・オブジェクトを処理できない場合、アプリケーションは、feedback フィールドが MQFB_NAN (または特定の WebSphere Business Integration システムの値) に設定されたレポート・メッセージを作成します。オプションで、このレポート・メッセージの本文にエラー・メッセージを含めることもできます。どちらの場合でも、アプリケーションはメッセージの correlationID フィールドをコネクター・メッセージの messageID に設定し、ReplyToQueue フィールドで指定されたキューにメッセージを発行します。

コネクターは、応答メッセージを取り出すと、デフォルトにより応答の correlationID を要求メッセージの messageID と突き合わせます。続いて、要求を発行したスレッドに通知を送信します。コネクターは、応答の feedback フィールドの設定によって、メッセージの本文にビジネス・オブジェクトとエラー・メッセージのどちらが含まれているかを予測します。ビジネス・オブジェクトが含まれていると予測したにもかかわらず、メッセージの本文にビジネス・オブジェクトが取り込まれていなかった場合、コネクターは InterChange Server が要求操作のために最初に発行したのと同じビジネス・オブジェクトを単純に返送します。エラー・メッセージが含まれていると予測したにもかかわらず、メッセージの本文にエラー・メッセージが取り込まれていなかった場合、InterChange Server には応答コードと汎用エラー・メッセージが返送されます。ただし、メッセージ選択子を使用して識別やフィルター操作を行うこともできま す。あるいは、アダプターが特定の要求に対して応答メッセージを識別する方法を制御できます。このメッセージ選択子機能は JMS 機能です。この JMS 機能は同期要求処理にのみ適用されます。以下に詳細を説明します。

Retrieve、Exists、および Retrieve by content

Retrieve 動詞、Exists 動詞、および Retrieve By Content 動詞を持つビジネス・オブジェクトは、同期送信のみをサポートします。 コネクターは、これらの動詞を持つビジネス・オブジェクトを、Create 動詞、Update 動詞、および Delete 動詞に対して定義されている同期送信と同様に処理します。 ただし、Retrieve 動詞、Exists 動詞、および Retrieve By Content 動詞を使用する場合には、responseTimeoutreplyToQueue が必要です。 さらに、Retrieve By Content 動詞と Retrieve 動詞の場合、トランザクションを完了するためにはメッセージの本文に直列化されたビジネス・オブジェクトが取り込まれている必要があります。

表 6 に、これらの動詞に対応する応答メッセージを示します。

表 6. 応答メッセージへの取り込み
動詞 Feedback フィールド メッセージの本文
Retrieve または RetrieveByContent

FAIL FAIL_RETRIEVE_BY_CONTENT

(オプション) エラー・メッセージ。

MULTIPLE_HITS SUCCESS

直列化されたビジネス・オブジェクト。
Exist

FAIL

(オプション) エラー・メッセージ。

SUCCESS

イベント処理

図 3 に、コネクターでのイベント処理を示します。pollForEvents() メソッドは、次の該当するメッセージを入力キューから検索します。 メッセージは実行中のキューに入れられ、処理が完了するまでキュー内に残ります。 コネクターは最初に、コネクター・メタオブジェクトを使用して、そのメッセージ・タイプがサポートされているかどうかを調べます。 サポートされている場合、コネクターは構成されているデータ・ハンドラー にメッセージを渡し、データ・ハンドラーがそのメッセージをビジネス・オブ ジェクトに変換します。設定される動詞には、そのメッセージ・タイプに対して定義されている変換プロパティーが反映されます。次に、コネ クターは、そのビジネス・オブジェクトがコラボレーションによってサブスク ライブされているかどうかを調べます。サブスクライブされている場合、gotApplEvents() メソッドがビジネス・オブジェクトを統合ブローカーにデリバリーし、実行中のキューからメッセージが削除されます。

コネクターは、イベント通知のために、データベース・トリガーではなくアプリケーションによってキューに書き込まれたイベントを検出します。イベントは、アプリケーションまたはその他の MQ 対応ソフトウェアが WebSphere MQ メッセージを生成して MQ メッセージ・キューに格納するときに発生します。

図 3. アプリケーションとコネクターの間の通信方法: メッセージ戻り

検索

コネクターは、pollForEvents() メソッドを使用して MQ キューからメッセージを定期的にポーリングします。 メッセージを検出すると、コネクターはそれを MQ キューから検索して調べ、メッセージのフォーマットを判別します。フォーマットがコネクター・メタオブジェクト内で定義されている場合、コネクターはデータ・ハンドラーを使用して適切な動詞付きのビジネス・オブジェクトを生成します。イベント失敗のシナリオについては、エラー処理の概要を参照してください。

コネクターは、最初に入力キューとのトランザクション・セッションを開いて、メッセージを処理します。このトランザクション・アプローチを使用すると、コネクターがビジネス・オブジェクトを正常にサブミットしたにもかかわらず、キューでトランザクションをコミットできなかった場合に、コラボレーションにビジネス・オブジェクトが 2 回デリバリーされるという可能性が少し残ります。この問題を回避するために、コネクターは、すべてのメッセージを進行中キューに移動します。 メッセージは、処理が完了するまでキュー内に残ります。処理中にコネクターが予期しないエラーでシャットダウンした場合、メッセージは元の入力キューには戻されず、実行中のキュー内に残ります。

注:
JMS サービス・プロバイダーとのトランザクション・セッションでは、キュー上の要求されたすべての処理が、キューからイベントが削除される前に実行され、コミットされる必要があります。したがって、コネクターがキューからメッセージを検索するときには、次の 3 つの処理が実行されるまでは検索がコミットされません。1) メッセージからビジネス・オブジェクトへの変換、2) gotApplEvents() メソッドによる、InterChange Server へのビジネス・オブジェクトのデリバリー、および 3) 戻り値の受信。

リカバリー

コネクターは初期化の際に実行中のキューを調べ、コネクターのシャットダウンが原因で未処理のまま残っているメッセージがないかどうかを調べます。コネクターの構成プロパティー InDoubtEvents を使用すると、そのようなメッセージのリカバリー処理に関する 4 つのオプション (fail on startup、reprocess、ignore、または log error) のうち、いずれかを指定できます。

Fail on startup

fail on startup オプションを指定した場合、コネクターが初期化の際に実行中のキュー内でメッセージを検出すると、コネクターはエラーを記録し、即時にシャットダウンします。ユーザーまたはシステム管理者は、検出されたメッセージを調べ、これらのメッセージを完全に削除するかまたは別のキューに移動するなどの適切な処置を取る必要があります。

Reprocess

reprocessing オプションを指定した場合、コネクターが初期化の際に実行中のキュー内でメッセージを検出すると、コネクターは以降のポーリングでそのメッセージを最初に処理します。実行中のキュー内にあったすべてのメッセージの処理が完了すると、コネクターは入力キューからのメッセージの処理を開始します。

Ignore

ignore オプションを指定した場合、初期化の際にコネクターが実行中のキュー内でメッセージを検出すると、コネクターはそれを無視しますが、シャットダウンはしません。

Log error

log error オプションを指定した場合、初期化の際にコネクターが実行中のキュー内でメッセージを検出すると、コネクターはエラーを記録しますが、シャットダウンはしません。

アーカイブ

コネクター固有のプロパティー ArchiveQueue が指定されており、かつ有効なキューを示している場合には、コネクターは正常に処理されたすべてのメッセージのコピーをアーカイブ・キューに格納します。 ArchiveQueue が未定義の場合、メッセージは処理後に破棄されます。アンサブスクライブされたメッセージまたはエラーを含むメッセージのアーカイブの詳細については、エラー処理の概要を参照してください。

注:
JMS 規則により、検索したメッセージを即時に別のキューに送信することはできません。メッセージをアーカイブして再デリバリーできるようにするために、コネクターは、オリジナルのメッセージから本文とヘッダー (該当する場合のみ) を複製した第 2 のメッセージを最初に生成します。JMS サービス・プロバイダーとの競合を避けるため、JMS に必須フィールドのみが複製されます。したがって、format フィールドは、アーカイブまたは再デリバリーされるメッセージにコピーされる唯一の追加メッセージ・プロパティーとなります。

Copyright IBM Corp. 2003, 2005