[MQ学習③]IBM MQのキューマネージャー接続(メッセージチャネル)をGUIで試す

# はじめに

前回はMQIクライアント接続でのMQ操作を行った。

https://qiita.com/alphajinsei/items/8750c885adbb08096332


今回は、もう一つの接続形態である、メッセージチャネルを経由したキューの伝搬を確認する。

接続イメージは以下。

↓[MQ虎の巻1](https://community.ibm.com/community/user/integration/viewdocument/mq-mq-v7) より「キューマネージャー接続」の図

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1523824/1a53345c-a917-b740-2454-60e58304a77b.png)

↓[MQ虎の巻2](https://community.ibm.com/community/user/integration/viewdocument/mq-2websphere-mq)より「メッセージチャネル」の図

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1523824/a40a11c3-9abd-5003-063f-22f20316966f.png)


# 環境構成

[前回](https://qiita.com/alphajinsei/items/8750c885adbb08096332) も利用したコンテナ環境を利用する。

完成イメージは以下。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1523824/ef7d1332-97b5-76d3-3732-58ce814ac6a7.png)

* キューマネージャー、リスナはMQコンテナ起動時にデフォルトで作成されるものを使用する。
* 各オブジェクトの命名は[MQ虎の巻7章:ネーミングルール](https://community.ibm.com/community/user/integration/viewdocument/mq-7)を参考に以下とする
    * リモートキュー：TEST_REMOTE_QUEUE
    * トランスミッションキュー：TEST_DEST_QUEUE (宛先ローカルキューと同名)
    * 送信側チャネル：QM1.TO.QM2 
    * 受信側チャネル：QM1.TO.QM2 (送信側と同名)
    * 宛先ローカルキュー：TEST_DEST_QUEUE


# MQコンテナ起動

今回も公式イメージを利用する。詳細は[前回](https://qiita.com/alphajinsei/items/8750c885adbb08096332)、[前々回](https://qiita.com/alphajinsei/items/cdbd82b7ac097f15ea57)を参照。

https://hub.docker.com/r/ibmcom/mq





```bash
# コンテナ間で名前解決・通信できるようにnetworkを定義
docker network create QM-network

# 永続化用のvolumeを作成
docker volume create qm1data
docker volume create qm2data

# QM1_containerを起動
docker run \
--name QM1_container \
--detach \
--rm \
--network QM-network \
--volume qm1data:/mnt/mqm \
--publish 1414:1414 \
--publish 9443:9443 \
--env LICENSE=accept \
--env MQ_QMGR_NAME=QM1 \
--env MQ_DEV=false \
--env MQ_APP_USER=app \
--env MQ_APP_PASSWORD=passw0rd \
--env MQ_ADMIN_USER=admin \
--env MQ_ADMIN_PASSWORD=passw0rd \
icr.io/ibm-messaging/mq:9.2.4.0-r1

# QM2_containerを起動
# そのままだとホストのポート番号が重複するため、ホスト側にマッピングするポートを1ずつずらしている
docker run \
--name QM2_container \
--detach \
--rm \
--network QM-network \
--volume qm2data:/mnt/mqm \
--publish 1415:1414 \
--publish 9444:9443 \
--env LICENSE=accept \
--env MQ_QMGR_NAME=QM2 \
--env MQ_DEV=false \
--env MQ_APP_USER=app \
--env MQ_APP_PASSWORD=passw0rd \
--env MQ_ADMIN_USER=admin \
--env MQ_ADMIN_PASSWORD=passw0rd \
icr.io/ibm-messaging/mq:9.2.4.0-r1
```

### キューマネージャー・リスナ存在確認

キューマネージャー・リスナは公式MQコンテナ起動時にデフォルトで作成されるものを利用する

```bash
# キューマネージャーQM1, QM2それぞれの存在確認。Runningになっている
[root@my-instance ~]# docker exec -it QM1_container dspmq
QMNAME(QM1)                                               STATUS(Running)
[root@my-instance ~]# docker exec -it QM2_container dspmq
QMNAME(QM2)                                               STATUS(Running)


# QM2側のリスナの存在確認。1414ポートでlistenしている
[root@my-instance ~]# docker exec -it QM2_container sh -c "echo \"DISPLAY LSSTATUS(*) ALL\" | runmqsc QM2 "
5724-H72 (C) Copyright IBM Corp. 1994, 2021.
Starting MQSC for queue manager QM2.


     1 : DISPLAY LSSTATUS(*) ALL
AMQ8631I: Display listener status details.
   LISTENER(SYSTEM.LISTENER.TCP.1)         STATUS(RUNNING)
   PID(321)                                STARTDA(2024-12-14)
   STARTTI(19.08.01)                       DESCR( )
   TRPTYPE(TCP)                            CONTROL(QMGR)
   IPADDR(*)                               PORT(1414)
   BACKLOG(100)
One MQSC command read.
No commands have a syntax error.
All valid MQSC commands were processed.
```

# 各種キュー・チャネル作成

https://localhost:9443, 9444 でそれぞれのMQに対応したGUIコンソールにアクセスすることができる（[前々回](https://qiita.com/alphajinsei/items/cdbd82b7ac097f15ea57)を参照）。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1523824/cef5efbf-ed61-5102-069e-3328d4f07dd6.png)

以降はGUIで構築していく。

まずはQM1側から進める。https://localhost:9443 を操作する。

### リモートキュー

以下の４つを指定。他はデフォルト。
* キュー名：`TEST_REMOTE_QUEUE`
* リモート・キュー：`TEST_DEST_QUEUE` (=宛先ローカルキュー名)
* リモート・キュー・マネージャー：`QM2`
* 伝送キュー：`TEST_DEST_QUEUE` (=宛先ローカルキュー名と同名)

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1523824/cbef3b51-39b5-b0a8-d9a4-e1acaf36582c.png)


### トランスミッションキュー
以下２つを指定。「トランスミッションキューであること」以外は普通のローカルキューと違いは無い。
※[虎の巻](https://community.ibm.com/community/user/integration/viewdocument/mq-2websphere-mq)でも「特殊な目的をもつローカルキュー」の一つとして紹介されている

* キュー名：`TEST_DEST_QUEUE`
* 使用法：`伝送`

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1523824/c073ce38-8ae6-313a-1ff9-b12b14a30839.png)

### 送信側チャネル

以下を指定して作成。接続名の指定が独特である点に注意。docker networkを共有しているため、QM1_containerから、QM2_containerを名前解決でき、ポートもそのまま指定できる。

* チャネル名：`QM1.TO.QM2 `
* チャネル・タイプ：`送信側`
* 接続名：`QM2_container(1414)`
* 伝送キュー：`TEST_DEST_QUEUE`

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1523824/63c1545c-ecca-5546-bdc3-13b64636ab97.png)

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1523824/878d4f96-0174-3940-0a9c-f32163e9654f.png)


