JAX-RPC 1.1を使用して、WAS 6.0で実行され、WebsphereMQを介して通信する一連のアプリケーションのサービスを生成しています。メインフレームはサービスにメッセージを送信するため、何らかの理由でメッセージをオブジェクトに変換できない場合（EBCDICからASCIIへの奇妙さなどが原因）、メッセージは検査のためにデッドレターキューに配置する必要があります。 。
これを行うための標準的な方法があるかどうか（つまり、jms：/アドレスにDLQ名を指定することによって）、またはDLQ転送を何らかの方法で手動で実行する必要があるかどうかを誰かが知っていますか？
まず、DLQ に頼らないことをお勧めします。DLQ は、チャネルが解決できないメッセージを格納するために使用される QMgr レベルのリソースです。これは潜在的な攻撃ベクトルであるため、ほとんどのセキュリティ意識の高いショップはアプリケーションへのアクセスを許可しないか、許可したとしてもプットのみのアクセスです。
これを行う最善の方法は、アプリ固有の例外キューを作成することです。アプリに複数の入力キューがある場合、それらはすべて同じ例外キューを使用できるため、アプリケーション サポート チームはそこに到着するメッセージをセキュリティの問題なしで管理できます。
どちらの方法でも、アプリにこれを尊重させるのは非常に簡単です。たとえば、アプリが JAX.SVC.REQUEST から読み取っているとします。例外キューを定義し、BOQ* フィールドを指定します。
DEF QL(JAX.SVC.EXCEPTION) ALTER QL(JAX.SVC.REQUEST) BOQNAME(JAX.SVC.EXCEPTION) BOQTHRESH(5)
JMS クラスは、キューが開かれたときにキューの BOQ* 属性を照会し、読み取られた各メッセージのバックアウト カウントをチェックします。プログラムでトランザクション セッションを使用し、メッセージを処理できない場合は、session.backout() メソッドを呼び出します。メッセージは BOTHRESH 回まで読み取られてバックアウトされ、BOQNAME で指定されたキューに再キューイングされます。そのキューがいっぱいであるか利用できない場合、DLQ が試行されます。それが失敗した場合、クラスは例外をスローします。
たとえば、QMgr がシャットダウンされた場合に、処理可能なメッセージがバックアウトされる可能性を考慮して、BOTHRESH > 1 を選択します。
私は通常、例外キューをトリガーして、何かが発生した場合にアラームを発生させたり、電子メールを送信したりできるようにします。監視ツールがある場合は、代わりに深さ > 0 を確認できます。
何らかの理由で、JMS 機能を使用してメッセージを自動的に再キューイングしたくない場合は、アプリケーションでメッセージを再キューイングするためのロジックが必要になります。メッセージを DLQ に配置する場合は、DLQ ヘッダーを先頭に追加する必要があります。そうしないと、DLQ ハンドラーまたはそのキューを監視している他のインストルメンテーションが壊れる可能性があります。