| Oracle® Fusion Middleware Oracle SOA Suite開発者ガイド 11gリリース1 (11.1.1.7) B56238-10 |
|
 前 |
 次 |
この章では、SOAコンポジット・アプリケーションでOracle MediatorまたはBPELプロセスからビジネス・イベントをサブスクライブまたは公開する方法を説明します。ビジネス・イベントは、イベント配信ネットワーク(EDN)に公開され、ビジネス環境で発生した結果として送信されるメッセージ・データから構成されます。ビジネス・イベントが公開されると、他のサービス・コンポーネントはそれをサブスクライブできます。
この章では、次の項目について説明します。
第41.3項「Oracle Mediatorサービス・コンポーネントからのビジネス・イベントのサブスクライブまたは公開」
第41.5項「Oracle ADF Business Componentビジネス・イベントをOracle Mediatorに統合する方法」
Oracle Mediatorでビジネス・イベントを使用する方法を示したサンプルは、Oracle SOA Suiteのサンプルを参照してください。
ビジネス・イベントをサブスクライブするサービス・コンポーネントでのコンポジット・センサーの作成の詳細は、第50章「コンポジット・センサーの定義」を参照してください。
スレッド数の指定、イベント配信の停止、最大配信数の指定などビジネス・イベントのトラブルシューティングの詳細は、『Oracle Fusion Middleware Oracle SOA SuiteおよびOracle Business Process Management Suite管理者ガイド』の付録Oracle SOA SuiteおよびOracle BPM Suiteのトラブルシューティングに関する項を参照してください。
ビジネス・イベント・チューニングの詳細は、『Oracle Fusion Middlewareパフォーマンスおよびチューニング・ガイド』を参照してください。
目的の状況が発生したときにビジネス・イベントを起動できます。たとえば、ローン・フローのシナリオで、ローン・プロセスを実行しているBPELプロセス・サービス・コンポーネントは、プロセスの完了時にローン完了イベントを起動できます。このアプリケーションのインフラストラクチャ内の他のシステムは、これらのイベントをリスニングし、イベントのインスタンスの受信時に次の処理を実行できます。
イベント・コンテキストを使用して、ビジネス・インテリジェンスまたはダッシュボード・データを導出します。
融資パッケージを顧客に送る必要があることをメール部門に知らせます。
別のビジネス・プロセスを起動します。
Oracle Business Activity Monitoring (BAM)に情報を送信します。
通常、ビジネス・イベントは、ビジネスの状態変化に関する通知を送信するための一方向のfire-and-forget非同期方法です。ビジネス・プロセスは、次の処理を行いません。
ビジネス・イベントの完了を受信するサービス・コンポーネントに依存しません。
他のサービス・コンポーネントがビジネス・イベントを受信しても関係ありません。
サブスクライバの存在(存在する場合)およびデータがサブスクライバに与える影響を知る必要がありません。
これらは、Web Services Description Language (WSDL)ファイル規定に依存する直接サービス起動(SOAPサービス・クライアントなど)とビジネス・イベントの重要な相違点です。イベントの発生がイベントの受信者に依存する場合、メッセージは通常、ビジネス・イベントではなくサービス起動を通して配信する必要があります。直接サービス起動とは異なり、ビジネス・イベントはサーバーからクライアントを分離します。
ビジネス・イベントは、イベント定義言語(EDL)を使用して定義されます。EDLは、ビジネス・イベント定義の作成に使用するスキーマです。アプリケーションは、ビジネス・イベント定義のインスタンスと協調して動作します。
EDLは、次のもので構成されます。
グローバル名
通常はJavaパッケージ名(com.acme.ExpenseReport.createdなど)ですが、必須ではありません。
ペイロード定義
定義には、XMLスキーマ(XSD)が最も一般的に使用されます。ビジネス・イベントのペイロードはXSDを使用して定義されます。スキーマのURIは、ペイロードのルート要素に含まれます。
例41-1に、BugReportイベント定義内に2つのビジネス・イベントbugUpdatedおよびbugCreatedがあるEDLファイルを示します。ネームスペース(BugReport)および関連するスキーマ・ファイル(BugReport.xsd)が参照されます。
例41-1 2つのビジネス・イベントがあるEDLファイル
<?xml version = '1.0' encoding = 'UTF-8'?> <definitions targetNamespace="/model/events/edl/BugReport" xmlns:ns0="/model/events/schema/BugReport" xmlns="http://schemas.oracle.com/events/edl"> <schema-import namespace="/model/events/schema/BugReport" location="BugReport.xsd"/> <event-definition name="bugCreated"> <content element="ns0:bugCreatedInfo"/> </event-definition> <event-definition name="bugUpdated"> <content element="ns0:bugUpdatedInfo"/> </event-definition> </definitions>
これら2つのイベントはOracle Mediatorのサブスクリプションで使用できます。
ビジネス・イベントは、Oracle Metadata Services (MDS)リポジトリにデプロイされます。ビジネス・イベントをそのアーティファクト(XSDなど)とともにMDSリポジトリにデプロイすることを、EDL(またはイベント定義)の公開とも呼びます。このアクションにより、EDLおよびそのアーティファクトがMDSリポジトリ内の共有領域に転送されます。MDSリポジトリ共有領域内のオブジェクトは、Oracle JDeveloperのリソース・パレット内のすべてのアプリケーションで参照できます。公開されたEDLは、他のアプリケーションでサブスクライブできます。EDLの公開を解除することはできません。定義は常に存在します。
サブスクリプションは、特定の修飾名(QName)(x.y.z/newOrdersなど)に対して行います。QNameはタプル(URI、localName)であり、xmlns:prefix=URIなどのネームスペース宣言またはネームスペース・コンテキストとの組合せで、文字列prefix:localNameから導出できます。また、コンテンツ・ベースのフィルタを使用すると、サブスクリプションをさらに絞り込むことができます。
ビジネス・イベントは、EDNに公開されます。EDNは、すべてのSOAインスタンスの範囲内で実行されます。発生したイベントはEDNにより、サブスクライブするサービス・コンポーネントに配信されます。Oracle Mediatorサービス・コンポーネントとBPELプロセス・サービス・コンポーネントはイベントをサブスクライブし、公開できます。
EDNには、次の2つの異なる実装があります。
EDN-DB: Oracleデータベースをバックエンド・ストアとして使用し、Oracle固有の機能に依存します。
EDN-JMS: 汎用JMSキューをバックエンド・ストアとして使用します。
Oracleデータベースを使用している場合は、EDN-JMSではなくEDN-DBを使用することをお薦めします。
1つのSOAコンポジット・アプリケーション・インスタンスは、1つのコンテナ内に配置することも、複数のコンテナにわたってクラスタ化することもできます。別のアプリケーション(Oracle Application Development Framework (ADF) Business Componentアプリケーションなど)を構成し、SOAコンポジット・アプリケーション・インスタンスと同じコンテナ内または異なるコンテナ内で実行できます。
ローカル・イベント接続またはリモート・イベント接続を通して、Java EEアプリケーションからイベントを発生させることができます。
ローカル・イベント接続
パブリッシャがアプリケーションと同じOracle WebLogic Serverに存在し、パブリッシャがローカル・ビジネス・イベント接続ファクトリを使用する場合、イベントはローカル・イベント接続を通して発生します。このシナリオでは、同期サブスクリプションが同期して実行されます。
リモート・イベント接続
コール元がアプリケーションと異なるコンテナ(異なるJVM)内に存在する場合、イベントはリモート・イベント接続を通して発生します。リモート・イベント接続では、非同期サブスクリプションのみがサポートされます。
別のアプリケーション(Oracle ADF Business Componentアプリケーションなど)を構成し、SOAコンポジット・アプリケーションと同じコンテナ内で実行すると、このアプリケーションはローカル・イベント接続を使用するように最適化されます。イベントの境界は、アプリケーション・インスタンスです。イベントがアプリケーション・インスタンス内で発生すると、アプリケーション・インスタンスに登録されたサブスクリプションが実行されます。イベントは、1つのアプリケーション・インスタンスから別のインスタンスに伝播されません。伝播は、イベントをリスニングし、イベントをJMSキューに公開するOracle Mediatorを通して、両方のインスタンスで実行されます。
この項では、ビジネス・イベントの作成方法およびサブスクライブ方法の高レベルな概要が提供されます。このシナリオでは、ストアフロント・アプリケーション(StoreFrontServiceサービス)でユーザーから注文を受けたときに、NewOrderSubmittedというビジネス・イベントが作成されます。その後、このビジネス・イベントをサブスクライブするOracle Mediatorサービス・コンポーネントを作成します。
ビジネス・イベントを作成する手順は、次のとおりです。
SOAプロジェクトを空のコンポジットとして作成します。
次の2つの方法のいずれかにより、「イベント定義の作成」ウィザードを起動します。
SOAコンポジット・エディタで、デザイナの上のアイコンをクリックします。図41-1に例を示します。
「ファイル」メイン・メニューから、「新規」→「SOA層」→「サービス・コンポーネント」→「イベント定義」の順に選択します。
「イベント定義の作成」ダイアログが表示されます。
表41-1に記載されている詳細を入力します。
「追加」アイコンをクリックして、イベントを追加します。
「イベントの追加」ダイアログが表示されます。
「検索」アイコンをクリックしてペイロードを選択し、「OK」をクリックします。図41-2に詳細を示します。
図41-3に示すように、「名前」フィールドに名前を入力します。
「OK」をクリックします。
図41-4に示すように、追加したイベントが「イベント」セクションに表示されます。
エディタの上部にある、event_definition_name.edlの横のxアイコンをクリックして、エディタを閉じます。
変更を保存するように求められた場合は、「はい」をクリックします。変更を保存しないとイベントは作成されず、「イベント・チューザ」ウィンドウでは選択できません。
ビジネス・イベントがOracle MDSリポジトリに公開され、SOAコンポジット・エディタに戻ります。「リソース・パレット」に、ビジネス・イベントが表示され参照できます。
この項では、Oracle Mediatorサービス・コンポーネントからビジネス・イベントをサブスクライブまたは公開する方法について説明します。
ビジネス・イベントをサブスクライブする手順は、次のとおりです。
「コンポーネント・パレット」からSOAコンポジット・エディタに、メディエータ・サービス・コンポーネントをドラッグします。このサービス・コンポーネントにより、ビジネス・イベントをサブスクライブできます。
「名前」フィールドに、名前を入力します。
「オプション」リストから、「イベントのサブスクライブ」を選択します。
ダイアログがリフレッシュされ、イベント表が表示されます。
「追加」アイコンをクリックして、イベントを選択します。
「イベント・チューザ」ダイアログが表示されます。
作成したイベントを選択し、「OK」をクリックします。
「メディエータの作成」ダイアログが再び表示されます。
イベントと一貫性がある配信のレベルを選択します。
唯一
イベントは、それ自体のグローバル(つまりJTA)トランザクションのサブスクライバに配信されます。イベント処理が完了すると、そのトランザクション内でサブスクライバが行ったあらゆる変更がコミットされます。サブスクライバが失敗すると、トランザクションはロールバックされます。失敗したイベントは、設定された回数だけ再試行されます。
保証付き
イベントは、グローバル・トランザクションなしでサブスクライバに非同期で配信されます。サブスクライバは、処理用にサブスクライバ自体のローカル・トランザクションの作成を選択できますが、他のイベント処理とは個別にコミットされます。このオプションでは、1つのキュー(メイン・イベント・キュー)へのトリップのみが存在するため、「1つのみ」オプションよりコストが低くなります。また、EDNではイベントの再送は試行されません(バッキング・ストアがAQであるかJMSであるかにかかわらず)。1人以上のサブスクライバがイベントの使用に失敗すると(他のサブスクライバは成功した場合)、それらのサブスクライバはメッセージを失います。その点において、保証付き配信は、実際にはベスト・エフォートの配信を意味します。つまり、各サブスクライバが確実にメッセージを使用することは保証されません。
即時
イベントは、パブリッシャと同じグローバル・トランザクションとスレッドで、サブスクライバに配信されます。すべての即時サブスクライバが処理を完了するまで、公開コールは返されません。いずれかのサブスクライバが例外をスローすると、追加のサブスクライバは起動されず、例外はパブリッシャにスローされます。即時処理中にエラーが発生した場合、トランザクションはロールバックされます。
イベントをフィルタリングするには、選択したイベントの「フィルタ」列をダブルクリックするか、またはイベントを選択して、表の上の「フィルタ」アイコン(最初のアイコン)をクリックします。これにより「式ビルダー」ダイアログが表示されます。このダイアログで、XPathフィルタ式を指定できます。フィルタ式では、サービスの起動前にメッセージのコンテンツ(ペイロードまたはヘッダー)が分析されるように指定します。たとえば、メッセージに顧客IDが含まれている場合のみサービスを起動することを指定するフィルタ式を適用できます。
式のロジックが満たされると、イベントの配信が可能になります。
フィルタの詳細は、第20.3.2.8項「メッセージをフィルタリングする式の指定方法」を参照してください。
図41-5は、「メディエータの作成」ダイアログを示しています。
「OK」をクリックします。
図41-6に、イベント・サブスクリプションのためにOracle Mediatorが構成されたことを示す左側のアイコンを示します。
例41-2のソース・コードに、Oracle Mediatorサービス・コンポーネントのサブスクライブするイベントに関する詳細を示します。
例41-2 サブスクライブするイベント
<component name="OrderPendingEvent">
<implementation.mediator src="OrderPendingEvent.mplan"/>
<business-events>
<subscribe
xmlns:sub1="/oracle/fodemo/storefront/entities/events/edl/OrderEO"
name="sub1:NewOrderSubmitted" consistency="oneAndOnlyOne"
runAsRoles="$publisher"/>
</business-events>
</component>
この例では明示的に示されていませんが、イベントにおいてXPathフィルタを定義できます。例41-3では、初期デポジットが50000を超える場合にのみ、イベントの配信が可能になります。
例41-3 イベントに対するXPathフィルタの定義
<business-events>
. . .
. . .
<filter>
<xpath xmlns:be="http://oracle.com/fabric/businessEvent"
xmlns:ns1="http://xmlns.oracle.com/singleString"
<xpath expression= "/be:business-event/be:content/
sub1:AccountInfo/Details[@initialDeposit > 50000]" />
</filter>
. . .
. . .
</business-events>
SOAコンポジット・アプリケーションのデフォルト以外のリビジョンに存在するサブスクライバでも、ビジネス・イベントを取得できます。たとえば、次の動作に注意してください。
ビジネス・イベントをサブスクライブする手順は、次のとおりです。
M1という最初のOracle Mediatorサービス・コンポーネントとM2という2番目のOracle Mediatorサービス・コンポーネントを含む、コンポジット・アプリケーションを作成します。M1はイベントを公開し、M2はイベントをサブスクライブします。出力はディレクトリに書き込まれます。
コンポジット・アプリケーションをリビジョン1としてデプロイします。
コンポジット・アプリケーションを変更して、M3という3番目のOracle Mediatorサービス・コンポーネントを追加します。M3は、同じイベントをサブスクライブし、別のディレクトリに出力を書き込みます。
コンポジット・アプリケーションをリビジョン2(デフォルト)としてデプロイします。
リビジョン2のコンポジット・アプリケーションを起動します。
Oracle Mediator M2は、同じ内容の出力をディレクトリ内の2つのファイルに書き込みます。Oracle Mediator M3は、予想どおりに、イベントを取得し、別のディレクトリに出力を正常に書き込みます。しかし、(リビジョン1の)Oracle Mediator M2も、コンポジット・アプリケーションのリビジョン2から公開されたイベントを取得し、処理しています。したがって、同じディレクトリ内にもう1つ出力ファイルが作成されます。
第41.3.1項「ビジネス・イベントをサブスクライブする方法」でサブスクライブしたイベントを公開するための、2番目のOracle Mediatorを作成できます。
ビジネス・イベントを公開する手順は、次のとおりです。
最初のOracle Mediatorがサブスクライブしたイベントを公開する、2番目のOracle Mediatorサービス・コンポーネントを作成します。
最初のOracle Mediatorサービス・コンポーネントに戻ります。
「ルーティング・ルール」セクションで、「追加」アイコンをクリックします。
「ターゲット・タイプ」ウィンドウでプロンプトが表示されたら、「サービス」をクリックします。
2番目のOracle Mediatorサービス・コンポーネントを選択します。
「ファイル」メイン・メニューから「すべて保存」を選択します。
この項では、公開側のアプリケーション(ADF EARファイルなど)がSOAサーバーではなく管理サーバーでデプロイされている場合に、外部JNDIプロバイダを構成する方法について説明します。
管理サーバー・アプリケーションでSOAサーバーにイベントを公開できるように外部JNDIプロバイダを構成する手順は、次のとおりです。
Oracle WebLogic Server管理コンソールにログインします。
http://host:port/console
「ドメイン構造」セクションで、「サービス」→「外部JNDIプロバイダ」を展開します。
「ロックして編集」をクリックします。
「新規」をクリックします。
「名前」フィールドに名前(SOA_JNDIなど)を入力し、「次へ」をクリックします。
「AdminServer」チェック・ボックスを選択し、「終了」をクリックします。
「名前」列で、ステップ5で入力したプロバイダ名をクリックします。
表41-2に記載されている詳細を入力し、「保存」をクリックします。
「リンク」→「新規」をクリックします。
表41-3に記載されている詳細を入力し、「OK」をクリックします。
「新規」をクリックします。
表41-4に記載されている詳細を入力し、「OK」をクリックします。
「OK」をクリックします。
「変更のアクティブ化」をクリックします。
LinuxのFMW_Home/user_projects/domains/domain_name/bin/setDomainEnv.shファイル(または、Windowsの場合はsetDomainEnv.batファイル)を次のように変更します。
WLS_JDBC_REMOTE_ENABLED="-Dweblogic.jdbc.remoteEnabled=true"
サーバーを再起動します。
EDN実装がJMSベース(EDN-JMS)の場合は、次に示すJNDI構成の変更が必要です。このようなシナリオでは、汎用JMSキューがバックエンド・ストアとして使用されます。この変更によって、リモート・クライアント(ADFアプリケーション・クライアントなど)は、イベントを公開する前に接続ファクトリを参照できるようになります。
JMSベースのEDN実装を構成する手順は、次のとおりです。
Oracle WebLogic Server管理コンソールにログインします。
http://host:port/console
「ドメイン構造」セクションで、「サービス」→「データ・ソース」を展開します。
EDN-JMSデータ・ソースを使用するために、EDN-DB JNDIソースを削除する必要があります。
次のEDN-DB JNDIデータ・ソースを選択し、「削除」をクリックします。
jdbc/EDNDataSource
jdbc/EDNLocalTxDataSource
イベント・パブリッシャが、異なるクラスタまたはEDN用のSOAサーバーとは異なるドメインで稼働中のアプリケーション(ADFなど)にある場合、SOAインフラストラクチャをターゲットとするJNDI名にマッピングするクラスタのローカルJNDI名を持つ外部JNDIプロバイダを構成する必要があります。ローカル/リモートJNDI名は、リンク内で同一になります。
「ドメイン構造」セクションで、「サービス」→「外部JNDIプロバイダ」を展開します。
「新規」をクリックします。
「名前」フィールドに外部JNDIプロバイダ名を入力します。
新規JNDIプロバイダのターゲットを選択し、「終了」をクリックします。
「名前」フィールドで、新規JNDIプロバイダをクリックします。
プロバイダ設定(初期コンテキスト・ファクトリ、プロバイダURLなど)を指定し、「保存」をクリックします。
「リンク」タブをクリックします。
「新規」をクリックし、外部JNDIリンクを作成します。
名前を入力し、jms/fabric/EDNConnectionFactoryのローカル/リモートJNDI名を指定します。
ステップ12を繰り返し、jms/fabric/xaEDNConnectionFactoryの名前およびローカル/リモートJNDI名を指定します。ステップ12を繰り返し、jms/fabric/EDNQueueの名前およびローカル/リモートJNDI名を指定します。
完了したら、3つのリンクが作成されます。
ターゲット・サーバーを再起動します。
JNDIツリー・ビューの新規JNDIプロバイダ・リンクを確認します。
このような構成変更が実行されない場合、例41-4に示されるものと同様のエラーが発生します。
例41-4 EDN-JMSエラー・メッセージ
<Aug 30, 2010 1:28:46 PM EDT> <Warning>
<oracle.adf.controller.faces.lifecycle.Utils> <BEA-000000> <ADF: Adding the
following JSF error message: [FMWGEN][SQLServer JDBC Driver][SQLServer]Could
not find stored procedure 'edn_internal_publish_event'.
oracle.fabric.common.FabricException: Error enqueueing event:
[FMWGEN][SQLServer JDBC Driver][SQLServer]Could not find stored procedure
'edn_internal_publish_event'.
at
oracle.integration.platform.blocks.event.saq.SAQRemoteBusinessEventConnection.
enqueueEvent(SAQRemoteBusinessEventConnection.java:86)
例41-5には、2つのOracle Mediatorサービス・コンポーネントが示されています。1つのサービス・コンポーネント(OrderPendingEvent)はイベントをサブスクライブし、もう1つのサービス・コンポーネント(PublishOrderPendingEvent)はイベントを公開します。
例41-5 イベントのサブスクリプションと公開
<component name="PublishOrderPendingEvent"> <implementation.mediator src="PublishOrderPendingEvent.mplan"/> <business-events> <publishes xmlns:sub1="/oracle/fodemo/storefront/entities/events/edl/OrderEO" name="pub1:NewOrderSubmitted"/> </business-events> </component> <component name="OrderPendingEvent"> <implementation.mediator src="OrderPendingEvent.mplan"/> <business-events> <subscribe xmlns:sub1="/oracle/fodemo/storefront/entities/events/edl/OrderEO" name="sub1:NewOrderSubmitted" consistency="oneAndOnlyOne" runAsRoles="$publisher"/> </business-events> </component>
この項では、BPELプロセス・サービス・コンポーネントからビジネス・イベントをサブスクライブまたは公開する方法について説明します。
ビジネス・イベントをサブスクライブする手順は、次のとおりです。
「コンポーネント・パレット」からSOAコンポジット・エディタにBPELプロセス・サービス・コンポーネントをドラッグします。
「名前」フィールドに、名前を入力します。他のデフォルトの選択は変更せずに、「OK」をクリックします。
BPELプロセス・サービス・コンポーネントが作成されます。
BPELプロセス・サービス・コンポーネントをダブルクリックします。Oracle BPELデザイナが開きます。または、BPELプロセス・サービス・コンポーネントを右クリックして「編集」をクリックすることもできます。
「コンポーネント・パレット」からSOAコンポジット・エディタのreceiveInputアクティビティの下に、receiveアクティビティをドラッグします。
|
注意: pickアクティビティのonMessageブランチは、EDNからイベントを受信するように設定することもできます。onMessageブランチの詳細は、第15.2項「プロセスの継続または待機を選択するpickアクティビティの作成」を参照してください。 |
receiveアクティビティをダブルクリックします。「Receive」ダイアログが開きます。または、receiveアクティビティを右クリックして「編集」をクリックすることもできます。
「名前」フィールドに、名前を入力します。
「相互作用タイプ」リストで「イベント」を選択します。「Receive」ダイアログのレイアウトが変更されます。
「イベント」フィールドの右側にある「イベントの参照」アイコンをクリックします。図41-7に示すように、「サブスクライブ済イベント」ダイアログが表示されます。
「追加」アイコンをクリックして、イベントを選択します。
図41-8に示すように、「イベント・チューザ」ダイアログが表示されます。
作成したイベントを選択し、「OK」をクリックします。
「サブスクライブ済イベント」ダイアログが再び表示されます。
イベントと一貫性がある配信のレベルを選択します。
唯一
イベントは、それ自体のグローバル(つまりJTA)トランザクションのサブスクライバに配信されます。イベント処理が完了すると、そのトランザクション内でサブスクライバが行ったあらゆる変更がコミットされます。サブスクライバが失敗すると、トランザクションはロールバックされます。失敗したイベントは、設定された回数だけ再試行されます。
保証付き
イベントは、グローバル・トランザクションなしでサブスクライバに非同期で配信されます。サブスクライバは、処理用にサブスクライバ自体のローカル・トランザクションの作成を選択できますが、他のイベント処理とは個別にコミットされます。このオプションでは、1つのキュー(メイン・イベント・キュー)へのトリップのみが存在するため、「1つのみ」オプションよりコストが低くなります。また、EDNではイベントの再送は試行されません(バッキング・ストアがAQであるかJMSであるかにかかわらず)。1人以上のサブスクライバがイベントの使用に失敗すると(他のサブスクライバは成功した場合)、それらのサブスクライバはメッセージを失います。その点において、保証付き配信は、実際にはベスト・エフォートの配信を意味します。つまり、各サブスクライバが確実にメッセージを使用することは保証されません。
即時
イベントは、パブリッシャと同じグローバル・トランザクションとスレッドで、サブスクライバに配信されます。すべての即時サブスクライバが処理を完了するまで、公開コールは返されません。いずれかのサブスクライバが例外をスローすると、追加のサブスクライバは起動されず、例外はパブリッシャにスローされます。即時処理中にエラーが発生した場合、トランザクションはロールバックされます。
イベントをフィルタリングするには、選択したイベントの「フィルタ」列をダブルクリックするか、またはイベントを選択して、表の上の「フィルタ」アイコン(最初のアイコン)をクリックします。これにより「式ビルダー」ダイアログが表示されます。このダイアログで、XPathフィルタ式を指定できます。フィルタ式では、サービスの起動前にメッセージのコンテンツ(ペイロードまたはヘッダー)が分析されるように指定します。たとえば、注文に注文IDが含まれている場合のみサービスを起動することを指定するフィルタ式を適用できます。
式のロジックが満たされると、イベントの配信が可能になります。
「OK」をクリックして「サブスクライブ済イベント」ダイアログを閉じます。「Receive」ダイアログが再び表示されます。
|
注意: このreceiveアクティビティがBPELプロセス・サービス・コンポーネント・インスタンスを起動する起動receiveアクティビティの場合は、必要に応じて「インスタンスの作成」チェック・ボックスを選択できます。この操作によって、すべての起動に対して新しいBPELプロセス・サービス・コンポーネント・インスタンスを作成できます。 この receive アクティビティが中間プロセスの receive アクティビティで、BPELインスタンスがすでに起動されている場合、この receive アクティビティは、そのBPELインスタンスの実行を続行するために、別のイベントを待機します。 |
「OK」をクリックします。
図41-9に、イベント・サブスクリプション用に構成されたBPELプロセス・サービス・コンポーネントを示します。
ビジネス・イベントを公開する手順は、次のとおりです。
「コンポーネント・パレット」からSOAコンポジット・エディタのreceiveアクティビティ(第41.4.1項「ビジネス・イベントをサブスクライブする方法」で作成したアクティビティ)の下に、invokeアクティビティをドラッグします。
invokeアクティビティをダブルクリックします。「Invoke」ダイアログが開きます。または、invokeアクティビティを右クリックして「編集」をクリックすることもできます。
「名前」フィールドに、名前を入力します。
「相互作用タイプ」リストで「イベント」を選択します。「Invoke」ダイアログのレイアウトが変更されます。
「イベント」フィールドの右側にある「イベントの参照」アイコンをクリックします。「イベント・チューザ」ダイアログが表示されます。
作成したイベントを選択し、「OK」をクリックします。
「Invoke」ダイアログが再び表示されます。
「OK」をクリックします。
図41-10は、イベントのサブスクリプションおよび公開用に構成されたBPELプロセス・サービス・コンポーネントを示します。左側にある丸囲みの青い稲妻は、イベントのサブスクリプションを示します。右側にある丸囲みの黄色い稲妻は、イベントの公開を示します。タイトル内の青い矢印をクリックすると、公開されたイベントのタイトルが表示されます。
図41-10 イベント・サブスクリプションおよび公開用のBPELプロセス・サービス・コンポーネントの構成
例41-6のソース・コードに、BPELプロセス・サービス・コンポーネントのサブスクライブおよび公開するイベントに関するcomposite.xmlソース変更の様子を示します。
例41-6 イベントのサブスクリプションと公開
<component name="EventBPELProcess">
<implementation.bpel src="EventBPELProcess.bpel"/>
<property name="configuration.monitorLocation" type="xs:string"
many="false">EventBPELProcess.monitor</property>
<business-events>
<subscribe xmlns:sub1="http://mycompany.com/events/orders"
name="sub1:OrderReceivedEvent" consistency="oneAndOnlyOne"
runAsRoles="$publisher"/>
<publishes xmlns:pub1="http://mycompany.com/events/orders"
name="pub1:ProductSoldAlert"/>
</business-events>
</component>
この例では明示的に示されていませんが、イベントにおいてXPathフィルタを定義できます。フィルタは、通常、イベント・サブスクリプションにあります。subscribe要素によって、このサービス・コンポーネントがサブスクライブされる対象のイベントのタイプが制限され、filterセクションによってさらに、コンポーネントが関連する特定のコンテンツにイベントが制限されます。例41-7では、初期デポジットが50000を超える場合にのみ、イベントの配信が可能になります。
例41-7 イベントに対するXPathフィルタの定義
<business-events>
. . .
. . .
<filter>
<xpath xmlns:be="http://oracle.com/fabric/businessEvent"
xmlns:ns1="http://xmlns.oracle.com/singleString"
<xpath expression= "/be:business-event/be:content/
sub1:AccountInfo/Details[@initialDeposit > 50000]" />
</filter>
. . .
. . .
</business-events>
特別な属性のbpelx:eventNameを使用すると、receive、invoke、onMessageおよびonEvent (BPEL 2.0)などの標準BPELアクティビティが拡張されるため、BPELプロセス・サービス・コンポーネントでEDNイベント・バスからのイベントを受信できます。例41-8に、eventName属性のスキーマを示します。
例41-8 Eventname属性のスキーマ
<xs:attribute name="eventName" type="xs:QName">
<xs:annotation>
<xs:appinfo>
<tns:parent>
<bpel11:onMessage/>
<bpel11:receive/>
<bpel11:invoke/>
</tns:parent>
</xs:appinfo>
</xs:annotation>
</xs:attribute>
例41-9に、BPELソース・ファイルでのeventName属性の使用方法を示します。
例41-9 eventName属性を使用したBPELソース・コード
<receive name="OrderPendingEvent" createInstance="yes"
bpelx:eventName="ns1:OrderReceivedEvent"/>
<invoke name="Invoke_1" bpelx:eventName="ns1:ProductSoldAlert"/>
bpelx:eventName属性をreceive、invoke、onMessageまたはonEvent (BPEL 2.0)要素で使用した場合、partnerLink、operationまたはportType属性などの標準属性は存在しません。これは、bpelx:eventName属性の存在が、このアクティビティがEDNイベント・バスからのイベントの受信またはEDNイベント・バスへのイベントの公開のみを対象としていることを表しているためです。
BPELプロセス・サービス・コンポーネントのXSDファイルは若干変更され、partnerLink、operationおよびportType属性は必須ではなくなりました。bpelx:eventName属性、またはpartnerLink、operationおよびportType属性(どちらか一方)の存在については、JDeveloperで検証ロジックを実施されます。例41-10に、BPELのreceiveアクティビティの変更されたスキーマ定義を示します。
例41-10 BPELのreceiveアクティビティのスキーマ定義
<complexType name="tReceive">
<complexContent>
<extension base="bpws:tExtensibleElements">
<sequence>
<element name="correlations" type="bpws:tCorrelations" minOccurs="0"/>
<group ref="bpws:activity"/>
</sequence>
<!- BPEL mandatory attributes relaxed to optional for supporting BPEL-EDN ->
<attribute name="partnerLink" type="NCName" use="optional"/>
<attribute name="portType" type="QName" use="optional"/>
<attribute name="operation" type="NCName" use="optional"/>
<attribute name="variable" type="NCName" use="optional"/>
</extension>
</complexContent>
</complexType>
invokeおよびonMessageアクティビティのスキーマ定義も同様に変更されています。
SOAコンポジット・アプリケーションのデフォルト以外のリビジョンに存在するサブスクライバでも、ビジネス・イベントを取得できます。たとえば、次の動作に注意してください。
ビジネス・イベントをサブスクライブする手順は、次のとおりです。
S1という最初のOracle Mediatorサービス・コンポーネントまたはBPELプロセス・サービス・コンポーネントと、S2という2番目のOracle Mediatorサービス・コンポーネントまたはBPELプロセス・サービス・コンポーネントを含む、コンポジット・アプリケーションを作成します。S1はイベントを公開し、S2はイベントをサブスクライブします。出力はディレクトリに書き込まれます。
コンポジット・アプリケーションをリビジョン1としてデプロイします。
コンポジット・アプリケーションを変更して、S3という3番目のOracle Mediatorサービス・コンポーネントまたはBPELプロセス・サービス・コンポーネントを追加します。S3は、同じイベントをサブスクライブし、別のディレクトリに出力を書き込みます。
コンポジット・アプリケーションをリビジョン2(デフォルト)としてデプロイします。
リビジョン2のコンポジット・アプリケーションを起動します。
サービス・コンポーネントS2は、同じ内容の出力をディレクトリ内の2つのファイルに書き込みます。サービス・コンポーネントS3は、予想どおりに、イベントを取得し、別のディレクトリに出力を正常に書き込みます。しかし、(リビジョン1の)サービス・コンポーネントS2も、コンポジット・アプリケーションのリビジョン2から公開されたイベントを取得し、処理しています。したがって、同じディレクトリ内にもう1つ出力ファイルが作成されます。
この項では、Oracle ADF Business Componentイベント条件をSOAコンポーネントに統合する方法に関する高レベルな概要が提供されます。SOAコンポーネントには、Oracle Mediatorサービス・コンポーネントとBPELプロセス・サービス・コンポーネントが含まれています。
Oracle ADF Business Componentのビジネス・イベントをSOAコンポーネントに統合する手順は、次のとおりです。
ビジネス・コンポーネント・プロジェクトを作成します。
ビジネス・イベント定義をプロジェクトに追加します。このアクションにより、EDLファイルおよびXSDファイルが生成されます。XSDファイルにはペイロードの定義が含まれます。また、作成時には、Oracle ADF Business Componentによってイベントが発生するように必ず指定します。
Oracle ADF Business Componentビジネス・イベントの作成および公開の詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド』を参照してください。
SOAコンポジット・アプリケーションを作成し、EDLスキーマ・ファイルとXSDスキーマ・ファイルをSOAプロジェクトのルート・ディレクトリに手動でコピーします。例:
JDeveloper/mywork/SOA_application_name/SOA_project_name
スキーマ・ファイルを、インポートに基づいて、EDLファイルからの適切な相対位置に格納します。
第41.3.1項「ビジネス・イベントをサブスクライブする方法」の説明に従って、Oracle Mediatorサービス・コンポーネントを作成します。
第41.3.1項「ビジネス・イベントをサブスクライブする方法」の説明に従って、「イベント・チューザ」ウィンドウでイベントのEDLファイルを選択します。
Oracle Mediatorを起動するために、同じSOAコンポジット・アプリケーション内にBPELプロセス・サービス・コンポーネントを作成します。「詳細」タブの「入力要素」フィールドでは、ステップ2で作成したBusiness Componentビジネス・イベントXSDのペイロードを必ず選択します。
BPELプロセス・サービス・コンポーネントをダブルクリックします。
emailアクティビティをBPELプロセス・サービス・コンポーネントにドラッグします。
ビジネス・イベントXSDのペイロードを参照して、「件名」フィールドおよび「本文」フィールドに入力します。
SOAコンポジット・エディタのOracle Mediatorサービス・コンポーネントに戻ります。
BPELプロセス・サービス・コンポーネントまたは2番目のOracle Mediatorサービス・コンポーネントのように、イベントを公開する2番目のサービス・コンポーネントを設計します。
これで、SOAコンポジット・アプリケーションの設計は完了です。
