この章の内容は次のとおりです。
メッセージ・キューイングは、非同期プログラム間通信のためのテクニックです。分散システム上の独立したアプリケーションの相互通信を可能にすることによりアプリケーションを統合できます。あるアプリケーションがキュー・マネージャ所有のキューにメッセージを送信し、別のアプリケーションがキューからメッセージを取り出します。各アプリケーションが異なる時期に実行されたり一時的に使用できなくなっても、アプリケーション間の通信は維持されます。
次のリストに、メッセージ・キューイングの基本的な概念を示します。
メッセージング
メッセージングは、2つのエンティティがメッセージを送受信することで通信できるようにするメカニズムです。メッセージングには、同期と非同期の2つのタイプがあります。同期メッセージングでは、メッセージの送信元がメッセージをメッセージ・キューに入れ、そのメッセージに対するリプライを待ってから自身の処理を再開します。非同期メッセージングでは、メッセージの送信元がリプライを待たずに自身の処理を続行します。
メッセージ
メッセージは、あるプログラムから別のプログラム宛に送信される構造化データです。
メッセージ・キュー
メッセージ・キューは、アプリケーションでメッセージが格納されるオブジェクトです。アプリケーションでは、メッセージをキューに蓄積し、キューからメッセージを取得できます。キューはキュー・マネージャにより管理されます。
キュー・マネージャ
キュー・マネージャは、アプリケーション・プログラム・インタフェースを介してアプリケーションにメッセージ・サービスとキューイング・サービスを提供します。キューへのアクセスを提供するのみでなく、メッセージ・チャネルを介して他のキュー・マネージャにメッセージを転送します。
メッセージ・チャネル
メッセージ・チャネルは、2つのキュー・マネージャ間の通信パスを提供します。キュー・マネージャが接続されます。メッセージ・チャネルによるメッセージの転送送信方向は一方向のみです。
転送キュー
転送キューは、リモート・キュー・マネージャ宛のメッセージを一時的に格納するために使用されます。
メッセージ・セグメント
メッセージがきわめて大きい場合は、セグメントと呼ばれる複数の小型メッセージに分割できます。各セグメントにはグループIDとオフセットがあります。メッセージのすべてのセグメントは、同じグループIDを持ちます。メッセージの最終セグメントはフラグでマークされます。
メッセージ・グループ
メッセージ・グループは、同じグループIDを持つ一連の関連メッセージで構成されます。メッセージ・グループ内の各メッセージには、メッセージ順序番号が付いています。メッセージ・グループ内の最後のメッセージはフラグでマークされます。
クラスタ
クラスタは、論理的に関連付けられたキュー・マネージャのグループです。
エンキュー/デキュー
図10-1 に示すように、エンキューとはメッセージをキューに蓄積することで、デキューとはキューからメッセージを取得することです。
リクエスト/レスポンス
リクエスト/レスポンス相互作用では、プログラムは別のプログラムにリプライを求めるメッセージを送信します。リクエスト・メッセージには、リプライの送信先情報が含まれています。受信側プログラムは、リクエスト・メッセージへのレスポンスとしてリプライ・メッセージを送信します。図10-2 にリクエスト/レスポンス相互作用を示します。
サポートされている相互作用のシナリオの詳細は、「メッセージのデキュー」を参照してください。
Messaging and Queuing Seriesは、IBM社が開発した製品および標準のセットです。保証されたメッセージ配信、セキュリティおよび優先度ベースのメッセージングを提供するキューイング・インフラストラクチャを備えています。
注意:
IBM MQ V7.5で動作確認済です。
図10-3に、アプリケーションとサーバー間の通信プロセスを示します。クライアントにより、アプリケーションからリモート・コンピュータ上のキュー・マネージャに接続できます。
各キューはキュー・マネージャに属しています。キュー・マネージャには一意の名前があり、Message Queue Interface (MQI)チャネルを介してアプリケーションにメッセージ・サービスとキューイング・サービスを提供します。また、キュー・マネージャは作成されたキューへのアクセスを提供し、メッセージ・チャネルを介してメッセージを他のキュー・マネージャに転送します。
データはメッセージ形式で送信されます。送信側アプリケーションではメッセージを作成し、APIコールを使用してキューに送信します。メッセージは、受信側アプリケーションの受信準備ができるまでキューに保持されます。受信側アプリケーションでは、APIコールを使用してキューからメッセージを取得します。
メッセージをリモート・キューに送信する場合は、リモート・キュー定義をローカルに定義する必要があります。リモート・キュー定義は、宛先キュー名と転送キュー名で構成されます。
図10-4に、メッセージのメッセージ構造を示します。
メッセージは、図10-4に示すパートで構成されます。
メッセージ・ヘッダー
メッセージ・ヘッダーには、一意のメッセージID、メッセージ・タイプ、メッセージ優先度およびルーティング情報などが含まれています。各メッセージには、メッセージ・ヘッダーが必要です。
オプション・ヘッダー
オプション・ヘッダーは、特定のアプリケーション(CICSアプリケーションなど)との通信に必須です。
詳細は、「CICSとの統合」を参照してください。
アプリケーション・データ
これには実際のデータが含まれます(索引付きファイルまたはフラット・ファイルからのレコードや、DB2の表からの行または列など)。
注意:
重要なトラブルシューティング: インバウンドMQプロセスは、相互に排他的なMessageSelectorが各インバウンド・プロセスに対して定義されていないかぎり、同じキューを使用できません。MessageSelectorが定義されていない場合、または2つ以上のインバウンド・プロセスの選択条件が重複している場合は、あるプロセスが、別のプロセス向けのメッセージを読み取ることが原因で問題が発生する可能性があります。
また、MQ Seriesアダプタのログに記録された次のメッセージはエラーではありません。これは、そのキューで使用できるメッセージがないことを示します。
com.ibm.mq.MQException: MQJE001: Completion Code 2, Reason 2033at com.ibm.mq.MQQueue.get(MQQueue.java:1033)
Oracle BPEL Process ManagerおよびOracle Mediatorとメディエータには、Oracle MQ Seriesアダプタが組み込まれています。Oracle MQ Seriesアダプタにより、アプリケーションはMQ Seriesキュー・マネージャに接続し、MQ Seriesメッセージをキューに蓄積したりキューから削除できます。
この項では、次の項目について説明します。
注意:
MQ Seriesアダプタのテスト接続スレッドが永久にブロックされることを防ぐには、KeepAlive
オプションがMQ Seriesキュー・マネージャで有効になっていることを確認します。KeepAlive
オプションの設定方法の詳細は、IBM MQのドキュメントを参照してください。
すべてのネイティブ機能を提供します。プロバイダとともに構成することはできますが、提供されるのは提供されるJMS機能のみで、ネイティブの機能は提供されません。次のリストに、上回るメリットを示します。
肯定アクション通知(PAN)および否定アクション通知(NAN)をサポートしています。
送信時の確認、着信時の確認、例外レポートおよび有効期限レポートなどのレポート・メッセージをサポートしています。
不要なメッセージや破損したメッセージのデッドレター・キューへの送信をサポートしています。
グループに属するメッセージのフィルタリングなど、高度なフィルタ・オプションが用意されています。
高速で、使用が容易です。
注意:
動作が確認されたMQ Seriesのバージョンは、WindowsでもLinuxでも7.5です。
自動的に統合されます。Oracle JDeveloper (JDeveloper)でパートナ・リンクまたはMQアダプタ・サービスを作成する際に、アダプタ構成ウィザードが起動します。
このウィザードで選択して構成できます。または他のOracle JCAアダプタを選択して構成できます。アダプタ構成ウィザードでは、図10-5 に示すように、サービス名の入力を求められます。
構成が完了すると、JDeveloperの「アプリケーション・ナビゲータ」セクションに同じ名前のWSDLファイルが作成されます。このWSDLファイルには、アダプタ構成ウィザードで指定する構成情報が含まれます。
アダプタ構成ウィザードの「操作」ページで、実行する操作の選択を求められます。選択内容に応じて、アダプタ構成ウィザードの別のページが表示され、構成情報の入力を求められます。
表10-1 に実行可能な操作と、これらの操作に関する情報が記載されている項を示します。
表10-1 Oracle BPEL Process Managerについてサポートされている操作
操作 | 参照先 |
---|---|
メッセージのエンキュー |
|
メッセージのデキュー |
|
リクエスト-レスポンス |
|
アウトバウンド・デキュー |
自動的に統合されます。JDeveloperメディエータ・デザイナでMQアダプタ・サービスを作成すると、アダプタ構成ウィザードが起動します。
このウィザードで選択して構成できます。構成が完了すると、JDeveloperの「アプリケーション・ナビゲータ」セクションに同じ名前のWSDLファイルが作成されます。このWSDLファイルには、アダプタ構成ウィザードで指定する構成情報が含まれます。
アダプタ構成ウィザードの「操作」ページで、実行する操作の選択を求められます。選択内容に応じて、アダプタ構成ウィザードの別のページが表示され、構成情報の入力を求められます。表10-2 に実行可能な操作と、指定する必要がある構成情報が記載されている項を示します。
表10-2 Oracle Mediatorについてサポートされている操作
操作 | 参照先 |
---|---|
メッセージのエンキュー |
|
メッセージのデキュー |
|
リクエスト-レスポンス |
|
アウトバウンド・デキュー |
この項では、次の機能について説明します。
RFH2ヘッダーは拡張可能なヘッダーです。RFH2ヘッダーでは、より多くのヘッダー・プロパティをペイロードに追加できます。RFH2は、メッセージ・コンテンツに関連するJMS固有データを送信します。JMSに直接関連しない追加情報も送信できます。
RFH2ヘッダーは、固定部分と可変部分の2つの部分で構成されます。同じメッセージに複数のRFH2ヘッダーが存在する場合があります。
固定部分は、standard
のMQヘッダー・パターンをモデルにして作成されており、次のフィールドで構成されています。
StrucId (MQCHAR4)
構造識別子。
初期値では、MQRFH_STRUC_ID(値: "RFH ")になります。
MQRFH_STRUC_ID_ARRAY(値: "R"、"F"、"H"、" ")を通常の方法で定義することもできます。
Version (MQLONG)
構造バージョン番号。
初期値では、MQRFH_VERSION_2(値: 2)になります。
StrucLength (MQLONG)
NameValueDataフィールドを内容としたMQRFH2の長さの合計。
StrucLengthに設定する値は、4の倍数である必要があります(このために、NameValueDataフィールドのデータをパディングできます)。
Encoding (MQLONG)
データのエンコーディング。
メッセージのうち、MQRFH2の後の部分(次のヘッダー、またはこのヘッダーの後のメッセージ・データ)に含まれているすべての数値データのエンコーディング。
CodedCharSetId (MQLONG)
コード化キャラクタ・セット識別子。
メッセージのうち、MQRFH2の後の部分(次のヘッダー、またはこのヘッダーの後のメッセージ・データ)に含まれているすべての文字データの表現。
Format (MQCHAR8)
フォーマット名。
メッセージのうち、MQRFH2の後の部分のフォーマット名。
Flags (MQLONG)
フラグ。
MQRFH_NO_FLAGS =0。フラグは設定されません。
NameValueCCSID (MQLONG)
このヘッダーに含まれているNameValueData文字列のコード化キャラクタ・セット識別子(CCSID)。NameValueDataは、ヘッダーに含まれている他の文字列(StrucIDおよびFormat)とは異なるキャラクタ・セットでコード化できます。
NameValueCCSIDフィールドが2バイトのUnicodeのCCSID (1200、13488または17584)である場合、Unicode CCSIDのバイト順は、MQRFH2の数値フィールドのバイト順と同じです(数値フィールドの例は、Version、StrucLengthまたはNameValueCCSID自体など)。
NameValueCCSIDフィールドに指定できる値は、表10-3 に示す値のみです。
表10-3 NameValueCCSIDフィールドに指定できる値
値 | 意味 |
---|---|
1200 |
拡張UCS2 |
1208 |
UTF8 |
13488 |
UCS2 2.0サブセット |
17584 |
UCS2 2.1サブセット(ユーロ記号を含む) |
固定部分の後に、可変部分が続きます。可変部分には、不特定数のMQRFH2フォルダが含まれます。同じRFH2ヘッダーに各フォルダが複数回出現する場合もあります。mqext
、mq_usr
、mqps
などの他のフォルダはRFH2フォルダに追加することもできます。詳細は、MQ RFH2ヘッダーに関するIBM社ドキュメントを参照してください。
関連するプロパティは、グループにまとめられます。MQRFH2ヘッダーには、次のメッセージ・サービス・フォルダを含めることができます。
<mcd>フォルダ
このフォルダには、メッセージの形またはフォーマットを記述するプロパティを指定します。たとえば、Msdプロパティはメッセージをテキスト、バイト、ストリーム、マップ、オブジェクトまたはNullであるとして識別します。このフォルダは、常にJMS MQRFH2に含まれています。
<jms>フォルダ
このフォルダは、JMSヘッダーのフィールドを転送する目的と、MQMDでは完全には表現できないJMSXプロパティを転送する目的に使用されます。このフォルダは、常にJMS MQRFH2に含まれています。
<usr>フォルダ
このフォルダは、メッセージに関連付けられているすべてのアプリケーション定義プロパティを転送するために使用されます。このフォルダは、アプリケーションにアプリケーション定義プロパティが設定されている場合にのみ含まれています。
<psc>フォルダ
このフォルダは、パブリッシュ/サブスクライブ・コマンド・メッセージをブローカに伝達するために使用されます。NameValueDataフィールドに許可されるpscフォルダは1つのみです。
<pscr>フォルダ
このフォルダは、パブリッシュ/サブスクライブ・コマンド・メッセージへのレスポンスとしてブローカからの情報を含めるために使用されます。レスポンス・メッセージに使用できるpscrフォルダは1つのみです。
表10-4 に、すべてのプロパティ名のリストを示します。
表10-4 JMSで使用されるMQRFH2フォルダとプロパティ
JMSフィールド名 | Javaタイプ | MQRFH2フォルダ名 | プロパティ名 | タイプ/値 |
---|---|---|---|---|
JMSDestination |
Destination |
jms |
Dst |
string |
JMSExpiration |
long |
jms |
Exp |
i8 |
JMSPriority |
int |
jms |
Pri |
i4 |
JMSDeliveryMode |
int |
jms |
Dlv |
i4 |
JMSCorrelationID |
文字列 |
jms |
Cid |
string |
JMSReplyTo |
Destination |
jms |
Rto |
string |
JMSTimestamp |
long |
jms |
Tms |
i8 |
JMSType |
文字列 |
mcd |
Type、Set、Fmt |
string |
JMSXGroupID |
文字列 |
jms |
Gid |
string |
JMSXGroupSeq |
int |
jms |
Seq |
i4 |
xxx (ユーザー定義) |
任意 |
usr |
xxx |
任意 |
mcd |
Msd |
jms_none jms_text jms_bytes jms_map jms_stream jms_object |
可変部分でプロパティを表現するには、次の構文を使用します。
NameValueLength (MQLONG)
この長さフィールドの直後に指定するNameValueData文字列のバイト単位の長さ。長さ自体の長さは含みません。NameValueLengthに設定する値は、常に4の倍数である必要があります。このために、NameValueDataフィールドをパディングできます。
NameValueData (MQCHARn)
直前のNameValueLengthフィールドによってバイト長を指定した単一文字列。これには、プロパティの順序を格納するフォルダを指定します。各プロパティは名前/タイプ/値の3つからなるセット(トリプレットと呼ばれる)で構成されており、次に示すように、これらのプロパティはフォルダ名と同じ名前のXML要素内に含まれています。
<フォルダ名> triplet1 triplet2 ..... tripletn </フォルダ名>
Secure Sockets Layer (SSL)は、インターネットまたは内部ネットワークを介して暗号化されたデータを転送するプロトコルです。SSLは、公開鍵と秘密鍵を使用して、SSL接続を介して転送されるデータを暗号化することによって機能します。公開鍵を使用して暗号化されたデータは、対応する秘密鍵でのみ復号化できます。逆に、秘密鍵を使用して暗号化されたデータは、対応する公開鍵でのみ復号化できます。
SSLを使用したクライアントとのセキュアな通信がサポートされています。この機能の一環として、SSLを使用したメッセージのエンキューがアダプタでサポートされます。SSL用に有効化するには、次のプロパティを指定する必要があります。
SSLEnable: このプロパティのtrue/false値は、SSL有効化/無効化を示します。
KeyStoreLocation: これは、秘密鍵を格納するキーストアです。このプロパティは、アダプタがサーバーから認証を受ける必要があるため必要です。
KeyStorePassword: このパスワードは、キーストアへのアクセスで必要になります。
TrustStoreLocation: これは、アダプタが信頼できる証明書情報を格納する場所です。この情報は、アダプタがサーバーから認証を受ける場合に必要になります。
Protocol: キー管理のアルゴリズム。
KeyStoreProviderName: キーストア・プロバイダの名前。
KeyStoreType: キーストアのタイプ。
KeyStoreAlgorithm: キーストアで使用されるアルゴリズム。
CipherSuite: CipherSuiteは、SVRCONN
チャネルで設定されているCipherSpecと一致する名前に設定します。NULL(デフォルト)に設定すると、SSL暗号化は実行されません。
SSLPeerName: 識別名パターン。CipherSuiteが設定されている場合、この変数を使用することによって、常に正しいキュー・マネージャが使用されるようにできます。NULL(デフォルト)に設定すると、キュー・マネージャの識別名はチェックされません。sslCipherSuite
がNULLの場合は、この変数は無視されます。
注意:
IBM社によると、WebSphere MQトランザクション・マネージャ以外によるWebSphere MQ Java Transaction API (JTA)の使用はサポートされません。IBM社では、XAトランザクションではかわりにWebSphere MQ JMS APIの使用を推奨しています。つまり、IBM MQとの対話にXAトランザクションが必要な場合、ユーザーはOracle JCA Adapter for MQ SeriesのかわりにOracle JCA Adapter for JMSを使用する必要があるということです。MQアダプタがXAトランザクションに使用されていると、XAトランザクションにロールバックする必要があるときに、アダプタにエラーが発生する可能性があります。その場合、ユーザーはインダウト・トランザクションを手動で解決する必要があります。Oracle MQ Seriesアダプタにより、固有のデータ処理とともにトランザクション・サポートが可能になり、これにより、それぞれの変更の結果が明確に定義されており、結果は成功か失敗のいずれかになるため、潜在的なデータ破損が防止され、他の変更から独立して実行され、完了後は別のトランザクションが発生するまで基礎となるデータが同じ状態で維持されることが保証されます。
Oracle MQ Seriesアダプタでは、インバウンドとアウトバウンドの両方のXAトランザクションがサポートされています。XAトランザクションを有効化するには、Oracle WebLogic Server管理コンソールでXATransaction
プロパティを設定する必要があります。XAトランザクションを有効化する手順は、次のとおりです。
パスワード資格証明を使用して、Oracle WebLogic Server管理コンソールにログインします。
左ペインの「ドメイン構造」で、「デプロイメント」をクリックします。「デプロイメントのサマリー」ページが表示されます。
「MQSeriesAdapter」をクリックします。「MQSeriesAdapterの設定」ページが表示されます。
「構成」タブをクリックします。「構成」サブメニュー・オプションが表示されます。
「アウトバウンド接続プール」をクリックします。「アウトバウンド接続プールの構成表」が表示されます。
javax.resource.cci.ConnectionFactoryの横にある「+」アイコンをクリックし、「eis/MQ/MQAdapter」を選択します。「アウトバウンド接続のプロパティ」ページが表示されます。
注意:
コンソールでオプションを有効化するには、「ロックして編集」をクリックします。
「XATransaction」オプションを選択し、「XATransaction」の端にある「プロパティ値」の行をクリックします。
図10-6 に示すように、テキスト・フィールドにtrue
と入力して「保存」をクリックします。
「トランザクション」タブをクリックします。javax.resource.cci.ConnectionFactory
の設定ページが表示されます。
「トランザクションのサポート」リストから「XAトランザクション」を選択します。
「保存」をクリックして、設定を保存します。「デプロイメント・プラン保存アシスタント」ページが表示されます。
「OK」をクリックします。
Oracle MQ Seriesアダプタに対してXAトランザクションが正常に有効化されました。
同期インバウンド・リクエスト-リプライのシナリオで、MQ SeriesのXAトランザクション機能をBPELで使用するには、bpel.config.transaction
パラメータをrequiredに設定する必要があります。このパラメータを設定しなければ、トランザクションはBPEL境界で分割され、MQはMQRC_SYNCPOINT_NOT_AVAILABLE
エラー・コードを戻します。
<property name="bpel.config.transaction">required
</property>
prepare phase
が正常に完了した後、ミドルウェアに障害が発生するなどの、フェイルオーバーが関係するシナリオでは、メッセージはMQSeriesサーバーを再起動しないでアダプタ内でリカバリされる必要があります。インダウト・トランザクションは手動で解決する必要があります。
キュー・マネージャのインダウト・トランザクションをすべて表示するには、コマンド・プロンプトで次のコマンドを実行する必要があります。
dspmqtrn -m[ourQueueManager]
メッセージをバックアウトするには、次のコマンドを使用します。
rsvmqtrn -m[ourQueueManager] -b [Transaction],[Number]
メッセージをコミットするには、次のコマンドを使用します。
rsvmqtrn -m[ourQueueManager] -c [Transaction],[Number]
注意:
dspmqtrn
コマンドの出力から[Transaction]
および[Number]
を使用できます。
Oracle BPEL Process Manager (Oracle BPEL PM)およびサービス・エンジンでのアクティブ/アクティブ・トポロジに対する高可用性機能をサポートしています。この機能は、インバウンド操作とアウトバウンド操作の両方でサポートされています。
高可用性を実現するように構成するには、次の前提条件が満たされていることを確認する必要があります。
クラスタリングされた複数のプロセスで、同じキューが使用されている必要があります。
再試行は、断続的なエラーが自動的に解決されるようにするために、バインディング・レベルで、またはフォルト・ポリシーを使用して、構成される必要があります。
インバウンド操作にのみスケーラビリティ機能がサポートされます。インバウンド・キューからメッセージをデキューするスレッドの数を制御するパラメータが用意されています。次のプロパティを.jca
ファイルで指定する必要があります。
InboundThreadCoun
t='N
'
ここで、Nは、インバウンド・キューからメッセージをデキューするために制御するスレッドの数を表しています。デフォルト設定は2です。
Oracle MQアダプタは、デプロイ時、つまりアダプタ・エンドポイントがポーリングを開始したときにバックエンド接続を作成します。接続の作成によって全体的なデプロイ・タスク自体が遅延することはありませんが、アプリケーション・サーバーで接続プールを事前にウォームアップするとわずかに利点があります。
.jcaファイルでInboundThreadCountを使用する場合の構文例を次に示します。
<adapter-config name="ExpressDeathEventListener" adapter="MQSeriesAdapter" wsdlLocation="ExpressDeathEventListener.wsdl" <xmlns="http://platform.integration.oracle/blocks/adapter/fw/metadata"> <connection-factory location="eis/MQ/MQAdapter" adapterRef=""/> <endpoint-activation portType="Dequeue_ptt" operation="Dequeue" UITransmissionPrimitive="Dequeue"> <activation-spec className="oracle.tip.adapter.mq.inbound.ActivationSpecImpl"> <property name="QueueName" value="BPMPOC_EXPCLAIMQ"/> <property name="InboundThreadCount" value="10"/> </activation-spec> </endpoint-activation> </adapter-config>
EISとのアウトバウンド接続の確立時の、エンタープライズ情報システム(EIS)の資格証明(ユーザー名やパスワードなど)の保護がサポートされています。ユーザー名とパスワードは、Oracle WebLogic Serverのコンテナ管理のサインオンを使用して保護できます。
詳細は、「エンタープライズ情報システムの資格証明の保護」を参照してください。
フォルト・ポリシー・ファイルには、フォルト条件および対応するフォルト・リカバリ・アクションを定義します。それぞれのフォルト条件で、処理を試みる特定のフォルトまたは一連のフォルトを指定し、それに対応するアクションを指定します。フォルト・ポリシー・ファイルでは一連のアクションがIDで識別されます。
フォルト・ポリシーを使用した拒否ハンドラの定義がサポートされています。
フォルト・ポリシーの詳細は、「拒否ハンドラの構成」を参照してください。
インバウンドのメッセージ拒否処理がサポートされています。メッセージ拒否ハンドラは、変換エラーを処理して修正処理を実行するように構成できます。
拒否ハンドラの詳細は、「拒否ハンドラの構成」を参照してください。
次の2つのインバウンド再試行メカニズムがサポートされています。
通常、JCAインバウンド再試行メカニズムはすべてのアダプタで共通して使用されますが、メッセージ・バックアウト・キュー・メカニズムはこれでのみ使用されます。.jcaファイルでBackoutQueueName
プロパティを指定した場合にのみ、再試行にメッセージ・バックアウト・キュー・メカニズムが使用されます。デフォルトでは、再試行にはJCAインバウンド再試行メカニズムが使用されます。
注意:
この2つの再試行方法は相互に排他的な操作であり、アダプタで一度に使用できるメカニズムは一方のみです。両方のオプションを指定した場合は、バックアウト・キュー・オプションが優先されます。
バックエンド・アプリケーションに接続してイベントを受信するためのプル・モデルがサポートされています。接続関連の問題はリカバリ可能とみなされ、ほとんどのインバウンド・アダプタはEISとの接続を確立できるまで再試行を続けます。
この場合、メッセージをキューに蓄積できない場合も再試行可能です。
再試行メカニズムの詳細は、「エラー処理」を参照してください。
バックアウト・キューは、インバウンド・キューから拒否されたメッセージが蓄積されるキューです。インバウンド・アダプタはメッセージのバックアウト数をチェックし、この数がMaximumBcakoutCount
値を超えた場合、指定されたバックアウト・キューにメッセージを蓄積します。このメカニズムを使用して、拒否されたメッセージのインバウンド再試行が処理されます。
.jca
ファイルでBackoutQueueName
プロパティを指定すると、再試行にメッセージのバックアウト数が使用されます。MaximumBackoutCount
プロパティを使用して最大再試行回数を指定できます。このプロパティのデフォルト値はinfiniteです。MaximumBackoutCount
値をBackoutQueueName
とともに指定しない場合、アダプタは無制限に再試行します。バックアウト・キュー・プロパティが指定されている場合、アダプタは(composite.xmlで指定された)JCA
再試行を考慮しません。
BackoutRetries
プロパティを設定して、メッセージをバックアウト・キューに配信する再試行の回数を指定する必要があります。この再試行の間隔はBackoutRetryInterval
を使用して設定されます。BackoutRetries
のデフォルト値は3
で、BackoutInterval
は5
秒です。
MaximumBackoutCount
値に達した後もメッセージが拒否される場合、アダプタはメッセージをバックアウト・キューに蓄積します。メッセージをバックアウト・キューに蓄積できなければ、BackoutInterval
の時間遅延を使用してBackoutRetries
数になるまで試行します。BackoutRetriesの後もメッセージをバックアウト・キューに蓄積できない場合、アダプタはエンドポイントを非アクティブ化します。
BackoutQueueManagerName
プロパティで、バックアウト・キューのキュー・マネージャの名前も指定する必要があります。BackoutQueueがインバウンド・キューQueueManagerにある場合、このプロパティは使用できません。
注意:
バックアウト・キューを使用する場合は、次の点を考慮してください。
バックアウト・キュー・オプションは、変換の失敗には使用できません。
JCA再試行とBackOut再試行の両方が指定されている場合は、BackOut再試行が優先されます。
バックアウト・キューの構成の詳細は、「バックアウト・キューの構成」を参照してください。
この項では、次の概念について説明します。
次のメッセージング・シナリオをサポートしています。
このシナリオではキュー・マネージャにより管理されている特定のキューに接続してメッセージを書き込みます。Oracle BPEL PMから送信されるアウトバウンド・メッセージの場合、次の操作が実行されます。
Oracle BPEL PMからメッセージを受信します。
設計時の指定に従ってXMLコンテンツがフォーマットされます。
メッセージのプロパティ(優先度、有効期限、メッセージ・タイプおよび永続性など)が設定されます。これらのプロパティは、アダプタ構成ウィザードで選択した内容に基づきます。
メッセージのプロパティの詳細は、「メッセージ・タイプ」を参照してください。
設計時にアダプタ構成ウィザードで指定したキューにメッセージが送信されます。
図10-7 に、アダプタ構成ウィザードで選択する必要がある操作タイプを示します。
図10-8 に、「MQにメッセージを蓄積」操作タイプを選択した後に表示されるページを示します。
このページで次のプロパティを指定できます。
キュー名: メッセージをエンキューするキューの名前。これは必須フィールドです。
キュー・マネージャ: キューが属しているキュー・マネージャの名前です。このフィールドはオプションで、メッセージをリモート・キューにエンキューする場合に必要です。
一部配信: このオプションを適用できるのは、アウトバウンド操作用のキューを複数指定した場合(配布リストのシナリオ)のみです。「一部配信」の値は、true
またはfalse
です。true
を割り当てると、一部のキューでメッセージの配信に失敗しても、メッセージは配布リストで指定した残りのキューに入れられて蓄積されます。false
を割り当てると、メッセージの1つに失敗しても、そのメッセージはキューに蓄積されません。
メッセージの書式: メッセージのフォーマット。
注意:
メッセージをエンキューする場合は、特定のフォーマットに必要な各種の必須値を正しく指定していることを確認してください。
優先度: 0(最低)から9(最高)までのメッセージの優先度。
永続性: メッセージの永続性。メッセージの永続性を、宛先キューで定義されているデフォルトの永続性属性から取得するように指定することも可能です。
配信失敗: メッセージの配信に失敗した場合、そのメッセージを配信不能キューに蓄積するか、または破棄できます。
必要な場合、メッセージをセグメント化できます: これは、大きすぎてキューに収まらないメッセージに適用可能です。その場合、セグメント化するように指定していれば、単一メッセージをキューで対応できるバイト数の複数のメッセージに分割できます。
有効期限: メッセージの有効期限。有効期限が経過したメッセージは破棄されます。
これらのプロパティの詳細は、「メッセージ・プロパティ」を参照してください。
次に表示されるアダプタ構成ウィザードのページは、図10-9 の「メッセージ」ページです。このページでは、変換用のXMLスキーマ定義(XSD)ファイルを選択できます。
ネイティブ・フォーマット変換が不要である場合は(JPGまたはGIFイメージが処理中であるなど)、「ネイティブ・フォーマット変換は不要」チェック・ボックスを選択します。ファイルはBase64エンコーディングで渡されます。
トランスレーションにはXSDファイルが必要です。新しいスキーマの定義、または既存のデータ型定義(DTD)やCOBOLコピーブックの変換を行うには、「ネイティブ・フォーマットのスキーマの定義」を選択します。これにより、ネイティブ・フォーマット・ビルダー・ウィザードが起動されます。このウィザードは、特殊文字区切り、カンマ区切り値(CSV)、固定長、DTDおよびCOBOLコピーブックなどのファイル・フォーマットを使用したネイティブ・スキーマ・ファイルの作成を支援します。ネイティブ・スキーマ・ファイルの作成後、「スキーマ・ファイルのURL」および「スキーマ要素」フィールドが入力された「メッセージ」ページが表示されます。
詳細は、「ネイティブ・フォーマット・ビルダー・ウィザードを使用したネイティブ・スキーマ・ファイルの作成」を参照してください。
注意:
指定するスキーマにネームスペースが含まれていることを確認してください。スキーマにネームスペースが含まれていない場合は、エラー・メッセージが表示されます。
このシナリオでは、キュー・マネージャにより管理されている特定のキューに接続し、そのキューからメッセージを削除します。Oracle BPEL PMに送信されるインバウンド・メッセージの場合、次の操作が実行されます。
設計時に指定したキューに接続されます。
メッセージの着信時にキューからメッセージがデキューされます。
設計時に定義したトランスレーション・ロジックに基づいて、メッセージが読み取られて変換されます。
メッセージがXMLメッセージとしてOracle BPEL PMにパブリッシュされます。
図10-10 に、アダプタ構成ウィザードで選択する必要がある操作タイプを示します。
図10-11 に、「MQからメッセージを取得」操作タイプを選択した後に表示されるページを示します。
このページで次のプロパティを指定できます。
キュー名: メッセージをデキューするキューの名前。これは必須フィールドです。
スキーマ・オプション: このオプションを使用すると、メッセージのデキューに使用するスキーマを指定できます。
他のスキーマを選択します: このオプションでは、メッセージのデキューに使用するスキーマを選択できます。
事前定義済スキーマを選択します: このオプションでは、アダプタに用意されている事前定義済のスキーマを選択できます。
次に表示されるアダプタ構成ウィザードのページは、図10-9 の「メッセージ」ページです。このページでは、変換用のXSDスキーマ・ファイルを選択できます。
メッセージ発行操作のスキーマの指定と同様に、このページでは次のタスクを実行できます。
ネイティブ・フォーマット変換の要不要の指定
変換用のXSDスキーマ・ファイルの選択
CSV、固定長、DTDおよびCOBOLコピーブックなどのファイル形式からXSDファイルの作成が可能なネイティブ・フォーマット・ビルダー・ウィザードの起動
「メッセージ」ページの詳細は、「メッセージのエンキュー」を参照してください。
このシナリオでは、Oracle BPEL PMがリクエスト・メッセージを送信し、非開始のreceiveアクティビティを使用して対応するレスポンスを受信します。invokeアクティビティによりアダプタのアウトバウンド起動が開始され、リクエストが送信されます。次の操作を実行します。
Oracle BPEL PMからのメッセージが受信されます。
設計時にアダプタ構成ウィザードで指定したXMLコンテンツがフォーマットされます。
リクエスト・メッセージのプロパティと相関スキーマが設定されます。
設計時に指定したキューにメッセージが送信されます。サード・パーティ・アプリケーションはメッセージを受信して処理し、レスポンスを生成してから、リクエスト・メッセージで指定されたreplyTo
キューにレスポンス・メッセージをエンキューします。レスポンス・メッセージの相関IDとメッセージIDは、リクエスト・メッセージで指定された相関スキーマに基づいて生成されます。
replyTo
キューからメッセージがデキューされます。
レスポンスがメディエータの非開始のreceiveアクティビティに送信されます。レスポンスが正しいBPELインスタンスに確実に送信されるように、相関スキーマが使用されます。
図10-12 に、アダプタ構成ウィザードで選択する必要がある操作タイプを示します。
図10-13 に、「MQにメッセージを送信し、リプライ/レポートを取得」操作タイプを選択した後に表示されるページを示します。
このページで次のプロパティを指定できます。
メッセージ・タイプ: メッセージのタイプ。通常メッセージまたはリクエスト・メッセージを送信できます。
レポートの取得: なんらかのレポートが必要な場合は、このオプションを選択します。レポートのタイプは、図10-14 に示す次のページで指定できます。
キュー名: メッセージをエンキューするキューの名前。これは必須フィールドです。
キュー・マネージャ: キューが属しているキュー・マネージャの名前です。このフィールドはオプションです。
メッセージの書式: メッセージのフォーマット。
優先度: 0(最低)から9(最高)までのメッセージの優先度。
永続性: メッセージの永続性。メッセージの永続性を、宛先キューで定義されているデフォルトの永続性属性から取得するように指定することも可能です。
配信失敗: メッセージの配信に失敗した場合、そのメッセージを配信不能キューに蓄積するか、または破棄できます。
必要な場合、メッセージをセグメント化できます: これは、大きすぎてキューに収まらないメッセージに適用可能です。その場合、セグメント化するように指定していれば、単一メッセージをキューで対応できるバイト数の複数のメッセージに分割できます。
有効期限: メッセージの有効期限。有効期限が経過したメッセージは破棄されます。
これらのプロパティの詳細は、「メッセージ・プロパティ」および「レポート・メッセージ」を参照してください。
「MQにメッセージを送信し、リプライ/レポートを取得」ページで「次へ」をクリックすると、「レポート」ページ(図10-14 )または「レスポンス」ページ(図10-15 )が表示されます。
図10-14 に示す「レポート」ページが表示されるのは、図10-13 に示した「MQにメッセージを送信し、リプライ/レポートを取得」ページで「レポートの取得」オプションを選択した場合のみです。
このページで次のレポート・タイプを選択できます。
着信時の確認
送信時の確認
例外レポート
有効期限レポート
これらのレポート・タイプの詳細は、「レポート・メッセージ」を参照してください。
「レポート」ページで「次へ」をクリックすると、図10-15 に示す「レスポンス」ページが表示されます。
「レスポンス」ページで次のプロパティを指定できます。
返信先キュー名: 返信先キューの名前。
「相関スキーム」: 必要な相関スキーマ。
相関スキーマの詳細は、「相関スキーマ」を参照してください。
スキーマ・オプション: このオプションを使用すると、メッセージのデキューに使用するスキーマを指定できます。
他のスキーマを選択します: このオプションでは、メッセージのデキューに使用するスキーマを選択できます。
事前定義済スキーマを選択します: このオプションでは、アダプタに用意されている事前定義済のスキーマを選択できます。
注意:
非同期アウトバウンド・リクエスト/リプライのシナリオ(このシナリオでは、リクエスト・メッセージはキューに蓄積され、このリクエストに対するリプライはreplyToQueueから非同期でデキューされます)の場合、プロパティは(Enqueue)
または(Dequeue)
ラベルによって区別されます。この区別は、エンキューとデキューのプロパティ名を区別するために必要です。たとえば、QueueName(Enqueue)
はメッセージの蓄積に使用され、QueueName(Dequeue)
はリプライのデキューに使用されます。
使用してこのシナリオのプロパティを編集する場合は、次の点に注意してください。
リクエスト・メッセージのreplyToQueueは、リプライのデキュー元と同じであるため、ReplyToQueueName(Enqueue)
プロパティを変更する場合は、QueueName(Dequeue)
プロパティも同じ値に変更する必要があります。
同様に、MessageId(Dequeue)
プロパティを変更する場合は、MessageId(Enqueue)
プロパティも同じ値に変更する必要があります。
同様に、CorrelationId(Dequeue)
プロパティを変更する場合は、CorrelationId(Enqueue)
プロパティも同じ値に変更する必要があります。
「レスポンス」ページで「次へ」をクリックすると、図10-16 に示す「メッセージ」ページが表示されます。このページでは、リクエスト・メッセージとレスポンス・メッセージの変換に使用するXSDスキーマ・ファイルを選択できます。
このページで次のタスクを実行できます。
ネイティブ・フォーマット変換の要不要の指定
変換用のXSDスキーマ・ファイルの選択
CSV、固定長、DTDおよびCOBOLコピーブックなどのファイル形式からXSDファイルの作成が可能なネイティブ・フォーマット・ビルダー・ウィザードの起動
「メッセージ」ページの詳細は、「メッセージのエンキュー」を参照してください。
請求-リクエスト-レスポンスのシナリオでは、リクエスト・メッセージを介して提供される、なんらかの相関スキームで指定されたリプライ・キュー内でリプライ・メッセージが予期されます。このリプライ・キューは特定のプロセス(BPEL/メディエータ)により使用され、他のプロセスでは使用されません。
同じリプライ・キューが他のなんらかのアプリケーションで使用される場合は、リプライ・メッセージの相関付けが正しいかどうかに関係なくメッセージが取得され、最終的にはメッセージが消失します。
このシナリオでは、Oracle BPEL PMがリクエストを受信して処理し、replyアクティビティを使用してレスポンスを同期的に送信します。次の操作を実行します。
メッセージの着信時にキューからリクエスト・メッセージがデキューされます。
設計時に定義したトランスレーション・ロジックに基づいて、メッセージが読み取られて変換されます。
メッセージがXMLメッセージとしてOracle BPEL PMにパブリッシュされます。Oracle BPEL PMでは、リクエストが処理されてレスポンスが送信されます。
Oracle BPEL PMからのレスポンス・メッセージが受信されます。
設計時の指定に従ってXMLコンテンツがフォーマットされます。
メッセージのプロパティ(優先度、有効期限、メッセージ・タイプおよび永続性など)が設定されます。これらのプロパティは、アダプタ構成ウィザードで選択した内容に基づきます。
設計時にアダプタ構成ウィザードで指定したキューにメッセージが送信されます。
図10-17 に、このシナリオのサンプルBPELプロセスを示します。
図10-17 同期リクエスト-レスポンスのサンプル(Oracle BPEL PMがサーバーの場合)
図10-18 に、アダプタ構成ウィザードで選択する必要がある操作タイプを示します。
図10-19 に、「MQからメッセージを取得し、リプライ/レポートを送信」操作タイプを選択した後に表示されるページを示します。このページで、メッセージがデキューされるキュー名を指定します。
「MQからメッセージを取得し、リプライ/レポートを送信」ページで「次へ」をクリックすると、図10-20 に示す「レスポンス」ページが表示されます。
「レスポンス」ページで次のプロパティを指定できます。
メッセージ・タイプ: デキューするメッセージのタイプ。このオプションは返信メッセージ・タイプに影響します。
メッセージの書式: メッセージのフォーマット。
優先度: メッセージの優先度。
永続性: メッセージの永続性。メッセージの永続性を、宛先キューで定義されているデフォルトの永続性属性から取得するように指定することも可能です。
配信失敗: メッセージの配信に失敗した場合、そのメッセージを配信不能キューに蓄積するか、または破棄できます。
必要な場合、メッセージをセグメント化できます: これは、大きすぎてキューに収まらないメッセージに適用可能です。その場合、セグメント化するように指定していれば、単一メッセージをキューで対応できるバイト数の複数のメッセージに分割できます。
有効期限: メッセージの有効期限。
これらのプロパティの詳細は、「メッセージ・プロパティ」を参照してください。
「レスポンス」ページで「次へ」をクリックすると、図10-16 に示す「メッセージ」ページが表示されます。このページで次のタスクを実行できます。
ネイティブ・フォーマット変換の要不要の指定
変換用のXSDスキーマ・ファイルの選択
CSV、固定長、DTDおよびCOBOLコピーブックなどのファイル形式からXSDファイルの作成が可能なネイティブ・フォーマット・ビルダー・ウィザードの起動
「メッセージ」ページの詳細は、「メッセージのエンキュー」を参照してください。
Oracle BPEL PMがリクエスト-レスポンス相互作用を開始すると、BPELプロセスはリクエストをインバウンド・メッセージとして受信し、処理してからinvokeアクティビティを介してレスポンスを送信します。非同期リクエスト-リプライのシナリオでは、次の操作が実行されます。
メッセージの着信時にキューからメッセージがデキューされます。
設計時に定義したトランスレーション・ロジックに基づいて、メッセージが読み取られて変換されます。
メッセージがXMLメッセージとしてOracle BPEL PMにパブリッシュされます。Oracle BPEL PMでは、リクエストが処理されてレスポンスが送信されます。
Oracle BPEL PMからのメッセージが受信されます。
設計時の指定に従ってXMLコンテンツがフォーマットされます。
メッセージのプロパティ(優先度、有効期限、メッセージ・タイプおよび永続性など)が設定されます。これらのプロパティは、アダプタ構成ウィザードで選択した内容に基づきます。
設計時にアダプタ構成ウィザードで指定したキューにメッセージが送信されます。
図10-21 に、このシナリオのサンプルBPELプロセスを示します。
図10-21 非同期リクエスト-レスポンスのサンプル(Oracle BPEL PMがサーバーの場合)
図10-22 に、アダプタ構成ウィザードで選択する必要がある操作タイプを示します。
図10-19 に、「MQからメッセージを取得し、リプライ/レポートを送信」操作タイプを選択した後に表示されるページを示します。このページで、メッセージがデキューされるキュー名を指定します。
「MQからメッセージを取得し、リプライ/レポートを送信」ページで「次へ」をクリックすると、図10-20 に示す「レスポンス」ページが表示されます。
「レスポンス」ページで次のプロパティを指定できます。
メッセージ・タイプ: デキューするメッセージのタイプ。このオプションは返信メッセージ・タイプに影響します。
メッセージの書式: メッセージのフォーマット。
優先度: メッセージの優先度。
永続性: メッセージの永続性。メッセージの永続性を、宛先キューで定義されているデフォルトの永続性属性から取得するように指定することも可能です。
配信失敗: メッセージの配信に失敗した場合、そのメッセージを配信不能キューに蓄積するか、または破棄できます。
必要な場合、メッセージをセグメント化できます: これは、大きすぎてキューに収まらないメッセージに適用可能です。その場合、セグメント化するように指定していれば、単一メッセージをキューで対応できるバイト数の複数のメッセージに分割できます。
有効期限: メッセージの有効期限。
これらのプロパティの詳細は、「メッセージ・プロパティ」を参照してください。
「MQからメッセージを取得し、リプライ/レポートを送信」ページで「次へ」をクリックすると、「レスポンス」ページ(図10-23 および図10-24 )が表示されますが、これらのページのオプションのセットは互いに異なります。
図10-24 に示す「レスポンス」ページが表示されるのは、「MQからメッセージを取得し、リプライ/レポートを送信」ページの「メッセージ・タイプ」フィールドで「標準」オプションを選択した場合のみです。
「レスポンス」ページで次のプロパティを指定できます。
(オプション)フォールバック返信先キュー: レスポンス・フォールバック・キュー名を入力します。レスポンス・メッセージは、リクエスト・メッセージのreplyToQueueプロパティで指定されたキューにエンキューされます。ただし、リクエスト・メッセージでreplyToQueueプロパティが設定されていない場合、ここに名前を入力することにより、プロセスがレスポンスをエンキューできるようになります。
(オプション)フォールバック返信先キュー・マネージャ: セカンダリ・キュー名を入力します。この名前が使用されるのは、JNDI接続名の指定時に設定したプライマリ・キュー・マネージャが、「キュー名」フィールドに入力されているキュー名にアクセスできない場合です。これは、「フォールバック返信先キュー」フィールドの説明にある機能に類似しています。
「レスポンス」ページでの他のプロパティの指定方法は、図10-23 で説明されているプロパティを参照してください。
「レスポンス」ページで「次へ」をクリックすると、図10-25 に示す「メッセージ」ページが表示されます。このページで次のタスクを実行できます。
ネイティブ・フォーマット変換の要不要の指定
変換用のXSDスキーマ・ファイルの選択
CSV、固定長、DTDおよびCOBOLコピーブックなどのファイル形式からXSDファイルの作成が可能なネイティブ・フォーマット・ビルダー・ウィザードの起動
「メッセージ」ページの詳細は、「メッセージのエンキュー」を参照してください。
非同期リクエスト-リプライ相互作用では、インバウンド・メッセージ・ヘッダーからアウトバウンド・メッセージ・ヘッダーに次のプロパティをマップする必要があります。
MsgID
: メッセージIDを指します。
CorrelID
: メッセージの相関IDを指します。
CorrelationScheme
: リクエスト・メッセージのmsgidとcorrelidの組合せを指します。
詳細は、「相関スキーマ」を参照してください。
ReplyToQ
: レスポンス・キューの名前を指します。
ReplyToQueueManager
: レスポンス・キュー・マネージャの名前を指します。
これらのプロパティはassignアクティビティを使用してマップできます。
このシナリオでは、リクエストを受信して処理し、レスポンスを同期的に送信します。次の操作を実行します。
メッセージの着信時にキューからリクエスト・メッセージがデキューされます。
設計時に定義したトランスレーション・ロジックに基づいて、メッセージが読み取られて変換されます。
メッセージがXMLメッセージとしてパブリッシュされます。リクエストが処理されてレスポンスが送信されます。
レスポンス・メッセージが受信されます。
設計時の指定に従ってXMLコンテンツがフォーマットされます。
メッセージのプロパティ(優先度、有効期限、メッセージ・タイプおよび永続性など)が設定されます。これらのプロパティは、アダプタ構成ウィザードで選択した内容に基づきます。
設計時にアダプタ構成ウィザードで指定したキューにメッセージが送信されます。
図10-19 に、アダプタ構成ウィザードで選択する必要がある操作タイプを示します。
これ以降のページは、すべて「同期リクエスト-レスポンス(サーバーの場合)」で説明したページと同様です。
注意:
メディエータの場合、非同期リクエスト-レスポンス・パターンはサポートされていません。
アウトバウンドの同期-請求-リクエスト-レスポンスのシナリオがサポートされています。このシナリオでは、アダプタにより同期的に通常/リクエスト・メッセージがキューにエンキューされてレポート/リプライが予想されます。レポート/リプライ・メッセージは、通常/リクエスト・メッセージのReplyToQueueName
キューに着信します。
注意:
グローバル・トランザクションに参加している場合、リクエスト・メッセージはエンキューされないため、非XAモードでアウトバウンド同期-請求-レスポンスを実行する必要があります。
図10-29 に、アダプタ構成ウィザードで選択する必要がある操作タイプを示します。
図10-13 に、「MQにメッセージを送信し、リプライ/レポートを取得」操作タイプを選択した後に表示されるページを示します。
このページで次のプロパティを指定できます。
メッセージ・タイプ: メッセージのタイプ。通常メッセージまたはリクエスト・メッセージを送信できます。
キュー名: メッセージをエンキューするキューの名前。これは必須フィールドです。
キュー・マネージャ: キューが属しているキュー・マネージャの名前です。このフィールドはオプションで、メッセージをリモート・キューにエンキューする場合に必要です。
メッセージの書式: メッセージのフォーマット。
優先度: 0(最低)から9(最高)までのメッセージの優先度。
永続性: メッセージの永続性。メッセージの永続性を、宛先キューで定義されているデフォルトの永続性属性から取得するように指定することも可能です。
配信失敗: メッセージの配信に失敗した場合、そのメッセージを配信不能キューに蓄積するか、または破棄できます。
必要な場合、メッセージをセグメント化できます: これは、大きすぎてキューに収まらないメッセージに適用可能です。その場合、セグメント化するように指定していれば、単一メッセージをキューで対応できるバイト数の複数のメッセージに分割できます。
有効期限: メッセージの有効期限。有効期限が経過したメッセージは破棄されます。
「MQにメッセージを送信し、リプライ/レポートを取得」ページで「次へ」をクリックすると、図10-30 に示す「レスポンス」ページが表示されます。
同期リクエスト-レスポンスのシナリオでは、「レスポンス」ページで次のプロパティも編集する必要があります。
返信先キュー名: 返信先キューの名前。
「相関スキーム」: 使用される必要がある相関スキーマ。
相関スキーマの詳細は、「相関スキーマ」を参照してください。
スキーマ・オプション: このオプションを使用すると、メッセージのデキューに使用するスキーマを指定できます。
他のスキーマを選択します: このオプションでは、メッセージのデキューに使用するスキーマを選択できます。
事前定義済スキーマを選択します: このオプションでは、アダプタに用意されている事前定義済のスキーマを選択できます。
レスポンス待機間隔: このプロパティに有効な値は、任意の間隔値(>= 0)です。これは、アダプタがreplyToQueueName
へのレポート/リプライの着信を待機するミリ秒数です。デフォルトでは、このプロパティの値は0(ゼロ)ミリ秒です。この値は変更できますが、アウトバウンド・アクティビティのタイムアウト間隔よりも小さい値に設定する必要があります。レポート/リプライ・メッセージが規定の時間内に着信しなければ、アダプタにより例外がスローされます。このプロパティはオプションです。
注意:
ResponseWaitInterval
は、アウトバウンド・アクティビティのタイムアウト間隔よりも小さい値に設定する必要があります。ResponseWaitInterval
の値がアウトバウンド・アクティビティのタイムアウトを超えると、アダプタの動作が曖昧になる可能性があります。
アウトバウンドの同期-請求-リクエスト-レスポンスのシナリオもサポートされています。このシナリオでは、アダプタにより同期的に通常/リクエスト・メッセージがキューにエンキューされてレポート/リプライが予想されます。レポート/リプライ・メッセージは、通常/リクエスト・メッセージのReplyToQueueNameキューに着信します。
同期リクエスト-レスポンス(Oracle Mediatorがクライアントの場合)のシナリオは、同期リクエスト-レスポンス(Oracle BPELがクライアントの場合)と同じです。同期リクエスト-レスポンスのシナリオの詳細は、「同期リクエスト-レスポンス(クライアントの場合)」を参照してください。
このシナリオでは、Oracle Mediatorがリクエスト・メッセージを送信し、Mediatorコールバック・ハンドラから対応するレスポンスを受信します。Oracle Mediatorでは、アウトバウンド起動が送信されてリクエストが送信されます。次の操作を実行します。
Oracle Mediatorからのメッセージが受信されます。
設計時にアダプタ構成ウィザードで指定したXMLコンテンツがフォーマットされます。
リクエスト・メッセージのプロパティと相関スキーマが設定されます。
設計時に指定したキューにメッセージが送信されます。サード・パーティ・アプリケーションはメッセージを受信して処理し、レスポンスを生成してから、リクエスト・メッセージで指定されたreplyTo
キューにレスポンス・メッセージをエンキューします。レスポンス・メッセージの相関IDとメッセージIDは、リクエスト・メッセージで指定された相関スキーマに基づいて生成されます。
replyTo
キューからメッセージがデキューされます。
メッセージのプロパティ(優先度、有効期限、メッセージ・タイプおよび永続性など)が設定されます。これらのプロパティは、アダプタ構成ウィザードで選択した内容に基づきます。
レスポンスがBPELプロセスの非開始のreceiveアクティビティに送信されます。レスポンスが正しいBPELインスタンスに確実に送信されるように、相関スキーマが使用されます。
図10-12 に、アダプタ構成ウィザードで選択する必要がある操作タイプを示します。
図10-13 に、「MQにメッセージを送信し、リプライ/レポートを取得」操作タイプを選択した後に表示されるページを示します。
このページで次のプロパティを指定できます。
メッセージ・タイプ: メッセージのタイプ。通常メッセージまたはリクエスト・メッセージを送信できます。
キュー名: メッセージをエンキューするキューの名前。これは必須フィールドです。
メッセージの書式: メッセージのフォーマット。
キュー・マネージャ: キューが属しているキュー・マネージャの名前です。このフィールドはオプションで、メッセージをリモート・キューにエンキューする場合に必要です。
優先度: 0(最低)から9(最高)までのメッセージの優先度。
永続性: メッセージの永続性。メッセージの永続性を、宛先キューで定義されているデフォルトの永続性属性から取得するように指定することも可能です。
配信失敗: メッセージの配信に失敗した場合、そのメッセージを配信不能キューに蓄積するか、または破棄できます。
必要な場合、メッセージをセグメント化できます: これは、大きすぎてキューに収まらないメッセージに適用可能です。その場合、セグメント化するように指定していれば、単一メッセージをキューで対応できるバイト数の複数のメッセージに分割できます。
有効期限: メッセージの有効期限。有効期限が経過したメッセージは破棄されます。
これらのプロパティの詳細は、「メッセージ・プロパティ」および「レポート・メッセージ」を参照してください。
「MQにメッセージを送信し、リプライ/レポートを取得」ページで「次へ」をクリックすると、「レポート」ページ(図10-14 )または「レスポンス」ページ(図10-15 )が表示されます。
図10-14 に示す「レポート」ページが表示されるのは、図10-13 に示した「MQにメッセージを送信し、リプライ/レポートを取得」ページで「レポートの取得」オプションを選択した場合のみです。
図10-15 に示す「レスポンス」ページは、「リクエスト」オプションと「標準」オプションのどちらを選択したかに関係なく表示されます。唯一の違いは、「リクエスト」オプションを選択すると、「レスポンス」ページの「メッセージ・タイプ」フィールドにREPLY
と表示されることです。これに対して、「標準」オプションを選択すると、「レスポンス」ページの「メッセージ・タイプ」フィールドにはREPORTS
と表示されます。
図10-14 に示すように、次のレポート・タイプを選択できます。
着信時の確認
送信時の確認
例外レポート
有効期限レポート
これらのレポート・タイプの詳細は、「レポート・メッセージ」を参照してください。
「レポート」ページで「次へ」をクリックすると、図10-15 に示す「レスポンス」ページが表示されます。
「レスポンス」ページで次のプロパティを指定できます。
返信先キュー名: 返信先キューの名前。
「相関スキーム」: 使用される相関スキーマ。
相関スキーマの詳細は、「相関スキーマ」を参照してください。
スキーマ・オプション: このオプションを使用すると、メッセージのデキューに使用するスキーマを指定できます。
他のスキーマを選択します: このオプションでは、メッセージのデキューに使用するスキーマを選択できます。
事前定義済スキーマを選択します: このオプションでは、アダプタに用意されている事前定義済のスキーマを選択できます。
注意:
非同期のアウトバウンド・リクエスト/リプライ・シナリオでは、プロパティは(Enqueue)
または(Dequeue)
ラベルによって区別されます。たとえば、QueueName(Enqueue)
はメッセージの蓄積に使用され、QueueName(Dequeue)
はリプライのデキューに使用されます。
使用してこのシナリオのプロパティを編集する場合は、次の点に注意してください。
ReplyToQueueName(Enqueue)
プロパティを変更する場合は、QueueName(Dequeue)
プロパティも同じ値に変更する必要があります。
MessageId(Dequeue)
プロパティを変更する場合は、MessageId(Enqueue)
プロパティも同じ値に変更する必要があります。
CorrelationId(Dequeue)
プロパティを変更する場合は、CorrelationId(Enqueue)
プロパティも同じ値に変更する必要があります。
「レスポンス」ページで「次へ」をクリックすると、図10-16 に示す「メッセージ」ページが表示されます。このページでは、リクエスト・メッセージとレスポンス・メッセージの変換に使用するXSDスキーマ・ファイルを選択できます。
「メッセージ」ページの詳細は、「メッセージのエンキュー」を参照してください。
アウトバウンド・デキューのシナリオでは、アダプタ構成ウィザードの「操作タイプ」ページで「MQからメッセージを取得」オプションを使用し、アウトバウンドを使用してキューから単一メッセージをデキューします。アウトバウンド・デキュー・オプションを有効化するには、図10-29 に示すように「同期」オプションを選択する必要があります。
「MQにメッセージを送信し、リプライ/レポートを取得」ページで「次へ」をクリックすると、図10-30 に示す「レスポンス」ページが表示されます。「レスポンス」ページで次のプロパティを設定する必要があります。
QueueName: メッセージのデキュー元のキュー名です。このプロパティは必須です。
レスポンス待機間隔: メッセージがキューにない場合にアダプタが待機するミリ秒数です。このプロパティのデフォルト値は0(ゼロ)ミリ秒です。このプロパティはオプションです。このプロパティに有効な値は、任意の整数値(>= 0)です。このプロパティには、アウトバウンド・アクティビティのタイムアウトよりも小さい値を設定する必要があります。
注意:
ResponseWaitInterval
は、アウトバウンド・アクティビティのタイムアウト間隔よりも小さい値に設定する必要があります。ResponseWaitInterval
の値がアウトバウンド・アクティビティのタイムアウトを超えると、アダプタの動作が曖昧になる可能性があります。
オプションで、次の2つのヘッダー・プロパティを使用して、デキューされるメッセージをメッセージIDおよび相関IDに基づいてフィルタ処理できます。
jca.mq.MQMD.MsgId
: このプロパティは、messageId
に基づいてメッセージ・フィルタ・オプションを設定します。このプロパティに設定する値は、特定のmessageId
の16進数エンコード値である必要があります。
jca.mq.MQMD.CorrelId
: このプロパティは、correlationId
に基づいてメッセージ・フィルタ・オプションを設定します。このプロパティに設定する値は、特定のcorrelationId
の16進数エンコード値である必要があります。
次のメッセージ・プロパティをサポートしています。
次の4タイプのメッセージをサポートしています。
通常メッセージ
通常メッセージは、あるプログラムから別のプログラムに送信されますが、レスポンスは期待されません。
リクエスト・メッセージ
リクエスト・メッセージは、あるプログラムから別のプログラムに送信され、レスポンスが必要です。
リプライ・メッセージ
リプライ・メッセージは、リクエスト・メッセージに対するレスポンスとしてプログラムにより送信されます。
レポート・メッセージ
レポート・メッセージは、受信側プログラムから送信側プログラムに、メッセージ配信の成功または失敗の確認として送信されます。レポート・メッセージはすべてのメッセージ・タイプ(通常メッセージ、リクエスト・メッセージまたはリプライ・メッセージ)について生成できます。
サポートされている確認メッセージの詳細は、「レポート・メッセージ」を参照してください。
図10-8 のように、アダプタ構成ウィザードを介して送信メッセージのフォーマットを指定できます。次のメッセージ・フォーマットがサポートされています。
フォーマット名なし(デフォルト)
コマンド・サーバー・リクエスト/リプライ・メッセージ
タイプ1コマンド・リプライ・メッセージ
タイプ2コマンド・リプライ・メッセージ
配信不能ヘッダー
イベント・メッセージ
プログラム可能なコマンド・フォーマットによるユーザー定義メッセージ
文字のみで構成されるメッセージ
トリガー・メッセージ
転送キュー・ヘッダー
図10-8 のように、アダプタ構成ウィザードを使用して送信メッセージの有効期限を指定できます。メッセージの有効期限後は、キュー・マネージャによりメッセージが破棄されます。
メッセージに有効期限通知が設定されている場合は、メッセージが破棄されるときに通知が生成されます。この通知は、replyToQueue
パラメータで指定されたキューに送信されます。デフォルトでは、expiryフィールドにNEVER
が設定されます。
図10-8 のように、アダプタ構成ウィザードを介して送信メッセージの優先度を指定できます。優先度の範囲は0(最低)から9(最高)までです。また、メッセージの優先度を、宛先キューで定義されているデフォルトの優先度属性から取得するように指定することも可能です。デフォルトでは、メッセージ優先度としてAS_Q_DEF
が設定されます。
図10-8 のように、アダプタ構成ウィザードを介して送信メッセージの永続性を指定できます。メッセージの永続性が設定されていない場合は、キュー・マネージャの再起動時またはシステム障害の発生時にメッセージが消失します。メッセージの永続性をtrue
に設定すると、システム障害が発生したりキュー・マネージャが再起動してもメッセージは消失しません。メッセージの永続性を、宛先キューで定義されているデフォルトの優先度属性から取得するように指定することも可能です。永続メッセージは、アダプタによってログ・ファイルとキュー・データ・ファイルに書き込まれます。障害後にキュー・マネージャが再起動すると、これらの永続メッセージが各ファイルからリカバリされます。
注意:
前述のメッセージ・プロパティはすべて、実行時にメッセージ・ヘッダーを介して指定できます。これらのプロパティにはassignアクティビティを使用して値を割り当てることができます。
リクエスト-リプライ相互作用でリクエストにレスポンスをマッピングするには、相関付けが必要です。各リクエスト・メッセージには、メッセージIDと相関IDが含まれています。アプリケーションは、Oracle BPEL PMからリクエスト・メッセージを受信すると、レスポンス・メッセージに対して定義されている相関スキーマをチェックします。アプリケーションでは、相関スキーマに基づいてレスポンス・メッセージのメッセージIDと相関IDが生成されます。
図10-15 に示すアダプタ構成ウィザードの「レスポンス」ページでは、レスポンス・メッセージの相関スキーマを指定できます。
図10-15 に示す「メッセージID」ボックスには、レスポンス・メッセージのメッセージIDについて次のオプションが用意されています。
レスポンス・メッセージの新規メッセージIDの生成
リクエスト・メッセージのメッセージIDを使用
同様に、図10-15 に示す「相関ID」ボックスには、レスポンス・メッセージの相関IDについて次のオプションが用意されています。
リクエスト・メッセージのメッセージIDを使用
リクエスト・メッセージの相関IDを使用
メッセージを複数のキューにエンキューできます。
「操作タイプ」ページで「MQにメッセージを蓄積」オプションを選択した場合に、複数のキューがあると、自動的にJCAファイルにDistributionList
パラメータが追加されます。
送信メッセージに各種の確認メッセージを設定できます。これらの確認メッセージはレポート・メッセージと呼ばれます。レポート・メッセージが生成されるのは、その生成基準が満たされる場合のみです。メッセージをキューにエンキューするときに、複数タイプのレポート・メッセージをリクエストできます。レポート・メッセージをリクエストする場合は、レポート・メッセージの送信先となるキュー名を指定する必要があります。このキューはreplyTo
キューと呼ばれます。レポート・メッセージは、キュー・マネージャ、メッセージ・チャネルまたはアプリケーションで生成できます。
次のメッセージ・レポートをサポートしています。
着信時の確認
「着信時の確認」(COA)メッセージは、メッセージがターゲット・キュー・マネージャに送信されたことを示します。COAメッセージはキュー・マネージャにより生成されます。このメッセージ・レポートは、図10-14 に示したアダプタ構成ページの「レポート」ページで選択できます。
送信時の確認
「送信時の確認」(COD)メッセージは、メッセージが受信側アプリケーションにより受信されたことを示します。CODメッセージはキュー・マネージャにより生成されます。このメッセージ・レポートは、図10-14 に示した「レポート」ページで選択できます。
例外レポート
例外レポートが生成されるのは、メッセージを指定の宛先キューに送信できない場合です。例外レポートは、メッセージ・チャネルにより生成されます。このメッセージ・レポートは、図10-14 に示したアダプタ構成ページの「レポート」ページで選択できます。
有効期限レポート
有効期限レポートは、メッセージが取得される前に指定の有効期限が経過したために、メッセージが破棄されたことを示します。有効期限レポートは、キュー・マネージャにより生成されます。このメッセージ・レポートは、図10-14 に示したアダプタ構成ページの「レポート」ページで選択できます。
肯定アクション通知
肯定アクション通知(PAN)は、リクエストが正常に処理されたことを示します。つまり、メッセージでリクエストされたアクションが正常に実行されたことを意味します。このタイプのレポートは、アプリケーションにより生成されます。
否定アクション通知
否定アクション通知(NAN)は、リクエストが正常に処理されなかったことを示します。つまり、メッセージでリクエストされたアクションが正常に実行されなかったことを意味します。このタイプのレポートは、アプリケーションにより生成されます。
PANとNANを除き、前述のすべてのレポート・メッセージについて、オリジナル・メッセージの全体または一部を含めるか、まったく含めないかを指定できます。アダプタ構成ウィザードで次のいずれかのオプションを選択できます。
オリジナル・メッセージのデータなし
オリジナル・メッセージの最初の100バイトのデータ
オリジナル・メッセージ全体
メッセージ配信失敗オプションは、リモート・キューに対してのみサポートされ、通常のキューではサポートされません。メッセージを宛先キューに配信できなかった場合に実行するアクションを指定できます。次のいずれかを指定できます。
メッセージを配信不能キューに蓄積します
これはデフォルトのアクションです。宛先キューに配信できなかったメッセージは配信不能キューに蓄積されます。送信者からリクエストされた場合は、レポート・メッセージが生成されます。
メッセージの破棄
これは、宛先キューに配信できないメッセージを破棄する必要があることを示します。送信者からリクエストされた場合は、レポート・メッセージが生成されます。
アダプタ構成ウィザードで「MQにメッセージを蓄積」オプションを選択すると、これらのオプションを指定できます。
インバウンド相互作用とアウトバウンド相互作用の両方でメッセージのセグメンテーションがサポートされています。セグメンテーションが必要になるのは、メッセージ・サイズがキューの許容メッセージ・サイズよりも大きい場合です。物理メッセージは2つ以上の論理メッセージに分割されます。すべての論理メッセージには、同じグループIDと順序番号およびオフセットが付きます。
インバウンド相互作用の場合、セグメンテーションは本来サポートされています。すべての論理メッセージが順序番号順にデキューされてから、単一メッセージがXMLとしてOracle BPEL PMにパブリッシュされます。
「必要な場合、メッセージをセグメント化できます」オプションを使用すると、アウトバウンド相互作用についてメッセージをセグメント化できます。このオプションは、アダプタ構成ウィザードの「レスポンス」ページに表示されます。
メッセージは、サイズがキューに設定された上限を超えるかどうかに基づいてセグメント化されます。
配信リストを使用する場合、メッセージのセグメンテーションはサポートされません。この原因は、MQアダプタで使用されるIBM MQ Series製品のJava APIにおける制限です。
CICSサーバーからのメッセージの送受信をサポートします。インバウンド方向では、CICSサーバーからのインバウンド・メッセージは通常メッセージと同様にデキューされます。アウトバウンド方向では、メッセージにCICSフォーマットを使用する必要があります。次のXSD例に、アウトバウンドCICSメッセージ・フォーマットのサンプル・スキーマ・ファイルを示します。「Oracle MQ Seriesアダプタのエンコーディング」で、サポートされているOracle MQ Seriesアダプタのエンコーディングのリストも参照してください。
<?xml version="1.0" ?><schema xmlns="http://www.w3.org/2001/XMLSchema" targetNamespace="http://xmlns.oracle.com/pcbpel/nxsd/cics_mqcih" elementFormDefault="qualified" attributeFormDefault="unqualified" xmlns:nxsd="http://xmlns.oracle.com/pcbpel/nxsd" nxsd:version="NXSD" nxsd:encoding="UTF8" nxsd:stream="bytes" nxsd:byteOrder="bigEndian" xmlns:nxsd_extn="http://xmlns.oracle.com/pcbpel/nxsd/extensions" <element name="MSGForMQCICSBridge"> <complexType> <sequence> <element name="MQCIH"> <complexType> <sequence> <!-- MQCHAR4 StrucId; Structure identifier --> <element name="StrucId" type="string" nxsd:style="fixedLength" nxsd:length="4" nxsd:padStyle="tail"/> <!-- MQLONG Version; Structure version number 1 or 2 --> <element name="Version" type="string" nxsd:style="integer" nxsd_extn:octet="4" nxsd_extn:align="0" nxsd_extn:sign="unticked" /> <!-- MQLONG StrucLength; Length of MQCIH structure V1=164 V2=180 --> <element name="StrucLength" type="string" nxsd:style="integer" nxsd_extn:octet="4" nxsd_extn:align="0" nxsd_extn:sign="unticked" /> <!-- MQLONG Encoding; Reserved --> <element name="Encoding" type="string" nxsd:style="integer" nxsd_extn:octet="4" nxsd_extn:align="0" nxsd_extn:sign="unticked" /> <!-- MQLONG CodedCharSetId; Reserved --> <element name="CodedCharSetId" type="string" nxsd:style="integer" nxsd_extn:octet="4" nxsd_extn:align="0" nxsd_extn:sign="unticked" /> <!-- MQCHAR8 Format; MQ Format name --> <element name="Format" type="string" nxsd:style="fixedLength" nxsd:length="8" /> <!-- MQLONG Flags; Reserved --> <element name="Flags" type="string" nxsd:style="integer" nxsd_extn:octet="4" nxsd_extn:align="0" nxsd_extn:sign="unticked" /> <!-- MQLONG ReturnCode; Return code from bridge --> <element name="ReturnCode" type="string" nxsd:style="integer" nxsd_extn:octet="4" nxsd_extn:align="0" nxsd_extn:sign="unticked" /> <!-- MQLONG CompCode; MQ completion code or CICS EIBRESP --> <element name="CompCode" type="string" nxsd:style="integer" nxsd_extn:octet="4" nxsd_extn:align="0" nxsd_extn:sign="unticked" /> <!-- MQLONG Reason; MQ reason or feedback code, or CICS EIBRESP2 --> <element name="Reason" type="string" nxsd:style="integer" nxsd_extn:octet="4" nxsd_extn:align="0" nxsd_extn:sign="unticked" /> <!-- MQLONG UOWControl; Unit-of-work control --> <element name="UOWControl" type="string" nxsd:style="integer" nxsd_extn:octet="4" nxsd_extn:align="0" nxsd_extn:sign="unticked" /> <!-- MQLONG GetWaitInterval; Wait interval for MQGET call issued by bridge --> <element name="GetWaitInterval" type="string" nxsd:style="integer" nxsd_extn:octet="4" nxsd_extn:align="0" nxsd_extn:sign="ticked" /> <!-- MQLONG LinkType; Link type --> <element name="LinkType" type="string" nxsd:style="integer" nxsd_extn:octet="4" nxsd_extn:align="0" nxsd_extn:sign="unticked" /> <!-- MQLONG OutputDataLength; Output commarea data length --> <element name="OutputDataLength" type="string" nxsd:style="integer" nxsd_extn:octet="4" nxsd_extn:align="0" nxsd_extn:sign="ticked" /> <!-- MQLONG FacilityKeepTime; Bridge facility release time --> <element name="FacilityKeepTime" type="string" nxsd:style="integer" nxsd_extn:octet="4" nxsd_extn:align="0" nxsd_extn:sign="unticked" /> <!-- MQLONG ADSDescriptor; Send/receive ADS descriptor --> <element name="ADSDescriptor" type="string" nxsd:style="integer" nxsd_extn:octet="4" nxsd_extn:align="0" nxsd_extn:sign="unticked" /> <!-- MQLONG ConversationalTask; Whether task can be conversational --> <element name="ConversationalTask" type="string" nxsd:style="integer" nxsd_extn:octet="4" nxsd_extn:align="0" nxsd_extn:sign="unticked" /> <!-- MQLONG TaskEndStatus; Status at end of task --> <element name="TaskEndStatus" type="string" nxsd:style="integer" nxsd_extn:octet="4" nxsd_extn:align="0" nxsd_extn:sign="unticked" /> <!-- MQBYTE Facility[8]; BVT token value. Initialise as required. --> <element name="Facility" type="string" nxsd:style="integer" nxsd_extn:octet="8" nxsd_extn:align="0" nxsd _extn:sign="unticked" /> <!-- MQCHAR4 Function; MQ call name or CICS EIBFN function name --> <element name="Function" type="string" nxsd:style="fixedLength" nxsd:length="4" /> <!-- MQCHAR4 AbendCode; Abend code --> <element name="AbendCode" type="string" nxsd:style="fixedLength" nxsd:length="4" /> <!-- MQCHAR8 Authenticator; Password or passticket --> <element name="Authenticator" type="string" nxsd:style="fixedLength" nxsd:length="8" /> <!-- MQCHAR8 Reserved1; Reserved --> <element name="Reserved1" type="string" nxsd:style="fixedLength" nxsd:length="8" /> <!-- MQCHAR8 ReplyToFormat; MQ format name of reply message --> <element name="ReplyToFormat" type="string" nxsd:style="fixedLength" nxsd:length="8" /> <!-- MQCHAR4 RemoteSysId; Remote sysid to use --> <element name="RemoteSysId" type="string" nxsd:style="fixedLength" nxsd:length="4" /> <!-- MQCHAR4 RemoteTransId; Remote transid to attach --> <element name="RemoteTransId" type="string" nxsd:style="fixedLength" nxsd:length="4" /> <!-- MQCHAR4 TransactionId; Transaction to attach --> <element name="TransactionId" type="string" nxsd:style="fixedLength" nxsd:length="4" /> <!-- MQCHAR4 FacilityLike; Terminal emulated attributes --> <element name="FacilityLike" type="string" nxsd:style="fixedLength" nxsd:length="4" /> <!-- MQCHAR4 AttentionId; AID key --> <element name="AttentionId" type="string" nxsd:style="fixedLength" nxsd:length="4" /> <!-- MQCHAR4 StartCode; Transaction start code --> <element name="StartCode" type="string" nxsd:style="fixedLength" nxsd:length="4" /> <!-- MQCHAR4 CancelCode; Abend transaction code --> <element name="CancelCode" type="string" nxsd:style="fixedLength" nxsd:length="4" /> <!-- MQCHAR4 NextTransactionId; Next transaction to attach --> <element name="NextTransactionId" type="string" nxsd:style="fixedLength" nxsd:length="4" /> <!-- MQCHAR8 Reserved2; Reserved --> <element name="Reserved2" type="string" nxsd:style="fixedLength" nxsd:length="8" /> <!-- MQCHAR8 Reserved3; Reserved --> <element name="Reserved3" type="string" nxsd:style="fixedLength" nxsd:length="8" /> <!-- MQLONG CursorPosition; Cursor position --> <element name="CursorPosition" type="string" nxsd:style="integer" nxsd_extn:octet="4" nxsd_extn:align="0" nxsd_extn:sign="unticked" /> <!-- MQLONG ErrorOffset; Error offset --> <element name="ErrorOffset" type="string" nxsd:style="integer" nxsd_extn:octet="4" nxsd_extn:align="0" nxsd_extn:sign="unticked" /> <!-- MQLONG InputItem; Input item --> <element name="InputItem" type="string" nxsd:style="integer" nxsd_extn:octet="4" nxsd_extn:align="0" nxsd_extn:sign="unticked" /> <!-- MQLONG Reserved4; Reserved --> <element name="Reserved4" type="string" nxsd:style="integer" nxsd_extn:octet="4" nxsd_extn:align="0" nxsd_extn:sign="unticked" /> </sequence> </complexType> </element> <!-- Application data --> <element name="ApplicationData" type="string" fixed="Nothing" /> </sequence> </complexType> </element> </schema>
このCCDTを使用すると、MQ SeriesアダプタにJNDIを構成している間にプロパティを定義する際に複数の利点があります。
クライアント・チャネル定義表の機能を理解しておくと役に立ちます。
クライアント・チャネル定義表の構成を理解するには、次の基本用語と基本概念を理解しておく必要があります。
チャネル名および接続名: 表内の各定義のチャネル名は、指定された接続名で実行されるリスナーを持つキュー・マネージャのサーバー接続チャネルとまったく同一にする必要があります。たとえば、CCDT内の第1の定義であるchannel.ccdt_qm1
は、localhost(1414)で実行されるリスナーを持つキュー・マネージャのサーバー接続チャネル名になっています。
キュー・マネージャ名: CCDTで定義済のキュー・マネージャ名は、定義されたチャネル名および接続名を持つキュー・マネージャの実際の名前と異なる可能性があります。次の可能性が考えられます。
クライアント・チャネルで定義されているキュー・マネージャ名は、表の第3の定義にあるように実際のキュー・マネージャ名となっています。したがって、ccdt_qm3
は、サーバー接続チャネルとしてchannel.ccdt_qm3
を所有し、さらにlocalhost(3414)でリスニングするリスナーを所有するキュー・マネージャの実際の名前となります。
クライアント・チャネル定義にキュー・マネージャ名が定義されていません。図10-31 では、定義されたキュー・マネージャ名を持たない表内の第4の定義においてこの状況を確認できます。
CCDT内の2つ以上のクライアント・チャネル・エントリに、定義された同一のキュー・マネージャ名が存在します。この名前は、どのエントリの実際のキュー・マネージャ名とも一致できます。図10-31 の第1と第2の定義には、QM
として定義された同じキュー・マネージャ名がありますが、実際は異なるキュー・マネージャをポイントしています。
図10-31 は、ccdt_qm1
からccdt_qm4
までの4つのキュー・マネージャに対する接続に定義されたクライアント・チャネルを持つ標準のCCDTを示しています。
図10-31 CCDTの例
一度定義されると、このCCDTはデフォルトで次の場所に存在します。
Windowsの場合、<C:\Program Files\IBM\ MQ\qmgrs\QM_NAME\@ipcc\AMQCLCHL.TAB>
Unixベースのシステムの場合、<var/mqm/qmgrs/QM_NAME/@ipcc/AMQCLCHL.TAB>
この機能により、MQ SeriesアダプタへのJNDIの構成中にConnectionFactoryプロパティのHostname、PortNumber、ChannelNameおよびQueueManagerNameの定義を要する、以前のタスクが単純化されます。
クライアント・チャネル定義表(CCDT)は、構成の一部としてCCDTファイルの他、QueueManagerNameをポイントするURLでのみ使用できます。MQ Seriesアダプタは、CCDTから残りの接続の詳細を読み取り、MQ Seriesアダプタに必要な接続を作成できます。
MQ Seriesアダプタは、キュー・マネージャのリスト(いくつかは停止中の場合もある)で使用可能なキュー・マネージャに動的に接続するよう構成できます。
コンポジット・プロセスでMQアダプタに使用するJNDIを変更する必要はなく、MQアダプタによる接続を要求されていたキュー・マネージャを変更するためにコンポジットを再デプロイする必要もありません。
キュー・マネージャに必要なConnectionFactory JNDIエントリは1つのみで、MQアダプタは、使用可能な最初のキュー・マネージャに動的に接続されます。
CCDTを使用して、クライアント・チャネル定義で同じキュー・マネージャ名のプロパティを持つキュー・マネージャのリストを定義できます。このリストは、いかなる構成の変更や再デプロイも要求されることなく、MQ Seriesアダプタが実行時に使用可能な最初のキュー・マネージャへの動的な接続をするために使用されます。
IBM MQおよびMQアダプタの使用方法の基本理解とCCDTの作成の詳細は、IBM MQ Seriesドキュメントを参照してください。
IBM MQバージョン6は、CCDT機能が動作するための最低要件となっています。
MQアダプタは、MQメッセージとしての大きなペイロードの読取りおよび書込みをサポートするようになりました。大きなペイロード用にインバウンドおよびアウトバウンドMQ Seriesアダプタを構成する方法については、次の項を参照してください。
インバウンド処理の場合、MQ Seriesアダプタ構成ウィザードを使用したインバウンド・アダプタの構成中に「大きいメッセージの使用のサポート」チェック・ボックスを選択して、大きなペイロード用のインバウンドMQアダプタを構成できます。次のスクリーンショットにこれを示します。
アウトバウンドでは、大きなペイロード・サポート用に必要な構成はありません。ただし、次の2つのオプションの構成が、アウトバウンド処理で重要となります。
1. SegmentIfRequired
プロパティ: デフォルトではこのプロパティはTRUEに設定されていますが、アウトバウンドMQアダプタの構成中に「必要な場合、メッセージをセグメント化できます」チェック・ボックスを使用して構成することもできます。MQアダプタが大きなメッセージを小さなセグメントに分割できるようにする場合は、このブール・プロパティをtrueに設定する必要があります。このプロパティがfalseに設定され、メッセージのサイズがキュー、チャネルまたはキュー・マネージャで許可されている最大メッセージ・サイズを超えている場合、MQサーバーは、キューにそのメッセージを格納することを許可せず、MQアダプタは例外をスローします。
2. MaximumSegmentLength
: デフォルトでは「最大許容」
に設定されており、ウィザードを使用したアウトバウンドMQアダプタの構成中に「最大セグメント長」
ラジオ・ボタンを使用して、このプロパティを構成できます。「カスタム」
ラジオ・ボタンを選択して、ユーザー定義のメッセージ・セグメント長を構成でき、アダプタはそのサイズにメッセージをセグメント化します。「最大許容」
ラジオ・ボタンが選択されている場合、MQアダプタは、アウトバウンド・キュー、チャネルおよびキュー・マネージャが許可している最大セグメント・サイズにメッセージをセグメント化します。
指定されたカスタム・セグメント値がMQサーバーで許可されている値より大きい場合は、サーバーで指定されている値が適用されます。
次の図は、2つの構成を示しています。
MQアダプタは、添付としてメッセージを処理することをサポートしています。インバウンド・メッセージを添付として処理する場合、MQアダプタは、ペイロードの変換を無視し、メッセージを次のコンポーネントに直接転送します。同様に、アウトバウンドでは、添付として書き込む場合、MQアダプタはペイロードの変換を無視し、キューにメッセージを不透明に書き込みます。この機能は、あるキューから別のキューに大きなメッセージを不透明に転送する場合に役立ちます。
構成ウィザードを使用したインバウンド・アダプタの構成中に、「メッセージを添付ファイルとして読取り」チェック・ボックスを選択して、メッセージを添付ファイルとして処理するようにMQアダプタを構成できます。詳細は、第10.6.9項の使用例を参照してください。
使用するための前提条件は次のとおりです。
IBM MQサーバーがインストール済で稼働している必要があります。
キュー・マネージャとサーバー接続チャネルを作成する必要があります。
注意:
キューはアプリケーションの要件に基づいて作成する必要があります。
構成するには、次の手順を実行します。
この項で説明する手順は、使用前に1度実行します。
クラスパスに正しいjarプロパティを追加するには、次のjarを<DOMAIN_HOME>/libフォルダにコピーします
com.ibm.mq.jar
クラスパスに正しいjarプロパティを追加するには、次のjarを<DOMAIN_HOME>/libフォルダにコピーします
com.ibm.mq.commonservices.jar
com.ibm.mq.jar
com.ibm.mq.pcf.jar
com.ibm.mq.headers.jar
com.ibm.mq.jmqi.jar
com.ibm.mqetclient.jar
(XAによる方法の場合。7.5より前のバージョンでは、XAトランザクション・シナリオでこのcom.ibm.mqetclient.jar
が含まれる必要があります。jarは、IBM MQ Seriesの標準インストールでは提供されません。このJARを入手するには、IBMから追加のライセンスを取得する必要があります。)
また、使用している場合は、サーバー接続チャネルの新しい会話の共有プロパティをゼロに設定する必要があります。
7.5バージョンのIBM MQ Seriesの場合、次のjarが必要となります。
com.ibm.mq.jar
com.ibm.mq.jmqi.jar
com.ibm.mqjms.jar
dhbcore.jar
com.ibm.mqetclient.jar
は、MQ Series 7.5サーバーでは必要ありません。XAトランザクションの実行は、MQ Series 7.5を使用している場合、そのjarが存在しなくても機能します。
Oracle WebLogic Server管理コンソールでプロパティをいくつか変更して、接続のバインディング・モードを有効化できます。
バインディング・モードを有効化する手順は、次のとおりです。
接続用のバインディング・モードが有効化されました。
2つ以上のBPELプロセスが同じキューからメッセージを受信すると、それらのメッセージが正しいBPELプロセスに配信される確証はなく、そのキューでリスニングするあらゆるBPELプロセスに関連付けられる可能性があります。
ただし、1つのプロセスのみが特定のキューからのメッセージをリスニングするようにプロセスを設定できます。
これを行うために、メッセージ選択条件を満たすメッセージのみをデキューし、条件を満たさないメッセージは破棄するようにMQアダプタを構成できます。
その後、これらのメッセージは、メッセージがその選択条件を満たせば、同じキューからメッセージをリスニングする他のBPELプロセスで受信できます。
メッセージ・セレクタに関連付けられた構文とルールを調べる前に、MQアダプタ構成ウィザードのコンテキストでメッセージ・セレクタを確認すると役立ちます。
同じキューからメッセージを受信するすべてのBPELプロセスのメッセージ・セレクタは、相互に排他的である必要があります。
メッセージ・セレクタ機能が、MQアダプタ・ウィザードの「MQからメッセージを取得」画面に表示されます。メッセージ・セレクタを指定すると、activation-specで指定したセレクタの情報がウィザードによって入れられます。図10-42 に示すように、「メッセージ・セレクタ」フィールドは「キュー名」フィールドの直下にあります。
図10-42 MQアダプタ構成ウィザードの「MQからメッセージを取得」画面上の「メッセージ・セレクタ」フィールド
メッセージ・セレクタを使用すると、セレクタがどのメッセージをMQキューからのデキュー対象とするかを指定できます。ヘッダーとプロパティがセレクタに一致するメッセージのみがデキューされます。
メッセージのヘッダー・フィールドおよびプロパティ値がセレクタの対応する識別子に代入された場合にセレクタがtrueと評価すると、メッセージはセレクタに一致します。
メッセージ・セレクタは、MQ構成ウィザード・アダプタを使用してインバウンドMQアダプタを構成するときに、アクティブ化仕様プロパティとして定義されます。サンプルのメッセージ・セレクタは次のとおりです。
例 - インバウンドMQアダプタのサンプル・メッセージ・セレクタ
<property name="MessageSelector" value="((jca.mq.MQMD.Priority BETWEEN 0 AND 3) AND NOT(jca.mq.MQMD.Priority = 1)) AND jca.mq.MQMD.PutApplName LIKE 'WebSph_re MQ%' AND jca.mq.MQMD.MsgType NOT IN (0, 1) AND (jca.mq.MQMD.ReplyToQ = 'test_q2' OR jca.mq.MQMD.ReplyToQ IS NULL) AND name = 'Joe'"/>
MessageSelectorが定義されていない場合、MQアダプタはメッセージの選択を行わず、キューに到達したすべてのメッセージをデキューします。
この項では、MessageSelector構文について詳細に説明します。メッセージ・セレクタを作成するオプションを提供するMQメッセージ取得画面のセレクタ・ボックスにセレクタ情報を入力するために、この構文を理解する必要があります。
メッセージ・セレクタの評価は、優先順位レベル内で左から右の順に行われます。カッコを使用して、この順序を変更できます。
セレクタには次のリテラルを含めることができます。
文字列: 文字列リテラルは一重引用符で囲む必要があります。Java文字列リテラルと同様、Unicode文字エンコーディングを使用します。
正確な数値: 正確な数値リテラルは、小数点を含まない数値です。Java longの範囲内の数値がサポートされます。
近似の数値: 近似の数値リテラルは、小数点を含む数値です。Java doubleの範囲内のすべての数値がサポートされます。
ブール: TrueまたはFalse。
識別子を使用して、メッセージ・セレクタでメッセージ・ヘッダーおよびプロパティ値を識別します。メッセージ・ヘッダー・プロパティは、MQMDプロパティ、ユーザー定義プロパティ、およびRFH2ヘッダーのUSRフォルダで定義されているプロパティです。他のRFH2フォルダで定義されているプロパティは、メッセージ・セレクタではサポートされていません。識別子に関して次のことに注意してください
大文字と小文字は区別されます
AND、OR、NOT、TRUE、FALSE、IN、LIKE、BETWEEN、IS、NULL、ESCAPEまたはdivは使用できません。
ネーミング規則があります。「jca.mq.MQMD.」で始まらない識別子名はすべて、RFH2ヘッダーのUSRフォルダ・プロパティ識別子であるとみなされます。
次のものが識別子を構成します。
MQMDヘッダー・フィールド。表10-5を参照してください。
RFH2 USRフォルダ。MQメッセージのRFH2ヘッダーのUSRフォルダで定義されているプロパティ名はすべて、識別子として使用できます。プロパティ名は、Java識別子開始文字で始まり、後に続く文字がJava識別子部分文字(「.」、「_」および「$」を含めることができます)である必要がある、長さが無制限の文字列とすることができます。
メッセージ・セレクタ内でのその他のRFH2フォルダ・プロパティの使用はサポートされていません。表10-5 に、MQMDヘッダーおよびメッセージ・セレクタ識別子を示します。
表10-5 MQMDヘッダーおよびメッセージ・セレクタ識別子
MQMDヘッダー・フィールド | 識別子 |
---|---|
アカウンティング・トークン |
jca.mq.MQMD.AccountingToken |
アプリケーションIDデータ |
jca.mq.MQMD.ApplIdentityData |
アプリケーション送信元データ |
jca.mq.MQMD.ApplOriginData |
バックアウト・カウント |
jca.mq.MQMD.BackoutCount |
コード化キャラクタ・セットID |
jca.mq.MQMD.CodedCharSetId |
相関ID |
jca.mq.MQMD.CorrelId |
エンコーディング |
jca.mq.MQMD.Encoding |
有効期限 |
jca.mq.MQMD.Expiry |
フィードバック |
jca.mq.MQMD.Feedback |
書式 |
jca.mq.MQMD.Format |
グループID |
jca.mq.MQMD.GroupId |
メッセージ・フラグ |
jca.mq.MQMD.MsgFlags |
メッセージID |
jca.mq.MQMD.MsgId |
メッセージ・シーケンス番号 |
jca.mq.MQMD.MsgSeqNumber |
メッセージ・タイプ |
jca.mq.MQMD.MsgType |
オフセット |
jca.mq.MQMD.Offset |
元の長さ |
jca.mq.MQMD.OriginalLength |
永続性 |
jca.mq.MQMD.Persistence |
優先度 |
jca.mq.MQMD.Priority |
蓄積アプリケーション名 |
jca.mq.MQMD.PutApplName |
蓄積アプリケーション・タイプ |
jca.mq.MQMD.PutApplType |
蓄積日時 |
jca.mq.MQMD.PutDateTime |
返信先キュー・マネージャ名 |
jca.mq.MQMD.ReplyToQMgr |
返信先キュー名 |
jca.mq.MQMD.ReplyToQ |
レポート |
jca.mq.MQMD.Report |
ユーザー識別子 |
jca.mq.MQMD.UserIdentifier |
メッセージ・セレクタ内の式は、次のタイプになります。
算術: 式自体、算術演算子および数値リテラルで構成されます。
条件付き: 式自体、比較演算子、論理演算子およびブール・リテラルで構成されます。
メッセージ・セレクタの演算子には、次の2つのタイプがあります。
カッコで囲む: 標準のカッコ()を使用して式評価を順序付けします。
論理: 優先順の論理演算子は、NOT、AND、ORです。
メッセージ・セレクタの比較演算子には、=、>、>=、<、<=、<> (等しくない)が含まれます。
次の点に注意してください。
likeタイプの値のみを比較対象とすることができます。1つの例外として、正確な数値と近似の数値の比較は有効です。
文字列とブールの比較は、=および<>に制限されています。2つの文字列は、同じ文字のシーケンスが含まれる場合にのみ等しくなります。
メッセージ・セレクタの高度な演算子のリストを参照してください。
表10-6 メッセージ・セレクタの高度な演算子
演算子 | 構文と例 |
---|---|
|
構文:
|
|
構文:
|
|
構文: pattern-valueは文字列リテラルで、「_」は任意の単一文字を表し、「%」は文字の任意のシーケンス(空のシーケンスを含む)を表し、その他のすべての文字はその文字自体を表します。
|
|
構文:
|
追加のセレクタを含むメッセージ・セレクタの例は、次のとおりです。その後、このセレクタをサンプル・メッセージに対して適用した結果を確認できます。
例 - 追加のセレクタを含むメッセージ・セレクタの例
<property name="MessageSelector" value="((jca.mq.MQMD.Priority BETWEEN 0 AND 3) AND NOT(jca.mq.MQMD.Priority = 1)) AND jca.mq.MQMD.PutApplName LIKE 'WebSph_re MQ%' AND jca.mq.MQMD.MsgType NOT IN (0, 1) AND (jca.mq.MQMD.ReplyToQ = 'test_q2' OR jca.mq.MQMD.ReplyToQ IS NULL) AND name = 'Joe'"/>
サンプル・メッセージをリストし、このセレクタに一致するメッセージおよび一致しないメッセージを示す、表10-7 を参照してください。
表10-7 メッセージ・セレクタ例のサンプル・メッセージ
メッセージ・プロパティ | メッセージ1 | メッセージ2 | メッセージ3 | メッセージ4 |
---|---|---|---|---|
優先度 |
2 |
2 |
3 |
1 |
蓄積アプリケーション名 |
WebSphere MQ7 |
WebSphere MQ6 |
WebSphere MQ6 |
WebSphere MQ |
メッセージ・タイプ |
8 |
8 |
2 |
4 |
返信先キュー名 |
test_q2 |
test_q2 |
||
USR RFH2フォルダ |
名前 = Ankur 年齢 = 24 電話番号 = 123456 |
名前 = Bob 年齢 = 42 電話番号 = 654321 |
名前 = Ankur 従業員ID = 3321 |
色 = Red テーマ = old |
MessageSelectorは成功したか |
True |
False |
False |
False |
コメント |
USRフォルダ内の名前プロパティがセレクタに一致しません。 |
蓄積アプリケーション名プロパティが一致しません。 |
USRフォルダ内の優先度と名前プロパティが一致しません。 |
この例では、MQ Seriesアダプタを使用してMQ Seriesキューからメッセージを選択的にデキューする方法を示します。たとえば、次の条件をすべて満たすメッセージのみをデキューするとします。
414D51206C6F63616C5F716Dで始まるメッセージID
優先度 > 4
メッセージ・タイプが2以外
返信先キュー名がqueue12またはqueue49のいずれか
この条件セット用のメッセージ・セレクタ(各条件セットがメッセージ・セレクタ・テキストに一致する)の作成に役立つ分析については、表10-8 を参照してください。
表10-8 1つのBPELプロセス使用例のメッセージ・セレクタ表
条件 | メッセージ・セレクタ・テキスト |
---|---|
414D51206C6F63616C5F716Dで始まるメッセージID |
|
優先度 > 4 |
|
メッセージ・タイプが2以外 |
|
返信先キュー名はqueue12またはqueueu49 |
|
したがって、MQ Seriesアダプタ構成ウィザードに完全なメッセージ文字列を入力すると、メッセージを取得画面は次のようになります。
jca.mq.MQMD.MsgId LIKE '414D51206C6F63616C5F716D%' AND jca.mq.MQMD.Priority > AND NOT (jca.mq.MQMD.MsgType = 2) AND jca.mq.MQMD.ReplyToQ IN ('queue12', 'queue49')
このため、ウィザードにより作成されるInboundAdapter.jca
JCAファイルには、次のタグ内のメッセージ・セレクタを<activation-spec>タグの子として示すために、次が含まれます。
<property name="MessageSelector" value= " jca.mq.MQMD.MsgId LIKE '414D51206C6F63616C5F716D%' AND jca.mq.MQMD.Priority > 4 AND NOT (jca.mq.MQMD.MsgType = 2) AND jca.mq.MQMD.ReplyToQ IN ('queue12', 'queue49')"/>
メッセージ・セレクタを使用して構成されたMQアダプタは、定義されているメッセージ・セレクタに一致するメッセージのみをデキューします。いくつかの例では、デキューするメッセージとデキューしないメッセージを明確にすることができます。
表10-9 に、メッセージ番号とメッセージID別にサンプル・メッセージをリストします。
表10-9 1つのBPELプロセス使用例に使用されるサンプル・メッセージ
メッセージ番号 | メッセージID |
---|---|
メッセージ1 |
414D51206C6F63616C5F716D2020202023595B4D20002802 |
メッセージ2 |
414D51206C6F63616C5F716D2020202023595B4D20002D04 |
メッセージ3 |
414D51268A6C63618C5D516D2020202023595B4D20002A0D |
表10-10 に、サンプル・メッセージ・セットに対してメッセージ・セレクタを使用した結果をリストします。
表10-10 サンプル・メッセージに対してメッセージ・セレクタを使用した結果
メッセージ・プロパティ | メッセージ1 | メッセージ2 | メッセージ3 |
---|---|---|---|
優先度 |
6 |
6 |
9 |
メッセージ・タイプ |
8 |
2 |
8 |
返信先キュー名 |
queue12 |
queue49 |
queue12 |
メッセージがデキューされる |
はい |
いいえ |
いいえ |
コメント |
完全なメッセージ・セレクタはtrueを返すため、メッセージがデキューされます。 |
2つのBPELプロセス(BPEL 1およびBPEL 2)があり、両方とも同じMQキューからMQメッセージを受信するように構成されています。各BPELプロセスがそのプロセスのみに向けたメッセージを確実に受信するように、インバウンドMQアダプタをこれら両方のアダプタに構成する必要があります。
第1のプロセスであるBPEL 1では、次の条件を満たすメッセージのみを受信するようにします。
414D51206C6F63616C5F716D20202020で始まる相関ID
メッセージ・タイプは2
BPEL 2では、次の条件を満たすメッセージのみを受信するようにします。
414D5120514D5F616E6B7072616B615Fで始まる相関ID
メッセージ・タイプは2
優先度 > 5
第1のプロセスであるBPEL 1では、MessageSelector文字列は次のようになります。
jca.mq.MQMD.CorrelId LIKE '414D51206C6F63616C5F716D20202020%' AND jca.mq.MQMD.MsgType = 2
第2のプロセスであるBPEL 2では、MessageSelector文字列は次のようになります。
jca.mq.MQMD.CorrelId LIKE '414D5120514D5F616E6B7072616B615F%' AND jca.mq.MQMD.MsgType = 2 AND jca.mq.MQMD.Priority > 5
次の手順は、インバウンド・アダプタを構成することです。BPELプロセスの各インバウンドMQアダプタそれぞれにこれを行うには、「MQからメッセージを取得」画面で各アダプタのメッセージ・セレクタを指定します。
MQ Seriesアダプタ・ウィザードでは、「メッセージ・セレクタ」フィールドへの入力内容に基づいて次が実行されます。
BPEL 1では、ウィザードにより、<activation-spec>タグの子として次のタグが追加されます。
<property name="MessageSelector" value=" jca.mq.MQMD.CorrelId LIKE '414D51206C6F63616C5F716D20202020%' AND jca.mq.MQMD.MsgType = 2"/>
BPEL 2では、ウィザードにより、<activation-spec>タグの子として次のタグが追加されます。
<property name="MessageSelector" value=" jca.mq.MQMD.CorrelId LIKE '414D5120514D5F616E6B7072616B615F % ' AND jca.mq.MQMD.MsgType = 2 AND jca.mq.MQMD.Priority > 5"/>
両方のBPELプロセスが同じキューでメッセージを同時にリスニングするようにデプロイされている場合、メッセージは各プロセスにより選択的に受信されます。
両方のプロセスは、それぞれに向けられたメッセージのみを受信し、メッセージがBPELプロセスのいずれかの条件を満たさない場合、そのメッセージはキューに残ります。表10-11 に、使用されるサンプル・メッセージをリストし、表10-12 に、特定のサンプル・メッセージに関する結果をリストします。
表10-11 2つのBPELプロセス使用例に使用されるサンプル・メッセージ
メッセージ番号 | メッセージID |
---|---|
メッセージ1 |
414D51206C6F63616C5F716D2020202023595B4D20004B06 |
メッセージ2 |
414D5120514D5F616E6B7072616B615F1E4B5A4D20094202 |
メッセージ3 |
414D5120514D325F616E6B7072616B61FD4A5A4D2006BE04 |
表10-12 2つのBPELプロセス使用例のサンプル・メッセージに対してメッセージ・セレクタを使用した結果
メッセージ・プロパティ | メッセージ1 | メッセージ2 | メッセージ3 |
---|---|---|---|
優先度 |
1 |
5 |
8 |
メッセージ・タイプ |
2 |
2 |
2 |
メッセージの移動先 |
BPEL1 |
BPEL2 |
キューに残る |
コメント |
相関IDがいずれのBPELプロセスのpattern-valueとも一致しませんでした。 |
この項では、次の項目について説明します。
この使用例では、MQアダプタでメッセージをデキューし、MQ Seriesキューからトランスフォーメーション後の同じメッセージをエンキューするエンドツーエンドの方法について説明します。この項では、次の項目について説明します。
デキュー/エンキューの使用例を実行するには、Adapters-101MQAdapterDequeueEnqueue
サンプルに含まれているartifacts.zip
ファイルの次のファイルが必要です。
artifacts/schemas/address-csv.xsd
artifacts/schemas/address-fixedLength.xsd
artifacts/input/data.txt
Adapters-101MQAdapterDequeueEnqueue
サンプルを入手するには、Oracle SOA Sample Codeサイトにアクセスします。
次のキューも作成する必要があります。
test_in
test_out
SOAコンポジットを含んだJDeveloperアプリケーションを作成する必要があります。使用例のアプリケーションとプロジェクトを作成する手順は、次のとおりです。
作成した3つのコンポーネント(インバウンド・アダプタ・サービス、BPELプロセスおよびアウトバウンド・アダプタ参照)をアセンブルまたは接続する必要があります。コンポーネントを接続する手順は、次のとおりです。
前述の手順で作成したSOAプロジェクトおよびアプリケーションについて、アプリケーション・プロファイルをデプロイする必要があります。
JDeveloperを使用してアプリケーション・プロファイルをデプロイする方法の詳細は、「JDeveloperからのOracle JCAアダプタ・アプリケーションのデプロイ」を参照してください。
アプリケーション・サーバー接続も作成する必要があります。アプリケーション・サーバー接続の作成方法の詳細は、「Oracle JCAアダプタ用のアプリケーション・サーバー接続の作成」を参照してください。
Fusion Middleware Controlコンソールを使用して、デプロイ済のSOAコンポジットを監視できます。次の手順を実行します。
この使用例では、インバウンドのOracle MQ SeriesアダプタがMQ Seriesのインバウンド・キューtest_in
からリクエスト・メッセージをデキューして、BPELプロセスにパブリッシュします。Oracle MQ Seriesアダプタは、BPELプロセスからのレスポンスを待機します。レスポンスを受信すると、Oracle MQ Seriesアダプタはリクエスト・メッセージのreplyToQueueName
キューで指定されたMQ Seriesキューにレスポンス・メッセージをエンキューします。この使用例は、次の項で構成されています。
この例は、基本的なBPELコンストラクト(アクティビティやパートナ・リンクなど)と、BPELプロセスを作成およびデプロイするJDeveloper環境をよく理解していることを前提としています。
「Oracle MQ Seriesアダプタの構成」の指定に従ってOracle MQ Seriesアダプタを構成し、キューtest_in
を作成する必要があります。
インバウンド同期リクエスト-リプライの使用例を実行するには、Adapters-101MQAdapterDequeueEnqueue
サンプルに含まれているartifacts.zip
ファイルの次のファイルが必要です。
artifacts/schemas/address-csv.xsd
artifacts/schemas/address-fixedLength.xsd
artifacts/input/data.txt
Adapters-101MQAdapterDequeueEnqueue
サンプルを入手するには、Oracle SOA Sample Codeサイトにアクセスします。
次のキューも作成する必要があります。
test_in
test_reply
SOAコンポジットを含んだJDeveloperアプリケーションを作成する必要があります。使用例のアプリケーションとプロジェクトを作成する手順は、次のとおりです。
前述の手順で作成したSOAプロジェクトおよびアプリケーションについて、アプリケーション・プロファイルをデプロイする必要があります。
JDeveloperを使用してアプリケーション・プロファイルをデプロイするには、「JDeveloperからのOracle JCAアダプタ・アプリケーションのデプロイ」を参照してください。
アプリケーション・サーバー接続も作成する必要があります。アプリケーション・サーバー接続の作成方法の詳細は、「Oracle JCAアダプタ用のアプリケーション・サーバー接続の作成」を参照してください。
Fusion Middleware Controlコンソールを使用して、デプロイ済のSOAコンポジットを監視できます。次の手順を実行します。
data.txt
ファイルのコンテンツでMQメッセージを作成し、replyToQueueNameをtest_reply
に設定します。このメッセージをtest_in
キューに蓄積します。この使用例では、MQアダプタの同期-請求-リクエスト-リプライのエンドツーエンドのシナリオについて説明します。この使用例では、コンポジットによりインバウンド・キューからメッセージがデキューされます。次に、リプライ・メッセージがインバウンド・メッセージで指定されたreplyToQueueキューにエンキューされます。この項では、次の項目について説明します。
インバウンド同期リクエスト-リプライの使用例を実行するには、Adapters-101MQAdapterDequeueEnqueue
サンプルに含まれているartifacts.zip
ファイルの次のファイルが必要です。
artifacts/schemas/address-csv.xsd
artifacts/schemas/address-fixedLength.xsd
次の名前のキューも作成する必要があります。
test_in
test1
ReplyQ
test_reply
Adapters-101MQAdapterDequeueEnqueue
サンプルを入手するには、Oracle SOA Sample Codeサイトにアクセスします。
SOAコンポジットを含んだJDeveloperアプリケーションを作成する必要があります。使用例のアプリケーションとプロジェクトを作成する手順は、次のとおりです。
リクエスト・メッセージをエンキューし、対応するレスポンス・メッセージ(レポート)をキューからデキューするアダプタ・サービスを作成する手順は、次のとおりです。
作成した3つのコンポーネント(InboundReqRepService、BPELSyncreqrepおよびOutboundReqRepService)をアセンブルまたは接続する必要があります。コンポーネントを接続する手順は、次のとおりです。
前述の手順で作成したSOAプロジェクトおよびアプリケーションについて、アプリケーション・プロファイルをデプロイする必要があります。
JDeveloperを使用してアプリケーション・プロファイルをデプロイする方法の詳細は、「JDeveloperからのOracle JCAアダプタ・アプリケーションのデプロイ」を参照してください。
アプリケーション・サーバー接続も作成する必要があります。アプリケーション・サーバー接続の作成方法の詳細は、「Oracle JCAアダプタ用のアプリケーション・サーバー接続の作成」を参照してください。
Fusion Middleware Controlコンソールを使用して、デプロイ済のSOAコンポジットを監視できます。次の手順を実行します。
data.txt
ファイルのコンテンツでMQメッセージを作成し、replyToQueueNameをtest_reply
に設定します。このメッセージをtest_in
キューに蓄積します。この使用例では、非同期リクエスト-リプライのエンドツーエンドのシナリオについて説明します。この使用例では、最初にコンポジットによりインバウンド・キューからメッセージがデキューされます。次に、リクエスト・メッセージがエンキューされ、リプライ・メッセージがデキューされます。最後に、コンポジットによりリプライ・メッセージが他のキューにエンキューされます。この項では、次の項目について説明します。
「Oracle MQ Seriesアダプタの構成」の指定に従ってOracle MQ Seriesアダプタを構成し、キューtest_in、test_outおよびtest_demoを作成する必要があります。
SOAコンポジットを含んだJDeveloperアプリケーションを作成する必要があります。使用例のアプリケーションとプロジェクトを作成する手順は、次のとおりです。
リクエスト・メッセージをエンキューし、対応するレスポンス・メッセージ(レポート)をキューからデキューするアダプタ・サービスを作成する手順は、次のとおりです。
作成した4つのコンポーネント(インバウンド・アダプタ・サービス、BPELプロセス、async-Req-Resおよびアウトバウンド・アダプタ参照)をアセンブルまたは接続する必要があります。コンポーネントを接続する手順は、次のとおりです。
前述の手順で作成したSOAプロジェクトおよびアプリケーションについて、アプリケーション・プロファイルをデプロイする必要があります。
JDeveloperを使用してアプリケーション・プロファイルをデプロイする方法の詳細は、「JDeveloperからのOracle JCAアダプタ・アプリケーションのデプロイ」を参照してください。
アプリケーション・サーバー接続も作成する必要があります。アプリケーション・サーバー接続の作成方法の詳細は、「Oracle JCAアダプタ用のアプリケーション・サーバー接続の作成」を参照してください。
Fusion Middleware Controlコンソールを使用して、デプロイ済のSOAコンポジットを監視できます。次の手順を実行します。
この使用例では、MQアダプタでメッセージを1度に1つデキューするエンドツーエンドの方法について説明します。この項では、次の項目について説明します。
アウトバウンド・デキューの使用例を実行するには、Adapters-101MQAdapterDequeueEnqueue
サンプルの次のファイルが必要です。
De-queueEn-queue/De-queueEn-queueComposite/xsd/singleString.xsd
また、Adapters-101MQAdapterDequeueEnqueue
サンプルに含まれているartifacts.zip
ファイルの次のファイルも必要です。
artifacts/input/data.txt
Adapters-101MQAdapterDequeueEnqueue
サンプルを入手するには、Oracle SOA Sample Codeサイトにアクセスします。
test_out
という名前のキューも作成する必要があります。
SOAコンポジットを含んだJDeveloperアプリケーションを作成する必要があります。使用例のアプリケーションとプロジェクトを作成する手順は、次のとおりです。
作成した3つのコンポーネント(クライアント、BPELプロセスおよびアウトバウンド・アダプタ参照)をアセンブルまたは接続する必要があります。コンポーネントを接続する手順は、次のとおりです。
前述の手順で作成したSOAプロジェクトおよびアプリケーションについて、アプリケーション・プロファイルをデプロイする必要があります。
JDeveloperを使用してアプリケーション・プロファイルをデプロイする方法の詳細は、「JDeveloperからのOracle JCAアダプタ・アプリケーションのデプロイ」を参照してください。
アプリケーション・サーバー接続も作成する必要があります。アプリケーション・サーバー接続の作成方法の詳細は、「Oracle JCAアダプタ用のアプリケーション・サーバー接続の作成」を参照してください。
この使用例では、Oracle MQ Seriesアダプタに対してバックアウト・キューを構成する方法について説明します。Oracle MQ Seriesアダプタはメッセージをデキューし、MQ Seriesキューからのトランスフォーメーション後に同じメッセージをエンキューします。このプロセスでは、invokeアクティビティ中またはレスポンスの送信時に失敗が発生する可能性があります。拒否されたメッセージを、デフォルトの拒否されたメッセージ・フォルダではなく、バックアウト・キューに送信するようにバックアウト・キューを構成する必要があります。この項では、次の項目について説明します。
バックアウト・キューの構成の使用例を実行するには、アダプタJNDIがXA用に構成されている必要があります。また、singleString.xsd
ファイルが必要です。このファイルは、次のコードを使用して作成できます。
<schema attributeFormDefault="unqualified" elementFormDefault="qualified" targetNamespace="http://xmlns.oracle.com/singleString" xmlns="http://www.w3.org/2001/XMLSchema"> <element name="singleString"> <complexType> <sequence> <element name="input" type="string"/> </sequence> </complexType> </element> </schema>
SOAコンポジットを含んだJDeveloperアプリケーションを作成する必要があります。使用例のアプリケーションとプロジェクトを作成する手順は、次のとおりです。
作成した3つのコンポーネント(インバウンド・アダプタ・サービス、BPELプロセスおよびアウトバウンド・アダプタ参照)をアセンブルまたは接続する必要があります。コンポーネントを接続する手順は、次のとおりです。
前述の手順で作成したSOAプロジェクトおよびアプリケーションについて、アプリケーション・プロファイルをデプロイする必要があります。
JDeveloperを使用してアプリケーション・プロファイルをデプロイする方法の詳細は、「JDeveloperからのOracle JCAアダプタ・アプリケーションのデプロイ」を参照してください。
アプリケーション・サーバー接続も作成する必要があります。アプリケーション・サーバー接続の作成方法の詳細は、「Oracle JCAアダプタ用のアプリケーション・サーバー接続の作成」を参照してください。
MQ Seriesアダプタは、接続の詳細にCCDTを使用するように構成できます。このCCDTを使用すると、キュー・マネージャのリストで使用可能な最初のキュー・マネージャに接続できます。
たとえば、このユース・ケースでは、後述の表に示すように、基本プロパティを持つQM1、QM2およびQM3の3つのキュー・マネージャがあります。
MQアダプタは、実行時に3つのキュー・マネージャのいずれにも動的に接続可能で、どれが使用可能であるかによって決定されます(たとえば、QM1が停止中の場合、MQアダプタはQM2に自動接続され、さらにQM2も停止中の場合は、QM3に接続される必要があります)。
キュー・マネージャのプロパティの例を次の表に示します。
キュー・マネージャ名 | QM1 | QM2 | QM3 |
---|---|---|---|
Hostname |
localhost |
localhost |
10.177.255.25 |
PortName |
1414 |
2414 |
1414 |
サーバー接続チャネル名 |
channel.QM1 |
channel.QM2 |
channel.QM3 |
これを実現するには、CCDTを次のように構成する必要があります。
チャネル名 | キュー・マネージャ名 | 接続名 |
---|---|---|
channel.QM1 |
MyQM_group |
localhost(1414) |
channel.QM2 |
MyQM_group |
localhost(2414) |
channel.QM3 |
MyQM_group |
10.177.255.25(1414) |
CCDTを作成した後、このCCDTを使用するように単一のConnectionFactory JNDIを構成する必要があります。そのJNDIで、次のConnectionFactoryプロパティを構成する必要があります。
CCDTurl
QueueManagerName
CCDTurlは、クライアント接続の詳細を指定するために、MQ Seriesアダプタで使用されるCCDTファイルのURLをポイントする必要があります。たとえば、指定される値は次のいずれかにできます。
file:/scratch/username/ccdt/AMQCLCHL.TAB
ftp://userName:password@myServer/definitionPath/AMQCLCHL.TAB
この使用例では、QueueManagerNameプロパティの値をMyQM_group
に設定する必要があります。
この名前は、MyQM_group
というキュー・マネージャ名を含むCCDTでクライアント定義エントリを所有する使用可能な最初のキュー・マネージャに対してMQ Seriesアダプタの接続が必要なことを示しています。
QueueManagerNameプロパティは、CCDTで定義されたキュー・マネージャ名と一致し、実際のキュー・マネージャ名とは一致しません。通常、QueueManagerNameには、次に示す考慮事項に従って適切な値が指定されます。
QM_default
などの1つのキュー・マネージャ名のみを指定した場合は、指定された名前と正確に(大/小文字の区別も含めて)一致するキュー・マネージャ名を定義内に含むクライアント・チャネルにおいてCCDTがアルファベット順で検索されます。
QM_default
などの指定されたキュー・マネージャ名の始めにアスタリスクが付加されている場合は、アスタリスクの有無にかかわらずキュー・マネージャ名と一致するエントリに対してCCDTがチャネル名のアルファベット順で検索されます。2つ以上のクライアント・チャネル定義にQM_defaultと定義されたキュー・マネージャ名がある場合は、使用可能な最初のキュー・マネージャに接続されます。
CCDTにキュー・マネージャ名が指定されていない場合は、JNDI内のキュー・マネージャ名を"*"に指定する必要があります。
前述の2つのプロパティは、接続の詳細にCCDTを使用するようMQ Seriesアダプタに通知する場合にのみ必要な構成です。CCDTを使用しても、SSL、ExitsまたはXAのサポートなど、他のMQアダプタの機能に必要な構成には影響がありません。
Hostname、PortNumber、ChannelNameなどの他のConnectionFactoryプロパティを構成した上で、CCDTも構成する場合は、それらのプロパティよりもCCDTが優先されます。
これらのConnectionFactoryプロパティが設定され、いずれかのコンポジット・プロセスでこのJNDIが使用されると、MQアダプタは、QM1、QM2およびQM3のうち使用可能な最初のキュー・マネージャに接続されます。
単一または複数のRFH2ヘッダーを含むMQメッセージのデキューと読取りに加えて、複数のRFH2ヘッダーを持つメッセージをエンキューすることもできます。この機能には、次の機能が含まれます。
RFH2ヘッダーの固定部分でのプロパティの読取りおよび書込み
任意のRFH2ヘッダー内の任意の個別フォルダが複数回出現した場合の読取りおよび書込み
単一メッセージでRFH2ヘッダーが複数回出現した場合の読取りおよび書込み
RFH2ヘッダーにより、メッセージ・プロデューサは、ペイロードにより多くのヘッダー・プロパティを追加して他の追加情報を提供できるようになります。
ヘッダー・プロパティとしてこの情報を読み取り、書き込む機能をMQアダプタに提供することで、RFH2ヘッダー・プロパティに依存するメッセージ・ペイロードの特定の処理を実行できます。
次のユース・ケースでは、2つのタイプのシナリオ例を示します。
この例は、1つまたは複数のRFH2ヘッダーを含むMQメッセージを処理するためのMQアダプタの使用方法を示しています。
2つのRFH2ヘッダーを含むMQメッセージは、キューおよび同じペイロードを含む新しいメッセージからデキューされますが、更新済のRFH2ヘッダーは別のキューにエンキューされます。
このユース・ケースの例を作成する手順は次のとおりです。
SOAコンポジットを含んだJDeveloperアプリケーションを作成する必要があります。使用例のアプリケーションとプロジェクトを作成する手順は、次のとおりです。
次の手順を実行し、メッセージをデキューし、キューに蓄積するアダプタ・サービスを作成します。
InboundMQ
と入力して「次へ」をクリックします。「接続」ページが表示されます。queue1
と入力し、「他のスキーマを選択します」を選択して「次へ」をクリックします。「メッセージ」ページが表示されます。作成した3つのコンポーネント(インバウンド・アダプタ・サービス、BPELプロセスおよびアウトバウンド・アダプタ参照)をアセンブルまたは接続する必要があります。コンポーネントを接続する手順は、次のとおりです。
「公開されたサービス」領域にあるInboundMQ内の小さい三角形を、「コンポーネント」領域のDequeueEnqueueRFH2内に緑の三角形として表示されるドロップ・ゾーンにドラッグします。
「コンポーネント」領域にあるDequeuEnqueueRFH2内の小さい三角形を、「外部参照」領域のOutboundMQ内に緑の三角形として表示されるドロップ・ゾーンにドラッグします。
図10-90 に示すように、「composite.xml」ページが表示されます。
「ファイル」、「すべて保存」を順番にクリックします。
「DequeueEnqueueRFH2」をダブルクリックします。「DequeueEnqueueRFH2.bpel」ページが表示されます。
「コンポーネント」ウィンドウから、receive、assignおよびinvokeアクティビティを「コンポーネント」領域にこの順序でドラッグ・アンド・ドロップします。JDeveloperの「DequeueEnqueueRFH2.bpel」ページが表示されます。
図10-100 「DequeueEnqueueRFH2.bpel」ページ
receiveアクティビティをインバウンド・サービスにドラッグ・アンド・ドロップします。「Receive」ダイアログが表示されます。
「変数」フィールドの端に表示される「変数の自動作成」アイコンをクリックします。「変数の作成」ダイアログが表示されます。
デフォルトを受け入れて「OK」をクリックします。
「インスタンスの作成」ボックスをクリックし、「OK」をクリックします。
invokeアクティビティをアウトバウンド・サービスにドラッグ・アンド・ドロップします。「Invoke」ダイアログが表示されます。
「入力変数」フィールドの端に表示される「入力変数の自動作成」アイコンをクリックします。
デフォルトを受け入れて「OK」をクリックします。Invokeダイアログが表示されます。
「OK」をクリックします。
assignアクティビティをダブルクリックします。Assignダイアログが表示されます。
変数を選択して、「プラス」アイコンをクリックします。
Assignダイアログで「OK」をクリックします。JDeveloperの「DequeueEnqueueRFH2.bpel.html
」が表示されます。
RFH2のヘッダー部分を格納する一時変数を作成します。
「DequeueEnqueueRFH2.bpel
」ページの「ソース」タブを開きます。
<variables>タブの下に、次の新規変数を追加します。
<variable name="RFH2.StructId" type="xsd:string"/> <variable name="RFH2.Version" type="xsd:string"/> <variable name="RFH2.Encoding" type="xsd:string"/> <variable name="RFH2.CodedCharSetId" type="xsd:string"/> <variable name="RFH2.Format" type="xsd:string"/> <variable name="RFH2.Flags" type="xsd:string"/> <variable name="RFH2.NameValueCCSID" type="xsd:string"/> <variable name="RFH2.JMSFolder" type="xsd:string"/> <variable name="RFH2.MCDFolder" type="xsd:string"/> <variable name="RFH2.USRFolder" type="xsd:string"/> <variable name="RFH2.USRFolder_2" type="xsd:string"/> <variable name="RFH2.PSCFolder" type="xsd:string"/> <variable name="RFH2extrafolder" type="xsd:string"/> <variable name="RFH2_2.StructId" type="xsd:string"/> <variable name="RFH2_2.Version" type="xsd:string"/> <variable name="RFH2_2.Encoding" type="xsd:string"/> <variable name="RFH2_2.CodedCharSetId" type="xsd:string"/> <variable name="RFH2_2.Format" type="xsd:string"/> <variable name="RFH2_2.Flags" type="xsd:string"/> <variable name="RFH2_2.NameValueCCSID" type="xsd:string"/> <variable name="RFH2_2.JMSFolder" type="xsd:string"/> <variable name="RFH2_2.JMSFolder_2" type="xsd:string"/> <variable name="RFH2_2.MCDFolder" type="xsd:string"/> <variable name="RFH2_2.USRFolder" type="xsd:string"/> <variable name="RFH2_2.USRFolder_2" type="xsd:string"/> <variable name="RFH2_2.PSCFolder" type="xsd:string"/> <variable name="TotalRFH2" type="xsd:string"/>
receiveアクティビティは、作成した一時変数でRFH2ヘッダー・プロパティを受け入れるように構成します。
「DequeueEnqueueRFH2.bpel
」ページの「ソース」タブを開きます。
<receive>タグの下に、次のエントリを追加します。
<bpelx:property name="jca.mq.RFH2.StructId" variable="RFH2.StructId"/> <bpelx:property name="jca.mq.RFH2.Version" variable="RFH2.Version"/> <bpelx:property name="jca.mq.RFH2.Encoding" variable="RFH2.Encoding"/> <bpelx:property name="jca.mq.RFH2.CodedCharSetId" variable="RFH2.CodedCharSetId"/> <bpelx:property name="jca.mq.RFH2.Format" variable="RFH2.Format"/> <bpelx:property name="jca.mq.RFH2.Flags" variable="RFH2.Flags"/> <bpelx:property name="jca.mq.RFH2.NameValueCCSID" variable="RFH2.NameValueCCSID"/> <bpelx:property name="jca.mq.RFH2.JMSFolder" variable="RFH2.JMSFolder"/> <bpelx:property name="jca.mq.RFH2.MCDFolder" variable="RFH2.MCDFolder"/> <bpelx:property name="jca.mq.RFH2.USRFolder" variable="RFH2.USRFolder"/> <bpelx:property name="jca.mq.RFH2.USRFolder_2" variable="RFH2.USRFolder_2"/> <bpelx:property name="jca.mq.RFH2.PSCFolder" variable="RFH2.PSCFolder"/> <bpelx:property name="jca.mq.RFH2.mq_usr" variable="RFH2extrafolder"/> <bpelx:property name="jca.mq.RFH2_2.StructId" variable="RFH2_2.StructId"/> <bpelx:property name="jca.mq.RFH2_2.Version" variable="RFH2_2.Version"/> <bpelx:property name="jca.mq.RFH2_2.Encoding" variable="RFH2_2.Encoding"/> <bpelx:property name="jca.mq.RFH2_2.CodedCharSetId" variable="RFH2_2.CodedCharSetId"/> <bpelx:property name="jca.mq.RFH2_2.Format" variable="RFH2_2.Format"/> <bpelx:property name="jca.mq.RFH2_2.Flags" variable="RFH2_2.Flags"/> <bpelx:property name="jca.mq.RFH2_2.NameValueCCSID" variable= "RFH2_2.NameValueCCSID"/> <bpelx:property name="jca.mq.RFH2_2.JMSFolder" variable="RFH2_2.JMSFolder"/> <bpelx:property name="jca.mq.RFH2_2.JMSFolder_2" variable="RFH2_2.JMSFolder_2"/> <bpelx:property name="jca.mq.RFH2_2.MCDFolder" variable="RFH2_2.MCDFolder"/> <bpelx:property name="jca.mq.RFH2_2.USRFolder" variable="RFH2_2.USRFolder"/> <bpelx:property name="jca.mq.RFH2_2.PSCFolder" variable="RFH2_2.PSCFolder"/> <bpelx:property name="jca.mq.RFH2_2.USRFolder_2" variable="RFH2_2.USRFolder_2"/> <bpelx:property name="jca.mq.RFH2.Total.Headers" variable="TotalRFH2"/>
invokeアクティビティは、変更済のRFH2ヘッダー・プロパティをアウトバウンド・メッセージにプッシュするように構成します。
「DequeueEnqueueRFH2.bpel」ページの「ソース」タブを開きます。
<invoke>タグの下に、次のエントリを追加します。
<bpelx:inputProperty name="jca.mq.MQMD.Format" expression="'RF_HDR_2'"/> <bpelx:inputProperty name="jca.mq.RFH2.StructId" variable="RFH2.StructId"/> <bpelx:inputProperty name="jca.mq.RFH2.Version" variable="RFH2.Version"/> <bpelx:inputProperty name="jca.mq.RFH2.CodedCharSetId" variable="RFH2.CodedCharSetId"/> <bpelx:inputProperty name="jca.mq.RFH2.Encoding" variable="RFH2.Encoding"/> <bpelx:inputProperty name="jca.mq.RFH2.Flags" variable="RFH2.Flags"/> <bpelx:inputProperty name="jca.mq.RFH2.Format" expression="'MQHRF2 '"/> <bpelx:inputProperty name="jca.mq.RFH2.NameValueCCSID" variable="RFH2.NameValueCCSID"/> <bpelx:inputProperty name="jca.mq.RFH2.JMSFolder" variable="RFH2.JMSFolder"/> <bpelx:inputProperty name="jca.mq.RFH2.MCDFolder" variable="RFH2.MCDFolder"/> <bpelx:inputProperty name="jca.mq.RFH2.USRFolder" variable="RFH2.USRFolder"/> <bpelx:inputProperty name="jca.mq.RFH2.mq_usr" variable="RFH2extrafolder"/> <bpelx:inputProperty name="jca.mq.RFH2_2.StructId" expression="'RFH '"/> <bpelx:inputProperty name="jca.mq.RFH2_2.Version" expression="'2'"/> <bpelx:inputProperty name="jca.mq.RFH2_2.CodedCharSetId" expression="'819'"/> <bpelx:inputProperty name="jca.mq.RFH2_2.Encoding" expression="'273'"/> <bpelx:inputProperty name="jca.mq.RFH2_2.Flags" expression="'0'"/> <bpelx:inputProperty name="jca.mq.RFH2_2.Format" expression="'MQSTR '"/> <bpelx:inputProperty name="jca.mq.RFH2_2.NameValueCCSID" expression="'1208'"/> <bpelx:inputProperty name="jca.mq.RFH2_2.JMSFolder" expression="'<jms><Dst>MYTOPIC</Dst><Exp>2000</Exp><Pri>4</Pri><Cid>22344</Cid><Rto>REPLY.QUEUE</Rto><Gid>3334</Gid><Seq>2</Seq><Dlv>1</Dlv><xxx>UserSpace</xxx></jms>'"/> <bpelx:inputProperty name="jca.mq.RFH2_2.JMSFolder_2" variable="RFH2_2.JMSFolder_2"/> <bpelx:inputProperty name="jca.mq.RFH2_2.MCDFolder" expression="'<mcd><Msd>jms_object</Msd></mcd>'"/> <bpelx:inputProperty name="jca.mq.RFH2_2.USRFolder" variable="RFH2_2.USRFolder"/> <bpelx:inputProperty name="jca.mq.RFH2_2.USRFolder_2" variable="RFH2_2.USRFolder_2"/>
「ファイル」、「すべて保存」を順番にクリックします。
前述の手順で作成したSOAプロジェクトおよびアプリケーションについて、アプリケーション・プロファイルをデプロイする必要があります。
JDeveloperを使用してアプリケーション・プロファイルをデプロイする方法の詳細は、「JDeveloperからのOracle JCAアダプタ・アプリケーションのデプロイ」を参照してください。
アプリケーション・サーバー接続も作成する必要があります。アプリケーション・サーバー接続の作成方法の詳細は、「Oracle JCAアダプタ用のアプリケーション・サーバー接続の作成」を参照してください。
適切なRFH2ヘッダーを含むMQメッセージをインバウンド・キューに配置する必要があります。
この例は、インバウンド・メッセージから2つのRFH2ヘッダーを取得するように構成されています(これは、必要に応じてBPELプロセスを構成することで変更できます)。MQメッセージのテスト入力は次のように行います。
ペイロード: すべてのメッセージ(Opaqueを使用しているためすべての書式が受入れ可能です)。
RFH2ヘッダー1: 2つのUSRフォルダ、1つのJMSフォルダ、1つのPSCフォルダ、1つのMCDフォルダおよび1つのmq_usrフォルダを含む必要があります。
RFH2ヘッダー2: 2つのUSRフォルダ、2つのJMSフォルダ、1つのPSCフォルダおよび1つのMCDフォルダを含む必要があります。
サンプルをデプロイし、メッセージをインバウンド・キューに格納します。変更済のRFH2ヘッダーを含む新しいメッセージのアウトバウンド・キューをチェックします(BPELのinvokeアクティビティでの構成に応じて)。
この例は、アウトバウンド・デキュー・シナリオで1つまたは複数のRFH2ヘッダーを含むMQメッセージを取得するためのMQアダプタの使用方法を示しています。
このサンプルでは、2つのRFH2ヘッダーを含むMQメッセージがアウトバウンド・キュー・シナリオのキューからデキューされます。
このユース・ケースの例を作成する手順は次のとおりです。
SOAコンポジットを含んだJDeveloperアプリケーションを作成する必要があります。使用例のアプリケーションとプロジェクトを作成する手順は、次のとおりです。
作成した3つのコンポーネント(クライアント、BPELプロセスおよびOutboundDQアダプタ参照)をアセンブルまたは接続する必要があります。
コンポーネントを接続する手順は、次のとおりです。
「コンポーネント」領域にあるBPELプロセス内の小さい三角形を、「外部参照」領域のOutboundDequeueService内に緑の三角形として表示されるドロップ・ゾーンにドラッグします。
「OutboundDequeueRFH2」BPELプロセスをダブルクリックします。「OutboundDequeueRFH2.bpel」ページが表示されます。
JDeveloperのcomposite.xmlが図10-106 のように表示されます。
図10-104 JDeveloper - composite.xml
「ファイル」、「すべて保存」を順番にクリックします。
「OutboundDequeueRFH2.bpel」をダブルクリックします。「OutboundDequeueRFH2.bpel」ページが表示されます。
「コンポーネント」ウィンドウからreceiveInput
アクティビティとreplyOutput
アクティビティ間にある「コンポーネント」領域に、invokeおよびassignの各アクティビティをこの順序でドラッグ・アンド・ドロップします。
invokeアクティビティをOutboundDQアダプタ参照にドラッグ・アンド・ドロップします。「Invoke」ダイアログが表示されます。
「変数」フィールドの端に表示される「変数の自動作成」アイコンをクリックします。「変数の作成」ダイアログが表示されます。
デフォルトを受け入れて「OK」をクリックします。
出力変数にも同じ手順を繰り返して「OK」をクリックします。
assignアクティビティをダブルクリックします。Assignダイアログが表示されます。
変数を選択して、「プラス」アイコンをクリックします。
Assignダイアログで「OK」をクリックします。JDeveloperの「BPELOutboundDequeue.bpel
」ページが表示されます。
図10-106 JDeveloperの「BPELOutboundDequeue.bpel」ページ
RFH2のヘッダー部分を格納する一時変数を作成します。
「DequeueEnqueueRFH2.bpel」ページの「ソース」タブを開きます。
<variables>タブの下に、次の新規変数を追加します。
<variable name="RFH2.StructId" type="xsd:string"/> <variable name="RFH2.Version" type="xsd:string"/> <variable name="RFH2.Encoding" type="xsd:string"/> <variable name="RFH2.CodedCharSetId" type="xsd:string"/> <variable name="RFH2.Format" type="xsd:string"/> <variable name="RFH2.Flags" type="xsd:string"/> <variable name="RFH2.NameValueCCSID" type="xsd:string"/> <variable name="RFH2.JMSFolder" type="xsd:string"/> <variable name="RFH2.MCDFolder" type="xsd:string"/> <variable name="RFH2.USRFolder" type="xsd:string"/> <variable name="RFH2.USRFolder_2" type="xsd:string"/> <variable name="RFH2.PSCFolder" type="xsd:string"/> <variable name="RFH2extrafolder" type="xsd:string"/> <variable name="RFH2_2.StructId" type="xsd:string"/> <variable name="RFH2_2.Version" type="xsd:string"/> <variable name="RFH2_2.Encoding" type="xsd:string"/> <variable name="RFH2_2.CodedCharSetId" type="xsd:string"/> <variable name="RFH2_2.Format" type="xsd:string"/> <variable name="RFH2_2.Flags" type="xsd:string"/> <variable name="RFH2_2.NameValueCCSID" type="xsd:string"/> <variable name="RFH2_2.JMSFolder" type="xsd:string"/> <variable name="RFH2_2.JMSFolder_2" type="xsd:string"/> <variable name="RFH2_2.MCDFolder" type="xsd:string"/> <variable name="RFH2_2.USRFolder" type="xsd:string"/> <variable name="RFH2_2.USRFolder_2" type="xsd:string"/> <variable name="RFH2_2.PSCFolder" type="xsd:string"/> <variable name="TotalRFH2" type="xsd:string"/>
invokeアクティビティは、アウトバウンド・デキュー・メッセージからRFH2ヘッダー・プロパティを受け入れるように構成します。
「DequeueEnqueueRFH2.bpel」ページの「ソース」タブを開きます。
<invoke>タグの下に、次のエントリを追加します。
<bpelx:outputProperty name="jca.mq.RFH2.StructId" variable="RFH2.StructId"/> <bpelx:outputProperty name="jca.mq.RFH2.Version" variable="RFH2.Version"/> <bpelx:outputProperty name="jca.mq.RFH2.Encoding" variable="RFH2.Encoding"/> <bpelx:outputProperty name="jca.mq.RFH2.CodedCharSetId" variable="RFH2.CodedCharSetId"/> <bpelx:outputProperty name="jca.mq.RFH2.Format" variable="RFH2.Format"/> <bpelx:outputProperty name="jca.mq.RFH2.Flags" variable="RFH2.Flags"/> <bpelx:outputProperty name="jca.mq.RFH2.NameValueCCSID" variable="RFH2.NameValueCCSID"/> <bpelx:outputProperty name="jca.mq.RFH2.JMSFolder" variable="RFH2.JMSFolder"/> <bpelx:outputProperty name="jca.mq.RFH2.MCDFolder" variable="RFH2.MCDFolder"/> <bpelx:outputProperty name="jca.mq.RFH2.USRFolder" variable="RFH2.USRFolder"/> <bpelx:outputProperty name="jca.mq.RFH2.USRFolder_2" variable="RFH2.USRFolder_2"/> <bpelx:outputProperty name="jca.mq.RFH2.PSCFolder" variable="RFH2.PSCFolder"/> <bpelx:outputProperty name="jca.mq.RFH2.mq_usr" variable="RFH2extrafolder"/> <bpelx:outputProperty name="jca.mq.RFH2_2.StructId" variable="RFH2_2.StructId"/> <bpelx:outputProperty name="jca.mq.RFH2_2.Version" variable="RFH2_2.Version"/> <bpelx:outputProperty name="jca.mq.RFH2_2.Encoding" variable="RFH2_2.Encoding"/> <bpelx:outputProperty name="jca.mq.RFH2_2.CodedCharSetId" variable="RFH2_2.CodedCharSetId"/> <bpelx:outputProperty name="jca.mq.RFH2_2.Format" variable="RFH2_2.Format"/> <bpelx:outputProperty name="jca.mq.RFH2_2.Flags" variable="RFH2_2.Flags"/> <bpelx:outputProperty name="jca.mq.RFH2_2.NameValueCCSID" variable="RFH2_2.NameValueCCSID"/> <bpelx:outputProperty name="jca.mq.RFH2_2.JMSFolder" variable="RFH2_2.JMSFolder"/> <bpelx:outputProperty name="jca.mq.RFH2_2.JMSFolder_2" variable="RFH2_2.JMSFolder_2"/> <bpelx:outputProperty name="jca.mq.RFH2_2.MCDFolder" variable="RFH2_2.MCDFolder"/> <bpelx:outputProperty name="jca.mq.RFH2_2.USRFolder" variable="RFH2_2.USRFolder"/> <bpelx:outputProperty name="jca.mq.RFH2_2.PSCFolder" variable="RFH2_2.PSCFolder"/> <bpelx:outputProperty name="jca.mq.RFH2_2.USRFolder_2" variable="RFH2_2.USRFolder_2"/> <bpelx:outputProperty name="jca.mq.RFH2.Total.Headers" variable="TotalRFH2"/>
「ファイル」、「すべて保存」を順番にクリックします。
前述の手順で作成したSOAプロジェクトおよびアプリケーションについて、アプリケーション・プロファイルをデプロイする必要があります。
JDeveloperを使用してアプリケーション・プロファイルをデプロイする方法の詳細は、「JDeveloperからのOracle JCAアダプタ・アプリケーションのデプロイ」を参照してください。
アプリケーション・サーバー接続も作成する必要があります。アプリケーション・サーバー接続の作成方法の詳細は、「Oracle JCAアダプタ用のアプリケーション・サーバー接続の作成」を参照してください。
適切なRFH2ヘッダーを含むMQメッセージをアウトバウンド・デキュー・キューに格納する必要があります。この例は、メッセージから2つのRFH2ヘッダーを取得するように構成されています(これは、必要に応じてBPELプロセスを構成することで変更できます)。MQメッセージのテストは次のように行います。
ペイロード: すべてのメッセージ(Opaqueを使用しているためすべての書式が有効です)。
RFH2ヘッダー1: 2つのUSRフォルダ、1つのJMSフォルダ、1つのPSCフォルダ、1つのMCDフォルダおよび1つのmq_usrフォルダを含む必要があります。
RFH2ヘッダー2: 2つのUSRフォルダ、2つのJMSフォルダ、1つのPSCフォルダおよび1つのMCDフォルダを含む必要があります。
サンプルをデプロイし、メッセージをアウトバウンド・デキュー・キューに格納します。Fusion Middleware Controlコンソールを開き、テスト・ユーティリティを使用してサンプルを起動します。しばらく待機してからインスタンス監査証跡を調査します。
この項では、メッセージを添付ファイルとして処理するようにインバウンドおよびアウトバウンドMQアダプタを構成する方法について説明します。
SOAコンポジットを含んだJDeveloperアプリケーションを作成する必要があります。使用例のアプリケーションとプロジェクトを作成する手順は、次のとおりです。
「アプリケーション名」
フィールドにMQAsAttachmentと入力して「次へ」をクリックします。「プロジェクトの名前付け」画面が表示されます。MQAsAttachment
と入力し、「テンプレート」ボックスから「サービスを後で定義」を選択します。MQAsAttachment
アプリケーションとMQAsAttachment
プロジェクトが設計領域に表示されます。作成した3つのコンポーネント(インバウンド・アダプタ・サービス、BPELプロセスおよびアウトバウンド・アダプタ参照)をアセンブルまたは接続する必要があります。コンポーネントを接続する手順は、次のとおりです。
前述の手順で作成したSOAプロジェクトおよびアプリケーションについて、アプリケーション・プロファイルをデプロイする必要があります。JDeveloperを使用してアプリケーション・プロファイルをデプロイするには、次の手順を実行する必要があります。