メッセージを格納するためのキューについて、以下の資源を設計します。
Destination
イベントチャネル
ユニット（保存先）
■Destinationの設計
Destinationは、キュー（イベントチャネル）にメッセージを送受信するための宛先を示す定義です。Interstage Application Serverでは、Destinationはイベントチャネルを指す論理名となります。
非同期アプリケーション連携実行基盤において、メッセージの宛先にはDestinationを用います。非同期アプリケーション連携実行基盤で利用するDestinationは、以下のように作成する必要があります。
Destinationは常にローカルに作成したものを利用
Destinationとイベントチャネルの関係が1対1
Destinationの定義としては、1つのイベントチャネルに対し、複数のDestinationを定義することが可能ですが、非同期アプリケーション連携実行基盤で利用するDestinationおよびイベントチャネルについては、1対1になるように定義してください。
注意
イベントチャネルとDestinationの関係において、「イベントチャネルとDestinationが1対1」とは、あるイベントチャネルを参照するすべてのアプリケーションサーバで、そのイベントチャネルに対して、同一の1つの名前だけでDestinationを作成することを指します。
1つの業務処理実行アプリケーションの受信キューとなるDestinationおよびイベントチャネルは1つ
1つのDestinationおよびイベントチャネルを受信キューとする業務処理実行アプリケーションの配備ファイルは1つ
業務処理実行アプリケーションの配備単位には2種類あります。これらとDestinationおよびイベントチャネルの関係は下図のようになります。
1つの業務処理実行アプリケーションを含む、ライブラリまたはJARファイル
複数の業務処理実行アプリケーションを含むEARファイル（Javaの場合）
アプリケーション連携フロー定義中に現れるすべてのDestinationの定義
アプリケーション連携フロー定義中に現れるDestinationは、すべてアプリケーションサーバ上で定義する必要があります。
注意
Destinationの定義名は、同一のネーミングサービスを参照するサーバの範囲内で一意である必要があります。
◆Destinationの登録方法
Destinationの登録方法については、“9.8.3.3 Destination定義の登録”を参照してください。
■イベントチャネルの設計
イベントチャネルは、非同期アプリケーション連携実行基盤で利用するDestinationの実体として、メッセージを格納する機能をもちます。
非同期アプリケーション連携実行基盤で利用するイベントチャネルに対しては、Destinationを定義する必要があります。
Destinationの設計については、“■Destinationの設計”を参照してください。
◆イベントチャネルの作成単位
非同期アプリケーション連携実行基盤で利用するイベントチャネルは、以下のように作成する必要があります。
Destinationとイベントチャネルの関係が1対1
Destinationの定義としては、1つのイベントチャネルに対し、複数のDestinationを定義することが可能ですが、非同期アプリケーション連携実行基盤で利用するDestinationおよびイベントチャネルについては、1対1になるように定義してください。
また、ワークユニットに配備するアプリケーションとDestinationおよびイベントチャネルの関係は、以下のようになる必要があります。
1つの業務処理実行アプリケーションの受信キューとなるDestinationおよびイベントチャネルは1つ
1つのDestinationおよびイベントチャネルを受信キューとする業務処理実行アプリケーションの配備ファイルは1つ
◆イベントチャネルの種類
非同期アプリケーション連携実行基盤で利用可能なイベントチャネルには、以下の3種類があります。
揮発チャネル
イベントチャネル内のメッセージをメモリで管理する方式です。メモリ管理のため高速ですが、業務システムの異常終了などによりイベントチャネルが停止した場合、メッセージは削除されます。
なお、esstopchnlコマンドまたはInterstage管理コンソールでイベントチャネルを停止した場合には、メッセージは以下のように退避されます。
フロー定義ツールの異常処理定義でエラーメッセージ退避キューを定義している場合
エラーメッセージ退避キューに退避
フロー定義ツールの異常処理定義でエラーメッセージ退避キューを定義していない場合
シリアライズファイルに出力
esstopchnlコマンドの詳細は、“Interstage Application Server リファレンスマニュアル（コマンド編）”を参照してください。Interstage管理コンソールの操作については、Interstage管理コンソールのヘルプを参照してください。
不揮発チャネル
イベントチャネル内のメッセージをファイルに保存する方式です。業務システムの異常終了などによりイベントチャネルが停止しても、メッセージは保存されますが、業務処理実行アプリケーションで業務データベースの更新とメッセージ処理の同期をとる場合は、アプリケーションで重複したメッセージの読み飛ばしを行う対処が必要です。
データベース連携チャネル
イベントチャネル内のメッセージをデータベースに保存する方式です。メッセージを保存するデータベースで使用するデータベースリソースと、業務データベース更新のデータベースを同一にすることにより、トランザクションを最適化し、業務処理実行アプリケーションにおけるメッセージとデータベースの整合性を、自動的に、高速かつ高信頼に保証することができます。
なお、データベース連携チャネルを使用する場合、必ず“9.8.2 フロー定義の登録”でメッセージ格納DBのデータベースリソースを設定してください。また、データベース連携に利用するデータベースリソースと業務データベースのデータベースリソースを同一にする必要があります。
データベース連携チャネルを作成しても、メッセージ格納DBのデータベースリソースをフローに設定しない場合、イベントチャネルは揮発チャネルとして動作します。
以下に、種類別のイベントチャネルの選択指針を示します。
| メッセージ保証 | メッセージと業務データベースの整合性保証 | 設計自由度 | 性能 | 選択指針 |
|---|---|---|---|---|---|
揮発チャネル | × | × | ○ | ◎ | メッセージ保証が不要で性能重視の場合 |
不揮発チャネル | ○ | × | △ | ○ | 業務データベースを利用しないで、メッセージの保証だけ必要な場合 |
データベース連携チャネル | ○ | ○ | △ | ○ | メッセージ保証と性能をバランス良く両立させる場合 |
注1）1メッセージの最大長は64Mバイトになります。
注2）1メッセージの最大長は2Mバイトになります。
注3）1メッセージの最大長は64Mバイトになります。
注意
メッセージ長については、“Interstage Business Application Server チューニングガイド”の“メッセージ長の見積り式”を参照して計算してください。
サーバダウンなどによりフローが終了する可能性があるため、揮発チャネルを利用する場合、メッセージトラッキングDBに記録されたメッセージが存在しない可能性があります。
データベース連携用のイベントチャネルを作成する場合、メッセージ格納DBを作成する際に指定した最大蓄積メッセージ数より小さい値を、イベントデータ蓄積最大数に指定する必要があります。
イベントチャネルの種類は、同一フロー内で合わせるように設計してください。
◆イベントチャネルの作成方法
イベントチャネルの作成方法については、“9.8.3.2 イベントチャネルの作成”を参照してください。
■ユニット(保存先)の設計
ユニット(保存先)は、イベントチャネルに格納されるデータの不揮発化保存先です。不揮発チャネルを利用する場合、ユニット(保存先)を作成する必要があります。ただし、データベース連携(メッセージとDBの整合性保証機能)を利用する場合は、ユニット(保存先)を作成する必要はありません。また、揮発チャネルを利用する場合も、ユニット(保存先)を作成する必要はありません。
| メッセージ保証 | ユニット(保存先)作成 |
|---|---|---|
揮発チャネル | × | × |
不揮発チャネル | ○ | ○ |
データベース連携チャネル | ○ | × |
注) データベース連携の場合、メッセージはデータベースに保存され、保証されますが、ユニット(保存先)は作成する必要がありません。
◆ユニット(保存先)の作成方法
ユニット(保存先)の作成方法については、“9.8.3.1 ユニットの作成(不揮発チャネルを利用する場合)”を参照してください。
