7章メッセージ - public.dhe.ibm.compublic.dhe.ibm.com/software/dw/jp/websphere/wmq/mq_intro/7.pdf-3-ⅳ.Expiryフィールドこのメッセージの有効期限(賞味期限)を指定します。設定された有効期限の

- 1 -

7章メッセージ

この章では、WebSphere MQでデータを処理や転送する際の単位となる「メッセージ」について、もう

少し詳しくお話しします。ただ、単に「WebSphere MQが扱うメッセージ」と言っても、実際には

●アプリケーションから見た「メッセージ」. つまり、アプリケーションからキューへ書き込む時

の、又はキューから読み込む時の、単位としてのメッセージ

●キュー・マネージャー間で転送する時の、単位としてのメッセージ

とが異なることもありますので、ご注意下さい。

7-1. メッセージとは

メッセージとは、WebSphere MQで各種データを取り扱う際の「単位」のことです。ただし上述の

ように、アプリケーションが処理する場合のメッセージと、キュー・マネージャーが処理するとき

のメッセージとで、そのサイズなどが異なることもあります。

取り扱うことが出来るデータとしては、

●テキスト・データ

●バイナリー・データ

●上記二つの混合

があります。これらは、ユーザー・アプリケーションが作成する場合もありますし、キュー・

マネージャーが生成することもあります。いずれにしても、メッセージは、それを処理するプロ

セスにとって意味を持つバイト列又は情報を含んだものと言えます。つまり、メッセージとその

中に含まれるデータの処理は、それを利用する各アプリケーションの責任となります。

以前のバージョンでは1メッセージの最大長は4MBまででしたが、V5.1以降(一部のプラット

フォームでは、V5.3以降)は、100MBまでのメッセージを処理できます。(だからと言って、本当に

100MBのメッセージをやり取りしているような事例はありませんが.....)

この章では、メッセージとそれに含まれるユーザー・データを区別してお話ししますので、

混乱しないよう、注意して下さい。

Copyright IBM Japan, Ltd

- 2 -

7-2. メッセージの構造

第2章でお話ししたように、メッセージの構造は

(1) そのメッセージの各種属性や、宛先情報を含んだヘッダ部分

(2) ユーザー・データ

から構成されます。

(1) ヘッダ部分

この部分は、通常MQMDと呼ばれる構造体で表されるもので、各種情報を含んでいます。

- メッセージを識別するための情報

- メッセージの宛先情報

- メッセージの属性

- そのメッセージを処理するアプリケーションための各種情報フィールド

実際のMQMDの構造は、次ページのような定義になっています (cmqc.hより)。主なものに

ついて、概要をお話しします。

ⅰ. Versionフィールド

この構造体のバージョンを表します。MQMD_VERSION_1とNQMD_VERSION_2という

値が定義されています。通常MQMD_VERSION_1を使いますが、V5.1以降で拡張

された機能を利用する場合には、MQMD_VERSION_2を使います。

ⅱ. Reportフィールド

このメッセージが宛先に届いた時に、送り元のキュー・マネージャーにそれを

通知するためのレポート・メッセージを返信させたいような場合に、送信側

アプリケーションで設定します。どのような事象に対してレポート・メッセージ

返信して欲しいか、またその際元のメッセージとどのように関連づけるかを、

MQRO_XXXXXXXXXXXXという値で指定します。

ⅲ. MsgTypeフィールド

このメッセージがどのようなタイプのメッセージなのか、を示すフィールド

です。例えば、このメッセージに対する何らかの処理を必要とする要求なのか、

又は応答なのか、などの値(MQMT_XXXXX)を設定します。メッセージを受け取った

アプリケーションは、このフィールドを元に適切な処理を行うことになります。

ヘッダユーザー・データ

[WebSphere MQのメッセージ] = [ヘッダ] + [ユーザー・データ]


- 3 -

ⅳ. Expiryフィールド

このメッセージの有効期限(賞味期限)を指定します。設定された有効期限の

