Message Queue受付を使用したサービス部品の呼び出し

Message Queue受付を利用することで，JMSプロバイダのメッセージキュー（IBM WebSphere MQ）からMQリソースアダプタを介してビジネスプロセスを呼び出すことができます。

Message Queue受付を使用したサービス部品呼び出しの流れを次の図に示します

図2-82　Message Queue受付を使用したJMSプロバイダ（メッセージキュー）からのサービス部品の呼び出し

[図データ]

Message Queue受付は，MQリソースアダプタを経由して要求電文を受け付けます。サービス部品の実行要求を受け付けたMessage Queue受付は，ビジネスプロセスを呼び出し，サービスアダプタを介して各種サービス部品を実行します。

要求電文の受け取りは，MDB（Message-Driven Bean）を使用します。

Message Queue受付からは，応答電文を返しません。

＜この項の構成＞: (1)　WebSphere MQの概要; (2)　Message Queue受付の送信オプション; (3)　Message Queue受付とMQリソースアダプタとの関係; (4)　Message Queue受付とキューとの関係; (5)　Message Queue受付とビジネスプロセスとの関係; (6)　Message Queue受付の構成例; (7)　Message Queue受付使用時のトランザクション; (8)　Message Queue受付使用時のメッセージの二重配信防止; (9)　メッセージのロールバック回数の設定; (10)　同時実行数の設定

(1)　WebSphere MQの概要

Message Queue受付では，JMSプロバイダとしてWebSphere MQ（IBM社製）を利用します。WebSphere MQは，異機種システムのプログラム間でデータ通信をするためのメッセージキューイング型の非同期通信基盤です。

Message Queue受付は，WebSphere MQのバージョン7.5に対応しています。

WebSphere MQの構成を次に示します。

図2-83　WebSphere MQの構成

[図データ]

（凡例）: キューマネージャ：キューやリスナーをまとめる管理プログラム; キュー：JMSオブジェクトをまとめるキューオブジェクト; リスナー：キューマネージャがメッセージを受信または送信するためのリスナー

注意: WebSphere MQのキューマネージャは，初期状態ではチャネル認証によるサーバへのアクセスができません。そのため，チャネル認証を使用しないように設定を変更するか，デフォルトで設定されているチャネル認証ルールを変更する必要があります。WebSphere MQの設定方法については，IBM社のマニュアルを参照してください。

(2)　Message Queue受付の送信オプション

メッセージを送信する場合，送信オプション（JMSヘッダおよびプロパティ）を指定できます。Message Queue受付の送信オプションの詳細を次に示します。

(a)　JMSヘッダの詳細

送信オプション（JMSヘッダ）の設定値は，すべてString型に変換され，ヘッダ電文の中に設定されます。このとき，値がnull，または空の場合は，空タグになります。

JMSヘッダの詳細を次に示します。

表2-20　JMSヘッダの詳細

ヘッダ名	設定内容	設定タイミング	クライアントでの設定可否
JMSDestination	メッセージが登録されるキュー名	QueueSession.createSender(Queue queue)メソッド発行時に設定されます。	×
JMSDeliveryMode	メッセージの永続性を示す値	メッセージ送信時に設定されます。	×
JMSMessageID	プロバイダによって送信される各メッセージを一意に識別するメッセージ識別子	メッセージ送信時に設定されます。	×
JMSTimestamp	メッセージの送信時刻を表す値（単位：ミリ秒）	メッセージ送信時に設定されます。	×
JMSExpiration	メッセージの有効期間となる時刻を表す値（単位：ミリ秒）	メッセージ送信時に設定されます。	×
JMSRedelivered	メッセージが再配送中であるかどうかを示す値	アプリケーションに配送済みのメッセージがリカバリされたなどで再度配送する必要があるときに設定されます。	×
JMSPriority	メッセージのプライオリティ	QueueSender.setPriority()メソッド，またはQueueSender.send()メソッドで指定できます。	○
JMSReplyTo	応答先のあて先	Message.setJMSReplyTo()メソッド発行時に設定されます。	○
JMSCorrelationID	あるメッセージをほかのメッセージと関連づけるための相関識別子	Message.setJMSCorrelationID()メソッド発行時に設定されます。	○
JMSType	メッセージが送信されるときに，アプリケーションによって提供されるメッセージタイプ	Message.setJMSType()メソッド発行時に設定されます。	○

