1

MQ では、既存のキュー マネージャーのインスタンスがある場合、アプリがアクセスできる queuemanager1 とします。queuemanager1 を介して別のキュー マネージャー queuemanager2 のキューを指すキューを作成することにより、メッセージを送信できます。これが行われるのは、アプリは qu​​euemanager2 に直接アクセスできない可能性がありますが、queumanager1 をホストする MQ サーバーはアクセスできるためです。

コードは次のようになります。

MQQueue destQueue = queuemanager1.accessQueue("queFromAnotherMngr",CMQC.MQOO_OUTPUT | CMQC.MQOO_FAIL_IF_QUIESCING,"queuemanager2", null, null);

JBoss AS 6 用の IBM MQ JCA アダプターを使用するようにコードをリファクタリングしています。そのため、接続を JBoss で管理するには、通常の JMS API (InitialContext JNDI ルックアップ、プロデューサーなどを使用) に固執する必要があると考えています。

しかし、通常の JMS で、受信側の MQ サーバーがメッセージを別のキューマネージャー (queuemanager2) の別のキューに転送できるようにする方法がわかりません。

これまで調べたところ、MQ に送信されるオブジェクトには Message Queueing Message Descriptor (MQMD) と呼ばれるものがあり、「ReplyToQMgr」と「ReplyToQ」というフィールドがあります。JCA アダプターで JMS API を使用してこれらのフィールドを更新する方法を見つけたら、解決策があると思います。何かご意見は？アイデア？提案？ソリューション？ありがとう！

4

1 に答える 1

1

ReplyTo フィールドを使用すると、リモート アプリケーションがメッセージを返信することができます。これらは、元のメッセージをルーティングする際に WebSphere MQ によって使用されるのではなく、確認応答と障害レポートのアドレス指定に使用されます。

JNDI ルックアップを使用してリモート QMgr でキューを指定する方法はQMNAME、キュー オブジェクトでフィールドを定義することです。WebSphere MQ オブジェクトでサポートされるすべてのプロパティーのリストについては、WebSphere MQ classes for JMS オブジェクトのプロパティーを参照してください。上の表で言及されていないのは、キューのプロパティが接続ファクトリQMNAMEのプロパティと一致する必要がないことです。QMNAMEこれらのプロパティが異なる場合、ローカル QMgr は、キュー オブジェクトが開かれたときにターゲット QMgr へのパスを解決しようとします。パスが見つかる限り (送信キューまたは QMgr エイリアスのいずれかがターゲット QMgr と同じ名前で存在する必要があります)、アプリが送信キューに対して承認されている限り、問題はありません。

JMS 例外を受け取った場合は、その存在を照会し、見つかったリンクされた例外を出力する必要があることに注意してください。これらには、問題が名前解決、承認、またはその他に関連しているかどうかをユーザーまたは管理者に通知する WMQ 理由コードがあります。これを行う方法に関する提案については、WebSphere MQ classes for JMS の例外を参照してください。これは WMQ 固有のアドバイスではないことに注意してください。JMS は、例外を報告するためのマルチレベル構造を指定します。リンクされた例外は、ベンダー固有のエラーが報告される場所です。したがって、 JMS アプリケーションは、使用されているトランスポート プロバイダーに関係なく、リンクされた例外を出力する必要があります。

于 2012-02-29T21:40:43.230 に答える