カウント・ダウンは、このメッセージがキューに書き込まれた時点から、開始

されます。もし指定された時間を経過しても何の処理も行われなかった場合、

超過後そのメッセージが滞留しているキューに対するMQGETが発行された時点で

キューから削除されます。(V5.3ではキューに滞留している有効期限を超過した

メッセージは、自動的に削除されるわけではありません. V6以降では、自動的に

削除が行われます)

ⅴ. CodedCharSetIdフィールド

ユーザー・データが記述されているCCSIDを示しています。受信側でコード変換を

行う場合には、ここで指定された値から、アプリケーションがMQGETのオプション

で指定した値へと変換されます。

ⅵ. Formatフィールド

このメッセージに含まれる、ユーザー・データのタイプを表すフィールドです。

例えば、全て文字型のユーザー・データの場合であればMQFMT_STRINGという値を

バイナリーであればMQFMT_NONEを指定します。(このフィールドの値が上記の

MQFMT_STRINGの場合、キュー・マネージャーによるコード変換が可能です)

ⅶ. Priorityフィールド

このメッセージの優先度(1から9までで、9が最も優先度が高い)を指定します。

キューにメッセージが書き込まれる際、このフィールドの値とキューのDEFPSIST

属性の値と異なった場合には、こちらのフィールドの値が使われます。


- 4 -


ⅷ. Persistenceフィールド

このメッセージがパーシステント・メッセージなのか、それともノン・パーシ

ステント・メッセージなのかを表すフィールドです。前述のPriorityフィールド

と同様に、キューのDEFPSIST属性と異なった場合には、このフィールドの値が

使われます。

ⅸ. MsgIdフィールドとCorrelIdフィールド

このメッセージを特定するために使われるフィールドです。キューの中に

複数のメッセージが存在するときに、アプリケーションからこれらのフィールド

を使って、特定のメッセージを読み込む事ができます。送信側アプリケーション

が、メッセージをキューに書き込む際に特定の値を設定することができます。

またキュー・マネージャーに自動的に設定させることも可能です。

ⅹ. ReplyToQフィールドとReplyToQMgrフィールド

このメッセージに対する何らかの処理を行った結果やレポート等のメッセージを

返送する宛先となるキューとそれを管理するキュー・マネージャーを指定する

フィールドです。例えば上記のMsgIdフィールドやCorrelIdフィールドと組み合わ

せて、以下のような使い方をすることがあります。

サンプル・プログラムのamqsbcg(Windowsでは、amqsbcg.exe)を使うと、キューの中に

存在する全てのメッセージを、そのヘッダ部分も含めて表示させることが出来ます。

(次ページ参照)

- 5 -

このように、サンプル・プログラム amqsbcgはヘッダ部分の情報と共に、データの16進

コードも表示してくれますので、覚えておくと便利なプログラムです。(表示させている

だけなので、メッセージはキューに残っています)

(2) データ部分

データ部分は、アプリケーションが生成したユーザー・データを格納している部分で、

一番重要な部分になります。この中には、テキスト・データやバイナリー・データ、及び

それらが混合したものなど、いずれかのフォーマットで記述されたアプリケーション・

データが納められている事になります。

キュー・マネージャーに対するコマンドを含んだPCFと呼ばれる特殊なデータを除き、

この部分に納められているデータは、アプリケーションがその作成や処理といった作業を

行うことになります。


- 6 -


キュー・マネージャーによるデータ変換機能と関係するため、データがどのような

フォーマットで作成されているかを、前述のMQMD.Formatフィールドに指定する必要が

あります。よく使われるのが、以下の2つです。

● MQFMT_STRING

データ部分に含まれるアプリケーション・データが、全てテキスト、つまり文字

型であることを表しています。この場合、キュー・マネージャーによるコード

変換が可能になります (実際に変換させるかどうかは、別として....)。

● MQFMT_NONE

データ部分に含まれるアプリケーション・データが、バイナリー・データの

ような一般的なフォーマットであり、キュー・マネージャーによるコード変換の