（凡例）: ○：指定できます。; ×：指定できません。

(b)　プロパティの詳細

メッセージのプロパティは，JMSプロバイダによって設定されるプロパティと，クライアントでユーザが設定できるプロパティで構成されます。

●JMSプロバイダによって設定されるプロパティ

JMSプロバイダによって設定されるプロパティには，JMS標準プロパティとWebSphere MQで設定されるプロパティがあります。どちらのプロパティも設定されている項目については，すべてヘッダ電文に設定されます。

JMS標準プロパティ
JMS標準のプロパティは，「JMSX」が項目名のプレフィックスに付いているプロパティです。
JMS標準プロパティの一覧を次の表に示します。

表2-21　JMS標準プロパティの一覧

項目名	説明
JMSXUserID	メッセージの送信者のユーザID
JMSXAppID	メッセージの送信アプリケーションのID
JMSXDeliveryCount	メッセージの再受信回数
JMSXGroupID	メッセージが属するグループのID
JMSXGroupSeq	グループ内でのメッセージ順序番号
JMSXProducerTXID	トランザクション識別子
JMSXConsumerTXID	トランザクション識別子
JMSXRcvTimestamp	メッセージ受信時間
JMSXState	プロバイダ内部で使用する項目

WebSphere MQで設定されるプロパティ
WebSphere MQで設定されるプロパティは，プロバイダ用プロパティの中に含まれます。プロバイダ用プロパティには，「JMS_」が項目名のプレフィックスに付いています。その中で，「JMS_IBM_」が項目名のプレフィックスに付いているものがWebSphere MQのプロパティです。

●ユーザが設定するプロパティ

ユーザが任意に設定できるプロパティは，「set<型名>Property(String name,<型名> value)」メソッドを使用して設定します。

プロパティに設定された値はすべてString型に変換し，ヘッダ電文の中に設定されます。

プロパティに設定できるデータ型の一覧を次の表に示します。

表2-22　プロパティに設定できるデータ型の一覧

データ型	設定するメソッド
Boolean	setBooleanProperty(String name, boolean value)
Byte^※1	setByteProperty(String name, byte value)
Short	setShortProperty(String name, short value)
Integer	setIntProperty(String name, int value)
Long	setLongProperty(String name, long value)
Float	setFloatProperty(String name, float value)
Double	setDoubleProperty(String name, double value)
String	setStringProperty(String name, String value)
Object^※2	setObjectProperty(String name, Object value)

注※1: Byte型の値を設定すると，Integer型の数値に変換されたものを文字列としてヘッダ電文に設定します。設定される数値の範囲は-127～127です。

注※2: データ型にObjectを設定すると，すべてのデータ型（Boolean，Byte，Short，Integer，Long，Float，DoubleおよびString）が使用できます。

(3)　Message Queue受付とMQリソースアダプタとの関係

MQリソースアダプタは，JMSプロバイダ（IBM WebSphere MQシステム）からのメッセージをMessage Queue受付に渡すためのリソースアダプタです。

MQリソースアダプタとMessage Queue受付の接続関係は，1つのリソースアダプタに対して複数の受付を関連づけることができますが，1つの受付に対して複数のリソースアダプタを関連づけることができません。

MQリソースアダプタとMessage Queue受付の関連づけは，Message Queue受付定義ファイルで指定します。指定した内容は，Message Queue受付を起動したときに有効になります。このとき，Message Queue受付と関連づけをするMQリソースアダプタを事前に起動しておく必要があります。関連づけをするMQリソースアダプタが起動されていないと，Message Queue受付は起動できないため，Message Queue受付定義ファイルの設定内容も有効になりません。

Message Queue受付とMQリソースアダプタの接続関係を次に示します。

(a)　構築できる接続関係（MQリソースアダプタの場合）

構築できる接続関係は次のどちらかです。

リソースアダプタと受付が1：1の接続関係の場合
リソースアダプタと受付が1：nの接続関係の場合

例を次に示します。

（例1）リソースアダプタと受付が1：1の接続関係の場合

[図データ]

説明

