WMB実装入門ガイド 2008年5月 日本アイ・ビー・エム システムズ・エンジニアリング ＜WMB実装入門ガイド＞
by user
Comments
Transcript
WMB実装入門ガイド 2008年5月 日本アイ・ビー・エム システムズ・エンジニアリング ＜WMB実装入門ガイド＞
＜WMB実装入門ガイド＞
WMB実装入門ガイド
2008年5月
日本アイ・ビー・エム システムズ・エンジニアリング
＜WMB実装入門ガイド＞
はじめに
当資料は、初めてWMBの開発に携わる方を対象とした、アプリケーション開発のための入門書で
す。
当資料ではWMBでのアプリケーション開発の流れや開発のためのテクニックをまとめています。
事前にWMBの製品概説を一読いただくことをお勧めします。
http://www-06.ibm.com/jp/software/websphere/developer/bi/mbv61/
当資料はWMBv6.1を使用し、作成しています。
当資料に含まれる全ての情報は、利用者の責任において使用されるべきものであり、特定環境
への適用は利用者の判断に依存します。
2
＜WMB実装入門ガイド＞
内容
WMBの基礎知識
WMB実装入門
その他の考慮点
フロー実装のテクニック
3
＜WMB実装入門ガイド＞
WMBの基礎知識
4
＜WMB実装入門ガイド＞
WMBの実装のお話しに入る前に、まず、WMBの基礎を復習
しておきましょう。
5
＜WMB実装入門ガイド＞
WMBの位置付け
WMB(WebSephere Message Broker)とはどんな製品なのでしょう？
通信プロトコル、データ・フォーマット、コードページの異なるアプリケーションを連携するためのミドルウェアです。
宛先に合わせて、プロトコル、データ・フォーマット、コードページなどを変換します。
アプリケーション連携のための変換ロジックや、宛先のルーティング情報を集中管理します。
N：Nのアプリケーション連携を実現します。
SOAリファレンス・アーキテクチャーの中で通信レイヤーを担うESBを実装する一製品です。
サポートするプロトコル、データフォーマット、機能の多さからAdvanced
ESBとして、位置づけられます。
アプリケーション
JMSアプリケーション
JMSMap/JMS
XML/JMS
WebSphere Message Broker
アプリケーション
・通信プロトコルの変換
・データ・フォーマットの変換
・コードページの変換
・制御の変換
XML/HTTP
MQアプリケーション
XML/MQ
SOAP/HTTP
Webサービス
アプリケーション
SOAP/JMS
CWF/MQ
MQアプリケーション
Webサービス
アプリケーション
(データ・フォーマット/通信プロトコル)
6
＜WMB実装入門ガイド＞
WMBの主なコンポーネント
WMBの製品コンポーネントは主に3つあります。
メッセージ・ブローカー・ツールキット
WMBで実行する処理を実装するためのEclipseベースのGUI開発ツールです。
構成マネージャー
ブローカーや実行グループなどのトポロジー情報を管理します。
ブローカー
ツールキット上で開発した処理の実行環境を提供します。
–開発物は実行グループのスレッドとして動きます。
<開発の流れ>
WMBの処理をGUIの開発ツール
で作成
メッセージ・ブローカー
ツール・キット
開発ツールで作成した開発物を
構成マネージャー経由でブローカーに
デプロイ
構成マネージャー
開発環境
デプロイ
開発物をブローカーで実行
※本番稼動後ではブローカーのみ起
動していればよい
実行環境
ブローカー
実行グループ
アプリケーション
アプリケーション
CWF/MQ
XML/MQ
7
＜WMB実装入門ガイド＞
WMBの開発物
WMBの主な開発物はメッセージ定義とメッセージ・フロー定義です。
WMBでの処理はメッセージ・ブローカー・ツールキットを使用して実装します。
メッセージ・フォーマットを定義するメッセージ定義と処理を定義するメッセージ・フローを開発します。
メッセージ・フォーマット定義では入出力のデータ・フォーマットを定義します。
メッセージ・フローの処理の中でメッセージにアクセスするために、メッセージを論理メッセージにパース（分解）
したり、出力メッセージを生成したりする際に使用します。
ツールキットでの設定や、メッセージ定義ファイルのインポートにより定義を実装します。
メッセージ・フローの処理内でツリーに
展開された各エレメントの値を操作
することが可能
例：条件によってDESTNAME（宛先
名）の値を変更する など
メッセージ・ツリー（論理メッセージ）
Root
Properties
WMBで入力メッセージの各データを意
味ある値として理解/操作するために
メッセージ･ツリーに展開
例：値「SYSTEM A」はSENDER NAME
を表す など
MQMD
Body
MessageSet
Format
MessageType
Version
DESTNAME
MSGTYPE
PROTOCOL
出力用のメッセージ定義に合わせて
メッセージを組み立て
SENDER_NAME
入力メッセージのパース
出力メッセージの組み立て
メッセージ
定義
MQMD
B
XML
WMQ
メッセージ
定義
SYSTEM A
MQMD
8
<Output><DESTNAME>B </DESTNAME> ･・</Output>
＜WMB実装入門ガイド＞
WMBの開発物
メッセージ・フローではブローカーでの処理を定義します。
メッセージ・フローはメッセージの受信をトリガーに処理を開始し、システム間の連携に必要なフォーマット／
データ変換を行い、適切な宛先に送信するアプリケーションです。
プロセス･ノードを組み合わせてメッセージフローを実装します。
プロセス･ノードは、特定の処理を行う部品（実体は共有ライブラリ）です。
製品として様々なプロセス･ノードを提供しています。
メッセージ送受信用のノード、メッセージ変換用のノード、データベース・アクセス用のノード、
ルーティング用のノード、エラー処理用のノードなど
メッセージを
取得
メッセージの
一部をDBへ
Insert
メッセージの
値に応じて、
宛先を振り分け
システムB用に
フォーマット変換
システムBへ
メッセージ送信
システムB
MQ
XMLデータ
システムA
MQ
固定長データ
システムC
JMS
この各部品が
プロセス･ノード
システムC用に
フォーマット変換
システムCへ
メッセージ送信
ユーザーDB
プロセス・ノードを組み合わせて
メッセージ･フローを実装
9
ｚ
タグ区切りデータ
＜WMB実装入門ガイド＞
WMBの開発物
WMBでの入出力メッセージの取り扱い
1.ブローカーがメッセージ定義を元に物理メッセージと論理メッセージの間変換を実行
a.メッセージ取得時に、入力メッセージを論理ツリーに展開（パース）
b.メッセージ出力時に、論理ツリーから出力メッセージを組み立て
2.論理メッセージでは物理フォーマット（XML、固定長、タグデリミタなど）やプロトコル（MQ、HTTP、JMS)の属性を排除
3.フロー開発者はメッセージの物理フォーマットやプロトコルを意識することなく、同一の方式でデータへのアクセスが可能
メッセージ・ツリー（論理メッセージ）
Root
Properties
ヘッダー部
データ部
メッセージ定義
2 入力メッセージをメッセージ・
ツリーとして保持
幕張 太郎
メッセージのデータ構造を定義
25
千葉市美浜区
データ部
043-XXX-XXXX
名前
年齢
住所
電話番号
1-a
3
入力メッセージを
論理ツリーにパース
メッセージ・ツリーに
アクセス
1-b
論理ツリーから出力
メッセージを組み立て
WMB
MQ
システムA
固定長データ
幕張太郎
美浜区
25千葉市
043-XXX-XXXX
システムB
XMLデータ
<Name>幕張太郎</Name>
<Age>25</Age >
<Address>千葉市美浜区
</Address>…
MQ
システムC
タグ・デリミタデータ
JMS
10
幕張太郎;25;千葉市
美浜区;043-XXX-XXXX
＜WMB実装入門ガイド＞
まとめ
¾ WMBはツールキットと呼ばれる開発ツールを使用して開発し、
その開発物を構成マネージャー経由で、実行環境のブロー
カーにデプロイします。
¾ WMBの開発物には、入出力メッセージのフォーマットを定義
したメッセージ・フォーマット定義と、処理内容を定義したメッ
セージ・フロー定義があります。
11
＜WMB実装入門ガイド＞
WMB実装入門
12
＜WMB実装入門ガイド＞
シンプルなメッセージ定義とフロー定義を開発してみましょう。
13
＜WMB実装入門ガイド＞
メッセージフローの設計
WMBでの処理を実装する前に、決定すべき項目を以下にまとめます。
WMBでの処理要件（正常処理フローの検討）
検討項目
検討内容
連携パターン
メッセージの流れと連携するアプリケーションやメッセージの単位
一方向型 or リクエスト･リプライ型
1対1連携 or 1対N連携 or N対N連携
1メッセージ単位の連携 or 複数メッセージ単位の連携
メッセージ・フォーマット
入出力するメッセージのフォーマット
XML形式 or 固定長 or タグ・デリミター区切りなど
メッセージの仕様
（例：固定長区切りなら、エレメントごとのバイト数など）
メッセージフローで実施
する処理内容
アプリケーションを連携するために必要な処理
フォーマットの変換の有無
入力メッセージのフォーマットと出力メッセージのフォーマットの紐付け
宛先の決定ロジック
宛先は固定か、条件によって動的にルーティングが必要か
コード変換の有無
プロトコル変換の有無 （送受信プロトコル） など
順序性保証の有無
メッセージの処理順序を維持する必要性の有無
14
＜WMB実装入門ガイド＞
WMB処理要件例
今回は以下の処理要件を満たすメッセージ定義、フロー定義を開発してみましょう。
連携パターン
一方向型のメッセージング
1対1連携
1メッセージ単位での連携
メッセージ・フォーマット
入力メッセージ： 固定長メッセージ
出力メッセージ： XMLメッセージ
メッセージフローで実施
する処理内容
入力メッセージのデータをそのままXML形式に変換して出力
宛先は固定
送受信プロトコルはMQ
順序性保証
メッセージの処理順序保証は不要
上記の処理要件を満たすフローの流れは以下のようになります。
①キューからメッセージを取得し、入力メッセージ用のメッセージ定義を使用してメッセージをパースする。
②入力メッセージを宛先システムに合わせたメッセージフォーマットに変換する。
③キューに出力用メッセージを出力する。
15
＜WMB実装入門ガイド＞
WMB処理要件例
今回の入出力メッセージの仕様を表にまとめます。
入力メッセージ・フォーマット
出力メッセージ・フォーマット
入力メッセージ・フォーマット
（XMLメッセージ）
入力メッセージ・フォーマット
（固定長区切りメッセージ）
エレメント名
エレメント長
エレメント型
エレメント名 （タグ名）
エレメントの処理要件
Category
5バイト
String
Category
入力メッセージの値をセット
Item
10バイト
String
Item
入力メッセージの値をセット
Price
5バイト
String
Price
入力メッセージの値をセット
Number
5バイト
String
Number
入力メッセージの値をセット
フォーマット変換
<XML>
<Category>Food</Category>
<Item> Wine</Item>
<Price> 2300</Price>
<Num>12</Num>
</XML>
固定長区切りメッセージはバイト数で
各エレメントの区切りを判別
Food Wine
2300 12
以下の手順で開発をしていきます。
①メッセージ定義の作成
②メッセージ・フロー定義の作成
③実行環境（ブローカー）へのデプロイ
④テストの実施
次ページより、実際に開発の手順を詳細に解説します。
16
＜WMB実装入門ガイド＞
開発ツールの説明
メッセージ・ブローカー・ツールキットを使って開発をします。
ツールキットは開発環境だけでなく、ブローカー（実行環境）へのデプロイ操作やフローの開始/停止などの運
用管理機能も提供しています。
ツールキットのパースペクティブを切り替えて、開発や運用管理を実施します。
ツールキットで使用する主なパースペクティブは以下です。
：フローやメッセージ定義の開発時に使用
：デプロイやフローの開始/停止などに使用
–「ブローカー・アプリケーション開発」
–「ブローカー管理」パースペクティブ
–その他、「デバッグ」ビューなどを提供
※必要なパースペクティブが表示されないときは「ウィンドウ」→「パースペクティブを開く」から選択
←パースペクティブ
ここでパースペクティブを
切り替えて作業
「ブローカー・アプリケーション開発」パースペクティブを使用して、開発作業を行います。
17
＜WMB実装入門ガイド＞
メッセージ定義の作成手順
まず入出力メッセージ用のメッセージ定義を作成します。
メッセージの仕様はp16を参照
STEP1： メッセージ・セット・プロジェクトとメッセージ・セットの作成
メッセージ・セット・プロジェクトとメッセージ・セットは関連するメッセージ定義などを格納するフォルダのようなものです。
②「リソース・ナビゲータ」ペインで右クリック．
ポップアップ・メニューから「新規」→ 「メッセージ・セット」
を選択
①「ブローカー・アプリケーション開発」
パースペクティブを選択
③メッセージ・セット名、メッセージ・セット・
プロジェクト名を入力して「終了」
メッセージ・セット名：TEST_MSG_SET
メッセージ・セット・プロジェクト名：TEST_MSG_PJ
18
＜WMB実装入門ガイド＞
メッセージ定義の作成手順
④メッセージ・データのタイプを指定
今回はXMLと固定長データを扱うため、「XML文書」と
「バイナリー・データ」を選択し、「終了」
⑤開いたメッセージ・セット定義画面で
データ・タイプ名「バイナリー1」を
「CWF1」に変更
19
＜WMB実装入門ガイド＞
メッセージ定義の作成手順
STEP2： メッセージ定義ファイルの作成
メッセージ定義ファイルにメッセージ定義を実装していきます。
①「ブローカー開発」ペインで右クリックし、
ポップアップ・メニューから「新規」→
「メッセージ定義ファイル」を選択
②「メッセージ定義ファイル名」を入力し、
「終了」
メッセージ定義ファイル名：TEST_MSG
③メッセージ定義ファイルが作成される
（TEST_MSG.mxsd)
④ここでメッセージ定義を作成していく
20
＜WMB実装入門ガイド＞
メッセージ定義の作成手順
STEP3： メッセージ定義の作成
メッセージ定義では以下のものを作成します。
–メッセージと、メッセージに紐づく複合タイプ
–メッセージに含めるエレメント
–エレメントの属性 （単純タイプ、論理プロパティー、物理プロパティー）
①「メッセージ」フォルダーを選択して右クリック
「メッセージの追加」を選択
※メッセージの作成と共に、複合タイプが自動作成される
②作成されたメッセージ、タイプを右クリック
「名前の変更」を選択し、名前を設定
メッセージ名：TestMsg
タイプ名：TestMsgType
21
＜WMB実装入門ガイド＞
メッセージ定義の作成手順
③エレメントを作成する「タイプ」を右クリック
「ローカル・エレメントの追加」を選択し、エレメントを作成
エレメント名：Category
④同様にその他のエレメントも追加
エレメント名： Item
Price
Number
⑤エレメントのタイプの確認
全てのエレメントのタイプが「string」であることを確認
変更する場合は、エレメントを選択して、タイプをクリック.
プルダウン・メニューから、適切な単純タイプを選択
22
＜WMB実装入門ガイド＞
メッセージ定義の作成手順
STEP4： メッセージの仕様に合わせて、エレメントの論理プロパティと物理プロパティを設定
論理プロパティではエレメントの出現回数や入力値がヌルだった場合の対応などの設定を行います。
物理プロパティではエレメントごとに物理情報（固定長メッセージではバイト数、タグ・デリミタメッセージでは区切り文字な
ど）の設定を行います。
③設定する論理プロパティ、物理プロパティを選択
④今回は入力メッセージを固定長メッセージと
して扱うために、物理プロパティで「長さ」を指定
※出力用のXMLメッセージの物理プロパティは
特に設定不要
Category：5バイト
Item：10バイト
Price：5バイト
Number：5バイト
②「アウトラン・ビュー」で
プロパティを設定するリ
ソースを選択
①プロパティ・タブを選択
23
＜WMB実装入門ガイド＞
メッセージ定義の作成手順
入出力用のメッセージ定義が完成しました。
Ctrl
+ s でファイルを保存します。
–保存後、ファイル名の前にある”*”がなくなります。
24
＜WMB実装入門ガイド＞
メッセージ・フローの作成手順
次にメッセージ・フロを作成します。
フローの処理要件はp15を参照
STEP1： メッセージ・フロー・プロジェクトの作成
メッセージ・フロー・プロジェクトは関連するフロー定義などを格納するフォルダのようなものです。
①「ブローカー・アプリケーション開発」
パースペクティブを選択
②「リソース・ナビゲータ」ペインで右クリック．
ポップアップ・メニューから「新規」→
「メッセージ・フロー・プロジェクト」を選択
25
③プロジェクト名を入力して「次へ」
プロジェクト名：TEST_FLW_PJ
＜WMB実装入門ガイド＞
メッセージ・フローの作成手順
④「参照するプロジェクト」でメッセージ・セット・
プロジェクト「TEST_MSG_PJ」をチェックし
て「終了」
補足： プロジェクト参照
メッセージ・フローで使用するメッセージ定義を含むメッセージ・セット・プロジェクトに対し、プロジェクト参照の設定をします。
フローを開発する際に、プロパティの設定画面やESQLのコーディング時にメッセージ定義に関する入力補助機能が利用
でき、便利です。
26
＜WMB実装入門ガイド＞
メッセージ・フローの作成手順
STEP2： メッセージ・フローを作成するためのキャンバスを開く
フローを記述するためのキャンバスを開きます。
①メッセージ・フローを作成するプロジェクトを選択
②「リソース・ナビゲータ」ペインで右クリック．
ポップアップ・メニューから「新規」→
「メッセージ・フロー」を選択
③メッセージ・フロー名を入力して「終了」
フロー名：TEST1
27
＜WMB実装入門ガイド＞
メッセージ・フローの作成手順
補足： キャンバスの使い方
フロー作成用のキャンバスにノードを配置し、フローを作成していきます。
このノードといわれる処理部品は、キャンバスの左端のパレットに格納されています。
ここにフローを実装
パレットから使用するプロセス・ノードを
選択し、キャンバス上で左クリック
パレット上にノードを配置しながら、
WMBの処理を実装していく
28
＜WMB実装入門ガイド＞
メッセージ・フローの作成手順
STEP3： MQのキューからメッセージを取得する処理を実装します。
MQキューからメッセージを取得するためのノード「MQInput」ノードをキャンバスに配置します。
パレットの「WebSphere MQ」フォルダの下
MQInputノードでは以下のプロパティを設定します。
–メッセージを取得するMQキュー名
–メッセージをパースするための入力メッセージ用のメッセージ定義
※ キャンバス上に配置したノードをクリックすると画面下にプロパティの設定画面が表示されます。
タブ
基本
属性
キュー名(必須)
説明
メッセージの受信待機をするキュー
キュー名：TEST1_IN
入力メッセージの
構文解析
メッセージ・ドメイン
メッセージ・セット
メッセージ・タイプ
メッセージ形式
メッセージのパースに使用するメッセージ定義
メッセージ・ドメイン：MRM
メッセージ・セット：TEST_MSG_SET
メッセージ・タイプ：TestMsg
メッセージ形式：CWF1
29
←使用するパーサー名
←メッセージ・セット名
←メッセージ名
←物理プロパティ名
＜WMB実装入門ガイド＞
メッセージ・フローの作成手順
STEP4： 宛先システムに合わせてメッセージを変換
フォーマット変換用のESQLロジックを書くためのノード「Compute」ノードをキャンバスに配置します。
パレットの「変換」フォルダの下
Computeノードで設定するプロパティは今回は特にありません。
–Computeノードで実装する処理内容に応じて必要なプロパティを設定します。
（例えばDBアクセスするときはDB名をプロパティでセット）
Computeノードで宛先に合わせてメッセージを変換するためのESQLを実装します。
–ESQLとはWMBが提供するスクリプト言語です。
»開発者はメッセージやデータベースにアクセスするためのロジックを追加実装します。
»ESQLはプロセス・ノードに組み込まれます。
30
自動生成されたESQL
＜WMB実装入門ガイド＞
メッセージ・フローの作成手順
–Computeノードを右クリック→「ESQLを開く」でESQLの実装画面を開きます。
–Computeノードが自動で生成した入力メッセージをハンドリングするためのESQLが表示されます。
入力メッセージと出力メッセージの関係に応じて適切なESQL文のコメントを外します。
»入力メッセージをそのまま出力するときは
「CALL CopyEntireMessage( )」のコメントを外します。
»Computeノード内で出力用のメッセージを作成する場合は
「CALL CopyMessageHeaders( )」のコメントを外します。
ESQLを以下のように実装します
–今回はデータ・フォーマットは変換しますが、メッセージに含まれるエレメントや、値はそのまま入力メッセージを引き
継ぐため、 「CALL CopyEntireMessage( )」のコメントを外します。
–出力メッセージはXML形式で出力するため、以下の一文を追加します。
SET OutputRoot.Properties.MessageFormat = ‘XML1’;
コメントを外す
ESQL文を追加
31
＜WMB実装入門ガイド＞
メッセージ・フローの作成手順
STEP5： キューへメッセージを出力
キューからメッセージを取得するためのノード「MQOutput」ノードをキャンバスに配置します。
MQOutputノードでは以下のプロパティを設定します。
– メッセージを出力するMQキュー名
タブ
基本
属性
説明
キュー・マネージャー名
メッセージを出力する宛先のキュー・マネージャー名
キュー名：TEST1_OUT
キュー名
メッセージを出力する宛先のキュー名
32
＜WMB実装入門ガイド＞
メッセージ・フローの作成手順
STEP6： 配置したノードのターミナルの接続
各ノードは複数の入出力用のターミナルを装備しています。
–このターミナル間を接続することにより、処理のフローを実装します。
–ブローカーは処理フロー内の各ノードで実装した処理を順次実行していきます。
Failure
Failure
Out
Out、Out1~4
Catch
正常系の処理フローではノードの「Out」ターミナルと、次のノードの「In」ターミナルを接続していきます。
①接続元のプロセス・ノードの出力
ターミナル「Out」上で、左クリック
②接続先のプロセス・ノードの上で、
左クリック
33
＜WMB実装入門ガイド＞
メッセージ・フローの作成手順
メッセージ・フロー定義が完成しました。
Ctrl
+ s でファイルを保存します。
34
＜WMB実装入門ガイド＞
デプロイ手順
開発したメッセージ定義とメッセージ・フロー定義をブローカーにデプロイします。
開発物をコンパイル＆パッケージングし、ブローカー・アーカイブ・ファイル（BARファイル）を作成します。
作成したBARファイルを構成マネージャー経由でブローカーにデプロイします。
開発環境
実行環境
メッセージ・フロー
ブローカー・アーカイブ・ファイル
メッセージ・セット
コンパイル&パッケージング
構成マネージャー
ブローカー
デプロイ
STEP1: BARファイルを作成
①メッセージ・フロー・プロジェクトを選択して右クリックし、
「新規」→「Message Broker アーカイブ」を選択
35
②BARファイル名を設定して「終了」
BARファイル名：TEST_PJ_BAR
＜WMB実装入門ガイド＞
デプロイ手順
③BARファイルの「準備」タブで、デプロイする定義をチェックする
フロー定義： /TEST_FLW_PJ/TEST1.msgflow
メッセージ定義： /TEST_MSG_PJ/TEST_MSG_SET/messageSet.mset
④「ブローカー・アーカイブのビルド」ボタンを押す
⑤「管理」タブに移動し、デプロイする定義がBARファイルに
取り込まれたことを確認
⑥Ctrl + ｓで変更を保管
36
＜WMB実装入門ガイド＞
デプロイ手順
STEP2: BARファイルをブローカーにデプロイ
②「ブローカー・アーカイブ」フォルダの下の
TEST_PJ_BAR.barファイルを右クリックし、
「ファイルのデプロイを選択
①「ブローカー管理」パースペ
クティブに移動
③デプロイ先のブローカーと実
行グループを選択し、「OK」
④「ドメイン」ビューで③で指定した
ブローカーの実行グループの下に
フローとメッセージがデプロイされた
ことを確認
37
＜WMB実装入門ガイド＞
テストの実施
開発した定義をブローカーで動かしてみます。
テストの流れ
①TEST1.IN キューに入力用メッセージをPUTします。
②TEST1.OUT キューに出力用のフォーマットでメッセージが出力されていることを確認します。
GET
PUT
TEST1.OUT
GET
TEST1.IN
PUT
<XML><Category>Food</Category>
<Goods> Wine</Goods><Price> 2300</Price>
<Num>12</Num></XML>
Food△Wine△△△△△△2300△12△△△
※△はスペースを表す
ツール
or
MQアプリ
※事前に入出力用のキューをブローカーのキュー・マネージャー
上に作成しておく
ツール
or
MQアプリ
キューに対してメッセージをPUT/GETできるツールをご紹介します。
MQサポートパック
サポートパックIH03はGUIベースのMQテストツールを提供しており、テストする際に便利です。
http://www-1.ibm.com/support/docview.wss?rs=171&uid=swg24000637&loc=en_US&cs=utf-8&lang=en よりダウンロード可能
MQエクスプローラー
MQで提供しているGUIツールです。メッセージのPUT/GETだけでなく、MQオブジェクトに対する操作が可能です。
サンプルプログラム（amqsput / amqsget）
MQで提供しているサンプルプログラムです。ちょっとしたテストの時などに便利です（使用するテストメッセージ長に制約あり）。
38
＜WMB実装入門ガイド＞
まとめ
¾ 開発を始めるまえに、アプリケーションの連携パターン、入出
力メッセージの仕様、WMBでの処理要件を確定します。
¾ 開発の流れは、メッセージ定義の作成→フローの作成
→BARファイルの作成→ブローカーへのデプロイ→テスト。
¾ メッセージ・フローではプロトコル別に提供される入力ノード、
出力ノードの間に実行したい処理ノードを配置します。
39
＜WMB実装入門ガイド＞
ここからは、よくあるWMBの処理の実装例をご紹介します。
40
＜WMB実装入門ガイド＞
メッセージの変換
メッセージ変換の実装方法をみてみましょう。
入力メッセージ・ツリーを参照するなどして、出力用のメッセージ・ツリーを組み立てていきます。
出力時にパーサーがメッセージ・ツリーを物理メッセージに組み立てます。
メッセージ変換をESQLで実装できるのはComputeノードのみになります。
①出力メッセージで使用するメッセージ定義の指定方法
出力メッセージに入力メッセージとは異なるメッセージ定義を使用する場合は、メッセージ・ツリーのProperties
のエレメントに使用するメッセージ定義を指定します。
Propertiesの子エレメントであるMessageSet、MessageType、MessageFormat
セット
に出力用のメッセージ定義情報を
メッセージ・ツリー（論理メッセージ）
Root
MQMD
Properties
ここのメッセージ定義情報を見て、
パーサーは出力メッセージ用の
メッセージ定義を識別
MessageSet
MessageType
MessageFormat
（Domain）
StrucId
Order
Format
Order No
CodedCharSetId
Customer
Encoding
Name
Address
ESQLの実装例
SET OutputRoot.Properties.MessageSet = ‘MSGSET01’;
SET OutputRoot.Properties.MessageTYpe = ‘MSG01’;
SET OutputRoot.Properties.MssageFormat = ‘XML1’;
出力メッセージに使用する
メッセージ・セット名
メッセージ名
物理プロパティ名
[補足]
p31で実装したフローでは、入出力メッセージは共通のメッセージ・セット、メッセージを使用。
物理フォーマットのみ、CWF1（固定長）からXML1（XML)に変更したため、ESQLではMessageFormatの設定のみを実装。
41
＜WMB実装入門ガイド＞
メッセージの変換
②出力メッセージのデータ部の組み立て
まず、メッセージ・ツリーのエレメントへのアクセス方法を見てみましょう。
ESQLでエレメントの値にアクセスするには、ツリーの上部から下方に向かって、エレメントの親子関係をたどります。
相関名から開始して、エレメント名をドット（．）で区切ります。
メッセージ・ツリー（論理メッセージ）
Root
Properties
MessageSet
MessageType
MessageFormat
MQMD
MRM
この値にアクセスするには
Root.MRM.Order.OrderNo
StrucId
Order
Format
OrderNo
CodedCharSetId
Customer
Encoding
Name
Address
この値にアクセスするには
Root.MRM.Order.Customer.Name
出力用のメッセージ・ツリーに値を設定するには、SETステートメントを使用します。
【使用例】
SET OutputRoot.MRM.Order.OrderNo = ‘261’;
解説： このESQL文では出力メッセージのOrderNoの値として「261」をセット
SET OutputRoot.MRM.Order.OrderNo = ‘JPN’ || InputRoot.MRM.Address.OrderNo;
解説： このESQL文では出力メッセージのOrderNoの値としてキーワード「JPN」の後に入力メッセージに
セットされていたOrderNo値をセット
入力メッセージのOrderNoの値が「261」だと、出力メッセージのOrderNoの値は「JPN261」
[補足]
Computeノードは入力と出力のツリーを区別し、Input・Outputのプレフィックスが付きます。
42
＜WMB実装入門ガイド＞
文字コードの変換
コード変換の実装方法をみてみましょう。
WMBのコード変換の動き
メッセージ・ツリーのコード・ページはUNICODEです。
・MQメッセージをパースするとき、文字フィールドをMQMD.CodedCharSetId－＞UNICODEにコード変換
・MQメッセージを組み立てるとき、文字フィールドをUNICODE－＞MQMD.CodedCharSetIdにコード変換
メッセージ・ツリーのMQヘッダー部に出力メッセージのコード・ページを指定します。
データ部のコード・ページ（CCSID)をMQMD.CodedCharSetIdに設定するのがMQのルール
MQMDの子エレメントであるCodedCharSetId、Encodingに、物理メッセージに組み立てるときのコード・ページ(CCSID)、
エンコーディング値（BigEndian / LittleEndian)を設定
メッセージ・ツリー（論理メッセージ）
Root
MQMD
Properties
ここのコード・ページ情報を見て、
メッセージ出力時にコード変換が行
われる
MessageSet
MessageType
MessageFormat
ESQLの実装例
SET OutputRoot.MQMD.CodedCharSetId = 5026;
43
（Domain）
StrucId
Order
Format
Order No
CodedCharSetId
Customer
Encoding
Name
Address
＜WMB実装入門ガイド＞
その他の考慮点
44
＜WMB実装入門ガイド＞
ここからは、処理要件以外でメッセージフローの実装に影響する
項目について確認していきます。
必要に応じて、前項で作成したフローにノードを追加していきます。
45
＜WMB実装入門ガイド＞
メッセージフローの設計
メッセージフローを設計する上で、処理要件以外の以下の項目を検討する必要があります。
検討項目
検討内容
トランザクションの整合性
フローで実施するリソース更新のトランザクションの整合性
複数のリソース更新の整合性
エラー発生時の整合性の維持
エラー処理
フローの処理中に発生したエラーのハンドリング方法
DBやキュー・メッセージに対する更新処理のバックアウト
アプリケーション・エラー・ログの取得
エラー用キューへのメッセージ出力、など
46
＜WMB実装入門ガイド＞
トランザクションの整合性
メッセージフローが行うリソース更新をトランザクション処理するかどうかを決定します。
メッセージの送受信やデータベース更新など一連のリソース更新を1つの処理単位としてコミット／バックアウ
トするかを決定します。
トランザクション処理しない場合
リソース更新は実施したタイミングで即時に反映されます。
フローの途中でエラーが発生しても、それまでの更新処理は有効
トランザクション処理する場合
フロー処理の成否によって、一連のリソース更新を反映するかどうかを決定します。
フローが正常終了するとトランザクションをコミットする。
フローの途中でエラーが発生するとトランザクションをバックアウトし、それまでのリソース更新処理を全て無効にする。
MSG受信
DB更新
トランザクション
47
MSG送信
コミット／バックアウト
＜WMB実装入門ガイド＞
メッセージフローのトランザクション
メッセージフローのトランザクション処理には2つのタイプがあります。
ブローカー整合
MQ処理とDB処理を別トランザクションとして管理します。
メッセージフローが成功するとSQL
COMMITとMQCMITでデータベースとMQを個別にコミット
データベースのコミットを先に実行
SQL.UPDATE
MQGET
SQL.COMMIT
MQPUT
MQCMIT
グローバル整合
MQ処理とDB処理を1つのトランザクションとして管理します。
MQをコーディネーターとした2フェーズ･コミット処理を実施
MQBEGIN
Trx開始
MQGET
48
SQL.UPDATE
MQPUT
MQCMIT
Trx終了
＜WMB実装入門ガイド＞
（補足）トランザクション設定
ブローカー整合の設定箇所
ノードの「トランザクション･モード」プロパティ
設定値によってトランザクション処理の動作は異なる
デフォルトの設定で、トランザクション処理実施
「トランザクション・モード」プロパティの設定値（下線がデフォルト）
設定値
MQInputノード
MQOutputノード
自動
パーシステント・メッセージはトランザクション処理する
MQInputノードの決定に従う
はい
トランザクション処理する
トランザクション処理する
いいえ
トランザクション処理しない
トランザクション処理しない
設定値
データベース・アクセス･ノード（Databaseノード、ほか）
自動
ブローカーにコミットを任せる
コミット
ノード通過時に即時にコミット
49
＜WMB実装入門ガイド＞
（補足）トランザクション設定
グローバル整合の設定箇所
メッセージフローの実行時属性「整合トランザクション」
BARファイルの構成タブで設定
デフォルトは、チェックなし
ノードの「トランザクション･モード」プロパティの設定はブローカー整合のときと同様に必要
キューマネージャーをコーディネーターとするMQレベルの設定も必要
詳細は、Information Centerを参照
http://publib.boulder.ibm.com/infocenter/wmbhelp/v6r1m0/topic/com.ibm.etools.mft.doc/ae83280_.htm
BARファイルの構成タブ
50
＜WMB実装入門ガイド＞
エラー処理
エラー処理の概要
エラーの種別には以下の2つがあります。
ユーザー･エラー
メッセージのフィールド値が業務で決められた範囲にないなど
システム･エラー
キューのPUT／GET失敗、メッセージのパース／組立失敗、データベース・アクセス失敗、ESQL実行の失敗など
システム･エラーは各々の処理ノードが例外として報告します。
メッセージフローのデフォルトのエラー処理では、トランザクションのバックアウトとエラー･ログの出力を実行します。
例外を捕捉して独自のエラー処理ロジックを実行することも可能です。
Catchターミナル（MQInput/TryCatchノード）、Failureターミナル（MQInputノード以外）を利用
ユーザー･エラーでは例外は報告されません。（デフォルトの動作）
フローの中でメッセージを検査し、エラー処理フローに分岐するなどの対応が必要です。
メッセージの妥当性検査を使用すれば、一部のユーザー･エラーは例外として報告させることが可能です。
・フィールドの単体値の検査のみ（最小値、最大値、最小長、最大長、ヌル許可 など）
・複数のフィールドに関連した検査はできません。
エラー処理の実装は、トランザクションの整合性にも影響します。
メッセージ･フローのエラー時の動作を正しく理解して、適切なエラー処理を実装する必要があります。
51
＜WMB実装入門ガイド＞
エラー時の動作
まずは、メッセージフローのエラー時の動作について確認します。
メッセージフローはノード処理にてエラーが発生すると例外を生成します。
同時に、例外ツリー（ExceptionList）を作成し、エラー情報をセットします。
制御は、MQInputノードに向かって遡ります。
デフォルトのフローでは、制御はMQInputノードまで戻り、
トランザクションのバックアウトとエラーログの出力が行われます。
メッセージは入力キューにバックアウトされます。
エラーログの出力先
例外ツリーを基にエラーログが出力されます。
Windwos
イベント・ログ
UNIX、Linux
syslog
例外ツリー
①エラー発生
⑤制御がMQInputノードまで戻ると、
トランザクションのバックアウト、および
エラーログの出力
④制御が遡る
②例外生成
③例外ツリーの作成
52
ExceptionList
RecoverableException
＜WMB実装入門ガイド＞
エラー処理の基本
エラー処理の基本
Failureターミナル
Catchターミナル、Failureターミナルで例外を捕捉することが可能です。
例外が捕捉されると、ターミナルの先に処理が移動します。
Catchターミナル
（CatchターミナルとFailureターミナルの違いは次ページの補足参照）
エラー処理はこれらのターミナルの先に実装します。
エラー処理の要件によってどのノードのどのターミナルを使用するかを決定します。
通常は、MQInputノードのCatchターミナルで後続ノードで発生する全ての例外を捕捉します。
例外を捕捉した場合、「トランザクションの整合性」、「エラーログの出力」はユーザー責任になります。
エラー処理が成功するとトランザクションはコミットされます。
※バックアウトされません。
⇒バックアウトさせるために、Throwノードを使用し明示的に例外を生成させることができます。（p56補足参照）
エラーログも出力されません。
生成された例外ツリーは参照可能です。
⇒Traceノードでダンプ可能（p57補足参照）
④例外をCatch
ターミナルで捕捉
③制御が戻る
①エラー発生
②例外ツリー生成
⑤制御がターミナル
の先に移動
※トランザクションはバックアウトでなく、コミットされることに注意
上図の場合、メッセージ受信処理やDB処理はコミットされてしまう
53
＜WMB実装入門ガイド＞
（補足）Catch／Failureターミナル
CatchターミナルとFailureターミナルの違い
Catchターミナル（MQInput／TryCatchノード）
後続処理でのすべての例外を捕捉します。
例外を捕捉したエラー処理での例外も捕捉します。
Failureターミナル
エラーキュー
接続されたノードでの例外だけを捕捉します。
後続のノードで発生した例外は捕捉しません。
MQInputノードではバックアウトされたメッセージも
条件によって捕捉します。（p55補足参照）
②Catchターミナルで
例外を捕捉
エラーキュー
出力キュー
①エラー発生
後続ノードで発生した例外は
このFailureターミナルでは捕捉されない
エラーキュー
②Failureターミナル
で①の例外を捕捉 ③エラーキュー出力
でも失敗
④Catchターミナルで③の
例外を捕捉
エラーキュー
出力キュー
①Computeノードで
エラー発生
54
＜WMB実装入門ガイド＞
（補足）MQInputノードの処理
MQInputノードの処理
受信メッセージのBackoutCountとキューのBOTHRESH属性の値を比較し、出力先を決定します。
Failureターミナルの接続有無やキューのBOQNAME属性、キューマネージャーのDEADQ属性の設定によって、
出力先（ターミナル、キュー）は異なります。
BOTHRESH属性が0（デフォルト）の場合、フローはBOTHRESH=1として処理します。
MQInputノード
BackoutCount < BOTHRESH
BackoutCount ： BOTHRESH？
BackoutCount >= BOTHRESH
Failureターミナルが
接続されている？
NO
BOQNAMEが定義されている？
Outターミナルへ
（正常処理フロー）
YES
エラー処理で例外が発生した場合
Failureターミナルへ
（エラー処理フロー）
BackoutCount < BOTHRESH×2 ⇒バックアウト
BackoutCount >= BOTHRESH×2
YES
MQPUTに失敗した場合
指定されたキューへPUT
NO
DEADQが定義されている？
YES
MQPUTに失敗した場合 ⇒バックアウト
DEADQへPUT
NO
※バックアウトされたメッセージは入力キューに戻り、
1秒後に再処理されます。
バックアウト
55
＜WMB実装入門ガイド＞
（補足）エラー処理に関連した機能
Throwノード
例外を生成します。
エラー処理にて明示的に例外を発生させる場合や
ユーザー・エラー時に例外を生成させる場合などに利用できます。
（※）ESQLのTHROWステートメントでも
明示的に例外を生成することが可能です。
属性
説明
メッセージ・カタログ
生成した例外がローカル・エラー・ログに出力されるときに参照されるカタログ
(デフォルトはシステム提供のカタログ ）
メッセージ番号
システム提供カタログでは3001～3049を使用 (下記のメッセージを出力)
メッセージ・テキスト
挿入するメッセージ・テキスト (下記メッセージの<insert_0>を置き換え)
BIP3001I Exception thrown by throw node '<insert_1>'; text is '<insert_0>'.
Explanation
The throw node '<insert_1>' has received a message and thus has thrown an exception
as this is its normal behavior. The message text associated with this exception is
'<insert_0>'.
Response
Since this is application generated (by message flow behavior), the user action is
determined by the message flow and the type of exception generated.
3001～3049まで同一メッセージ
56
＜WMB実装入門ガイド＞
（補足）エラー処理に関連した機能
Traceノード
システム・ログなどにメッセージやエラー情報等を書き出すことができます。
属性
説明
宛先
情報の書き出し先 (下記から選択)
・「ローカル・エラー・ログ」 システム・ログ(イベント・ログ、または、syslog)
・「ユーザー・トレース」
メッセージ・フローのトレース・ファイル
・「ファイル」
ユーザーが指定したファイル
ファイル・パス
ファイル名（「宛先」で「ファイル」を選択したときに指定）
メッセージ・カタログ
ローカル・エラー・ログ、ユーザー・トレースに情報を出力するときに参照され
るカタログ
（デフォルトはシステム提供のカタログ ）
メッセージ番号
システム提供カタログでは3051～3099を使用
パターン
挿入するメッセージ・テキスト (下記メッセージの<insert_0>を置き換え)
BIP3051E Error message '<insert_0>' from trace node '<insert_1>'.
Explanation
The trace node '<insert_1>' has output the specified error message.
Response
This is an error message provided by the message flow designer. The user
response will be determined by the local environment.
3051～3099まで同一メッセージ
57
＜WMB実装入門ガイド＞
（補足）エラー処理に関連した機能
パターンの記述 例
Message passed through with the following fields:
Store name is ${Body.storedetailselement.storename}
Total sales are ${Body.totalselement.totalsales}
Time is: ${EXTRACT(HOUR FROM CURRENT_TIMESTAMP)}:${EXTRACT(MINUTE FROM CURRENT_TIMESTAMP)}
任意のテキスト、および、ESQL表現を記述
ESQL表現は${
}で括る
${Root} や ${ExceptionList}で論理メッセージ全体のダンプも可能
58
＜WMB実装入門ガイド＞
エラー処理の実装例
エラー処理の実装は、エラー時に求められる処理要件によって異なります。
エラーの種別や発生箇所によってエラー処理を変えるか
メッセージの内容やエラー情報をダンプするか ダンプする場合はどこに出力するか
メッセージはエラーキューに出力するか、など
今回は以下の要件に従ってp34で作成したフローにエラー処理を追加してみましょう。
※トランザクションについてはデフォルトの設定のままで「ブローカー整合」のトランザクション処理を実施する
MQInputノード以降で発生した例外はすべて共通のエラー処理を実施する
⇒例外は全てMQInputノードのCatchターミナルで捕捉する
（他ノードのFailureターミナルやTryCatchノードは使用しない）
エラー処理では、例外ツリーの情報やメッセージの内容をファイルにダンプする
⇒Traceノードを使用する
トランザクションはバックアウトさせるため、エラー処理の最後にThrowノードを配置する
バックアウトされたメッセージはエラーキューに出力する
⇒MQInputノードのFailureターミナルの先でMQOutputノードを利用し、
バックアウトされたメッセージをエラーキューに出力する
⇒FailureターミナルにはMQInputノードで発生した例外も捕捉されるため、
Traceノードを利用し例外ツリーのダンプ処理も組み込む
59
＜WMB実装入門ガイド＞
エラー処理の実装手順
STEP1：Catchターミナルの実装
MQInputノード以降で発生した例外を捕捉するため、
MQInputノードのCatchターミナルの先にエラー処理を実装します。
エラーが発生したメッセージの内容や例外ツリーをファイルにダンプするため
「Trace」ノードを使用します。
「構造」パレットから「Trace」ノードをキャンパスに配置
MQInputノードのCatchターミナルの先に接続
プロパティの設定
タブ
基本
属性
設定値
宛先
ファイル
ファイル･パス
C:¥wmb_logs¥wmb_error.log
パターン
*******************************************
TIME : ${CURRENT_TIMESTAMP}
ERR_MSG : ${ExceptionList}
MESSAGE : ${Root}
※「ファイル･パス」や「パターン」は
任意に設定可能です。
左表のパターン例ではノード通過時の
タイムスタンプ、例外ツリー、メッセージ･
ツリーを出力しています。
トランザクションを明示的にバックアウトさせるため「Throw」ノードを使用し例外を発生させます。
「構造」パレットから「Throw」ノードをキャンパスに配置
Traceノードの先に接続
プロパティの設定は特になし
60
＜WMB実装入門ガイド＞
エラー処理の実装手順
STEP2：Failureターミナルの実装
MQInputノードで発生した例外およびバックアウト･メッセージを処理するため
MQInputノードのFailureターミナルの先にもエラー処理を実装します。
MQInputノードで生成された例外ツリーをファイルにダンプするため
「Trace」ノードを使用します。
「構造」パレットから「Trace」ノードをキャンパスに配置
MQInputノードのFailureターミナルの先に接続
プロパティの設定
タブ
基本
属性
設定値
宛先
ファイル
ファイル･パス
C:¥wmb_logs¥wmb_error.log
パターン
*******************************************
TIME : ${CURRENT_TIMESTAMP}
ERR_MSG : ${ExceptionList}
エラーキューに出力するため「MQOutput」ノードを使用します。
「WebSphere
MQ」パレットから「MQOutput」ノードをキャンパスに配置
「Trace」ノードの先に接続
プロパティの設定
タブ
基本
属性
キュー名
設定値
任意のエラーキュー名
61
※MQInputノードのFailureターミナルには、
パースに失敗したメッセージも流れるため、
メッセージ･ツリーのダンプは行わない。
（ダンプにも失敗する可能性があるため）
＜WMB実装入門ガイド＞
エラー処理の実装手順
フローは以下のようになります。
変更したフローをブローカーにデプロイし、テストを実施します。（p35～参照）
出力キューをPUT禁止にして故意にエラーを発生させ、意図通りの動きをするか確認してみましょう。
ダンプさせたメッセージやエラー情報についても確認してみましょう。
⑤バックアウト
⇒再処理
⑥Failureターミナル ⑦例外ツリーダンプ、エラーキューへ出力
に移動
エラーキュー
出力キュー
入力キュー
①PUT失敗、例外発生
②Catchターミナルで
例外捕捉
③メッセージと
例外情報をダンプ
④トランザクション
のバックアウト
62
＜WMB実装入門ガイド＞
まとめ
¾ メッセージフローの実装の際は、トランザクションの整合性や
エラー処理についても検討します。
¾ エラー時の動作をよく理解してエラー処理を実装する必要が
あります。
63
＜WMB実装入門ガイド＞
フロー実装のテクニック
64
＜WMB実装入門ガイド＞
ここからは、メッセージフロー実装のテクニックについて紹介します。
始めは、リクエスト／リプライ型のフローの実装について
見ていきます。
65
＜WMB実装入門ガイド＞
リクエスト／リプライ型の実装
リクエスト／リプライ型メッセージフローの実装
一方向型の要求メッセージを処理するフローと応答メッセージを処理するフローを
それぞれ個別に作成するのが一般的です。
要求メッセージと応答メッセージの紐付けには、MsgID／CorrelIDを利用します。
通常、MQのクライアント／サーバ･アプリケーションではこれらのIDで紐付けるため、
ブローカーでも同様の仕組みを利用します。
メッセージフローでは受信したメッセージのMsgID／CorrelIDをそのまま出力するメッセージにコピーして送信します。
ユニークなMsgIDをセットして
要求メッセージを送信
クライアントAPPL
MsgIDをコピーして送信
MsgID：111
要求処理フロー
サーバーAPPL
MQGET
wait
MsgID：111
MQPUT
処理
Copy MsgId
to CorrelId
MQGET
wait
MQPUT
CorrelD指定で
受信待ち
CorrelID：111
応答処理フロー
CorrelDをコピーして送信
66
CorrelID：111
要求メッセージのMsgIDを
応答メッセージのCorrelIDに
セットして送信
＜WMB実装入門ガイド＞
リクエスト／リプライ型の実装
応答処理フローでは、応答メッセージの送信先を特定する必要があります。
通常、クライアントアプリケーションは応答先情報を要求メッセージのMQMDのReplyToQ／ReplyToQMgrに
セットします。
しかし、サーバ側に転送されるときにはReplyToQ／ReplyToQMgrは応答処理フローの入力キュー情報に付
け替えられます。（MQのサーバ･アプリケーションの作りとしてこのプロパティの情報を基に応答メッセージを返すこ
とが一般的である為）
従って、応答処理フローは何らか仕組みで応答メッセージの送信先を特定する必要があります。
要求メッセージの応答先情報
応答先情報を応答処理フローの入力
キューに付け替え
ReplyToQMgr ： CLNT_QMGR
ReplyToQ
： REPLYQ
クライアントA
要求メッセージの応答先情報
ReplyToQMgr ： WBIMB_QMGR
ReplyToQ
： INPUTQ
MQGET
wait
要求処理フロー
MQPUT
処理
Copy MsgId
to CorrelId
MQGET
wait
クライアントAの応答キュー：
REPLYQ＠CLNT_QMGR.A
MQPUT
応答処理フロー
フローの入力キュー：
INPUTQ＠WMB_QMGR
クライアントB
MQPUT
サーバーAPPL
応答先情報を本来の応答キューに付け替え
MQGET
wait
応答メッセージと本来の応答先を紐付けるための仕組みが必要となる
クライアントBの応答キュー：
REPLYQ＠CLNT_QMGR.B
67
＜WMB実装入門ガイド＞
応答先情報の引継ぎ方法
応答先情報の特定方法として以下の方法が考えられます。
メッセージ内に保存して引き継ぐ
要求処理フローで、ReplyToQ／ReplyToQMgrの情報をメッセージ内の他のフィールドに移します。
・MQMDの空きフィールドに保存
： ApplIdentityData(MQCHAR32)の利用がお勧めです。
ユーザー・データ
MQMD
・ユーザー・ヘッダーのフィールドに保存
MQMD
ユーザー・ヘッダー
ユーザー・データ
サーバー・アプリケーションでは、応答先情報を持ち回るように作成する必要があります。
応答処理フローではメッセージの中から応答先情報を取得し、応答メッセージを送信します。
データベースに保存して引き継ぐ
要求処理フローで、MsgIdをキーにして応答先情報を保存します。
MQMD.MsgId（キー値）、ReplyToQ、ReplyToQmgr、タイムスタンプ
応答処理フローで、MQMD.CorrelIdの値を使って応答先情報を取得します。（同時にレコードを削除します。）
応答処理フローにメッセージが戻らないと、データベースに応答先情報が残ってしまうため、
タイムスタンプを参照し、一定時間を経過しているレコードの削除処理が必要になります。
メッセージ内に保存して持ちまわる方法が単純でお勧め
68
＜WMB実装入門ガイド＞
応答情報の引継ぎ例
応答情報の引継ぎ例 ： MQMD.ApplIdentityDataを利用する場合
要求処理フローで必要なESQL、設定は以下になります。
16バイト
16バイト
ReplyToQ
ReplyToQMgr
ApplIdentityDataは32バイトしかないため、ReplyToQとReplyToQMgrが収まるように
16バイトずつ使用するなどの調整が必要です。
ComputeノードのESQL
SET OutputRoot.MQMD.ApplIdentiryData =
OVERLAY(OutputRoot.MQMD.ApplIdentiryData PLACING TRIM(InputRoot.MQMD.ReplyToQ FROM 1);
SET OutputRoot.MQMD.ApplIdentiryData =
OVERLAY(OutputRoot.MQMD.ApplIdentiryData PLACING TRIM(InputRoot.MQMD.ReplyToQMgr FROM 17) ;
SET OutputRoot.MQMD.ReplyToQ = ‘xxxxxx’
SET OutputRoot.MQMD.ReplyToQMgr = ‘’
//応答処理フローの入力キュー
//MQPUTでのデフォルト設定に任せる
コンテキスト情報（ApplIdentityData）を引き継ぐため、
MQOutputノードの「メッセージ･コンテキスト」を
「すべて設定」に設定します。
メッセージ・コンテキスト：「すべて設定」
MQPMO_SET_ALL_CONTEXTでPUT
69
＜WMB実装入門ガイド＞
応答情報の引継ぎ例
応答処理フローで必要なESQL、設定は以下になります。
応答メッセージのMQMD.ApplIdentityDataからReplyToQ、ReplyToQMgrをセットします。
ComputeノードのESQL
SET OutputRoot.MQMD.ReplyToQ =
SUBSTRING(InputRoot.MQMD.ApplIdentiryData FROM 1 FOR 16);
SET OutputRoot.MQMD.ReplyToQMgr =
SUBSTRING(InputRoot.MQMD.ApplIdentiryData FROM 17 FOR 16) ;
MQOutputノードの「宛先モード」を「応答先キュー」に
設定して応答メッセージを返却します。
宛先モード：「応答先キュー」
MQMD.ReplyToQにメッセージをPUT
70
＜WMB実装入門ガイド＞
まとめ
¾ リクエスト／リプライ型も要求用、応答用をそれぞれ一方向型フ
ローで実装するのが一般的です。
¾ 要求メッセージと応答メッセージの紐付けは、MsgId／CorrelId
を利用します。
¾ 応答先情報はメッセージ内に持ちまわるのがお勧めです。
71
＜WMB実装入門ガイド＞
次はメッセージフローの実装単位について見てみましょう。
72
＜WMB実装入門ガイド＞
メッセージフローの実装単位
メッセージフローの実装単位
当資料で作成したメッセージフローは、MQInputノードに受信するメッセージのフォーマットを指定したため、
1つのフォーマットしか処理できません。
この方法では、受信メッセージのフォーマットの数だけメッセージフローを用意する必要があります。
ここでは、複数フォーマットのメッセージを1つのメッセージフローで処理するための実装方法を紹介します。
メッセージのフォーマット毎に専用のメッセージフローを作成する場合と複数のフォーマットのメッセージを処理
可能な汎用メッセージフローを作成する場合のどちらも、メリット、デメリットがあります。
どちらのタイプのメッセージフローを作成するかは、これらのメリット、デメリットを理解して決定する必要があり
ます。
73
＜WMB実装入門ガイド＞
汎用メッセージフローの実装
異なるフォーマットのメッセージを処理可能なフローの実装例
※前提として、各フォーマットの共通部分（MQMD、ユーザヘッダ部など）にフォーマットを識別するIDが必要です。
各フォーマットのメッセージ定義、およびフォーマットの共通部分を定義したメッセージ定義を用意します。
フォーマットの異なる部分は可変長バイナリデータ（BLOB）として定義します。
MQInputノードでは共通フォーマットのメッセージ定義でパースし、
後続ノードでフォーマット識別IDを確認します。
フォーマット識別IDに従って処理を分岐させます。
⇒RouteToLabelノード、Labelノードを利用します。（p75）
分岐した先で個別フォーマットのメッセージ定義を使って再パースします。
⇒フローの途中で再度パースするためResetContentDescriptorノードを利用します。（p76）
MQMD
ユーザヘッダ
BLOB
共通フォーマットのメッセージ定義でパース
フォーマット識別IDに従って処理を分岐
A
B
MQMD
ユーザヘッダ
ユーザデータA
個別のメッセージ定義で再パース
MQMD
74
ユーザヘッダ
ユーザデータB
＜WMB実装入門ガイド＞
（補足）RouteToLabel／Labelノード
RouteToLabel／Labelノードを利用したフロー分岐の実装
LocalEnvironmentの設定に基いて、
RouteToLabelノードからLabelノードへ処理を移動させることができます。
ノード間を線で接続する必要がなく、分岐が多数ある場合に視覚的に見易いフローを実装可能です。
実装方法
RouteToLabelノードの前でLocalEnvironmentの下記エレメントに移動先（ラベル名）を指定します。
LocalEnvironment.Destination.RouterList.DestinationData.labelname
各Labelノードの「ラベル名」プロパティにはLocalEnvironmentの指定と一致するラベル名を設定します。
IF （条件） THEN
SET OutputLocalEnvironment.Destination.RouterList.DestinationData.labelname = (ラベル名)
END-IF;
LocalEnvironmentに
移動先のラベル名を
指定
指定されたラベル名の
ノードへ処理が移動
Labelノードの「ラベル名」プロパティに
ラベル名を設定
75
＜WMB実装入門ガイド＞
（補足）メッセージの再パース
ResetContentDescriptorノードを利用したメッセージの再パース
メッセージフローの途中で、ノードに設定されたメッセージ定義に基づいてメッセージを再パースします。
BLOB
プロパティ
「メッセージ・ドメイン｣、｢メッセージ・セット｣、｢メッセージ・タイプ｣、｢メッセージ形式｣
メッセージ定義を指定します。（MQInputノードと同じ）
「xxxxのリセット」
設定したメッセージ定義を有効にするためにチェックします。
76
XML
＜WMB実装入門ガイド＞
汎用メッセージフローのメリット／デメリット
複数のメッセージ・フォーマットを処理する汎用的なメッセージ・フロー
メリット
メッセージ種別が多くても、フローの数を抑えられるので少ないメモリ・リソースで稼動可能
・メッセージフロー・インスタンス単位でMQ、データベースに接続
同一のメッセージ・フロー・インスタンスからの同一データベース接続は1つだけ
・将来的にメッセージ種別が追加されても、メモリ・リソースへの影響は少ない
拡張性が高い
・フォーマットが増えても入力キューを追加する必要はない
パフォーマンス調整が専用メッセージフローと比較して容易
デメリット
メッセージの中にメッセージ種別の情報が必要
・メッセージ種別の情報をもたない既存の送信アプリケーションは改修が必要
複数の開発者が同時に開発するための考慮が必要
PUT禁止によって特定メッセージ種別の処理を停止したければ、別名キューの定義が必要
入力キュー障害の影響範囲が大きい
MSG_01
MSG_02
MSG_03
メッセージフローをどのようなグループにまとめるかは検討が必要
77
＜WMB実装入門ガイド＞
専用メッセージフローのメリット／デメリット
メッセージ種別ごとに専用のメッセージ・フロー
メリット
メッセージ内にメッセージ種別を識別する情報をもたなくてよい
・メッセージ種別の情報をもたない既存の送信アプリケーションの改修が不要
複数の開発者がそれぞれ独立してメッセージ・フローを開発可能
入力キューのPUT禁止によって、メッセージ種別ごとに処理の停止が可能
入力キュー障害によって影響を受けるのは、該当のメッセージ種別のみ
デメリット
メッセージ種別が多くなると、フローの数が増え、メモリ・リソースも多く使用
・各メッセージフロー・インスタンスがMQ（、データベース）との接続を確立
・将来的にメッセージ種別の追加が予想される場合は、そのリソースも考慮
パフォーマンス調整がしにくい
・各フローのパフォーマンス要件やトランザクション量に応じて、それぞれのフローの稼動インスタンス数を調整する必要があ
る
・ほとんど処理が発生しないフローも稼動させておく必要がある
MSG_01
MSG_02
MSG_03
78
＜WMB実装入門ガイド＞
まとめ
¾ 専用メッセージフローではフォーマットの数だけメッセージフローを
作成する必要があります。
¾ 汎用メッセージフローを作成するにはメッセージ内にフォーマット
を識別するIDが必要となります。
¾ 専用メッセージフロー、汎用メッセージフロー、どちらもメリット、
デメリットがあります。
79
＜WMB実装入門ガイド＞
最後にメッセージフローのネスティングの方法について
見てみましょう。
80
＜WMB実装入門ガイド＞
メッセージフローのネスティング
メッセージフローの一部分を別のメッセージフロー（サブフロー）として作成することができます。
共通のエラー処理などをサブフロー化し、再利用可能な共通部品を作成できます。
大きなメッセージフローを複数のサブフローに分けて開発ができます。
入力ノード／出力ノードをサブフローの入口点／出口点とします。
作成したサブ・フローをメイン・フローにドラッグ & ドロップすると
1つのノードとして現れます。
サブ・フロー
81
＜WMB実装入門ガイド＞
メッセージフローのネスティング
サブフロー内の入力／出力ノードは、上位のフローの中でノードのターミナルとして現れます。
ターミナル名は入力／出力ノードに付けた名前になります。
「入力」
ターミナル
サブ・フロー
「出力」
ターミナル
サブフロー内に配置できる入力／出力ノードの数に制約はありません。
上位のフローに展開されたときに、正しいメッセージフローになっていればよいです。
サブフロー内に複数の入力／出力ノードを配置することも可能です。
入力ノードがないサブフローも作成可能です。
例：入り口点がLabelノードになっているサブフロー
ネスティングの階層数に制限はありません。
ただし、通常は2、3階層まででそれ以上階層数を増やしても処理内容が分かりにくくなるので注意が必要です。
82
＜WMB実装入門ガイド＞
メッセージフローのネスティング
サブフローの利用例
大規模メッセージフローを複数ユーザーで並行開発できます。
前述の「汎用メッセージフローの実装例」にサブフローを適用した例
サブフローとして作成
分担して、
並行開発可能
83
＜WMB実装入門ガイド＞
まとめ
¾ 共通処理部分をサブフロー化することで再利用が可能となりま
す。
¾ 大きなメッセージフローを複数のサブフローに分けることで
並行開発が可能になります。
84
＜WMB実装入門ガイド＞
参考資料
WebSphere Developer Domain
WebSphere Message Broker V6.1 概説資料
http://www-06.ibm.com/jp/software/websphere/developer/bi/mbv61/
マニュアル
WebSphere Message Broker Version 6.1 Information center
http://publib.boulder.ibm.com/infocenter/wmbhelp/v6r1m0/index.jsp
ワークショップ資料
WebSphere Message Broker v6.1 アップデート・ワークショップ
http://w306.ibm.com/jp/domino02/ise/ISEINFO.NSF/e7aef50b5a652b31492563fd002500a3/2671e6ed4c5cb14c4
92573a8000ae345?OpenDocument
85