### 受信側チャネル

続いてQM2側を構築する。https://localhost:9444 を操作する。

受信側チャネルは単に名前の指定のみ。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1523824/4dfd13c9-3539-07f4-b1d9-1230de60087a.png)

### 宛先ローカルキュー

こちらも単に名前のみ指定して作成。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1523824/a5e1736a-70b6-8c66-edb5-28de783c9995.png)

# 送信テスト

### チャネル接続

QM1側の送信側チャネルを「開始」し、チャネルを接続する

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1523824/9724d3c4-a6ac-3099-469d-d4a5f09f1585.png)

実行中の表示になった。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1523824/36832241-cec5-23d7-842f-8e3e84f549d9.png)


### キュー送信

QM1上のリモートキューを選択し、「メッセージの作成」を押す

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1523824/312702ad-5900-242b-61a2-d61e6ecf9bd1.png)

適当なメッセージを記載して「送信」
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1523824/73aee533-ae74-aa66-f35f-f0e5d74ce9c9.png)

正常にメッセージが作成された。トランスミッションキューに滞留していないことが確認ポイント
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1523824/563b53dd-fa3d-6637-da24-3316f93dfde8.png)

QM2側の宛先ローカルキューを見ると、無事にキューが伝搬してきたことがわかる。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1523824/a9fa4457-1939-9f11-ed1c-ba0830b3d787.png)


# 補足：

チャネルが断絶した状態でキューを送ろうとすると、キューはトランスミッションキューに滞留する。本番で起きると困る。


チャネルが停止している状態で・・・
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1523824/9697337f-46c8-04f9-5499-499be13e7897.png)

リモートキューにエンキューすると

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1523824/164ae4d6-9c10-84db-551f-606f2efeaa2c.png)

キューはトランスミッションキューに滞留する。こうなると困るので、実運用ではトランスミッションキューの滞留状況を監視しておきたい。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1523824/6c6b1806-3c9c-27d2-d950-c2a034537315.png)

チャネル断絶が解消すると（再度チャネルを開始すると）、
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1523824/ead71fdc-97de-58cd-3ab3-3f8bfbb4bc1f.png)

キュー滞留は解消、
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1523824/c78e4479-409b-907e-c6a4-cc51d11cb438.png)

QM2へ配送される。これで安心。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1523824/09999bad-bbdf-53d4-cd15-8d75f02a8952.png)