1つのMQリソースアダプタに関連づいているMessage Queue受付は1つ
1つのMessage Queue受付に関連づいているMQリソースアダプタは1つ

（例2）リソースアダプタと受付が1：nの接続関係の場合

[図データ]

説明

1つのMQリソースアダプタに関連づいているMessage Queue受付は複数
1つのMessage Queue受付に関連づいているMQリソースアダプタは1つ

(b)　構築できない接続関係（MQリソースアダプタの場合）

1つの受付に対して複数のリソースアダプタを指定できないため，リソースアダプタと受付の接続関係がn：1の構成は構築できません。

例を次に示します。

（例）

[図データ]

説明

1つのMQリソースアダプタに関連づいているMessage Queue受付は１つ
1つのMessage Queue受付に関連づいているMQリソースアダプタは複数

(4)　Message Queue受付とキューとの関係

キューは，JMSオブジェクトをまとめるキューオブジェクトで，キューマネージャによって管理されます。

キューとMessage Queue受付の接続関係は，1つのキューに対して複数の受付を関連づけることができますが，1つの受付に対して複数のキューを関連づけることができません。

Message Queue受付とキューの接続関係を次に示します。

(a)　構築できる接続関係（キューの場合）

構築できる接続関係は次のどちらかです。

キューと受付の接続関係が1：1の場合
キューと受付の接続関係が1：nの場合

例を次に示します。

（例1）キューと受付の接続関係が1：1の場合

[図データ]

説明

1つのキューマネージャの中に存在するキューは1つ
1つのキューに対して関連づけられたMessage Queue受付は1つ

（例2）キューと受付の接続関係が1：nの場合

[図データ]

説明

1つのキューマネージャの中に存在するキューは1つ
1つのキューに対して関連づけられたMessage Queue受付は2つ

(b)　構築できない接続関係（キューの場合）

1つの受付に対して複数のキューを指定できないため，キューと受付の接続関係がn：1の構成は構築できません。

（例1）キューマネージャが1つの場合

[図データ]

説明

1つのキューマネージャの中に存在するキューは2つ
キュー1およびキュー2に対して関連づけられたMessage Queue受付は1つ

（例2）キューマネージャが複数の場合

[図データ]

説明

2つのキューマネージャが存在
それぞれのキューマネージャの中に存在するキューは1つずつ
キュー1およびキュー2に対して関連づけられたMessage Queue受付は1つ

(5)　Message Queue受付とビジネスプロセスとの関係

ビジネスプロセスを作成するときは，受付アクティビティの通信モデルをMessage Queue受付の通信モデルと同一にする必要があります。

ビジネスプロセスの永続化については，永続化でも非永続化でも設定できます。

ただし，非永続化を設定すると，障害発生時にメッセージの二重配信が発生するおそれがあるので注意が必要です。

ビジネスプロセスとMessage Queue受付の接続関係は，1つのビジネスプロセスに対して複数の受付を関連づけることができますが，1つの受付に対して複数のビジネスプロセスを関連づけることができません。

Message Queue受付とビジネスプロセスの接続関係を次に示します。

(a)　構築できる接続関係（ビジネスプロセスの場合）

構築できる接続関係は次のどちらかです。

ビジネスプロセスと受付の接続関係が1：1の場合
ビジネスプロセスと受付の接続関係が1：nの場合

例を次に示します。

（例1）ビジネスプロセスと受付の接続関係が1：1の場合

[図データ]

説明

1つのMessage Queue受付に関連づけるビジネスプロセスは1つ
1つのビジネスプロセスに関連づけるMessage Queue受付は1つ

（例2）ビジネスプロセスと受付の接続関係が1：nの場合

[図データ]

説明

1つのMessage Queue受付に関連づけるビジネスプロセスは1つ
1つのビジネスプロセスに関連づけるMessage Queue受付は複数

(b)　構築できない接続関係（ビジネスプロセスの場合）

1つの受付に対して複数のビジネスプロセスを定義できないため，ビジネスプロセスと受付の接続関係がn：1の構成は構築できません。

例を次に示します。

（例）

[図データ]

説明

1つのMessage Queue受付に関連づけるビジネスプロセスは複数
1つのビジネスプロセスに関連づけるMessage Queue受付は1つ

(6)　Message Queue受付の構成例