対象外であることを表しています。例えば、イメージ・データのようなデータを

メッセージとして処理する場合に、使われます。

なお、データが全てテキスト・データであって、かつMQMD.FormatにMQFMT_STRINGを

指定したからといって、キュー・マネージャーによるコード変換が必ず成功するとは

限りません。例えば、

●シングル・バイト文字列とダブル・バイト文字列の混成から成るEBCDICのデータを

扱う際に、シングル・バイト文字列とダブル・バイト文字列との境界を示すSO/

SIが1メッセージ中に揃っていなかった場合 (どこまでが、ダブル・バイト文字な

の ?)

●ダブル・バイト文字列からなるデータを、CCSID 819などのシングル・バイト文字

列に変換しようとした場合 (そりゃ、当然 !)

には、コード変換ができません。

キュー・マネージャーによるコード変換が出来ない例

バイナリー・データとテキスト・データが混在しているようなデータのように、アプ

- 7 -


リケーション独自のフォーマットのデータを扱う場合には、

ⅰ. キュー・マネージャーによるコード変換を行わず、アプリケーションでその

処理を行う.

ⅱ. その独自フォーマット用の変換ロジックを実装したモジュール(ユーザーEXITと

呼ばれます)を組み込み、コード変換の際そのモジュールにデータを渡してコード

変換を行う.

のどちらかの方法を使う必要があります。(ⅱのユーザーEXITを使う方法については、マ

ニュアル「WebSphere MQ アプリケーション・プログラミング・リファレンス」の「付録

F. データ変換」を参照して下さい)

7-3. メッセージの種類と性質

(1) メッセージの種類

先にメッセージには、パーシスタント・メッセージとノン・パーシスタント・メッセージが

あるということをお話ししました。

ここでは、アプリケーションから見たとき、メッセージにはどのような種類があるか、を

お話しします。

7-2 (1)でお話ししたヘッダ部分に、MsgTypeフィールドがあります。ここで使用可能な値、

つまりWebSphere MQのcmqc.hで定義されている値には、以下のものがあり、メッセージ作成

時に指定します。

通常アプリケーションで使われるのは、以下のタイプになります。

ⅰ. MQMT_REQUEST

受信側アプリケーションに対して何らかの処理を要求するためのメッセージで、

通常このメッセージの処理に関する応答を必要とする場合に使用します。そのため、

MQMD.ReplyToQMフィールドやMQMD.ReplyToQフィールド、MQMD.MsgIdフィールドを

- 8 -


一緒に使うことがあります。

ⅱ. MQMT_REPLY

上記のMQMT_REQUESTのようなメッセージに対する何らかの処理結果に関する情報を

含んだ、応答メッセージである事を示す場合に使用します。このような場合、どの

要求メッセージに対する応答なのかという関連性を示すため、MQMD.MsgIdフィールド

やMQMD.CorrelIdフィールドを利用します。(例えば、前述のように要求メッセージの

MQMD.MsgIdフィールドを、応答メッセージのMQMD.CorrelIdフィールドにコピーする

といった方法で、どの要求メッセージに対する応答メッセージなのかという関連性を

表すことがあります)

ⅲ. MQMT_DATAGRAM

一方通行のデータで特に応答などの処理を要求しないメッセージや、一般的な

データを含んだメッセージであることを意味します。

ⅳ. MQMT_REPORT

メッセージの処理中に発生した例外情報など、何らかの事象を相手側に通知する

ための情報を含んでいることを意味します。

これらメッセージ・タイプは、キュー・マネージャーにとってはそれほど重要な意味を

持ちません。実際キュー・マネージャーはこのMDMD.MsgTypeフィールドからタイプを確認して、

何らかの処理を行うようなことはありません。このフィールドの値によってメッセージが

どのように処理されるかは、メッセージを作成したアプリケーションと読み込んだアプリ

ケーションとの間での取り決めになります。もしMQMD.MsgTypeフィールドの値を使う場合には

メッセージを読み込んだアプリケーションが指定されたタイプを元に、適切な処理を行って

