| Oracle Application Serverリリース・ノートおよび新機能 10gリリース3（10.1.3.4） B50870-02 |
|
 戻る |
 次へ |
この章では、Oracle Application Serverテクノロジ・アダプタに関連する問題について説明します。内容は次のとおりです。
MaxTransactionSizeDatabaseアダプタで、MaxTransactionSizeに制限値を設定します。たとえば、次のように設定します。
MaxTransactionSize=10
MaxTransactionSizeにより大きな値を設定すると、タイムアウトになる可能性があります。
RACでXAを使用すると、フェイルオーバー中のマスター/ディテール・アダプタの処理時にメッセージが失われます。
Oracle Application Server 10gリリース10.1.3.4でのRACのXAでは、複数のコンポーネントがRACデータベースに接続されている場合、それらが同じ接続プール定義だけでなく、必ず同じ管理データソース定義も共有するようにします。
Oracleファイル/FTPアダプタのクラスタリングは、異なるサブネット内のエンドポイント間では機能しません。ただし、UDPプロトコルでは適切に機能します。
この問題を解決するには、SOAクラスタがサブネットをまたぐ場合、jgroups-protocol.xmlでTCPプロトコルを使用し、対応するBPELプロセスのbpel.xmlで必ずアクティブ化エージェント・プロパティuseJGroupConfigFile=falseを設定します。
この項では、次のテクノロジ・アダプタに対するOracle Application Server 10gリリース10.1.3.4の新機能について説明します。
Oracle Application Server 10gリリース10.1.3.4には、ネイティブ・フォーマット・ビルダー・ウィザードに次の新機能が含まれています。
データにデリミタなどの特殊文字が含まれるインスタンスが存在する場合があります。そのような場合、実際のデータは引用符に囲まれている必要があります。フィールド・データに引用符が存在する場合、埋め込まれる引用符を二重にし、二重引用符によりフィールドを区切る必要があります。次のCSVデータ・フィールドの例を見てみます。
Arun said, " I love google".
この例の特殊文字は、次のようにネイティブでエスケープする必要があります。
"Arun said, "" I love google""."
ここでは特殊文字「,（カンマ）」と「"（二重引用符）」がデータに含まれています。
レベル1およびレベル2のインバウンド操作でさらに厳密な検証が実行されるように、アダプタを構成できます。この新機能により、アダプタで無効なレコードが公開されないようになります。このリリースでは、次の検証が使用可能です。
トップレベルで、XMLスキーマに対してDOMResultを検証できます。この種の検証は役立ちますが、このエラーが発生したネイティブ・ストリームの行や列などの変換コンテキスト情報は得られません。ただし、この検証により、無効なレコードが公開されるのを制御でき、XML検証エラーが発生します。次のコードSnippetにより、XML検証が有効になります。
<schema xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:nxsd="http://xmlns.oracle.com/pcbpel/nxsd"
targetNamespace="http://xmlns.oracle.com/pcbpel/nxsd/smoketest"
elementFormDefault="qualified"
attributeFormDefault="unqualified"
nxsd:stream="chars"
nxsd:version="NXSD"
nxsd:validation="true"
>
フィールドレベルでのタイプ検証サポート、つまりXMLスキーマ・タイプ検証は、ネイティブ・ストリームから読み取られたトークンごとに実行されます。エラーが発生した場合、この検証の失敗が発生したネイティブ・ストリーム内の行番号と列番号、および対応するXMLタイプとともにエラーが報告されます。
次のコードSnippetにより、フィールドレベルの検証が有効になります。
<schema xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:nxsd="http://xmlns.oracle.com/pcbpel/nxsd"
targetNamespace="http://xmlns.oracle.com/pcbpel/nxsd/smoketest"
elementFormDefault="qualified"
attributeFormDefault="unqualified"
nxsd:stream="chars"
nxsd:version="NXSD"
nxsd:fieldValidation="true"
>
現在のところ、フィールドレベルの検証では、XMLスキーマ・パターンおよびファセットレベルの検証はサポートされていません。
Oracle Application Server 10gリリース10.1.3.4には、ファイルおよびFTPアダプタの次の新機能が含まれています。
ファイルおよびFTPアダプタには、1つの場所から別の場所へファイルをコピーまたは移動したり、ターゲット・フォルダからファイルを削除する機能があります。さらに、FTPアダプタを使用すると、ローカル・ファイル・システムからリモート・ファイル・システムへのファイルの移動やコピー、またその逆が可能です。
FTPアダプタには、SFTPおよびFTPSの変数が含まれています。
Oracle JDeveloperリリース10.1.3.4では、この機能はサポートされていません。ただし、この機能を手動で構成することは可能です。この新機能は、アウトバウンド・サービス用の新しい相互作用仕様として実装されます。したがって、この機能には、BPEL invokeアクティビティまたはESBルーティング・ルールのいずれかを使用してアクセスできます。
高レベルでアウトバウンド・サービスを作成し、このサービスをソース・ディレクトリとターゲット・ディレクトリおよびファイル名を使用して構成する必要があります。
次のユースケースでは、アウトバウンド・サービスの使用によりファイルをコピー、移動および削除できる、ファイルおよびFTPアダプタでサポートされている新機能を説明しています。
11.4.2.1.1項「ユースケース1: ファイル・システムのローカル・フォルダから別のローカル・フォルダへのファイルの移動」
11.4.2.1.2項「ユースケース2: ファイル・システムのローカル・フォルダから別のローカル・フォルダへのファイルのコピー」
11.4.2.1.5項「ユースケース5: 同じFTPサーバーのリモート・フォルダから別のリモート・フォルダへのファイルの移動」
11.4.2.1.6項「ユースケース6: ファイル・システムのローカル・フォルダからFTPサーバーのリモート・フォルダへのファイルのコピー」
11.4.2.1.7項「ユースケース7: ファイル・システムのリモート・フォルダからファイル・システムのローカル・フォルダへのファイルのコピー」
対応するOracle JDeveloperウィザードを使用できないため、ウィザードを使用してこの手順の一部のみをモデル化します。生成されたWSDLファイルを手動で構成して、残りの手順を完了します。
ファイル・システムのローカル・フォルダから別のローカル・フォルダにファイルを移動する手順は、次のとおりです。
図11-1のように、空のBPELプロセスを作成します。
BPELの「サービス」リストから「ファイル・アダプタ」をドラッグ・アンド・ドロップします。
アダプタ構成ウィザードが表示されます。
「次へ」をクリックします。「サービス名」ページが表示されます。
図11-2のように、サービス名を入力し、オプションで説明を入力して、「次へ」をクリックします。
「操作」ページで、図11-3のように、操作として「同期Read File」を選択します。オプションで操作名を変更し、「次へ」をクリックします。
操作として「同期Read File」を選択したのは、この操作の結果として生成されるWSDLファイルが、ファイルI/O操作に必要なファイルと似ているためです。
「ファイル・ディレクトリ」ページで、図11-4のように、すぐには使用されないダミー・ディレクトリを選択し、「次へ」をクリックします。ディレクトリは後から手動で変更します。
「ファイル名」ページで、図11-5のように、すぐには使用されないダミー・ファイルを選択し、「次へ」をクリックします。ファイル名は後から手動で変更します。
「メッセージ」ページで、図11-6のように、「ネイティブ・フォーマット変換は不要(スキーマを不透明(Opaque)にする)」を選択し、「次へ」をクリックします。
「終了」をクリックします。
図11-7のように、先ほど作成したMoveFileServiceサービスのinvokeアクティビティを作成します。
次の手順は、MoveFileServiceサービス用に生成されたWSDLファイルを変更し、移動操作の新しい相互作用仕様で構成するためのものです。
MoveFileService.wsdlファイルを開き、次の例のように、jca:operationを変更します。
WSDLファイルをソース、ターゲット・ディレクトリおよびファイルの詳細によって構成します。ソース、ターゲット・ディレクトリおよびファイルの詳細をWDLファイルでハードコードすることも、それらを移入するヘッダー変数を使用することもできます。次の例では、ヘッダー変数を使用します。
<jca:operation InteractionSpec="oracle.tip.adapter.file.outbound.FileIoInteractionSpec" SourcePhysicalDirectory="foo1" SourceFileName="bar1" TargetPhysicalDirectory="foo2" TargetFileName="bar2" Type="MOVE"> </jca:operation>
|
注意: className属性を変更し、SourcePhysicalDirectory、SourceFileName、TargetPhysicalDirectory、TargetFileNameおよびTypeを追加しました。現在のところ、ソースおよびターゲットの詳細の値はダミーです。実行時にそれらに値を移入します。それらを特定のディレクトリやファイル名にハードコードすることもできます。
|
ダミー・ソースとターゲットの詳細でWDLファイルを構成したので、実行時にオーバーライドできるように、ヘッダーを指定することが必要になります。まず、fileAdapterOutboundHeader.wsdlを変更し、次の例のように、新しいヘッダーを追加します。
<types>
<schema ..>
<element name="OutboundFileHeaderType">
<complexType>
<sequence>
<element name="fileName" type="string"/>
<element name="directory" type="string"/>
<element name="sourceDirectory" type="string"/>
<element name="sourceFileName" type="string"/>
<element name="targetDirectory" type="string"/>
<element name="targetFileName" type="string"/>
</sequence>
</complexType>
</element>
</schema>
</types>
これは、実行時にソース、ターゲット・ディレクトリおよびファイルの詳細をオーバーライドする際にBPELヘッダー・メカニズムを使用するために必要です。
図11-8のように、invokeアクティビティのヘッダー変数を作成します。
図11-9のように、新しいヘッダー変数を作成し、fileAdapterOutboundHeader.wsdlファイルのOutboundHeader_msgメッセージ・タイプで構成します。
図11-10のように、sourceDirectory、sourceFileName、targetDirectoryおよびtargetFileNameのヘッダー変数値を割り当てるためのassignアクティビティを作成します。
同様に、sourceFileName、targetDirectoryおよびtargetFileNameに対するコピー操作を作成します。これでBPELソース・ビューには、次のコードSnippetに示すように、割当て操作が表示されます。
<assign name="AssignFileDetails">
<copy>
<from expression="'C:\source'"/>
<to variable="outHeader" part="outboundHeader"
query="/ns2:OutboundFileHeaderType/ns2:sourceDirectory"/>
</copy>
<copy>
<from expression="'in.zip'"/>
<to variable="outHeader" part="outboundHeader"
query="/ns2:OutboundFileHeaderType/ns2:sourceFileName"/>
</copy>
<copy>
<from expression="'C:\target'"/>
<to variable="outHeader" part="outboundHeader"
query="/ns2:OutboundFileHeaderType/ns2:targetDirectory"/>
</copy>
<copy>
<from expression="'out.zip'"/>
<to variable="outHeader" part="outboundHeader"
query="/ns2:OutboundFileHeaderType/ns2:targetFileName"/>
</copy>
</assign>
ここではソースとターゲットの詳細がハードコードされています。これらの詳細は、ランタイム・パラメータとしても指定できます。
最後に、初期receiveまたはpickアクティビティを追加します。
ファイル・システムのローカル・フォルダから別のローカル・フォルダへのファイルの移動が完了しました。
ファイル・システムのローカル・フォルダから別のローカル・フォルダにファイルをコピーする手順は、次のとおりです。
11.4.2.1.1項「ユースケース1: ファイル・システムのローカル・フォルダから別のローカル・フォルダへのファイルの移動」の手順1〜10に従います。
11.4.2.1.1項「ユースケース1: ファイル・システムのローカル・フォルダから別のローカル・フォルダへのファイルの移動」の手順11で、次の例のように、jca:operationでTYPE属性の値をCOPYに変更します。
<jca:operation
InteractionSpec="oracle.tip.adapter.file.outbound.FileIoInteractionSpec"
SourcePhysicalDirectory="foo1"
SourceFileName="bar1"
TargetPhysicalDirectory="foo2"
TargetFileName="bar2"
Type="COPY">
</jca:operation>
ファイルを削除するために必要なパラメータは、TargetPhysicalDirectoryとTargetFileNameです。ローカル・ファイル・システム・フォルダからファイルを削除するのに、SourcePhysicalDirectoryとSourceFileNameは必要ありません。
/home/alexからdelete_me.txtファイルを削除する手順は、次のとおりです。
11.4.2.1.1項「ユースケース1: ファイル・システムのローカル・フォルダから別のローカル・フォルダへのファイルの移動」の手順1〜10に従います。
11.4.2.1.1項「ユースケース1: ファイル・システムのローカル・フォルダから別のローカル・フォルダへのファイルの移動」の手順11で、次の例のように、jca:operationのTYPE属性の値をDELETEに変更します。
<jca:operation
InteractionSpec="oracle.tip.adapter.file.outbound.FileIoInteractionSpec"
TargetPhysicalDirectory="/home/alex"
TargetFileName="delete_me.txt"
Type="DELETE">
</jca:operation>
次のシナリオを考えます。
ソース・フォルダでまもなくサイズが1GBになる大きなファイルがあり、次の操作を実行する必要があります。
CSVをXMLに変換します。
結果のXMLを、XSLを使用して変換します。
最後に、変換操作の結果を固定長のファイルに変換します。
このユースケースは、121.FileAdapterのBPELサンプル・ディレクトリにおけるFlatStructureサンプルと似ています。違いは、1つのファイルI/O相互作用に3つの手順が発生する点です。
1つのファイルI/O相互作用で3つの手順すべてが発生するのは、データ・ファイル内のレコードがすべて同じ型である場合に限られます。
CSVファイルで3つの操作を実行する手順は、次のとおりです。
address-csv.xsdファイルとaddress-fixedLength.xsdファイルを、FlatStructureサンプルからプロジェクトのxsdディレクトリにコピーします。
addr1Toaddr2.xslをFlatStructureサンプルからプロジェクトのxslディレクトリにコピーします。
ファイルI/O相互作用を、次の例のように構成します。次の例に示すように、相互作用仕様の高いレベルで、ソース、ターゲット・フォルダ、ファイルの詳細とともに、ソース・スキーマ、ターゲット・スキーマおよびXSLを指定する必要があります。
<jca:operation
InteractionSpec="oracle.tip.adapter.file.outbound.FileIoInteractionSpec"
SourcePhysicalDirectory="C:\inputDirectory"
SourceFileName="input.csv"
TargetPhysicalDirectory="C:\outputDirectory"
TargetFileName="output_fixedLength.txt"
SourceSchema="address-csv.xsd"
SourceSchemaRoot ="Root-Element"
SourceType="native"
TargetSchema="address-fixedLength.xsd"
TargetSchemaRoot ="Root-Element"
TargetType="native"
Xsl="addr1Toaddr2.xsl"
Type="MOVE">
</jca:operation>
ここでは、次の追加パラメータを指定しています。
SourceSchema: ソース・スキーマへの相対パス。
SourceSchemaRoot: ソース・スキーマ内のルート要素。
SourceType: データの型。他に指定可能な型はXMLです。
TargetSchema: ターゲット・スキーマへの相対パス。
TargetSchemaRoot: ターゲット・スキーマ内のルート要素。
TargetType: データの型。他に指定可能な型はXMLです。
XSL: XSLファイルへの相対パス。
FTPアダプタのI/Oユースケースは、ファイル・アダプタのユースケースと非常に似ています。ただし、注意が必要な微妙な差異がいくつかあります。
同じフォルダ内でファイルを移動するため、同じサーバー上の名前変更操作のように見えるため注意が必要です。ほとんどのFTPサーバーではFTPサーバー上のファイル名を変更できるRNFRとRNTO FTPコマンドがサポートされています。
ただし、RNFRとRNTOコマンドがサポートされていなくても、バインディング・プロパティUseNativeRenameOperationによって、同じフォルダ内でのファイルの移動は可能です。このプロパティがTRUEに設定されている場合、FTPアダプタではネイティブのRNFRおよびRNTOコマンドを使用します。ただし、このプロパティがFALSEに設定されている場合、FTPアダプタではGetコマンドとPutコマンドの後にDeleteコマンドを続けて使用し、移動操作をエミュレートします。デフォルトでは、UseNativeRenameOperationがFALSEに設定され、FTPアダプタでは移動操作をエミュレートします。FTPサーバーでRNFRコマンドとRNTOコマンドがサポートされている場合、このプロパティをTRUEに設定します。
ファイルI/Oの場合と同様に、対応するOracle JDeveloperウィザードを使用できないため、Oracle JDeveloperウィザードを使用してユースケースの一部をモデル化する必要があります。
このユースケースのモデル化は、ユースケース1との次の2つの相違点を除き、11.4.2.1.1項「ユースケース1: ファイル・システムのローカル・フォルダから別のローカル・フォルダへのファイルの移動」に似ています。
InteractionSpecをoracle.tip.adapter.ftp.outbound.FTPIoInteractionSpecに変更します。
UseNativeRenameOperationのアウトバウンド・パートナ・リンクのbpel.xmlファイルにエンドポイント・プロパティを1つ追加します。
FTPサーバーでRNFRとRNTO FTPコマンドがサポートされている場合、UseNativeRenameOperationをTRUEに設定する必要があります。サポートされていない場合は、FALSEに設定します。例のように、bpel.xmlでプロパティを定義します。
<partnerLinkBinding name="FtpRenameSvc">
<property name="wsdlLocation">FtpRenameSvc.wsdl</property>
<property name=" UseNativeRenameOperation">true</property>
<property name="retryInterval">60</property>
</partnerLinkBinding>
次の例のように、InteractionSpecクラス名に対してのみ変更を加えて、11.4.2.1.1項「ユースケース1: ファイル・システムのローカル・フォルダから別のローカル・フォルダへのファイルの移動」で説明されている残りの手順に従います。
<jca:operation
InteractionSpec="oracle.tip.adapter.ftp.outbound.FTPIoInteractionSpec"
SourcePhysicalDirectory="foo1"
SourceFileName="bar1"
TargetPhysicalDirectory="foo2"
TargetFileName="bar2"
Type="MOVE">
</jca:operation>
このユースケースの手順は、ソース・フォルダをローカルとして、ターゲット・フォルダをリモートとして構成する必要がある点を除けば、11.4.2.1.5項「ユースケース5: 同じFTPサーバーのリモート・フォルダから別のリモート・フォルダへのファイルの移動」と同じです。
次の例のように、SourceIsRemoteとTargetIsRemoteの2つのプロパティを使用して、ソース・ファイルまたはターゲット・ファイルをローカルまたはリモートのいずれのファイル・システムに置くかを指定します。
<jca:operation
InteractionSpec="oracle.tip.adapter.ftp.outbound.FTPIoInteractionSpec"
SourcePhysicalDirectory="foo1"
SourceFileName="bar1"
SourceIsRemote="false"
TargetPhysicalDirectory="foo2"
TargetFileName="bar2"
Type="COPY">
</jca:operation>
SourceIsRemoteをFALSEとして構成しています。この場合、FTP I/Oでは、ソース・ファイルがローカル・ファイル・システムのものであるとみなされます。また、デフォルトでは、TargetIsRemoteがTRUEに設定されているため、ターゲットのパラメータは指定していません。
このユースケースの手順は、次の例のように、ソース・フォルダをリモートとして、ターゲット・フォルダをローカルとして構成する必要がある点を除けば、11.4.2.1.6項「ユースケース6: ファイル・システムのローカル・フォルダからFTPサーバーのリモート・フォルダへのファイルのコピー」と同じです。
<jca:operation
InteractionSpec="oracle.tip.adapter.ftp.outbound.FTPIoInteractionSpec"
SourcePhysicalDirectory="foo1"
SourceFileName="bar1"
TargetPhysicalDirectory="foo2"
TargetFileName="bar2"
TargetIsRemote="false"
Type="COPY">
</jca:operation>
TargetIsRemoteをFALSEとして構成しています。この場合、FTP I/Oでは、ソース・ファイルはリモート・ファイル・システムのもので、ターゲットはローカル・ファイル・システム・フォルダにあるとみなされます。また、デフォルトでは、SourceIsRemoteがTRUEに設定されているため、ソースのパラメータは指定していません。
さらに、SourceIsRemoteとTargetIsRemoteの両方をFALSEに設定することはできません。このユースケースはファイル・アダプタには適用できますが、FTPアダプタには適用できないためです。
このユースケースの場合、11.4.2.1.6項「ユースケース6: ファイル・システムのローカル・フォルダからFTPサーバーのリモート・フォルダへのファイルのコピー」と11.4.2.1.7項「ユースケース7: ファイル・システムのリモート・フォルダからファイル・システムのローカル・フォルダへのファイルのコピー」を順次実行する必要があります。ユースケース6では、FTPサーバーのファイルがローカル・ディレクトリにダウンロードされ、ユースケース7では、ファイルがローカル・ディレクトリから別のFTPサーバーにアップロードされます。
Oracle Application Server 10gリリース10.1.3.4では、LinuxのFTPアダプタでもSSLがサポートされるようになりました。これは、以前はSolarisだけでサポートされている機能でした。
LinuxでのSSLの構成は、Solaris用の構成と同じです。この構成については、これまでのリリース（Oracle Application Server 10gリリース10.1.3など）の、SSL経由のFTPに関するドキュメントで説明されています。さらに、次のパラメータを構成する必要があります。
keyStoreProviderName: oracle.security.pki.OraclePKIProvider
keystoreType: PKCS12
keystoreAlgorithm: OracleX509
pkiProvider: OraclePKI
jsseProvider: OracleJSSE
必ずSOA-HOME\jdk\jre\lib\securityディレクトリにOraclePKIProvider in java.securityポリシーを追加します。
現行のXML仕様（http://www.w3.org/TR/REC-xml/#sec-line-endsで入手可能）には、次のように記載されています。
0x0D、すなわちキャリッジ・リターン（CR）がすべて、0x0A、すなわちライン・フィード（LF）に変換されます。
連続した0x0Aはすべて1つの0x0Aに変換されます。
たとえば、次のようになります。
0x0D --> 0x0A
0x0D0x0A --> 0x0A
0x0A0x0A0x0A --> 0x0A
ソースからターゲットへデータの一貫性を維持するために、前述の例で示したようなCR文字とLF文字（0x0Dと0x0A）の変換を回避するには、オプションが必要です。
Oracle Application Server 10gリリース10.1.3.4には、トップ・レベルのスキーマ・ディレクティブとしてnormalizeLineTerminatorsとencodeLineTerminatorsの2つの新しいパラメータが追加された機能が含まれています。
nxsd:normalizeLineTerminators="false"の場合、トランスレータによって新しい行文字は正規化されません。たとえば、\r\nは0x0D0x0A文字列として維持されます。デフォルトでは、normalizeLineTerminators="true"で、行終了文字の文字列は\nに正規化されます。nxsd:encodeLineTerminators="true"の場合は、トランスレータにより行終了文字がエンコードされます。たとえば、ライン・フィード（\n）は
としてエンコードされ、キャリッジ・リターン（\r）は としてエンコードされます。デフォルトでは、encodeLineTerminatorsはFALSEに設定されています。つまり、\nは0x0Aとして、\rは0x0Dとして表示されます。
Oracle Application Server 10gリリース10.1.3.4には、ファイル・アダプタのアクティブ化仕様で、新しいパラメータSorterを構成することにより、ファイルをソートするようにインバウンド・アダプタを構成できる機能が含まれています。
Sorterパラメータでは現在のところ、次の例のように、変更時間の昇順でファイルをソートする値と、降順でソートする値の2つの値がサポートされています。
Set
Sorter="oracle.tip.adapter.file.sorter.TimestampSorterAscending"
in order to sort the file names by their modified timestamps in ascending manner
or
Sorter="oracle.tip.adapter.file.sorter.TimestampSorterDescending
in order to sort the file names by their modified timestamps in descending manner
You can also plugin your own sorter by implementing java.util.Comparator e.g.
public class MySorter implements Comparator
{
public int compare(Object a, Object b)
{
FileInfo first = (FileInfo)a;
FileInfo second = (FileInfo)b;
if(first.get…()… > second.get…())
return 1;
else if(first.get…() < second.get…())
return -1;
return 0;
}
}
最後に、MySorter.classをbpel/system/classesフォルダにコピーする必要があります。
|
注意: この機能は、次の2つの条件を満たした場合にのみ機能します。
|
Oracle Application Server 10gリリース10.1.3.4には、Oracle JMSアダプタの次の新機能が含まれています。
MapMessageは、一連の名前値ペア（名前が文字列、値がJavaプリミティブ型）を送信するために使用されます。エントリには、順次または無作為に名前でアクセスすることができます。エントリの順序は定義されていません。これはメッセージから継承され、マップ・メッセージ・ボディが追加されます。
Oracle JMSアダプタでは、MapMessageの処理がサポートされています。さらに、アクティブ化および相互作用のそれぞれ1つの新しい仕様、JmsMapMessageConsumeActivationSpecおよびJmsMapMessageProduceInteractionSpecがサポートされるようになりました。PayloadEntryプロパティは、ペイロードとして使用されるMapMessageエントリを指定します。AttachmentListプロパティが定義されている場合、ユーザーには、ペイロードを添付ファイルとして送信するオプションがあります。PayloadEntryとAttachmentListの両プロパティが定義されていない場合、MapMessage全体がXMLに変換され、XMはペイロードとして転送されます。
Oracle JMSアダプタは、WebLogic JMSプロバイダとActive MQ-JMSプロバイダの両方で動作するようになりました。
Oracle Application Server 10gリリース10.1.3.4には、Oracle AQアダプタの次の新機能が含まれています。
DequeueTimeoutプロパティリリース10.1.3.xで適用されるDequeueTimeOutプロパティは、複数のインバウンド・デキュー・スレッドをサポートします。このプロパティの値により、dequeue() APIが戻って、次のポーリング・サイクルが始まる前に、メッセージを待つ秒数が決まります。
このプロパティを、次の例のように、bpel.xmlファイルに追加します。
<partnerLinkBindings>
<partnerLinkBinding name="InboundPartnerLink">
<property name="wsdlLocation">Dequeuer.wsdl</property>
</partnerLinkBinding>
...
<activationAgents>
<activationAgent className="oracle....JCAActivationAgent"
partnerLink="InboundPartnerLink">
<property name="DequeueTimeOut">60</property>
Oracle AQアダプタでは、アクティブ化プロパティadapter.aq.dequeue.threadsにより、複数のデキュー・スレッドがサポートされるようになりました。このプロパティの値により、アクティブ化が開始された時点でアクティブになるポーリング・スレッド数が決まります。次の例では、アクティブ化プロパティadapter.aq.dequeue.threadsを使用しています。
<service name="Raw-Dequeuer">
<interface.wsdl interface="http://xmlns.oracle.com/pcbpel/adapter/aq/Raw_Dequeuer/#wsdl.interface(Dequeue_ptt)"/>
<binding.jca config="Raw-Dequeuer_aq.jca"/>
<property name="adapter.aq.dequeue.threads">2</property> </service>
Oracle Application Server 10gリリース10.1.3.4には、Oracleデータベース・アダプタの次の新機能が含まれています。
純粋なSQLアダプタは、データベース・アダプタ・ウィザードのオプションで、SQLを直接入力し、XSD/Webサービスが自動的に生成されるようにすることができます。ウィザードでは、SQLをテストし、XSDにより適切な値、つまり有効な戻り型を移入するために、データベース表が動的にイントロスペクトされます。
純粋なSQLのサポートにより、データベース・アダプタで表またはビューをエンティティとして処理し、SQLを直接処理できます。次の場合に純粋なSQLを使用できます。
単純なデータ予測スタイルのレポート問合せの場合
結果セットが表主体ではない場合（select count(*)など）
すべて更新またはすべて削除を実行する場合
XMLType列およびxqueryを処理する場合
ウィザードの式ビルダーでモデル化できない複雑なSQLを使用する場合
純粋なSQLアダプタはOracle XMLTypesで使用できます。XMLをXMLType表および列に挿入し、xquery SELECT文を使用してXMLを取得するのに適しています。純粋なSQLは、XML DB（XDB）サポートに匹敵するリレーショナルXMLマッピングを提供するデータベース・アダプタに適しています。したがって、XDBを使用するとき、アダプタはできるだけ軽量かつ透過的にして、XDBとXqueryに重点を置けるようにする必要があります。
データがXML（非構造/半構造）フォーマットで、データをマップできるリレーショナル・スキーマがまったくない場合、XDBを使用できます。従来のデータベース・アダプタでは、既存のリレーショナル・スキーマをWebサービスで使用するXMLスキーマとしてインポートできます。XDBのXMLシュレッディング・アルゴリズムは、既存のXMLスキーマから永続記憶域にリレーショナル・スキーマを生成できます。
|
注意: Oracle Application Server 10gリリース10.1.3.3では、XMLTypesは、従来の表/ビュー・データベース・アダプタでサポートされていません。データベース・アダプタ・ストアド・プロシージャは、匿名XMLTypesをサポートします。 |
Oracle Application Server 10gリリース10.1.3.4には、Oracle MQSeriesアダプタの次の新機能が含まれています。
インバウンド・アダプタで変換用にMQメッセージのキャラクタ・セットを使用するには、ActivationSpecで次のプロパティをTRUEに設定します。
UseMessageEncodingForTransalation="true"
UseMessageEncodingForTransalationをTRUEに設定すると、MQSeriesアダプタでは、MQメッセージで変換用に指定されているキャラクタ・セットが使用されます。このプロパティのデフォルト値はTRUEです。UseMessageEncodingForTransalationをFALSEに設定すると、アダプタではスキーマ（NXSD）・ファイルで指定されているキャラクタ・セットが使用されます。
同様に、アウトバウンド・アダプタでは、実行時に指定されるキャラクタ・セットを使用する場合、アウトバウンド・ヘッダー・ファイルMQOutboundHeader.wsdlでキャラクタ・セットを指定し、InteractionSpecでUseMessageEncodingForTransalationをTRUEに設定できます。
現在のところ、MQOutboundHeader.wsdlファイルで、CodedCharSetId要素は使用できません。これはOracle JDeveloperで手動により追加する必要があります。CodedCharSetId要素をアウトバウンドWSDLに割り当てる場合、次の手順を実行します。
MQアダプタ用のアウトバウンド・サーバーを作成した後、MQAdapterOutboundHeader.wsdlファイルのMQOutboundHeader要素に、次のコードを追加します。
<element name="CodedCharSetId" type="string" minOccurs="0" />
Oracle JDeveloperを再起動します。
invokeアクティビティを作成し、「アダプタ」タブで、アウトバウンド・ヘッダー変数を作成します。
手順3で作成したアウトバウンド・ヘッダー変数を使用して、CodedCharSetID要素をアウトバウンド・ヘッダーに割り当てます。