Message Queue受付では，使用する通信モデルに応じてさまざまなシステム構成を実現できます。

ここでは，次の場合の構成例を次に示します。

Message Queue受付を非同期の通信モデルで使用する場合
Message Queue受付を同期の通信モデルで使用する場合

(a)　Message Queue受付を非同期の通信モデルで使用する場合

前提条件

Message Queue受付を定義したビジネスプロセスを作成します。
Message Queue受付の通信モデルを「非同期」で定義します。

構成例: Message Queue受付とビジネスプロセスの構成の例を次の図に示します。

説明

MQクライアントのプログラムから，WebSphere MQサーバのキューにメッセージを登録します。
WebSphere MQサーバからMessage Queue受付（HCSCサーバ）に対し，メッセージが送信されます。
Message Queue受付は，ビジネスプロセスを呼び出します。
すべてのアクティビティの処理が終了したあと，Message Queue受付も処理を終了します。
WebSphere MQサーバがトランザクションをコミットし，キューからメッセージを削除します。

参考: この構成例の場合，リクエスト処理が完了するまで，メッセージが保持されます。このため，ビジネスプロセスが処理している間は，キューからメッセージは削除されません。ただし，二重配信防止の処理が実行された場合，またはロールバック制限でメッセージが移動した場合は，キューからメッセージが削除されます。メッセージの二重配信防止については，「(8) Message Queue受付使用時のメッセージの二重配信防止」を参照してください。

(b)　Message Queue受付を同期の通信モデルで使用する場合

前提条件

Message Queue受付を定義したビジネスプロセスを作成します。
Message Queue受付の通信モデルを「同期」で定義します。

構成例: Message Queue受付とビジネスプロセスの構成の例を次の図に示します。

説明

MQクライアントのプログラムから，WebSphere MQサーバのキューにメッセージを登録します。
WebSphere MQサーバからMessage Queue受付（HCSCサーバ）に対し，メッセージが送信されます。
Message Queue受付は，ビジネスプロセスを呼び出します。
応答アクティビティの処理が終了したあと，応答アクティビティのあとの実行に必要な情報をReliable Messagingまたは非同期EJBへ格納し，Message Queue受付も処理を終了します。
WebSphere MQサーバがトランザクションをコミットし，キューからメッセージを削除します。
Reliable Messagingまたは非同期EJBに格納した情報に従って，応答アクティビティのあとに設定されたアクティビティが実行されます。

参考: この構成例の場合，ビジネスプロセスの処理が終了する前に，キューからメッセージを削除できます。ただし，応答アクティビティのあとのビジネスプロセスの処理で例外が発生した場合に，キューからメッセージが削除されているので，リクエストを再送信する必要があります。

(7)　Message Queue受付使用時のトランザクション

Message Queue受付では，例外発生時はキューをロールバックするため，WebSphere MQのキューマネージャと同一のトランザクションを使用する必要があります。そのため，Message Queue受付のトランザクションはコンテナ管理のトランザクションを使用します。それによって，トランザクションのコミットはWebSphere MQのキューがコミットされるタイミングと同時となります。

Message Queue受付を使用した場合のトランザクションの範囲を次の図に示します。

図2-84　Message Queue受付を使用した場合のトランザクションの範囲

[図データ]

Message Queue受付は，WebSphere MQのキューマネージャと同一のトランザクションを使用して処理しますが，ビジネスプロセスは，WebSphere MQのキューマネージャとは異なるトランザクションで処理します。そのため，Message Queue受付で処理が異常終了し，ロールバックを実行するためにメッセージがキューの先頭に戻った場合でも，ビジネスプロセスのトランザクションが正常終了していることがあります。このような状態のときにロールバックによって再びメッセージが送信されると，一度処理を実行したビジネスプロセスで再び同じ処理が実行されてしまうことになります。このような処理を防ぐには，メッセージの二重配信防止の処理をしてください。メッセージの二重配信防止については，「(8) Message Queue受付使用時のメッセージの二重配信防止」を参照してください。

(8)　Message Queue受付使用時のメッセージの二重配信防止

リクエスト処理が異常終了した場合，ロールバックを実行するためにメッセージはキューの先頭に戻り，再びメッセージが送信されることで，一度処理を実行したビジネスプロセスが再び処理されてしまうことがあります。