下さい。

ちなみに全ての種類のメッセージに、パーシスタント又はノン・パーシスタントの指定が

可能です (つまり、MQMD.Persistenceフィールドの設定が有効です)

(2) メッセージの性質

「1-4. WebSphere MQの機能概説」でお話ししたように、WebSphere MQが扱うメッセージは

パーシスタント(持続属性)とノン・パーシスタント(非持続属性)という性質を持っています。

アプリケーションがメッセージをキューに書き込むと、内部的には

●パーシスタント・メッセージの場合、初めにログに書き込みを行い、次に物理的な

キュー・ファイル(UNIXでは/var/mqm/qmgrs/xxxxxx/queues/下のファイル. Windowsで

は[WebSphere MQ導入先ディレクトリー]\qmgrs\xxxxxx\queues\下のファイル)へ書き

込まれる.

●ノン・パーシスタント・メッセージの場合、物理メモリー上のバッファーに書き込ま

るが、もしこのバッファーの容量を超えた場合には、物理的なキュー・ファイルへ

書き込みが行われる.

という処理が行われます (次ページの図を参照)。

- 9 -


このためシステムのリブートなどが発生しても、ログ・ファイルが正常であればパーシス

タント・メッセージは、キュー・マネージャーの再始動後キューに復元されます。例えば、

HA構成を組んだ時に、共有ディスク上にログ・ファイルとキュー・ファイルを配置すると

takeoverでシステムが切り替わっても、キュー・マネージャーの再始動後処理中のパーシ

スタント・メッセージはキューに復元されるので、処理を継続できます。

(HA構成のシステム上でWebSphere MQを構成するような場合には、幾つかの資料がWEBに公開

されていますので、そちらを必ず参照して下さい)

- 10 -


あるメッセージが、パーシスタントなのか、それともノン・パーシスタントなのかは、

●MQMD.Persistenceフィールドの設定

●メッセージの書き込み先となるキューのDEFPSIST属性

によります。簡単にまとめると、以下の表のようになります。

この表にあるように、もしMQMD.Persistenceフィールドの設定とDEFPSIST属性が異なる場合

は、MQMD.Persistenceフィールドの設定が優先されます。そのため、必要に応じ

MQMD.Persistenceフィールドの値を変えることで、各メッセージ毎にパーシスタント/ノン・

パーシスタントを切り替えることが出来ます。

実は、ノン・パーシスタント・メッセージも、WebSphere MQ V5.3の6番目の修正パッケージ

(CSDとか、FixPackと呼ばれています)を適用すると追加されるキューのNPMCLASS属性により、

パーシスタント・メッセージのように扱うことが出来るようになりました。

このNPMCLASS属性を

●HIGHに設定すると、キュー・マネージャーが正常終了した場合、キューに格納されて

いるパーシスタント・メッセージはキュー・マネージャー再起動時にキューへ復元され

る.

●NORMALに設定すると、ノン・パーシスタント・メッセージは従来と同様にキュー・

マネージャーの終了時にキューから削除される.

ようになりました。このNPMCLASS属性による機能拡張は、あくまでも、「キュー・マネージャー

が正常終了した場合」に、ノン・パーシスタント・メッセージでもキューに復元するという

ものですので、重要なデータを取り扱う場合にはこれまでと同様にパーシスタント・メッセー

ジを使うようにして下さい。

7-4. 同期点処理

(1) WebSphere MQでの同期点処理

WebSphere MQで「同期点処理」とは、

① キューに対するメッセージの読み取り/書き込み処理

② 上記の①に加え、DBなど外部の資源との連携処理

(例:キューからメッセージを読み取り、その中に含まれるデータをDBへinsert処理を

行い、COMMIT又はROLLBACKするなど)

がその範囲となります。ただし、②に関してはいろいろなケースが考えられますので、ここ

- 11 -


では概略をお話しするだけにして、①のケースに関してお話しします。

(2) メッセージ書き込み及び読み込み処理における同期点処理

