キュー・マネージャーを別個に作成することにした場合、送達不能キュー (DLQ) をセットアップする必要があります。DLQ は、メッセージ・フロー内のメッセージの処理でエラーが発生したときに、WebSphere Message Broker から参照されます。
ユーザー定義のメッセージ・フロー中かパブリッシュ/サブスクライブ・モデル中にあるメッセージが処理できないと、そのメッセージは最後の手段としてこの DLQ にルーティングされます。もし、そうではなく、メッセージを入力キューにバックアウトさせ、問題が解決するまで事実上メッセージ・フローを停止させておきたい場合には、DLQ を使用不可にしておいてください。
このキューは mqsideletebroker コマンドによって削除されません (キュー・マネージャーを削除した場合を除く)。
mqsicreatebroker コマンドとは無関係に作成された WebSphere MQ キュー・マネージャーを使用する場合、クラスターを定義することもできます。これを使用すると、ほとんどの場合に構成が簡単になります。
このコマンドを使用してキュー・マネージャーを作成した場合は、キュー・マネージャーは Windows サービスとして開始されません。したがって、ログオフすると停止します。これが起きないようにするには、ログオンの状態を維持するか、またはキュー・マネージャー・サービスの開始状況を変更します。(ワークステーションをロックしても、WebSphere MQ キュー・マネージャーは停止しません。)
z/OS では、大文字のブローカー名を作成した場合、ワークベンチのブローカーでもその名前を大文字で使用しなければなりません。
使用できる文字セットに関する制約事項については、コマンドで使用できる文字を参照してください。これは、任意の有効なユーザー名構文の形式で指定できます。Windows プラットフォームでは、それは次のとおりです。
Linux および UNIX システムでは、最後の形式の username だけが有効です。
このユーザー ID の非修飾形式 (username) を Windows プラットフォームで使用すると、オペレーティング・システムによって、ローカル・システムから始めてドメイン全体でこのユーザー ID が検索されます。この検索が完了するまでに多少の時間がかかることがあります。
指定する ServiceUserID は、ローカル・グループ mqbrkrs のメンバーでなければなりません。Windows プラットフォームでは、このグループの直接または間接のメンバーとして指定することができます。また ServiceUserID は、ホーム・ディレクトリー (WebSphere Message Broker のインストール先) と作業ディレクトリー (-w フラグで指定した場合) へのアクセスも許可されていなければなりません。
Windows プラットフォームでは、WebSphere MQ トラステッド・アプリケーション (フラグ -t) としてのブローカーの実行を指定する場合は、このユーザー ID をグループ mqm に追加する必要もあります。Linux および UNIX システムで、-t フラグを設定した場合、mqm として ServiceUserID を指定します。
ServiceUserID のセキュリティー要件は、Windows プラットフォームでのセキュリティー要件 に詳述されています。
このユーザー ID をデータベース・アクセスに使用する場合 (つまり、-u フラグを使用して別のユーザー ID を指定しない場合)、SQL Server をデータベースとして使用するのであれば、ブローカーを作成する前に、このユーザー ID を SQL Server ログイン ID として作成し、正しいアクセス権を付与しなければなりません (詳細については、ブローカーのセキュリティーの考慮 を参照)。DB2 中にブローカー・データベースがあり、このユーザー ID が DB2 に認識されていない場合、DB2 によって自動的にユーザー ID が作成されます。
既存のシステムとの互換性を保つために、引き続き <password> を指定することができます。 しかし、コマンドの実行時にパスワードをこのパラメーターとともに指定しない場合は、起動時にパスワードを入力するようにプロンプトが出され、正しく入力したことを確認するためにパスワードをもう一度入力するようにプロンプトが出されます。
Linux および UNIX システムの場合、-a は Windows プラットフォームとの互換性を保つのに必須ですが、ServiceUserID に関連して使用されるわけではなく、-p を指定しない場合のデフォルトとして使用されるだけです。(詳細については、-p パラメーターの注意事項を参照してください。)
キュー・マネージャーがまだ存在していない場合は、このコマンドによって作成されます。ただし、デフォルトのキュー・マネージャーとして作成されるわけではありません。このキュー・マネージャーをこのシステム上のデフォルト・キュー・マネージャーにするには、このコマンドを発行する前にキュー・マネージャーを作成するか、または WebSphere MQ Service でこのキュー・マネージャーの設定を変更してデフォルトにしなければなりません。
キュー・マネージャー属性 MAXMSGLN (キューに挿入できるメッセージの最大長) は、100 MB に更新されています。この更新は、このコマンドによってキュー・マネージャーが作成されたかどうかに関係なく行われます。
使用できる文字セットに関する制約事項については、コマンドで使用できる文字を参照してください。
このデータベースはすでに存在していなければなりません。この DSN に対する System DSN ODBC 接続をまだ作成していない場合は、これを作成する必要があります。
Linux 上に DB2 データベースがある場合は、該当する DB データベース別名を入力してください。ODBC DSN は必要ありません。
このユーザー ID には、このデータベース中に表を作成し、それらの表を読み書きする権限がなければなりません。
Windows プラットフォームでは、DB2 中にブローカー・データベースがある場合に、このユーザー ID が DB2 に認識されていないと、DB2 中にユーザー ID が作成されます。Linux および UNIX システムでは、サービス利用者に正しい特権が事前に付与されていなければなりません。データベースが SQL Server である場合は、ブローカーを作成する前に、このユーザー ID を SQL Server ログイン ID として作成し、正しいアクセス権を付与しなければなりません (詳細については、Windows プラットフォームでのセキュリティー要件 を参照)。
このユーザー ID が作成したアプリケーション・データベースや、このユーザー ID が該当する読み取り、書き込み、または作成権限を持つアプリケーション・データベースが DB2 中にある場合、このブローカーで実行されるメッセージ・フローは、スキーマ名を明示的に指定しなくても、このデータベース中のアプリケーション・データにアクセスして操作できます。
既存のシステムとの互換性を保つために、引き続き <password> を指定することができます。 しかし、コマンドの実行時にパスワードをこのパラメーターとともに指定しない場合は、起動時にパスワードを入力するようにプロンプトが出され、正しく入力したことを確認するためにパスワードをもう一度入力するようにプロンプトが出されます。
Linux および UNIX システムで DB2 を使用している場合、 -u と -p を空ストリング (2 つの二重引用符 "") で指定することもできます。この場合、DB2 から WebSphere Message Broker に ServiceUserID の特権が付与され、データベース接続が「検査済み」の状態になります。-u と -p だけでなく -a も空ストリングとして指定すると、WebSphere Message Broker でパスワードが保管されないので、最も安全な構成が作成されます。
また、このディレクトリーはトレースがアクティブの際に作成されるトレース・レコード用にも使用されます。これらはサブディレクトリー log に作成されます。このサブディレクトリーは、ブローカーを開始する前に作成しなければなりません。
プロセスが異常終了した際にブローカーによって作成されるエラー・ログは、このディレクトリーに保管されます。Windows プラットフォームでは、このオプションを使用し、製品がインストールされているドライブ以外のドライブ上のディレクトリーを指定します。
エラー・ログに制限はなく、そのサイズは大きくなり続けます。定期的にこのディレクトリーを調べ、古くなったエラー情報は消去してください。
このオプションの変更は、mqsichangebroker コマンドでは行えません。作業パスの指定または変更を行いたい場合は、ブローカーを削除してから再作成します。
このオプションは、AIX では使えません。これが指定される場合には、フラグは無視されます。
Windows プラットフォームでこのオプションを指定する場合は、ServiceUserID (フラグ -i で指定) をグループ mqm に追加します。HP-UX および Solaris でこのオプションを指定する場合、mqm として ServiceUserID を指定します。WebSphere MQ トラステッド・アプリケーションの使用に関する詳細は、「WebSphere MQ相互通信」を参照してください。
独自のディレクトリーを作成して、.lil ファイルや .jar ファイルを保管する必要があります。これらのファイルを WebSphere Message Broker インストール・ディレクトリーに保管しないでください。
複数のディレクトリーをさらに別に指定する場合、プラットフォーム固有のデフォルトのパス区切り文字 (Windows プラットフォームではセミコロン (;)、Linux および UNIX システムではコロン (:)) でそれぞれを区切る必要があります。
このパス内で環境変数を使用することはできません。使用しても、無視されます。
メッセージ・フローがアプリケーション・メッセージを処理している場合、構成変更には対応できません。構成を変更するように要求された実行グループ内のメッセージ・フローのいずれかが、アプリケーション・メッセージの処理を完了しておらず、そのタイムアウト内で構成変更を適用していない場合、実行グループは否定応答を戻して、構成メッセージをデプロイします。
このタイムアウトに関して設定する値は、システム負荷 (CPU の使用効率など) およびそれぞれの実行グループの負荷によって異なります。最初の見積もりは、ブローカーの構成全体をデプロイすることによって行うことができます。これを正常に完了するのにかかる時間によって、設定すべき最小値を知ることができます。
値は、10~3600 の範囲の秒数で指定することができます。デフォルト値は 300 です。
ConfigurationTimeout と ConfigurationDelayTimeout (以下で説明される) の合計は、デプロイ済み構成メッセージをブローカーが処理するために許可されている最大時間 (これを超えると、否定応答が生成される) を表しています。
これは、最も小さいデプロイ済み構成メッセージをブローカーおよびその実行グループが処理するためにかかる時間を表しており、キュー・マネージャー・ネットワーク遅延、ブローカーのキュー・マネージャーの負荷、およびシステム負荷によって異なります。
mqsireporttrace brokerName -e "Execution Group Name" -u
F MQP1BRK,reporttrace u=yes,e='exgrp1'
各実行グループの応答時間は、システム負荷およびそれ自体のプロセスの負荷に応じて異なります。設定する値は、実行グループが応答にかかる最も長い応答時間を反映していなければなりません。設定した値が短すぎると、ブローカーは否定応答を戻し、場合によっては、エラー・メッセージをローカル・エラー・ログに出すこともあります。
値は、10~3600 の範囲の秒数で指定することができます。デフォルト値は 60 です。
ブローカーが実動システムに置かれている場合、構成変更が適用される前に、メッセージ・フローによって現在処理されているアプリケーション・メッセージを完了できるようにするため、ConfigurationTimeout と ConfigurationDelayTimeout の両方の値を増やすようにお勧めします。
ブローカーが開発システムまたはテスト・システム上にある場合、知覚できる応答時間を向上させるためと、期待どおりの振る舞いを示さないブローカーに強制的に応答させるために、タイムアウト (特に ConfigurationTimeout) を減らすこともできます。ただし、タイムアウト値を減らすと、構成変更が正常にデプロイされる見込みが低下します。
Web サービス・サポートが組み込まれたメッセージ・フローの開始時にブローカーによってこのリスナーが始動され、そのデフォルト値は 7080 です。
指定するポートが、他の目的で指定されていないことを確認してください。
ゼロ分のインターバルは、外部通知手段がプラットフォームに装備されているので、WebSphere Message Broker の内部タイマーは使用しないことを示します。
Windows システムでは、このコマンドを呼び出すのに使用するユーザー ID には、ローカル・システムに対する Administrator 権限がなければなりません。
UNIX システムでは、このコマンドを呼び出すのに使用するユーザー ID は、mqbrkrs グループのメンバーでなければなりません。
z/OS システムでは、このコマンドを呼び出すのに使用するユーザー ID は、コンポーネント・ディレクトリーに対する READ および WRITE アクセス権のあるグループのメンバーでなければなりません。
LDAP を使用する場合: 無許可アクセスできないように、レジストリーが適切に保護されていることを確認してください。ブローカーの正しい操作のためには、mqsicreatebroker 上での LdapPrincipal および LdapCredentials オプションの設定は必要ありません。パスワードは平文でファイル・システム中に保管されません。
上記のすべてのキューには、WebSphere Message Broker グループ mqbrkrs へのアクセス権限が付与されます。DLQ が使用可能になっている場合は、DLQ にも同じ権限が付与されます。
このコマンドは、以下の応答を戻します。
(51002)[IBM][CLI Driver][DB2/NT]SQL0805N Package "NULLID.SQLLF000" was not found. SQLSTATE=51002.
このエラーは、データベースへのバインドが正常に行われなかった場合に起きます。
Windows プラットフォームでは、ブローカー・データベースにバインディングは必要ありませんが、ユーザー・データベースにはバインディングが必要です。DB2 コントロール・センターを使ってデータベースを作成した場合、バインドは自動的に完了します。コマンド・インターフェースを使用した場合は、そうではありません。たとえば、データベース MYDB の場合、コマンド・プロンプトで以下のコマンドを入力すれば、バインドを作成したり再作成したりすることができます。
db2 connect to MYDB user db2admin using db2admin db2 bind X:¥sqllib¥bnd¥@db2cli.lst grant public db2 connect reset
X: は DB2 のインストール先のドライブです。
UNIX プラットフォームでは、すべてのデータベースでバインディングが必要です。たとえば、データベース WBRKBKDB の場合は、コマンド・プロンプトで以下のコマンドを入力するとこの処理を行えます (ここで、<user_name> は、データベース・インスタンスの作成に使用されたユーザー ID です)。
db2 connect to WBRKBKDB user db2admin using db2admin
db2 bind ~<user_name>/sqllib/bnd/@db2cli.lst grant public CLIPKG 5
db2 connect reset
デフォルトの DB2 ユーザー ID とパスワード (db2admin) を使用していない場合は、db2 connect コマンド中のこれらの値を正しい値に置き換えなければなりません。
最初に mqsicreatebroker コマンドを実行したときに失敗した場合、 2 度目にこのコマンドを実行すると、一連のメッセージが戻されます。これらのメッセージは、作成できない項目を示します。この結果として有害な影響が生じることはありません。たとえば、最初に失敗した理由が解決されている場合、最初に失敗したブローカーの作成を試行したときに、ブローカーは適切に作成されます。