この章では、外部サービスとしてOracle BPEL Process Manager(Oracle BPEL PM)およびOracle Mediator(メディエータ)とともに動作する、Oracle JCA Adapter for MQ Series(Oracle MQ Seriesアダプタ)の使用方法について説明します。この章では、JCA Adapter for MQ Seriesの概念、機能、構成および使用例について説明します。
この章には、次の項が含まれます。
メッセージ・キューイングは、非同期プログラム間通信のためのテクニックです。分散システム上の独立したアプリケーションの相互通信を可能にすることによりアプリケーションを統合できます。あるアプリケーションがキュー・マネージャ所有のキューにメッセージを送信し、別のアプリケーションがキューからメッセージを取り出します。各アプリケーションが異なる時期に実行されたり一時的に使用できなくなっても、アプリケーション間の通信は維持されます。
次のリストに、メッセージ・キューイングの基本的な概念を示します。
メッセージングは、2つのエンティティがメッセージを送受信することで通信できるようにするメカニズムです。メッセージングには、同期と非同期の2つのタイプがあります。同期メッセージングでは、メッセージの送信元がメッセージをメッセージ・キューに入れ、そのメッセージに対するリプライを待ってから自身の処理を再開します。非同期メッセージングでは、メッセージの送信元がリプライを待たずに自身の処理を続行します。
メッセージは、あるプログラムから別のプログラム宛に送信される構造化データです。
メッセージ・キューは、アプリケーションでメッセージが格納されるオブジェクトです。アプリケーションでは、メッセージをキューに蓄積し、キューからメッセージを取得できます。キューはキュー・マネージャにより管理されます。
キュー・マネージャは、Application Program Interface(API)を介してアプリケーションにメッセージ・サービスとキューイング・サービスを提供します。キューへのアクセスを提供するのみでなく、メッセージ・チャネルを介して他のキュー・マネージャにメッセージを転送します。
メッセージ・チャネルは、2つのキュー・マネージャ間の通信パスを提供します。キュー・マネージャが接続されます。メッセージ・チャネルによるメッセージの転送送信方向は一方向のみです。
転送キューは、リモート・キュー・マネージャ宛のメッセージを一時的に格納するために使用されます。
メッセージがきわめて大きい場合は、セグメントと呼ばれる複数の小型メッセージに分割できます。各セグメントにはグループIDとオフセットがあります。メッセージのすべてのセグメントは、同じグループIDを持ちます。メッセージの最終セグメントはフラグでマークされます。
メッセージ・グループは、同じグループIDを持つ一連の関連メッセージで構成されます。メッセージ・グループ内の各メッセージには、メッセージ順序番号が付いています。メッセージ・グループ内の最後のメッセージはフラグでマークされます。
クラスタは、論理的に関連付けられたキュー・マネージャのグループです。
図10-1に示すように、エンキューとはメッセージをキューに蓄積することで、デキューとはキューからメッセージを取得することです。
リクエスト/レスポンス相互作用では、プログラムは別のプログラムにリプライを求めるメッセージを送信します。リクエスト・メッセージには、リプライの送信先情報が含まれています。受信側プログラムは、リクエスト・メッセージへのレスポンスとしてリプライ・メッセージを送信します。図10-2にリクエスト/レスポンス相互作用を示します。
Oracle MQ Seriesアダプタでサポートされている相互作用のシナリオの詳細は、第10.4.1.2項「メッセージのデキュー」を参照してください。
Messaging and Queuing Series(MQ Series)は、IBM社が開発した製品および規格の集合です。MQ Seriesは、保証付きメッセージ配信、セキュリティおよび優先度ベースのメッセージングを提供するキューイング・インフラストラクチャとなります。
注意: Oracle MQ Seriesアダプタは、IBM WebSphere MQ V7.5で動作確認済です。 |
図10-3に、MQ SeriesアプリケーションとMQ Seriesサーバー間の通信プロセスを示します。MQ Seriesクライアントにより、アプリケーションからリモート・コンピュータ上のキュー・マネージャに接続できます。
MQ Seriesの各キューはキュー・マネージャに属しています。キュー・マネージャには一意の名前があり、Message Queue Interface(MQI)チャネルを介してアプリケーションにメッセージ・サービスとキューイング・サービスを提供します。また、キュー・マネージャは作成されたキューへのアクセスを提供し、メッセージ・チャネルを介してメッセージを他のキュー・マネージャに転送します。
MQ Seriesでは、データはメッセージ形式で送信されます。送信側アプリケーションではメッセージを作成し、APIコールを使用してキューに送信します。メッセージは、受信側アプリケーションの受信準備ができるまでキューに保持されます。受信側アプリケーションでは、APIコールを使用してキューからメッセージを取得します。
メッセージをリモート・キューに送信する場合は、リモート・キュー定義をローカルに定義する必要があります。リモート・キュー定義は、宛先キュー名と転送キュー名で構成されます。
図10-4に、MQ Seriesメッセージのメッセージ構造を示します。
MQ Seriesメッセージは、図10-4に示すパートで構成されます。
メッセージ・ヘッダーには、一意のメッセージID、メッセージ・タイプ、メッセージ優先度およびルーティング情報などが含まれています。各MQ Seriesメッセージには、メッセージ・ヘッダーが必要です。
オプション・ヘッダーは、特定のアプリケーション(CICSアプリケーションなど)との通信に必須です。
詳細は、第10.4.8項「CICSとの統合」を参照してください。
これには実際のデータが含まれます(索引付きファイルまたはフラット・ファイルからのレコードや、DB2の表からの行または列など)。
Oracle BPEL Process Managerとメディエータには、Oracle MQ Seriesアダプタが組み込まれています。Oracle MQ Seriesアダプタにより、アプリケーションはMQ Seriesキュー・マネージャに接続し、MQ Seriesメッセージをキューに蓄積したりキューから削除できます。
この項には、次の項目が含まれます。
Oracle MQ Seriesアダプタは、すべてのネイティブMQ Series機能を提供します。Oracle JCA Adapter for JMS(Oracle JMSアダプタ)をMQ Seriesプロバイダとともに構成することはできますが、提供されるのはMQ Seriesで提供されるJMS機能のみで、ネイティブMQ Series機能は提供されません。次のリストに、Oracle JMSアダプタを上回るOracle MQ Seriesアダプタのメリットを示します。
Oracle MQ Seriesアダプタは、肯定アクション通知(PAN)および否定アクション通知(NAN)をサポートしています。
Oracle MQ Seriesアダプタは、送信時の確認、着信時の確認、例外レポートおよび有効期限レポートなどのレポート・メッセージをサポートしています。
Oracle MQ Seriesアダプタは、不要なメッセージや破損したメッセージの配信不能キューへの送信をサポートしています。
Oracle MQ Seriesアダプタには、グループに属するメッセージのフィルタリングなど、高度なフィルタ・オプションが用意されています。
Oracle MQ Seriesアダプタは高速で、使用が容易です。
注意: Oracle MQ Seriesアダプタの動作が確認されたMQ Seriesのバージョンは、WindowsでもLinuxでも7.5です。 |
Oracle MQ Seriesアダプタは、自動的にOracle BPEL Process Managerと統合されます。Oracle JDeveloper(JDeveloper)でパートナ・リンクまたはMQアダプタ・サービスを作成する際に、アダプタ構成ウィザードが起動します。
このウィザードで、Oracle MQ Seriesアダプタまたは他のOracle JCAアダプタを選択して構成できます。アダプタ構成ウィザードでは、図10-5に示すように、サービス名の入力を求められます。
構成が完了すると、JDeveloperの「アプリケーション・ナビゲータ」セクションに同じ名前のWSDLファイルが作成されます。このWSDLファイルには、アダプタ構成ウィザードで指定する構成情報が含まれます。
アダプタ構成ウィザードの「操作」ページで、実行する操作の選択を求められます。選択内容に応じて、アダプタ構成ウィザードの別のページが表示され、構成情報の入力を求められます。
表10-1に実行可能な操作と、これらの操作に関する情報が記載されている項を示します。
表10-1 Oracle BPEL Process Managerについてサポートされている操作
Oracle MQ Seriesアダプタは、自動的にメディエータと統合されます。JDeveloperメディエータ・デザイナでMQアダプタ・サービスを作成すると、アダプタ構成ウィザードが起動します。
このウィザードで、Oracle MQ Seriesアダプタを選択して構成できます。構成が完了すると、JDeveloperの「アプリケーション・ナビゲータ」セクションに同じ名前のWSDLファイルが作成されます。このWSDLファイルには、アダプタ構成ウィザードで指定する構成情報が含まれます。
アダプタ構成ウィザードの「操作」ページで、実行する操作の選択を求められます。選択内容に応じて、アダプタ構成ウィザードの別のページが表示され、構成情報の入力を求められます。表10-2に実行可能な操作と、指定する必要がある構成情報が記載されている項を示します。
表10-2 Oracle Mediatorについてサポートされている操作
操作 | 参照先 |
---|---|
メッセージのエンキュー |
|
メッセージのデキュー |
|
リクエスト-レスポンス |
第10.4.1.6項「同期リクエスト-レスポンス(Mediatorがサーバーの場合)」 第10.4.1.8項「同期リクエスト-レスポンス(Oracle Mediatorがクライアントの場合)」 第10.4.1.9項「非同期リクエスト-レスポンス(Oracle Mediatorがクライアントの場合)」 |
アウトバウンド・デキュー |
第10.4.1.10項「アウトバウンド・デキューのシナリオ」 |
この項では、Oracle MQ Seriesアダプタの次の機能について説明します。
RFH2ヘッダーは拡張可能なヘッダーです。RFH2ヘッダーでは、より多くのヘッダー・プロパティをペイロードに追加できます。RFH2は、メッセージ・コンテンツに関連するJMS固有データを送信します。JMSに直接関連しない追加情報も送信できます。
RFH2ヘッダーは、固定部分と可変部分の2つの部分で構成されます。同じメッセージに複数のRFH2ヘッダーが存在する場合があります。
固定部分は、standard
のWebSphere 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に示す値のみです。
固定部分の後に、可変部分が続きます。可変部分には、不特定数の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 |
String |
jms |
Cid |
string |
JMSReplyTo |
Destination |
jms |
Rto |
string |
JMSTimestamp |
long |
jms |
Tms |
i8 |
JMSType |
String |
mcd |
Type、Set、Fmt |
string |
JMSXGroupID |
String |
jms |
Gid |
string |
JMSXGroupSeq |
int |
jms |
Seq |
i4 |
xxx(ユーザー定義) |
Any |
usr |
xxx |
any |
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接続を介して転送されるデータを暗号化することによって機能します。公開鍵を使用して暗号化されたデータは、対応する秘密鍵でのみ復号化できます。逆に、秘密鍵を使用して暗号化されたデータは、対応する公開鍵でのみ復号化できます。
MQ Seriesでは、SSLを使用したMQ Seriesクライアントとのセキュアな通信がサポートされています。この機能の一環として、SSLを使用したメッセージのエンキューがアダプタでサポートされます。Oracle MQ SeriesアダプタでSSLを有効化するには、次のプロパティを指定する必要があります。
SSLEnable: このプロパティのtrue/false値は、Oracle MQ SeriesアダプタでのSSL有効化/無効化を示します。
KeyStoreLocation: これは、Oracle MQ Seriesアダプタが秘密鍵を格納するキーストアです。このプロパティは、アダプタがMQ Seriesサーバーから認証を受ける必要があるため必要です。
KeyStorePassword: このパスワードは、キーストアへのアクセスで必要になります。
TrustStoreLocation: これは、アダプタが信頼できる証明書情報を格納する場所です。この情報は、アダプタがMQ Seriesサーバーから認証を受ける場合に必要になります。
Protocol: キー管理のアルゴリズム。
KeyStoreProviderName: キーストア・プロバイダの名前。
KeyStoreType: キーストアのタイプ。
KeyStoreAlgorithm: キーストアで使用されるアルゴリズム。
CipherSuite: CipherSuiteは、SVRCONN
チャネルで設定されているCipherSpecと一致する名前に設定します。NULL(デフォルト)に設定すると、SSL暗号化は実行されません。
SSLPeerName: 識別名パターン。CipherSuiteが設定されている場合、この変数を使用することによって、常に正しいキュー・マネージャが使用されるようにできます。NULL(デフォルト)に設定すると、キュー・マネージャの識別名はチェックされません。sslCipherSuite
がNULLの場合は、この変数は無視されます。
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]
注意:
|
Oracle MQ Seriesアダプタは、Oracle BPEL Process Manager(Oracle BPEL PM)とOracle Mediatorサービス・エンジンでのアクティブ/アクティブ・トポロジに対する高可用性機能をサポートしています。この機能は、インバウンド操作とアウトバウンド操作の両方でサポートされています。
高可用性を実現するようにOracle MQ Seriesアダプタを構成するには、次の前提条件が満たされていることを確認する必要があります。
クラスタリングされた複数のプロセスで、同じキューが使用されている必要があります。
アダプタを正常に機能させるために、リモート・フォルトに対するフォルト・ポリシーとフォルト・バインディングが作成されている必要があります。
Oracle MQ Seriesアダプタは、XAトランザクションに関与する必要があります。XAトランザクションの詳細は、第10.3.3項「XAトランザクション」を参照してください。
Oracle MQ Seriesアダプタでは、インバウンド操作に対してのみ、スケーラビリティ機能がサポートされます。Oracle MQ Seriesアダプタには、インバウンド・キューからメッセージをデキューするスレッドの数を制御するパラメータが用意されています。次のプロパティを.jca
ファイルで指定する必要があります。
InboundThreadCount
='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>
Oracle MQ Seriesアダプタでは、エンタープライズ情報システム(EIS)とのアウトバウンド接続の確立時の、EISの資格証明(ユーザー名やパスワードなど)の保護がサポートされています。Oracle MQ Seriesアダプタのユーザー名とパスワードは、Oracle WebLogic Serverのコンテナ管理のサインオンを使用して保護できます。
詳細は、第4.2.22項「エンタープライズ情報システムの資格証明の保護」を参照してください。
フォルト・ポリシー・ファイルには、フォルト条件および対応するフォルト・リカバリ・アクションを定義します。それぞれのフォルト条件で、処理を試みる特定のフォルトまたは一連のフォルトを指定し、それに対応するアクションを指定します。フォルト・ポリシー・ファイルでは一連のアクションがIDで識別されます。
Oracle MQ Seriesアダプタでは、フォルト・ポリシーを使用した拒否ハンドラの定義がサポートされています。
フォルト・ポリシーの詳細は、第2.21.1.1項「拒否ハンドラの構成」を参照してください。
Oracle MQ Seriesアダプタでは、インバウンドのメッセージ拒否処理がサポートされています。メッセージ拒否ハンドラは、変換エラーを処理して修正処理を実行するように構成できます。
拒否ハンドラの詳細は、第2.21.1.1項「拒否ハンドラの構成」を参照してください。
Oracle MQ Seriesアダプタでは、次の2つのインバウンド再試行メカニズムがサポートされています。
通常、JCAインバウンド再試行メカニズムはすべてのアダプタで共通して使用されますが、メッセージ・バックアウト・キュー・メカニズムはOracle MQ Seriesアダプタでのみ使用されます。.jcaファイルでBackoutQueueName
プロパティを指定した場合にのみ、Oracle MQ Seriesアダプタでは再試行にメッセージ・バックアウト・キュー・メカニズムが使用されます。デフォルトでは、再試行にはJCAインバウンド再試行メカニズムが使用されます。
注意: Oracle MQ Seriesアダプタでは、この2つの再試行方法は相互に排他的な操作であり、アダプタで一度に使用できるメカニズムは一方のみです。両方のオプションを指定した場合は、バックアウト・キュー・オプションが優先されます。 |
Oracle MQ Seriesアダプタでは、バックエンド・アプリケーションに接続してイベントを受信するためのプル・モデルがサポートされています。接続関連の問題はリカバリ可能とみなされ、ほとんどのインバウンド・アダプタはEISとの接続を確立できるまで再試行を続けます。
Oracle MQ Seriesアダプタの場合、メッセージをキューに蓄積できない場合も再試行可能です。
再試行メカニズムの詳細は、第2.21項「エラー処理」を参照してください。
バックアウト・キューは、インバウンド・キューから拒否されたメッセージが蓄積されるキューです。インバウンド・アダプタはメッセージのバックアウト数をチェックし、この数がMaximumBcakoutCount
値を超えた場合、指定されたバックアウト・キューにメッセージを蓄積します。Oracle MQ Seriesアダプタではこのメカニズムを使用して、拒否されたメッセージのインバウンド再試行が処理されます。
.jca
ファイルでBackoutQueueName
プロパティを指定すると、Oracle MQ Seriesアダプタでは再試行にメッセージのバックアウト数が使用されます。MaximumBackoutCount
プロパティを使用して最大再試行回数を指定できます。このプロパティのデフォルト値はinfiniteです。MaximumBackoutCount
値をBackoutQueueName
とともに指定しない場合、アダプタは無制限に再試行します。バックアウト・キュー・プロパティが指定されている場合、アダプタは(composite.xmlで指定された)JCA
再試行を考慮しません。
BackoutRetries
プロパティを設定して、メッセージをバックアウト・キューに配信する再試行の回数を指定する必要があります。この再試行の間隔はBackoutRetryInterval
を使用して設定されます。BackoutRetries
のデフォルト値は3
で、BackoutInterval
は5
秒です。
MaximumBackoutCount
値に達した後もメッセージが拒否される場合、アダプタはメッセージをバックアウト・キューに蓄積します。Oracle MQ Seriesアダプタは、メッセージをバックアウト・キューに蓄積できなければ、BackoutInterval
の時間遅延を使用してBackoutRetries
数になるまで試行します。BackoutRetriesの後もメッセージをバックアウト・キューに蓄積できない場合、アダプタはエンドポイントを非アクティブ化します。
BackoutQueueManagerName
プロパティで、バックアウト・キューのキュー・マネージャの名前も指定する必要があります。BackoutQueueがインバウンド・キューQueueManagerにある場合、このプロパティは使用できません。
注意: バックアウト・キューを使用する場合は、次の点を考慮してください。
|
バックアウト・キューの構成の詳細は、第10.6.6項「バックアウト・キューの構成」を参照してください。
この項では、Oracle MQ Seriesアダプタの次の概念について説明します。
Oracle MQ Seriesアダプタでは、次のメッセージングのシナリオがサポートされます。
このシナリオでは、Oracle MQ Seriesアダプタはキュー・マネージャにより管理されている特定のキューに接続してメッセージを書き込みます。Oracle BPEL PMまたはメディエータから送信されるアウトバウンド・メッセージの場合、Oracle MQ Seriesアダプタでは次の操作が実行されます。
Oracle BPEL PMまたはメディエータからメッセージを受信します。
設計時の指定に従ってXMLコンテンツがフォーマットされます。
メッセージのプロパティ(優先度、有効期限、メッセージ・タイプおよび永続性など)が設定されます。これらのプロパティは、アダプタ構成ウィザードで選択した内容に基づきます。
メッセージのプロパティの詳細は、第10.4.2.1項「メッセージ・タイプ」を参照してください。
設計時にアダプタ構成ウィザードで指定したキューにメッセージが送信されます。
図10-7に、アダプタ構成ウィザードで選択する必要がある操作タイプを示します。
図10-8に、「MQにメッセージを蓄積」操作タイプを選択した後に表示されるページを示します。
このページで次のプロパティを指定できます。
キュー名: Oracle MQ Seriesアダプタがメッセージをエンキューするキューの名前。これは必須フィールドです。
キュー・マネージャ: キューが属しているキュー・マネージャの名前です。このフィールドはオプションで、メッセージをリモート・キューにエンキューする場合に必要です。
一部配信: このオプションを適用できるのは、アウトバウンド操作用のキューを複数指定した場合(配布リストのシナリオ)のみです。「一部配信」の値は、true
またはfalse
です。true
を割り当てると、一部のキューでメッセージの配信に失敗しても、メッセージは配布リストで指定した残りのキューに入れられて蓄積されます。false
を割り当てると、メッセージの1つに失敗しても、そのメッセージはキューに蓄積されません。
メッセージの書式: メッセージのフォーマット。
注意: メッセージをエンキューする場合は、特定のフォーマットに必要な各種の必須値を正しく指定していることを確認してください。 |
優先度: 0(最低)から9(最高)までのメッセージの優先度。
永続性: メッセージの永続性。メッセージの永続性を、宛先キューで定義されているデフォルトの永続性属性から取得するように指定することも可能です。
配信失敗: メッセージの配信に失敗した場合、そのメッセージを配信不能キューに蓄積するか、または破棄できます。
必要な場合、メッセージをセグメント化できます: これは、大きすぎてキューに収まらないメッセージに適用可能です。その場合、セグメント化するように指定していれば、単一メッセージをキューで対応できるバイト数の複数のメッセージに分割できます。
有効期限: メッセージの有効期限。有効期限が経過したメッセージは破棄されます。
これらのプロパティの詳細は、第10.4.2項「メッセージ・プロパティ」を参照してください。
次に表示されるアダプタ構成ウィザードのページは、図10-9の「メッセージ」ページです。このページでは、変換用のXMLスキーマ定義(XSD)ファイルを選択できます。
ネイティブ・フォーマット変換が不要である場合は(JPGまたはGIFイメージが処理中であるなど)、「ネイティブ・フォーマット変換は不要」チェック・ボックスを選択します。ファイルはBase64エンコーディングで渡されます。
トランスレーションにはXSDファイルが必要です。新しいスキーマの定義、または既存のデータ型定義(DTD)やCOBOLコピーブックの変換を行うには、「ネイティブ・フォーマットのスキーマの定義」を選択します。これにより、ネイティブ・フォーマット・ビルダー・ウィザードが起動されます。このウィザードは、特殊文字区切り、カンマ区切り値(CSV)、固定長、DTDおよびCOBOLコピーブックなどのファイル・フォーマットを使用したネイティブ・スキーマ・ファイルの作成を支援します。ネイティブ・スキーマ・ファイルの作成後、「スキーマ・ファイルのURL」および「スキーマ要素」フィールドが入力された「メッセージ」ページが表示されます。
詳細は、第6.1項「ネイティブ・フォーマット・ビルダー・ウィザードを使用したネイティブ・スキーマ・ファイルの作成」を参照してください。
このシナリオでは、Oracle MQ Seriesアダプタはキュー・マネージャにより管理されている特定のキューに接続し、そのキューからメッセージを削除します。Oracle BPEL PMまたはメディエータに送信されるインバウンド・メッセージの場合、Oracle MQ Seriesアダプタでは次の操作が実行されます。
設計時に指定したキューに接続されます。
メッセージの着信時にキューからメッセージがデキューされます。
設計時に定義したトランスレーション・ロジックに基づいて、メッセージが読み取られて変換されます。
メッセージがXMLメッセージとしてOracle BPEL PMまたはメディエータにパブリッシュされます。
図10-10に、アダプタ構成ウィザードで選択する必要がある操作タイプを示します。
図10-11に、「MQからメッセージを取得」操作タイプを選択した後に表示されるページを示します。
このページで次のプロパティを指定できます。
キュー名: Oracle MQ Seriesアダプタがメッセージをデキューするキューの名前。これは必須フィールドです。
スキーマ・オプション: このオプションを使用すると、メッセージのデキューに使用するスキーマを指定できます。
他のスキーマを選択します: このオプションでは、メッセージのデキューに使用するスキーマを選択できます。
事前定義済スキーマを選択します: このオプションでは、アダプタに用意されている事前定義済のスキーマを選択できます。
次に表示されるアダプタ構成ウィザードのページは、図10-9の「メッセージ」ページです。このページでは、変換用のXSDスキーマ・ファイルを選択できます。
メッセージ発行操作のスキーマの指定と同様に、このページでは次のタスクを実行できます。
ネイティブ・フォーマット変換の要不要の指定
変換用のXSDスキーマ・ファイルの選択
CSV、固定長、DTDおよびCOBOLコピーブックなどのファイル形式からXSDファイルの作成が可能なネイティブ・フォーマット・ビルダー・ウィザードの起動
「メッセージ」ページの詳細は、第10.4.1.1項「メッセージのエンキュー」を参照してください。
このシナリオでは、Oracle BPEL PMがリクエスト・メッセージを送信し、非開始のreceiveアクティビティを使用して対応するレスポンスを受信します。invokeアクティビティによりアダプタのアウトバウンド起動が開始され、リクエストが送信されます。Oracle MQ Seriesアダプタでは、次の操作が実行されます。
Oracle BPEL PMからのメッセージが受信されます。
設計時にアダプタ構成ウィザードで指定したXMLコンテンツがフォーマットされます。
リクエスト・メッセージのプロパティと相関スキーマが設定されます。
設計時に指定したキューにメッセージが送信されます。サード・パーティ・アプリケーションはメッセージを受信して処理し、レスポンスを生成してから、リクエスト・メッセージで指定されたreplyTo
キューにレスポンス・メッセージをエンキューします。レスポンス・メッセージの相関IDとメッセージIDは、リクエスト・メッセージで指定された相関スキーマに基づいて生成されます。
Oracle MQ Seriesアダプタにより、replyTo
キューからメッセージがデキューされます。
レスポンスがメディエータの非開始のreceiveアクティビティに送信されます。レスポンスが正しいBPELインスタンスに確実に送信されるように、相関スキーマが使用されます。
図10-12に、アダプタ構成ウィザードで選択する必要がある操作タイプを示します。
図10-13に、「MQにメッセージを送信し、リプライ/レポートを取得」操作タイプを選択した後に表示されるページを示します。
このページで次のプロパティを指定できます。
メッセージ・タイプ: メッセージのタイプ。通常メッセージまたはリクエスト・メッセージを送信できます。
レポートの取得: なんらかのレポートが必要な場合は、このオプションを選択します。レポートのタイプは、図10-14に示す次のページで指定できます。
キュー名: Oracle MQ Seriesアダプタがメッセージをエンキューするキューの名前。これは必須フィールドです。
キュー・マネージャ: キューが属しているキュー・マネージャの名前です。このフィールドはオプションです。
メッセージの書式: メッセージのフォーマット。
優先度: 0(最低)から9(最高)までのメッセージの優先度。
永続性: メッセージの永続性。メッセージの永続性を、宛先キューで定義されているデフォルトの永続性属性から取得するように指定することも可能です。
配信失敗: メッセージの配信に失敗した場合、そのメッセージを配信不能キューに蓄積するか、または破棄できます。
必要な場合、メッセージをセグメント化できます: これは、大きすぎてキューに収まらないメッセージに適用可能です。その場合、セグメント化するように指定していれば、単一メッセージをキューで対応できるバイト数の複数のメッセージに分割できます。
有効期限: メッセージの有効期限。有効期限が経過したメッセージは破棄されます。
これらのプロパティの詳細は、第10.4.2項「メッセージ・プロパティ」および第10.4.5項「レポート・メッセージ」を参照してください。
「MQにメッセージを送信し、リプライ/レポートを取得」ページで「次へ」をクリックすると、「レポート」ページ(図10-14)または「レスポンス」ページ(図10-15)が表示されます。
図10-14に示す「レポート」ページが表示されるのは、図10-13に示した「MQにメッセージを送信し、リプライ/レポートを取得」ページで「レポートの取得」オプションを選択した場合のみです。
このページで次のレポート・タイプを選択できます。
着信時の確認
送信時の確認
例外レポート
有効期限レポート
これらのレポート・タイプの詳細は、第10.4.5項「レポート・メッセージ」を参照してください。
「レポート」ページで「次へ」をクリックすると、図10-15に示す「レスポンス」ページが表示されます。
「レスポンス」ページで次のプロパティを指定できます。
返信先キュー名: 返信先キューの名前。
「相関スキーム」: Oracle MQ Seriesアダプタで必要な相関スキーマ。
相関スキーマの詳細は、第10.4.3項「相関スキーマ」を参照してください。
スキーマ・オプション: このオプションを使用すると、メッセージのデキューに使用するスキーマを指定できます。
他のスキーマを選択します: このオプションでは、メッセージのデキューに使用するスキーマを選択できます。
事前定義済スキーマを選択します: このオプションでは、アダプタに用意されている事前定義済のスキーマを選択できます。
注意: 非同期アウトバウンド・リクエスト/リプライのシナリオのOracle MQ Seriesアダプタの場合、プロパティはOracle Enterprise Managerコンソールで Oracle Enterprise Manager Consoleを使用してこのシナリオのOracle MQ Seriesアダプタのプロパティを編集する場合は、次の点に注意してください。
|
「レスポンス」ページで「次へ」をクリックすると、図10-16に示す「メッセージ」ページが表示されます。このページでは、リクエスト・メッセージとレスポンス・メッセージの変換に使用するXSDスキーマ・ファイルを選択できます。
このページで次のタスクを実行できます。
ネイティブ・フォーマット変換の要不要の指定
変換用のXSDスキーマ・ファイルの選択
CSV、固定長、DTDおよびCOBOLコピーブックなどのファイル形式からXSDファイルの作成が可能なネイティブ・フォーマット・ビルダー・ウィザードの起動
「メッセージ」ページの詳細は、第10.4.1.1項「メッセージのエンキュー」を参照してください。
請求-リクエスト-レスポンスのシナリオでは、リクエスト・メッセージを介して提供される、なんらかの相関スキームで指定されたリプライ・キュー内でリプライ・メッセージが予期されます。このリプライ・キューは特定のプロセス(BPEL/メディエータ)により使用され、他のプロセスでは使用されません。
同じリプライ・キューが他のなんらかのアプリケーションで使用される場合は、リプライ・メッセージの相関付けが正しいかどうかに関係なくメッセージが取得され、最終的にはメッセージが消失します。
このシナリオでは、Oracle BPEL PMがリクエストを受信して処理し、replyアクティビティを使用してレスポンスを同期的に送信します。Oracle MQ Seriesアダプタでは、次の操作が実行されます。
メッセージの着信時にキューからリクエスト・メッセージがデキューされます。
設計時に定義したトランスレーション・ロジックに基づいて、メッセージが読み取られて変換されます。
メッセージがXMLメッセージとしてOracle BPEL PMにパブリッシュされます。Oracle BPEL PMでは、リクエストが処理されてレスポンスがOracle MQ Seriesアダプタに送信されます。
Oracle BPEL PMからのレスポンス・メッセージが受信されます。
設計時の指定に従ってXMLコンテンツがフォーマットされます。
メッセージのプロパティ(優先度、有効期限、メッセージ・タイプおよび永続性など)が設定されます。これらのプロパティは、アダプタ構成ウィザードで選択した内容に基づきます。
設計時にアダプタ構成ウィザードで指定したキューにメッセージが送信されます。
図10-17に、このシナリオのサンプルBPELプロセスを示します。
図10-17 同期リクエスト-レスポンスのサンプル(Oracle BPEL PMがサーバーの場合)
図10-18に、アダプタ構成ウィザードで選択する必要がある操作タイプを示します。
図10-19に、「MQからメッセージを取得し、リプライ/レポートを送信」操作タイプを選択した後に表示されるページを示します。このページで、Oracle MQ Seriesアダプタでメッセージがデキューされるキュー名を指定します。
「MQからメッセージを取得し、リプライ/レポートを送信」ページで「次へ」をクリックすると、図10-20に示す「レスポンス」ページが表示されます。
「レスポンス」ページで次のプロパティを指定できます。
メッセージ・タイプ: デキューするメッセージのタイプ。このオプションは返信メッセージ・タイプに影響します。
メッセージの書式: メッセージのフォーマット。
優先度: メッセージの優先度。
永続性: メッセージの永続性。メッセージの永続性を、宛先キューで定義されているデフォルトの永続性属性から取得するように指定することも可能です。
配信失敗: メッセージの配信に失敗した場合、そのメッセージを配信不能キューに蓄積するか、または破棄できます。
必要な場合、メッセージをセグメント化できます: これは、大きすぎてキューに収まらないメッセージに適用可能です。その場合、セグメント化するように指定していれば、単一メッセージをキューで対応できるバイト数の複数のメッセージに分割できます。
有効期限: メッセージの有効期限。
これらのプロパティの詳細は、第10.4.2項「メッセージ・プロパティ」を参照してください。
「レスポンス」ページで「次へ」をクリックすると、図10-16に示す「メッセージ」ページが表示されます。このページで次のタスクを実行できます。
ネイティブ・フォーマット変換の要不要の指定
変換用のXSDスキーマ・ファイルの選択
CSV、固定長、DTDおよびCOBOLコピーブックなどのファイル形式からXSDファイルの作成が可能なネイティブ・フォーマット・ビルダー・ウィザードの起動
「メッセージ」ページの詳細は、第10.4.1.1項「メッセージのエンキュー」を参照してください。
Oracle BPEL PMがリクエスト-レスポンス相互作用を開始すると、BPELプロセスはリクエストをインバウンド・メッセージとして受信し、処理してからinvokeアクティビティを介してレスポンスを送信します。非同期リクエスト-リプライのシナリオでは、Oracle MQ Seriesアダプタにより次の操作が実行されます。
メッセージの着信時にキューからメッセージがデキューされます。
設計時に定義したトランスレーション・ロジックに基づいて、メッセージが読み取られて変換されます。
メッセージがXMLメッセージとしてOracle BPEL PMにパブリッシュされます。Oracle BPEL PMでは、リクエストが処理されてレスポンスがOracle MQ Seriesアダプタに送信されます。
Oracle BPEL PMからのメッセージが受信されます。
設計時の指定に従ってXMLコンテンツがフォーマットされます。
メッセージのプロパティ(優先度、有効期限、メッセージ・タイプおよび永続性など)が設定されます。これらのプロパティは、アダプタ構成ウィザードで選択した内容に基づきます。
設計時にアダプタ構成ウィザードで指定したキューにメッセージが送信されます。
図10-21に、このシナリオのサンプルBPELプロセスを示します。
図10-21 非同期リクエスト-レスポンスのサンプル(Oracle BPEL PMがサーバーの場合)
図10-22に、アダプタ構成ウィザードで選択する必要がある操作タイプを示します。
図10-19に、「MQからメッセージを取得し、リプライ/レポートを送信」操作タイプを選択した後に表示されるページを示します。このページで、Oracle MQ Seriesアダプタでメッセージがデキューされるキュー名を指定します。
「MQからメッセージを取得し、リプライ/レポートを送信」ページで「次へ」をクリックすると、図10-20に示す「レスポンス」ページが表示されます。
「レスポンス」ページで次のプロパティを指定できます。
メッセージ・タイプ: デキューするメッセージのタイプ。このオプションは返信メッセージ・タイプに影響します。
メッセージの書式: メッセージのフォーマット。
優先度: メッセージの優先度。
永続性: メッセージの永続性。メッセージの永続性を、宛先キューで定義されているデフォルトの永続性属性から取得するように指定することも可能です。
配信失敗: メッセージの配信に失敗した場合、そのメッセージを配信不能キューに蓄積するか、または破棄できます。
必要な場合、メッセージをセグメント化できます: これは、大きすぎてキューに収まらないメッセージに適用可能です。その場合、セグメント化するように指定していれば、単一メッセージをキューで対応できるバイト数の複数のメッセージに分割できます。
有効期限: メッセージの有効期限。
これらのプロパティの詳細は、第10.4.2項「メッセージ・プロパティ」を参照してください。
「MQからメッセージを取得し、リプライ/レポートを送信」ページで「次へ」をクリックすると、「レスポンス」ページ(図10-23および図10-24)が表示されますが、これらのページのオプションのセットは互いに異なります。
図10-24に示す「レスポンス」ページが表示されるのは、「MQからメッセージを取得し、リプライ/レポートを送信」ページの「メッセージ・タイプ」フィールドで「標準」オプションを選択した場合のみです。
「レスポンス」ページで次のプロパティを指定できます。
(オプション)フォールバック返信先キュー: レスポンス・フォールバック・キュー名を入力します。レスポンス・メッセージは、リクエスト・メッセージのreplyToQueueプロパティで指定されたキューにエンキューされます。ただし、リクエスト・メッセージでreplyToQueueプロパティが設定されていない場合、ここに名前を入力することにより、プロセスがレスポンスをエンキューできるようになります。
(オプション)フォールバック返信先キュー・マネージャ: セカンダリ・キュー名を入力します。この名前が使用されるのは、JNDI接続名の指定時に設定したプライマリ・キュー・マネージャが、「キュー名」フィールドに入力されているキュー名にアクセスできない場合です。これは、「フォールバック返信先キュー」フィールドの説明にある機能に類似しています。
「レスポンス」ページでの他のプロパティの指定方法は、図10-23で説明されているプロパティを参照してください。
「レスポンス」ページで「次へ」をクリックすると、図10-25に示す「メッセージ」ページが表示されます。このページで次のタスクを実行できます。
ネイティブ・フォーマット変換の要不要の指定
変換用のXSDスキーマ・ファイルの選択
CSV、固定長、DTDおよびCOBOLコピーブックなどのファイル形式からXSDファイルの作成が可能なネイティブ・フォーマット・ビルダー・ウィザードの起動
「メッセージ」ページの詳細は、第10.4.1.1項「メッセージのエンキュー」を参照してください。
非同期リクエスト-リプライ相互作用では、インバウンド・メッセージ・ヘッダーからアウトバウンド・メッセージ・ヘッダーに次のプロパティをマップする必要があります。
MsgID
: メッセージIDを指します。
CorrelID
: メッセージの相関IDを指します。
CorrelationScheme
: リクエスト・メッセージのmsgidとcorrelidの組合せを指します。
詳細は、第10.4.3項「相関スキーマ」を参照してください。
ReplyToQ
: レスポンス・キューの名前を指します。
ReplyToQueueManager
: レスポンス・キュー・マネージャの名前を指します。
これらのプロパティはassignアクティビティを使用してマップできます。
このシナリオでは、メディエータがリクエストを受信して処理し、レスポンスを同期的に送信します。Oracle MQ Seriesアダプタでは、次の操作が実行されます。
メッセージの着信時にキューからリクエスト・メッセージがデキューされます。
設計時に定義したトランスレーション・ロジックに基づいて、メッセージが読み取られて変換されます。
メッセージがXMLメッセージとしてメディエータにパブリッシュされます。メディエータでは、リクエストが処理されてレスポンスがOracle MQ Seriesアダプタに送信されます。
メディエータからのレスポンス・メッセージが受信されます。
設計時の指定に従ってXMLコンテンツがフォーマットされます。
メッセージのプロパティ(優先度、有効期限、メッセージ・タイプおよび永続性など)が設定されます。これらのプロパティは、アダプタ構成ウィザードで選択した内容に基づきます。
設計時にアダプタ構成ウィザードで指定したキューにメッセージが送信されます。
図10-19に、アダプタ構成ウィザードで選択する必要がある操作タイプを示します。
これ以降のページは、すべて第10.4.1.4項「同期リクエスト-レスポンス(Oracle BPEL PMがサーバーの場合)」で説明したページと同様です。
注意: メディエータの場合、非同期リクエスト-レスポンス・パターンはサポートされていません。 |
Oracle MQ Seriesアダプタでは、アウトバウンドの同期-請求-リクエスト-レスポンスのシナリオがサポートされています。このシナリオでは、アダプタにより同期的に通常/リクエスト・メッセージがキューにエンキューされてレポート/リプライが予想されます。レポート/リプライ・メッセージは、通常/リクエスト・メッセージのReplyToQueueName
キューに着信します。
注意: グローバル・トランザクションに参加している場合、リクエスト・メッセージはエンキューされないため、非XAモードでアウトバウンド同期-請求-レスポンスを実行する必要があります。 |
図10-29に、アダプタ構成ウィザードで選択する必要がある操作タイプを示します。
図10-13に、「MQにメッセージを送信し、リプライ/レポートを取得」操作タイプを選択した後に表示されるページを示します。
このページで次のプロパティを指定できます。
メッセージ・タイプ: メッセージのタイプ。通常メッセージまたはリクエスト・メッセージを送信できます。
キュー名: Oracle MQ Seriesアダプタがメッセージをエンキューするキューの名前。これは必須フィールドです。
キュー・マネージャ: キューが属しているキュー・マネージャの名前です。このフィールドはオプションで、メッセージをリモート・キューにエンキューする場合に必要です。
メッセージの書式: メッセージのフォーマット。
優先度: 0(最低)から9(最高)までのメッセージの優先度。
永続性: メッセージの永続性。メッセージの永続性を、宛先キューで定義されているデフォルトの永続性属性から取得するように指定することも可能です。
配信失敗: メッセージの配信に失敗した場合、そのメッセージを配信不能キューに蓄積するか、または破棄できます。
必要な場合、メッセージをセグメント化できます: これは、大きすぎてキューに収まらないメッセージに適用可能です。その場合、セグメント化するように指定していれば、単一メッセージをキューで対応できるバイト数の複数のメッセージに分割できます。
有効期限: メッセージの有効期限。有効期限が経過したメッセージは破棄されます。
「MQにメッセージを送信し、リプライ/レポートを取得」ページで「次へ」をクリックすると、図10-30に示す「レスポンス」ページが表示されます。
同期リクエスト-レスポンスのシナリオでは、「レスポンス」ページで次のプロパティも編集する必要があります。
返信先キュー名: 返信先キューの名前。
「相関スキーム」: Oracle MQ Seriesアダプタで使用される必要がある相関スキーマ。
相関スキーマの詳細は、第10.4.3項「相関スキーマ」を参照してください。
スキーマ・オプション: このオプションを使用すると、メッセージのデキューに使用するスキーマを指定できます。
他のスキーマを選択します: このオプションでは、メッセージのデキューに使用するスキーマを選択できます。
事前定義済スキーマを選択します: このオプションでは、アダプタに用意されている事前定義済のスキーマを選択できます。
レスポンス待機間隔: このプロパティに有効な値は、任意の間隔値(>= 0)です。これは、アダプタがreplyToQueueName
へのレポート/リプライの着信を待機するミリ秒数です。デフォルトでは、このプロパティの値は0(ゼロ)ミリ秒です。この値は変更できますが、アウトバウンド・アクティビティのタイムアウト間隔よりも小さい値に設定する必要があります。レポート/リプライ・メッセージが規定の時間内に着信しなければ、アダプタにより例外がスローされます。このプロパティはオプションです。
注意:
|
Oracle MQ Seriesアダプタでは、アウトバウンドの同期-請求-リクエスト-レスポンスのシナリオもサポートされています。このシナリオでは、アダプタにより同期的に通常/リクエスト・メッセージがキューにエンキューされてレポート/リプライが予想されます。レポート/リプライ・メッセージは、通常/リクエスト・メッセージのReplyToQueueNameキューに着信します。
同期リクエスト-レスポンス(Oracle Mediatorがクライアントの場合)のシナリオは、同期リクエスト-レスポンス(Oracle BPELがクライアントの場合)と同じです。同期リクエスト-レスポンスのシナリオの詳細は、第10.4.1.7項「同期リクエスト-レスポンス(Oracle BPEL PMがクライアントの場合)」を参照してください。
このシナリオでは、Oracle Mediatorがリクエスト・メッセージを送信し、Mediatorコールバック・ハンドラから対応するレスポンスを受信します。Oracle Mediatorでは、アウトバウンド起動が送信されてリクエストが送信されます。Oracle MQ Seriesアダプタでは、次の操作が実行されます。
Oracle Mediatorからのメッセージが受信されます。
設計時にアダプタ構成ウィザードで指定したXMLコンテンツがフォーマットされます。
リクエスト・メッセージのプロパティと相関スキーマが設定されます。
設計時に指定したキューにメッセージが送信されます。サード・パーティ・アプリケーションはメッセージを受信して処理し、レスポンスを生成してから、リクエスト・メッセージで指定されたreplyTo
キューにレスポンス・メッセージをエンキューします。レスポンス・メッセージの相関IDとメッセージIDは、リクエスト・メッセージで指定された相関スキーマに基づいて生成されます。
Oracle MQ Seriesアダプタにより、replyTo
キューからメッセージがデキューされます。
メッセージのプロパティ(優先度、有効期限、メッセージ・タイプおよび永続性など)が設定されます。これらのプロパティは、アダプタ構成ウィザードで選択した内容に基づきます。
レスポンスがBPELプロセスの非開始のreceiveアクティビティに送信されます。レスポンスが正しいBPELインスタンスに確実に送信されるように、相関スキーマが使用されます。
図10-12に、アダプタ構成ウィザードで選択する必要がある操作タイプを示します。
図10-13に、「MQにメッセージを送信し、リプライ/レポートを取得」操作タイプを選択した後に表示されるページを示します。
このページで次のプロパティを指定できます。
メッセージ・タイプ: メッセージのタイプ。通常メッセージまたはリクエスト・メッセージを送信できます。
キュー名: Oracle MQ Seriesアダプタがメッセージをエンキューするキューの名前。これは必須フィールドです。
メッセージの書式: メッセージのフォーマット。
キュー・マネージャ: キューが属しているキュー・マネージャの名前です。このフィールドはオプションで、メッセージをリモート・キューにエンキューする場合に必要です。
優先度: 0(最低)から9(最高)までのメッセージの優先度。
永続性: メッセージの永続性。メッセージの永続性を、宛先キューで定義されているデフォルトの永続性属性から取得するように指定することも可能です。
配信失敗: メッセージの配信に失敗した場合、そのメッセージを配信不能キューに蓄積するか、または破棄できます。
必要な場合、メッセージをセグメント化できます: これは、大きすぎてキューに収まらないメッセージに適用可能です。その場合、セグメント化するように指定していれば、単一メッセージをキューで対応できるバイト数の複数のメッセージに分割できます。
有効期限: メッセージの有効期限。有効期限が経過したメッセージは破棄されます。
これらのプロパティの詳細は、第10.4.2項「メッセージ・プロパティ」および第10.4.5項「レポート・メッセージ」を参照してください。
「MQにメッセージを送信し、リプライ/レポートを取得」ページで「次へ」をクリックすると、「レポート」ページ(図10-14)または「レスポンス」ページ(図10-15)が表示されます。
図10-14に示す「レポート」ページが表示されるのは、図10-13に示した「MQにメッセージを送信し、リプライ/レポートを取得」ページで「レポートの取得」オプションを選択した場合のみです。
図10-15に示す「レスポンス」ページは、「リクエスト」オプションと「標準」オプションのどちらを選択したかに関係なく表示されます。唯一の違いは、「リクエスト」オプションを選択すると、「レスポンス」ページの「メッセージ・タイプ」フィールドにREPLY
と表示されることです。これに対して、「標準」オプションを選択すると、「レスポンス」ページの「メッセージ・タイプ」フィールドにはREPORTS
と表示されます。
図10-14に示すように、次のレポート・タイプを選択できます。
着信時の確認
送信時の確認
例外レポート
有効期限レポート
これらのレポート・タイプの詳細は、第10.4.5項「レポート・メッセージ」を参照してください。
「レポート」ページで「次へ」をクリックすると、図10-15に示す「レスポンス」ページが表示されます。
「レスポンス」ページで次のプロパティを指定できます。
返信先キュー名: 返信先キューの名前。
「相関スキーム」: Oracle MQ Seriesアダプタで使用される相関スキーマ。
相関スキーマの詳細は、第10.4.3項「相関スキーマ」を参照してください。
スキーマ・オプション: このオプションを使用すると、メッセージのデキューに使用するスキーマを指定できます。
他のスキーマを選択します: このオプションでは、メッセージのデキューに使用するスキーマを選択できます。
事前定義済スキーマを選択します: このオプションでは、アダプタに用意されている事前定義済のスキーマを選択できます。
注意: 非同期アウトバウンド・リクエスト/リプライのシナリオのOracle MQ Seriesアダプタの場合、プロパティはOracle Enterprise Managerコンソールで Oracle Enterprise Manager Consoleを使用してこのシナリオのOracle MQ Seriesアダプタのプロパティを編集する場合は、次の点に注意してください。
|
「レスポンス」ページで「次へ」をクリックすると、図10-16に示す「メッセージ」ページが表示されます。このページでは、リクエスト・メッセージとレスポンス・メッセージの変換に使用するXSDスキーマ・ファイルを選択できます。
「メッセージ」ページの詳細は、第10.4.1.1項「メッセージのエンキュー」を参照してください。
アウトバウンド・デキューのシナリオでは、アダプタ構成ウィザードの「操作タイプ」ページで「MQからメッセージを取得」オプションを使用し、アウトバウンドOracle MQ Seriesアダプタを使用してキューから単一メッセージをデキューします。アウトバウンド・デキュー・オプションを有効化するには、図10-29に示すように「同期」オプションを選択する必要があります。
「MQにメッセージを送信し、リプライ/レポートを取得」ページで「次へ」をクリックすると、図10-30に示す「レスポンス」ページが表示されます。「レスポンス」ページで次のプロパティを設定する必要があります。
QueueName: メッセージのデキュー元のMQ Seriesキュー名です。このプロパティは必須です。
レスポンス待機間隔: メッセージがキューにない場合にアダプタが待機するミリ秒数です。このプロパティのデフォルト値は0(ゼロ)ミリ秒です。このプロパティはオプションです。このプロパティに有効な値は、任意の整数値(>= 0)です。このプロパティには、アウトバウンド・アクティビティのタイムアウトよりも小さい値を設定する必要があります。
注意:
|
メッセージID: このプロパティは、messageId
に基づいてメッセージ・フィルタ・オプションを設定します。このプロパティはオプションです。このプロパティに設定する値は、特定のmessageId
の16進数エンコード値である必要があります。
相関ID: このプロパティは、correlationId
に基づいてメッセージ・フィルタ・オプションを設定します。このプロパティはオプションです。このプロパティに設定する値は、特定のcorrelationId
の16進数エンコード値である必要があります。
注意: ヘッダーを介し、「メッセージID」および「相関ID」プロパティに基づいてメッセージをフィルタ処理できます。 |
Oracle MQ Seriesアダプタでは、次のメッセージ・プロパティがサポートされます。
Oracle MQ Seriesアダプタは、次の4タイプのメッセージをサポートしています。
通常メッセージは、あるプログラムから別のプログラムに送信されますが、レスポンスは期待されません。
リクエスト・メッセージは、あるプログラムから別のプログラムに送信され、レスポンスが必要です。
リプライ・メッセージは、リクエスト・メッセージに対するレスポンスとしてプログラムにより送信されます。
レポート・メッセージは、受信側プログラムから送信側プログラムに、メッセージ配信の成功または失敗の確認として送信されます。レポート・メッセージはすべてのメッセージ・タイプ(通常メッセージ、リクエスト・メッセージまたはリプライ・メッセージ)について生成できます。
Oracle MQ Seriesアダプタでサポートされている確認メッセージの詳細は、第10.4.5項「レポート・メッセージ」を参照してください。
図10-8のように、アダプタ構成ウィザードを介して送信メッセージのフォーマットを指定できます。次のメッセージ・フォーマットがサポートされています。
フォーマット名なし(デフォルト)
コマンド・サーバー・リクエスト/リプライ・メッセージ
タイプ1コマンド・リプライ・メッセージ
タイプ2コマンド・リプライ・メッセージ
配信不能ヘッダー
イベント・メッセージ
プログラム可能なコマンド・フォーマットによるユーザー定義メッセージ
文字のみで構成されるメッセージ
トリガー・メッセージ
転送キュー・ヘッダー
図10-8のように、アダプタ構成ウィザードを使用して送信メッセージの有効期限を指定できます。メッセージの有効期限後は、キュー・マネージャによりメッセージが破棄されます。
メッセージに有効期限通知が設定されている場合は、メッセージが破棄されるときに通知が生成されます。この通知は、replyToQueue
パラメータで指定されたキューに送信されます。デフォルトでは、expiryフィールドにNEVER
が設定されます。
図10-8のように、アダプタ構成ウィザードを介して送信メッセージの優先度を指定できます。優先度の範囲は0(最低)から9(最高)までです。また、メッセージの優先度を、宛先キューで定義されているデフォルトの優先度属性から取得するように指定することも可能です。デフォルトでは、メッセージ優先度としてAS_Q_DEF
が設定されます。
図10-8のように、アダプタ構成ウィザードを介して送信メッセージの永続性を指定できます。メッセージの永続性が設定されていない場合は、キュー・マネージャの再起動時またはシステム障害の発生時にメッセージが消失します。メッセージの永続性をtrue
に設定すると、システム障害が発生したりキュー・マネージャが再起動してもメッセージは消失しません。メッセージの永続性を、宛先キューで定義されているデフォルトの優先度属性から取得するように指定することも可能です。永続メッセージは、アダプタによってログ・ファイルとキュー・データ・ファイルに書き込まれます。障害後にキュー・マネージャが再起動すると、これらの永続メッセージが各ファイルからリカバリされます。
注意: 前述のメッセージ・プロパティはすべて、実行時にメッセージ・ヘッダーを介して指定できます。これらのプロパティにはassignアクティビティを使用して値を割り当てることができます。 |
リクエスト-リプライ相互作用でリクエストにレスポンスをマッピングするには、相関付けが必要です。各MQ Seriesリクエスト・メッセージには、メッセージIDと相関IDが含まれています。アプリケーションは、Oracle BPEL PMからリクエスト・メッセージを受信すると、レスポンス・メッセージに対して定義されている相関スキーマをチェックします。アプリケーションでは、相関スキーマに基づいてレスポンス・メッセージのメッセージIDと相関IDが生成されます。
図10-15に示すアダプタ構成ウィザードの「レスポンス」ページでは、レスポンス・メッセージの相関スキーマを指定できます。
図10-15に示す「メッセージID」ボックスには、レスポンス・メッセージのメッセージIDについて次のオプションが用意されています。
レスポンス・メッセージの新規メッセージIDの生成
リクエスト・メッセージのメッセージIDを使用
同様に、図10-15に示す「相関ID」ボックスには、レスポンス・メッセージの相関IDについて次のオプションが用意されています。
リクエスト・メッセージのメッセージIDを使用
リクエスト・メッセージの相関IDを使用
Oracle MQ Seriesアダプタでは、メッセージを複数のキューにエンキューできます。
「操作タイプ」ページで「MQにメッセージを蓄積」オプションを選択した場合に、複数のキューがあると、自動的にJCAファイルにDistributionList
パラメータが追加されます。
Oracle MQ Seriesアダプタでは、送信メッセージに各種の確認メッセージを設定できます。これらの確認メッセージはレポート・メッセージと呼ばれます。レポート・メッセージが生成されるのは、その生成基準が満たされる場合のみです。メッセージをキューにエンキューするときに、複数タイプのレポート・メッセージをリクエストできます。レポート・メッセージをリクエストする場合は、レポート・メッセージの送信先となるキュー名を指定する必要があります。このキューはreplyTo
キューと呼ばれます。レポート・メッセージは、キュー・マネージャ、メッセージ・チャネルまたはアプリケーションで生成できます。
Oracle MQ Seriesアダプタでは、次のメッセージ・レポートがサポートされます。
「着信時の確認」(COA)メッセージは、メッセージがターゲット・キュー・マネージャに送信されたことを示します。COAメッセージはキュー・マネージャにより生成されます。このメッセージ・レポートは、図10-14に示したアダプタ構成ページの「レポート」ページで選択できます。
「送信時の確認」(COD)メッセージは、メッセージが受信側アプリケーションにより受信されたことを示します。CODメッセージはキュー・マネージャにより生成されます。このメッセージ・レポートは、図10-14に示した「レポート」ページで選択できます。
例外レポートが生成されるのは、メッセージを指定の宛先キューに送信できない場合です。例外レポートは、メッセージ・チャネルにより生成されます。このメッセージ・レポートは、図10-14に示したアダプタ構成ページの「レポート」ページで選択できます。
有効期限レポートは、メッセージが取得される前に指定の有効期限が経過したために、メッセージが破棄されたことを示します。有効期限レポートは、キュー・マネージャにより生成されます。このメッセージ・レポートは、図10-14に示したアダプタ構成ページの「レポート」ページで選択できます。
肯定アクション通知(PAN)は、リクエストが正常に処理されたことを示します。つまり、メッセージでリクエストされたアクションが正常に実行されたことを意味します。このタイプのレポートは、アプリケーションにより生成されます。
否定アクション通知(NAN)は、リクエストが正常に処理されなかったことを示します。つまり、メッセージでリクエストされたアクションが正常に実行されなかったことを意味します。このタイプのレポートは、アプリケーションにより生成されます。
PANとNANを除き、前述のすべてのレポート・メッセージについて、オリジナル・メッセージの全体または一部を含めるか、まったく含めないかを指定できます。アダプタ構成ウィザードで次のいずれかのオプションを選択できます。
オリジナル・メッセージのデータなし
オリジナル・メッセージの最初の100バイトのデータ
オリジナル・メッセージ全体
メッセージ配信失敗オプションは、リモート・キューに対してのみサポートされ、通常のキューではサポートされません。Oracle MQ Seriesアダプタでは、メッセージを宛先キューに配信できなかった場合に実行するアクションを指定できます。次のいずれかを指定できます。
メッセージを配信不能キューに蓄積します
これはデフォルト・アクションです。宛先キューに配信できなかったメッセージは配信不能キューに蓄積されます。送信者からリクエストされた場合は、レポート・メッセージが生成されます。
メッセージの破棄
これは、宛先キューに配信できないメッセージを破棄する必要があることを示します。送信者からリクエストされた場合は、レポート・メッセージが生成されます。
アダプタ構成ウィザードで「MQにメッセージを蓄積」オプションを選択すると、これらのオプションを指定できます。
Oracle MQ Seriesアダプタでは、インバウンド相互作用とアウトバウンド相互作用の両方でメッセージのセグメンテーションがサポートされています。セグメンテーションが必要になるのは、メッセージ・サイズがキューの許容メッセージ・サイズよりも大きい場合です。物理メッセージは2つ以上の論理メッセージに分割されます。すべての論理メッセージには、同じグループIDと順序番号およびオフセットが付きます。
インバウンド相互作用の場合、セグメンテーションは本来Oracle MQ Seriesアダプタでサポートされています。Oracle MQ Seriesアダプタでは、すべての論理メッセージが順序番号順にデキューされてから、単一メッセージがXMLとしてOracle BPEL PMまたはメディエータにパブリッシュされます。
「必要な場合、メッセージをセグメント化できます」オプションを使用すると、アウトバウンド相互作用についてメッセージをセグメント化できます。このオプションは、アダプタ構成ウィザードの「レスポンス」ページに表示されます。
メッセージは、サイズがキューに設定された上限を超えるかどうかに基づいてセグメント化されます。
Oracle MQ Seriesアダプタは、CICSサーバーからのメッセージの送受信をサポートします。インバウンド方向では、CICSサーバーからのインバウンド・メッセージは通常メッセージと同様にデキューされます。アウトバウンド方向では、メッセージにCICSフォーマットを使用する必要があります。次の例に、アウトバウンドCICSメッセージ・フォーマットのサンプル・スキーマ・ファイルを示します。
<?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>
デフォルトでは、Oracle MQ Seriesアダプタは次のリストに示すエンコーディングをサポートしています。MQ Seriesメッセージ・エンコーディングとJavaエンコーディング、およびMQ Seriesメッセージ・エンコーディングとJavaエンコーディング間のマッピングを示します。Oracle MQ Seriesアダプタでサポートされるエンコーディングのリストは、次のとおりです。
ibm037
ibm437
ibm500
ibm819
Unicode
UTF8
ibm273
ibm277
ibm278
ibm280
ibm284
ibm285
ibm297
ibm420
ibm424
ibm737
ibm775
ibm813
ibm838
ibm850
ibm852
ibm855
ibm856
ibm857
ibm860
ibm861
ibm862
ibm863
ibm864
ibm866
ibm868
ibm869
ibm870
ibm871
ibm874
ibm875
ibm912
ibm913
ibm914
ibm915
ibm916
ibm918
ibm920
ibm921
ibm922
ibm930
SJIS
ibm933
ibm935
ibm937
ibm939
ibm942
ibm948
ibm949
ibm950
EUCJIS
ibm964
ibm970
ibm1006
ibm1025
ibm1026
ibm1089
ibm1097
ibm1098
ibm1112
ibm1122
ibm1123
ibm1124
Cp1250
Cp1251
Cp1252
Cp1253
Cp1254
Cp1255
Cp1256
Cp1257
Cp1258
ibm1381
ibm1383
JIS
KSC5601
ibm33722813
GB18030
このリストに示されていないその他の標準Javaエンコーディングのサポートは、次の方法で追加できます。
MQSeriesAdapter.rar
ファイルからMQSeriesAdapter.jar
ファイルを抽出します。
MQSeriesAdapter.jar
ファイルからmq.properties
ファイルを抽出します。
mq.properties
ファイルにエントリを追加します。新しいエンコーディングごとに、mq.properties
ファイルに2つの行(プロパティ)を追加する必要があります。1行はMQ Seriesエンコーディングとそれに対応するJavaエンコーディング、もう1行はJavaエンコーディングとそれに対応するMQ Seriesエンコーディングです。
たとえば、次のibm037
Javaエンコーディング(ibm037(Javaエンコーディング)<->37(MQ Seriesメッセージ・エンコーディング))のサポートを追加するには、mq.properties
ファイルに次の2行を追加する必要があります。
oracle.tip.adapter.mq.encoding.37=ibm037
oracle.tip.adapter.mq.encoding.ibm037=37
このCCDTを使用すると、MQ SeriesアダプタにJNDIを構成している間にプロパティを定義する際に複数の利点があります。
クライアント・チャネル定義表の機能を理解しておくと役に立ちます。
クライアント・チャネル定義表の構成を理解するには、次の基本用語と基本概念を理解しておく必要があります。
チャネル名および接続名: 表内の各定義のチャネル名は、指定された接続名で実行されるリスナーを持つキュー・マネージャのサーバー接続チャネルとまったく同一にする必要があります。たとえば、CCDT内の第1の定義であるchannel.ccdt_qm1
は、localhost(1414)で実行されるリスナーを持つキュー・マネージャのサーバー接続チャネル名になっています。
キュー・マネージャ名: CCDTで定義済のキュー・マネージャ名は、定義されたチャネル名および接続名を持つキュー・マネージャの実際の名前と異なる可能性があります。次の可能性が考えられます。
クライアント・チャネルで定義されているキュー・マネージャ名は、表の第3の定義にあるように実際のキュー・マネージャ名となっています。したがって、ccdt_qm3
は、サーバー接続チャネルとしてchannel.ccdt_qm3
を所有し、さらにlocalhost(3414)でリスニングするリスナーを所有するキュー・マネージャの実際の名前となります。
クライアント・チャネル定義にキュー・マネージャ名が定義されていません。後述のCCDTの例では、定義されたキュー・マネージャ名を持たない表内の第4の定義においてこの状況を確認できます。
CCDT内の2つ以上のクライアント・チャネル・エントリに、定義された同一のキュー・マネージャ名が存在します。この名前は、どのエントリの実際のキュー・マネージャ名とも一致できます。後述の例の第1と第2の定義には、QM
として定義された同じキュー・マネージャ名がありますが、実際は異なるキュー・マネージャをポイントしています。
次の図は、ccdt_qm1からccdt_qm4までの4つのキュー・マネージャに対する接続に定義されたクライアント・チャネルを持つ標準のCCDTを示しています。
一度定義されると、このCCDTはデフォルトで次の場所に存在します。
Windowsの場合
<C:\Program Files\IBM\WebSphere 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 Websphere MQおよびMQアダプタの使用方法の基本理解とCCDTの作成の詳細は、IBM MQ Seriesドキュメントを参照してください。
IBM Websphere MQバージョン6は、CCDT機能が動作するための最低要件となっています。
クライアント・チャネル定義表の構成を理解するには、次の基本用語と基本概念を理解しておく必要があります。
チャネル名および接続名: 表内の各定義のチャネル名は、指定された接続名で実行されるリスナーを持つキュー・マネージャのサーバー接続チャネルとまったく同一にする必要があります。たとえば、CCDT内の第1の定義であるchannel.ccdt_qm1
は、localhost(1414)で実行されるリスナーを持つキュー・マネージャのサーバー接続チャネル名になっています。
キュー・マネージャ名: CCDTで定義済のキュー・マネージャ名は、定義されたチャネル名および接続名を持つキュー・マネージャの実際の名前と異なる可能性があります。次の可能性が考えられます。
クライアント・チャネルで定義されているキュー・マネージャ名は、表の第3の定義にあるように実際のキュー・マネージャ名となっています。したがって、ccdt_qm3
は、サーバー接続チャネルとしてchannel.ccdt_qm3
を所有し、さらにlocalhost(3414)でリスニングするリスナーを所有するキュー・マネージャの実際の名前となります。
クライアント・チャネル定義にキュー・マネージャ名が定義されていません。後述のCCDTの例では、定義されたキュー・マネージャ名を持たない表内の第4の定義においてこの状況を確認できます。
CCDT内の2つ以上のクライアント・チャネル・エントリに、定義された同一のキュー・マネージャ名が存在します。この名前は、どのエントリの実際のキュー・マネージャ名とも一致できます。後述の例の第1と第2の定義には、QM
として定義された同じキュー・マネージャ名がありますが、実際は異なるキュー・マネージャをポイントしています。
次の図は、ccdt_qm1からccdt_qm4までの4つのキュー・マネージャに対する接続に定義されたクライアント・チャネルを持つ標準のCCDTを示しています。
一度定義されると、このCCDTはデフォルトで次の場所に存在します。
Windowsの場合
<C:\Program Files\IBM\WebSphere MQ\qmgrs\QM_NAME\@ipcc\AMQCLCHL.TAB>
UNIXベース・システムの場合
<var/mqm/qmgrs/QM_NAME/@ipcc/AMQCLCHL.TAB>
Oracle MQ Seriesアダプタを使用するための前提条件は、次のとおりです。
IBM WebSphere MQサーバーがインストール済で稼働している必要があります。
キュー・マネージャとサーバー接続チャネルを作成する必要があります。
注意: キューはアプリケーションの要件に基づいて作成する必要があります。 |
Oracle MQ Seriesアダプタを構成する手順は、次のとおりです。
この項に示す手順は、Oracle MQ Seriesアダプタを使用する前に1度実行します。
Oracle MQ Series 6アダプタのクラスパスに正しいjarプロパティを追加するには、次のjarを<DOMAIN_HOME>/libフォルダにコピーします。
com.ibm.mq.jar
com.ibm.mqetclient.jar
(XAによる方法の場合)
Oracle MQ Series 7アダプタのクラスパスに正しい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による方法の場合)
また、Oracle MQ Series 7アダプタを使用している場合は、サーバー接続チャネルの新しい会話の共有プロパティをゼロに設定する必要があります。
com.ibm.mqetclient.jar
は、MQ Series 7.5サーバーでは必要ありません。
注意: WebSphere Application ServerプラットフォームのMQSeries 7.5で実行されるMQアダプタの場合は、MQSeries 7.0.xから必要なjarを追加する必要があります。 |
次の手順に従って、Oracle WebLogic Server管理コンソールに新しいJNDIエントリを追加できます。
ユーザー名とパスワードを使用して次のURLにログインし、Oracle WebLogic Server管理コンソールを開きます。
http://<localhost>:port/console
図10-33に示すように、ホーム・ページが表示されます。
左ペインの「ドメイン構造」で、「デプロイメント」をクリックします。「デプロイメントの概要」ページが表示されます。
「MQSeriesAdapter」をクリックします。図10-34に示すように、「MQSeriesAdapterの設定」ページが表示されます。
「構成」タブをクリックします。図10-35に示すように、「構成」サブメニュー・オプションが表示されます。
図10-35 「MQSeriesAdapterの設定」ページ - 「構成」サブメニュー・オプション
「アウトバウンド接続プール」をクリックします。図10-36に示すように、「アウトバウンド接続プールの構成表」が表示されます。
「新規作成」をクリックします。図10-37に示すように、「新しいアウトバウンド接続の作成」ページが表示されます。
「javax.resource.cci.ConnectionFactory」オプションを選択し、「次へ」をクリックします。
図10-38に示すように、「JNDI名」フィールドに値(eis/MQ/MQAdapter
など)を入力します。
「終了」をクリックします。「デプロイメント・プラン保存アシスタント」ページが表示されます。
「OK」をクリックします。JNDI名が正常に作成されました。
Oracle WebLogic Server管理コンソールでプロパティをいくつか変更して、Oracle MQ Seriesアダプタ用の接続のバインディング・モードを有効化できます。
バインディング・モードを有効化する手順は、次のとおりです。
パスワード資格証明を使用して、Oracle WebLogic Server管理コンソールにログインします。
左ペインの「ドメイン構造」で、「デプロイメント」をクリックします。「デプロイメントの概要」ページが表示されます。
「MQSeriesAdapter」をクリックします。「MQSeriesAdapterの設定」ページが表示されます。
「構成」タブをクリックします。「構成」サブメニュー・オプションが表示されます。
「アウトバウンド接続プール」をクリックします。「アウトバウンド接続プールの構成表」が表示されます。
「javax.resource.cci.ConnectionFactory」の横にある「+」アイコンをクリックします。JNDIのリストが表示されます。
「eis/MQ/MQAdapter」を選択します。これは、第10.5.2項「JNDIエントリの追加」で作成したJNDIです。図10-39に示すように、24のプロパティのリストを含んだ「アウトバウンド接続のプロパティ」ページが表示されます。
次の説明に従ってパラメータを設定します。
hostName: この値は常に空白にする必要があります。
portNumber: この値には未使用のポート番号を指定する必要があります。たとえば、44888を指定します。
channelName: この値は常に空白にする必要があります。
queueManagerName: この値は有効なキュー・マネージャ名です。
Oracle MQ Seriesアダプタの接続用のバインディング・モードが有効化されました。
この項には、次の項目が含まれます。
この使用例では、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アプリケーションを作成する必要があります。使用例のアプリケーションとプロジェクトを作成する手順は、次のとおりです。
JDeveloperで、「ファイル」をクリックして「新規」を選択します。
「新規ギャラリ」ダイアログが表示されます。
「一般」ノードを開いて「アプリケーション」カテゴリを選択します。
「項目」リストから「汎用アプリケーション」を選択し、「OK」をクリックします。汎用アプリケーションの作成ウィザードが表示されます。
図10-40に示すように、「アプリケーションの名前付け」画面で、「アプリケーション名」フィールドにDe-queueEn-queue
と入力して「次へ」をクリックします。「プロジェクトの名前付け」画面が表示されます。
図10-41に示すように、「プロジェクト名」フィールドにDe-queueEn-queueComposite
と入力し、「選択可能」リストから「SOA」を選択して右矢印ボタンをクリックします。
「次へ」をクリックします。「SOA設定の設定」画面が表示されます。
図10-42に示すように、「コンポジット・テンプレート」リストで「BPELを使用するコンポジット」を選択して「終了」をクリックします。「BPELプロセスの作成」ダイアログが表示されます。
図10-43に示すように、「名前」フィールドにBPELdequeueenqueue
と入力し、「テンプレート」ボックスから「サービスを後で定義」を選択します。
「OK」をクリックします。図10-44に示すように、De-queueEn-queueアプリケーションとDe-queueEn-queueプロジェクトが設計領域に表示されます。
address-csv.xsd
ファイルおよびaddress-fixedLength.xsd
ファイルをプロジェクトのxsdフォルダにコピーします(これらのファイルの場所は、第10.6.1.1項「前提条件」を参照)。
次の手順を実行し、メッセージをキューからデキューするアダプタ・サービスを作成します。
「コンポーネント・パレット」から、「MQアダプタ」を「公開されたサービス」スイムレーンにドラッグ・アンド・ドロップします。アダプタ構成ウィザードの「ようこそ」ページが表示されます。
「次へ」をクリックします。「サービス名」ページが表示されます。
図10-45に示すように、「サービス名」フィールドにInboundService
と入力して「OK」をクリックします。「MQ Series接続」ページが表示されます。
図10-46に示すように、MQ Series接続のデフォルトのJNDI名を受け入れて「次へ」をクリックします。「アダプタ・インタフェース」ページが表示されます。
図10-47に示すように、「操作およびスキーマから定義(後で指定)」を選択して「次へ」をクリックします。「操作タイプ」ページが表示されます。
図10-48に示すように、「MQからメッセージを取得」を選択して「次へ」をクリックします。「MQからメッセージを取得」ページが表示されます。
図10-49に示すように、「キュー名」フィールドにtest_in
と入力して「次へ」をクリックします。「メッセージ」ページが表示されます。
「URL」フィールドの端にある「参照」をクリックします。「タイプ・チューザ」ダイアログが表示されます。
図10-50に示すように、「プロジェクトのスキーマ・ファイル」、「address-csv.xsd」および「Root-Element」を順番にクリックします。
「OK」をクリックします。図10-51に示すように、「メッセージ」ページの「URL」フィールドにaddress-csv.xsdファイルが表示されます。
「次へ」をクリックします。「終了」ページが表示されます。
「終了」をクリックします。インバウンド・アダプタ・サービスの構成が完了し、図10-52に示すように、「composite.xml」ページが表示されます。
次の手順を実行し、メッセージをエンキューするアダプタ・サービスを作成します。
「コンポーネント・パレット」から、「MQアダプタ」を「外部参照」スイムレーンにドラッグ・アンド・ドロップします。アダプタ構成ウィザードの「ようこそ」ページが表示されます。
「次へ」をクリックします。「サービス名」ページが表示されます。
「サービス名」フィールドにOutboundService
と入力して「OK」をクリックします。「MQ Series接続」ページが表示されます。
図10-46に示すように、MQ Series接続のデフォルトのJNDI名を受け入れて「次へ」をクリックします。「アダプタ・インタフェース」ページが表示されます。
図10-47に示すように、「操作およびスキーマから定義(後で指定)」を選択して「次へ」をクリックします。「操作タイプ」ページが表示されます。
「MQにメッセージを蓄積」を選択して「次へ」をクリックします。「MQにメッセージを蓄積」ページが表示されます。
「キュー名」フィールドにtest_out
と入力して「次へ」をクリックします。図10-53に示すように、「詳細オプション」ページが表示されます。
デフォルトを受け入れて「次へ」をクリックします。「メッセージ」ページが表示されます。
「URL」フィールドの端にある「参照」をクリックします。「タイプ・チューザ」ダイアログが表示されます。
「プロジェクトのスキーマ・ファイル」、「address-fixedLength.xsd」および「Root-Element」を順番に選択して「OK」をクリックします。「メッセージ」ページの「URL」フィールドにaddress-fixedLength.xsdファイルが表示されます。
「次へ」をクリックします。「終了」ページが表示されます。
「終了」をクリックします。アウトバウンド・アダプタ・サービスの構成が完了し、図10-54に示すように、「composite.xml」ページが表示されます。
作成した3つのコンポーネント(インバウンド・アダプタ・サービス、BPELプロセスおよびアウトバウンド・アダプタ参照)をアセンブルまたは接続する必要があります。コンポーネントを接続する手順は、次のとおりです。
「公開されたサービス」領域にあるInboundService内の小さい三角形を、「コンポーネント」領域のBPELプロセス内に緑の三角形として表示されるドロップ・ゾーンにドラッグします。
「コンポーネント」領域にあるBPELプロセス内の小さい三角形を、「外部参照」領域のOutboundService内に緑の三角形として表示されるドロップ・ゾーンにドラッグします。
JDeveloperのcomposite.xmlが図10-55のように表示されます。
「ファイル」、「すべて保存」を順番にクリックします。
「BPELdequeueenqueue」をダブルクリックします。「BPELdequeueenqueue.bpel」ページが表示されます。
「コンポーネント・パレット」から、receive、transformおよびinvokeアクティビティを「コンポーネント」領域に順番にドラッグ・アンド・ドロップします。
図10-56に示すように、JDeveloperの「BPELdequeueenqueue.bpel」ページが表示されます。
receiveアクティビティをInboundServiceにドラッグ・アンド・ドロップします。「Receive」ダイアログが表示されます。
「変数」フィールドの端に表示される「変数の自動作成」アイコンをクリックします。「変数の作成」ダイアログが表示されます。
デフォルトを受け入れて「OK」をクリックします。
「インスタンスの作成」ボックスを選択して「OK」をクリックします。
invokeアクティビティをOutboundServiceにドラッグ・アンド・ドロップします。「Invoke」ダイアログが表示されます。
「入力変数」フィールドの端に表示される「入力変数の自動作成」アイコンをクリックします。
デフォルトを受け入れて「OK」をクリックします。「Invoke」ダイアログが表示されます。
「OK」をクリックします。
transformアクティビティをダブルクリックします。「Transform」ダイアログが表示されます。
「作成... (Alt + N)」アイコンをクリックします。「ソース変数」ダイアログが表示されます。
デフォルトを受け入れて「OK」をクリックします。
ターゲットとしてinvoke変数を選択して「OK」をクリックします。「Transformation_xsl」ページが表示されます。
「ソース」ペインのtns:Root-Elementを「ターゲット」ペインのfix:Root-Elementにドラッグ・アンド・ドロップします。「自動マップ・プリファレンス」ダイアログが表示されます。
「OK」をクリックします。図10-57に示すように、「Transformation_xsl」ページが表示されます。
図10-58に示す「BPELdequeueenqueue.bpel」ページが表示されます。
前述の手順で作成したSOAプロジェクトおよびアプリケーションについて、アプリケーション・プロファイルをデプロイする必要があります。
JDeveloperを使用してアプリケーション・プロファイルをデプロイする方法の詳細は、第2.7項「JDeveloperからのOracle JCAアダプタ・アプリケーションのデプロイ」を参照してください。
アプリケーション・サーバー接続も作成する必要があります。アプリケーション・サーバー接続を作成する方法の詳細は、第2.6項「Oracle JCAアダプタ用のアプリケーション・サーバー接続の作成」を参照してください。
Fusion Middleware Controlコンソールを使用して、デプロイ済のSOAコンポジットを監視できます。次の手順を実行します。
ユーザー名とパスワードを使用してhttp://servername:portnumber/emにログインします。「Oracle Enterprise Manager Fusion Middleware Control」ページが表示されます。
左ペインで、「SOA」、「soa-infra (soa_server1)」の順にナビゲートします。デプロイされている全コンポジットのリストが表示されます。
「De-queueEn-queueComposite[1.0]」をクリックします。「De-queueEn-queueComposite[1.0]」ページが表示されます。
data.txtファイルをコピーしてtest_inキューに入れます。
少し待ってからFusion Middleware Controlコンソールをリフレッシュします。インスタンスがコンソールに表示されます。これは、発生した処理のためトリガーされたインスタンスです。
「インスタンス」タブをクリックします。
このデプロイメントに関連付けられているインスタンスをクリックします。「フローのトレース」ページが表示されます。
「BPELdequeueenqueue」コンポーネント・インスタンスをクリックします。「監査証跡」ページが表示されます。
「フロー」タブをクリックしてインスタンスをデバッグします。BPELプロセス・インスタンスのフローが表示されます。
アクティビティをクリックして関連するペイロードの詳細を表示します。
この使用例では、インバウンドのOracle MQ SeriesアダプタがMQ Seriesのインバウンド・キューtest_in
からリクエスト・メッセージをデキューして、BPELプロセスにパブリッシュします。Oracle MQ Seriesアダプタは、BPELプロセスからのレスポンスを待機します。レスポンスを受信すると、Oracle MQ Seriesアダプタはリクエスト・メッセージのreplyToQueueName
キューで指定されたMQ Seriesキューにレスポンス・メッセージをエンキューします。この使用例は、次の項で構成されています。
この例は、基本的なBPELコンストラクト(アクティビティやパートナ・リンクなど)と、BPELプロセスを作成およびデプロイするJDeveloper環境をよく理解していることを前提としています。
第10.5項「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アプリケーションを作成する必要があります。使用例のアプリケーションとプロジェクトを作成する手順は、次のとおりです。
JDeveloperで、「ファイル」をクリックして「新規」を選択します。
「新規ギャラリ」ダイアログが表示されます。
「一般」ノードを開いて「アプリケーション」カテゴリを選択します。
「項目」リストから「汎用アプリケーション」を選択し、「OK」をクリックします。汎用アプリケーションの作成ウィザードが表示されます。
「アプリケーションの名前付け」画面で、「アプリケーション名」フィールドにSyncReqRes
と入力して「次へ」をクリックします。「プロジェクトの名前付け」画面が表示されます。
「プロジェクト名」フィールドにSync_ReqRes
と入力し、「選択可能」リストから「SOA」を選択して右矢印ボタンをクリックします。
「次へ」をクリックします。「SOA設定の設定」画面が表示されます。
「コンポジット・テンプレート」リストから「BPELを使用するコンポジット」を選択して「終了」をクリックします。「BPELプロセスの作成」ダイアログが表示されます。
JDeveloperのアプリケーション・ナビゲータに新しいアプリケーションとプロジェクトが反映され、「設計」タブに空白のパレットが表示されます。
「名前」フィールドにBPELsyncreqres
と入力し、「テンプレート」ボックスから「サービスを後で定義」を選択します。
「OK」をクリックします。図10-59に示すように、SyncReqResアプリケーションとSync_ReqResプロジェクトが設計領域に表示されます。
次の手順を実行し、メッセージをキューからデキューするアダプタ・サービスを作成します。
「コンポーネント・パレット」から、「MQアダプタ」を「公開されたサービス」スイムレーンにドラッグ・アンド・ドロップします。アダプタ構成ウィザードの「ようこそ」ページが表示されます。
「次へ」をクリックします。「サービス名」ページが表示されます。
「サービス名」フィールドにinbound_reqres
と入力して「次へ」をクリックします。「MQ Series接続」ページが表示されます。
MQ Series接続JNDI名のデフォルトJNDI名を受け入れて「次へ」をクリックします。「アダプタ・インタフェース」ページが表示されます。
「操作およびスキーマから定義(後で指定)」を選択して「次へ」をクリックします。「操作タイプ」ページが表示されます。
図10-18に示すように、「MQからメッセージを取得し、リプライ/レポートを送信」を選択し、「同期」を選択して「次へ」をクリックします。「MQからメッセージを取得し、リプライ/レポートを送信」ページが表示されます。
「メッセージ・タイプ」ボックスで「標準」を選択し、「キュー名」フィールドにtest_in
と入力します。
「次へ」をクリックします。「レスポンス」ページが表示されます。
デフォルトを受け入れて「次へ」をクリックします。「メッセージ」ページが表示されます。
「プロジェクトのスキーマ・ファイル」、「address-csv.xsd」および「Root-Element」を順番に選択して「OK」をクリックします。「メッセージ」ページの「URL」フィールドにaddress-csv.xsdファイルが表示されます。
「メッセージ・スキーマの送信」グループで、「URL」フィールドの端にある「参照」をクリックします。「タイプ・チューザ」ダイアログが表示されます。
「プロジェクトのスキーマ・ファイル」、「address-fixedLength.xsd」および「Root-Element」を順番に選択して「OK」をクリックします。「メッセージ」ページの「URL」フィールドにaddress-fixedLength.xsdファイルが表示されます。
「次へ」をクリックします。「終了」ページが表示されます。
「終了」をクリックします。インバウンド・アダプタ・サービスの構成が完了し、図10-60に示すように、「composite.xml」ページが表示されます。
「ファイル」、「すべて保存」を順番にクリックします。
コンポーネントを接続する手順は、次のとおりです。
inbound_reqres
アダプタ・サービスをBPELsyncreqres
BPELプロセスにドラッグ・アンド・ドロップします。
「BPELsyncreqres」をダブルクリックします。「BPELsyncreqres.bpel」ページが表示されます。
「コンポーネント・パレット」から、receive、transformおよびreplyアクティビティを「コンポーネント」領域に順番にドラッグ・アンド・ドロップします。
receiveアクティビティをinbound_reqres
アダプタ・サービスにドラッグ・アンド・ドロップします。「Receive」ダイアログが表示されます。
「名前」フィールドにReadMsg
と入力します。
「変数」フィールドの端に表示される「変数の自動作成」アイコンをクリックします。「変数の作成」ダイアログが表示されます。
デフォルトを受け入れて「OK」をクリックします。
「Receive」ダイアログで、「インスタンスの作成」ボックスを選択して「OK」をクリックします。
replyアクティビティをinbound_reqres
アダプタ・サービスにドラッグ・アンド・ドロップします。「Reply」ダイアログが表示されます。
「名前」フィールドにReplyMsg
と入力します。
「変数」フィールドの端に表示される「変数の自動作成」アイコンをクリックします。「変数の作成」ダイアログが表示されます。
デフォルトを受け入れて「OK」をクリックします。この変数が「Reply」ダイアログに表示されます。
「OK」をクリックします。
transformアクティビティをダブルクリックします。「Transform」ダイアログが表示されます。
「+」アイコンをクリックします。「ソース変数」ダイアログが表示されます。
「ソース変数」リストで、「ReadMsg_DequeueEnqueue_InputVariable」を選択して「OK」をクリックします。
「ターゲット変数」リストで「ReplyMsg_DequeueEnqueue_OutputVariable」を選択します。
「マッピングの作成」アイコンをクリックします。図10-61に示すように、「Transformation.xsl」ページが表示されます。
「<sources>」パネルから、「tns:Root-Element」を「<target>」パネルの「fix:Root-Element」にドラッグします。「自動マップ・プリファレンス」ダイアログが表示されます。
「OK」をクリックします。図10-62に示すように、JDeveloperの「BPELsyncreqres.bpel」ページが表示されます。
前述の手順で作成したSOAプロジェクトおよびアプリケーションについて、アプリケーション・プロファイルをデプロイする必要があります。
JDeveloperを使用してアプリケーション・プロファイルをデプロイするには、第2.7項「JDeveloperからのOracle JCAアダプタ・アプリケーションのデプロイ」を参照してください。
アプリケーション・サーバー接続も作成する必要があります。アプリケーション・サーバー接続を作成する方法の詳細は、第2.6項「Oracle JCAアダプタ用のアプリケーション・サーバー接続の作成」を参照してください。
Fusion Middleware Controlコンソールを使用して、デプロイ済のSOAコンポジットを監視できます。次の手順を実行します。
ユーザー名とパスワードを使用してhttp://servername:portnumber/emにログインします。「Oracle Enterprise Manager Fusion Middleware Control」ページが表示されます。
左ペインで、「SOA」、「soa-infra (soa_server1)」の順にナビゲートします。デプロイされている全コンポジットのリストが表示されます。
「Sync_ReqRes[1.0]」をクリックします。「Sync_ReqRes[1.0]」ページが表示されます。
data.txt
ファイルのコンテンツでMQメッセージを作成し、replyToQueueNameをtest_reply
に設定します。このメッセージをtest_in
キューに蓄積します。
少し待ってからFusion Middleware Controlコンソールをリフレッシュします。インスタンスがコンソールに表示されます。これは、発生した処理のためトリガーされたインスタンスです。
「インスタンス」タブをクリックします。
このデプロイメントに関連付けられているインスタンスをクリックします。「フローのトレース」ページが表示されます。
「BPELsyncreqres」コンポーネント・インスタンスをクリックします。「監査証跡」ページが表示されます。
「フロー」タブをクリックしてインスタンスをデバッグします。BPELプロセス・インスタンスのフローが表示されます。
アクティビティをクリックして関連するペイロードの詳細を表示します。
この使用例では、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アプリケーションを作成する必要があります。使用例のアプリケーションとプロジェクトを作成する手順は、次のとおりです。
JDeveloperで、「ファイル」をクリックして「新規」を選択します。
「新規ギャラリ」ダイアログが表示されます。
「一般」ノードを開いて「アプリケーション」カテゴリを選択します。
「項目」リストから「汎用アプリケーション」を選択し、「OK」をクリックします。汎用アプリケーションの作成ウィザードが表示されます。
「アプリケーションの名前付け」画面で、「アプリケーション名」フィールドにSync-Req-Rep
と入力して「次へ」をクリックします。「プロジェクトの名前付け」画面が表示されます。
「プロジェクト名」フィールドにSync-Req-RepComposite
と入力し、「選択可能」リストから「SOA」を選択して右矢印ボタンをクリックします。
「次へ」をクリックします。「SOA設定の設定」画面が表示されます。
「コンポジット・テンプレート」リストから「BPELを使用するコンポジット」を選択して「終了」をクリックします。「BPELプロセスの作成」ダイアログが表示されます。
「名前」フィールドにBPELSyncreqrep
と入力し、「テンプレート」ボックスから「サービスを後で定義」を選択します。
「OK」をクリックします。図10-63に示すように、Sync-Req-RepアプリケーションとSync-Req-RepCompositeプロジェクトが設計領域に表示されます。
次の手順を実行し、メッセージをキューからデキューするアダプタ・サービスを作成します。
「コンポーネント・パレット」から、「MQアダプタ」を「公開されたサービス」スイムレーンにドラッグ・アンド・ドロップします。アダプタ構成ウィザードの「ようこそ」ページが表示されます。
「次へ」をクリックします。「サービス名」ページが表示されます。
「サービス名」フィールドにInboundReqRepService
と入力して「次へ」をクリックします。「MQ Series接続」ページが表示されます。
MQ Series接続用のデフォルトJNDI名を受け入れて「次へ」をクリックします。「アダプタ・インタフェース」ページが表示されます。
「操作およびスキーマから定義(後で指定)」を選択して「次へ」をクリックします。「操作タイプ」ページが表示されます。
図10-18に示すように、「MQからメッセージを取得し、リプライ/レポートを送信」を選択し、「操作名」ボックスで「同期」を選択して「次へ」をクリックします。「MQからメッセージを取得し、リプライ/レポートを送信」ページが表示されます。
「メッセージ・タイプ」リストで「標準」を選択し、「キュー名」フィールドにtest_in
と入力し、「スキーマ・オプション」ボックスで「他のスキーマを選択します」を選択して「次へ」をクリックします。「レスポンス」ページが表示されます。
デフォルトを受け入れて「次へ」をクリックします。「メッセージ」ページが表示されます。
「メッセージ・スキーマの取得」ボックスで、「URL」フィールドの端に表示される「参照」をクリックします。「タイプ・チューザ」ダイアログが表示されます。
「プロジェクトのスキーマ・ファイル」、「address-csv.xsd」および「Root-Element」を順番に選択して「OK」をクリックします。「メッセージ」ページの「メッセージ・スキーマの取得」ボックスにaddress-csv.xsdファイルが移入されます。
「メッセージ・スキーマの送信」ボックスで、「URL」フィールドの端に表示される「参照」をクリックします。「タイプ・チューザ」ダイアログが表示されます。
「プロジェクトのスキーマ・ファイル」、「address-fixedLength.xsd」および「Root-Element」を順番に選択して「OK」をクリックします。「メッセージ」ページの「メッセージ・スキーマの送信」ボックスにaddress-fixedLength.xsdファイルが移入されます。
「次へ」をクリックします。「終了」ページが表示されます。
「終了」をクリックします。InboundReqRepServiceアダプタ・サービスの構成が完了し、図10-64に示すように、「composite.xml」ページが表示されます。
リクエスト・メッセージをエンキューし、対応するレスポンス・メッセージ(レポート)をキューからデキューするアダプタ・サービスを作成する手順は、次のとおりです。
「コンポーネント・パレット」から、「MQアダプタ」を「外部参照」スイムレーンにドラッグ・アンド・ドロップします。アダプタ構成ウィザードの「ようこそ」ページが表示されます。
「次へ」をクリックします。「サービス名」ページが表示されます。
「サービス名」フィールドにOutboundReqRepService
と入力して「OK」をクリックします。「MQ Series接続」ページが表示されます。
デフォルトを受け入れて「次へ」をクリックします。「アダプタ・インタフェース」ページが表示されます。
「操作およびスキーマから定義(後で指定)」を選択して「次へ」をクリックします。「操作タイプ」ページが表示されます。
「MQにメッセージを送信し、リプライ/レポートを取得」を選択し、「操作名」ボックスで「同期」を選択して「次へ」をクリックします。「MQにメッセージを送信し、リプライ/レポートを取得」ページが表示されます。
「キュー名」フィールドにtest1
と入力して「次へ」をクリックします。「レスポンス」ページが表示されます。
「返信先キュー名」フィールドにキュー名(ReplyQ
など)を入力し、「レスポンス待機間隔」オプションを選択して値を入力し、「空のレスポンス・メッセージを許可」オプションを選択します。
「次へ」をクリックします。「詳細オプション」ページが表示されます。
デフォルト値を受け入れて「次へ」をクリックします。「メッセージ」ページが表示されます。
「メッセージ・スキーマの取得」ボックスで、「URL」フィールドの端に表示される「参照」をクリックします。「タイプ・チューザ」ダイアログが表示されます。
「プロジェクトのスキーマ・ファイル」、「address-csv.xsd」および「Root-Element」を順番に選択して「OK」をクリックします。「メッセージ」ページの「メッセージ・スキーマの取得」ボックスにaddress-csv.xsdファイルが移入されます。
「メッセージ・スキーマの送信」ボックスで、「URL」フィールドの端に表示される「参照」をクリックします。「タイプ・チューザ」ダイアログが表示されます。
「プロジェクトのスキーマ・ファイル」、「address-fixedLength.xsd」および「Root-Element」を順番に選択して「OK」をクリックします。「メッセージ」ページの「メッセージ・スキーマの送信」ボックスにaddress-fixedLength.xsdファイルが移入されます。
「次へ」をクリックします。「終了」ページが表示されます。
「終了」をクリックします。OutboundReqRepServiceサービスの構成が完了し、図10-65に示すように、「composite.xml」ページが表示されます。
作成した3つのコンポーネント(InboundReqRepService、BPELSyncreqrepおよびOutboundReqRepService)をアセンブルまたは接続する必要があります。コンポーネントを接続する手順は、次のとおりです。
「公開されたサービス」領域にあるInboundReqRepServiceサービス内の小さい三角形を、「コンポーネント」領域のBPELSyncreqrep内に緑の三角形として表示されるドロップ・ゾーンにドラッグします。
「コンポーネント」領域にあるBPELSyncreqrep内の小さい三角形を、「外部参照」領域のOutboundReqRepService内に緑の三角形として表示されるドロップ・ゾーンにドラッグします。
同様に、「コンポーネント」領域にあるBPELSyncreqrep内の小さい三角形を、「外部参照」領域のOutboundReqRepService内のドロップ・ゾーンにドラッグします。
JDeveloperのcomposite.xmlが図10-66のように表示されます。
「ファイル」、「すべて保存」を順番にクリックします。
「BPELSyncreqrep」をダブルクリックします。「BPELSyncreqrep.bpel」ページが表示されます。
「コンポーネント・パレット」から、receive、transform、invoke、assignおよびreplyアクティビティを「コンポーネント」領域に順番にドラッグ・アンド・ドロップします。図10-67に示すように、JDeveloperの「BPELSyncreqrep.bpel」ページが表示されます。
receiveアクティビティをInboundReqRepService
にドラッグ・アンド・ドロップします。「Receive」ダイアログが表示されます。
「変数」フィールドの端に表示される「変数の自動作成」アイコンをクリックします。「変数の作成」ダイアログが表示されます。
デフォルトを受け入れて「OK」をクリックします。
図10-68 に示すように、「インスタンスの作成」ボックスを選択して「OK」をクリックします。
replyアクティビティをInboundReqRepServiceにドラッグ・アンド・ドロップします。「Reply」ダイアログが表示されます。
「変数の自動作成」アイコンをクリックして変数を作成し、「OK」をクリックします。図10-69に示すように、「Reply」ダイアログが表示されます。
invokeアクティビティをOutboundReqRepServiceサービスにドラッグ・アンド・ドロップします。「Invoke」ダイアログが表示されます。
「入力変数」フィールドの端に表示される「入力変数の自動作成」アイコンをクリックします。「変数の作成」ダイアログが表示されます。
「OK」をクリックします。
同様に、出力変数を作成します。デフォルトを受け入れて「OK」をクリックします。図10-70に示すように、「Invoke」ダイアログが表示されます。
「OK」をクリックします。
transformアクティビティをダブルクリックします。「Transform」ダイアログが表示されます。
「+」アイコンをクリックし、ソース変数として「Receive_1_DequeueEnqueue_InputVariable」を選択します。また、図10-71に示すように、ターゲット変数としてInvoke_1_EnqueueDequeue_InputVariableを選択します。
「マッピングの作成」をクリックします。「Transformation_1.xsl」ページが表示されます。
「<sources>」パネルから、「tns:Root-Element」を「<target>」パネルの「fix:Root-Element」にドラッグ・アンド・ドロップします。「自動マップ・プリファレンス」ダイアログが表示されます。
「OK」をクリックします。図10-72に示すように、「Transformation.xsl」ページにマッピングが表示されます。
「BPELSyncreqrep.bpel」タブをクリックします。
assignアクティビティをダブルクリックします。「Assign」ダイアログが表示されます。
「+」アイコンをクリックして「コピー操作」を選択します。「コピー操作の作成」ダイアログが表示されます。
図10-73に示すように、変数を選択して「OK」をクリックします。
「Assign」ダイアログで「OK」をクリックします。図10-74に示すように、JDeveloperの「BPELSyncreqrep.bpel」ページが表示されます。
前述の手順で作成したSOAプロジェクトおよびアプリケーションについて、アプリケーション・プロファイルをデプロイする必要があります。
JDeveloperを使用してアプリケーション・プロファイルをデプロイする方法の詳細は、第2.7項「JDeveloperからのOracle JCAアダプタ・アプリケーションのデプロイ」を参照してください。
アプリケーション・サーバー接続も作成する必要があります。アプリケーション・サーバー接続を作成する方法の詳細は、第2.6項「Oracle JCAアダプタ用のアプリケーション・サーバー接続の作成」を参照してください。
Fusion Middleware Controlコンソールを使用して、デプロイ済のSOAコンポジットを監視できます。次の手順を実行します。
ユーザー名とパスワードを使用してhttp://servername:portnumber/emにログインします。「Oracle Enterprise Manager Fusion Middleware Control」ページが表示されます。
左ペインで、「SOA」、「soa-infra (soa_server1)」の順にナビゲートします。デプロイされている全コンポジットのリストが表示されます。
「Sync-Req-RepComposite[1.0]」をクリックします。「Sync-Req-RepComposite[1.0]」ページが表示されます。
data.txt
ファイルのコンテンツでMQメッセージを作成し、replyToQueueNameをtest_reply
に設定します。このメッセージをtest_in
キューに蓄積します。
少し待ってからFusion Middleware Controlコンソールをリフレッシュします。インスタンスがコンソールに表示されます。これは、発生した処理のためトリガーされたインスタンスです。
「インスタンス」タブをクリックします。
このデプロイメントに関連付けられているインスタンスをクリックします。「フローのトレース」ページが表示されます。
「BPELSyncreqrep」コンポーネント・インスタンスをクリックします。「監査証跡」ページが表示されます。
「フロー」タブをクリックしてインスタンスをデバッグします。BPELプロセス・インスタンスのフローが表示されます。
アクティビティをクリックして関連するペイロードの詳細を表示します。
この使用例では、非同期リクエスト-リプライのエンドツーエンドのシナリオについて説明します。この使用例では、最初にコンポジットによりインバウンド・キューからメッセージがデキューされます。次に、リクエスト・メッセージがエンキューされ、リプライ・メッセージがデキューされます。最後に、コンポジットによりリプライ・メッセージが他のキューにエンキューされます。この項には、次の項目が含まれます。
第10.5項「Oracle MQ Seriesアダプタの構成」の指定に従ってOracle MQ Seriesアダプタを構成し、キューtest_in、test_outおよびtest_demoを作成する必要があります。
SOAコンポジットを含んだJDeveloperアプリケーションを作成する必要があります。使用例のアプリケーションとプロジェクトを作成する手順は、次のとおりです。
JDeveloperで、「ファイル」をクリックして「新規」を選択します。
「新規ギャラリ」ダイアログが表示されます。
「一般」ノードを開いて「アプリケーション」カテゴリを選択します。
「項目」リストから「汎用アプリケーション」を選択し、「OK」をクリックします。汎用アプリケーションの作成ウィザードが表示されます。
「アプリケーションの名前付け」画面で、「アプリケーション名」フィールドにAsynchronousRequestReply
と入力して「次へ」をクリックします。「プロジェクトの名前付け」画面が表示されます。
「プロジェクト名」フィールドにAsync-Req-RepComposite
と入力し、「選択可能」リストから「SOA」を選択して右矢印ボタンをクリックします。
「次へ」をクリックします。「SOA設定の設定」画面が表示されます。
「コンポジット・テンプレート」リストから「BPELを使用するコンポジット」を選択して「終了」をクリックします。「BPELプロセスの作成」ダイアログが表示されます。
「名前」フィールドにBPELAsyncreqrep
と入力し、「テンプレート」ボックスから「サービスを後で定義」を選択します。
「OK」をクリックします。図10-75に示すように、AsynchronousRequestReplyアプリケーションとAsync-Req-RepCompositeプロジェクトが設計領域に表示されます。
次の手順を実行し、メッセージをキューからデキューするアダプタ・サービスを作成します。
「コンポーネント・パレット」から、「MQアダプタ」を「公開されたサービス」スイムレーンにドラッグ・アンド・ドロップします。アダプタ構成ウィザードの「ようこそ」ページが表示されます。
「次へ」をクリックします。「サービス名」ページが表示されます。
「サービス名」フィールドにInboundService
と入力して「次へ」をクリックします。「MQ Series接続」ページが表示されます。
MQ Series接続用のデフォルトJNDI名を受け入れて「次へ」をクリックします。「アダプタ・インタフェース」ページが表示されます。
「操作およびスキーマから定義(後で指定)」を選択して「次へ」をクリックします。「操作タイプ」ページが表示されます。
「MQからメッセージを取得」を選択して「次へ」をクリックします。「MQからメッセージを取得」ページが表示されます。
「キュー名」フィールドにtest_in
と入力して「次へ」をクリックします。「メッセージ」ページが表示されます。
「ネイティブ・フォーマット変換は不要(スキーマを不透明(Opaque)にする)」を選択し、「次へ」をクリックします。「終了」ページが表示されます。
「終了」をクリックします。インバウンド・アダプタ・サービスの構成が完了し、図10-76に示すように、「composite.xml」ページが表示されます。
リクエスト・メッセージをエンキューし、対応するレスポンス・メッセージ(レポート)をキューからデキューするアダプタ・サービスを作成する手順は、次のとおりです。
「コンポーネント・パレット」から、「MQアダプタ」を「外部参照」スイムレーンにドラッグ・アンド・ドロップします。アダプタ構成ウィザードの「ようこそ」ページが表示されます。
「次へ」をクリックします。「サービス名」ページが表示されます。
「サービス名」フィールドにasyn-Req-Res
と入力して「OK」をクリックします。「MQ Series接続」ページが表示されます。
MQ Series接続用のデフォルトJNDI名を受け入れて「次へ」をクリックします。「アダプタ・インタフェース」ページが表示されます。
「操作およびスキーマから定義(後で指定)」を選択して「次へ」をクリックします。「操作タイプ」ページが表示されます。
「MQにメッセージを送信し、リプライ/レポートを取得」を選択し、「操作名」ボックスで「非同期」を選択して「次へ」をクリックします。「MQにメッセージを送信し、リプライ/レポートを取得」ページが表示されます。
「メッセージ・タイプ」ボックスで「標準」を選択し、「キュー名」フィールドにtest_out
と入力し、「レポートの取得」チェック・ボックスを選択して「次へ」をクリックします。「レポート」ページが表示されます。
図10-77に示すように、「着信時の確認」を選択して「次へ」をクリックします。「レスポンス」ページが表示されます。
「返信先キュー名」フィールドにtest_out
と入力して「次へ」をクリックします。「詳細オプション」ページが表示されます。
デフォルト値を受け入れて「次へ」をクリックします。「メッセージ」ページが表示されます。
「メッセージ・スキーマの取得」ボックスと「メッセージ・スキーマの送信」ボックスで、「ネイティブ・フォーマット変換は不要(スキーマを不透明(Opaque)にする)」をそれぞれ選択して「次へ」をクリックします。「終了」ページが表示されます。
「終了」をクリックします。async-Req-Resサービスの構成が完了し、図10-78に示すように、「composite.xml」ページが表示されます。
次の手順を実行し、レスポンス(レポート)メッセージをエンキューするアダプタ・サービスを作成します。
「コンポーネント・パレット」から、「MQアダプタ」を「外部参照」スイムレーンにドラッグ・アンド・ドロップします。アダプタ構成ウィザードの「ようこそ」ページが表示されます。
「次へ」をクリックします。「サービス名」ページが表示されます。
「サービス名」フィールドにOutboundService
と入力して「OK」をクリックします。「MQ Series接続」ページが表示されます。
MQ Series接続用のデフォルトJNDI名を受け入れて「次へ」をクリックします。「アダプタ・インタフェース」ページが表示されます。
「操作およびスキーマから定義(後で指定)」を選択して「次へ」をクリックします。「操作タイプ」ページが表示されます。
「MQにメッセージを蓄積」を選択して「次へ」をクリックします。「MQにメッセージを蓄積」ページが表示されます。
「キュー名」フィールドにtest_demo
と入力して「次へ」をクリックします。「詳細オプション」ページが表示されます。
デフォルト値を受け入れて「次へ」をクリックします。「メッセージ」ページが表示されます。
「ネイティブ・フォーマット変換は不要(スキーマを不透明(Opaque)にする)」を選択し、「次へ」をクリックします。「終了」ページが表示されます。
「終了」をクリックします。OutboundServiceサービスの構成が完了し、図10-79に示すように、「composite.xml」ページが表示されます。
作成した4つのコンポーネント(インバウンド・アダプタ・サービス、BPELプロセス、async-Req-Resおよびアウトバウンド・アダプタ参照)をアセンブルまたは接続する必要があります。コンポーネントを接続する手順は、次のとおりです。
「公開されたサービス」領域にあるInboundServiceサービス内の小さい三角形を、「コンポーネント」領域のBPELプロセス内に緑の三角形として表示されるドロップ・ゾーンにドラッグします。
「コンポーネント」領域にあるBPELプロセス内の小さい三角形を、「外部参照」領域のasync-Req-Res内に緑の三角形として表示されるドロップ・ゾーンにドラッグします。
同様に、「コンポーネント」領域にあるBPELプロセス内の小さい三角形を、「外部参照」領域のOutboundService内のドロップ・ゾーンにドラッグします。
JDeveloperのcomposite.xmlが図10-80のように表示されます。
「ファイル」、「すべて保存」を順番にクリックします。
「BPELAsyncreqrep」をダブルクリックします。「DequeueEnqueueRFH2.bpel」ページが表示されます。
「コンポーネント・パレット」から、receive、assign、invoke、receive、assignおよびinvokeアクティビティを「コンポーネント」領域に順番にドラッグ・アンド・ドロップします。図10-81に示すように、JDeveloperの「BPELAsyncreqrep.bpel」ページが表示されます。
1つ目のreceiveアクティビティをInboundServiceアダプタ・サービスにドラッグ・アンド・ドロップします。「Receive」ダイアログが表示されます。
「変数」フィールドの端に表示される「変数の自動作成」アイコンをクリックします。「変数の作成」ダイアログが表示されます。
デフォルトを受け入れて「OK」をクリックします。
「インスタンスの作成」ボックスを選択して「OK」をクリックします。
1つ目のinvokeアクティビティをasync-Req-Resサービスにドラッグ・アンド・ドロップします。「Invoke」ダイアログが表示されます。
「入力変数」フィールドの端に表示される「入力変数の自動作成」アイコンをクリックします。
デフォルトを受け入れて「OK」をクリックします。「Invoke」ダイアログが表示されます。
「OK」をクリックします。
2つ目のreceiveアクティビティをasync-Req-Repサービスにドラッグ・アンド・ドロップします。「Receive」ダイアログが表示されます。
「変数の自動作成」アイコンをクリックして変数を作成します。
注意: 「インスタンスの作成」ボックスは選択しないでください。 |
「Receive」ダイアログで「OK」をクリックします。
2つ目のinvokeアクティビティをOutboundServiceにドラッグ・アンド・ドロップします。「Invoke」ダイアログが表示されます。
「入力変数の自動作成」アイコンをクリックして変数を作成します。
「Invoke」ダイアログで「OK」をクリックします。
1つ目のassignアクティビティをダブルクリックします。「Assign」ダイアログが表示されます。
「+」アイコンをクリックして「コピー操作」を選択します。「コピー操作の作成」ダイアログが表示されます。
図10-82に示すように、変数を選択して「OK」をクリックします。
「Assign」ダイアログで「OK」をクリックします。
2つ目のassignアクティビティをダブルクリックします。「Assign」ダイアログが表示されます。
「+」アイコンをクリックして「コピー操作」を選択します。「コピー操作の作成」ダイアログが表示されます。
図10-83に示すように、変数を選択して「OK」をクリックします。
「Assign」ダイアログで「OK」をクリックします。図10-84に示すように、JDeveloperの「BPELAsyncreqrep.bpel」ページが表示されます。
前述の手順で作成したSOAプロジェクトおよびアプリケーションについて、アプリケーション・プロファイルをデプロイする必要があります。
JDeveloperを使用してアプリケーション・プロファイルをデプロイする方法の詳細は、第2.7項「JDeveloperからのOracle JCAアダプタ・アプリケーションのデプロイ」を参照してください。
アプリケーション・サーバー接続も作成する必要があります。アプリケーション・サーバー接続を作成する方法の詳細は、第2.6項「Oracle JCAアダプタ用のアプリケーション・サーバー接続の作成」を参照してください。
Fusion Middleware Controlコンソールを使用して、デプロイ済のSOAコンポジットを監視できます。次の手順を実行します。
ユーザー名とパスワードを使用してhttp://servername:portnumber/emにログインします。「Oracle Enterprise Manager Fusion Middleware Control」ページが表示されます。
左ペインで、「SOA」、「soa-infra (soa_server1)」の順にナビゲートします。デプロイされている全コンポジットのリストが表示されます。
「Async-Req-RepComposite[1.0]」をクリックします。「Async-Req-RepComposite[1.0]」ページが表示されます。
address-csv.xsdに準拠するコンテンツを含み、ヘッダーとしてReply Queueも含んでいるメッセージを、test_inキューに蓄積します。
少し待ってからFusion Middleware Controlコンソールをリフレッシュします。インスタンスがコンソールに表示されます。これは、発生した処理のためトリガーされたインスタンスです。
「インスタンス」タブをクリックします。
このデプロイメントに関連付けられているインスタンスをクリックします。「フローのトレース」ページが表示されます。
「BPELAsyncreqrep」コンポーネント・インスタンスをクリックします。「監査証跡」ページが表示されます。
「フロー」タブをクリックしてインスタンスをデバッグします。BPELプロセス・インスタンスのフローが表示されます。
アクティビティをクリックして関連するペイロードの詳細を表示します。
この使用例では、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アプリケーションを作成する必要があります。使用例のアプリケーションとプロジェクトを作成する手順は、次のとおりです。
JDeveloperで、「ファイル」をクリックして「新規」を選択します。
「新規ギャラリ」ダイアログが表示されます。
「一般」ノードを開いて「アプリケーション」カテゴリを選択します。
「項目」リストから「汎用アプリケーション」を選択し、「OK」をクリックします。汎用アプリケーションの作成ウィザードが表示されます。
「アプリケーションの名前付け」画面で、「アプリケーション名」フィールドにOutboundDequeue
と入力して「次へ」をクリックします。「プロジェクトの名前付け」画面が表示されます。
「プロジェクト名」フィールドにOutboundDequeueComposite
と入力し、「選択可能」リストから「SOA」を選択して右矢印ボタンをクリックします。
「次へ」をクリックします。「SOA設定の設定」画面が表示されます。
「コンポジット・テンプレート」リストから「BPELを使用するコンポジット」を選択して「終了」をクリックします。「BPELプロセスの作成」ダイアログが表示されます。
「名前」フィールドにBPELOutboundDequeue
と入力し、「テンプレート」ボックスで「同期BPELプロセス」を選択します。
「入力」フィールドの端にある「参照」をクリックします。「タイプ・チューザ」ダイアログが表示されます。
「プロジェクトのスキーマ・ファイル」、「singleString.xsd」および「singleString」を順番に選択し、「OK」をクリックします。
「出力」フィールドの端にある「参照」をクリックします。「タイプ・チューザ」ダイアログが表示されます。
「プロジェクトのスキーマ・ファイル」、「singleString.xsd」および「singleString」を順番に選択し、「OK」をクリックします。
「OK」をクリックします。図10-85に示すように、OutboundDequeueアプリケーションとOutboundDequeueCompositeプロジェクトが設計領域に表示されます。
次の手順を実行し、メッセージをキューにデキューするアダプタ・サービスを作成します。
「コンポーネント・パレット」から、「MQアダプタ」を「外部参照」スイムレーンにドラッグ・アンド・ドロップします。アダプタ構成ウィザードの「ようこそ」ページが表示されます。
「次へ」をクリックします。「サービス名」ページが表示されます。
「サービス名」フィールドにOutboundDequeueService
と入力して「OK」をクリックします。「MQ Series接続」ページが表示されます。
MQ Series接続用のデフォルトJNDI名を受け入れて「次へ」をクリックします。「アダプタ・インタフェース」ページが表示されます。
「操作およびスキーマから定義(後で指定)」を選択して「次へ」をクリックします。「操作タイプ」ページが表示されます。
「MQからメッセージを取得」および「同期」を選択し、「次へ」をクリックします。「MQからメッセージを取得」ページが表示されます。
「キュー名」フィールドにtest_out
と入力し、「待機間隔」フィールドに10
と入力して「次へ」をクリックします。「メッセージ」ページが表示されます。
「URL」フィールドの端にある「参照」をクリックします。「タイプ・チューザ」ダイアログが表示されます。
「プロジェクトのスキーマ・ファイル」、「singleString.xsd」および「singleString」を順番に選択し、「OK」をクリックします。「メッセージ」ページの「URL」フィールドにsingleString.xsdファイルが表示されます。
「次へ」をクリックします。「終了」ページが表示されます。
「終了」をクリックします。インバウンド・アダプタ・サービスの構成が完了し、図10-86に示すように、「composite.xml」ページが表示されます。
「ファイル」、「すべて保存」を順番にクリックします。
作成した3つのコンポーネント(クライアント、BPELプロセスおよびアウトバウンド・アダプタ参照)をアセンブルまたは接続する必要があります。コンポーネントを接続する手順は、次のとおりです。
「コンポーネント」領域にあるBPELプロセス内の小さい三角形を、「外部参照」領域のOutboundDequeueService内に緑の三角形として表示されるドロップ・ゾーンにドラッグします。
「BPELOutboundDequeue」をダブルクリックします。「BPELOutboundDequeue.bpel」ページが表示されます。
「コンポーネント・パレット」から、invokeおよびassignアクティビティを「コンポーネント」領域にあるreceiveInputアクティビティとreplyOutputアクティビティの間に順番にドラッグ・アンド・ドロップします。
図10-87に示すように、「composite.xml」ページが表示されます。
図10-88に示すように、JDeveloperの「BPELOutboundDequeue.bpel」ページが表示されます。
invokeアクティビティをOutboundDequeueServiceアダプタ参照にドラッグ・アンド・ドロップします。「Invoke」ダイアログが表示されます。
「入力変数」フィールドの端に表示される「変数の自動作成」アイコンをクリックします。「変数の作成」ダイアログが表示されます。
デフォルトを受け入れて「OK」をクリックします。
同じ手順を出力変数について繰り返し、「OK」をクリックします。
assignアクティビティをダブルクリックします。「Assign」ダイアログが表示されます。
「+」アイコンをクリックして「コピー操作」を選択します。「コピー操作の作成」ダイアログが表示されます。
図10-89に示すように、変数を選択して「OK」をクリックします。
「Assign」ダイアログで「OK」をクリックします。
図10-90に示すように、「BPELOutboundDequeue.bpel」ページが表示されます。
前述の手順で作成したSOAプロジェクトおよびアプリケーションについて、アプリケーション・プロファイルをデプロイする必要があります。
JDeveloperを使用してアプリケーション・プロファイルをデプロイする方法の詳細は、第2.7項「JDeveloperからのOracle JCAアダプタ・アプリケーションのデプロイ」を参照してください。
アプリケーション・サーバー接続も作成する必要があります。アプリケーション・サーバー接続を作成する方法の詳細は、第2.6項「Oracle JCAアダプタ用のアプリケーション・サーバー接続の作成」を参照してください。
Fusion Middleware Controlコンソールを使用して、デプロイ済のSOAコンポジットを監視できます。次の手順を実行します。
ユーザー名とパスワードを使用してhttp://servername:portnumber/emにログインします。
左ペインで、「SOA」、「soa-infra (soa_server1)」の順にナビゲートします。デプロイされている全コンポジットのリストが表示されます。
「OutboundDequeueComposite[1.0]」をクリックします。「OutboundDequeueComposite[1.0]」ページが表示されます。
「テスト」ボタンをクリックします。「Webサービスのテスト」ページが表示されます。
「リクエスト」タブをクリックし、「引数を入力」ペインにスクロールします。
「入力」フィールドにTest Outbound Dequeue
と入力し、「Webサービスのテスト」ボタンをクリックします。
少し待ってから「レスポンス」タブをクリックします。指定したsingleString xsd内のメッセージが「レスポンス」タブに表示されます。
「インスタンス」タブをクリックします。
このデプロイメントに関連付けられているインスタンスをクリックします。「フローのトレース」ページが表示されます。
「BPELOutboundDequeue」コンポーネント・インスタンスをクリックします。図10-91に示すように、「監査証跡」ページが表示されます。
「フロー」タブをクリックしてインスタンスをデバッグします。BPELプロセス・インスタンスのフローが表示されます。
アクティビティをクリックして関連するペイロードの詳細を表示します。
この使用例では、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アプリケーションを作成する必要があります。使用例のアプリケーションとプロジェクトを作成する手順は、次のとおりです。
JDeveloperで、「ファイル」をクリックして「新規」を選択します。
「新規ギャラリ」ダイアログが表示されます。
「一般」ノードを開いて「アプリケーション」カテゴリを選択します。
「項目」リストから「汎用アプリケーション」を選択し、「OK」をクリックします。汎用アプリケーションの作成ウィザードが表示されます。
「アプリケーションの名前付け」画面で、「アプリケーション名」フィールドにMQ_BackoutQ_Retry
と入力して「次へ」をクリックします。「プロジェクトの名前付け」画面が表示されます。
「プロジェクト名」フィールドにSOA_BackoutQ_Retry
と入力し、「選択可能」リストからSOAを選択して右矢印ボタンをクリックします。
「次へ」をクリックします。「SOA設定の設定」画面が表示されます。
「コンポジット・テンプレート」リストから「BPELを使用するコンポジット」を選択して「終了」をクリックします。「BPELプロセスの作成」ダイアログが表示されます。
「名前」フィールドにBPELProcess_BackoutQ_Retry
と入力し、「テンプレート」ボックスから「サービスを後で定義」を選択します。
「OK」をクリックします。MQ_BackoutQ_RetryアプリケーションとSOA_BackoutQ_Retryプロジェクトが設計領域に表示されます。
次の手順を実行し、メッセージをデキューし、キューに蓄積するアダプタ・サービスを作成します。
「コンポーネント・パレット」から、「MQアダプタ」を「公開されたサービス」スイムレーンにドラッグ・アンド・ドロップします。アダプタ構成ウィザードの「ようこそ」ページが表示されます。
「次へ」をクリックします。「サービス名」ページが表示されます。
「サービス名」フィールドにInboundService
と入力して「次へ」をクリックします。「MQ Series接続」ページが表示されます。
MQ Series接続用のデフォルトJNDI名を受け入れて「次へ」をクリックします。「アダプタ・インタフェース」ページが表示されます。
「操作およびスキーマから定義(後で指定)」を選択して「次へ」をクリックします。「操作タイプ」ページが表示されます。
「MQからメッセージを取得し、リプライ/レポートを送信」(同期)を選択して「次へ」をクリックします。「MQからメッセージを取得し、リプライ/レポートを送信」ページが表示されます。
「キュー名」フィールドにINBOUND_QUEUE
と入力して「次へ」をクリックします。「レスポンス」ページが表示されます。
デフォルトを受け入れて「次へ」をクリックします。「メッセージ」ページが表示されます。
「URL」フィールドの端にある「参照」をクリックします。「タイプ・チューザ」ダイアログが表示されます。
「プロジェクトのスキーマ・ファイル」、「singleString.xsd」および「singleString」を順番に選択します。
「OK」をクリックします。「メッセージ」ページの「URL」フィールドにsingleString.xsdファイルが表示されます。
「次へ」をクリックします。「終了」ページが表示されます。
「終了」をクリックします。インバウンド・アダプタ・サービスの構成が完了し、インバウンド・アダプタが追加された「composite.xml」ページが表示されます。
次の例に示すように、バックアウト・キュー・プロパティを対応するJCA
ファイル(ReqReply_mq.jca
)に追加します。
<property name="BackoutQueueName" value="BACKOUT.QUEUE"/> <property name="MaximumBackoutCount" value="5"/> <property name="BackoutRetries" value="3"/>
次の手順を実行し、メッセージをエンキューするアダプタ・サービスを作成します。
「コンポーネント・パレット」から、「MQアダプタ」を「外部参照」スイムレーンにドラッグ・アンド・ドロップします。アダプタ構成ウィザードの「ようこそ」ページが表示されます。
「次へ」をクリックします。「サービス名」ページが表示されます。
「サービス名」フィールドにEQ
と入力して「次へ」をクリックします。「MQ Series接続」ページが表示されます。
MQ Series接続用のデフォルトJNDI名を受け入れて「次へ」をクリックします。「アダプタ・インタフェース」ページが表示されます。
「操作およびスキーマから定義(後で指定)」を選択して「次へ」をクリックします。「操作タイプ」ページが表示されます。
「MQにメッセージを蓄積」を選択して「次へ」をクリックします。「MQにメッセージを蓄積」ページが表示されます。
「キュー名」フィールドにtest_out
と入力して「次へ」をクリックします。「詳細オプション」ページが表示されます。
デフォルトを受け入れて「次へ」をクリックします。「メッセージ」ページが表示されます。
「URL」フィールドの端にある「参照」をクリックします。「タイプ・チューザ」ダイアログが表示されます。
「プロジェクトのスキーマ・ファイル」、「singleString.xsd」および「singleString」を順番に選択し、「OK」をクリックします。「メッセージ」ページの「URL」フィールドにsingleString.xsdファイルが表示されます。
「次へ」をクリックします。「終了」ページが表示されます。
「終了」をクリックします。アウトバウンド・アダプタ・サービスの構成が完了し、図10-92に示すように、「composite.xml」ページが表示されます。
作成した3つのコンポーネント(インバウンド・アダプタ・サービス、BPELプロセスおよびアウトバウンド・アダプタ参照)をアセンブルまたは接続する必要があります。コンポーネントを接続する手順は、次のとおりです。
「公開されたサービス」領域にあるInboundService内の小さい三角形を、「コンポーネント」領域のBPELプロセス内に緑の三角形として表示されるドロップ・ゾーンにドラッグします。
「コンポーネント」領域にあるBPELプロセス内の小さい三角形を、「外部参照」領域のOutboundService内に緑の三角形として表示されるドロップ・ゾーンにドラッグします。
JDeveloperのcomposite.xmlが図10-93のように表示されます。
「ファイル」、「すべて保存」を順番にクリックします。
BPELProcess_BackoutQ_Retryをダブルクリックします。「BPELProcess_backoutQ_Retry.bpel」ページが表示されます。
「コンポーネント・パレット」から、receive、assign、invokeおよびreplyアクティビティを「コンポーネント」領域にこの順序でドラッグ・アンド・ドロップします。
receiveアクティビティをReqReplyにドラッグ・アンド・ドロップします。「Receive」ダイアログが表示されます。
「変数」フィールドの端に表示される「変数の自動作成」アイコンをクリックします。「変数の作成」ダイアログが表示されます。
デフォルトを受け入れて「OK」をクリックします。
「インスタンスの作成」ボックスを選択して「OK」をクリックします。
replyアクティビティをReqReplyにドラッグ・アンド・ドロップします。「Reply」ダイアログが表示されます。
「名前」フィールドにReplyOutput
と入力します。
「変数」フィールドの端に表示される「変数の参照」アイコンをクリックします。「変数チューザ」ダイアログが表示されます。
replyOutput_DequeueEnqueue_OutputVariableを選択し、「OK」をクリックします。この変数が「Reply」ダイアログに表示されます。
「OK」をクリックします。
invokeアクティビティをEQにドラッグ・アンド・ドロップします。「Invoke」ダイアログが表示されます。
「入力変数」フィールドの端に表示される「入力変数の自動作成」アイコンをクリックします。
デフォルトを受け入れて「OK」をクリックします。「Invoke」ダイアログが表示されます。
「OK」をクリックします。
assignアクティビティをダブルクリックします。「Assign」ダイアログが表示されます。
「+」アイコンをクリックして「コピー操作」を選択します。「コピー操作の作成」ダイアログが表示されます。
「コピー操作の作成」ダイアログで、「タイプから」としてreceiveInput_DequeueEnqueue_InputVariable
を選択し、コピー操作の作成先の「To」ペインで変数を選択します。
次に、コピー操作が定義されたBPELProcess_BackoutQ_Retry.bpelファイルのコード・スニペットを示します。
<assign name="Assign_1"> <copy> <from variable="receiveInput_DequeueEnqueue_InputVariable" part="singleString" query="/ns3:singleString/ns3:input"/> <to variable="Invoke_1_Enqueue_InputVariable" part="body" query="/ns3:singleString/ns3:input"/> </copy> <copy> <from variable="receiveInput_DequeueEnqueue_InputVariable" part="singleString" query="/ns3:singleString/ns3:input"/> <to variable="replyOutput_DequeueEnqueue_OutputVariable" part="singleString" query="/ns3:singleString/ns3:input"/> </copy> </assign>
「OK」をクリックします。図10-94に示す「BPELdequeueenqueue.bpel」ページが表示されます。
前述の手順で作成したSOAプロジェクトおよびアプリケーションについて、アプリケーション・プロファイルをデプロイする必要があります。
JDeveloperを使用してアプリケーション・プロファイルをデプロイする方法の詳細は、第2.7項「JDeveloperからのOracle JCAアダプタ・アプリケーションのデプロイ」を参照してください。
アプリケーション・サーバー接続も作成する必要があります。アプリケーション・サーバー接続を作成する方法の詳細は、第2.6項「Oracle JCAアダプタ用のアプリケーション・サーバー接続の作成」を参照してください。
Fusion Middleware Controlコンソールを使用して、デプロイ済のSOAコンポジットを監視できます。次の手順を実行します。
http://
servername:portnumber
/em
にナビゲートします。デプロイしたコンポジットがアプリケーション・ナビゲータに表示されます。
インバウンド・メッセージが出力されるtest_outキューまたはリプライ・キューを無効に(蓄積を抑制)し、メッセージをINBOUND_QUEUE
に蓄積します。
少し待ってからFusion Middleware Controlコンソールをリフレッシュします。処理のためトリガーされるインスタンスがコンソールに表示されます。
注意: トリガーされるインスタンスの数は、 |
「インスタンス」タブをクリックします。
このデプロイメントに関連付けられているインスタンスをクリックします。「フローのトレース」ページが表示されます。
BPELProcess_BackoutQ_Retryコンポーネント・インスタンスをクリックします。「監査証跡」ページが表示されます。
「フロー」タブをクリックしてインスタンスをデバッグします。BPELプロセス・インスタンスのフローが表示されます。
アクティビティをクリックして関連するペイロードの詳細を表示します。
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を作成すると、単一のConnectionFactory JNDIはそのCCDTを使用するように構成する必要があります。その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アプリケーションを作成する必要があります。使用例のアプリケーションとプロジェクトを作成する手順は、次のとおりです。
JDeveloperで、「ファイル」をクリックして「新規」を選択します。
「新規ギャラリ」ダイアログが表示されます。
「一般」ノードを開いて「アプリケーション」カテゴリを選択します。
「項目」リストから「汎用アプリケーション」を選択し、「OK」をクリックします。汎用アプリケーションの作成ウィザードが表示されます。
「アプリケーションの名前付け」画面で、「アプリケーション名」フィールドにDequeueEnqueueRFH2
と入力して「次へ」をクリックします。「プロジェクトの名前付け」画面が表示されます。
「プロジェクト名」フィールドにDequeueEnqueueRFH2
と入力し、「選択可能」リストから「SOA」を選択して右矢印ボタンをクリックします。
「次へ」をクリックします。SOA設定の構成画面が表示されます。
「コンポジット・テンプレート」リストから「BPELを使用するコンポジット」を選択して「終了」をクリックします。「BPELプロセスの作成」ダイアログが表示されます。
「名前」フィールドにDequeueEnqueueRFH2
と入力し、「テンプレート」ボックスから「サービスを後で定義」を選択します。
「OK」をクリックします。DequeueEnqueueRFH2
アプリケーションとDequeueEnqueueRFH2
プロジェクトが設計領域に表示されます。
次の手順を実行し、メッセージをデキューし、キューに蓄積するアダプタ・サービスを作成します。
「コンポーネント・パレット」から、「MQアダプタ」を「公開されたサービス」スイムレーンにドラッグ・アンド・ドロップします。アダプタ構成ウィザードの「ようこそ」ページが表示されます。
「次へ」をクリックします。「サービス名」ページが表示されます。
「サービス名」フィールドにInboundMQ
と入力して「次へ」をクリックします。「MQ Series接続」ページが表示されます。
MQ Series接続用のデフォルトJNDI名を受け入れて「次へ」をクリックします。「アダプタ・インタフェース」ページが表示されます。
「操作およびスキーマから定義(後で指定)」を選択して「次へ」をクリックします。「操作タイプ」ページが表示されます。
「MQからメッセージを取得」を選択し(「同期」は選択しません)、「次へ」をクリックします。「MQからメッセージを取得」ページが表示されます。
「キュー名」フィールドにqueue1
と入力し、「他のスキーマを選択します」を選択して「次へ」をクリックします。「メッセージ」ページが表示されます。
ネイティブ・フォーマットは不要(スキーマを不透明(Opaque)にする)を選択し、「次へ」をクリックします。「終了」ページが表示されます。
「終了」をクリックします。インバウンド・アダプタ・サービスの構成が完了し、インバウンド・アダプタが追加された「composite.xml」ページが表示されます。
「コンポーネント・パレット」から、「MQアダプタ」を「外部参照」スイムレーンにドラッグ・アンド・ドロップします。アダプタ構成ウィザードの「ようこそ」ページが表示されます。
「次へ」をクリックします。「サービス名」ページが表示されます。
「サービス名」フィールドにOutboundMQ
と入力して「次へ」をクリックします。「MQ Series接続」ページが表示されます。
MQ Series接続用のデフォルトJNDI名を受け入れて「次へ」をクリックします。「アダプタ・インタフェース」ページが表示されます。
「操作およびスキーマから定義(後で指定)」を選択して「次へ」をクリックします。「操作タイプ」ページが表示されます。
「MQにメッセージを格納」を選択します。「次へ」をクリックします。「MQにメッセージを蓄積」ページが表示されます。
「キュー名」フィールドにqueue2
と入力します。「次へ」をクリックします。「詳細オプション」ページが表示されます。
デフォルトを受け入れて「次へ」をクリックします。「メッセージ」ページが表示されます。
「ネイティブ・フォーマット変換は不要(スキーマを不透明(Opaque)にする)」
を選択し、「次へ」をクリックします。「終了」ページが表示されます。
「終了」をクリックします。アウトバウンド・アダプタ・サービスの構成が完了し、図10-92に示すように、composite.xml
ページが表示されます。
作成した3つのコンポーネント(インバウンド・アダプタ・サービス、BPELプロセスおよびアウトバウンド・アダプタ参照)をアセンブルまたは接続する必要があります。コンポーネントを接続する手順は、次のとおりです。
「公開されたサービス」領域にあるInboundMQ内の小さい三角形を、「コンポーネント」領域のDequeueEnqueueRFH2内に緑の三角形として表示されるドロップ・ゾーンにドラッグします。
「コンポーネント」領域にあるDequeuEnqueueRFH2内の小さい三角形を、「外部参照」領域のOutboundMQ内に緑の三角形として表示されるドロップ・ゾーンにドラッグします。
図10-87に示すように、「composite.xml」ページが表示されます。
「ファイル」、「すべて保存」を順番にクリックします。
「DequeueEnqueueRFH2」をダブルクリックします。「DequeueEnqueueRFH2.bpel」ページが表示されます。
「コンポーネント・パレット」から、receive、assignおよびinvokeアクティビティを「コンポーネント」領域にこの順序でドラッグ・アンド・ドロップします。
「JDeveloper 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を使用してアプリケーション・プロファイルをデプロイする方法の詳細は、第2.7項「JDeveloperからのOracle JCAアダプタ・アプリケーションのデプロイ」を参照してください。
アプリケーション・サーバー接続も作成する必要があります。アプリケーション・サーバー接続を作成する方法の詳細は、第2.6項「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アプリケーションを作成する必要があります。使用例のアプリケーションとプロジェクトを作成する手順は、次のとおりです。
JDeveloperで、「ファイル」をクリックして「新規」を選択します。
「新規ギャラリ」ダイアログが表示されます。
「一般」ノードを開いて「アプリケーション」カテゴリを選択します。
「項目」リストから「汎用アプリケーション」を選択し、「OK」をクリックします。汎用アプリケーションの作成ウィザードが表示されます。
「アプリケーションの名前付け」画面で、「アプリケーション名」フィールドにOutboundDequeueRFH2
と入力して「次へ」をクリックします。「プロジェクトの名前付け」画面が表示されます。
「プロジェクト名」フィールドにOutboundDequeueRFH2
と入力し、「選択可能」リストから「SOA」を選択して右矢印ボタンをクリックします。
「次へ」をクリックします。「SOA設定の設定」画面が表示されます。
「コンポジット・テンプレート」リストから「BPELを使用するコンポジット」を選択して「終了」をクリックします。「BPELプロセスの作成」ダイアログが表示されます。
「名前」フィールドにOutboundDequeueRFH2
と入力し、「テンプレート」ボックスで「同期BPELプロセス」を選択します。
「入力」フィールドの端にある「参照」をクリックします。「タイプ・チューザ」ダイアログが表示されます。
「プロジェクトのスキーマ・ファイル」、「singleString.xsd」および「singleString」を順番に選択し、「OK」をクリックします。
「出力」フィールドの端にある「参照」をクリックします。「タイプ・チューザ」ダイアログが表示されます。
「プロジェクトのスキーマ・ファイル」、「singleString.xsd」および「singleString」を順番に選択し、「OK」をクリックします。
「OK」をクリックします。「OutboundDequeueRFH2」アプリケーションおよび「OutboundDequeueRFH2」コンポジット・プロジェクトが設計領域に表示されます。
次の手順を実行し、メッセージをキューにデキューするアダプタ・サービスを作成します。
「コンポーネント・パレット」から、「MQアダプタ」を「外部参照」スイムレーンにドラッグ・アンド・ドロップします。アダプタ構成ウィザードの「ようこそ」ページが表示されます。
「次へ」をクリックします。「サービス名」ページが表示されます。
「サービス名」フィールドにOutboundDQ
と入力して「OK」をクリックします。「MQ Series接続」ページが表示されます。
MQ Series接続用のデフォルトJNDI名を受け入れて「次へ」をクリックします。「アダプタ・インタフェース」ページが表示されます。
「操作およびスキーマから定義(後で指定)」を選択して「次へ」をクリックします。「操作タイプ」ページが表示されます。
「MQからメッセージを取得」および「同期」を選択し、「次へ」をクリックします。「MQからメッセージを取得」ページが表示されます。
「キュー名」フィールドにqueue1
と入力し、「待機間隔」フィールドに10 seconds
と入力して「次へ」をクリックします。「メッセージ」ページが表示されます。
「ネイティブ・フォーマット変換は不要(スキーマを不透明(Opaque)にする)」を選択し、「OK」をクリックします。
「次へ」をクリックします。「終了」ページが表示されます。
「終了」をクリックします。インバウンド・アダプタ・サービスの構成が完了し、図10-100に示すように、「composite.xml」ページが表示されます。
「ファイル」、「すべて保存」を順番にクリックします。
作成した3つのコンポーネント(クライアント、BPELプロセスおよびOutboundDQアダプタ参照)をアセンブルまたは接続する必要があります。
コンポーネントを接続する手順は、次のとおりです。
「コンポーネント」領域にあるBPELプロセス内の小さい三角形を、「外部参照」領域のOutboundDequeueService内に緑の三角形として表示されるドロップ・ゾーンにドラッグします。
「OutboundDequeueRFH2」BPELプロセスをダブルクリックします。「OutboundDequeueRFH2.bpel」ページが表示されます。
JDeveloperのcomposite.xmlが図10-93のように表示されます。
「ファイル」、「すべて保存」を順番にクリックします。
「OutboundDequeueRFH2.bpel」をダブルクリックします。「OutboundDequeueRFH2.bpel」ページが表示されます。
「コンポーネント・パレット」からreceiveInputアクティビティとreplyOutputアクティビティ間にある「コンポーネント」領域に、invokeおよびassignの各アクティビティをこの順番でドラッグ・アンド・ドロップします。
invokeアクティビティをOutboundDQアダプタ参照にドラッグ・アンド・ドロップします。「Invoke」ダイアログが表示されます。
「変数」フィールドの端に表示される「変数の自動作成」アイコンをクリックします。「変数の作成」ダイアログが表示されます。
デフォルトを受け入れて「OK」をクリックします。
出力変数にも同じ手順を繰り返して「OK」をクリックします。
assignアクティビティをダブルクリックします。Assignダイアログが表示されます。
変数を選択して、「プラス」アイコンをクリックします。
Assignダイアログで「OK」をクリックします。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を使用してアプリケーション・プロファイルをデプロイする方法の詳細は、第2.7項「JDeveloperからのOracle JCAアダプタ・アプリケーションのデプロイ」を参照してください。
アプリケーション・サーバー接続も作成する必要があります。アプリケーション・サーバー接続を作成する方法の詳細は、第2.6項「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フォルダを含む必要があります。
サンプルをデプロイし、前述のメッセージをアウトバウンド・デキュー・キューに格納します。Enterprise Managerコンソールを開き、「テスト」ユーティリティを使用してサンプルを起動します。しばらく待機してからインスタンス監査証跡を調査します。