例えば、WebSphere MQを使って、ファイル転送を行うケースを考えてみましょう。

送信側では、アプリケーションが準備したバッファー単位でファイルを読み込み、

メッセージを作成し、キューへ書き込む、という処理が通常行われます。このプロセスでは、

●全てのメッセージがキューに書き込まれたら、それらの転送を開始する.

●たとえ一つのメッセージでも書き込みに失敗した場合、ファイル転送はキャンセルし、

キューに貯まっているメッセージは破棄する.

という処理が一般に行われます (途中経過を記録しておく等の工夫をすれば、別ですが)。

また受信側では、まずファイルをオープンし、キューから読み込んだメッセージからデータ

を取り出して、ファイルへ追加書き込みを繰り返し、全てのデータの書き込みが成功したら

ファイルをクローズする、という処理が行われます。そのため

●全てのデータの書き込みが成功し、かつファイルのクローズが正常に終了したら、処理

が成功したことになるので、キューからメッセージを削除する.

●一つでもデータの書き込みが失敗した場合や、ファイルのクローズが失敗した場合には

それまでの処理をキャンセルし、再度初めからやり直す.

という処理が、やはり一般的です。(やはり途中経過を記録するなどの方法を取れば、別です)

データベースへデータをinsertやupdateといった処理を行った後、それらの処理を確定させ

るために同期点処理(COMMIT又はROLLBACK)を行うのと同様に、WebSphere MQでもキューへの

メッセージ処理を、COMMIT又はROLLBACKすることができます。

メッセージを同期点処理の対象としたい場合、キューへの書き込み時又は読み込み時に、

同期点処理フラグをパラメータとして指定し、それぞれのAPIを呼び出します。その後作業

単位をクローズするために、同期点処理(つまり、COMMIT又はROLLBACK)を行うことになります。

メッセージの書き込みの場合、作業単位が確定(COMMIT)するまで、同期点処理の対象と

なっているメッセージは、他のアプリケーションからは読み取ることはできませんし、

ネットワーク上を転送されることもありません (但し、キューのCURDEPTH属性にはカウント

されます)。作業単位が確定すると、他のアプリーションが読み取ることが可能になります。

またROLLBACKされた場合には、その作業単位内で同期点処理対象として書き込まれたメッ

セージは、キューから削除されます。

一方メッセージの読み込みの場合、作業単位が確定するまで、同期点処理対象のメッセージ

はキューに残っていますが、他のアプリケーションからはアクセスできない状態になってい

ます。作業単位が確定すると、読み取り処理が正常に行われたことになりますので、キュー

からメッセージは「消去」されます。

- 12 -


ROLLBACKされた場合には、その作業単位内で同期点処理対象として読み取られたメッセージ

全てが、キューに復元されます。

(上)メッセージ書き込み時における同期点処理.(下)メッセージ読み込み時における同期点処理

- 13 -


(3) 外部資源との連携処理

(1)と同じく

●キューからメッセージを読み取り、その中に含まれるデータをDBへinsert処理

という処理を考えてみましょう。この場合、アプリケーションは

ⅰ. キューから、必要なメッセージを読み込み

ⅱ. メッセージに含まれるデータを採りだし

ⅲ. DBへInsert処理

を繰り返し、最終的にCOMMITすることになります (もし何らかのエラーが生じた際は、当然

ROLLBACK)。つまり、キューからのメッセージ読み込み処理とDBへのinsert処理は、裏表一体の

関係にあって、これらの同期点処理の成功/失敗は必ず一致する必要があり、通常はXA

2フェーズ・コミットが行われます。

このような連携処理形態では、全体の同期点処理を管理するトランザクション・マネー

ジャー(例えば、CICSやENCINA)と、DBやキューなど個々の資源を管理するリソース・

マネージャーの二つの役割が存在します。

DBとの連携の場合であれば、WebSphere MQ(キュー・マネージャー)自身がコーディネーター

として機能することが出来ます。またCICSなどのコーディネーターと、その配下のリソース

