| Oracle® Fusion Middleware Oracle SOA SuiteでのSOAアプリケーションの開発 12c (12.2.1.2.0) E82771-02 |
|
 前 |
 次 |
この章の内容は次のとおりです。
Oracle JDeveloperでのビジネス・イベントの作成
Oracle ADF Business Componentビジネス・イベントをOracle Mediatorに統合する方法
ビジネス・イベントをサブスクライブするサービス・コンポーネントでのコンポジット・センサーの作成の詳細は、「コンポジット・センサーの定義」を参照してください。
スレッド数の指定、イベント配信の停止、最大配信数の指定などビジネス・イベントのトラブルシューティングの詳細は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』の付録「Oracle SOA SuiteおよびOracle BPM Suiteのトラブルシューティング」を参照してください。
Oracle Enterprise Manager Fusion Middleware Controlからのビジネス・イベントの管理の詳細は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』の「ビジネス・イベントの管理」を参照してください。
ビジネス・イベント・チューニングの詳細は、『パフォーマンスのチューニング』を参照してください。
目的の状況が発生したときにビジネス・イベントを起動できます。たとえば、ローン・フローのシナリオで、ローン・プロセスを実行しているBPELプロセス・サービス・コンポーネントは、プロセスの完了時にローン完了イベントを起動できます。このアプリケーションのインフラストラクチャ内の他のシステムは、これらのイベントをリスニングし、イベントのインスタンスの受信時に次の処理を実行できます。
イベント・コンテキストを使用して、ビジネス・インテリジェンスまたはダッシュボード・データを導出します。
融資パッケージを顧客に送る必要があることをメール部門に知らせます。
別のビジネス・プロセスを起動します。
Oracle Business Activity Monitoring (BAM)に情報を送信します。
通常、ビジネス・イベントは、ビジネスの状態変化に関する通知を送信するための一方向のfire-and-forget非同期方法です。ビジネス・プロセスは、次の処理を行いません。
ビジネス・イベントの完了を受信するサービス・コンポーネントに依存しません。
他のサービス・コンポーネントがビジネス・イベントを受信しても関係ありません。
サブスクライバの存在(存在する場合)およびデータがサブスクライバに与える影響を知る必要がありません。
これらは、Web Services Description Language (WSDL)ファイル規定に依存する直接サービス起動(SOAPサービス・クライアントなど)とビジネス・イベントの重要な相違点です。イベントの発生がイベントの受信者に依存する場合、メッセージは通常、ビジネス・イベントではなくサービス起動を通して配信する必要があります。直接サービス起動とは異なり、ビジネス・イベントはサーバーからクライアントを分離します。
ビジネス・イベントは、イベント定義言語(EDL)を使用して定義されます。EDLは、ビジネス・イベント定義の作成に使用するスキーマです。アプリケーションは、ビジネス・イベント定義のインスタンスと協調して動作します。
EDLは、次のもので構成されます。
定義済イベント
同じネームスペース(definitionsルート要素のtargetNamespace属性)を持つ1つ以上のイベント定義(event-definition要素)の場合、それぞれがローカル名(event-definition要素のname属性)を持ちます。ネームスペースおよびローカル名は、イベント名(QName)を構成します。
ペイロード定義
定義には、XMLスキーマ(XSD)が最も一般的に使用されます。ビジネス・イベントのペイロードは、(schema-import要素を介して)EDLにインポートされたXSDで定義されます。定義済の各イベント(つまりevent-definition要素)には、インポートされたペイロードのXSD要素(content要素のelement属性)への参照を含めることができます。スキーマのURIは、ペイロードのルート要素に含まれます。
次の例は、BugReportイベント定義内に2つのビジネス・イベントbugUpdatedおよびbugCreatedがあるEDLファイルを示しています。ネームスペース(/model/events/edl/BugReport)および関連するスキーマ・ファイル(BugReport.xsd)が参照されます。
<?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およびBPELプロセスのサブスクリプションで使用できます。
ビジネス・イベントは、Oracle Metadata Servicesリポジトリ(MDSリポジトリ)にデプロイされます。ビジネス・イベントをそのアーティファクト(XSDなど)とともにMDSリポジトリにデプロイすることを、EDL (またはイベント定義)の公開とも呼びます。このアクションにより、EDLおよびそのアーティファクトがMDSリポジトリ内の共有領域に転送されます。MDSリポジトリ共有領域内のオブジェクトは、Oracle JDeveloperの「リソース」ウィンドウ内のすべてのアプリケーションで参照できます。EDLは公開後、Oracle MediatorやBPELプロセスなどのSOAコンポーネントでサブスクライブできます。
サブスクリプションは、特定の修飾名(QName)(x.y.z/newOrdersなど)に対して行います。QNameはタプル(URI、localName)であり、xmlns:prefix=URIなどのネームスペース宣言またはネームスペース・コンテキストとの組合せで、文字列prefix:localNameから導出できます。また、コンテンツ・ベースのフィルタを使用すると、サブスクリプションをさらに絞り込むことができます。
ビジネス・イベントは、EDNに公開されます。EDNはOracle SOA Suiteの各インスタンス内で実行されます。発生したイベントはEDNにより、サブスクライブするサービス・コンポーネントに配信されます。Oracle Mediatorサービス・コンポーネントとBPELプロセス・サービス・コンポーネントはイベントをサブスクライブし、公開できます。
EDNは、Oracle SOA SuiteコンポーネントとOracle SOA Suite以外のコンポーネントとの間のビジネス・イベントベースの相互作用をサポートする、標準のJMSメッセージング・インフラストラクチャに基づいています。EDNは次の2つのJMSベースのタイプを提供します。
Oracle WebLogic Server JMS: デフォルトでは、すべてのビジネス・イベントで、1つのデフォルトOracle WebLogic Server JMSトピックを使用します。
Oracle Advanced Queueing (AQ) JMS
追加のJMSトピック(Oracle WebLogic Server JMSまたはAQ JMS)を作成して、Oracle Enterprise Manager Fusion Middleware Controlでこれらの追加のJMSトピックに別々のイベント・タイプをマッピングできます。
Oracle SOA Suite EDNには、次の機能があります。
次の機能を備えた標準JMSベースのメッセージング・インフラストラクチャ。
JMSベースのイベントが、Oracle SOA SuiteクライアントおよびOracle SOA Suite以外のクライアント用のアーキテクチャを公開およびサブスクライブします。
双方向の相互作用をサポートします(Oracle SOA SuiteとOracle SOA Suite以外のクライアント間で公開とサブスクライブの両方を実行できます)。
Oracle AQ JMSおよびOracle WebLogic Server JMSプロバイダの両方をサポートします。Oracle WebLogic Server JMSトピック(デフォルト)およびAQ JMSトピックは、インストール後にEDNを使用できるよう自動的に構成されます。デフォルトのJMSタイプは、Oracle Enterprise Manager Fusion Middleware Controlで、Oracle WebLogic Server JMS (デフォルト)からAQ JMSに切替え可能です。詳細は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』の「ビジネス・イベント」ページでのJMSトピック宛先へのビジネス・イベントのマッピングに関する項を参照してください。
EDNが軽量マネージャとして、前述のJMSプロバイダをサポートします。
プレーンJMS APIおよびOracle SOA Suite、リモート用に値を追加したEDN API、Oracle SOA Suiteとの統合に使用するOracle SOA Suite以外のクライアント。詳細は、を参照してください
EDN配信を保証するJMSトランザクション(OAOO (one-and-only-one)と一貫性保証済メソッドの両方)。
メッセージ・ロスを防ぐ、永続的な公開配信オプション。これらのデフォルト・オプションは、リモートのOracle SOA Suite以外のクライアントとの相互作用に役立ちます。
多数のJMSの機能の実装に内部で使用されるJMSアダプタ。JMSアダプタの詳細は、『テクノロジ・アダプタの理解』の「JMS用のOracle JCAアダプタ」を参照してください。
マルチノード・クラスタではイベントを重複して処理しません。
非常に詳細なレベルのスケーラビリティ。これにより、様々なイベントを様々なJMSトピックの接続先にマッピングできるので、1箇所ですべてのイベントを処理する必要がなくなります。これにより、ボトルネックの可能性がなくなります。マッピングは、Oracle Enterprise Manager Fusion Middleware Controlの管理者が実行します。詳細は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』のJMSトピックの接続先へのビジネス・イベントのマッピングに関する項を参照してください。
次の公開およびサブスクライブのシナリオをサポートします。
同じコンポジット間または別のコンポジット間でイベントを公開およびサブスクライブします。
自動的に提供されるデフォルトEDN Oracle WebLogic Server JMSトピックを使用します。
Oracle Enterprise Manager Fusion Middleware Controlで提供される、イベントからJMSトピックへのカスタム・マッピングを使用します。
次のいずれかのAPIを使用して、リモートのOracle SOA Suite以外の参加者からイベントを公開およびサブスクライブします。
プレーンJMS API (J2SEクライアント環境用)
EDI API EdnJmsConnection (J2SEおよびJ2EEクライアント環境用)
エラー・ホスピタルでインスタンス・トラッキングおよびフォルト・リカバリをサポートします。詳細は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』を参照してください。
MDSリポジトリのEDLファイルの記憶域。これにより、ファイルをOracle JDeveloperの「リソース」ウィンドウで参照できます。詳細は、「デザインタイムとの共有データの管理」を参照してください。
注意:
Oracle AQ JMSによるイベント配信ネットワーク(EDN)で大規模なペイロードを送信する際のメモリーの推奨サイズについては、「SOAコンポジット・アプリケーション用JVMメモリーのサイズ設定の推奨事項」を参照してください。
Oracle SOA Suiteでイベントを公開およびサブスクライブするリモート・クライアントには、APIオプションがいくつかあります。表42-1に詳細を示します。
表42-1 リモートAPIオプション
| オプション | 説明 | サポート | メリット/デメリット |
|---|---|---|---|
プレーンJMS API |
EDN JMSトピックとの直接対話に使用します。これは通常、RAW JMSアクセスを使用するJ2SEクライアントです。 リモート・クライアントでは、SOAサーバーを指すようにJNDIプロパティを構成する必要があります。 |
|
このメリットは、次のとおりです。
このデメリットは、次のとおりです。
|
EDN API - |
Oracle Event ProcessingなどのJ2SEクライアント用です。このオプションには、標準の公開およびサブスクライブ・オプションがすべて用意されています。 リモート・クライアントでは次のタスクを実行する必要があります。
|
|
このメリットは、次のとおりです。
このデメリットは、次のとおりです。
JMSアダプタの詳細は、『テクノロジ・アダプタの理解』の「JMS用のOracle JCAアダプタ」を参照してください。 |
EDN APIの詳細は、を参照してください。
イベント配信ネットワーク(EDN)ビジネス・イベントを公開する場合、ほとんどのプロパティではBusinessEvent.setProperty(String name, Object value) APIを呼び出して手動設定することはできません。
次のEDNビジネス・イベント・プロパティは設定しないでください。これらのプロパティの値は内部で設定され、EDNによって使用されます。
一般プロパティ:
BusinessEvent.EVENT_ID ("id")
BusinessEvent.PARENT_ID ("parent-id")
BusinessEvent.PUBLISHED_TIME ("published-time")
BusinessEvent.OWNER ("owner")
BusinessEvent.SOURCE ("source")
BusinessEvent.MODE ("mode")
すべてのトラッキング・プロパティの例:
BusinessEvent.PROPERTY_ECID ("tracking.ecid")
BusinessEvent.PROPERTY_COMPOSITE_INSTANCE_ID ("tracking.compositeInstanceId")
BusinessEvent.PROPERTY_PARENT_COMPONENT_INSTANCE_ID ("tracking.parentComponentInstanceId")
BusinessEvent.PROPERTY_CONVERSATION_ID ("tracking.conversationId")
tracking.compositeInstanceCreatedTime"
1つのSOAコンポジット・アプリケーション・インスタンスは、1つのコンテナ内に配置することも、複数のコンテナにわたってクラスタ化することもできます。別のアプリケーション(Oracle Application Development Framework (ADF) Business Componentアプリケーションなど)を構成し、SOAコンポジット・アプリケーション・インスタンスと同じコンテナ内または異なるコンテナ内で実行できます。
ローカル・イベント接続またはリモート・イベント接続を通して、Java EEアプリケーションからイベントを発生させることができます。
ローカル・イベント接続
パブリッシャがアプリケーションと同じOracle WebLogic Serverに存在し、パブリッシャがローカル・ビジネス・イベント・コネクション・ファクトリを使用する場合、イベントはローカル・イベント接続を通して発生します。
リモート・イベント接続
コール元がアプリケーションと異なるコンテナ(異なるJVM)内に存在する場合、イベントはリモート・イベント接続を通して発生します。
別のアプリケーション(Oracle ADF Business Componentアプリケーションなど)を構成し、SOAコンポジット・アプリケーションと同じコンテナ内で実行すると、このアプリケーションはローカル・イベント接続を使用するように最適化されます。
この項では、ビジネス・イベントの作成方法およびサブスクライブ方法の高レベルな概要が提供されます。
ビジネス・イベントを作成する手順は、次のとおりです。
SOAプロジェクトを空のコンポジットとして作成します。
次の方法のいずれかにより、イベント定義の作成ウィザードを起動します。
「ファイル」メイン・メニューで、「新規」→「イベント定義」を選択します。
「ファイル」メイン・メニューで、「新規」→「アプリケーション」→「SOA層」→「サービス・コンポーネント」→「イベント定義」を選択します。
「イベント定義の作成」ダイアログが表示されます。
表42-2に記載されている詳細を入力します。
表42-2 「イベント定義の作成」ダイアログのフィールドと値
| フィールド | 値 |
|---|---|
名前 |
名前を入力するか、 注意: イベント名としてスラッシュ( |
ディレクトリ |
イベント定義ファイルを作成するディレクトリ・パスを表示します。 |
ネームスペース |
デフォルトのネームスペースをそのまま使用するか、イベントを配置するネームスペースに対する値を入力します。これにより、サブスクライバは指定されたネームスペースのイベントを受信します。 |
「追加」アイコンをクリックして、イベントを追加します。
「イベントの作成」ダイアログが表示されます。
「検索」アイコンをクリックしてペイロードを選択し、「OK」をクリックします。図42-1に詳細を示します。
「イベントの作成」ダイアログに戻ります。
「名前」フィールドに、名前を入力します。
「OK」をクリックします。
これで、追加されたイベントが「イベント」セクションに表示されます。図42-2に詳細を示します。
エディタの上部にある、event_definition_name.edlの横のxアイコンをクリックして、エディタを閉じます。
変更を保存するように求められた場合は、「はい」をクリックします。変更を保存しないとイベントは作成されず、「イベント・チューザ」ウィンドウでは選択できません。
ビジネス・イベントがMDSリポジトリに公開され、に戻ります。「リソース」ウィンドウに、ビジネス・イベントが表示され参照できます。
この項では、Oracle Mediatorサービス・コンポーネントからビジネス・イベントをサブスクライブまたは公開する方法について説明します。
ビジネス・イベントをサブスクライブするには:
表42-3 「メディエータの作成」ダイアログのイベント表
| 要素 | 説明 |
|---|---|
一貫性 |
「一貫性」列内をクリックし、イベントに対する配信一貫性のレベルを選択します。
|
恒久 |
恒久サブスクリプションでは、パブリッシャ、サブスクライバおよびフレームワークのライフ・サイクルの相違によるメッセージ・ロスを防ぎます。次のオプションを選択します。
|
パブリッシャとして実行 |
セキュリティ公開オプションを選択します。
|
フィルタ |
イベントをフィルタリングするには、選択したイベントの「フィルタ」列をダブルクリックするか、またはイベントを選択して、表の上の「フィルタ」アイコン(最初のアイコン)をクリックします。これにより「式ビルダー」ダイアログが表示されます。このダイアログで、XPathフィルタ式を指定できます。フィルタ式では、サービスの起動前にメッセージのコンテンツ(ペイロードまたはヘッダー)が分析されるように指定します。たとえば、メッセージに顧客IDが含まれている場合のみサービスを起動することを指定するフィルタ式を適用できます。 式のロジックが満たされると、イベントの配信が可能になります。 フィルタの詳細は、「メッセージをフィルタリングする式の指定方法」を参照してください。 |
図42-3は、「メディエータの作成」ダイアログを示しています。
図42-4に、イベント・サブスクリプションのためにOracle Mediatorが構成されたことを示す左側のアイコンを示します。
「ビジネス・イベントをサブスクライブする方法」でサブスクライブしたイベントを公開するための、2番目のOracle Mediatorを作成できます。ここには示されていませんが、イベントを公開するためのBPELコンポーネントも作成できます。
ビジネス・イベントを公開するには:
次の例のソース・コードに、Oracle Mediatorサービス・コンポーネントのサブスクライブするイベントに関する詳細を示します。
<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"
durable="true" runAsRoles="$publisher"/>
</business-events>
</component>
この例では明示的に示されていませんが、イベントにおいてXPathフィルタを定義できます。次の例では、初期デポジットが50000を超える場合にのみ、イベントの配信が可能になります。
<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>
次の例には、2つのOracle Mediatorサービス・コンポーネントが示されています。1つのサービス・コンポーネント(OrderPendingEvent)はイベントをサブスクライブし、もう1つのサービス・コンポーネント(PublishOrderPendingEvent)はイベントを公開します。
<component name="PublishOrderPendingEvent"> <implementation.mediator src="PublishOrderPendingEvent.mplan"/> <business-events> <publishes xmlns:sub1="/oracle/fodemo/storefront/entities/events/edl/OrderEO" name="pub1:NewOrderSubmitted" persistent="true" priority="7" timeToLive="36000000"/> </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" durable="true" runAsRoles="$publisher"/> </business-events> </component>
SOAコンポジット・アプリケーションのデフォルト・リビジョンのサブスクライバのみがビジネス・イベントを受信できます。たとえば、次の動作に注意してください。
ビジネス・イベントをサブスクライブするには:
SAF (Store-and-Forward)を使用するドメイン間でイベントを公開する際、ローカル・サブスクライバはそのイベントをサブスクライブできません。たとえば、次のサブスクライバがあるとします。
ローカル・サブスクライバ(イベント・パブリッシャと同じドメインでデプロイ)
リモート・サブスクライバ(イベント・パブリッシャの外部のドメインにデプロイ)
いずれも、同じイベント(たとえばEという名前)をサブスクライブし、このイベントはSAFトピックをリスニングするよう構成されています。この環境では、リモート・サブスクライバのみがこのイベントをサブスクライブできます。ローカル・サブスクライバはこのイベントをサブスクライブできません。
EDNのJMSトピックは、インポート済SAFトピックとしてではなく、物理JMSトピックとしてプロビジョニングされる必要があります。これは、インポート済SAFトピックに、EDNではネイティブにサポートされていないコンテキスト参照およびセキュリティ・チェックの独自ルールがあるためです。
回避策として、次の手順を実行する必要があります。
パブリッシャから特定可能なローカルJMSトピックを作成します。たとえば、イベント・パブリッシャから特定可能なローカル・ドメインAで、標準のOracle WebLogic Server JMSトピック(たとえば、Taという名前)をイベントの公開先、およびこのトピックをリスニングするサブスクライバ(ドメインAのローカル)にプロビジョニングします。
リモート・サブスクライバから特定可能なリモート・ドメインBで、ドメインAのトピックTaにマッピングするインポート済SAFトピック(たとえば、safTbという名前)を作成し、リモート・サブスクライバがsafTbをリスニングするようにします。
手順2のかわりに、リモート・サブスクライバがリスニングするドメインBの別のJMSトピック(たとえば、Tbという名前)をプロビジョニングし、ソース・トピックTaと接続先トピックTbをブリッジするJMSブリッジを作成できます。
この項では、公開側のアプリケーション(ADF EARファイルなど)がSOAサーバーではなく管理サーバーでデプロイされている場合に、外部JNDIプロバイダを構成する方法について説明します。
管理サーバー・アプリケーションでSOAサーバーにイベントを公開できるように外部JNDIプロバイダを構成する手順は、次のとおりです。
この項では、BPELプロセス・サービス・コンポーネントからビジネス・イベントをサブスクライブまたは公開する方法について説明します。
ビジネス・イベントを公開するには:
図42-8は、イベントのサブスクリプションおよび公開用に構成されたBPELプロセス・サービス・コンポーネントを示します。左側にある丸囲みの青い稲妻は、イベントのサブスクリプションを示します。右側にある丸囲みの黄色い稲妻は、イベントの公開を示します。タイトル内の青い矢印をクリックすると、公開されたイベントのタイトルが表示されます。
図42-8 イベント・サブスクリプションおよび公開用のBPELプロセス・サービス・コンポーネントの構成
次の例のソース・コードに、BPELプロセス・サービス・コンポーネントのサブスクライブおよび公開するイベントに関するcomposite.xmlソース変更の様子を示します。
<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"
durable="true" runAsRoles="$publisher"/>
<publishes xmlns:pub1="http://mycompany.com/events/orders"
name="pub1:ProductSoldAlert" persistent="true" priority="7"
timeToLive="36000000"/>/>
</business-events>
</component>
<business-events>
<publishes xmlns:sub1="/oracle/fodemo/storefront/entities/events/edl/OrderEO"
name="pub1:NewOrderSubmitted" persistent="true" priority="7"
timeToLive="36000000"/>
</business-events>
</component>
この例では明示的に示されていませんが、イベントにおいてXPathフィルタを定義できます。フィルタは、通常、イベント・サブスクリプションにあります。subscribe要素によって、このサービス・コンポーネントがサブスクライブされる対象のイベントのタイプが制限され、filterセクションによってさらに、コンポーネントが関連する特定のコンテンツにイベントが制限されます。次の例では、初期デポジットが50000を超える場合にのみ、イベントの配信が可能になります。
<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イベント・バスからのイベントを受信できます。次の例に、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>
次の例に、BPELソース・ファイルでのeventName属性の使用方法を示します。
<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属性(どちらか一方)の存在については、Oracle JDeveloperで検証ロジックを実施されます。次の例は、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アクティビティのスキーマ定義も同様に変更されています。
