10g（10.1.3.1.0）
B31900-01
 目次 |
 索引 |
| Oracle Application Server Adapter概要 10g（10.1.3.1.0） B31900-01 |
|
Oracle Application Serverアダプタは、J2EE Connector Architecture（J2CA）1.5標準に基づいており、Oracle Containers for J2EE（OC4J）内にデプロイされます。Oracle Application Serverアダプタのライフ・サイクルは、Business Process Execution Language for Web Services（BPEL）Process Managerによって決まります。これらのアダプタは、アダプタ・フレームワーク・コンポーネントを介してBPEL Process Managerに統合されます。
この章の内容は、次のとおりです。
テクノロジ・アダプタおよびOracleAS Adapter for Oracle Applicationsは、Oracle BPEL Process Managerのインストールの一部として組み込まれています。 これらのアダプタは、スタンドアロンOC4Jと中間層の両方のデプロイをサポートしています。パッケージ・アプリケーション・アダプタおよびレガシー・アダプタは、OracleAS Adapters CDの一部として使用できます。 これらのアダプタは、中間層デプロイのみをサポートしています。
Oracle Application Serverアダプタは、J2CA 1.5リソース・アダプタとしてデプロイされます。 したがって、アダプタを起動および停止するには、すべてのリソース・アダプタが、start (BootstrapContext)メソッドとstopメソッドをSPIインタフェースの一部として実装している必要があります。Oracle Application Serverアダプタは、それらのアダプタを使用するBPELプロセスがJ2CAアウトバウンド相互作用を開始したときに起動されます。 アダプタは、BPELプロセス自体がインバウンド相互作用のためにロードされるとき、またはアダプタがBPELプロセスにイベントをパブリッシュするときにも起動されます。
アダプタの起動後にアダプタを停止する唯一の方法は、OC4Jを停止することです。 このリリースでは、アダプタ・フレームワークはJ2CA 1.5コンテナの一部として機能します。
Oracle Application Serverアダプタは、OC4Jコンテナ内にJ2CA 1.5リソース・アダプタとしてデプロイされます。アダプタは、Javaアーカイブ（JAR）形式を使用してリソース・アダプタ・アーカイブ（RAR）ファイルとしてパッケージ化されています。 アダプタを物理的にデプロイするには、RARファイルを使用すること、および基礎となるOC4Jまたは中間層プラットフォームにアダプタをコネクタとして登録することが必要です。RARファイルには、ra.xmlファイルが含まれています。このファイルは、リソース・アダプタに関するデプロイ固有の情報が格納されるデプロイメント・ディスクリプタXMLファイルです。また、RARファイルには、OC4Jとリソース・アダプタ間の規約に関する宣言情報も含まれています。
アダプタは、.rarファイル内のra.xmlファイルに加え、oc4j-ra.xmlテンプレート・ファイルをパッケージ化します。oc4j-ra.xmlファイルは、リソース・アダプタのConnectorFactoryオブジェクト（論理的なデプロイ）の定義に使用されます。このoc4j-ra.xmlファイルは、リソース・アダプタ用のOC4J固有のデプロイメント・ディスクリプタです。 このファイルには、リソース・アダプタをOC4Jにデプロイするためのデプロイ構成が含まれており、これには、リソース・アダプタのデプロイメント・ディスクリプタに指定されているバックエンド・アプリケーションの接続情報、使用するJava Naming and Directory Interface（JNDI）の名前、接続プーリング・パラメータ、リソース・プリンシパル・マッピング・メカニズムおよび構成が含まれます。
この例では、BPEL Process ManagerのスタンドアロンOC4Jインストールの一部として、テクノロジおよびOracleAS Adapter for Oracle Applicationsを物理的にデプロイする方法を示します。 スタンドアロンOC4Jインストールでは、次のコマンドを使用してJCA 1.5リソース・アダプタをデプロイします。
java -jar $ORACLE_ HOME/integration/orabpel/system/appserver/oc4j/j2ee/home/admin.jar ormi://localhost oc4jadmin welcome1 -deployConnector -file myAdapter.rar -name myAdapter
スタンドアロンOC4Jインストールでは、次のコマンドを使用してJCA 1.5リソース・アダプタを削除します。
java -jar $ORACLE_ HOME/integration/orabpel/system/appserver/oc4j/j2ee/home/admin.jar ormi://localhost oc4jadmin welcome1 -undeployConnector -name myAdapter
MANIFEST.MF、oc4j-ra.xmlおよびra.xmlファイルは、コネクタ・フォルダにも格納されます。
サンプルのoc4j-ra.xmlファイルを次に示します。
アダプタの論理的なデプロイとは、oc4j-ra.xmlデプロイメント・ディスクリプタ・ファイルでのConnectionFactoryオブジェクトの作成を意味します。 接続情報を追加してJNDI名に割り当てるには、リソース・アダプタの対応するoc4j-ra.xmlファイルを編集します。 また、必要なアダプタのoc4j-ra.xmlファイルを手動で検索して編集する必要があります。 oc4j-ra.xmlファイルには、アダプタのランタイム接続パラメータが含まれています。
たとえば、OracleAs Adapter for Databaseを論理的にデプロイするには、次の場所にあるoc4j-ra.xmlファイルを編集します。
$ORACLE_HOME/integration/orabpel/system/appserver/oc4j/j2ee/home/application-deployments/d efault/DbAdapter/oc4j-ra.xml.
次のOracle Application Serverアダプタのログを表示できます。
LogManagerインタフェースを実装します。このインタフェースを使用して、アダプタ・ログをBPELドメイン・ログにリダイレクトします。アウトバウンド相互作用とインバウンド相互作用の両方について、ログ・ファイルがBPELドメイン・ログにリダイレクトされます。BPELドメイン・ログは、次の場所にあります。
$ORACLE_HOME/integration/orabpel/domains/default/logs/domain.log.
LogManagerインタフェースを実装しません。したがって、これらのアダプタ・ログ出力は、opmn/logsディレクトリにリダイレクトされます。アウトバウンド相互作用の場合、ログはopmnログに出力されます。一方、インバウンド相互作用の場合、ログはBPELドメイン・ログにリダイレクトされます。
アダプタは、基礎となるバックエンド操作固有のプロパティをヘッダー要素として公開し、ビジネス・プロセス内でこれらの要素を操作できるようにします。たとえば、OracleAS Adapter for Advanced Queuingのヘッダー要素は、1つのビジネス・プロセス内に2つのAdvanced Queuingメッセージを関連付けるための相関IDやメッセージIDなど、ヘッダーのプロパティを公開します。
次のOracle Application Serverアダプタのトレース・レベルを設定します。
default.collaxa.cube.wsプロパティを設定します。インバウンド相互作用には、default.collaxa.cube.activationプロパティを設定します。
oc4j-ra.xmlファイル内のパッケージ・アプリケーション・アダプタのLoglevelプロパティを設定します。
デプロイ中（JDevまたはobant）、J2CAバインディングを含むWSDLは、J2CA WSDL検証サービスにより精査されます。 WSDL検証サービスでは、J2CAバインディングを含むWSDLのみが選択されます。
検証ステップは次のように実施されます。
jca:serviceで提供されている場合）を介してデプロイされる場合のJNDIロケーションの検証
jca:operationで指定されているInteractionSpecまたはActivationSpecの存在
jca:operationでInteractionSpecまたはActivationSpecにバインドされているプロパティ名と値すべての検証
pc:inbound_bindingで指定されているXMLレコード・コンバータすべての検証
validate()メソッドが起動します。
BPELサーバー・ドメインのXML検証は、BPELコンソールを介して、またはPartnerLinkレベルで有効化できます。インバウンドおよびアウトバウンドのXML検証は、BPEL Process Managerで有効化できます。
Oracle Application Serverアダプタのレコード実装は、XMLRecordです。アダプタ相互作用はすべてXMLRecordで開始します。各JCAレコードは、oracle.tip.adapter.api.record.XMLRecordの実装であることが必要です。XMLRecordの各インスタンスには、1つまたは2つのRecordElementのインスタンス（1つは必須のペイロードRecordElement、もう1つはオプションのヘッダーRecordElement）があります。RecordElementsにはデータが格納されています。また、各RecordElementには、UTF-8エンコードのXML文字列または不透明（Opaque）なバイナリ・バイト・ストリームのBLOBデータが1つ含まれています。
XMLRecordは、次のメソッドで構成されます。
getHeaderRecordElement: ヘッダーRecordElementを取得します。
getPayloadRecordElement: ペイロードRecordElementを取得します。
setHeaderRecordElement: XMLRecordのヘッダー・レコード要素を設定します。
setPayloadRecordElement: XMLRecordのペイロード・レコード要素を設定します。
orabpel¥binディレクトリのencryptコマンド（encrypt.shまたはencrypt.bat）を使用して、oc4j-ra.xmlファイルのパスワードを暗号化します。
各JCAリソース・アダプタ実装は、このパスワードを復号化するために、適切なアダプタ・フレームワークの復号化機能を使用する必要があります。 アダプタで復号化できないと、oc4j-ra.xmlエントリの暗号化が意味をなしません。
アダプタおよびその基盤となっているアダプタ・フレームワーク（AF）・ライブラリでは、次のタイプの例外がスローされます。
WSIFExceptionがスローされます。
ActivationExceptionがスローされます。
PCRetriableResourceExceptionがスローされます。このエラーは、アウトバウンド相互作用の場合にはリカバリ可能です。 bpel.xmlでリトライ・ポリシーを定義することにより、PCRetriableResourceException例外の再試行が可能となります。
ResourceException例外は、すべてのケースについてスローされます。
テクノロジおよびOracleAS Adapter for Oracle Applicationsのアダプタは、次の相互作用に対する接続エラーを処理できます。
oracle.tip.adapter.api.exception.PCRetriableResourceExceptionが発生します。たとえば、データベース・リスナーが起動していないために、接続エラーが発生する可能性があります。 実行する再接続の最大試行回数をbpel.xmlファイルに定義できます。このファイルのPartnerLinkBindingパラメータの下に、再接続を試行するためのパラメータを次のように指定します。
<BPELSuitcase> <BPELProcess ...> <partnerLinkBindings> <partnerLinkBinding name="myOutboundPartnerLink"> <property name="wsdlLocation">Outbound.wsdl</property> <property name="retryInterval">10</property> <property name="retryMaxCount">30</property> </partnerLinkBinding>
この例の再接続パラメータ設定では、10秒ごとに再接続を試行し、最大30回の再接続を試行するように、BPELランタイムを指定しています。最大回数まで試行すると、BPELプロセスのRemoteFault例外が発生します。
他のすべての例外はリカバリ不可で、BindingFault例外がBPELプロセスにスローされる結果となります。
次の相互作用の際に発生する可能性があるエラーを処理できます。
ResourceAdapter例外をスローします。データの修正およびメッセージの再生は、BPELプロセス内で処理される必要があります。
bpel.xmlでは、これらのメッセージの処理方法を次のように構成できます。
メッセージの順序付けは、BPELプロセスを同期させることにより達成できます。これはBPELエンジンにメッセージをパブリッシュするリソース・アダプタのスレッドが、BPELインスタンス全体を実行するために使用されることを意味します。
非同期BPELプロセスでは、受信したメッセージはBPELエンジンのワーカー・スレッドのプールで処理されます。 この場合、メッセージの順序は保証されません。ほとんどの場合、BPELインスタンスの期間は他のBPELインスタンスの期間と異なるためです。
通常、JCAリソース・アダプタ・ウィザードでは、一方向（非同期）、つまり、入力メッセージのみを操作するWSDLが作成されます。 ウィザードで生成されたWSDLを手動で変更して、インプットおよびアウトプット・メッセージのあるリクエスト-レスポンス（同期）・タイプのWSDLにする必要があります。
次の例を考慮に入れて、通常は生成されないレスポンス（アウトプット）・メッセージ用のXMLスキーマ・タイプを作成してください。
<タイプ> <schema xmlns="http://www.w3.org/2001/XMLSchema" targetNamespace="http://acme.com/adapterService/"> <import namespace="http://TargetNamespace.com/adapterService/type" schemaLocation="adapterTypes.xsd" /> . . . <element name="empty"> <complexType/> </element>
XMLスキーマ・タイプを作成した後、次のようにWSDLメッセージを（アダプタWSDLファイル内に）定義します。
<message name="ignoreMessage"> <part name="empty" element="tns:empty"/> </message>
次に、例に示すように、インバウンドWSDL操作にアウトプット・メッセージを追加します。
<portType name="Receive_ptt"> <operation name="Receive"> <input message="tns:payloadMessage"/> <output message="tns:ignoreMessage"/> </operation> </portType>
次に、例に示すように、バインディング・セクションにアウトプット要素を追加します。
<binding name="Receive_binding" type="tns:Receive_ptt"> <pc:inbound_binding /> <operation name="Receive"> <jca:operation .../> <input/> <output/> </operation> </binding>
WSDLはこれでOKです。
次に、例に示すように、BPELプロセスのビジネス・プロセス・ロジックの最後に再試行アクティビティを追加します。
<variables> <variable name="ignore" messageType="ns1:ignoreMessage"/> . . . <sequence name="main"> <receive partnerLink="ReceivePL" portType="ns1:Receive_ptt" operation="Receive" variable="Receive_1_Read_InputVariable" createInstance="yes"/> . . . <!-- processing --> <invoke partnerLink="DB_Insert" portType="ns1:DB_Insert_ptt" operation="InsertCust" inputVariable="NewCust"/> <reply partnerLink="ReceivePL" portType="ns1:Receive_ptt" operation="Receive" variable="ignore"/> . . . <!-- optionally more processing --> </sequence>
前述の例でリソース・アダプタがマルチスレッド・インバウンドをサポートしている場合には、1つのスレッドのみを使用するように構成または調整する必要があります。複数スレッドでは、確率論的な期間によって、メッセージの順序が保証されなくなるためです。
メッセージ拒否ハンドラは、次のことを行うように構成できます。
関連するPartnerLinkアクティビティ下でbpel.xmlファイル内にMessage Rejectionハンドラを指定します。 さらに、メッセージ拒否ハンドラをアクティブ化エージェント・プロパティの一部として定義する必要があります。 メッセージ拒否ハンドラの4つのタイプを次に示します。
INVALID_MSG_ + <process-name> + <operation-name> + <current-time>
ファイル・システム・ベースの拒否ハンドラを指定する構文は次のとおりです。
<property name="rejectedMessageHandlers"> file://<directory-path> </property>
ファイル・システム・ベースの拒否ハンドラを指定する例を次に示します。
<property name="rejectedMessageHandlers"> file://C:/orabpel/domains/default/rejectedMessages </property>
RAW Oracleアドバンスト・キュー・ベースのメッセージ拒否ハンドラを指定する例を次に示します。
<property name="rejectedMessageHandlers"> queue://jdbc:oracle:thin:@<db-host>:<tns-port>:<sid>|<user>/<password>|<queue-n ame> </property>
「:」および「|」は、コード内で、この例に示されているとおりの位置に入力してください。
BPELプロセスのメッセージ拒否ハンドラを指定する構文は次のとおりです。
<property name="rejectedMessageHandlers"> bpel://<bpel-domain[:<password>]>|<process-name>|<operation-name>|<input-messag e-partname> </property>
このように、プロセスは受信操作の（WSDLおよびBPELソースに関する）選択によって定義できます。唯一の制約は、この拒否ハンドラに送信されるメッセージのWSDLメッセージ・タイプに関する制約のみです。 このタイプは、RejectedMessageタイプとして宣言されている必要があります。 この宣言を行うには、xmllibに常駐するWSDL RejectionMessage.wsdlをインポートします。このファイルで、次の例に示すようにメッセージを定義します。
<message name="RejectionMessage"> <part name="message" element="err:RejectedMessage"/> </message>
次の例に示すURLを使用して、他のWSDLからxmllib WSDLをインポートできます。
<import namespace="http://xmlns.oracle.com/pcbpel/rejectionHandler" location="http://localhost:9700/orabpel/xmllib/jca/RejectionMessage.wsdl"/>
BPELプロセスには、インポートをこの例に示すとおりにのみ含めることができます。 ポート・タイプは次のように参照されます。
<definitions ... xmlns:rej="http://xmlns.oracle.com/pcbpel/rejectionHandler" <portType name="MyRejectionHandlerPortType"> <operation name="myHandleRejectionOperation"> <input message="rej:RejectionMessage"/> </operation> </portType>
WSIFベースのメッセージ拒否ハンドラを指定する構文は次のとおりです。
<property name="rejectedMessageHandlers"> wsif://<wsif-wsdl-location>|<operation-name>|<input-message-part-name> </property>
次の例のようにして、WSIFベースのメッセージ拒否ハンドラを指定できます。
<property name="rejectedMessageHandlers"> wsif://file:/C:/orabpel/samples/test/ErrorTest/FileAdapterWrite.wsdl|write|mess age </property>
WSIFベースのメッセージ拒否ハンドラには、メッセージ・タイプに関して、BPELプロセスの拒否ハンドラと同じ制約があります。 BPELプロセスの拒否ハンドラの項を参照してください。
この項では、アダプタでメッセージの欠落のないことを確認する方法、およびBPELデハイドレーション・ストアからメッセージをリカバリする方法を記述します。
BPELエンジンは常に配信を確認するよう構築されています。 デハイドレーション・ポイントは、reveive、pickおよびwaitの前と、replyおよびinvokeの後に、それぞれ設置されます。 デフォルトでは起動後のデハイドレーションは遅延しますが、チューニング・プロセス・パラメータを介して管理できます（BPELチューニング・ガイドのidempotent設定オプションを参照してください）。
JCAリソース・アダプタによって、BPELエンジンの及ぶ範囲が拡張され、配信保証も特定の方法により確実に維持されます。
トランザクション・アダプタにより、EISを1フェーズまたは2フェーズ・コミット（ローカル・トランザクション、あるいは、グローバルまたは分散トランザクション）に加えることができます。 これらのコミットは、アダプタ（インバウンド）またはBPELエンジン（アウトバウンド）により制御されます。 非トランザクション・アダプタには、トランザクション・セマンティクスを使用せずに配信を確実にするための独自のスキームが実装されています。
BPEL PM 10.1.3のトランザクション・アダプタでは、JCA 1.5 XA規約を介して、グローバル（2フェーズ・コミット）・トランザクションをサポートしています。 これには、Oracle Applications、Oracle Database、Advanced Queuing、JMSおよびMQSeries用のアダプタが含まれます。 非トランザクション・アダプタには、ファイル・アダプタおよびFTPアダプタが含まれます。
非同期BPELプロセスの場合、トランザクション・アダプタはグローバルJTAトランザクションを開始してからインバウンド・メッセージをBPELに送信します。 このインバウンド・メッセージは、BPELエンジンの配信サービスを介してデハイドレーション・ストアのキューに入ります。 制御がアダプタに戻ると、アダプタはJTAトランザクションをコミットします。このようにして、次の一連のアクションを最小の作業ユニットとして実行します。
この処理中に何らかの失敗があった場合、アクション1および2の両方がロールバックされることが保証されています。
アダプタからデハイドレーション・ストアへのメッセージ配信が成功した後は、そのインバウンド・メッセージは次のBPELプロセスのデハイドレーション・ポイントが発生するまで（たとえば、最初の起動まで）、ストア内に残ります。 次のデハイドレーション・ポイントで、受信アクティビティからのメッセージは配信サービスから削除されます。 これらのチェックポイント間のアクティビティはすべてJTA（グローバル）トランザクションの一部として扱われます。 2つのデハイドレーション・ポイント間でBPELサーバーに障害が発生した場合は、トランザクション全体がロールバックされて、状態が保証されます。 最新のメッセージは、次に使用可能となったBPELサーバーにより再実行されます。 これらはすべて表面的に見えることなく行われます。
同期プロセスの場合、アダプタにより開始されたグローバル・トランザクションでは、メッセージ配信およびBPELプロセスの実行が最初のリプライ・アクティビティ（通常プロセス・フローの最後に配置）までにわたります。
トランザクション・アダプタの場合、アウトバウンドJCA相互作用（invokeアクティビティ）は、グローバルBPEL JTA（ejb）トランザクションで精査されます。 これはJCAアダプタの起動を含むすべてのBPELアクティビティがグローバル・トランザクションの一部となることを意味し、そのため、すべてのアクティビティは、コミットされるか、またはエラーが発生した場合はロールバックされるかのどちらかになります。
たとえば、BPELプロセスでは、（データベース・アダプタを起動する）異なるinvokeアクティビティを介して、（異なるデータベース上の）複数の表にデータを挿入できます。 BPELインスタンスがほぼ終了すると、JTAトランザクションはコミットされます。 この時点でのみデータベースの挿入操作がコミットされます。 BPELインスタンスの実行中にエラーが生じた場合は、すべてのアクティビティ（およびデータベース操作）は最後のデハイドレーション・ポイントまでロールバックされます。
アダプタ・フレームワークでは、インバウンド・アダプタ・サービスのアクティブ・フェイルオーバーがサポートされます。 これを実現するには、特定のJCAアクティブ化エージェントにプロパティを追加します（bpel.xml内）。次に例を示します。
<activationAgents> <activationAgent className="..." partnerLink="MyInboundAdapterPL"> <property name="clusterGroupId">myBpelCluster</property>
クラスタ内の各BPEL PMサーバー（JVM）がTCP/IPのサブネットの境界を越えて配置されている場合は、属性clusterAcrossSubnet=trueを追加する必要があります。
クラスタ・グループ内では、同じアダプタ（ファイル・アダプタなど）のアクティブ化エージェントが（特定のパートナ・リンクについて）複数アクティブ化されると、そのクラスタ内でアクティブになっているアダプタ・フレームワークのすべてのインスタンスで、暗黙的かつ自動的に検出されます。 実際にメッセージの読取りまたはパブリッシュを開始するために許可されるアクティブ化は、1つのみです。 アダプタ・フレームワーク・インスタンスによって、複数あるアクティブ化のうち、どれをプライマリとするかについてはランダムに、1つが選択されます。 クラスタ内のその他のアクティブ化（インスタンス）は、JCAリソース・アダプタ上で実際にEndpointActivationを起動させずに、ホット・スタンバイ状態で開始されます。
プライマリのアクティブ化対象がいずれかのポイントで反応しなくなった場合、つまり、手動で非アクティブ化されたり、クラッシュまたは終了した場合は、クラスタ・グループの残りのアダプタ・フレームワーク・メンバーのうちの1つが即時にこれを検出し、プライマリのアクティブ化対象をスタンバイのアクティブ化エージェントのうちの1つに割り当てます。 この機能では、実装の基底部分でJGroupsのclusterGroupIdプロパティを使用しています。
アダプタ・サービスは、JDeveloperとBPELコンソールを使用して、2つの方法でデプロイできます。また、BPELプロセスをデプロイすることでもアダプタ・サービスがデプロイされます。アダプタ・サービスは、BPELコンソールを使用して削除できます。
バッチ化およびバッチ分割化機能は、OracleAS Adapter for Files、OracleAS Adapter for FTPおよびOracleAS Adapter for Databasesのみでサポートされます。OracleAS Adapter for FilesおよびOracleAS Adapter for FTPは、単一の大きなファイルを複数のバッチに分割できるリーダーで構成されます。設計時の構成でバッチ・サイズを指定する必要があります。また、アダプタには、一連のメッセージを単一のファイルにバッチ化するライターが含まれています。
OracleAS Adapter for Databasesは、一連の表をポーリングしてイベントを検出するパブリッシュ・コンポーネントで構成されます。このコンポーネントは、一度に1つのレコードまたは一度に複数のレコードをBPELプロセスに呼び出すことができます。
アダプタ構成ウィザードで生成されるすべてのアダプタ・サービスWSDLは、JNDI名への参照を持ちます。 この参照は、アダプタのデプロイメント・ディスクリプタであるoc4j-ra.xml内で、jca:address要素のロケーション属性を介して定義されます。 これが、開発環境から本番環境のためのテスト環境へ移行する際のキーとなります。 oc4j-ra.xmlファイルを更新して、開発、テストおよび本番の3つの環境すべてにおいて同じJNDI名を持つようにする必要があります。 再試行間隔や再試行回数など、デプロイ時のプロパティに対して値を指定し、その後、テスト環境や本番環境に再デプロイする必要があります。 oc4j-ra.xmlでは、エンドポイントが開発EIS、テストEISまたは本番EISとして識別されます。 たとえば、データベース・アダプタ・サービス・ウィザードを介して実行する場合に、createCustomerサービス用のJNDI名としてeis/DB/custStoreを指定したとします。 このアダプタ・サービスを使用してBPELプロセスをモデリングした後は、これを変更せずに開発、テストまたは本番環境にデプロイする必要があります。 ただし、これを実行する前に、各環境において、正しいEISインスタンスを示すeis/DB/custStoreに対応したJNDIエントリがあることを確認してください。
|
 Copyright © 2006 Oracle Corporation. All Rights Reserved. |
|