管理者として連携処理することも可能です。

- 14 -


連携可能なトランザクション・モニターやデータベース、それらのバージョンなどは、

以下のURLから検索できますので、ご参照下さい。

http://www-306.ibm.com/software/integration/websphere/mqplatforms/supported.html

(4) 考慮事項

WebSphere MQで同期点処理を使用する場合には、

ⅰ. あまりにも多数のメッセージを同一作業単位内で処理した場合に、メッセージの読み

書きのパフォーマンスが悪くなることがあります。また作業単位中に何らかの問題が

発生しBACKOUTしなければいけない場合、そのための時間がかかることになります。

ⅱ. 特にパーシステント・メッセージを同期点処理するような場合、ログ容量が不足する

ことがあります。予め十分なログ容量(ファイル数と、その大きさ)を準備しておく

ようにして下さい。

ⅲ. 作業単位中に、未確定メッセージ数ががキュー・マネージャーのMAXUMSGS属性で

指定されている値を超えると、ROLLBACKされます。予め、MAXUMSGS属性の値を調整

おく事をお勧めします。

ⅳ. XA連携の場合、パフォーマンスが要求されるような場合には、むしろ外部トランザク

ション・モニターを使った方が、処理全体の効率的が上がります。(「餅は餅屋」!)

などの点を、十分に考慮して下さい。

- 15 -


7-5. 大きなメッセージの取り扱い

キュー・マネージャーやキュー、チャネルのMAXMSGL属性を変更することで、WebSphere MQ

V5.3では、1メッセージは最大100MBまで扱えます。しかし

●MAXMSGL属性の設定値を超えるようなメッセージを取り扱いたい

●100MBを超えるようなファイルの送受信を、WebSphere MQを使って行いたい

などの場合、WebSphere MQでは以下の3つの機能で対応できます。

(1) メッセージのグループ化

(2) メッセージの分割/結合

(3) 参照メッセージ

いずれも、メッセージの書き込み時又は読み込み時にあるオプションを指定するなど、プロ

グラミングに関する知識が必要になるので、ここではその概要についてだけお話しします。

(もしプログラミング・レベルの情報が必要な方は、マニュアルの「プログラミングの手引き」

又は「プログラミング・リファレンス」を参照して下さい)

(1)メッセージのグループ化

「メッセージのグループ化」は、物理的に独立した複数のメッセージを、論理的に

関連付けて、1つの意味を構成する「メッセージ・グループ」とする機能です。

例えば、互いにに依存関係と順序関係がある複数ファイルの転送を考えてみましょう。

それぞれ大きさが2MBのA,B,C,Dというファイルがあり、これらの送受信処理ではこの

順番を守る必要があるとします。つまり、4つのファイルで、合計8MBの送受信となりま

すが、単に転送処理するだけでなく、順番を守り確実に転送する必要があります。

それぞれを2MBちょっとのメッセージとしてキューに書き込みますが、4つファイル (4つ

のメッセージ) 1組で初めて意味を持つため、これらを1つの「グループ」として、ヘッダ

部分のあるフィールドに、共通の名前と、そのグループ内での順序番号(オフセット)を

設定します。

受信側では、読み込む際にこの"SAMPMSGGROUP"と順序番号を指定して、キューから

メッセージを読み込むようにします。その結果、4つのファイルが順番通り受信できるよう

になります。(実際のプログラミングでは、もうちょっと複雑になりますので、必要な方

は、マニュアルを参照して下さい)

データ内容大きさグループ名順序番号(オフセット)

ファイル A 2 MB SAMPMSGGROUP 0

ファイル B 2 MB SAMPMSGGROUP 1

ファイル C 2 MB SAMPMSGGROUP 2

ファイル D 2 MB SAMPMSGGROUP 3

- 16 -


(2)メッセージの分割/結合

(1)では、物理的に独立した複数のメッセージを「グループ化」することで、キューなど

のMAXMSGL属性設定値を超える大きさを持つ「論理的な」メッセージとして扱うことができ

