| Oracle Fusion Middleware Oracle SOA Suite開発者ガイド 11g リリース1（11.1.1） B56238-02 |
|
 戻る |
 次へ |
この章では、SOAコンポジット・アプリケーションでビジネス・イベントを公開し、サブスクライブする方法を説明します。ビジネス・イベントは、ビジネス環境で発生した結果として送信されるメッセージ・データから構成されます。ビジネス・イベントが公開されると、他のサービス・コンポーネントはそれをサブスクライブできます。
項目は次のとおりです。
第39.3項「Oracle Mediatorサービス・コンポーネントからのビジネス・イベントのサブスクライブまたは公開」
第39.6項「Oracle ADF Business Componentビジネス・イベントをOracle Mediatorに統合する方法」
Oracle Mediatorでビジネス・イベントを使用する方法を示したサンプルは、次のURLを参照してください。
https://soasamples.samplecode.oracle.com/#mediator
目的の状況が発生した場合は、ビジネス・イベントを発生させることができます。たとえば、融資フロー・シナリオにおいて、融資プロセスを実行するBPELプロセス・サービス・コンポーネントは、プロセスの完了時に融資完了イベントを発生させることができます。このアプリケーションのインフラストラクチャの範囲内で、他のシステムはこれらのイベントをリスニングし、イベントの受信時に次の処理を実行できます。
イベント・コンテキストを使用して、ビジネス・インテリジェンスまたはダッシュボード・データを導出します。
融資パッケージを顧客に送る必要があることをメール部門に知らせます。
別のビジネス・プロセスを起動します。
Oracle Business Activity Monitoring（BAM）に情報を送信します。
ビジネス・イベントは通常、一方向（fire-and-forget）、非同期方式でビジネス発生の通知を送信します。ビジネス・プロセスには、次のような特徴があります。
ビジネス・イベントの完了を受信するサービス・コンポーネントに依存しません。
他のサービス・コンポーネントがビジネス・イベントを受信しても関係ありません。
サブスクライバの存在（存在する場合）およびデータがサブスクライバに与える影響を知る必要がありません。
これらは、Web Services Description Language（WSDL）ファイル規定に依存する直接サービス起動（Simple Object Access Protocolサービス・クライアントなど）とビジネス・イベントの重要な相違点です。イベントの発生がイベントの受信者に依存する場合、メッセージは通常、ビジネス・イベントではなくサービス起動を通して配信する必要があります。直接サービス起動とは異なり、ビジネス・イベントはサーバーからクライアントを分離します。
ビジネス・イベントは、イベント定義言語（EDL）を使用して定義されます。EDLは、ビジネス・イベント定義の作成に使用するスキーマです。アプリケーションは、ビジネス・イベント定義のインスタンスと協調して動作します。
EDLの構成内容は次のとおりです。
グローバル名
通常はJavaパッケージ名（com.acme.ExpenseReport.createdなど）ですが、必須ではありません。
ペイロード定義
定義には、XMLスキーマ（XSD）が最も一般的に使用されます。ビジネス・イベントのペイロードはXSDを使用して定義されます。スキーマのURIは、ペイロードのルート要素に含まれます。
例39-1に、BugReportイベント定義内に2つのビジネス・イベントbugUpdatedおよびbugCreatedがあるEDLファイルを示します。ネームスペース（BugReport）および関連するスキーマ・ファイル（BugReport.xsd）が参照されます。
例39-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のサブスクリプションで使用できます。
ビジネス・イベントは、メタデータ・サービス（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）内に存在する場合、イベントはリモート・イベント接続を通して発生します。リモート・イベント接続では、非同期サブスクリプションのみがサポートされます。
PL/SQL APIを通してイベントを発生させることもできます。
別のアプリケーション（Oracle ADF Business Componentアプリケーションなど）を構成し、SOAコンポジット・アプリケーションと同じコンテナ内で実行すると、このアプリケーションはローカル・イベント接続を使用するように最適化されます。イベントの境界は、アプリケーション・インスタンスです。イベントがアプリケーション・インスタンス内で発生すると、アプリケーション・インスタンスに登録されたサブスクリプションが実行されます。イベントは、1つのアプリケーション・インスタンスから別のインスタンスに伝播されません。伝播は、イベントをリスニングし、イベントをJMSキューに公開するOracle Mediatorを通して、両方のインスタンスで可能になります。
この項では、ビジネス・イベントの作成方法およびサブスクライブ方法の高レベルな概要が提供されます。このシナリオでは、ストアフロント・アプリケーション（StoreFrontServiceサービス）でユーザーから注文を受けたときに、NewOrderSubmittedというビジネス・イベントが作成されます。その後、このビジネス・イベントをサブスクライブするOracle Mediatorサービス・コンポーネントを作成します。
ビジネス・イベントを作成する手順は、次のとおりです。
SOAプロジェクトを空のコンポジットとして作成します。
次の2つの方法のいずれかにより、イベント定義の作成ウィザードを起動します。
SOAコンポジット・エディタで、デザイナの上のアイコンをクリックします。図39-1に例を示します。
「ファイル」メイン・メニューから、「新規」→「SOA層」→「サービス・コンポーネント」→「イベント定義」の順に選択します。
「イベント定義の作成」ダイアログが表示されます。
表39-1に記載されている詳細を入力します。
「追加」アイコンをクリックして、イベントを追加します。
「イベントの追加」ダイアログが表示されます。
「検索」アイコンをクリックしてペイロードを選択し、「OK」をクリックします。図39-2に詳細を示します。
図39-3に示すように、「名前」フィールドに名前を入力します。
「OK」をクリックします。
図39-4に示すように、追加したイベントが「イベント」セクションに表示されます。
エディタの上部にある、event_definition_name.edlの横のxアイコンをクリックして、イベント・エディタを閉じます。
変更を保存するように求められた場合は、「はい」をクリックします。変更を保存しないとイベントは作成されず、「イベント・チューザ」ウィンドウでは選択できません。
ビジネス・イベントがMDSに公開され、SOAコンポジット・エディタに戻ります。「リソース・パレット」に、ビジネス・イベントが表示され参照できます。
この項では、Oracle Mediatorサービス・コンポーネントからビジネス・イベントをサブスクライブまたは公開する方法について説明します。
ビジネス・イベントをサブスクライブする手順は、次のとおりです。
「コンポーネント・パレット」からSOAコンポジット・エディタに、メディエータ・サービス・コンポーネントをドラッグします。このサービス・コンポーネントにより、ビジネス・イベントをサブスクライブできます。
「名前」フィールドに、名前を入力します。
「オプション」リストから、「イベントのサブスクライブ」を選択します。
ウィンドウがリフレッシュされ、イベント表が表示されます。
「追加」アイコンをクリックして、イベントを選択します。
「イベント・チューザ」ウィンドウが表示されます。
作成したイベントを選択し、「OK」をクリックします。
「メディエータの作成」ダイアログが再び表示されます。
イベントと一貫性がある配信のレベルを選択します。
唯一
イベントは、それ自体のグローバル（つまりJTA）トランザクションのサブスクライバに配信されます。イベント処理が完了すると、そのトランザクション内でサブスクライバが行ったあらゆる変更がコミットされます。サブスクライバが失敗すると、トランザクションはロールバックされます。失敗したイベントは、設定された回数だけ再試行されます。
保証付き
イベントは、グローバル・トランザクションなしでサブスクライバに非同期で配信されます。サブスクライバは、独自のローカル・トランザクションを作成して処理できますが、そのトランザクションは、残りのイベント処理とは別にコミットされます。イベントはサブスクライバに渡されることが保証されていますが、グローバル・トランザクションがないため、システムの障害が原因でイベントが2回以上配信される可能性があります。サブスクライバが例外をスローすると（または失敗すると）、例外は記録されますが、イベントは再送信されません。
即時
イベントは、パブリッシャと同じグローバル・トランザクションとスレッドで、サブスクライバに配信されます。すべての即時サブスクライバが処理を完了するまで、公開コールは返されません。いずれかのサブスクライバが例外をスローすると、追加のサブスクライバは起動されず、例外はパブリッシャにスローされます。即時処理中にエラーが発生した場合、トランザクションはロールバックされます。
イベントをフィルタリングするには、選択したイベントの「フィルタ」列をダブルクリックするか、またはイベントを選択して、表の上の「フィルタ」アイコン（最初のアイコン）をクリックします。これにより「式ビルダー」ダイアログが表示されます。このダイアログで、XPathフィルタ式を指定できます。フィルタ式では、サービスの起動前にメッセージのコンテンツ（ペイロードまたはヘッダー）が分析されるように指定します。たとえば、メッセージに顧客IDが含まれている場合のみサービスを起動することを指定するフィルタ式を適用できます。
式のロジックが満たされると、イベントの配信が可能になります。
フィルタの詳細は、第20.2.2.7項「メッセージをフィルタリングする式の指定方法」を参照してください。
図39-5は、「メディエータの作成」ダイアログを示しています。
「OK」をクリックします。
図39-6に、イベント・サブスクリプションのためにOracle Mediatorが構成されたことを示す左側のアイコンを示します。
例39-2のソース・コードに、Oracle Mediatorサービス・コンポーネントのサブスクライブするイベントに関する詳細を示します。
例39-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フィルタを定義できます。例39-3では、頭金が50000を超える場合にのみ、イベントの配信が可能になります。
例39-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つ出力ファイルが作成されます。
第39.3.1項「ビジネス・イベントをサブスクライブする方法」でサブスクライブしたイベントを公開するための、2番目のOracle Mediatorを作成できます。
ビジネス・イベントを公開する手順は、次のとおりです。
最初のOracle Mediatorがサブスクライブしたイベントを公開する、2番目のOracle Mediatorサービス・コンポーネントを作成します。
最初のOracle Mediatorサービス・コンポーネントに戻ります。
「ルーティング・ルール」セクションで、「追加」アイコンをクリックします。
「ターゲット・タイプ」ウィンドウでプロンプトが表示されたら、「サービス」をクリックします。
2番目のOracle Mediatorサービス・コンポーネントを選択します。
「ファイル」メイン・メニューから「すべて保存」を選択します。
例39-4には、2つのOracle Mediatorサービス・コンポーネントが示されていることに注意してください。1つのサービス・コンポーネント（OrderPendingEvent）はイベントをサブスクライブし、もう1つのサービス・コンポーネント（PublishOrderPendingEvent）はイベントを公開します。
例39-4 イベントのサブスクリプションと公開
<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>
この項のトピックは、次のとおりです。
ビジネス・イベントをサブスクライブする手順は、次のとおりです。
「コンポーネント・パレット」からSOAコンポジット・エディタにBPELプロセス・サービス・コンポーネントをドラッグします。
「名前」フィールドに、名前を入力します。他のデフォルトの選択は変更せずに、「OK」をクリックします。
BPELプロセス・サービス・コンポーネントが作成されます。
BPELプロセス・サービス・コンポーネントをダブルクリックします。Oracle BPELデザイナが開きます。または、BPELプロセス・サービス・コンポーネントを右クリックして「編集」をクリックすることもできます。
「コンポーネント・パレット」からSOAコンポジット・エディタのreceiveInputアクティビティの下に、receiveアクティビティをドラッグします。
|
注意: pickアクティビティのonMessageノードを設定して、EDNからイベントを受信することもできます。onMessageノードの詳細は、第5.4項「タイムアウト付き非同期相互作用の概要」を参照してください。 |
receiveアクティビティをダブルクリックします。図39-7に示すように、「Receive」ダイアログが開きます。または、receiveアクティビティを右クリックして「編集」をクリックすることもできます。
「名前」フィールドに、名前を入力します。
「相互作用タイプ」リストで「イベント」を選択します。図39-8に示すように、「Receive」ダイアログのレイアウトが変更されます。
「イベント」フィールドの右側にある「イベントの参照...」アイコンをクリックします。図39-9に示すように、「サブスクライブ済イベント」ダイアログが表示されます。
「追加」アイコンをクリックして、イベントを選択します。
図39-10に示すように、「イベント・チューザ」ダイアログが表示されます。
作成したイベントを選択し、「OK」をクリックします。
「サブスクライブ済イベント」ダイアログが再び表示されます。
イベントと一貫性がある配信のレベルを選択します。
唯一
イベントは、それ自体のグローバル（つまりJTA）トランザクションのサブスクライバに配信されます。イベント処理が完了すると、そのトランザクション内でサブスクライバが行ったあらゆる変更がコミットされます。サブスクライバが失敗すると、トランザクションはロールバックされます。失敗したイベントは、設定された回数だけ再試行されます。
保証付き
イベントは、グローバル・トランザクションなしでサブスクライバに非同期で配信されます。サブスクライバは、独自のローカル・トランザクションを作成して処理できますが、そのトランザクションは、残りのイベント処理とは別にコミットされます。イベントはサブスクライバに渡されることが保証されていますが、グローバル・トランザクションがないため、システムの障害が原因でイベントが2回以上配信される可能性があります。サブスクライバが例外をスローすると（または失敗すると）、例外は記録されますが、イベントは再送信されません。
即時
イベントは、パブリッシャと同じグローバル・トランザクションとスレッドで、サブスクライバに配信されます。すべての即時サブスクライバが処理を完了するまで、公開コールは返されません。いずれかのサブスクライバが例外をスローすると、追加のサブスクライバは起動されず、例外はパブリッシャにスローされます。即時処理中にエラーが発生した場合、トランザクションはロールバックされます。
イベントをフィルタリングするには、選択したイベントの「フィルタ」列をダブルクリックするか、またはイベントを選択して、表の上の「フィルタ」アイコン（最初のアイコン）をクリックします。これにより「式ビルダー」ダイアログが表示されます。このダイアログで、XPathフィルタ式を指定できます。フィルタ式では、サービスの起動前にメッセージのコンテンツ（ペイロードまたはヘッダー）が分析されるように指定します。たとえば、注文に注文IDが含まれている場合のみサービスを起動することを指定するフィルタ式を適用できます。
式のロジックが満たされると、イベントの配信が可能になります。
「OK」をクリックして「サブスクライブ済イベント」ダイアログを閉じます。「Receive」ダイアログが再び表示されます。
|
注意: このreceiveアクティビティがBPELプロセス・サービス・コンポーネント・インスタンスを起動する起動receiveアクティビティの場合は、必要に応じて「インスタンスの作成」チェック・ボックスを選択できます。この操作によって、すべての起動に対して新しいBPELプロセス・サービス・コンポーネント・インスタンスを作成できます。
この |
「OK」をクリックします。
図39-6に、イベント・サブスクリプション用に構成されたBPELプロセス・サービス・コンポーネントを示します。
図39-11 イベント・サブスクリプション用のBPELプロセス・サービス・コンポーネントの構成
ビジネス・イベントを公開する手順は、次のとおりです。
「コンポーネント・パレット」からSOAコンポジット・エディタのreceiveアクティビティ（第39.4.1項「ビジネス・イベントをサブスクライブする方法」で作成したアクティビティ）の下に、invokeアクティビティをドラッグします。
invokeアクティビティをダブルクリックします。図39-12に示すように、「Invoke」ダイアログが開きます。または、invokeアクティビティを右クリックして「編集」をクリックすることもできます。
「名前」フィールドに、名前を入力します。
「相互作用タイプ」リストで「イベント」を選択します。図39-13に示すように、「Invoke」ダイアログのレイアウトが変更されます。
「イベント」フィールドの右側にある「イベントの参照...」アイコンをクリックします。「イベント・チューザ」ウィンドウが表示されます。
作成したイベントを選択し、「OK」をクリックします。
「Invoke」ダイアログが再び表示されます。
「OK」をクリックします。
図39-14に、イベント・サブスクリプションおよび公開用に構成されたBPELプロセス・サービス・コンポーネントを示します。
図39-14 イベント・サブスクリプションおよび公開用のBPELプロセス・サービス・コンポーネントの構成
例39-2のソース・コードに、BPELプロセス・サービス・コンポーネントのサブスクライブおよび公開するイベントに関するcomposite.xmlソース変更の様子を示します。
例39-5 イベントのサブスクリプションと公開
<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フィルタを定義できます。例39-6では、頭金が50000を超える場合にのみ、イベントの配信が可能になります。
例39-6 イベントに対する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などの標準BPELアクティビティが拡張されるため、BPELプロセス・サービス・コンポーネントでEDNイベント・バスからのイベントを受信できます。例39-7に、eventName属性のスキーマを示します。
例39-7 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>
例39-8に、BPELソース・ファイルでのeventName属性の使用方法を示します。
例39-8 eventName属性を使用したBPELソース・コード
<receive name="OrderPendingEvent" createInstance="yes"
bpelx:eventName="ns1:OrderReceivedEvent"/>
<invoke name="Invoke_1" bpelx:eventName="ns1:ProductSoldAlert"/>
bpelx:eventName属性をreceive、invokeまたはonMessage要素で使用した場合、partnerLink、operationまたはportType属性などの標準属性は存在しません。これは、bpelx:eventName属性の存在が、このアクティビティがEDNイベント・バスからのイベントの受信またはEDNイベント・バスへのイベントの公開のみを対象としていることを表しているためです。
BPELプロセス・サービス・コンポーネントのXSDファイルは若干変更され、partnerLink、operationおよびportTyp属性は必須ではなくなりました。bpelx:eventName属性、またはpartnerLink、operationおよびportTyp属性（どちらか一方）の存在については、JDeveloperで検証ロジックを実施する必要があります。例39-9に、BPELのreceiveアクティビティの変更されたスキーマ定義を示します。
例39-9 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という最初のMediatorサービス・コンポーネントまたはBPELプロセス・サービス・コンポーネントと、S2という2番目のMediatorサービス・コンポーネントまたはBPELプロセス・サービス・コンポーネントを含む、コンポジット・アプリケーションを作成します。S1はイベントを公開し、S2はイベントをサブスクライブします。出力はディレクトリに書き込まれます。
コンポジット・アプリケーションをリビジョン1としてデプロイします。
コンポジット・アプリケーションを変更して、S3という3番目のMediatorサービス・コンポーネントまたはBPELプロセス・サービス・コンポーネントを追加します。S3は、同じイベントをサブスクライブし、別のディレクトリに出力を書き込みます。
コンポジット・アプリケーションをリビジョン2（デフォルト）としてデプロイします。
リビジョン2のコンポジット・アプリケーションを起動します。
サービス・コンポーネントS2は、同じ内容の出力をディレクトリ内の2つのファイルに書き込むことに注意してください。サービス・コンポーネントS3は、予想どおりに、イベントを取得し、別のディレクトリに出力を正常に書き込みます。しかし、（リビジョン1の）サービス・コンポーネントS2も、コンポジット・アプリケーションのリビジョン2から公開されたイベントを取得し、処理しています。したがって、同じディレクトリ内にもう1つ出力ファイルが作成されます。
この項では、Oracle ADF Business Componentイベント条件をSOAコンポーネントに統合する方法に関する高レベルな概要が提供されます。SOAコンポーネントには、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ファイルからの適切な相対位置に格納します。
第39.3.1項「ビジネス・イベントをサブスクライブする方法」の説明に従って、Mediatorサービス・コンポーネントを作成します。
第39.3.1項「ビジネス・イベントをサブスクライブする方法」の説明に従って、「イベント・チューザ」ウィンドウでイベントのEDLファイルを選択します。
Oracle Mediatorを起動するために、同じSOAコンポジット・アプリケーション内にBPELプロセス・サービス・コンポーネントを作成します。「詳細」タブの「入力要素」フィールドでは、手順2で作成したBusiness Componentビジネス・イベントXSDのペイロードを必ず選択します。
BPELプロセス・サービス・コンポーネントをダブルクリックします。
emailアクティビティをBPELプロセス・サービス・コンポーネントにドラッグします。
ビジネス・イベントXSDのペイロードを参照して、「件名」フィールドおよび「本文」フィールドに入力します。
SOAコンポジット・エディタのOracle Mediatorサービス・コンポーネントに戻ります。
BPELプロセス・サービス・コンポーネントまたは2番目のOracle Mediatorサービス・コンポーネントのように、イベントを公開する2番目のサービス・コンポーネントを設計します。
これで、SOAコンポジット・アプリケーションの設計は完了です。
