CMP Applicationをz/OSのUSS上で動かく方法
ConfigManagerProxy.jarを使って、
WebSphere Message Brokerを管理するのは、
WMBを使ったテストの自動化する上では必要なやり方だろう。
CMPアプリケーションを書く人も少なく、
しかもz/OS上で動かすとか普通しないだろうなぁ。
ははは、役に立たないブログエントリーだ。
z/OSではなく、Linux/Windowsなどでは、
BrokerProxyのインスタンスを得るのにだいたいこんなコードを書く。
BrokerConnectionParameters bcp = new MQBrokerConnectionParameters("host.name", 1414,"qmgrName"); BrokerProxy.getInstance(bcp);
なんか知らんけど、z/OSでCMPを動かしたいらしく、その方法を考えた。
上記の方法では、WMQ的にはTCPIPを前提としたクライアントモードで繋ぐことになる。
z/OS上でクライアンントモードが許されるのはWebSphere Application Serverのみなので、
この方法では繋ぐことは出来ない。
だから、MQの2012、MQRC_ENVIRONMENT_ERRORが返ってくるんだ。
方向性としては、BINDINGSモードで繋ぐことの出来る方法はないかという点に尽きる。
BrokerConnectionParametersの実装は3種類ある。
LocalBrokerConnectionParameters
MQBrokerConnectionParameters
MQPropertyFileConfigManagerConnectionParameters
あとは、BrokerProxy自体の持ってるgetLocalInstance()メソッドを使うというものもあるが、
裏側で上記の方法(LocalBrokerConnectionParameters)になってしまい、
やってることに違いがない認識。
そこでまずは、LocalBrokerConnectionParametersをまず試した。
うーむ、失敗。
どうやらLocalBrokerConnectionParametersは、フロー上で動くことを意図しているようだ。
コンストラクタに渡せるのはブローカー名だった。
こんな情報のみではMQに繋げない。
使う前から「?」マークは点灯していた。
実験の順序は違うけど、問題が認識されているMQBrokerConnectionParametersの使い方も考えた。
localhostを指定する方法は実験されていたようだ。
代わりにホスト名(IPアドレス)にnullを渡してみたが、これも失敗。
むーりー。
結局、z/OS上のCMP ApplicationでBrokerProxyを使えたのは、
MQPropertyFileConfigManagerConnectionParametersだった。
これは*.brokerというファイルを使う。
ToolKitでリモートブローカーに繋ぐ時に使うことの出来るXML形式のファイルを用いる。
MQPropertyFileConfigManagerConnectionParametersのJavaDocに書かれているXMLの例をカスタマイズした。
<?xml version="1.0" encoding="UTF-8"?> <broker queueManager="QueueManagerName"/> <|| たったこれだけで繋ぐことができる。 もともと、z/OS上のBINDINGSモードの場合、MQ接続に必要な情報はキューマネージャ名のみでOKだ。 コンストラクタにファイルパスを書かないといけないので、そこが少し面倒だ。 カレントディレクトリがどこかも確認せずに相対パスとかマジ勘弁。 正直、この手のキューマネージャ名は、テスト用のプロパティファイルに書いてることが多く、 そこにきてまた新たに*.brokerファイルにも書くとか冗長でオラは嫌いだ。 プロパティファイルから拾ったキューマネージャ名を元に*.brokerファイルを自動生成しちまえばいい。 可変の部分は1箇所だし、エンコーディングもUTF-8と決まってる。 user.homeか、user.dirか、java.io.tmpdirか。 フォルダにファイルが既にあれば使うし、なければファイルを作る。 パーミッション的に安全なのはuser.homeかな。 まあ、RACFユーザーのOMVSセグメントでHOMEがルートになってる不届きなユーザーは論外な。 もちろん、z/OS上であるかはos.nameで拾って分岐する感じ。 ファイルのお掃除までは考えてない。 JavaでcreateTempFileとかするのは避けたい。 テストケースみたいな何回も使いそうなところでTempFile使うのは、 shutDownHookが呼ばれるまで何個作るかよく分からないのでヒープ的にやめとけってこと。 メソッド的には、BrokerConnectionParametersをリターンするメソッドを用意すべきだろう。 引数にはTCP/IPベースで必要な最低3つのパラメータ(IP,PORT,QMGR名)を渡す。 内部でos.name判定、z/OSならIPとPORTを無視、*.brokerの自動生成をする。 *.brokerファイルのファイル名はキューマネージャ名.brokerにするのが無難だが、 クライアントモードも全てこの方法に集約したいという話であれば、キューマネージャ名のみは危険だろう。 例えばz/OS上なら、local.キューマネージャ名.brokerにし、 Linux上等ならば、<IP>.<PORT>.<キューマネージャ名>.brokerの形式にすればいい。 まあ、チャネル名も分けたいというなら、メソッド引数も込みでファイル名の規則も直せばいいだろう。 このくらいやっておけば、どんなプラットフォームでも動くCMPアプリケーションになる。