WebSphere Business Integration Event Broker 内の パブリッシュ/サブスクライブ は、ワークベンチ から管理され、 トポロジーまたは階層においてブローカーを接続したり、トピック・ベースのセキュリティーを管理したりするのに使用されます (ユーザー・ネーム・サーバー が使用中の場合)。他のワークベンチの変更と同じように、加える変更をデプロイして、更新がブローカーに送信されるようにする必要があります。
このセクションでは、パブリッシュ/サブスクライブ の使用中に生じる可能性のある共通問題のいくつかについて概説します。このセクションには、以下の問題を処理するためのアドバイスが含まれます。
BIP8303W: The Broker's user/group cache is empty. BIP8303W: The Broker's user/group cache is empty.
+() 0 BIP8204I: User Name Server is registering a client with UUID 15db2a8e-869e-11d5-8000-091465ac0000, and cache version 0.
これはサブスクライバーに対しては常に可能ですが、パブリッシャー側では、アプリケーションの作成に関する知識がない状態で、メッセージが発行されることがあります (たとえば、入力ノードでデフォルトのトピック・プロパティーを使用することによって)。そのメッセージの処理結果は、依然としてユーザー・トレースにログ記録されており、何が起きているかを知る手掛かりとなる場合があります。
アプリケーションが応答を要求していない場合 (つまり、メッセージ・タイプ MQMT_REQUEST を使用していない場合)、これを実行することを考慮します。アプリケーションを開発する場合は特にそうです。
サブスクライバーにメッセージが送信されるのは、それらがトピック、およびサブスクリプション・ポイント、およびフィルターと一致している場合のみです。サブスクリプション・ポイントは、パブリケーション・メッセージ内ではなくメッセージ・フローで指定されるため、間違ったメッセージ・フロー設定によって予期しない障害が発生する可能性があります。
さらに、ユーザー・トレースは、フィルターが使用されている場合、これが予期されるとおりに評価されているかどうかを表示します。
複数の実行グループまたは複数のブローカーを使用している場合は、さらに複雑です。 応答は、メッセージがターゲット実行グループによって処理されると、サブスクライバーに送信されます。 他の実行グループ (およびブローカー) は非同期的に更新されます。 結果として、他の場所で作成されたパブリケーションを受け取るまでの遅延が生じる可能性があります。 ブローカーがビジーの場合、メッセージが完全に処理されるまでの遅延が生じる可能性があります。 複数ブローカーのセットアップで、通信が中断された場合、サブスクリプションの変更はブローカーのネットワークを介して伝搬されます。 チャネルをチェックします。
複数の実行グループまたはブローカーを使用した場合、負荷が大きいと、中間 WebSphere MQ キューを充てんすることができる場合があります。これは、syslog に (ブローカーが、キューがいっぱいで書き込むことができない場合)、または WebSphere MQ ログに (チャネル経由で受け取るメッセージを、宛先キューがいっぱいで書き込むことができない場合) 報告されます。このタイプのメッセージを参照するには、すべてのキュー・マネージャーでキュー項目数を表示して、いっぱいになりそうなキューがないかどうかをチェックします。
始動後に BIP8303 エラーがブローカーのログに記録された場合、これはユーザー・ネーム・サーバーに通信問題があることを示しています。 ユーザー・ネーム・サーバーとやりとりするWebSphere MQ チャネルをチェックして、再試行してください。構成マネージャー とブローカーの両方でイベント・メッセージ BIP8204I を参照する必要があります。 このメッセージは、これらが両方ともユーザー・ネーム・サーバーに正常に登録されていることを示します。
パブリッシュ/サブスクライブ 要求が失敗して、 イベント BIP7017 が記録された場合、 クライアントのユーザー ID が、 ユーザー・ネーム・サーバーが実行しているシステムに認識されていることを確認します。また、Windows ドメイン環境で操作している場合、 ユーザー・ネーム・サーバー が、適切なドメインに設定されている mqsicreateusernameserver コマンドの -d フラグを使用して作成されていることと、 すべてのクライアント・アプリケーション・ユーザー ID がこのドメインのメンバーであることを確認します。
通常、パブリッシュ/サブスクライブでのメッセージ持続性は保存されます。ただし、サブスクライバーは、ACL が許可しない場合、予期したとおりの持続性を取得しない場合があります。
記号 | エスケープ文字 |
---|---|
< | < |
> | > |
" | " |
' | ' |
& | & |
たとえば、以下を使用する場合、
<Filter>Body.e_ALERT_BODY.eqnum<6</Filter>
以下のように指定する必要があります。
<Filter>Body.e_ALERT_BODY.eqnum<6</Filter>
構成がデプロイされると、各ブローカーから応答を受け取ります。 これらはワークベンチに表示されます。ただし、各ブローカーのローカル・ログもチェックする必要があります。 それぞれの接続ごとに、BIP7113 メッセージが表示されます。 通信をテストする際に、Soccer サンプル・アプリケーションが役立つ場合があります。 別々のブローカーの各部分を実行して、ブローカー間の通信をテストすることができます。
構成マネージャーのキュー・マネージャーおよびユーザー・ネーム・サーバーのキュー・マネージャーとの間で、送信側と受信側チャネルと伝送キューの両方を確立している必要があります。これらのチャネルが作成されており、現在実行していることを確認してください。
変更を加える場合は、 構成マネージャーを再始動して、 Windows イベント・メッセージ 8258 をチェックします。 これは、構成マネージャーがユーザー・ネーム・サーバーに正常に登録されたことを示します。たとえば、チャネルに変更を加える場合には、ワークベンチを再始動して表示されているユーザーのリストをリフレッシュする必要があります。
z/OS では、ユーザー・ネーム・サーバーが実行しており、 また上記のように正しく設定しているにもかかわらず、 「ブローカー管理 (Broker Administration)」パースペクティブ の「トピック (Topics)」ビューにリストされた z/OS ユーザーが表示されない場合、z/OS ユーザーがすべて OMVS セグメントを定義していることをチェックしてください。セグメントが定義されていない場合、ユーザーはユーザー・ネーム・サーバーによってリストされません。
JIT コンパイラーは、LIBPATH が設定されていない場合、正常にロードおよび稼働します。 これは簡単な事例ですが、LIBPATH を設定しないことをお勧めします。ライブラリーを /var/wmqi/lib (AIX プロセス用のすべての WebSphere Business Integration Event Broker に対して) または /usr/lib (システム上のすべてのプロセスに対して) にリンクすることによって、これを使用可能にできます。 AIX 構成用の WebSphere Business Integration Event Broker は、 DB2 ライブラリーに対してこれを行います。
LIBPATH を設定する必要がある場合、 それを更新してディレクトリー /usr/java130/bin を組み込む必要があります。
たとえば、以下のコマンドを使用して、ブローカーを始動します。LIBPATH=/usr/local/lib:/usr/java130/bin mqsistart mybroker
#DFL0 DSNILMCL RESOURCE UNAVAILABLE 558 CORRELATION-ID=ST03BRK CONNECTION-ID=RRSAF LUW-ID=* REASON 00C90092 TYPE 00000905 NAME IRLM *DXR175E IFL0001 IRLM IS UNABLE TO OBTAIN STORAGE - ECSA DSNT501I #DFL0 DSNILMCL RESOURCE UNAVAILABLE 560 CORRELATION-ID=ST04BRK CONNECTION-ID=RRSAF LUW-ID=* REASON 00C90092 TYPE 00000905 NAME IRLM
注意 |
商標 |
ダウンロード |
ライブラリー |
技術サポート |
フィードバック
![]() ![]() |
au16630_ |