Message Queue受付では，メッセージの二重配信防止の設定をすることで，リクエスト処理が異常終了した場合に，メッセージの再送信による実行済みビジネスプロセスの再実行を防止します。

(a)　二重配信防止の前提条件

次に示す条件をすべて満たす場合に，二重配信防止のチェックをします。

データベースを使用している。
実行履歴が有効になっている（ビジネスプロセスのプロパティで，ステータスの永続化が「yes」になっている）。

(b)　二重配信防止使用時の注意点

二重配信防止を設定している場合の注意点を次に示します。

実行履歴の管理が必要なため，データベース容量の見積もりが必要です。
システム例外が発生したビジネスプロセスは，再実行する必要があります。

(c)　ビジネスプロセスで障害が発生したときの対策

ビジネスプロセスで発生する主な障害の例を挙げ，二重配信防止を設定している場合の動作および対処方法を説明します。

（例1）メッセージ関連づけ情報テーブルへ登録前に障害が発生した場合

この場合の実行履歴の表示，リクエストメッセージの状態および対処方法を次に示します。

実行履歴の表示
未実行
リクエストメッセージの状態
ロールバックされ，再度リクエストメッセージが送信されます。
電文不正（nullなど）が原因だった場合は，指定したロールバックの実行回数分だけロールバックを続けます。
対処方法
ロールバックの制限回数を設定してください。
障害の発生するメッセージを除去してください。

（例2）ビジネスプロセスの処理実行中に障害が発生した場合

この場合の実行履歴の表示，リクエストメッセージの状態および対処方法を次に示します。

実行履歴の表示
実行中またはエラー
リクエストメッセージの状態
障害発生時にロールバックされ，2回目のリクエストメッセージ送信時に二重配信防止のチェックによって正常終了としてコミットされます。
対処方法
再実行コマンドまたは運用環境の画面を使用し，ビジネスプロセスを再実行してください。

（例3）ビジネスプロセスの処理終了後に障害が発生した場合

この場合の実行履歴の表示，リクエストメッセージの状態および対処方法を次に示します。

実行履歴の表示
正常終了
リクエストメッセージの状態
障害発生時にロールバックされ，2回目のリクエストメッセージ送信時に二重配信防止のチェックによって正常終了としてコミットされます。
対処方法
必要ありません。

（例4）ビジネスプロセスの応答アクティビティ処理終了後に障害が発生した場合

この場合の実行履歴の表示，リクエストメッセージの状態および対処方法を次に示します。

実行履歴の表示
実行中
リクエストメッセージの状態
応答アクティビティの処理終了後に，キューはコミットされるため，リクエストメッセージが送信されることはありません。
対処方法
再実行コマンドまたは運用環境の画面を使用し，応答アクティビティのあとのアクティビティを再実行してください。

(9)　メッセージのロールバック回数の設定

Message Queue受付では，リクエスト処理時に障害が発生した場合，必ずロールバックします。これは，キューマネージャのデッドレターキューまたはキューのバックアウトリキューに指定されたキューへメッセージを移動させることで，無限ループを防ぐためです。

ロールバック回数は，WebSphere MQのキューマネージャおよびキューで設定します。

なお，設定方法については，WebSphere MQのマニュアルを参照してください。

●キューマネージャで設定する項目

キューマネージャで設定するロールバック関連の設定項目を次に示します。

表2-23　キューマネージャで設定するロールバック関連の設定項目

設定項目	設定内容	設定可能な値	デフォルト値
DEADQ	デッドレターキュー名	キュー名	SYSTEM.DEAD.LETTER.QUEUE

●キューで設定する項目

キューで設定するロールバック関連の設定項目を次に示します。

表2-24　キューで設定するロールバック関連の設定項目

設定項目	設定内容	設定可能な値	デフォルト値
BOTHRESH	バックアウトの閾値	0～999999999	0
BOQNAME	バックアウトリキュー名	キュー名	なし

注意: クライアントで設定するQueueSender#sendパラメタに値（メッセージを保持する時間）が指定されている場合は，注意が必要です。メッセージをデッドレターキューに移動しても，QueueSender#sendパラメタに指定されている時間を過ぎるとメッセージは削除されます。