ることを、簡単にお話ししました。

では、物理的に1つのメッセージ自体が、MAXMSGL属性の設定値を超えるようなケースを

考えてみましょう。

例えば、ftpでのファイル転送を思い出して下さい。getコマンドやputコマンドでファ

イルを転送すると、実際にはネットワーク上を「複数のパケット」に分割されて、転送が

行われます。受信側では、届いた「複数のパケット」から、元のファイルを再構築し、

ディスクなどに保管します。

WebSphere MQでの「メッセージの分割/結合」も、このftpの例と同様に、

●転送対象の「物理的に大きな」1メッセージを、MAXMSGL属性で設定された値以下の

「小さな」複数メッセージに分割して転送

●それら複数メッセージを結合して、元の1メッセージに再構築する

という機能です。

通常この機能を利用する場合、アプリケーションはメッセージをキューに書き込む際

「キュー・マネージャーが、適切な大きさにメッセージを分割しても構わない」事を示す

フラグをオプションとして指定します。すると、キュー・マネージャーはMAXMSGL属性の

設定値よりも小さい値で、渡されたメッセージを分割して、キューに格納します。

一方メッセージを読み込む側のアプリケーションは、「分割されて複数のメッセージを、

元の大きさのメッセージに復元して、読み込みたい」というフラグをオプションに指定し

て、メッセージの読み込みを実行します。

この機能を使うと、アプリケーションがメッセージのサイズをあまり気にせずに、送受

信することが出来ますが、その反面、実メモリー上にメッセージの大きさ分のバッファー

を準備する必要があるため、メモリー使用量が急激に増える可能性がありますので、注意

- 17 -


して下さい。

(3)参照メッセージ

この機能は、これまでお話ししてきた2つの機能と異なり、実際のデータの送受信に

キューを使わないという、ちょっと変わった方法になります。

この機能を利用する場合、まず「メッセージ EXIT」と呼ばれる一種のplug-inを作成し

送信側と受信側の両方に準備します。

次に送信側で、送りたいデータをファイルとして準備します。送信側アプリケーション

は、この保管場所(ディレクトリー)を特殊なメッセージ形式に「埋め込んで」、キューに

書き込みます。(送ろうとしているデータを、直接キューに書き込んでいる訳ではありま

せん)

この特殊なメッセージが送信される際、

ⅰ. 先に作成したメッセージEXITが転送対象となっているファイルの保管場所を読み

取る.

ⅱ. 保管場所からファイルを読み取り、WebSphere MQで扱うメッセージとして整形

する

という作業を行い、先の特殊なメッセージに引き続いて、転送します。

一方受信側では、最初に送られてくる特殊なメッセージをキューに書き込むと同時に、

以降のメッセージを、先に作成したメッセージ EXITで、適当なディレクトリー下に保管

します。キューに書き込まれた特殊なメッセージを読み込んだユーザー・アプリケー

ションは、データの保管場所をその中から入手して、実際のデータへアクセスすることに

なります。

このように実際のデータはキューを経由しないために100MBを超えるデータの処理が

可能になります。しかし、メッセージ EXITのロジックや作成が必要なこと、また先に

お話しした「メッセージのグループ化」や「メッセージの分割/結合」などの機能よりも

処理が複雑になりますので、もしお使いになる場合は、製品パッケージに含まれている

サンプル・コード(AMQSXRMA.CとAMQSQRMA.C)を参照して下さい。

Documents

7章メッセージ - public.dhe.ibm.compublic.dhe.ibm.com/software/dw/jp/websphere/wmq/mq_intro/7.pdf-3-ⅳ.Expiryフィールド このメッセージの有効期限(賞味期限)を指定します。設定された有効期限の

7章メッセージ - public.dhe.ibm.compublic.dhe.ibm.com/software/dw/jp/websphere/wmq/mq_intro/7.pdf-3-ⅳ.Expiryフィールドこのメッセージの有効期限(賞味期限)を指定します。設定された有効期限の