| Oracle® Fusion Middleware Oracle SOAコア拡張機能開発者ガイド 12c (12.1.3) E54313-02 |
|
 前 |
 次 |
この章では、直接統合の概要を示し、直接統合を実装するための手順について説明します。
この章の内容は次のとおりです。
Oracle SOAコア拡張機能を使用すると、組織では、標準モデルと呼ばれる一般的な情報モデルを使用して、そのアプリケーションを容易に統合できるようになります。正規のエンタープライズ・ビジネス・オブジェクト(EBO)は、統合フローに複数のソース・システムと宛先システムとの接続が含まれている統合で最も効果的に動作します。正規ベースのインタフェースでは、参加アプリケーション間の緊密な結合が最小限になります。この結果、新規アプリケーションがエコシステムに追加された場合に、再利用が可能になり、デプロイメントの速度が向上します。
ただし、すべての統合シナリオに標準統合モデルが必要なわけではありません。SOAコア拡張機能のコンポーネントでも、アプリケーション間(直接)統合がサポートされます。
直接統合を検討する必要があるのは次の場合です。
統合の各エンドにあるアプリケーションが1つのみである場合。
マッピングを少なくする必要がある場合。
統合の待ち時間を最大限短縮する必要がある場合。
統合が変換中心であり、非常に高いスループット(最大で10,000メッセージ/時間以上、または30メッセージ/秒)が要求される場合。
統合がデータ中心ではなくプロセス中心である場合。
リクエスタ・アプリケーションとプロバイダ・アプリケーションに変更の予定がない場合。
コンシューマ・アプリケーションとプロバイダ・アプリケーションまたはサービス間の単一モードの通信では、プロバイダまたはサービスで指定されたとおりに、XMLベースのデータ構造を使用して直接相互作用できます。
アプリケーション・ビジネス・フロー(ABF)では、統合フローが管理され、統合に必要な次のタスクが実装されます。
サービスで、クライアント・アプリケーションからリクエストが受信され、必要に応じてデータ・エンリッチメントが実行されます。
データ・エンリッチメントとは、クライアント・アプリケーションから追加の詳細を取得することであるといえます。
サービスで、接続プロトコルを使用してプロバイダがコールされます。
プロバイダ・アプリケーションから受信したレスポンスは、クライアント・アプリケーションの書式に変換された後で、クライアント・アプリケーションに返されます。
統合サービスのインタフェースは、リクエスタ/クライアント・アプリケーションによって定義されます。
注意:
後で追加のプロバイダを導入する場合は、別のABFを追加する必要があります。
エンドツーエンドの統合フローは、統合要件に応じて、単一のABFコンポジットまたは複数のABFコンポジットを使用して実装できます。統合フローを設計する際は、次のことを考慮してください。
サービスの機能を複数回再使用する可能性がある場合は、再使用可能なサービスを定義および設計します。
サービスに埋め込まれた一部の機能が複数の統合シナリオで必要な場合は、それを別々のABFに再度分解して、それを参照するサービスを作成します。
オプションで、機能を別々のサービスとして使用できる場合は、図3-1に示すように、ABFを使用して別のABFを呼び出します。
図3-1 ABFを呼び出すABF
ABFサービス・インタフェースで定義された操作に2つ以上のリソースに対する破壊的な書込みが含まれる場合は、これらのタスクを単一のトランザクションで実行することをお薦めします。
次のシナリオでは、トランザクション属性を設定したABFコンポジットを設計します。
2つの異なるアプリケーションの更新が必要であり、1つの更新のみが成功して不整合になった場合に発生する問題を回避する場合。
既存のグローバル・トランザクション・コンテキストがあり、統合プロセス・サービスで実行される操作がそのグローバル・トランザクションの一部である必要がある場合。
アプリケーションでメッセージを送信/受信する必要があり、同時に更新を実行する必要がある場合。
関連メッセージのグループをバッチ・モードで処理する必要がある場合。
トランザクション機能を実現するには、2フェーズ・コミットを使用して共通のトランザクション・コンテキストを作成します。
BPELコンポーネントでは、BPELプロセスが呼び出されると新規トランザクションが作成されます。トランザクションがすでに存在する場合、BPELではそのトランザクションが中断され、新しいトランザクションが作成されます。BPELコンポーネントにトランザクション・フラグを設定して、単一のグローバル・トランザクションに実行を連鎖するには、例3-1に示すように、コンポジット・エディタのソースにbpel.config.transactionをrequiredという値で追加します。
トランザクション・フラグが設定されると、BPELでは既存のトランザクションが継承されます。新しいトランザクションが作成されるのは、同様のトランザクションが存在しない場合のみです。
ABFサービスが別のSOAコンポジットによって呼び出される場合は、必ずコンポジットの単一スレッド実行としてください。これを実装する必要があるのは、サービスによって一方向の操作が公開されている場合のみです。コンポジットの単一スレッド実行を実現するには、次に示すように、コンポジット内のBPELコンポーネントに対してプロパティを設定することによって、コール元のコンポジットでコンポジットの同期タイプの呼出しを設定します。
bpel.config.oneWayDeliveryPolicy=sync
注意:
両方の設定を、JDeveloperでのサービスの設計時に設定できます。
例3-1 BPELコンポーネントのトランザクション・フラグの設定
<component name="<BPELProcessName">
<implementation.bpel src="<BPELProcessName" >.bpel"/>
<property name="bpel.config.transaction">required</property>
</component>
この項では、参加アプリケーションとのアウトバウンド相互作用を有効化する方法について説明します。
JCAアダプタを使用できる場合、JCAアダプタでは、ランタイム環境との組合せで、接続管理、トランザクション管理およびスケーラビリティに関するタスクがサポートされるため、アプリケーションに接続するための最初の選択肢とする必要があります。
ほとんどのアプリケーションは、Webサービスの形式で機能を公開しています。最も一般的に使用されるトランスポートは、SOAP over HTTPです。ただし、アプリケーションによっては直接XML over HTTPを公開している場合もあります。同期モードのみでアウトバウンド相互作用を行う参加アプリケーションは、SOAP/HTTPを使用してリクエストを送信する必要があります。
メッセージの送信をメッセージの処理と分離する場合は、キューを使用します。JMSキューを使用する場合は、JMSアダプタを使用してアクセスします。メッセージは、ABFアーティファクトによってJMSキューにエンキューされ、そのメッセージがアプリケーションによってデキューされます。
ABFとアプリケーション間の通信は、アプリケーション機能によって管理されます。次の方法でABFを呼び出すことができます。
クライアント・アプリケーションでABFに対するWebサービス・コールを実行する標準のWebサービス・インタフェースの使用。
必要な機能を個別のABFとして使用できる場合は、別のABFの使用。
リクエスタでWebサービス・コールを実行できない場合は、サービス・エンドポイントに対するコンポジット内での、JCA/JMSなどの適切なバインディングの使用。
ABFは、クライアント・アプリケーションで呼び出すことができるアダプタを組み込むことによって作成されます。
メッセージの送信をメッセージの処理と分離する必要がある場合は、JMSキューの使用。JMSキューには、JMSアダプタを使用してアクセスする必要があります。メッセージは、アプリケーションによってJMSキューにエンキューされ、そのメッセージがABFによってデキューされます。JMSを使用すると、保証付きメッセージ配信に対する永続的な方法でのメッセージの交換が容易になります。
リクエスタ・アプリケーションにメッセージをキューに入れる機能がない場合は、JMSプロデューサ・コンポジットの公開。ABFコンポジットにJMSコンシューマ・アダプタを作成します。JMSコンシューマ・アダプタによってメッセージがデキューされ、サービス・プロバイダ・アプリケーションが呼び出されます。非同期キューイング設計パターンによって、中央のキューが設定され、サービスで可用性の問題を解決できるようになり、非同期データ交換の全体的な堅牢性が向上します。
この項では、直接統合の実装時にエラーを捕捉する方法について説明します。
直接統合サービスを有効化して、ランタイム・フォルトとビジネス・フォルトを捕捉および処理するように構成します。WSDLコントラクトの決定時に予測できるビジネス・フォルトをすべて組み込み、サービスからABFサービスのコール元にビジネス・フォルトを返すことができるようにします。
考えられるすべてのエラーに対して個別のcatchブロックを作成して、予期しないエラーのみを確実にcatchAllに移動することをお薦めします。
ベスト・プラクティスは、エラー通知およびエラー・ロギングを送信するための一方向のエラー通知サービスを呼び出すことです。
SOAコア拡張機能に付属のエラー処理フレームワークを例外の捕捉および例外処理に利用できます。サービス固有のフォルト・ポリシー・ファイルを定義し、その中にランタイム・フォルトとビジネス・フォルトの両方を定義して、コンポジット・レベルでフォルト・ポリシーを関連付けることをお薦めします。
直接統合でAIAエラー・ハンドラ・フレームワークのAIAAsyncErrorHandlerBPELProcessを使用できますが、それに必要な書式で入力を渡します。AIAFault要素を文字列で表すXML要素を作成した後で、ビジネス・フォルト処理およびエラー通知/ロギング用のAIAAsyncErrorHandlerBPELProcessを呼び出します。
AIAAsyncErrorHanlderBPELProcessを呼び出すには、「同期リクエスト/レスポンスでのBPELのCatchおよびCatch-Allブロックに関するガイドライン」に記載されているガイドラインに従います(XSLTのEBM_to_Fault.xslを適用するステップを除く)。ただし、入力メッセージには、データが入力された次の要素が必要です。
Fault/FaultNotification/FaultMessage/Text
Fault/FaultNotification/FaultingService/InstanceID
Fault/FaultNotification/FaultingService/ECID
Fault/FaultNotification/FaultingService/ImplementationCode
Fault/FaultNotification/FaultingService/ID
電子メール通知など、必要なフレームワーク動作すべてを取得でき、EMコンソールを使用してドリルダウンすることもできます。
EBM_HEADERから導出されるフォルト・メッセージの一部である情報にはアクセスできません。ただし、次の要素は、フォルト・ポリシーxmlファイルに構成されている、リモート、結合およびその他のフォルトに対するAIA処理フレームワークによって導出できます。
フォルト・メッセージ・コード
フォルト・メッセージ・テキスト
Severity
Stack
フォルト処理サービスID
フォルト処理サービス実装コード
フォルト処理サービス・インスタンスID
修正処理
レポート作成日付
エラー・コードおよびサービス名を使用して、通知設定画面からエラー情報のルーティングを有効化します。
注意:
正規統合でフォルト処理に使用する、BPELプロセスのEBM_Header変数の作成は、直接統合では関係ありません。
このリリースでは、メッセージ再発行はデフォルトでサポートされていません。
直接統合サービスを保護するためのプロセスは、AIAサービスを保護する方法と同じです。プロセスは次のとおりです。
すべてのWebサービス・エンド・ポイントを保護する必要があります。
個々のサービス・コンポーネントを保護する必要はありません。
すべてのサービスを認証資格証明付きで提供する必要があります。
保護されたABFサービスを呼び出すアプリケーションは、必要な資格証明を送信する必要があります。
表3-1に、OWSMポリシーに関するセキュリティ推奨事項を示します。
表3-1 OWSMポリシーに関するセキュリティ推奨事項
| ポリシー | 推奨事項 |
|---|---|
oracle/aia_wss_saml_or_username_token_service_policy_OPT_ON |
これは、「ローカルの最適化」が「オン」に設定されたoracle/wss_saml_or_username_token_service_policyのクローンです。このOWSMセキュリティ・ポリシーをコンポジットのサービス・エンド・ポイントにアタッチします。このポリシーは、WS-Security SOAPヘッダーまたはUsernameToken WS-Security SOAPヘッダーのSAMLトークンで提供される資格証明を使用した受信リクエストの認証時に適用されます。 |
oracle/aia_wss10_saml_token_client_policy_OPT_ON |
これは、「ローカルの最適化」が「オン」に設定されたoracle/wss10_saml_token_client_policyのクローンです。このOWSMセキュリティ・ポリシーをコンポジットの参照エンド・ポイントにアタッチします。このポリシーでは、アウトバウンドSOAPリクエスト・メッセージにSAMLトークンが挿入されます。 |
注意:
2つのカスタムOWSMポリシーは、SOAコア拡張機能がインストールされるとサーバーで使用可能になります。
その他の推奨事項:
保護されたアプリケーション・サービスを呼び出すコンポジットに対しては、適切なクライアント固有のポリシーを使用します。
保護されていないアプリケーション・サービスを呼び出す場合は、no_authentication_client_policyを使用します。
JCAベースのアプリケーション・サービスをコールするコンポジットに対しては、ポリシーをアタッチする必要はありません。
直接統合のサービスでは、SOAコア拡張機能で提供されるグローバル・ポリシー・アタッチメント・サポートを利用できます。デプロイメント後に、SOAコア拡張機能ツールによって、ネーミング・パターンがABFで終わるサービスにグローバル・ポリシーが自動的にアタッチされます。
SOAコア拡張機能を使用しないサービスは、OWSMポリシーを直接(ローカルで)アタッチする必要があります。設計時に、composite.xmlファイルのポリシーをサービスおよび参照エンドポイントにアタッチします。デプロイメント後に、EMコンソールを使用してOWSMポリシーをSOAコンポジットにアタッチすることもできます。
相互参照エンティティごとにカスタム・データベース表を生成します。カスタム相互参照表に相互参照を格納するためXREFエンティティを構成することをお薦めします。これによるプログラミング・モデルの変更はありません。相互参照データが格納されるたびに、それがSOAインフラ(XREF_DATAまたはカスタム・データベース表)に存在するかどうかに関係なく、単一のAPIのセットを使用してXREFの参照と入力が実行されます。
相互参照エディタを使用すると、カスタム・データベース表を使用する必要があるかどうかを指定できます。(相互参照アーティファクトの定義時に、最適化オプションを使用します。)また、必要なDDLスクリプトも生成されます。ただし、SOAでは表は自動的には作成されません。
カスタム相互参照表の使用方法の詳細は、http://www.oracle.com/technetwork/middleware/foundation-pack/learnmore/aiaxref-524690.htmlを参照してください。
注意:
統合レイヤーへの相互参照行の入力は、ソースまたはターゲット・アプリケーションに相互参照を管理する機能がある場合は必要ありません。
ABFは、処理ロジックを取得するためのタスク指向サービスとしてモデル化されます。実際の方法は、処理およびエンティティ・コンテキストに基づいてサービスに名前を付けることです。サービス名に動詞およびエンティティを使用することをお薦めします。
ABFは、特定のアプリケーションを統合するように設計されているため、サービス名の一部としてアプリケーションの名前を使用してください。
ABF名のテンプレートは、[動詞][エンティティ][App1][App2] ABF[バージョンが1より大きい場合はVn]で、App1はソース・アプリケーション、App2はターゲット・アプリケーションです。
たとえば、ProcessFulfillmentOrderEbizFusionABFです。
必要に応じて、参加ソース・アプリケーションと参加ターゲット・アプリケーションの間にToという語を追加することもできます。たとえば、ProcessFulfillmentOrderEbizToFusionABFです。
エンリッチメント・サービスの呼出しが含まれる場合のABFの名前設定
統合が、ターゲット・アプリケーションとの統合に使用する値を取得するために、GOP、税金計算などの仲介/ユーティリティ・アプリケーションと相互作用する場合は、これらの仲介/ユーティリティ・アプリケーションの名前をサービス名に含めます。
包括的なABFの名前設定
包括的な編成プロセスには複数のタスクが含まれ、この場合、各タスクに別のアプリケーションとの統合が含まれる場合があります。このような場合は、すべてのアプリケーション名をサービス名に組み込まないでください。ソース・アプリケーション名のみを使用します。
たとえば、ProcessFulfillmentOrderEbizABFは、FusionCRMにエントリを作成し、請求のためにBRMを更新して、B2BGatewayとインタフェースを介して出荷通知を外部のTPに送信します。包括的なプロセスは、ソース・アプリケーションによって指定できるため、ソース・アプリケーション名のみを使用します。
操作名
サービス名は幅広いコンテキストを対象とするため、動詞の後にサービス操作名のエンティティを使用できます。
メッセージ名
メッセージ名は、[操作名]Request/[操作名]Responseにする必要があります。
コンポジット・ネームスペース
コンポジット・ネームスペースの標準は、http://xmlns.oracle.com/ApplicationBusinessFlow/[機能領域または事前作成済の統合]/[バージョンなしのコンポジット名]/V[n]です。
たとえば、http://xmlns.oracle.com/ApplicationBusinessFlow/OrderToCash/ProcessFulfillmentOrderFusionDOOToEbiz/V1です。
メッセージのネームスペース
すべてのネームスペースがhttp://xmlns.oracle.com/で始まり、エンティティ固有およびドメイン固有の識別子が続く必要があります。たとえば、core、Industryです。サブドメインがある場合は、それらを指定します。
たとえば、http://xmlns.oracle.com/ABFMessage/Core/Invoice/V1です。
ABF (WSDL)インタフェースのネームスペース
http://xmlns.oracle.com/ApplicationBusinessFlow/\[機能エリアPIP]/[コンポジット名]/V[n]
たとえば、http://xmlns.oracle.com/ApplicationBusinessFlow/OrderToCash/ProcessFulfillmentOrderFusionDOOEbizABF/V1です。
ABFサービスのメタ情報は、Oracle Enterprise Repository (OER)のアセットの保守で使用されます。公開されたサービスおよび参照先サービスに対して、コンポジットに注釈を付けることをお薦めします。提示されているガイドラインに従い、開発時にこれらのコメントを挿入してください。
この項の例に示すように、<svcdoc:AIA>要素に注釈を埋め込み、<svcdoc:AIA>要素をxmlコメント・タグ<!--と-- >内に配置します。
<svcdoc:ServiceSolutionComponentAssociation>は、例3-2に示すように、すべての注釈付きcomposite.xmlファイルで、最初の注釈要素である必要があります。
この要素は、アーティファクトの生成に使用するグローバル一意識別子(GUID)を記述し、ルート要素<composite>の下に配置される必要があります。この要素の値は、空白のままにする必要があります。GUIDによって、ソリューション・サービス・コンポーネントが、実装されたビジネス・サービス・コンポジットに関連付けられます。この関連付けによって、部品構成表への自動入力が可能になります。
例3-3および例3-4に示すように、composite.xmlのサービスおよび参照要素に注釈を付けます。
前述の例で、コンポジットの注釈要素のルートは、<svcdoc:AIA>です。注釈要素<svcdoc:Service>および<svcdoc:Reference>を使用して、xmlコメント・タグの下にあるコンポジットのサービスおよび参照要素に対して、それぞれ例3-5と例3-6に示すように注釈を付けます。
<svcdoc:Service>
<svcdoc:ImplementationDetails>
<svcdoc:ApplicationName>Source Application</svcdoc:ApplicationName>
.................................................................
<svcdoc:ArtifactType>ApplicationBusinessFlow</svcdoc:ArtifactType>
<svcdoc:ServiceOperation>
......................................................................
</svcdoc:ServiceOperation>
</svcdoc:ImplementationDetails>
<svcdoc:TransportDetails>
<svcdoc:JMSAdapter>
<svcdoc:ResourceProvider>WLSJMS</svcdoc:ResourceProvider>
<svcdoc:ConnectionFactory>JNDINameOfConnectionFactory</svcdoc:ConnectionFactory>
<svcdoc:XAEnabled>true</svcdoc:XAEnabled>
<svcdoc:ResourceTargetIdentifier>JMSUSER1</svcdoc:ResourceTargetIdentifier>
<svcdoc:ResourceType>Queue</svcdoc:ResourceType>
<svcdoc:ResourceName>JMSQueueName</svcdoc:ResourceName>
<svcdoc:ResourceFileName></svcdoc:ResourceFileName>
</svcdoc:JMSAdapter>
</svcdoc:TransportDetails>
</svcdoc:Service>
<svcdoc:Reference>
<svcdoc:ArtifactType>TransportAdapter</svcdoc:ArtifactType>
<svcdoc:ServiceOperation>
<svcdoc:Name>GetSalesOrderLineShippingDetailsEbizAdapter</svcdoc:Name>
</svcdoc:ServiceOperation>
<svcdoc:TransportDetails>
<svcdoc:ApplicationAdapter>
<svcdoc:ResourceProvider>OracleDB</svcdoc:ResourceProvider>
<svcdoc:BaseVersion>12.1.3</svcdoc:BaseVersion>
<svcdoc:ConnectionFactory>eis/Apps/OracleAppsDataSource</svcdoc:ConnectionFactory>
<svcdoc:ApplicationName>ebiz</svcdoc:ApplicationName>
<svcdoc:XAEnabled>true</svcdoc:XAEnabled>
<svcdoc:ResourceTargetIdentifier></svcdoc:ResourceTargetIdentifier>
<svcdoc:ResourceType>Procedure</svcdoc:ResourceType>
<svcdoc:ResourceName></svcdoc:ResourceName>
<svcdoc:ResourceFileName>XX_BPEL_GETSALESORDERLINESHIPP.sql</svcdoc:ResourceFileName>
</svcdoc:ApplicationAdapter>
</svcdoc:TransportDetails>
</svcdoc:Reference>
例3-2 すべてのcomposite.xmlファイルに対する最初の注釈要素
<composite name="SamplesCreateCustomerPartyPortalBusinessService"> ........................ <!--<svcdoc:AIA> <svcdoc:ServiceSolutionComponentAssociation> <svcdoc:GUID></svcdoc:GUID> </svcdoc:ServiceSolutionComponentAssociation> </svcdoc:AIA>--> ..................................... </composite>
例3-3 注釈付きのcomposite.xmlのスケルトン・サービス要素
<service ui:wsdlLocation .......> <interface.wsdl ....... /> <binding.ws ........... /> <!-- <svcdoc:AIA> <svcdoc:Service> . . . . . . . . . . . . </svcdoc:Service> </svcdoc:AIA> --> </service>
例3-4 注釈付きのcomposite.xmlのスケルトン参照要素
<reference ui:wsdlLocation ........"> <interface.wsdl ............/> <binding.ws ................/> <!-- <svcdoc:AIA> <svcdoc:Reference> ................. </svcdoc:Reference> </svcdoc:AIA> --> </reference>
例3-5 サービス注釈要素の例
<svcdoc:Service>
<svcdoc:InterfaceDetails>
<svcdoc:ServiceName>.....</svcdoc:ServiceName>
<svcdoc:Namespace>.......</svcdoc:Namespace>
<svcdoc:ArtifactType>ApplicationBusinessFlow</svcdoc:ArtifactType>
<svcdoc:ServiceOperation>
.......
</svcdoc:ServiceOperation>
</svcdoc:InterfaceDetails>
<svcdoc:ImplementationDetails>
<svcdoc:ApplicationName>Source Application</svcdoc:ApplicationName>
................
<svcdoc:ArtifactType>ApplicationBusinessFlow</svcdoc:ArtifactType>
<svcdoc:ServiceOperation>
..........
</svcdoc:ServiceOperation>
</svcdoc:ImplementationDetails>
</svcdoc:Service>
例3-6 トランスポート・アダプタがある場合のサービス注釈要素の例
<svcdoc:Reference>
<svcdoc:ArtifactType>UtilityService</svcdoc:ArtifactType>
<svcdoc:ServiceOperation>
<svcdoc:Name>initiate</svcdoc:Name>
</svcdoc:ServiceOperation>
</svcdoc:Reference>
WSDL注釈は、既存のAIAサービス注釈と同じです。例3-7を参照してください。
例3-7 サンプルのWSDL注釈
<documentation> <svcdoc:Service> <svcdoc:Description></svcdoc:Description> <svcdoc:ServiceType>ApplicationBusinessFlow</svcdoc:ServiceType> <svcdoc:Version>2</svcdoc:Version> </svcdoc:Service> </documentation>
SOAコア拡張機能のツールを使用する直接統合サービスは、XMLファイルのサービス・レベル構成プロパティの設定に既存の方法を使用できます。ただし、新しく作成された直接統合フローに対しては、SOAのBPELプリファレンス/プロパティ機能を利用することによって、BPELプリファレンスを使用することをお薦めします。コンポジットで、プロパティを使用して、構成可能なプロファイルを定義します。
<property name="bpel.preference.myProperty">myValue</property>
定義済のプロパティに対する追加/削除/変更などの構成の更新は、EMコンソールから直接実行できます。サービス構成にSOAのBPELプリファレンスを使用している場合は、プロパティの更新に別のUIは必要ありません。
この方法には制限があります。この方法の特徴は、次のとおりです。
XSL変換でサポートされません。
BPELからのみ使用できます。メディエータではサポートされません。
ドメイン・レベルの構成はサポートされません。
EMコンソールのプリファレンスに対するナビゲーションは非直観的です。
SOAコア拡張機能がインストールされると、AIAサービス構成ファイルを直接統合フローによるサービスのランタイム動作の構成に使用できます。
この項では、直接統合の拡張パターンについて説明します。この項には次のトピックが含まれます:
次のガイドラインを使用して、拡張機能を提供するためのベース変換XSLファイルを開発します。
変換マップの拡張が認識されるようにするには、すべての変換に対する拡張XSLファイルを作成します。
コア変換XSLファイルの例: PurchaseOrder_to_PurchaseOrder.xsl
すべてのコアXSLファイル名に1つの拡張XSLファイルがあります(例: PurchaseOrder_to_PurchaseOrder_Custom.xsl)。
メッセージ内のすべてのコンポーネントに対して、拡張ファイルに空の名前付きテンプレートを定義します。
コア変換ファイルに拡張ファイルを組み込みます。
コア変換の各コンポーネントに対してcall-templateを追加します。
例3-8に示すように、カスタム要素の変換に変換で対応できるようにします。
例3-8 カスタム要素の変換に対応可能な変換
<!-XSL template to transform Address-->
<xsl: template name="Core_AddressTemplate">
<xsl:param name = "context" select ="."/>
<xsl:param name = "contextType" select ="'CORE'"/>
<address1><xsl:value-of select="$context/address1"><address1>
<address2><xsl:value-of select="$context/address1"></address2>
<city><xsl:value-of select="$context/city"></city>
<state><xsl:value-of select="$context/state"></state>
<zip><xsl:value-of select="$context/zip"></zip>
<xsl:if test="$contextType!='CORE'">
<xsl:call-template name="Vertical_AddressTemplate">
<xsl:with-param name="context" select="$context"/>
<xsl:with-param name="contextType" select="$contextType">
</xsl:call-template>
</xsl:if>
</xsl: template>
特定のカスタマイズ・ユースケースがある場合のみ、コンポジットにカスタマイズ可能のマークを付けます。
特定のカスタマイズ・ユースケースがある場合のみ、BPELプロセス内の特定のスコープにカスタマイズ可能のマークを付けます。
この項では、カスタマイズ可能のマークを付けるBPELスコープを識別するための一般的なガイドラインについて説明します。
カスタマイズ可能なスコープ・アクティビティの範囲は、可能なかぎり狭くする必要があります。たとえば、BPELフローの最上位レベルのスコープをカスタマイズ可能としてマーク付けするのではなく、カスタマイズ要件を満たすためにロジックを追加できる特定のスコープを識別します。
後で部分的に削除される可能性がある複雑なロジックにカスタマイズ可能のマークを付けないようにしてください。
コンポジットにカスタマイズ可能のマークを付けた場合は、それをリリースするまでマークを解除しないでください。マークを解除すると、カスタマイズによってパッチ適用が機能しなくなります。
ベース・バージョンに対して、カスタマイズしたコンポジットにパッチが適用された場合に、ある意味で競合が発生するような変更はしないでください。たとえば、カスタマイズ可能なBPELスコープ内のコンポーネント、ルーティング・ルールおよびアクティビティの削除では、顧客は、カスタマイズされた項目が削除されたときに、マージ競合を手動で解決する必要があります。
コンポジットがリリースされた後は、カスタマイズ可能コンポジットからのコンポーネントまたはルーティング・ルールの削除、およびカスタマイズ可能とマーク付けされたBPELスコープ内のアクティビティの削除は実行しないでください。
