9 Oracle JCA Adapter for Database

この章では、Oracle JCA Adapter for Databaseについて説明します。また、Oracleデータベース・アダプタおよびストアド・プロシージャの使用例も参照できます。

この章の内容は次のとおりです。

9.1 Oracleデータベース・アダプタの概要

Oracleデータベース・アダプタを使用すると、SOAコンポジット・アプリケーションでJDBCを介してOracle Databaseまたはサード・パーティ・データベースと通信できます。

この項には次のトピックが含まれます:

9.1.1 機能概要

この項では、Oracleデータベース・アダプタの機能概要について説明します。Oracleデータベース・アダプタを使用すると、Oracle SOA SuiteおよびOracle Fusion Middlewareとデータベース・エンドポイントとの通信が可能になります。データベース・エンドポイントとしては、ANSI SQL標準に準拠し、JDBCドライバを備えたOracleデータベース・サーバーおよびリレーショナル・データベースがあげられます。

Oracleデータベース・アダプタの表やビューは原則的に、できるかぎり透過的でノン・イントルーシブにSOA表およびSQLに対して公開されます。表およびSQLはリレーショナル・データベース製品に必ず備わっているため、統合の観点からは、標準にフォーカスした一般的なソリューションを作成すると、最も大きな影響を及ぼすことができます。データベースをSOAに対して公開する場合、一般的なソリューションとは、情報の問合せに最適なSQLのテクノロジと、情報の転送および表現に最適なXMLのテクノロジを統合することです。ストアド・プロシージャのサポートは各種データベースの中ではそれほど標準的ではありませんが、Oracleデータベース・アダプタでは、このガイドで説明するように、ストアド・プロシージャがサポートされています。

Oracleデータベース・アダプタは、Oracle WebLogic Server上で動作するJCA 1.5コネクタです。これは、データベース通信を実現するために、基礎となるJDBCコネクタ/ドライバに依存します。JDBCとは対照的に、それは非プログラム的です。相互作用(一連のSELECT、UPDATE、INSERT)の概略は、アダプタ構成ウィザードを使用してモデル化されます。入力/出力はXMLであり、XMLが入力パラメータとして使用されたり、XMLに変換された結果セットという形式が最もよく見られます。これらのXMLの入出力により、Oracleデータベース・アダプタ・サービスをOracle Fusion Middlewareにプラグインできるようになります。

既存のリレーショナル・スキーマにアクセスするには、アプリケーションおよびSOAプロジェクトを作成し、アダプタ構成ウィザードを使用して次の手順を実行します。

リレーショナル・スキーマ(1つ以上の関連表)をインポートしXMLスキーマ(XSD)としてマップ

詳細は、「リレーショナルからXMLへのマッピング」を参照してください。
SELECT、INSERTおよびUPDATEなどのSQL操作をWebサービスとして抽出

詳細は、「WebサービスとしてのSQL操作」を参照してください。
データベース・イベントによるOracle Fusion Middlewareプロセスの開始

Oracle Streams Advanced Queuing (Oracle AQ)はOracle Databaseの機能ですが、Oracle AQと統合するには、個別に特化されたOracle JCA Adapter for AQを使用します。詳細は、「概要」を参照してください。

非リレーショナル・データベースとレガシー・システム(AS/400上のDB2など少数の例外は除く)の場合は、アプリケーション・アダプタおよびメインフレーム・アダプタを使用できます。アプリケーション・アダプタおよびメインフレーム・アダプタの詳細は、次の各項を参照してください。

Oracleデータベース・アダプタの詳細は、次の各項を参照してください。

9.1.1.1 Oracleデータベース・アダプタとOracle BPEL PMの統合

Oracleデータベース・アダプタは、データベース・イベントのポーリング(通常は入力表に対するINSERT操作)とプロセスの開始を行うために使用される場合、公開サービスと呼ばれます。Oracle BPELプロセスでは、Oracleデータベース・アダプタはreceiveアクティビティに関連付けられるパートナ・リンクです。通常は、式inbound(データベースからSOAへ)が使用されます。

Oracleデータベース・アダプタは、INSERTまたはSELECTなどの1回かぎりのDML文の起動用として使用される場合、メディエータ・コンポーネントまたはSOAコンポーネントでは、サービス参照と呼ばれます。Oracle BPELプロセスでは、Oracleデータベース・アダプタはinvokeアクティビティに関連付けられたパートナ・リンクです。式outbound (SOAからデータベースへ)が使用されます。

9.1.2 設計の概要

この項では、Oracleデータベース・アダプタの設計の概要について説明します。図9-1に、Oracleデータベース・アダプタが様々な設計時成果物およびデプロイメント成果物とどのように対話するかを示します。

図9-1 Oracleデータベース・アダプタの動作

「図9-1 Oracleデータベース・アダプタの動作」の説明

Oracleデータベース・アダプタは、インストール時にアプリケーション・サーバーにデプロイされるJCA 1.5コネクタです。

Oracleデータベース・アダプタは複数のインスタンスで構成されており、各インスタンスはデータベース・エンドポイントへの接続を表します。異なるSOAプロセスが同じアダプタ・インスタンス(データベース)を指し示すことがある一方、SOAプロセス内の異なるサービス・エンドポイントが異なるアダプタ・インスタンス(データベース)を指し示すこともあります。

各アダプタ・インスタンスは単一のデータベースを指し示すため、アダプタ・インスタンス対アプリケーション・サーバー・データソースは1対1の対応があります。データソースjdbc/SOADataSourceを指し示す、eis/DB/SOADemoという名前の単一のOracleデータベース・アダプタ・インスタンスが、デフォルトで使用できます。

アダプタ・インスタンスのリストは、Oracle WebLogic Server上のデプロイメント・ディスクリプタ・ファイルweblogic-ra.xmlに格納されています。(このディスクリプタ・ファイルはDbAdapter.rar内にあります。この.rarファイルには、DBAdapter.jarが含まれ、さらにその中にJavaクラス・ファイルが含まれています。)Oracleデータベース・アダプタ・インスタンスを構成するには、基礎となるデータソースの作成、つまり、正しいJDBCドライバおよび接続URLの取得が必要です。

詳細は、「JDBCドライバとデータベース接続の構成」を参照してください。

ただし、場合によっては、weblogic-ra.xmlエントリには、基礎となるデータソースの単なる名前以外のものも含まれます。これらのプロパティの詳細は、「データベース・アダプタ・デプロイメント」を参照してください。

実行時にはOracleデータベース・アダプタ・インスタンスを使用しますが、設計時にはアダプタ構成ウィザード(リンク)を使用します。このウィザードを1回実行して1つのアダプタ・サービス・エンドポイントを生成した後で、さらにこのウィザードを編集モードで複数回実行して、それぞれを徐々に変更できます。これにより、表9-1に示すように、SOAコンポジットのデプロイ時に必要となるすべてのアダプタ関連成果物が生成されます。

表9-1 アダプタ構成ウィザードによって生成されるSOAコンポジットのアダプタ成果物

ファイル	説明
`<serviceName>.wsdl`	これは、操作および入出力XML要素の名前によってサービス・エンドポイントを定義する抽象WSDLです。
`<serviceName>_table.xsd`	これには、これらの入出力XML要素のXMLファイル・スキーマが含まれます。これらの両ファイルは、SOAプロジェクトの残りへのインタフェースを形成します。
`<serviceName>_or-mappings.xml`	これは内部ファイルです。リレーショナル・スキーマとXMLスキーマ間のマッピングを記述するために使用されるTopLink固有のファイルです。これは実行時に使用されます。
`<serviceName>_db.jca`	これには、抽象WSDLの内部実装詳細が含まれます。これには、場所と操作に関する2つのメイン・セクションがあります。場所は、アダプタ・インスタンスのJNDI名(`eis/DB/SOADemo`)です。操作は、エンドポイントに対して実行するアクション(`INSERT`、`UPDATE`、`SELECT`および`POLL`など)です。`db.jca`ファイルの内容は、アダプタ構成ウィザードの実行時に行った選択によってすべて決定されます。
`<serviceName>.properties`	これも内部ファイルです。表のインポート時に作成され、表に関する情報が保存されます。設計時にのみ使用されます。実行時には、前述の場所を使用して、サービスを実行するアダプタ・インスタンスが参照されます。`db.jca`ファイルおよびリンクされている`or-mappings.xml`ファイルのプロパティに基づいて、`<seviceName>.properties`により実行対象として正しいSQLが生成され、入力XMLが解析されて、XSDファイルに一致する出力XMLファイルが作成されます。SQLを実行するために、プールされているSQL接続が基礎となるデータソースから取得されます。

9.2 データベース・アダプタ構成ウィザードの概要

この項では、アダプタ構成ウィザードの概要とアダプタ構成ウィザードを使用してOracleデータベース・アダプタを定義する方法について説明します。

この項では、Oracleデータベース・アダプタの様々な概念を使用例を通じて説明します。これにより、アダプタ構成ウィザードの概要を示します。さらに、この使用例では、アダプタ構成ウィザードを使用して、データベースからの表のインポート、複数の表にわたるリレーションシップの指定、対応するXMLスキーマ定義の生成、および必要なSQLまたはデータベース操作を公開するサービスの作成を行う方法についても説明します。これらのサービスは、BPELプロセスで使用されるパートナ・リンクの定義に使用されます。アダプタ・サービスの作成および編集のどちらにもアダプタ構成ウィザードを使用します。

9.2.1 アプリケーションおよびSOAプロジェクトの作成

SOAコンポジットを含んだOracle JDeveloper (JDeveloper)アプリケーションを作成する必要があります。次の手順に従ってアプリケーションとSOAプロジェクトを作成します。

JDeveloperを開きます。
「アプリケーション・ナビゲータ」で、「新規アプリケーション」をクリックします。
図9-2に示すように、「汎用アプリケーションの作成 - アプリケーションの名前付け」ページが表示されます。
「アプリケーション名」フィールドにアプリケーションの名前を入力します。
「アプリケーション・テンプレート」リストで、「汎用アプリケーション」を選択します。
図9-2 「汎用アプリケーションの作成 - アプリケーションの名前付け」ページ

「図9-2 「汎用アプリケーションの作成 - アプリケーションの名前付け」ページ」の説明
「次へ」をクリックします。
図9-3に示すように、「汎用アプリケーションの作成 - プロジェクトの名前付け」ページが表示されます。
「プロジェクト名」フィールドにわかりやすい名前を入力します。
「プロジェクト・テクノロジ」タブの「選択可能」リストで「SOA」をダブルクリックし、「選択済」リストに移動します。
図9-3 「汎用アプリケーションの作成 - 汎用プロジェクトの名前付け」ページ

「図9-3 「汎用アプリケーションの作成 - 汎用プロジェクトの名前付け」ページ」の説明
「次」を選択します。図9-4に示すように、「汎用アプリケーションの作成 - SOA設定の構成」ページが表示されます。
図9-4 「汎用アプリケーションの作成 - SOA設定の構成」ページ

「図9-4 「汎用アプリケーションの作成 - SOA設定の構成」ページ」の説明
「コンポジット・テンプレート」リストから「BPELを使用するコンポジット」を選択して、「終了」をクリックします。
新規アプリケーションおよびSOAプロジェクトが作成されました。これにより、SOAコンポジットが自動的に作成されます。

図9-5に示すように、「BPELプロセスの作成」ページが表示されます。

図9-5 「BPELプロセスの作成」ページ

「図9-5 「BPELプロセスの作成」ページ」の説明
「名前」フィールドにBPELプロセスの名前を入力します。
「テンプレート」リストで「サービスを後で定義」を選択し、「OK」をクリックします。
BPELプロセスが作成されました。

9.2.2 Oracleデータベース・アダプタの定義

次のステップは、Oracleデータベース・アダプタ・サービスを定義することです。次の手順に従ってOracleデータベース・アダプタ・サービスを作成します。

「コンポーネント・パレット」で「SOA」を選択します。
「サービス・アダプタ」リストから、「データベース・アダプタ」を「composite.xml」ページの公開されたコンポーネント・スイムレーンにドラッグ・アンド・ドロップします。
「アダプタ構成ウィザード」が表示されます。

注意:
Oracleデータベース・アダプタ・サービスをBPELプロセスの一部として作成するには、「サービス・コンポーネント」から「コンポーネント」にBPELプロセスをドラッグ・アンド・ドロップします。それをダブルクリックします。次に、BPELの「コンポーネント・パレット」で、「データベース・アダプタ」を「BPELサービス」から「パートナ・リンク」スイムレーンにドラッグ・アンド・ドロップします。
「次」を選択します。図9-6に示すように、「サービス名」ページが表示されます。次の情報を入力します。
図9-6 サービス名の指定

「図9-6 サービス名の指定」の説明
「サービス名」フィールドにサービス名を入力し、「次へ」をクリックします。「サービス接続」ページが表示されます。

アダプタ構成ウィザードの使用を続行するには、「データベースへの接続」を参照してください。

9.2.3 データベースへの接続

図9-7に、サービスで使用するデータベース接続を選択する場所を示します。これは、サービスを構成する表をインポートするデータベースです。これは、サービスを構成する表をインポートするデータベースです。ここで、作成する新しいJDeveloperアプリケーションごとにデータベースを再作成できます。

データベース接続を識別するJava Naming and Directory Interface (JNDI)の名前を指定できます。デフォルト名はeis/DB/<ConnectionNameInJDev>です。

詳細は、「データベース・アダプタ・デプロイメント」を参照してください。

図9-7 「アダプタ構成ウィザード - サービス接続」ページ

「図9-7 「アダプタ構成ウィザード - サービス接続」ページ」の説明

次の点に注意してください。

本番環境では、アダプタのデプロイメント・ディスクリプタ(weblogic-ra.xml)にJNDIエントリを追加することをお薦めします。この場合、管理モードで作業することでOracleデータベース・アダプタのパフォーマンスが向上します。

データソースとアウトバウンド接続プールの作成の詳細は、「アダプタ・コネクション・ファクトリの追加」を参照してください。
「次へ」をクリックすると、データベースへの接続が試行されます。接続できない場合は、既存のパートナ・リンクを編集している場合でも、次のウィンドウには進めません。

アダプタ構成ウィザードの使用を続行するには、「操作タイプの選択」を参照してください。

9.2.4 操作タイプの選択

図9-8に、このサービスに構成する操作タイプを指定する場所を示します。

図9-8 「アダプタ構成ウィザード - 操作タイプ」ページ

「図9-8 「アダプタ構成ウィザード - 操作タイプ」ページ」の説明

次の操作タイプを使用できます。

ストアド・プロシージャまたはファンクションの呼出し

サービスでストアド・プロシージャまたはファンクションを実行する場合にこのオプションを選択します。詳細は、「ストアド・プロシージャおよびファンクションのサポート」を参照してください。
表に対して操作を実行

このオプションは、アウトバウンド操作に対して選択します。「挿入/更新」、「挿入のみ」、「更新のみ」、「削除」、「選択」またはこの6つのオプションを任意に組み合せて選択できます。これらの操作は、同等のSQL操作であるMERGE、INSERT、UPDATE、DELETEおよびSELECTに変換されます。

詳細は、「DML操作」を参照してください。

注意:
「更新のみ」操作では、子レコードに対する挿入または削除が実行されることがあります。これは、マスターの更新に伴い、ディテールが追加または削除されることがあるためです。したがって、更新対象の入力に含まれるディテール・レコードが1つのみの場合は、表内の他のディテール・レコードが削除されます。
表の新規レコードまたは更新されたレコードをポーリング

この操作は、インバウンド操作(つまり、receiveアクティビティと関連付けられている操作)に対して選択します。この操作タイプでは、指定された表がポーリングされ、追加された任意の新しい行の処理用に返されます。また、ポーリング間隔も指定できます。

詳細は、「ポーリング戦略」を参照してください。

図9-9に示すように、データベースからデータが読み取られた後に実行できるポーリング操作は次のとおりです。
図9-9 ポーリング操作

「図9-9 ポーリング操作」の説明
Pure SQLの実行

任意の複雑な文、集計問合せ(結果は行ベースではありません)およびXMLType列を処理する場合に役立ちます。アダプタ構成ウィザードのこの使用方法は、「Pure SQL - XMLタイプのサポート」を参照してください。

注意:
スキーマ・バインドXML表はサポートされていません。

アダプタ構成ウィザードのこれ以外の使用方法は、「表の選択およびインポート」を参照してください。

9.2.5 表の選択およびインポート

図9-10に、操作のルート・データベース表を選択する場所を示します。複数の関連する表を使用している場合は、これがリレーションシップ・ツリーの最上位の表(または最上位の親表)になります。

図9-10 アダプタ構成ウィザード - 表の選択

「図9-10 アダプタ構成ウィザード - 表の選択」の説明

「表のインポート」を選択すると、サブウィザードが起動します。このウィザードで、データベースからインポートする複数の表を検索および選択できます。表を削除すると、残された関連する表にあるリレーションシップが削除されます(元に戻されます)。このウィザードを編集モードで実行している間に基礎となる表が変更された場合、その変更内容を示す警告が表示されます。調整するには、表を再度インポートします。「表のインポート」をクリックして複数の表を選択すると、外部キーの制約に基づいてそれらの表の間のリレーションシップが推測されます。ただし、インポートした表ごとに「表のインポート」を起動する場合は、リレーションシップは推測されません。

注意:

表を再インポートすると、その表に対して任意で定義したカスタムのリレーションシップとカスタムWHERE句はすべて失われます(インポートする表がルート表の場合)。

アダプタ構成ウィザードの使用を続行するには、「主キーの定義」を参照してください。

9.2.6 主キーの定義

インポートした表にデータベースで定義された主キーがない場合、図9-11に示すように、各表に主キーを指定するよう求められます。インポートしたすべての表に主キーを指定する必要があります。複数のフィールドを選択すると、マルチパートの主キーを指定できます。

図9-11 「アダプタ構成ウィザード - 主キーの定義」ページ

「図9-11 「アダプタ構成ウィザード - 主キーの定義」ページ」の説明

ここで指定する主キーは、オフライン・データベース表に記録され、データベース・スキーマには保存されないため、データベース・スキーマは変更されません。

アダプタ構成ウィザードの使用を続行するには、「リレーションシップの作成」を参照してください。

注意:

Oracleデータベース・アダプタでは、主キーが定義されている表のみがサポートされることに注意してください。表で主キー制約が明示的に定義されていない場合は、設計時にアダプタ構成ウィザードを使用してOracleデータベース・アダプタを定義する際に指定する必要があります。有効な主キーを指定しなければ、一意の制約は保証されず、これにより実行時にメッセージが失われる可能性があります。つまり、重複する主キー値を持つ行が失われる可能性があります。また、主キーが100バイト未満であることを確認する必要があります。

注意:

主キー列にはcharではなくvarcharを使用することをお薦めします。charを使用する場合は、weblogic-ra.xmlプロパティのshouldTrimStringsをfalseに設定する必要があります。後続のスペースが切り捨てられることによって主キーが不適切に読み取られ、読取り行を処理済として更新できなくなることがあります。

9.2.6.1 主キーとしてのROWIDの使用

Oracleデータベース・アダプタのROWIDサポートによって、ROWIDを特定のサポート対象の操作の主キーとして選択できます。

主キー制約がない表をインポートすると、行を一意に識別するために使用できる一連の列を選択するよう求められます(図9-12を参照)。統合シナリオの場合、ターゲット・スキーマに関する知識がより必要となることがあり、エラーが発生する可能性があります。たとえば、ここで一意でない列を選択すると、意図しない複数の行を更新する操作、または一部の行を2回返しその他の行は返さない選択となる可能性があります。

Oracle Databaseでは、エラーが発生しにくいROWID疑似列を主キーとして使用するよう選択できます。ROWIDは直接物理アドレスであるため、通常の索引よりも高速である場合があります。

ROWIDは、Oracle表の疑似列です。疑似列は、ユーザーが直接更新できない列であり、ユーザーが作成した列ではありません。また、疑似列は列のメタデータ・ビューに表示されず、select *問合せから返されます。

ROWIDの使用には、特定の制限があります。このような場合は、ユーザー・インタフェースのオプションがグレー表示され、選択できません。

ROWIDは、行を一意に識別する必要がない操作(挿入、選択)または同じトランザクションですでに読み取られている行のみを識別する必要がある操作(ほとんどのポーリング操作)に対してのみ使用できます。物理アドレスはデータベースの外部で意味を持たず、行の一部ではない(値がトランザクション内で安定している)ため、行自体の列を使用して行を一意に識別する必要がある操作では使用できません(マージ、削除、主キーによる選択)。

表間のリレーションシップでは行に明示的な主キーが必要なため、ROWIDは、単一の表との組合せでのみ使用できます。

ROWIDサポートは、Pure SQLまたはストアド・プロシージャには適用されません。

9.2.6.1.1 「主キー」ページでのROWIDの使用

主キー・セットのない表をインポートすると、ウィザードに「主キー」ページが表示されます。図9-12を参照してください。

図9-12 ROWIDを使用した主キーの定義

「図9-12 ROWIDを使用した主キーの定義」の説明

このページでは、次のいずれかを実行できます。

主キーを構成する列を選択するラジオ・ボタンをクリックして、主キーを作成する列を選択します。
主キーとして、疑似列ROWIDを使用するラジオ・ボタンをクリックして、主キーとしてROWIDを選択します。

この場合も、ROWIDは、インバウンド・ポーリング、挿入または選択操作でのみ使用できます。

主キーを構成する列を選択する場合は、各列の横に、NOT NULL、INDEXED、AUTO INCREMENT、UNIQUE INDEXEDなどの可能なヒントが表示されます。

後者の場合、列のチェック・ボックスがデフォルトで自動的に選択され、確認するよう求められます。

9.2.7 リレーションシップの作成

図9-13に、ルート・データベース表およびその他の関連する表に定義されたリレーションシップを示します。「リレーションシップの作成…」をクリックして2つの表の間にリレーションシップを作成したり、「リレーションシップの削除」をクリックしてリレーションシップを削除できます。リレーションシップの名前を変更するには、「リレーションシップの名前変更」をクリックします。

図9-13 「アダプタ構成ウィザード - リレーションシップ」ページ

「図9-13 「アダプタ構成ウィザード - リレーションシップ」ページ」の説明

リレーションシップの作成に関して次の事項に注意してください。

データベース上に表間の外部キー制約が存在する場合、表をインポートすると、ソース表(外部キー制約を含む表)からターゲット表に1対1 (1:1)、ターゲット表からソース表に1対多(1:M)の2つのリレーションシップが自動的に作成されます。
図9-13に示すように、ルート・データベース表からアクセス可能なリレーションシップのみが表示されます。リレーションシップを1つ削除すると、他のリレーションシップがルート表からアクセスできなくなり、「リレーションシップ」ウィンドウに表示されなくなります。次に示す一連のリレーションシップがあるとします。

A --1:1--> B --1:1--> C --1:M--> D --1:1--> E --1:M--> F

(1) (2) (3) (4) (5)

リレーションシップ3を削除すると、表示されるリレーションシップは次のようになります。

A --1:1--> B

B --1:1--> C

リレーションシップ2を削除すると、表示されるリレーションシップは次のようになります。

A --1:1--> B

リレーションシップ1を削除すると、リレーションシップは表示されなくなります。

図9-14に、リレーションシップを作成する場所を示します。

図9-14 「リレーションシップの作成」ダイアログ

「図9-14 「リレーションシップの作成」ダイアログ」の説明

リレーションシップを作成する手順は次のとおりです。

親表と子表を選択します。
マッピング・タイプ(1対多、1対1または子表に外部キーのある1対1)を選択します。
外部キー・フィールドを主キー・フィールドに関連付けます。
オプションでリレーションシップに名前を付けます(デフォルト名が生成されます)。

注意:

親表として選択できるのは、ルート表からアクセス可能な表のみです。

9.2.7.1 リレーションシップが作成または削除された際の動作

アダプタ構成ウィザードに最初に表がインポートされると、データベースの各フィールドに対応する、TopLinkのフィールドへの直接的なマッピングが作成されます。図9-15および図9-16に示すスキーマがあるとします。

図9-15 EMPLOYEEスキーマ

「図9-15 EMPLOYEEスキーマ」の説明

図9-16 ADDRESSスキーマ

「図9-16 ADDRESSスキーマ」の説明

これら2つの表をインポートするとすぐに、Employeeディスクリプタに次のマッピングが作成されます。

Employee:

id (IDフィールドへのダイレクト・マッピング。たとえば、151)
name (NAMEフィールドへのダイレクト・マッピング。たとえば、Stephen King)
addrId (ADDR_IDフィールドへのダイレクト・マッピング。たとえば、345)

リレーションシップ・マッピングを作成すると、外部キー・フィールドへの直接的なマッピングは削除され、単一のリレーションシップ(1対1、1対多)マッピングと置き換えられます。そのため、EmployeeとhomeAddressと呼ばれるAddressの間に1対1リレーションシップを作成した後には、Employeeディスクリプタは次の例のようになります。

Employee:

id
name
homeAddress (ADDRESS表への1対1マッピング。この属性はAddressオブジェクト全体を表します。)

リレーションシップが削除されると、外部キーへのダイレクト・マッピングがリストアされます。

9.2.7.2 様々なタイプの1対1マッピング

リレーションシップが自動的に作成される場合、1対多リレーションシップは、外部キーを持たない表からのものになります。ただし、このマッピング(技術的には1対多)を1対1として宣言できます。このためには、1対1(外部キーはターゲット上)を選択します。

9.2.7.3 外部キーが主キーである場合

インポートされるすべての表が第3正規形(3NF)であるとはかぎりません。まれに、複数の表が同じ主キーを共有しており、個別の外部キー列が存在しない場合があります。ルート表から関連するすべての表への1対1(外部キーはターゲット上)リレーションシップを作成することをお薦めします。これには、2つの理由があります。1つ目は、ルート上の主キーを外部キーとして(ソース上に1対1で)宣言する場合、マッピングが削除されるため、主キーはルート・レコードには存在せず、子レコードにのみ存在することになるためです。2つ目は、外部キーは単一の表のみを指すことができるためです。ある列を外部キーの一部として宣言すると、外部キーは削除されるため、新しいリレーションシップで再使用できなくなります。ルート表に1対1リレーションシップ(外部キーはソース上)を作成すると、主キー列が表示されなくなります。また、ルート表をその他の表に結合できなくなる可能性があります。

9.2.8 属性フィルタの作成

図9-17に、インポートされた表の定義から作成された属性フィルタを示します。これには定義したリレーションシップも含まれます。

図9-17 「アダプタ構成ウィザード - 属性のフィルタ処理」ページ

「図9-17 「アダプタ構成ウィザード - 属性のフィルタ処理」ページ」の説明

オブジェクト・フィルタにセルフ・リレーションシップ(従業員対従業員の管理者のリレーションシップなど)が含まれる場合、ツリーではループとして表示されます。XSDファイルではループは表示されません。これはディスクリプタ・オブジェクト・モデルであり、XSDファイルではありません。

このページでは、入力(MERGE、INSERT)であるか出力(SELECT)であるかに関係なく、XMLファイルに表示する列を選択します。不要な列や読取り専用(変更不可)の列の選択をここで解除できます。

アダプタ構成ウィザードの使用を続行するには、「WHERE句の定義」を参照してください。

9.2.9 WHERE句の定義

サービスにSELECT問合せ(インバウンド・ポーリング・サービスまたはSELECTを含むアウトバウンド・サービスなど)が含まれる場合、SELECT文のWHERE句をカスタマイズできます。

注意:

Sequencing Table/Update an External Sequencing Tableによるポーリングを使用する場合は、SELECT問合せの表名が順序表のデータの大/小文字区別と一致することを確認してください。

図9-18に、アウトバウンド・サービスのWHERE句を定義する場所を示します。

図9-18 「アダプタ構成ウィザード - 選択条件の定義」ページ

「図9-18 「アダプタ構成ウィザード - 選択条件の定義」ページ」の説明

注意:

WHERE句はSELECT操作(新規または変更されたレコードのポーリング、または表におけるSELECT操作の実行)にのみ適用されます。INSERT、UPDATEおよびDELETE操作には適用されません。

WHERE句の最も基本的な式は、式の右側(RHS)の内容に応じて、次に示す3つのいずれかになります。

EMP.ID = 123
この場合、RHSはリテラル値です。このRHSは、図9-19に示す「リテラル」オプションです。
EMP.ADDR_ID = ADDR.ID
この場合、RHSは別のデータベース・フィールドです。このRHSは、図9-19に示す「問合せキー」オプションです。
EMP.ID = ?
この場合、実行時にRHS値を指定する必要があります。これは、図9-19に示す「パラメータ」オプションです。

WHERE句の作成を開始する前に「追加」をクリックして、WHERE句で必要なパラメータを作成します。WHERE句を作成するには、図9-19に示すように、「編集…」をクリックして「式ビルダー」を起動します。

図9-19 式ビルダー

「図9-19 式ビルダー」の説明

より複雑なWHERE句(サブSELECT文およびFUNCTION文)をモデル化する場合、およびORDER BY句を追加する場合は、SQLプロシージャを編集して「次へ」をクリックします。ただし、この場合、ハードコードされたSQLによって後からメンテナンス・オーバーヘッドが発生し、プラットフォーム非依存性を失う可能性があります。

列の名前を含むshouldOrderRowsおよびsequencingFieldプロパティをmapping.xmlファイルに追加することでも、ORDER BY句を実行することができます。

  if ((this.sequencingField != null) && (shouldOrderRows())) 
     { 
        ReadAllQuery raPollingQuery = (ReadAllQuery)this.pollingQuery; raPollingQuery.addOrdering(raPollingQuery.getExpressionBuilder().getField(this.sequencingField).ascending()); 
     }

FROM句に記述されている列の変更は、列数と各列の列型が変更されなければ可能です。より複雑な変更については、任意のSQLを直接入力できる「Pure SQLの実行」オプションの使用を検討してください。

単一結果セットを戻す方法

複数の関連表の問合せ時にTopLinkで使用される文の合計数に影響する拡張機能を使用するには、「選択条件の定義」ページで「外部結合を使用してマスター表とディテール表の両方の単一結果セットを返す」を選択する必要があります。最も安全な方法はデフォルト(表ごとに1)を使用することで、この機能ではすべての関連表が単一の結果セットに外部結合されることで合計が1になります。

アダプタ構成ウィザードの使用を続行するには、「読取り後戦略の選択」を参照してください。

9.2.10 読取り後戦略の選択

「表に対して操作を実行」を選択した場合は、手順を省略して「詳細オプションの指定」に進んでください。

インバウンド操作の構成時には、1つ以上の行が読み取られた後の処理に関して次のオプションがあります。

図9-20にこれらのオプションを示します。

図9-20 「アダプタ構成ウィザード - 読取り後」ページ

「図9-20 「アダプタ構成ウィザード - 読取り後」ページ」の説明

アダプタ構成ウィザードの使用を続行するには、「ポーリング戦略」を参照してください。

9.2.10.1 読取り済の行の削除

このオプションでは、アダプタ・サービスによる読取りおよび処理後に、行はデータベースから削除されます。

9.2.10.2 表のフィールドの更新(論理削除)

このオプションでは、ルート・データベース表のフィールドを更新して、その行が読取り済であることを示します。図9-21に示すように、構成の完了後に問合せのWHERE句が自動的に更新されます。

図9-21 「アダプタ構成ウィザード - 論理削除」ページ

「図9-21 「アダプタ構成ウィザード - 論理削除」ページ」の説明

この方法を使用すると、データベース表は図9-22のようになります。

図9-22 表のフィールドの更新

「図9-22 表のフィールドの更新」の説明

次の点に注意してください。

行150および153はすでに読み取られて処理されています。
STATUS列にUNPROCESSEDと表示されているため、次のポーリング・イベントで、行152が読み取られて処理されます。Unread Valueが明示的に指定されているため、行151は読み取られません。
行154にはLOCKEDというフラグが付いているため読み取られません。表が他のプロセスに使用されている場合、この予約値を使用できます。

9.2.10.3 順序表の更新

このオプションでは、別の順序表の最終読取り行を追跡します。図9-23に指定する情報を示します。構成が完了すると、問合せのWHERE句が自動的に更新されます。

図9-23 「アダプタ構成ウィザード - 順序表」ページ

「図9-23 「アダプタ構成ウィザード - 順序表」ページ」の説明

これらの設定を使用すると、順序表は図9-24のようになります。

図9-24 順序表の更新

「図9-24 順序表の更新」の説明

行が読み取られるたびに、この表は読み取られたIDで更新されます。次のポーリング・イベントが発生すると、最終読取りID (154)より大きなIDの行が検索されます。

使用される一般的な列は、event_id、transaction_id、scn(システム変更番号)、idまたはlast_updatedです。通常、これらの列には順序番号またはsysdateが移入され、値は(一定量で)増加します。

9.2.10.4 異なるデータベースにある外部順序表の更新

この操作は、順序表: 最終更新戦略を採用するときに選択します。図9-25に、アダプタ構成ウィザードの「外部順序表」ページを示します。このページで、この操作の実行に必要な詳細を指定します。

図9-25 「アダプタ構成ウィザード - 外部順序表」ページ

「図9-25 「アダプタ構成ウィザード - 外部順序表」ページ」の説明

9.2.10.5 順序ファイルの更新

このオプションは、順序ファイルを更新する場合に使用します。図9-26に、アダプタ構成ウィザードの「順序ファイルの更新」ページを示します。このページで、この操作の実行に必要な詳細を指定します。

図9-26 「アダプタ構成ウィザード - 順序ファイルの更新」ページ

「図9-26 「アダプタ構成ウィザード - 順序ファイルの更新」ページ」の説明

9.2.11 ポーリング・オプションの指定

追加のポーリング・オプションがある場合は、このページで指定できます。図9-27に、アダプタ構成ウィザードの「ポーリング・オプション」ページを示します。

図9-27 ポーリング・オプションの指定

「図9-27 ポーリング・オプションの指定」の説明

このページでは、新規の行またはイベントに関してデータベース表をポーリングする方法の詳細を指定します。

「ポーリング頻度」リストから、新規のレコードまたはイベントのポーリング頻度を選択します。

「XML文書ごとのデータベース行数」フィールドで、Oracle BPEL PMまたはメディエータにイベントを送信する際の、XML文書ごとの行数を指定します。これは、データベース・アダプタとコンシューマ(Oracle BPEL PMまたはメディエータ)の間のバッチ設定です。

「トランザクションごとのデータベース行数」フィールドで、「無制限」を選択するか、または1回のトランザクションで処理する表の行数を示す値を入力します。

イベントに関してデータベースをポーリングする場合は、「ソート順」リストを使用して、戻される行を選択した列でソートできます。ベスト・プラクティスは、追加の構成なしではメッセージの順序付けが保証されないため、「<順序付けなし>」を選択することです。

「SQL」フィールドには、SQL構文が正しくない場合にメッセージが赤で表示されます。

ポーリング・オプションの指定の詳細は、「ポーリング・オプション」ページで「ヘルプ」をクリックするか、[F1]を押します。

9.2.12 詳細オプションの指定

詳細オプションを指定できます。図9-28に、アダプタ構成ウィザードの「詳細オプション」ページを示します。このページでは、JDBCおよびDBアダプタの詳細オプションを指定し、再試行を構成し、ネイティブ順序付けを構成できます。

図9-28 詳細オプションの指定

「図9-28 詳細オプションの指定」の説明

「JDBCオプション」セクションでJDBCオプションを指定する必要があります。下位レベルのJDBCオプションはデータベースへのコール時に設定します。このページに表示されるオプションは、選択した操作によって決まります。

「自動再試行」セクションでは、タイムアウト時の自動再試行の値を指定します。接続関連のフォルトが発生した場合は、invokeアクティビティを回数制限付きで自動的に再試行できます。このセクションのフィールドでは、次の値を指定できます。

無限に再試行するには、「試行」フィールドにunlimitedと入力します。
「間隔」は、再試行間の遅延です。
「バックオフ係数: x」を指定すると、再試行間の待ち時間を延長できます。開始間隔に1、バックオフに2を指定して9回再試行すると、1、2、4、8、16、32、64、128および256 (2⁸)秒後に再試行されます。

「相互作用オプション」では、相互作用オプションを次のように指定します。

GetActiveUnitOfWork。同じSOAインスタンスの複数の起動間で同じレコードに対して複数の増分変更を行うときは、GetActiveUnitOfWorkをtrueに設定します。GetActiveUnitOfWorkによって、データベース・アダプタの起動(オプションをtrueに設定することで関与し、同じJTAトランザクション内に存在し、同じeis/DB/インスタンスに対して起動する)ですべての操作に対して同じEclipseLinkセッションが使用されるようになります。EclipseLinkベースの操作(ストアド・プロシージャおよびPure SQLは除く)では、すべての書込みがJTAが完了する前まで遅延されます。

つまり、2つの起動で同じオブジェクトを挿入/マージする場合、書込みは1回になります。EclipseLinkベースの書込みは遅延されるため、すべて選択では、書込みを実行した前の起動と一致しない可能性があります。しかし、主キーによる選択では一致します。書込みはJTAコールバック内で発生するため、その時点で発生する例外や、BPELのグローバル・トランザクションが予期せずに失敗した場合の例外を処理する方法がありません。2つの起動の操作が同じ物理SQL接続を使用したことを保証するためにGetActiveUnitOfWorkが頻繁に使用されるのは、トランザクションの間はEclipseLinkセッションに対する接続が固定されるためです。ただし、ほとんどのアプリケーション・サーバーのデータ・ソースでは同じ保証が提供されます。WebLogicにも同様の「スレッドに固定」プロパティがあり、GridLinkにはXAアフィニティがあります。これにより、XAトランザクションのすべての書込みはRACクラスタ内の同じノードで発生することになります。これを設定すると、異なるSOAインスタンス間のロック競合が解決されなくなります。

関連データ(親と子など)に複数の操作がある場合は、同じSOAインスタンスまたは起動でもそれらが発生するようにします。これもまた、2つの起動がトランザクション境界にある場合に接続再使用を保証するものではありません。BPELにおいて第2のDbAdapter起動がサブプロセス内にある場合は、コール先のコンポジット・レベルでBPELプロパティのbpel.config.transactionがrequiredに設定されていることを確認してください。
「省略の検出」を選択すると、MERGEおよびINSERT操作で入力ペイロード内の空または欠落しているXML要素を無視できます。MERGE操作の場合は、これにより有効だが未指定の値がNULLで上書きされなくなります。INSERT操作の場合は、これらの値がINSERT文から省略され、デフォルト値を有効にすることができます。
「マージの最適化」は、MERGEのパフォーマンス全般の強化であるため(主キーの存在チェックの問合せに使用)、常に選択する必要があります。

「ネイティブ順序付け(Oracleのみ)」では、すべてのINSERT時に順序から主キーが割り当てられるように指定できます。「検索」をクリックして「順序」リストから順序を選択するか、または名前を入力して「作成」をクリックします。

詳細オプションの指定の詳細は、「詳細オプション」ページで「ヘルプ」をクリックするか、[F1]を押します。

9.2.13 Pure SQL操作に必要なSQL文字列の入力

「カスタムSQL」ページで、「Pure SQLの実行」操作を実行するためのSQL文字列を入力できます。図9-29に、アダプタ構成ウィザードの「カスタムSQL」ページを示します。

図9-29 SQL文字列の入力

「図9-29 SQL文字列の入力」の説明

「SQL」フィールドにカスタムSQL文字列を入力します。SQL入力のXSDスキーマが「XSD」フィールドに自動的に作成されます。

「XSD」フィールドには、入力したカスタムSQL文字列のXSDスキーマが表示されます。結果のXSDは直接編集できます。ただし、以降にSQL文字列を変更すると、XSDの変更内容が失われます。

SQL文字列の入力の詳細は、「カスタムSQL」ページで「ヘルプ」をクリックするか、[F1]を押します。

9.3 Oracleデータベース・アダプタの機能

この項では、Oracleデータベース・アダプタの機能について説明します。

次のトピックが含まれています:

9.3.1 トランザクション・サポート

Oracleデータベース・アダプタにより、固有のデータ処理とともにトランザクション・サポートが可能になります。これにより、それぞれの変更の結果が明確に定義されており、結果は成功か失敗のいずれかになるため、潜在的なデータ破損が防止され、他の変更から独立して実行され、完了後は別のトランザクションが発生するまで基礎となるデータが同じ状態で維持されることが保証されます。

トランザクション・サポートには、XAトランザクション・サポートとローカル・トランザクション・サポートの2つのタイプがあります。XAトランザクション・サポートでは、トランザクションをリソース・アダプタの外部にあるトランザクション・マネージャで管理できます。これに対して、ローカル・トランザクション・サポートでは、アプリケーション・サーバーでリソース・アダプタに対してローカルなリソースを管理できます。

2つのOracleデータベース・アダプタによりコミットまたはロールバックが1単位として確実に起動されるようにするには、次を実行する必要があります。

両方のOracleデータベース・アダプタの起動を、グローバル・トランザクションに関与するように構成する必要があります。
両方のOracleデータベース・アダプタの起動が、同じグローバル・トランザクションに関与する必要があります。
いずれかの起動に失敗した場合は、グローバル・トランザクションをロールバックする必要があります。

注意:

XA以外のドライバはSOALocalTxDataSourceパラメータとともに使用する必要があります。XAドライバに切り替えると、製品の機能が破損します。

9.3.1.1 グローバル・トランザクションへの関与のためのOracleデータベース・アダプタの構成

デプロイメント・ディスクリプタ(weblogic-ra.xmlファイル)で、xADataSourceNameパラメータを設定する必要があります。また、Oracle WebLogic Serverコンソールでデータソースを作成して、参照されるDataSourceをトランザクションに関与するように構成する必要があります。

データソースを作成し、リストからXAデータソースを選択する必要があります。

注意:

実際のデータベースXAは、Oracle 10.2.0.4または11.1.0.7でのみ動作確認済です。以前のリリースでは、非XAデータソース実装を選択して次のページで「2フェーズ・コミットのエミュレート」を選択する方が安全です。

Oracle JCAアダプタで使用する非XAおよびXAデータソースの推奨設定については、「Oracle JCAアダプタで使用するデータソースの推奨設定」を参照してください。

Oracle WebLogic Serverではdata-sources.xmlファイルを編集できません。「データソースの作成」の説明に従って、Oracle WebLogic Server管理コンソールを使用してデータソースを作成する必要があります。

9.3.1.2 両方を同じグローバル・トランザクションで起動

両方のOracleデータベース・アダプタの起動が1単位としてコミットまたはロールバックするためにグローバル・トランザクションに関与する場合は、同じグローバル・トランザクションに関与する必要があります。BPELでは、そのためにトランザクション境界の位置、つまりチェックポイントでデハイドレーション・ストアに書き込み、現行のグローバル・トランザクションをコミットし、新規トランザクションを開始する位置を認識する必要があります。

BPELプロセスでのトランザクション境界は、ReceiveアクティビティまたはReceiveアクティビティの前、あるいはonMessageまたはPickアクティビティの前に発生します。次のサンプル・コードに示すように、パートナ・リンク上でbpel.config.transactionプロパティが設定されていないかぎり、これは同期の子BPELプロセスの起動時にも発生することがあります。

<property name="bpel.config.transaction">required</property>

それ以外の場合は、親プロセスが2つのトランザクションに分割され、子プロセスは固有のトランザクションで実行されます。

9.3.1.3 失敗時のロールバックが必須

最後に、両方のOracleデータベース・アダプタの起動が同じグローバル・トランザクションに関与していても、一方の起動に失敗するとグローバル・トランザクションをロールバックできない場合があります。

失敗により実際にグローバル・ロールバックが発生可能なのは、次の場合のみです。

ある書込みには成功しても他の書込みに失敗した後で、1回の起動の一部として複数の表を挿入または更新するOracleデータベース・アダプタ操作に失敗した場合。この場合、起動操作はアトミックでなく、コミットするとデータが破損する可能性があるため、Oracleデータベース・アダプタはグローバル・トランザクションをロールバックのみとしてマーク付けします。
データベース停止のシナリオで、グローバル・トランザクションがタイムアウトしてロールバックされるまで、起動が数回再試行される場合。
BPELプロセス内で明示的なbpelx:rollbackフォルトがスローされる場合。

9.3.1.3.1 両方の起動に対する同一セッションの使用

両方のOracleデータベース・アダプタの起動に同じセッションまたは接続を使用可能にするには、GetActiveUnitOfWork JCAパラメータをtrueに設定する必要があります。

GetActiveUnitOfWorkは、すべてのDBInteractionSpecに設定できる拡張JCAプロパティです。これにより、2フェーズ・コミット・コールバックに自己登録する起動とデータベースへのすべての書込みが、2フェーズ・コミットの一部として実行されます。障害発生時にこのプロパティを設定することで、この段階でフォルトを処理する方法がないため、トランザクションが自動的にロールバックされます。同様に、両方の起動には同じ基礎となるTopLinkセッションが使用されます。これは、同じオブジェクトを2回マージする場合、挿入または更新されるのは1回であることを意味します。GetActiveUnitOfWorkがtrueに設定されているすべてのマージの起動は、累積的です。

9.3.1.4 トランザクション/XAサポート

2つのOracleデータベース・アダプタの起動が1単位としてコミットまたはロールバックされるようにするには、両方のOracleデータベース・アダプタの起動がグローバル・トランザクションに関与するよう構成されていること、両方の起動が同じグローバル・トランザクションに関与していること、およびいずれかの起動に失敗した場合はグローバル・トランザクションがロールバックされるようになっていることが必要です。

9.3.1.4.1 グローバル・トランザクションに関与するようにOracleデータベース・アダプタを構成

デプロイメント・ディスクリプタ(weblogic-ra.xml)で、xADataSourceNameを設定する必要があります。対応するデータソース・エントリは、グローバル・トランザクションに関与するように構成する必要があります。

実際のXA: 2フェーズ(XA)コミットと1フェーズ(エミュレート)コミットの違い

XAは2フェーズ・コミット・プロトコルで、1フェーズ・コミット/エミュレート・プロトコルよりも堅牢です。その違いは、1フェーズ・プロトコルでは、メッセージが消失したりロールバック/コミットの不整合が発生することは非常にまれではありますが、その割合は通常、1000当たり1程度はある点です。

Oracle RACの構成

Oracle RACの構成の詳細は、Oracle Database高可用性概要ガイドのReal Application Clustersを参照してください。

サード・パーティのドライバを使用した実際のXA構成

サード・パーティのドライバ(Microsoft SQL Server 2008やIBM DB2など)に対して実際のXA構成を構成する場合、javax.sql.XADataSourceを実装するクラスがドライバのJarに含まれることを確認します。

データ直接ドライバの場合、ネーミングはcom.oracle.ias.jdbcx.db2.DB2DataSourceまたはcom.oracle.ias.jdbcx.sqlserver.SQLServerDataSourceである可能性があります。

9.3.1.4.2 失敗時のロールバックが必須

最後に、両方の起動が同じグローバル・トランザクションに関与していても、一方の起動に失敗するとグローバル・トランザクションをロールバックできない場合があります。

失敗により実際にグローバル・ロールバックが発生可能なのは、次の場合のみです。

ある書込みには成功しても他の書込みに失敗した後で、1回の起動の一部として複数の表を挿入または更新するOracleデータベース・アダプタ操作に失敗した場合。この場合、起動操作はアトミックでなく、コミットするとデータが破損する可能性があるため、アダプタはグローバル・トランザクションをロールバックのみとしてマーク付けします。
データベース停止のシナリオで、グローバル・トランザクションがタイムアウトしてロールバックされるまで、起動が数回再試行される場合。
BPELプロセス内で明示的なbpelx:rollbackフォルトがスローされる場合。WSDL内のGetActiveUnitOfWork="true"。

9.3.2 Pure SQL - XMLタイプのサポート

Pure SQLアダプタは、SQL文字列を直接入力してXSD/Webサービスを自動的に生成できるようにする、Oracleデータベース・アダプタ・ウィザードのオプションです。データベース表はアダプタ構成ウィザードで動的にイントロスペクトされ、SQLがテストされてXSDファイルに適切に(有効な戻り型が)移入されます。

Pure SQLのサポートにより、Oracleデータベース・アダプタは表やビューをエンティティとして処理し、SQLで直接処理できます。Pure SQLを次の目的で使用できます。

単純なデータ予測スタイルのレポート問合せ
select count(*)のように結果セットが表指向でない場合
update allまたはdelete allを実行する場合
XMLType列とxqueryで作業する場合
アダプタ構成ウィザードの式ビルダーでモデル化されていない複雑なSQLを使用する場合

Pure SQLアダプタはOracle XMLTypeで使用できます。XMLをXMLType表および列に挿入し、xquery selectを使用してXMLを取得する操作に適しています。Pure SQLは、XML DB (XDB)サポートと並行するリレーショナル-xmlマッピングを提供するOracleデータベース・アダプタに適しています。そのため、XDBを使用する場合、XDBとXQueryに専念できるように、アダプタをできるかぎり軽量かつ透過的にする必要があります。

データがXML(非構造化/半構造化)形式で、データをマップできるリレーショナル・スキーマが存在しない場合は、XDBを使用できます。従来のOracleデータベース・アダプタでは、既存のリレーショナル・スキーマをWebサービスで使用するXMLスキーマとしてインポートできます。XDBのXML断片化アルゴリズムでは、永続的記憶域について既存のXMLスキーマからリレーショナル・スキーマを生成できます。

注意:

スキーマ・バインドXMLTypeを使用するにはociドライバが必要ですが、このドライバの動作はリリース11gでは確認されていません。そのため、実行時には非スキーマ・バインドXMLTypeを使用する必要がありますが、設計時にはスキーマ・バインドXMLTypeを使用して代表的なXSDをインポートできます。

詳細は、次を参照してください。

操作タイプの選択

9.3.3 強い型指定のXSDまたは弱い型指定のXSDを使用した行セットのサポート

REF CURSORはどのような結果セットもサポートできるため、設計時に生成されるXSDでもこれが許可され、次の例に示すようなXSDになります。

注意:

Oracle Databaseのストアド・プロシージャによって返される結果セットは、RefCursorsとして参照されるのに対し、サード・パーティ・データベースの場合、返される結果セットはRowSetsとして参照されます。

例 - 弱い型指定のXSD

<refCursorOutputParam>
    <Row>
        <Column name="DEPTNO" sqltype="NUMBER">20</Column>
        ...
    </Row>
</refCursorOutputParam>

ただし、ここからのXML出力を使用するのは困難です。弱い型指定のXSDに基づき、要素名ではなく列名を属性値としてXpath式またはXSLを作成することは非常に困難です。

行セットはすべての結果セットを表現できますが、一部のプロシージャについては、結果セットの構造が毎回同じであることが想定できるため、強い型指定のXSDを使用して記述することも可能です。一般的に、後で結果セットを別のXSDに変換する場合は、強い型指定のXSDが必要となります。強い型指定のXSDは、次の例に示すようなXSDになります。

例 - 強い型指定のXSD

<refCursorOutputParam>
    <dept>
        <deptno>20</deptno>
        ...
    </dept>
</refCursorOutputParam>

アダプタ構成ウィザードを使用して、ストアド・プロシージャまたはファンクションのREF CURSOR変数によって返される行セットのための、強い型指定のXSDを作成できます。Oracle Databaseのファンクションは、常に1つの出力があり、かつ、select文内などにインラインで組み込むことができる特別なストアド・プロシージャです。このため、通常は更新を行いません。

この機能を使用すると、ストアド・プロシージャ(またはストアド・ファンクション)を選択してその引数を入力し、テスト実行を行って実際の行セットを取得できます。その後、返された行セットがアダプタ構成ウィザードでイントロスペクションされ、強い型指定のXSDが生成されます。引数はウィザードから簡単に入力できます。たとえば、数値や文字列を直接入力でき、日付をリテラルとして(2009/11/11)入力できます。また、MYOBJ('a', 'b')のような構造体を入力することもできます。

注意:

IBM DB2 UDBでは、ファンクションはサポートされていません。サポートされるのはSQLストアド・プロシージャのみです。

アダプタ構成ウィザードでの強い型指定のXSDの使用に関する行セットのサポートには、次の制限があります。

Oracle Database PL/SQLのrecord型およびboolean型はサポートされていません。
Oracle Database PL/SQLのvarrayはサポートされていません。
Oracle Database PL/SQLの%rowtypeはサポートされていません。
Oracle Database PL/SQLのtable型はサポートされていません。
Oracle Database PL/SQLプロシージャでは、INのみのREF CURSORパラメータはサポートされていません。

REF CURSORをIN/OUTパラメータとして使用するOracle Database PL/SQLプロシージャの場合、アダプタ構成ウィザードではINが無視され、OUTパラメータに基づいて強い型指定のXSDが生成されます。
refを使用したXSDの要素の参照はサポートされていません。
SQL Server 2008のテーブル値関数およびCLR関数はサポートされていません。

Oracleデータベース・アダプタでは、次のサード・パーティ・データベースに対して強い型指定のXSDがサポートされています。

Microsoft SQL Server 2005
Microsoft SQL Server 2008
IBM DB2 UDB 9.7

Oracleデータベース・アダプタでは、次のサード・パーティ・データベースに対して強い型指定のXSDはサポートされていません。

IBM DB2 AS/400
MySQL
Informix Dynamic Server
Sybase 15.0.2

詳細は、次を参照してください。

9.3.4 プロキシ認証のサポート

このリリースでは、プロキシ認証を使用してOracleデータ・ストアに接続できます。起動ごとに、次の新しいヘッダー・プロパティの組合せを設定できます。

jca.db.ProxyUserName: OracleConnection.PROXYTYPE_USER_PASSWORDプロキシ・タイプを使用するには、このプロパティをjava.lang.Stringとしてプロキシ・ユーザー名に設定します。
jca.db.ProxyPassword: OracleConnection.PROXYTYPE_USER_PASSWORDプロキシ・タイプを使用するには、このプロパティをjava.lang.Stringとしてプロキシ・ユーザー・パスワードに設定します。
jca.db.ProxyCertificate: OracleConnection.PROXYTYPE_CERTIFICATEプロキシ・タイプを使用するには、このプロパティをbase64Binaryでエンコードされた、有効な証明書を含むbyte[]配列に設定します。

これは、プロキシされるユーザーの資格証明をデータベースに渡す、より暗号化された方法です。証明書には、エンコードされた識別名が含まれます。証明書を生成する1つの方法として、ウォレットを作成した後、そのウォレットをデコードして証明書を取得する方法があります。ウォレットはrunutl mkwalletを使用して作成できます。その後、生成した証明書を使用して認証を受ける必要があります。
jca.db.ProxyDistinguishedName: OracleConnection.PROXYTYPE_DISTINGUISHED_NAMEプロキシ・タイプを使用するには、このプロパティをjava.lang.Stringとしてプロキシ識別名に設定します。

この識別名は、プロキシされるユーザーのパスワードにかわるグローバル名です。
jca.db.ProxyRoles: 使用するプロキシ・タイプに関係なく、このプロパティを必要に応じて設定し、プロキシ・ユーザーに関連付けられるロールをString[]配列として定義できます。この配列内の各java.lang.Stringがロール名に対応します。
jca.db.ProxyIsThickDriver: OCIドライバを使用している場合、JDBCレベルのAPIにおけるthickドライバとthinドライバの差異に対応するには、このプロパティを値trueに設定します。

起動を実行するには、プロキシ接続をデータソースから取得する必要があります。

詳細は、Oracle Database JDBC開発者ガイドのプロキシ認証を参照してください。

9.3.5 大きなペイロードのストリーミング

ペイロードのストリーミングのサポートを有効化するには、図9-27に示すように、ポーリング・オプションを指定する際に「ストリーミングの有効化」チェック・ボックスを選択する必要があります。この機能を有効化すると、ペイロードはメモリーDOM内のSOAランタイムで操作されるかわりにデータベースにストリーミングされます。この機能は、大きなペイロードの処理中に使用します。「ストリーミングの有効化」チェック・ボックスを選択すると、対応するブール・プロパティStreamPayloadがそれぞれの.jcaファイルに定義されているActivationSpecプロパティに追加されます。

9.3.6 スキーマ検証

SchemaValidation [false/true]プロパティは、新しく追加されたアクティブ化仕様プロパティで、.jcaファイルで構成できます。trueに設定すると、ポーリングOracleデータベース・アダプタ(receiveアクティビティ用)により生成されたXMLファイルはすべて、XSDファイルと対照して検証されます。失敗時には、XMLレコードは拒否されますが、引き続きOracleデータベース・アダプタにより処理済としてマーク付けされます。

データベースには構造化された記憶域が用意されており、XSDファイルはOracleデータベース・アダプタ・ウィザード自体により生成されます。ただし、自動生成XSDを編集して独自の制限を追加する場合、検証を開始する必要があります。たとえば、VARCHAR(50)フィールドをインポートする場合、自動生成XSDには最大長が50という制限があります。ただし、なんらかの理由でBPELプロセスで固定長22の値の処理のみが可能な場合は、XMLファイルを検証する必要があります。

9.3.7 高可用性

Oracle Databaseアダプタは、アクティブ/アクティブ設定での高可用性をサポートします。アクティブ/アクティブ設定では、インバウンド・データベース・アダプタに対して分散ポーリング技術を使用して、同一データが重複して取得されないようにできます。詳細は、「分散ポーリングのベスト・プラクティス1: SELECT FOR UPDATE(SKIP LOCKED)」を参照してください。他のアダプタと同様、Oracle Databaseアダプタをアクティブ/パッシブ設定内でのシングルトン動作に対して構成することもできます。これにより、アクティブ/パッシブ設定で動作するパフォーマンスの高いマルチスレッドのインバウンドOracleデータベース・アダプタ・インスタンスは、展開パターンに従ってクラスタ全体で複数のコンポジット・インスタンスを起動できます。Oracle Databaseアダプタは、データベース障害時や再起動時にも、高可用性機能をサポートします。DBアダプタは、メッセージを損失することなく、再度メッセージを取得します。

9.3.8 スケーラビリティ

次の各項では、複数のOracle BPEL PMまたはメディエータ・ノードに複数のOracleデータベース・アダプタ・プロセス・インスタンスをデプロイするためのベスト・プラクティスについて説明します。

9.3.8.1 分散ポーリングのベスト・プラクティス1: SELECT FOR UPDATE (SKIP LOCKED)

複数のOracle BPEL PMまたはメディエータ・ノードに複数のOracleデータベース・アダプタ・プロセス・インスタンスをデプロイするための1つ目のベスト・プラクティスは、アダプタ構成ウィザードを使用して、アダプタ構成ウィザードの「分散ポーリング」チェック・ボックスを設定し、さらにMaxTransactionSizeを設定することです。

adapter _db.JCAプロパティNumberOfThreadsを設定することによって、アダプタ同時実行性が向上します。

この場合、Oracle Databaseでは、自動的に構文SELECT FOR UPDATE SKIP LOCKEDが使用されます。Microsoft SQLServerデータベースでは、構文はWITH (UPDLOCK,READPAST)になります。

SELECT FOR UPDATE SKIP LOCKEDでは、同時スレッドにより、使用可能な行の選択およびロックがそれぞれ試行されますが、ロックはフェッチ時にのみ取得されます。フェッチしようとしている行がロックされている場合、かわりに次のロックされていない行がロックおよびフェッチされます。複数のスレッドがすべて同じポーリング問合せを同時に実行する場合、各スレッドは、処理されていない行の非結合サブセットを比較的迅速に取得する必要があります。

9.3.8.1.1 SKIP LOCKEDの詳細

ロックのスキップに固有な点は、各スレッドが、その他のスレッドがすでに取得しているロックをスキップし、各スレッドが独自にロック済行のセットを取得できることです。その他のロック方法では、Selectが最初のロックを検出して待機するか、または即時に失敗します。これにより、データベース・アダプタでスケーリングできます。

これがSKIP LOCKED機能の概要ですが、SKIP LOCK機能を次のプロパティ、相互作用および依存関係の設定に関して詳細に検討することも重要です。

NumberOfThreads: 同時スレッド数。
PollingInterval: Oracleデータベース・アダプタがOracle Databaseに対するポーリング文を実行する間隔(秒単位)。
MaxTransactionSize: 1つのトランザクションでDBからデータベース・アダプタにフェッチされる行の数。
MaxRaiseSize: データベース・アダプタからBPELに1つのメッセージとして送信される行の最大数。
RowsPerPollingInterval: 1ポーリング間隔で処理できるレコード数に対する制限。

データベース・アダプタの.jcaファイルがデプロイされると、NumberOfThreadsプロパティに基づいてポーリング・スレッドが作成されます。このようなスレッドは、相互に独立してポーリングされ、トランザクションを開始して、SELECT FOR UPDATE SKIP LOCKを開始します。

次に、すべての使用可能な行のデータベース・カーソルが返され、SELECTに一致するレコードがない場合、スレッドはトランザクションをリリースし、PollingIntervalプロパティに指定されている期間スリープします。

SELECTポーリング文に一致するレコードがデータベースに表示されると、各スレッドはスリープ後にウェイクアップし、トランザクションを開始して、SELECT FOR UPDATE SKIP LOCKを発行します。

この時点で、データベース・カーソルは返されていますが、今回は、SELECT基準に一致する行があります。各スレッドによって、MaxTransactionSizeプロパティで定義されている行数に対するFETCHが発行されます。

データベース(SKIP LOCKED)の行をロックし、他のFETCHがこれらの行を取得しないようにするのは、このFETCHです。これにより、各ポーリング・スレッドがSELECT、FETCHにのみ焦点を当てて、処理の重複を考慮せずに処理できます。

これにより、各スレッドに処理対象の独自の行セットが含まれるため、スレッドはフェッチした行に対するループ処理を実行し、MaxRaiseSizeプロパティに基づいてグループ化します。

各グループは構成された宛先に配信され、すべての行が正常に配信されると、トランザクションがコミットされます。

次に、各スレッドでは、配信された行数とRowsPerPollingIntervalプロパティで指定されている値が比較されます。配信された行数がRowsPerPollingIntervalプロパティの値以上である場合、スレッドはスリープします。配信された行数がRowsPerPollingInterval未満の場合、スレッドはプロセス全体を繰り返します。

ロッキングのスキップに関するPollingIntervalとMaxTransactionSizeの計算は、「PollingInterval、MaxTransactionSizeおよびActivationInstancesの詳細な構成」を参照してください

9.3.8.1.2 Oracle以外のデータベース

Oracle以外のデータベースでは、SELECT FOR UPDATEによって、同じ行が複数回処理できないことが安全に保証されますが、スケーラビリティが低下する場合があります。パーティション・フィールドを追加して使用するか、または2つ目のベスト・プラクティス、つまり、基本的には単一ノード上でマルチスレッド処理と展開を使用するかを検討する必要があります(「分散ポーリングのベスト・プラクティス2: 最初に単一ノードでチューニングする」を参照)。

注意:

分散アプローチによって、複数のアクティブ化インスタンスで同じ行が処理されないようにします。

このベスト・プラクティスを構成する場合は、次の各項も参照してください。

9.3.8.1.3 PollingInterval、MaxTransactionSizeおよびActivationInstancesの詳細な構成

分散シナリオの場合、各ポーリング・インスタンスでは、処理されていないすべての行をそのインスタンス単独で処理しようと試みるのではなく、負荷の分散が試行されます。このため、1つのインスタンスで一度にフェッチされる行数が、最大でもMaxTransactionSizeの行数のみとなります。

ロッキングのスキップを使用すると、完全なMaxTransactionSize行がフェッチされた場合、次のMaxTransactionSize行をただちに連続してフェッチできます。

これは、ロッキングのスキップを使用する場合、同時スレッドは相互にブロックされないので、1つのインスタンスがすべての行をフェッチする危険がないためです。

ただし、ロッキングのスキップを無効にしている場合は、すべてのスレッドが同じ行をロックしようとし、そのうちの1つだけがロックに成功します。その後、そのスレッドがMaxTransactionSizeの行数を処理し終えると、そのスレッドは次のポーリング間隔まで一時停止し、他のスレッドが行のロックと処理を行えるようになります。

したがって、分散ポーリングを有効にし、ロッキングのスキップを無効にしている場合の最大スループットは次のようになります。

NumberOfThreads x MaxTransactionSize/PollingInterval

注意:

MaxTransactionSizeを増やすことが必要となる場合がありますが、この値が大きすぎると、トランザクション・タイムアウトが発生するようになることがあります。表9-2に、MaxTransactionSizeの安全な値を示します。

ロード・バランシングが目的である場合は、ロッキングのスキップを無効化した状態で分散環境のMaxTransactionSize設定を小さくしすぎると、MaxTransactionSizeによって速度が制限されるため、適切ではありません。MaxTransactionSizeは、ビジネス・プロセス全体の各CPUスループットに近い値に設定するのが最適です。このようにすると、ロード・バランシングは必要なときにのみ発生します。

表9-2 MaxTransactionSize値とMaxRaiseSize値

MaxTransactionSize MaxRaiseSize 説明

順次ルーティングを使用する場合。

10行の場合、個別のインスタンスが10個使用され、10個のXMLレコードがSOAを通過します。

100

パラレル・ルーティングを使用する場合。

>= 100

MaxTransactionSize

アダプタを使用してできるかぎり迅速に行をストリーミングする場合。

ロード・バランシングが目的である場合は、1つの分散環境でMaxTransactionSizeの設定が小さすぎると、その分散環境によって速度が制限されるため、適切ではありません。MaxTransactionSizeは、ビジネス・プロセス全体の各CPUスループットに近い値に設定するのが最適です。このようにすると、ロード・バランシングは必要なときにのみ発生します。

分散ポーリングが設定されていない場合、アダプタでは、処理されていないすべての行を単一のポーリング間隔で処理しようとします。

9.3.8.1.4 パーティション・フィールド

分散シナリオでは、複数のサーバー上にポーリング・インスタンスが存在しますが、サーバーごとに複数のスレッドを構成することもできます。これらのアクティブ化インスタンスを構成すると、個別に行を処理することによって、ある程度の連携が可能となり、スケーリングが向上する場合があります。

そのためには、単に次のプロパティPartitionFieldをdb.jcaファイルに追加します。

<property name="PartitionField" value="ID"/>

activationInstancesを2に設定すると、アクティブ化インスタンス1および2(または0および1)はそれぞれ次のように実行されます。

SELECT ... WHERE ... AND MOD (ID, 2) = 0 FOR UPDATE SKIP LOCKED

および

SELECT ... WHERE ... AND MOD (ID, 2) = 1 FOR UPDATE SKIP LOCKED

アクティブ化インスタンス0は、依然として、他のサーバーでこのIDを持つその他のアクティブ化インスタンスと競合しますが、少なくともID 1を持つその他のアクティブ化インスタンスとは競合しません。

パーティション・フィールドが数値であり、modを適用することによって、行が均等に分散されることを確認します(つまり、この場合は、すべてのIDが偶数または奇数でないことを確認します)。

Oracle Databaseでは、db.jcaファイル・プロパティPartitionFieldを次のように設定することによって、パーティション・フィールドがrowidとなるように設定できます。

 <property name="PartitionField" value="rowid"/>

これにより、SQLが実際に次のように変換されます。

SELECT ... WHERE ... AND MOD (dbms_rowid.rowid_row_number(rowid), 2) = [0/1] FOR UPDATE SKIP LOCKED

スケーラビリティはOracle Databaseのロッキングのスキップによってもたらされるため、パーティション・フィールドを設定することはお薦めしません。これは、より複雑なSQLを使用してデータベースのCPU使用率が増加することによって、コストがかかるためです。

9.3.8.1.5 activationInstances

アダプタ・フレームワーク・レベル・プロパティactivationInstances (composite.xml内で構成)は、分散シナリオ用のNumberOfThreadsと置換え可能です。

activationInstancesを5に、NumberOfThreadsを5に設定することは、一方を25に、もう一方を1に設定するのと同じです。追加の作業インスタンスはデータベース・アダプタの外部に作成されるため、これらはいかなる方法でも連携しません。したがって、マルチスレッドの単一ノード・シナリオでは、常にNumberOfThreadsのみを構成してください。分散ポーリングを有効化することによるデータベース・レベルの同時実行性制御がない場合は、重複が読み取られます。

注意:

分散クラスタ・シナリオでは、NumberOfThreadsとactivationInstancesのどちらを構成しても効果は同じです。非分散シナリオでは、NumberOfThreadsを使用する必要があります。したがって、常にNumberOfThreadsを使用し、activationInstancesは使用しないようにするのが無難と言えます。

詳細は、「アダプタ内でのシングルトン(アクティブ/パッシブ)インバウンド・エンドポイント・ライフサイクルのサポート」を参照してください。

9.3.8.1.6 索引付けおよびNULL値

主キー、および結合表へのすべての外部キーに索引付け(および/またはこれらのキーに対してデータベース上に明示的な制約を追加)します。論理削除ポーリングを使用する場合は、状態列に索引付けします。NULL以外のMarkUnreadValueおよびMarkReadValueを構成します。

アウトバウンド・データベース・アダプタ上の最適なパフォーマンスのすべての操作(INSERTを除く)において、データベース・アダプタの主キーとして選択されている列のデータベースに索引を作成する必要があります。

索引がなく、かつ索引を作成しないことが適切である場合は、単一ノードのマルチスレッドのアプローチを使用できます(「分散ポーリングのベスト・プラクティス2: 最初に単一ノードをチューニングする」を参照)。この方法では、ポーリング問合せの1度の実行で全表スキャンが行われることがありますが、その場合、複数のスレッドで、すべての行を処理するまで結果セット全体が使用されます。分散アプローチを使用する場合は、行が排他的にロックされている(つまり、時間が指定されたトランザクションでロックされている)間にすべての作業が完了する必要があります。分散シナリオでは、選択が何度も繰り返して実行されるため、選択ごとに全表スキャンが実行されると、パフォーマンスに悪影響を及ぼす場合があります。

注意:

MarkUnreadValueがNULLとして構成されている場合は、パフォーマンスが著しく低下します。

9.3.8.1.7 ロッキングのスキップの無効化

Oracle Databaseでは、Oracle 8以降にロッキングのスキップを使用できるようになりましたが、ドキュメント化はOracle 11で行われました。互換性のない機能を無効化することが必要となる状況はほとんど発生しません。このような状況が発生した場合は、次の例に示すように、アプリケーションでデプロイしたra.xmlファイルでOracleデータベース・アダプタのコネクタ・プロパティusesSkipLockingをfalseに設定できます。

例 - ra.xmlでのusersSkipLockingの構成

<?xml version="1.0" encoding="UTF-8"?>
<connector xmlns="http://java.sun.com/xml/ns/j2ee"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee
  http://java.sun.com/xml/ns/j2ee/connector_1_5.xsd" version="1.5">
...
  <resourceadapter>
        <outbound-resourceadapter>
            <connection-definition>
...
            <config-property>
              <config-property-name>usesSkipLocking</config-property-name>
              <config-property-type>java.lang.Boolean</config-property-type>
                    <config-property-value>false</config-property-value>
            </config-property>
...
            </connection-definition>
...
        </outbound-resourceadapter>
  </resourceadapter>
</connector>

コネクタレベルのプロパティを構成する方法の詳細は、次の各項を参照してください。

Oracle WebLogic Serverリソース・アダプタの開発のra.xmlファイルの構成
.
Oracle WebLogic Serverリソース・アダプタの開発のリソース・アダプタのパッケージ化およびデプロイ

注意:

データベース・アダプタ構成ウィザードおよびデータベース・アダプタ・ランタイムにより、次の条件のいずれかの下で、AND ROWNUM <= ?句がSQL文に追加されます。

usesSkipLockingが"false"に設定されている
MarkReservedValueが使用されている
ReturnSingleResultSetが"true"に設定されている

追加されたAND ROWNUM <= ?により、SQL問合せから戻される行数が制限されます。ただし、AND ROWNUM <= ?句により、戻される行は、行が挿入された順番になっていない場合があります。AND ROWNUM <= ?句が問合せに追加されるのを防ぐために、アダプタdb.jcaファイルにプロパティを追加することができます。

<property name="UseRowNumClause" value="false"/>

AND ROWNUM <= ?句がない場合、戻される行は、行が挿入された順番になります。

9.3.8.1.8 MarkReservedValueとロッキングのスキップ

論理削除ポーリングを使用していて、MarkReservedValueを設定している場合は、ロックのスキップは使用されません。

以前は、複数のOracle BPEL Process ManagerまたはOracle Mediatorノードに複数のOracleデータベース・アダプタ・プロセス・インスタンスをデプロイするための基本的なベスト・プラクティスは、ポーリング・ノードごとに一意のMarkReservedValueを指定してLogicalDeletePollingStrategyまたはDeletePollingStrategyを使用し、MaxTransactionSizeを設定することでした。

ただし、ロッキングのスキップが導入されたことによって、このアプローチは現在使用されなくなりました。以前にこのアプローチを使用していた場合は、MarkReservedValueを(db.jcaで)削除するか、または(ウィザードの「論理削除」ページで)消去するだけで、ロックが自動的にスキップされるようになります。

予約された値に対してロックのスキップを使用することには、次のような利点があります。

ロックをスキップすると、クラスタにおいて、また負荷がかかっている状態で、スケーリングが向上します。
更新/予約した後、コミットし、新しいトランザクションで選択、という手順とは対照的に、すべての作業が1つのトランザクションに含まれます。このため、HA環境においてリカバリ不能の状況が発生するリスクが最小化されます。
一意のMarkReservedValueを指定する必要がありません。この指定を有効にするには、R${weblogic.Name-2}-${IP-2}-${instance}などの複雑な変数を構成する必要があります。

9.3.8.1.9 SequencingPollingStrategy (最終読取りまたは最終更新)

この分散アプローチは、削除または論理削除に基づくポーリング戦略で機能します。

順序付けポーリングに基づく戦略の作業は、最初にレコードが順番に処理されるため、分散できません。

たとえば、2つ目の行が1つ目の行よりも先に処理済としてマークされることはありません(最終読取りIDを2に設定することは、2だけでなく、1も処理済であることを意味します)。

ただし、順序付けポーリング戦略は、ソース表に対して更新後または削除後の処理を行う必要がなく簡潔であるため、非常に高速です。

順序付けポーリング戦略は、単一ノードでクラスタ上の展開とともに使用します。クラスタでの使用は引き続き安全ですが、ヘルパー表の最終読取りIDにアクセスするときには、かわりにSELECT FOR UPDATEが適用されます。

9.3.8.2 分散ポーリングのベスト・プラクティス2: 最初に単一ノードをチューニングする

複数のOracle BPEL PMまたはメディエータ・ノードに複数のOracleデータベース・アダプタ・プロセス・インスタンスをデプロイするための次のベスト・プラクティスは、最初に単一ノードをチューニングする方法です。

Oracleデータベース・アダプタに高い負荷がかかるプロセス(データベース同士の統合など)では、単一Java仮想マシン(JVM)をチューニングして|NumberOfThreads|を大きくし、MaxTransactionSizeおよびMaxRaiseSizeに高い値を設定するのみで、パフォーマンスを10から100倍に向上できます。

「分散ポーリングのベスト・プラクティス1: SELECT FOR UPDATE (SKIP LOCKED)」で説明するように、単一ノードでのパフォーマンスを向上させ、必要に応じてクラスタ内の複数のノードに展開することが最適である場合があります。データベースの同時実行性制御機能(ロックなど)への依存性が高くなる可能性がありますが、これらの機能は、通常、パフォーマンスの高いスケーラビリティよりもデータ整合性を保持することを重視して設計されています。

クラスタ内の単一ノード上でポーリングを行うことが最適となるケースとして、煩雑でない順序付けポーリング戦略、索引付けされていない大規模な表のポーリング、または同時実行性が高いロック(ロックのスキップなど)が備えられていないOracle以外のバックエンド・データベースを使用するケースなどがあります。

注意:

クラスタ環境でポーリング操作を使用するOracleデータベース・アダプタの場合は、アダプタ構成ウィザードで「分散ポーリング」チェック・ボックスを選択して、分散ポーリングのオプションを使用する必要があります。

必要であれば、「アダプタ内でのシングルトン(アクティブ/パッシブ)インバウンド・エンドポイント・ライフサイクルのサポート」も参照してください。

9.3.9 パフォーマンス・チューニング

Oracleデータベース・アダプタは、多くのパフォーマンス最適化で事前構成されています。ただし、パフォーマンス・チューニングを実装することで、変更を加えてデータベースへのラウンドトリップの回数を減らせます。

パフォーマンス・チューニングの詳細は、データベース・アダプタのパフォーマンスおよびチューニングを参照してください。

9.3.10 `detectOmissions`機能

detectOmission機能の特長は、次のとおりです。

使用可能なリリース

リリース10.1.3以上

構成可能

はい

デフォルト値

設計時: true(明示的にfalseに設定しない場合)

使用例

ユーザーは、マージ、更新または挿入対象とする不完全または部分的なXMLを渡して、XMLで未指定の各列がデータベースでNULLに設定されていることを確認できます。

この機能により、DBAdapterのmerge、insertまたはupdateでは、XML文書内のnull値と欠落値(省略)を区別できます。XML内のどの情報が有効で、どの情報が無効であるかは、事例ごとに判別されます。このようにして、XMLは完全な表現ではなくデータベース行の部分表現とみなされます。次の表に、NULL値と省略可能な値の例を示します。

表9-3 NULL値の例

要素タイプ省略 NULL

要素タイプ	省略	NULL
列	`<director></director>` `<director />` `<!-- director>…</director -->`	`<director xsi:nil="true" />`
1-1	<!-- dept> … </dept -->	`<dept xsi:nil="true" />`
1-M	`<!-- empCollection>…` `</empCollection -->`	`</empCollection>` `</empCollection>`(空)

列

<director></director>

<director />

<director xsi:nil="true" />

1-1

<dept xsi:nil="true" />

1-M

<!-- empCollection>…

</empCollection -->

</empCollection>

</empCollection>(空)

注意:

1-1の表現<dept />は空の部門オブジェクトであり、使用しないことを示します。1-Mの場合、<empCollection />は実際には0要素のコレクションを意味し、有効な値とみなされます。列の場合、空の文字列を表す<director></director>は省略とはみなされません。

省略と見なされた値は、UPDATEまたはINSERT SQLから省略されます。更新操作の場合、データベース上の既存の(有効な)値は上書きされません。挿入操作の場合、SQL文字列では明示的な値が提供されないため、データベース上のデフォルト値が使用されます。

DBAdapter receiveでは、省略を含むXMLを生成できず、xsi:nil="true"が使用されます。xsi:nil="true"に設定して入力XMLを生成できない場合、または<director />と<director></director>の違いが問題になる場合は、JCAファイルでDetectOmissions="false"に設定するのが最善の方法です。

更新を予期している場合は、1-1および1-M関係を省略することでパフォーマンスを改善できます。merge操作ではディテール・レコードの考慮を完全にスキップできます。

または、必要な列のみをマップし、起動ごとに個別のマッピングを作成できます。2つのupdateで2つの異なる列セットを更新する場合は、2つの個別partnernlinksを作成します。

パフォーマンス

デフォルトでは、省略を含むXMLはOracleデータベース・アダプタへの入力として使用されません。省略を含むXMLが検出されるまで、パフォーマンス上のオーバーヘッドは存在しません。

省略が検出されると、TopLink descriptor event listenerが追加されます。このevent listenerはなんらかのオーバーヘッドを伴い、SQLUpdateまたはSQLInsertになろうとする各modifyRowは省略をチェックするために繰り返される必要があります。したがって、データベースに送信される各列値がチェックされます。入力XMLの大部分が省略の場合、コストのオーバーヘッドはデータベースに送信する値を減らすことで補正する場合よりも大きくなります。

互換性のない相互作用

DirectSQL="true"およびDetectOmissions="true" - DetectOmissionsが優先されます。互換性のない相互作用の例を次に示します。

DetectOmissionsMerge
IgnoreNullsMerge
OptimizeMerge

注意:

古いBPELプロジェクトを移行した場合は、JCAファイルを再生成するためにデータベース・アダプタ・ウィザードを再実行する必要があります。データベース・アダプタ・ウィザードを再実行すると、JCAファイルにDetectOmissionsおよびOptimizeMergeオプションが表示され、デフォルト値としてDetectOmissions="false"およびOptimizeMerge="false"が設定されます。

詳細は、次を参照してください:

また、Oracle Technology Networkからもフォーラムにアクセスできます。

Oracle BPEL Process Managerフォーラム

http://forums.oracle.com/forums/forum.jspa?forumID=212

TopLinkフォーラム
```
http://forums.oracle.com/forums/forum.jspa?forumID=48
```
このサイトには、ネイティブ順序付けの実装、オプティミスティック・ロック、およびTopLinkを使用したJTA管理の接続プーリングなど、2,000を超えるトピックがあります

    http://www.oracle.com/technology

9.3.11 `OutputCompletedXml`機能

OutputCompletedXmlは、アウトバウンドのinsertアクティビティの機能です。OutputCompletedXml機能の特長は、次のとおりです。

使用可能なリリース

リリース10.1.2.0.2以上

構成可能

OutputCompletedXmlは、デフォルトがtrueの場合にのみJCAファイルに表示されます。

デフォルト値

OutputCompletedXmlは、TopLinkの順序付けがデータベース順序からのinsertに主キーを割り当てるように構成されている場合はtrue、それ以外の場合はfalseです。

問題点

データベース順序からのinsertに主キーを自動割当てできます。ただし、insert/mergeには出力メッセージがなく、どの主キーが割り当てられたかを指示する手段がないため、この機能の有用性は減少しています。

注意:

順序付け(リンク)の構成後にアダプタ構成ウィザードを再実行してください。これにより、出力メッセージとWSDLプロパティOutputCompletedXml="true"を使用してinsert/merge WSDL操作を再生成できます。

パフォーマンス

output XMLが提供されるのは、output XMLが大幅に異なる場合のみです。そのため、TopLinkの順序付けが使用されない場合、この機能は無効化され、パフォーマンス・ヒットはありません。また、この機能は明示的に無効化することも可能です。同様に、オリジナルの入力XMLが更新されて戻され、まったく新しいXMLが作成されることはありません。また、主キーがディテール・レコードに割り当てられている場合は、XMLのシャロー・アップデートのみが実行され、出力XMLには反映されません。

互換性のない相互作用

DirectSQL="true"およびOutputCompletedXmlが存在する場合は、OutputCompletedXmlが優先されます。

9.3.12 インバウンドおよびアウトバウンド・トランザクションのQueryTimeout

アダプタ構成ウィザードの「詳細オプション」ページでQueryTimeoutを構成できます。この機能により、同じ名前のjava.sql.Statementレベル・プロパティが公開されます。基本的には、QueryTimeoutを使用するとコール時のタイムアウトを構成できます。

9.3.13 BPELへの同期ポストの実行(順序配信の許可)

この機能では、起動全体が単一スレッドとグローバル・トランザクションで実行されます。デフォルトでは、開始は非同期で、BPELプロセスは別のグローバル・トランザクションで起動されます。これはOracle BPELプロセスにのみ固有であるため、Oracle Mediatorを使用する場合、これは通常は同期起動です。

この機能を有効化するには、アダプタ構成ウィザードの「操作」ページで「BPELへの同期ポストの実行(順序配信の許可)」オプションをクリックします。

9.4 Oracleデータベース・アダプタの説明

この項には、Oracleデータベース・アダプタの概念に関する次の項目が含まれます。

9.4.1 リレーショナルからXMLへのマッピング

この項には、リレーショナルからXMLへのマッピングに関する次の項目が含まれます。

フラット表またはスキーマでは、リレーショナルからXMLへのマッピングを簡単に参照できます。表の各行は複合XML要素になります。各列の値はXML要素のテキスト・ノードになります。列値およびテキスト要素のどちらもプリミティブ型です。

表9-4に、MOVIES表の構造を示します。この表は、この章で説明する使用例で使用されます。詳細は、Oracleデータベース・アダプタの使用例を参照してください。

表9-4 MOVIES表の説明

名前	NULLかどうか	タイプ
`TITLE`	NULL以外	`VARCHAR2(50)`
`DIRECTOR`	--	`VARCHAR2(20)`
`STARRING`	--	`VARCHAR2(100)`
`SYNOPSIS`	--	`VARCHAR2(255)`
`GENRE`	--	`VARCHAR2(70)`
`RUN_TIME`	--	`NUMBER`
`RELEASE_DATE`	--	`DATE`
`RATED`	--	`VARCHAR2(6)`
`RATING`	--	`VARCHAR2(4)`
`VIEWER_RATING`	--	`VARCHAR2(5)`
`STATUS`	--	`VARCHAR2(11)`
`TOTAL_GROSS`	--	`NUMBER`
`DELETED`	--	`VARCHAR2(5)`
`SEQUENCENO`	--	`NUMBER`
`LAST_UPDATED`	--	`DATE`

対応するXMLスキーマ定義(XSD)を次の例に示します。

例 - 映画コレクションのXSD

<?xml version = '1.0' encoding = 'UTF-8'?>
<xs:schema targetNamespace="http://xmlns.oracle.com/
                pcbpel/adapter/db/top
/ReadS1" xmlns="http://xmlns.oracle.com/pcbpel/
adapter/db/top/ReadS1" elementFormDefault=
"qualified" attributeFormDefault="qualified" 
xmlns:xs="http://www.w3.org/2001/XMLSchema">
  <xs:element name="MoviesCollection" 
              type="MoviesCollection"/>
  <xs:complexType name="MoviesCollection">
     <xs:sequence>
        <xs:element name="Movies" type="Movies"
                           minOccurs="0" 
maxOccurs="unbounded"/>
     </xs:sequence>
  </xs:complexType>
  <xs:complexType name="Movies">
     <xs:sequence>
        <xs:element name="title">
           <xs:simpleType>
              <xs:restriction base="xs:string">
                 <xs:maxLength value="50"/>
              </xs:restriction>
           </xs:simpleType>
        </xs:element>
        <xs:element name="director" minOccurs="0"
                           nillable="true">
           <xs:simpleType>
              <xs:restriction base="xs:string">
                 <xs:maxLength value="20"/>
              </xs:restriction>
           </xs:simpleType>
        </xs:element>
        <xs:element name="starring" minOccurs="0"
                              nillable="true">
           <xs:simpleType>
              <xs:restriction base="xs:string">
                 <xs:maxLength value="100"/>
              </xs:restriction>
           </xs:simpleType>
        </xs:element>
        <xs:element name="synopsis" minOccurs="0" 
                             nillable="true">
           <xs:simpleType>
              <xs:restriction base="xs:string">
                 <xs:maxLength value="255"/>
              </xs:restriction>
           </xs:simpleType>
        </xs:element>
        <xs:element name="genre" minOccurs="0" 
                                  nillable="true">
           <xs:simpleType>
              <xs:restriction base="xs:string">
                 <xs:maxLength value="70"/>
              </xs:restriction>
           </xs:simpleType>
        </xs:element>
        <xs:element name="runTime" type="xs:decimal"
                              minOccurs="0"
                                 nillable="true"/>
        <xs:element name="releaseDate" type="xs:dateTime"
                                 minOccurs="0"
 nillable="true"/>
        <xs:element name="rated" minOccurs="0"
                                   nillable="true">
           <xs:simpleType>
              <xs:restriction base="xs:string">
              </xs:restriction>
           </xs:simpleType>
        </xs:element>
        <xs:element name="rating" minOccurs="0"
                                   nillable="true">
           <xs:simpleType>
              <xs:restriction base="xs:string">
                 <xs:maxLength value="4"/>
              </xs:restriction>
           </xs:simpleType>
        </xs:element>
        <xs:element name="viewerRating" minOccurs="0"
                                   nillable="true">
           <xs:simpleType>
              <xs:restriction base="xs:string">
                 <xs:maxLength value="5"/>
              </xs:restriction>
           </xs:simpleType>
        </xs:element>
        <xs:element name="status" minOccurs="0"
                                    nillable="true">
           <xs:simpleType>
              <xs:restriction base="xs:string">
                 <xs:maxLength value="11"/>
              </xs:restriction>
           </xs:simpleType>
        </xs:element>
        <xs:element name="totalGross"
                        type="xs:decimal" minOccurs="0"
                                 nillable="true"/>
        <xs:element name="deleted" minOccurs="0" 
                          nillable="true">
           <xs:simpleType>
              <xs:restriction base="xs:string">
                 <xs:maxLength value="5"/>
              </xs:restriction>
           </xs:simpleType>
        </xs:element>
        <xs:element name="sequenceno" type="xs:decimal"
                 minOccurs="0"
 nillable="true"/>
        <xs:element name="lastUpdated" type="xs:dateTime" 
                 minOccurs="0"
 nillable="true"/>
     </xs:sequence>
  </xs:complexType>
</xs:schema>

前述のコード例が示すように、MOVIESは、XML文字列全体を含む単一のCLOBまたはXMLTYPE列ではありません。そのかわり、XML complexType要素で構成されており、それぞれの要素はMOVIES表の各列に対応しています。フラット表の場合、リレーショナルからXMLへのマッピングは簡単です。

表9-5と表9-6に、EMPおよびDEPT表の構造をそれぞれ示します。これらの表は、MasterDetailの使用例で使用されます。詳細は、Oracleデータベース・アダプタの使用例を参照してください。

表9-5 EMP表の説明

名前	NULLかどうか	タイプ
`EMPNO`	NULL以外	`NUMBER(4)`
`ENAME`	--	`VARCHAR2(10)`
`JOB`	--	`VARCHAR2(9)`
`MGR`	--	`NUMBER(4)`
`HIREDATE`	--	`DATE`
`SAL`	--	`NUMBER(7,2)`
`COMM`	--	`NUMBER(7,2)`
`DEPTNO`	--	`NUMBER(2)`

表9-6 DEPT表の説明

名前	NULLかどうか	タイプ
`DEPTNO`	NULL以外	`NUMBER(2)`
`DNAME`	--	`VARCHAR2(14)`
`LOC`	--	`VARCHAR2(13)`

前の表定義が示すように、典型的な正規化されたリレーショナル・スキーマであるため、EMP表には従業員の部門番号が格納されていません。そのかわり、EMPの列の1つ(DEPTNO)は外部キーで、DEPTの主キー(DEPTNO)に相当します。

ただし、対応するXMLファイルには主キーおよび外部キーに類似の概念はありません。このため、結果のXMLファイルでは同一のデータが階層で表されます。したがって、リレーションシップは、マスター内部に埋め込まれたディテール・レコードを取得することで保持します。

XML要素には、プリミティブ型(stringやdecimal)または別のXML要素である複合型のいずれかの要素を含めることができます。そのため、従業員の要素に部門の要素を含めることができます。

対応するXMLで、リレーションシップがどのように表現され、インラインでどのように表示されるかを示します。EMPからはDEPTNOが削除され、DEPT自体が表示されています。

<EmpCollection>
  <Emp>
    <comm xsi:nil = "true" ></comm> 
    <empno >7369.0</empno>
    <ename >SMITH</ename>
    <hiredate >1980-12-17T00:00:00.000-08:00</hiredate>
    <job >CLERK</job>
    <mgr >7902.0</mgr
    <sal >800.0</sal>
    <dept>
      <deptno >20.0</deptno>
      <dname >RESEARCH</dname>
      <loc >DALLAS</loc>
    </dept>
  </Emp>
    ...
</EmpCollection>

リレーションシップを表現することで人間がXMLを読み取ることが可能になり、データを情報の1つのパケットとして送信できます。XMLファイルでは循環が許可されていないため、要素はそれ自体を含むことはできません。これはOracleデータベース・アダプタにより自動的に処理されます。

ただし、重複の可能性があります(つまり、異なるマスター・レコードで、同じXMLディテール・レコードが2回以上出現するということです)。たとえば、問合せで同じ部門で働く2人の従業員が返された場合、返されたXMLではどちらのEMPレコードにも同じDEPTレコードがインラインで出現します。

そのため、表をインポートしてXMLとしてマッピングする際には、Oracleデータベース・アダプタではアダプタ内の要素は出力されませんが、過剰な重複は避ける必要があります。Oracleデータベース・アダプタでは、次のように出力されます。

<Emp>
  <name>Bob</name>
  <spouse> 
    <name>June</name>
  </spouse
</Emp>

次のようには出力されません。

<Emp>
  <name>Bob</name>
  <spouse>
    <name>June</name> 
    <spouse>
      <name>Bob</name> 
      <spouse>
        ...
      </spouse> 
    </spouse> 
  </spouse> 
</Emp>

重複を回避するには、次のようにします。

複数の表をインポートします。EMPのみをインポートすると、DEPTが表示されません。
アダプタ構成ウィザードで、EMPとDEPTのリレーションシップを削除します。これでリレーションシップは削除されますが、外部キー列が元に戻ります。

どちらの場合も、対応するXMLは次のとおりです。

<EmpCollection> 
  <Emp>
    <comm xsi:nil = "true" ></comm>
    <empno >7369.0</empno>
    <ename >SMITH</ename> 
    <hiredate >1980-12-17T00:00:00.000-08:00</hiredate>
    <job >CLERK</job>
    <mgr >7902.0</mgr>
    <sal >800.0</sal> 
    <deptno >20.0</deptno>
  </Emp> 
   ...
</EmpCollection>

前述のどちらの解決策も、ディテール・レコードを完全に元に戻すのではなく、外部キーを元に戻すことで十分な場合にのみ適切です。

9.4.1.1 リレーショナル型からXMLスキーマ型へ

表9-7に、データベースから表をインポートする際に、データベースのデータ型がどのようにXMLのプリミティブ型に変換されるかを示します。

表9-7 データベースのデータ型のXMLのプリミティブ型へのマッピング

データベース・タイプ	XMLタイプ(接頭辞はxs:)
`VARCHAR、VARCHAR2、CHAR、NCHAR、NVARCHAR、NVARCHAR2、MEMO、TEXT、CHARACTER、CHARACTER VARYING、UNICHAR、UNIVARCHAR、SYSNAME、NATIONAL CHARACTER、NATIONAL CHAR、NATIONAL CHAR VARYING、NCHAR VARYING、LONG、CLOB、NCLOB、LONGTEXT、LONGVARCHAR、NTEXT`	`string`
`BLOB、BINARY、IMAGE、LONGVARBINARY、LONG RAW、VARBINARY、GRAPHIC、VARGRAPHIC、DBCLOB、BIT VARYING`	`base64Binary`
`BIT、NUMBER(1) DEFAULT 0、SMALLINT DEFAULT 0、SMALLINT DEFAULT 0`	`boolean`
`TINYINT、BYTE`	`byte`
`SHORT、SMALLINT`	`short`
`INT、SERIAL`	`int`
`INTEGER、BIGINT`	`integer`
`NUMBER、NUMERIC、DECIMAL、MONEY、SMALLMONEY、UNIQUEIDENTIFIER`	`decimal`
`FLOAT FLOAT16、FLOAT(16)、FLOAT32、FLOAT(32)、DOUBLE、DOUBLE PRECIS、REAL`	`double`
`TIME、DATE、DATETIME、TIMESTAMP、TIMESTAMP(6)、SMALLDATETIME、TIMESTAMPTZ、TIMESTAMPLTZ、TIMESTAMP WITH TIME ZONE、TIMESTAMP WITH LOCAL TIME ZONE`	`dateTime`

NUMBERは最も用途の広い数値用のXMLデータ型であるdecimalに、VARCHAR2とCLOBはstringに、BLOBはbase64Binary(プレーン・テキスト要件を満たすため)に、DATE型はdateTimeに変換されます。

ここで説明されていない型は、デフォルトでjava.lang.Stringおよびxs:stringになります。

サポートされているのがxs:dateTime形式のみであるため、タイムスタンプのサポートは基本的です。BFILE型は明確にサポートされていません。

注意:

ユーザー定義のObject、Struct、VARRAYおよびREF型は、リリース11gおよび12でサポートされています。

XMLはプレーン・テキストであるため、BLOBおよびbyteの値はbase 64/MIMEでエンコードされ、文字データとして渡されます。

9.4.1.2 任意のリレーショナル・スキーマの任意のXMLスキーマへのマッピング

Oracleデータベース・アダプタでは、リレーショナル・データベース上の任意のリレーショナル・スキーマの、任意のXMLスキーマへのマッピングがサポートされています。ただし、要素のレイアウトに対する明確なユーザー制御がない状態でアダプタ構成ウィザードによりXMLスキーマが生成されるため、ユーザーはXMLスキーマを選択できません。

スキーマのマッピング方法は、「アダプタ構成ウィザード」で制御することも、後からTopLink Workbenchで制御することもできます。トランスフォーメーション・ステップとOracleデータベース・アダプタを関連付けることで、任意のリレーショナル・スキーマを任意のXMLスキーマにマッピングできます。

9.4.1.3 複数の表の問合せ

複数の関連表に対するSQL select文を実行する場合、SQLを作成するには次の3つの方法があります。これらの方法は、マスター・レコードに対する問合せ時にディテール・レコードを取り込む方法に関係しています。

以降の各項では、この3つの方法を比較しながら説明します。単一表から行を選択する場合は、複数の表から選択する場合のような問題が存在しません。

9.4.1.3.1 リレーションシップの問合せを使用する方法(TopLinkのデフォルト)

単一のMaster行を選択すると、TopLinkでは常に個別に問合せを行い、そのMaster表に属するディテールをすべて取得できます。このような隠れた問合せ(リレーションシップの問合せ)はTopLinkのメタデータで捕捉され、準備するのは1回のみです。

次のサンプル・シナリオのSQL文を考えてみます。

SELECT DIRECTOR, ..., VIEWER_RATING 
       FROM MOVIES 
WHERE RATING = 'A';

このSQL文はマスターごとに次のようになります。

SELECT CRITIC, ..., TITLE
       FROM MOVIE_REVIEWS
WHERE (TITLE = ?)

問合せを1+n回実行してすべてのデータを取り込むことができます。nは、1回目の問合せで戻されるマスターの行数です。

このアプローチは安全ですが、すべてのデータを取得するためにデータベースへのラウンドトリップが多数必要になるため低速です。

リレーションシップの問合せを使用するアプローチ(TopLinkのデフォルト)を使用して構成する場合は、JDeveloperの外部でor_mappings.xmlを編集する必要があります。また、batch-reading要素の値をfalseに変更してください。

9.4.1.3.2 オリジナルのselectを利用する方法(TopLinkのバッチ属性読取り)

これはデフォルト機能で、次の例に示すように、TopLinkは第2のselect文ですべてのディテールを読み取るように、オリジナルのSQL select文を変更できます。

SELECT DIRECTOR, ..., VIEWER_RATING
FROM MOVIES
WHERE RATING = 'A'
SELECT DISTINCT t0.CRITIC, ..., t0.TITLE
FROM MOVIE_REVIEWS t0, MOVIES t1
WHERE ((t1.RATING = 'A') AND (t0.TITLE = t1.TITLE))

オリジナルのselect文でディテールを取得することを考慮して、問合せを合計2回(1+1=2)実行する必要があります。

メリット

バッチ属性読取りには、次のメリットがあります。

すべてのデータがデータベースへの2回のラウンドトリップで読み取られます。
これは、リリース10.1.2.0.2のデフォルト機能です。

デメリット

バッチ属性読取りには、次のデメリットがあります。

maxTransactionSize (RECEIVEのポーリング時)またはmaxRows (SELECTの起動時)を使用してメモリーに1回にロードされる行数を制限する場合、この設定ではバッチ属性問合せの持ち越しが容易ではありません。結果セットが1つのみの場合は、カーソル付きの結果を操作する方が容易です。(オリジナルの問合せにORDER BY句があると、複数カーソルの使用が困難な場合があります)。
TopLinkでSQL文を変更できるのは、認識可能なフォーマットが使用されている場合のみです。ハイブリッドSQLアプローチを使用し、ルートselectにカスタムSQLを設定すると、TopLinkでは、そのSQLを解析してバッチselectを作成できません。
バッチ問合せでは、2つのマスターがどちらも同じディテールを指している場合に、同じディテールが2回戻されないように、DISTINCT句を使用します。結果セットでLOBを戻す場合、DISTINCT句は使用できません。

構成

構成は、1-1または1-Mマッピングに基づきます。リリース10.1.2.0.2以降は、これらのマッピングすべてにデフォルトでこのプロパティが設定されています。構成するには、JDeveloperの外部でor_mappings.xmlを編集し、<batch-reading>要素をtrue (デフォルト)またはfalseに編集します。

9.4.1.3.3 単一結果セットを戻す方法(TopLinkの結合属性読取り)

ディテール表はオリジナルのSQL select文に外部結合され、次の例に示すようにマスターとディテールの両方を1つの結果セットで戻します。

SELECT DISTINCT t1.DIRECTOR, ..., t1.VIEWER_RATING, t0.CRITIC, ..., t0.TITLE
FROM MOVIE_REVIEWS t0, MOVIES t1
WHERE ((t1.RATING = 'A') AND (t0.TITLE (+) = t1.TITLE))

このため、実行する必要のある問合せは合計1回となります。

メリット

次のようなメリットがあります。

ポーリング中にmaxTransactionSizeを使用する場合、単一カーソルの処理によるメリットが大きくなります。
ハイブリッドSQLのルートをたどってカスタムSQL文に入る場合、処理する必要のあるSQL文は1つのみですが、通常、TopLinkでは非表示の一連のSQL文をさらに使用して関連行を取り込みます。
read一貫性: 様々な表について異なるインスタンスで読み取るのではなく、同時にすべての関連行を読み取ることができます。
データベースへのラウンドトリップが1回のみですむためパフォーマンスは理想的ですが、バッチ属性読取りは問合せ対象の表ごとに1回ずつ必要です。

デメリット

ただし、重複データを戻すコストなど、デメリットもいくつかあります。たとえば、Master表とDetail表を読み取る場合に、Masterには各行に100列、Detailには各行に2列が含まれているとします。Master表の各行には、通常、関連するDetail行も100行含まれています。

各表で1回問合せすると、前述の例の結果セットは次の例のようになります。

Master
Column1 column2 ….. column100

Master1 ...

Detail

Detail
Column1 column2
Detail1   ...
Detail2
...
Detail100 ...

この例では、300列の値が次のように戻されます。

(columns in master + columns in detail x details per master) =
(           100             +            2                x              100         )  =  300

すべての表に対して1回問合せすると、結果セットは次の例のようになります。

Master                                             Detail

Column1 Column2 ... Column100                      Column1  Column2
Master1    ...                                     Detail1     ...
Master1    ...                                     Detail2     ...
Master1    ...                                     Detail100   ...

2つの結果セットでは300列の値が戻されるのに対して、すべての表を1回問合せすると、次のように単一の結果セットで10,200列の値が戻されます。

((columns in master + columns in detail) x details per master) =
((          100     +            2     ) x       100         ) =  10,200

この場合、戻されるデータの97パーセントは重複データであるため、ネットワーク通信量と計算の重大な浪費となる可能性があります。また、マスターに2つの関連表detail1およびdetail2があり、各マスターに100列があると、戻される列値の数はマスター行ごとに1,000万以上になります。

通常は、次の単純な算式を使用して、単一の結果セットですべての行を戻す場合の相対コストを予想できます。

        (Master columns + Detail1 columns + Detail2 columns + ... ) x 
                Detail1s per Master x 
                Detail2s per Master x ...
bloat = ___________________________________________________________

       (Master columns + Detail1 columns X Detail1s per Master + 
               Detail2 columns X Detail2s per Master + ...)

1-1関係の場合、この値は常に1であり、同じ例でマスター行ごとに2列のみで、ディテールに100列があり、マスター各行にそれぞれ3または4行のディテールしかなければ、膨張度は次のようになります。

               (2 + 100) x 4        408
bloat =        ____________  = ___________  ~=  1
               (2 + 100 x 4)        402

もう1つのデメリットは、この設定ではアウトバウンドSELECTのmaxRows設定の意味に歪みが生じることです。

構成

構成するには、アダプタ構成ウィザードの「選択条件の定義」ページで「外部結合を使用してマスター表とディテール表の両方の単一結果セットを返す」を選択します。

注意:

TopLinkの式ビルダーを使用して次のようなSQL問合せを作成すると、予期した結果が得られない場合があります。

SELECT DISTINCT t1.TABLE1_ID, t1.COLUMN_A FROM TABLE2 t0, 
TABLE1 t1 WHERE ((t0.STATUS = 1) AND (t0.TABLE1_ID = t1.
TABLE1_ID))

この問合せに予期される結果は、表1とそれが所有する表2でstatus = 1の行のみが戻されることです。

ただし、この問合せでの実際の意味は「表2のいずれかがstatus = 1であれば表1」となり、選択基準に一致する表1と、表1が所有するすべて(ALL)の表2が、status = 1かどうかに関係なく他のステータスのものも含めて戻されます。DISTINCTキーワードにより、表1が繰り返されず、表2にまたがって結合が発生することが保証されます。

解釈の誤りは、TopLinkの動作に発生します。式ビルダーでは、表1の選択基準しか指定できず、表1が所有する表2は制御されないため、この部分は自動的に実行されます。

ただし、次の2つのアプローチのいずれかを使用すると、予期した結果を取得できます。

1.)選択基準にstatus = 1を使用して表2を直接問い合せます。つまり、表1を通過して表1が所有する表2を取得することはしません。

2.)次の例のように直接(カスタムSQL)を使用します。

SELECT TABLE1.TABLE1_ID, TABLE1.COLUMN_A, TABLE2.STATUS 
FROM TABLE2, TABLE1 WHERE TABLE2.STATUS=1 AND TABLE1.
TABLE1_ID = TABLE2.TABLE1_ID

9.4.1.3.4 複数の表の問合せに使用した方法の比較

表面上は、単一結果セットを戻すのが最善の方法(1回の問合せ)で、次にバッチ属性読取り(select文の変更、2回の問合せ)、最後にデフォルトのリレーションシップの読取り(n+1回の問合せ)となります。ただし、より高度なオプションにはどちらもいくつか問題があります。

ユーザー定義SQLの変更

custom/hybrid SQLを指定すると、TopLinkでは、そのSQL文字列を変更してディテールのselectを作成することができません。このため、hybrid SQLを使用せず、できるだけ頻繁にウィザードのvisual expression builderを使用してselectsを作成する必要があります。

SQLの表示

デフォルトおよびバッチ属性読取りでは、どちらの場合も、TopLinkにより実行される追加の問合せがユーザーにとってわかりにくくなることがあります。このため、アダプタ構成ウィザードでユーザーに表示されるraw SQLは、わかりやすく管理しやすいように単一の結果セットを戻すことを想定しています。

1度に戻される行数が多すぎる

データベースには膨大な情報を格納でき、select文には1度に戻される情報が多すぎるという共通の問題があります。データベース・アダプタのreceiveでは、maxTransactionSizeプロパティを設定して、一度にカーソル付き結果セットから読み取られてメモリー内で処理される行数を制限できます。select文の1回の起動用に、類似のmax-rows設定が存在します。ただし、この設定は大きなリスクを伴います。

9.4.2 WebサービスとしてのSQL操作

リレーショナル・スキーマをXMLとしてマッピングした後、基本的なSQL操作もWebサービスとしてマッピングする必要があります。いくつかの操作では直接SQL等価に変換されますが、その他はより複雑です。

この項には次のトピックが含まれます:

9.4.2.1 DML操作

データ操作言語(DML)の操作は、基本的なSQLのINSERT、UPDATEおよびSELECT操作と同等です。SQLのINSERT、UPDATE、DELETEおよびSELECTは、すべて同じ名前のWebサービス操作にマッピングされます。MERGEは、存在チェックの結果に基づき、INSERTまたはUPDATEのいずれかになります。アウトバウンド書込みと呼ばれるデータ操作とアウトバウンド読取りと呼ばれるSELECT操作とで区別されます。merge(アウトバウンド書込みのデフォルト)およびqueryByExampleに関するWebサービスとSQLとの関係は、基本的なSQLのINSERT、UPDATEおよびSELECTとの関係ほど明確ではありません。

この項には次のトピックが含まれます:

Merge

Mergeでは、まずデータベースの対応するレコードが読み取られて変更箇所が算出され、最低限の更新が実行されます。INSERT、UPDATEおよびMERGEは、単一の行および表が作業対象の場合に最も適切です。ただし、XMLには複合型が含まれ、複数の表の複数の行にマッピングされます。たとえば、DEPTに多数のEMPSがあり、それらのそれぞれにADDRESSがあるとします。この場合、変更された可能性のある行がどのくらいで、どの行を挿入、更新または削除すればよいかを算出する必要があります。特定の行が変更されなかったか、1つのフィールドのみが変更された場合、DMLコールは最小限になります。

querybyExample

SELECT操作とは異なり、queryByExampleには設計時に指定する選択基準はありません。そのかわり、各invokeでは、典型的な入力XMLレコードから選択基準が推測されます。

たとえば、出力のxmlRecordが従業員レコードで、入力がlastName = "Smith"を含むサンプルのxmlRecordである場合、実行時には姓がSmithの従業員がすべて返されます。

queryByExampleのサブセットは、主キーで問合せを行うためのもので、主キー属性のみが設定されているサンプルのXMLレコードに渡すことで実装できます。

視覚的なクエリー・ビルダーを使用して問合せを作成する必要がない場合や、出力レコードと同様に入力レコードでも同じXMLスキーマを共有する柔軟性が必要な場合にqueryByExampleを使用します。

queryByExample操作では、実行ごとに新しいSELECTを準備する必要があるため、ややパフォーマンスが低下します。これは、サンプルのXMLレコードに設定されている属性が毎回異なり、選択基準が変わるためです。

入力xmlRecord:

<Employee>
      <id/>
      <lastName>Smith</lastName>
</Employee>

出力xmlRecord:

<EmployeeCollection>
      <Employee>
         <id>5</id>
         <lastName>Smith</lastName>
         ....
      </Employee>
      <Employee>
         <id>456</id>
         <lastName>Smith</lastName>
         ....
      </Employee>
</EmployeeCollection>

制限

queryByExampleを使用すると、問合せがキャッシュされる通常の選択問合せとは異なり、毎回問合せが異なる可能性があるため、データベース・アダプタが起動されるたびに問合せが動的に生成されます。
queryByExample機能では、ユーザーは結果を返す行の最大数の制限を設定できません。このため、多数の行が返されます。これに伴って、行を処理するためのメモリー要件も増加します。

9.4.2.2 ポーリング戦略

インバウンドのreceive操作では、データベース内のイベントや変更のリスニングおよび検出が可能で、言い換えればビジネス・プロセスを起動させる役割を果たします。これは一度のみのアクションではなく、アクティブ化です。新しい行またはイベントに関してデータベース表をポーリングする、ポーリング・スレッドが開始されます。

MOVIES表に新しい行が挿入されるたびに、ポーリング操作によりSCAランタイムに伝達されます。戦略はすべてのレコードを一度ポーリングすることです。開始時に存在する行、および一定期間にわたり新しい行が挿入されるたびにそれらをすべて受信するには、最初のSELECTを一定期間繰り返す必要があります。ただし、一度読み取られた新しい行は削除されないため、各ポーリングで繰り返し読み取られる可能性があります。

イベントをポーリングする様々な方法は、ポーリング戦略、読取り後戦略またはパブリッシュ戦略とも呼ばれ、単純で変更を伴うものから複雑で変更を伴わないものまで多岐にわたります。各戦略では、行やイベントの読取り後に次のポーリング間隔で再度検索しないためにはどうしたらよいかという問題に対して異なる解決策が採用されています。最も簡単(および変更を伴う)解決策は、行を削除して再度問い合せないようにすることです。

この項では、データベースからデータが読み取られた後に実行できるポーリング操作について説明します。また、この項では、特定の状況でどの戦略を採用するかを判断するために役立つ方針と要因についても説明します。

読取り済の行の削除

この操作は、物理削除ポーリング戦略を採用するときに選択します。この操作は、データベース表でレコードをポーリングし、処理後に削除します。この戦略は、INSERT操作に関連するイベントの取得に使用でき、親表のDELETEおよびUPDATE操作に関連するデータベース・イベントの取得には使用できません。この戦略は、子表イベントのポーリングには使用できません。この戦略では、複数のアダプタ・インスタンスで同じソース表にアクセスできます。データが重複することはありません。

事前条件: 削除ポーリング戦略を使用するには、親表および関連する子表に対する削除権限を持っている必要があります。表9-8に、削除ポーリング戦略を使用するための要件を示します。

表9-8 削除ポーリング戦略の事前条件

一致する要件	競合
挿入のポーリング	ソースでの削除は不可
シャロー・デリート	ソースでの更新は不可
カスケード削除	更新のポーリング
最小SQL	削除のポーリング
データの重複なし	子の更新のポーリング
デフォルト	--
実際のSQLの許可	--
同時ポーリング	--

注意:

シャロー・デリートとカスケード削除の場合、最上位行の削除、すべてカスケードまたは状況に応じたカスケードを行うように削除操作を構成できます。

同時ポーリングは、削除と論理削除の両方のポーリング戦略用に構成できます。

構成: 削除ポーリング戦略は、最上位行の削除、すべてカスケードまたは状況に応じたカスケードを行うように構成できます。この戦略により、状況に応じて、子行ではなく親行のみの削除、カスケード削除およびオプションのカスケード削除が可能になります。設計時にイベント公開を実行するためのポーリング間隔を構成できます。

削除カスケード・ポリシー: オプションの高度な構成では、DELETE操作のカスケード・ポリシーを指定します。たとえば、住所と複数の電話番号を持つ従業員をポーリングすると、電話番号(デフォルトでは1対多)は個人的に所有されるため削除されますが、住所(デフォルトでは1対1)は削除されません。次の例に示すように、or_mappings.xmlを構成することで変更できます。

<database-mapping>
   <attribute-name>orders</attribute-name>
   <reference-class>taxonomy.Order</reference-class>
   <is-private-owned>true</is-private-owned>

また、アクティブ化自体を構成し、最上位(マスター行)のみの削除、またはすべての削除を実行することもできます。

注意:

PrivateOwned注釈を使用して、リレーションシップが私有されることが指定されます。リレーションシップが私有されるとは、ターゲット・オブジェクトがソース・オブジェクトの依存部分であり、その他のオブジェクトから参照されず、単独では存在できないことを意味します。私有によって、操作が、削除、挿入、リフレッシュ、ロック(ロックがカスケードされる場合)を含むリレーションシップ間でカスケードされます。

また、PrivateOwnedは、コレクションから除去されるプライベート・オブジェクトが削除され、追加されるオブジェクトが挿入されたことも確認します。

receive操作はインバウンドJCAでは次のように表示されます。

例 - インバウンドJCAのreceive操作

<connection-factory location="eis/DB/Connection1"
            UIConnectionName="Connection1" adapterRef=""/>
  <endpoint-activation portType="dd_ptt" operation="receive">
    <activation-spec className="oracle.tip.adapter.db.
                      DBActivationSpec">
      <property name="DescriptorName" value="dd.Emp"/>
      <property name="QueryName" value="ddSelect"/>
      <property name="MappingsMetaDataURL" value="dd-or-mappings.xml"/>
      <property name="PollingStrategy" 
                         value="LogicalDeletePollingStrategy"/>
      <property name="MarkReadColumn" value="STATUS"/>
      <property name="MarkReadValue" value="PROCESSED"/>
      <property name="MarkReservedValue" value="RESERVED-1"/>
      <property name="MarkUnreadValue" value="UNPROCESSED"/>
      <property name="PollingInterval" value="5"/>
      <property name="MaxRaiseSize" value="1"/>
      <property name="MaxTransactionSize" value="10"/>
      <property name="ReturnSingleResultSet" value="false"/>
    </activation-spec>
  </endpoint-activation>
</adapter-config>

[Table_Name]表のフィールドの更新 (論理削除)

この操作は、論理削除ポーリング戦略を採用するときに選択します。この戦略には、処理された各行の特別なフィールドの更新、および処理済の行を除外するための実行時のWHERE句の更新が関連します。

アプリケーション行はほとんど削除されないが、状態列isDeletedがtrueに設定されている論理削除に似ています。状態列と読取り値は指定する必要がありますが、変更されたWHERE句と読取り後の更新はOracleデータベース・アダプタにより自動的に処理されます。

事前条件: ソース表の論理削除権限またはスキーマを1度のみ変更(列追加)する権限を持っている必要があります。表9-9に、論理削除ポーリング戦略を使用するための要件を示します。

表9-9 論理削除ポーリング戦略の事前条件

一致する要件	競合
挿入のポーリング	ソースでの更新は不可
ソースでの削除は不可	削除のポーリング
最小SQL	--
データの重複なし	--
最小構成	--
実際のSQLの許可	--
更新のポーリング	--
子の更新のポーリング	--
同時ポーリング	--

注意:

要件を満たす方法は、次のとおりです。

更新のポーリング: トリガーの追加
子の更新のポーリング: トリガーの追加
同時ポーリング: 追加のマーク未読取り値および予約値の指定

構成: 論理削除ポーリング戦略には最小構成が必要です。マーク読取り列および処理済レコードを示す値を指定する必要があります。

receive操作はインバウンドWSDLでは次のように表示されます。

<operation name="receive">
   <jca:operation
      ActivationSpec="oracle.tip.adapter.db.DBActivationSpec"
         …
      PollingStrategyName="LogicalDeletePollingStrategy"
      MarkReadField="STATUS"
      MarkReadValue="PROCESSED"

論理削除の構成を指定すると、Oracleデータベース・アダプタにより次のWHERE句がすべてのポーリング問合せに追加されます。

AND (STATUS IS NULL) OR (STATUS <> 'PROCESSED')

データベース構成: ポーリングする表には状態列が存在する必要があります。存在しない場合は、既存の表に追加できます。

更新のポーリングのサポート: 各読取りで行が削除されない場合、行は何度でも読み取れます。レコードが変更されるたびにマーク読取りフィールドをリセットするには、次のように、トリガーを追加する必要があります。

create trigger Employee_modified
before update on Employee
for each row
begin
   :new.STATUS := 'MODIFIED';
end;

同時アクセス・ポーリングのサポート: 単一のインスタンスでイベントを処理するのは1度のみであるように、インスタンスが複数の場合にも同じことが当てはまります。そのため、インスタンスでレコードを処理する前に、そのレコードを一意の値で予約しておく必要があります。前の例と同様に、状態列を次のように使用できます。

<operation name="receive">
   <jca:operation
      ActivationSpec="oracle.tip.adapter.db.DBActivationSpec"
         …
      PollingStrategyName="LogicalDeletePollingStrategy"
      MarkReadField="STATUS"
      MarkUnreadValue="UNPROCESSED"
      MarkReservedValue="RESERVED${IP-2}-${weblogic.Name-1}-${instance}"
      MarkReadValue="PROCESSED"

ポーリング問合せは次の例のようになります。

Update EMPLOYE set STATUS = 'RESERVED65-1-1' where (CRITERIA) AND (STATUS = 'UNPROCESSED');

Select … from EMPLOYEE where (CRITERIA) AND (STATUS = 'RESERVED65-1-1');

読取り後のUPDATEは、すべてを更新できるため、より高速です。

Update EMPLOYEE set STATUS = 'PROCESSED' where (CRITERIA) AND (STATUS = 'RESERVED65-1-1');

順序表の更新

この操作は、「順序表: 最終読取りID」戦略を採用するときに選択します。このポーリング戦略では、順序値の保存にヘルパー表の使用が関連します。ソース表は変更されませんが、別のヘルパー表で読取り済の行が記録されます。たとえば、順序値1000は、順序値がそれより小さいすべてのレコードが処理済であることを意味します。多くの表には、常に増加しトリガーやアプリケーションによって維持されているカウンタ・フィールドがあるため、この戦略は変更を伴わないポーリングに使用されます。処理済の行のフィールドをOracleデータベース・アダプタで変更する必要はありません。

事前割当てサイズが1のネイティブ順序付けでは、時間とともに増加し続ける主キーと一緒に行が挿入されることが保証されます。

この戦略ではソース行が更新されないため、変更を伴わない削除とも呼ばれます。また、sequenceフィールドなどの順序付け戦略は、行を処理順に順序付けるために使用できます。

行が順番にソートされている場合、Oracleデータベース・アダプタは、処理する行としない行を単一の情報の単位により把握します。

事前条件: ソース・スキーマの表の順序付け権限または表の作成権限を持っている必要があります。ソース表には、INSERT(ネイティブ順序付けされたOracleの主キー)またはUPDATE(最終変更タイムスタンプ)ごとに一定量増加する列があります。表9-10に、順序付けポーリング戦略を使用するための要件を説明します。

表9-10 順序付けポーリング戦略の事前条件

一致する要件	競合
挿入のポーリング	削除のポーリング
更新のポーリング	実際のSQLの許可
ソースでの削除は不可	同時ポーリング
ソースでの更新は不可	--
追加のSQLを1つ選択	--
データの重複なし	--
中程度の構成	--
子の更新のポーリング	--

構成: 別のヘルパー表を定義する必要があります。ソース表では、増加し続ける列を指定する必要があります。

例 - 順序付けの指定

<adapter-config name="ReadS" adapter="Database Adapter" 
xmlns="http://platform.integration.oracle/blocks/adapter/fw/metadata">
    <connection-factory location="eis/DB/DBConnection1" 
UIConnectionName="DBConnection1" adapterRef=""/>
  <endpoint-activation portType="ReadS_ptt" operation="receive">
    <activation-spec className="oracle.tip.adapter.db.DBActivationSpec">
      <property name="DescriptorName" value="ReadS.PerfMasterIn"/>
      <property name="QueryName" value="ReadSSelect"/>
      <property name="MappingsMetaDataURL" value="ReadS-or-mappings.xml"/>
      <property name="PollingStrategy" value="SequencingPollingStrategy"/>
      <property name="SequencingTable" value="PC_SEQUENCING"/>
      <property name="SequencingColumn" value="PK"/>
      <property name="SequencingTableKeyColumn" value="TABLE_NAME"/>
      <property name="SequencingTableValueColumn" value="LAST_READ_ID"/>
      <property name="SequencingTableKey" value="PERF_MASTER_IN"/>
      <property name="PollingInterval" value="60"/>
      <property name="MaxRaiseSize" value="1"/>
      <property name="MaxTransactionSize" value="10"/>
      <property name="ReturnSingleResultSet" value="false"/>
    </activation-spec>
  </endpoint-activation>
</adapter-config>

順序付けフィールドの型が実際には数値の場合は除外できます。

データベース構成: 指定されたデータベースに対して、順序付け表を一度構成する必要があります。複数のプロセスで同じ表を共有できます。前述の例でActivationSpecが指定されていた場合、CREATE TABLEコマンドは次のようになります。

CREATE TABLE SEQUENCING_HELPER 
(
TABLE_NAME VARCHAR2(32) NOT NULL,
LAST_READ_DATE DATE
)
;

更新のポーリング: 前述の例では、オブジェクトが変更されるたびに変更時間が更新されるため、ポーリングは新しいオブジェクトまたは更新を対象としています。

insertまたはupdateごとの変更時間を設定するサンプルのトリガーは次のようになります。

create trigger Employee_modified
before insert or update on Employee
for each row
begin
  :new.modified_date := sysdate;
end;

順序番号の使用: 順序番号は挿入または更新のポーリングに使用できます。ネイティブ順序付けでは、増分値1が使用されている場合、単調に増加する主キーが返されます。また、マテリアライズド・ビュー・ログの順序番号も使用できます。

異なるデータベースにある外部順序表の更新

この操作は、順序表: 最終更新戦略を採用するときに選択します。このポーリング戦略では、last_updated値の保存にヘルパー表の使用が関連します。たとえば、2005-01-01 12:45:01 000というlast_updated値は、最終更新がその時間またはそれより前のすべてのレコードは処理済であることを意味します。

多くの表には、トリガーやアプリケーションによって維持されているlast_updatedまたはcreation_time列があるため、この戦略は変更を伴わないポーリングに使用されます。処理済の行のフィールドをOracleデータベース・アダプタで変更する必要はありません。

この戦略ではソース行が更新されないため、変更を伴わない削除とも呼ばれます。また、last_updatedフィールドなどの順序付け戦略は、行を処理順に順序付けるために使用できます。行が順番にソートされている場合、Oracleデータベース・アダプタは、処理する行としない行を単一の情報の単位により把握します。

事前条件および構成の詳細は、「順序表の更新」を参照してください。

順序ファイルの更新

この戦略の動作は「異なるデータベースにある外部順序表の更新」と同様で、唯一の相違点は制御情報が表ではなくファイルに格納されることです。

制御表戦略

この操作は、制御表ポーリング戦略を採用するときに選択します。このポーリング戦略には、まだ処理されていないすべての行の主キーの保存に制御表の使用が関連します。(主キーにより)制御表とソース表が自然結合しているため、制御表に対するポーリングは、実際にはソース表を直接ポーリングすることと同じです。ただし、追加のインダイレクション層により次のことが可能になります。

削除ポーリング戦略などの変更を伴うポーリング戦略を制御表の行にのみ適用できます。これにより、ソース表の行を保護できます。
処理対象の行の主キーのみが制御表に表示されます。行自体にない情報は、処理する行の制御に使用できます(WHERE句のみでは不十分です)。
制御表には行全体はコピーされず、ディテール行などのソース表の任意の構造をコピーせずに呼び出せます。

ストリームおよびマテリアライズド・ビュー・ログにより適切な制御表が作成されます。

事前条件: ソース表に対するトリガーの作成/変更権限を持っている必要があります。表9-11に、制御表ポーリング戦略を使用するための要件を示します。

表9-11 制御表ポーリング戦略の事前条件

一致する要件	競合
挿入のポーリング	高度な構成: データベースのネイティブXMLには制御ヘッダーがあり、トリガーが必要です。
更新のポーリング	--
削除のポーリング	--
子の更新のポーリング	最小のデータ重複(主キーは制御表に格納)。
ソースでの削除は不可	--
ソースでの更新は不可	--
追加のSQL選択は不可	--
同時ポーリング	--
実際のSQLの許可	--
監査	--

行が変更されるたびにトリガーを使用すると、マスター表の名前と主キーを含む制御表にエントリが追加されます。設計時、制御表は、一致する主キーに基づきマスター表への1対1マッピングで、ルート表として定義されます。制御表には、タイムスタンプなどの追加の制御情報および操作タイプ(INSERT、UPDATEなど)が含まれます。

この設定では、"削除"ポーリング戦略が便利です。制御表を小さく保つことが重要であり、shouldDeleteDetailRows="false"オプションが使用されている場合は、制御行のみが削除され、変更を伴わない削除が実行されます(DELETEは実際の表にはカスケードされません)。

複数のマスター表に同じ制御表を再利用できます。TopLinkでは、制御表を複数の子を持つ1つの抽象クラスとしてマッピングすることで、同じ表を複数のディスクリプタにマッピングできます。各子には、異なるマスター表への一意の1対1マッピングがあります。この方法の利点は、各子にクラス・インジケータ・フィールドおよび値を指定できるため、各ポーリング問合せに明示的なWHERE句が不要なことです。

部門表および子の従業員行の両方への変更のポーリングに使用するサンプル・トリガーを次に示します。

CREATE OR REPLACE TRIGGER EVENT_ON_DEPT 
   AFTER INSERT OR UPDATE ON DEPARTMENT 
   REFERENCING NEW AS newRow 
   FOR EACH ROW 
   DECLARE X NUMBER;
BEGIN
   SELECT COUNT(*) INTO X FROM DEPT_CONTROL WHERE (DEPTNO = :newRow.DEPTNO);
   IF X = 0 then
   insert into DEPT_CONTROL values (:newRow. DEPTNO);
   END IF;
END;
CREATE OR REPLACE TRIGGER EVENT_ON_EMPLOYEE
   AFTER INSERT OR UPDATE ON EMPLOYEE
   REFERENCING OLD AS oldRow NEW AS newRow
   FOR EACH ROW
   DECLARE X NUMBER;
BEGIN
   SELECT COUNT(*) INTO X FROM DEPT_CONTROL WHERE (DEPTNO = :newRow.DEPTNO);
   IF X = 0 then
   INSERT INTO DEPT_CONTROL VALUES (:newRow.DEPTNO);
   END IF;
   IF (:oldRow.DEPTNO <> :newRow.DEPTNO) THEN
      SELECT COUNT(*) INTO X FROM DEPT_CONTROL WHERE (DEPTNO = :oldRow.DEPTNO);
      IF (X = 0) THEN
         INSERT INTO DEPT_CONTROL VALUES (:oldRow.DEPTNO);
      END IF;
   END IF;
END;

9.5 データベース・アダプタ・デプロイメント

Oracleデータベース・アダプタは、インストールによってアプリケーション・サーバーにデプロイされます。これには、データソースjdbc/SOADataSourceを指す単一アダプタ・インスタンス・エントリeis/DB/SOADemoが含まれています。データベースへの接続情報は、データソース定義内にあります。

OracleAS Adapter for Databasesを使用するSOAプロジェクトをデプロイするとき、最初に新しいアダプタ・インスタンスを追加し、アプリケーション・サーバーを再起動することが必要となる場合があります。これは、jdbc/SOADataSourceで参照されるデータベースとは別のデータベースを指す場合や、まだ存在しない名前をアダプタ・インスタンスに付けた場合などに必要となります。たとえば、JDeveloperでConnection1という名前の接続を作成した場合、図9-7に示すように、DBアダプタ・サービスはデフォルトでeis/DB/Connection1を指します。

また、次のコードスニペットに示すようにdb.jcaファイルを確認することによって、サービスがどのアダプタ・インスタンスを指しているかを確認できます。

<connection-factory location="eis/DB/Connection1" UIConnectionName="Connection1" 
adapterRef="" />

前述の例では、場所は実行時のアダプタ・インスタンスのJNDI名で、UIConnectionNameはJDeveloperで使用されている接続の名前です。

データベース・アダプタ・インスタンスを作成するには、「アダプタ・コネクション・ファクトリの追加」の説明に従ってOracle WebLogic Server管理コンソールを使用するか、weblogic-ra.xmlファイルを直接編集します。次の手順に続く各スクリーンショットは、Oracle WebLogic管理コンソールによるアダプタ・インスタンスの作成方法を示しています。weblogic-ra.xmlを編集する手順は、次のとおりです。

fmwhome/でDbAdapter.rarを検索します。
ファイルを解凍します。
META-INF/weblogic-ra.xml(および、場合によってはra.xml)を編集します。
このファイルから再びJARを作成します。
アプリケーション・サーバーを再起動します。

次の例は、weblogic-ra.xmlのサンプル・アダプタ・インスタンスです。

例 - weblogic-ra.xmlのサンプル・アダプタ・インスタンス

<connection-instance>
  <jndi-name>eis/DB/SOADemo</jndi-name>
    <connection-properties>
       <properties>
          <property>
            <name>xADataSourceName</name>
            <value>jdbc/SOADataSource</value>
              </property>
              <property>
                <name>dataSourceName</name>
                <value> </value>
              </property>
              <property>
                <name>platformClassName</name>
                <value>Oracle10Platform</value>
              </property>
           </properties>
        </connection-properties>
</connection-instance>

4つの必須プロパティは、jndi-name、xADataSourceName、dataSourceNameおよびplatformClassNameです。jndi-nameプロパティは、db.jcaファイル内の場所属性に一致している必要があり、アダプタ・インスタンスの名前を表しています。

xADataSourceNameプロパティは、基礎となるデータソースの名前です(接続情報を含みます)。

platformClassNameは、どのSQLを生成するかを示します。PlatformClassNameの詳細は、表9-13を参照してください。

次の各スクリーンショットは、Oracle WebLogic管理コンソールを使用したデータベース・アダプタのプロパティの編集方法を示しています。

最初のスクリーンショットは、WebLogic管理コンソール内での「アウトバウンド接続プール」へのナビゲーションを示しています。これが実際のデータベース・アダプタ構成ページであり、ここから後続のページに移動してデータベース・アダプタのプロパティを編集できます。

図9-30 WebLogicコンソールの「アウトバウンド接続プール」タブ

「図9-30 WebLogicコンソールの「アウトバウンド接続プール」タブ」の説明

2つ目のスクリーンショットは、必要に応じて編集する、WebLogicコンソールの編集プロパティを示しています。プロパティごとに名前、タイプおよび値が表示されます。

図9-31 Oracle WebLogic管理コンソールのデータベース・アダプタのプロパティ

「図9-31 Oracle WebLogic管理コンソールのデータベース・アダプタのプロパティ」の説明

最も一般的なミス

デプロイメントに関する最も一般的なミスとして、次の2つがあります。

db.jcaファイル内の場所属性に一致するアダプタ・インスタンス・エントリが作成されていません(または、エントリが1つも作成されていません)。
db.jcaファイル内の場所属性にデータソース名を直接設定しています。
Oracle以外のデータベースに接続する際、platformClassNameを変更していません。

後者の場合は、アダプタ・インスタンス名(eis/DB/...)を指定し、このインスタンス名がデータソース・プール(jdbc/...)を指すというように間接的に指定する必要があります。一般的なミスは、このように間接的に指定せず、名前jdbc/...を場所属性に直接指定することです。

データソースの構成

アプリケーション・サーバーの関連データソース構成の詳細は、「JDBCドライバとデータベース接続の構成」を参照してください。Oracleデータソースを構成するときには、必ずthin XAオプションを使用してください。

その他のアダプタ・インスタンス・プロパティ

この項では、xADataSourceName、dataSourceNameおよびplatformClassName以外のデータベース・アダプタ・インスタンスのプロパティについて簡単に説明します。

weblogic-ra.xmlにプロパティを追加するときには、そのプロパティがra.xml(およびDbAdapter.rar)でも宣言されていることを確認する必要があります。例として、weblogic-ra.xmlのxADataSourceNameプロパティに関するra.xmlファイルのコードスニペットを次に示します。

<config-property>
<config-property-name>xADataSourceName </config-property-name>
<config-property-type>java.lang.String</config-property-type>
<config-property-value></config-property-value>
</config-property>

Oracleデータベース・アダプタのインスタンス・プロパティの詳細は、「Oracleデータベース・アダプタのプロパティ」を参照してください。

そこに記載されているプロパティの他に、表9-12に示すプロパティも追加できます。

表9-12 Toplink DatabaseLoginオブジェクトに表示されるOracleデータベース・アダプタのプロパティ

プロパティ名	タイプ
`usesNativeSequencing`	Boolean
`usesSkipLocking`	Boolean
`usesStringBinding`	Boolean
`usesByteArrayBinding`	Boolean
`usesStreamsForBinding`	Boolean
`eventListenerClass`	文字列
`logTopLinkAll`	Boolean
`maxBatchWritingSize`	Integer
`nonRetriableSQLErrorCodes`	文字列
`shouldOptimizeDataConversion`	Boolean
`shouldTrimStrings`	Boolean
`driverClassName`	文字列
`sequencePreallocationSize`	Integer
`tableQualifier`	文字列
`usesBatchWriting`	Boolean

前述のプロパティは、oracle.toplink.sessions.DatabaseLoginオブジェクトに出現します。

DBConnectionFactory JavadocおよびDatabaseLogin Javadocの情報は、「TopLink API Reference」(http://download.oracle.com/docs/cd/B10464_02/web.904/b10491/index.html)を参照してください。

9.5.1 サード・パーティ・データベースを使用したデプロイメント

表9-13は、各データベースとそれらの高度なプロパティ(データベース・プラットフォーム変数)を一覧に示したものです。

platformClassName名は、一覧にあるいずれかの変数に設定してください。platformClassNameの設定は、データベース間で統一されていない高度なデータベース機能(ネイティブ順序付けやストアド・プロシージャなど)を使用している場合には必須です。

たとえば、ストアド・プロシージャをDB2とSQL Serverで実行する場合、DbAdapterは異なるSQLを生成し、送信する必要があります。SQLServerプラットフォームで使用する場合は、次の例を使用してください。

execute <procedure> @<arg1>=? ...

DB2 Platformの場合は次の例を使用してください。

call <procedure>(?, ...)

platformClassName設定は、生成するSQLを示します。ほとんどのデータベースは不均一な機能(つまり、ANSI SQL 92言語仕様のバリアント)を提供するため、platformClassNameを正確に構成するのが最も安全な方法です。デフォルト値はOracle10Platformで、別のデータベース・ベンダーに接続している場合は適切な変数に変更する必要があります。

注意:

パッケージに修飾クラス名を付けることは、名前がorg.eclipse.persistence.platform.databaseで始まっている場合には必要ありません。

表9-13 データベース・プラットフォーム名

データベース	PlatformClassName
Oracle10以上(11gを含む)	`org.eclipse.persistence.platform.database.Oracle10Platform`
Oracle9以上(オプション)	`org.eclipse.persistence.platform.database.Oracle9Platform`
DB2	`org.eclipse.persistence.platform.database.DB2Platform`
DB2 (AS400e上)	`oracle.tip.adapter.db.toplinkext.DB2AS400Platform`
Informix	`org.eclipse.persistence.platform.database.InformixPlatform`
SQLServer	`org.eclipse.persistence.platform.database.SQLServerPlatform`
MySQL	`org.eclipse.persistence.platform.database.MySQLPlatform`
Derby	`org.eclipse.persistence.platform.database.DerbyPlatform`
z/OS上のDB2	`org.eclipse.persistence.platform.database.DB2MainframePlatform`
その他のデータベース	`org.eclipse.persistence.platform.database.DatabasePlatform`

9.6 JDBCドライバとデータベース接続の構成

このリリースでは、Oracle JCAアダプタはOracle WebLogic Serverタイプ4 JDBCドライバを使用する次のサード・パーティ・データベースで動作確認されています。

Microsoft SQL Server 2005および2008 (すべてのSPレベルを含む)
Sybase 15
Informix 11.5
DB2 9.7およびそれ以降のFixPaks
MySQL 5.x以上

注意:

主要なデータベースおよびバージョンのみが動作確認されています。他のデータベースでの作業は、作業用のJDBCドライバが用意されており、コアANSI SQLリレーショナル機能(表やビューに対する作成、読取り、更新および削除(CRUD)の各操作など)に依存している場合、実行可能です。問題の多くは、データベース・メタデータ・イントロスペクションが、必ずしもすべてのJDBCドライバで同じように実装されていないことによって、発生する傾向があります。ただし、動作確認されたデータベース上に一致する表をインポートした後、動作確認されていないデータベースを実行時に参照することができます。動作確認されていないデータベースに関してこの項で説明する情報は、ガイドとしてのみ参照してください。

詳細は、以下のトピックを参照してください。

9.6.1 ネイティブまたはバンドルされたOracle WebLogic Server JDBCドライバを使用したデータベース接続の作成

ネイティブまたはバンドルされたOracle WebLogic Server JDBCドライバを使用している場合にデータベース接続を作成するには、次のようにします。

適切なJDBCドライバJARファイルをインストールしてクラスパスを設定します。
詳細は、「JDBCドライバJARファイルの場所とクラスパスの設定」を参照してください。
「ファイル」メニューの「新規」をクリックします。
「新規ギャラリ」ページが表示されます。
「すべてのテクノロジ」タブで、「一般」カテゴリの「接続」を選択します。
「新規ギャラリ」ページの右側にある「項目」ペインに、確立できる様々な接続のリストが表示されます。
「データベース接続」を選択し、「OK」をクリックします。
「データベース接続の作成」ページが表示されます。
「接続の作成場所」で、「IDE接続」を選択します。
「接続名」フィールドにこの接続の名前を入力します。
例: SQLServer。
「接続タイプ」メニューから適切なドライバを選択します。
資格証明(必要に応じてユーザー名、パスワードおよびロールなど)を入力します。
接続情報を入力します。
たとえば、jdbc:sqlserver://HOST-NAME:PORT;databaseName=DATABASE-NAMEと入力します。

詳細は、次を参照してください。
- 表9-14
- デプロイメント・ディスクリプタ・ファイル(weblogic-ra.xml)のサンプルのエントリ。
「接続のテスト」をクリックします。
正常に接続した場合は、「OK」をクリックします。

9.6.2 サード・パーティJDBCドライバを使用したデータベース接続の作成

サード・パーティJDBCドライバを使用している場合にデータベース接続を作成するには、次のようにします。

適切なJDBCドライバJARファイルをインストールしてクラスパスを設定します。
詳細は、「JDBCドライバJARファイルの場所とクラスパスの設定」を参照してください。
「ファイル」メニューの「新規」をクリックします。
「新規ギャラリ」ページが表示されます。
「すべてのテクノロジ」タブで、「一般」カテゴリの「接続」を選択します。
「新規ギャラリ」ページの右側にある「項目」ペインに、確立できる様々な接続のリストが表示されます。
「データベース接続」を選択し、「OK」をクリックします。
「データベース接続の作成」ページが表示されます。
「接続の作成場所」で、「IDE接続」を選択します。
「接続名」フィールドにこの接続の名前を入力します。
例: SQLServer。
「接続タイプ」から「汎用JDBC」を選択します。
ユーザー名、パスワードおよびロール情報を入力します。
「ドライバ・クラス」で「新規」をクリックします。
「JDBCドライバの登録」ダイアログが表示されます。

「JDBCドライバの登録」ダイアログでステップ10、11および19を実行します。
「ドライバ・クラス」にドライバ名(some.jdbc.Driverなど)を入力します。
例: com.microsoft.sqlserver.jdbc.SQLServerDriver。
「ライブラリ」で「参照」をクリックします。
「ライブラリの選択」ダイアログが表示されます。

「ライブラリの選択」ダイアログでステップ12および18を実行します。
「新規作成」をクリックしてライブラリを作成します。
「ライブラリの作成」ダイアログが表示されます。

「ライブラリの作成」ダイアログでステップ13から17を実行します。
「ライブラリ名」フィールドに名前を入力します。
例: SQL Server JDBC。
「クラスパス」をクリックしてから「エントリの追加」をクリックしてドライバの各JARファイルをクラスパスに追加します。
「パス・エントリの選択」ダイアログが表示されます。
JDBCクラス・ファイルを選択して「選択」をクリックします。
たとえば、「sqljdbc.jar」を選択します。
すべてのクラス・ファイルを「クラスパス」フィールドに追加した後、「OK」をクリックします。
「OK」をクリックして「ライブラリの作成」ダイアログを終了します。
「OK」をクリックして「ライブラリの選択」ダイアログを終了します。
「OK」をクリックして「JDBCドライバの登録」ダイアログを終了します。
「JDBC URL」に接続文字列名を入力して、「次へ」をクリックします。
たとえば、jdbc:sqlserver://HOST-NAME:PORT;databaseName=DATABASE-NAMEと入力します。

詳細は、次を参照してください。
- 表9-14
- デプロイメント・ディスクリプタ・ファイル(weblogic-ra.xml)のサンプルのエントリ。
「接続のテスト」をクリックします。
正常に接続した場合は、「OK」をクリックします。

9.6.3 サード・パーティJDBCドライバおよびデータベース接続情報の概要

表9-14に、一般的なサード・パーティ・データベースの接続情報の概要を示します。

Oracle、IBM DB2、Informix、Sybase、SQLServer、MySQLおよびDerbyのドライバ・ファイルは、SOAインストールにバンドルされます。

Oracleでは、これらのWebLogic Serverドライバ(Oracleドライバ)のこれらのデータベースでの動作を保証しています。DB2/AS400、DB2/ZOS、ProgressDBなど、その他のデータベースについては、適切なネイティブ・ドライバを取得する必要があります。

PlatformClassNameの詳細は、表9-13を参照してください。

詳細は、次を参照してください。

表9-14 (Weblogic Serverコンソールからの)データベース・ドライバの選択

データベース	JDBCドライバ
Microsoft SQL Server	OracleのMS SQL Serverドライバ(タイプ4 XA) OracleのMS SQL Serverドライバ(タイプ4)
Sybase	OracleのSybaseドライバ(タイプ4 XA) OracleのSybaseドライバ(タイプ4)
Informix	OracleのInformixドライバ(タイプ4 XA) OracleのInformixドライバ(タイプ4)
IBM DB2	OracleのDB2ドライバ(タイプ4 XA) OracleのDB2ドライバ(タイプ4)
MySQL	MySQLのドライバ(タイプ4) バージョン: `com.mysql.jdbc.Driver`を使用
Derby	Derbyのドライバ(タイプ4 XA)
DB2/AS400	オンラインのドライバjt400Native.jarをダウンロードして、user_projects/domains/<domain_name>/lib/にコピーします。注意: WLSからのjndiの作成中に`other`オプションを選択します。
DB2/ ZOS	オンラインのドライバ`db2jcc4.jar`、`db2jcc_license_cu.jar`および`db2jcc_license_cisuz.jar`をダウンロードして、`user_projects/domains/<domain_name>/lib/`にコピーします。注意: WebLogic ServerからのJNDIの作成中に`other`オプションを選択します。
ProgressDb	Progressインストールのドライバ`openedge.jar`、`pool.jar`および`schema.jar`を`user_projects/domains/<domain_name>/lib/`にコピーします。注意: WebLogic ServerからのJNDIの作成中に`other`オプションを選択します。

9.6.3.1 Microsoft SQL Serverの使用方法

SQL Serverデータベースに接続する際は次の点に注意する必要があります。

XAトランザクションを有効にするには、次の手順を実行します。

<install_dir>/oracle_common/modules/datadirectのすべてのファイルをMSSQLインストールのProgram Files\Microsoft SQL Server\MSSQL11.MSSQLSERVER\MSSQL\Binnにコピーします。
<Install_dir>/oracle_common/modules/datadirectのinstjdbc.sqlをMSSQLインストール・マシンのcディレクトリ(c:/)などにコピーします。
オペレーティング・システムに基づいて、必要なDLLをSQL Server Binディレクトリにコピーし、名前をsqljdbc.dllに変更します。次に例を示します。
- sqljdbc.dll: 32ビットOSの場合
- 64sqljdbc.dll: Itaniumベースの64ビットOSの場合
- x64sqljdbc.dll: Intelベースの64ビットOSの場合
SQLコマンドラインで次のコマンドを実行します。そのコマンドは、エラーなしで完了する必要があります。
```
sqlcmd -Usa -Pwelcome1! -Slocalhost -iC:\instjdbc.sql
```
SQLサーバー・サービスを再起動します。

XAトランザクションを正常に実行するには、次の手順も実行する必要があります。

「run」→「dcomcnfg」に進みます
その後、「component servies」→「Mycomp」→「DTC」→「LocalDTC」→「Properties」に進みます(「Properties」を右クリック)。
さらに「Security」に進み、「Enable xa transaction」を選択します
最後に、すべての関連サービスを再起動します(trxn、sqlserver)。

9.6.3.2 SQLSERVER Weblogic JDBCドライバの使用方法

URL: jdbc:weblogic:sqlserver://<host>:<port>

ドライバ・クラス: weblogic.jdbcx.sqlserver.SQLServerDataSource

ドライバJar: wlsqlserver.jarはWebLogic Serverにバンドルされており、インストール時に提供されます。

その場所は、/<install_dir>/oracle_common/modules/datadirectです。

9.6.3.3 Sybaseデータベースの使用方法

この項には次のトピックが含まれます:

Sybase JConnect JDBCドライバの使用方法

9.6.3.3.1 Sybase JConnect JDBCドライバの使用方法

URL: jdbc:weblogic:sybase://<host>:<port>

ドライバ・クラス: weblogic.jdbcx.sybase.SybaseDataSource

ドライバJar: wlsybase.jarはWebLogic Serverにバンドルされており、インストール時に提供されます。

その場所は、/<install_dir>/oracle_common/modules/datadirectです。

Sybase JConnect JDBCドライバの詳細は、次のリンクを参照してください。

http://www.sybase.com/products/middleware/jconnectforjdbc

9.6.3.4 Informixデータベースの使用方法

この項には次のトピックが含まれます:

Informix JDBCドライバの使用方法

9.6.3.4.1 Informix JDBCドライバの使用方法

URL: jdbc:weblogic:informix://<host>:<port>;informixServer=<server_name>;databaseName=<db_name>

ドライバ・クラス: weblogic.jdbcx.informix.InformixDataSource

ドライバJar: wlinformix.jarはサーバーにバンドルされており、インストール時に提供されます。その場所は、/<install_dir>/oracle_common/modules/datadirectです。

Informix JDBCドライバの詳細は、次のリンクを参照してください。

http://www-01.ibm.com/software/data/informix/tools/jdbc/

9.6.3.5 IBM DB2データベースの使用方法

この項には次のトピックが含まれます:

9.6.3.5.1 IBM DB2ドライバ

URL: jdbc:weblogic:db2://<host>:<port>ドライバ・クラス: weblogic.jdbcx.db2.DB2DataSourceDriver Jar: wldb2.jarはサーバーでバンドルされています。インストールとともに提供されます。場所: /<install_dir>/oracle_common/modules/datadirect

DataDirectドライバについては、次のリンクを参照してください。

http://www.datadirect.com/techres/jdbcproddoc/index.ssp

9.6.3.5.2 JT400ドライバ(AS400 DB2)

URL: jdbc:as400://hostname;translate binary=true

ドライバ・クラス: com.ibm.as400.access.AS400JDBCDriver/

com.ibm.as400.access.AS400JDBCXADataSource

ドライバJar: jt400.jar/jt400Native.jar

キャラクタ・セットを適切に変換するには、translate binary=trueを使用します。

9.6.3.5.3 IBM Universalドライバ

(ZOS)

URL: jdbc:db2://hostname:port/schemaname

ドライバ・クラス: weblogic.jdbcx.db2.DB2DataSource

ドライバJar: wldb2.jarはサーバー内でバンドルされています。インストールとともに提供されます。場所: /<install_dir>/oracle_common/modules/datadirect

9.6.3.6 MySQLデータベースの使用方法

次の情報を使用します。

URL: jdbc:mysql://hostname:3306/dbname

ドライバ・クラス: com.mysql.jdbc.Driver / com.mysql.jdbc.jdbc2.optional.MysqlXADataSource

ドライバJar: mysql-connector-java-<version_number>-bin.jar

9.6.3.7 Derbyデータベースの使用方法

次の情報を使用します。

URL: jdbc:derby://<host>:<port><location of schema>

ドライバ・クラス: org.apache.derby.jdbc.ClientXADataSource

ドライバJar: Derby.jar, derbyclient.jar

9.6.3.8 Progressデータベースの使用方法

次の情報を使用します。

URL: jdbc:datadirect:openedge://<host>:<port>;databaseName=<dbname>

ドライバ・クラス: com.ddtek.jdbc.openedge.OpenEdgeDriver

ドライバJar: openedge.jar, pool.jar, schema.jar

9.6.4 JDBCドライバJARファイルの場所とクラスパスの設定

この項では、JDBC JARファイルの場所と、実行時および設計時のクラスパスの設定について説明します。

実行時

WindowsとLinuxの場合は、どちらも次の手順を実行する必要があります。

ベンダー固有のドライバJARファイルをuser_projects/domains/soainfra/libディレクトリに移動します。
ベンダー固有のドライバJARファイルを<Weblogic_Home>/server/libに移動します。
クラスパスを編集し、ベンダー固有のjarファイルを<Weblogic_HOME>/common/bin/commEnv.shに含めます

設計時

WindowsとLinuxの場合は、どちらもJDBC JARをOracle/Middleware/jdeveloper/jdev/lib/patchesディレクトリに移動します。

9.7 ストアド・プロシージャおよびファンクションのサポート

この項では、Oracleデータベース・アダプタで、ストアド・プロシージャとファンクションの使用がどのようにサポートされているかについて説明します。

この項には次のトピックが含まれます:

9.7.1 設計時: アダプタ構成ウィザードの使用

「アダプタ構成ウィザード - ストアド・プロシージャ」は、アダプタ・サービスWSDLおよび必要なXSDの生成に使用されます。アダプタ・サービスWSDLは、基礎となるストアド・プロシージャまたはファンクションをWSIF JCAバインディングのあるWebサービスとしてカプセル化します。XSDファイルには、すべてのパラメータおよびそのタイプを含む、プロシージャまたはファンクションが記述されています。このXSDには、実行時にOracleデータベース・アダプタに発行されるインスタンスXMLの作成に使用される定義が指定されています。

この項には次のトピックが含まれます:

9.7.1.1 最上位のスタンドアロンAPIの使用

この項では、PL/SQLパッケージに定義されていないAPIを持つアダプタ構成ウィザードの使用方法を説明します。「アダプタ構成ウィザード - ストアド・プロシージャ」を使用し、プロシージャまたはファンクションを選択してXSDファイルを生成します。アダプタ構成ウィザードの起動方法については、Oracleデータベース・アダプタの使用例を参照してください。

アダプタ構成ウィザードを使用してストアド・プロシージャまたはファンクションを選択するには、次の手順を実行します。

「サービス・アダプタ」リストから「データベース・アダプタ」を「composite.xml」ページの「公開されたサービス」スイムレーンにドラッグ・アンド・ドロップします。
図9-32に示すように、アダプタ構成ウィザードが表示されます。

図9-32 アダプタ構成ウィザード

「図9-32 アダプタ構成ウィザード」の説明
「次」を選択します。図9-33に示すように、「サービス名」ページが表示されます。
注意:
データベースまたはユーザー定義データ型を参照するストアド・プロシージャまたはパッケージの名前には、文字$を使用できないことに注意してください。名前に$が含まれていると、XSDファイルの生成に失敗します。

図9-33 サービス名の指定

「図9-33 サービス名の指定」の説明
「サービス名」フィールドにサービス名を入力し、「次へ」をクリックします。「サービス接続」ページが表示されます。
図9-34に示すように、接続をサービスに関連付けます。アダプタ・サービスを構成するにはデータベース接続が必要です。リストから既存の接続を選択するか、新規の接続を作成してください。

図9-34 アダプタ構成ウィザードにおけるデータベース接続の設定

「図9-34 アダプタ構成ウィザードにおけるデータベース接続の設定」の説明
「次」を選択します。「操作タイプ」ページが表示されます。
図9-35に示すように、「操作タイプ」に「ストアド・プロシージャまたはファンクションの呼出し」を選択します。
図9-35 アダプタ構成ウィザードにおけるストアド・プロシージャまたはファンクションの呼出し

「図9-35 アダプタ構成ウィザードにおけるストアド・プロシージャまたはファンクションの呼出し」の説明
「次」を選択します。図9-36に示すように、「ストアド・プロシージャの指定」ページが表示されます。このページで、ストアド・プロシージャまたはファンクションを指定します。
図9-36 「ストアド・プロシージャの指定」ページ

「図9-36 「ストアド・プロシージャの指定」ページ」の説明
次に、スキーマと、プロシージャまたはファンクションを選択します。リストからスキーマを選択するか、「<デフォルト・スキーマ>」を選択します。この場合、接続に関連付けられているスキーマが使用されます。プロシージャ名がわかっている場合は、「プロシージャ」フィールドに入力します。プロシージャがパッケージ内に定義されている場合は、EMPLOYEE.GET_NAMEのようにパッケージ名を含める必要があります。
スキーマ名およびプロシージャ名が不明である場合は、「参照」をクリックして、図9-37に示すように、「ストアド・プロシージャ」ウィンドウにアクセスします。

図9-37 プロシージャまたはファンクションの検索

「図9-37 プロシージャまたはファンクションの検索」の説明

リストからスキーマを選択するか、「<デフォルト・スキーマ>」を選択します。使用可能なプロシージャのリストが左側のウィンドウに表示されます。APIの長いリストから特定のAPIを検索するには、「検索」フィールドに検索基準を入力します。たとえば、XXで始まるすべてのAPIを検索するには、XX%と入力し「検索」ボタンをクリックします。「すべて表示」ボタンをクリックすると、使用可能なすべてのAPIが表示されます。

図9-38に、FACTORIALファンクションの選択方法を示します。「引数」タブには、ファンクションのパラメータが表示されます。表示されるパラメータは、名前、型、モード(IN、IN/OUTまたはOUT)およびプロシージャの定義におけるパラメータの数値位置です。ファンクションの戻り値は、名前がなく、常に位置がゼロ(0)のOUTパラメータです。

図9-38 選択したプロシージャの引数の表示

「図9-38 選択したプロシージャの引数の表示」の説明

図9-39に、ファンクションを実装するコードが「ソース」タブでどのように表示されるかを示します。ファンクション名に一致するテキストが強調表示されています。

図9-39 選択したプロシージャのソース・コードの表示

「図9-39 選択したプロシージャのソース・コードの表示」の説明
ストアド・プロシージャまたはファンクションを選択して、「OK」をクリックします。図9-40に示すように、APIに関する情報が表示されます。修正するには、「戻る」または「参照」をクリックします。
図9-40 アダプタ構成ウィザードにおけるプロシージャまたはファンクションの詳細の表示

「図9-40 アダプタ構成ウィザードにおけるプロシージャまたはファンクションの詳細の表示」の説明
「次」を選択します。ストアド・プロシージャまたはファンクションに、行セット・タイプの出力パラメータ(Oracle DatabaseではREF CURSOR)が含まれる場合、図9-41に示すように、このREF CURSORに対して強い型指定のXSDまたは弱い型指定のXSDを定義できます。
図9-41 アダプタ構成ウィザードにおけるプロシージャまたはファンクションの詳細の表示: 行セット・タイプの場合

「図9-41 アダプタ構成ウィザードにおけるプロシージャまたはファンクションの詳細の表示: 行セット・タイプの場合」の説明

詳細は、次を参照してください。
- 強い型指定のXSDを使用した行セットのサポート
- 弱い型指定のXSDを使用した行セットのサポート
「次」を選択します。図9-42に示すように、「詳細オプション」ページが表示されます。JDBCの「問合せタイムアウト」の値など、任意の詳細オプションを入力します。その他のオプションとしては、再試行回数や再試行間隔などの再試行パラメータがあります。
図9-42 「詳細オプション」ページ

「図9-42 「詳細オプション」ページ」の説明
すべてのオプションを指定した後、「次へ」をクリックし、「終了」をクリックしてアダプタ構成ウィザードを終了します。
アダプタ構成ウィザードの使用が終了すると、次の3つのファイルが既存のプロジェクトに追加されます。
- servicename.wsdl (Factorial.wsdlなど)
- service_name_db.jca (Factorial_db.jcaなど)
- schema_package_procedurename.xsd (SCOTT_FACTORIAL.xsdなど)

9.7.1.2 パッケージ化されたAPIの使用およびオーバーロード

パッケージで定義されたAPIの使用は、スタンドアロンAPIの使用と似ています。唯一の違いは、図9-43に示すように、パッケージ名を開いて、パッケージに定義されているすべてのAPIのリストを参照できることです。

同じ名前でパラメータが異なるAPIは、オーバーロードされたAPIと呼ばれます。図9-43に示すように、PACKAGEというパッケージには、OVERLOADというオーバーロードされたプロシージャが2つあります。

図9-43 オーバーロードされたプロシージャが2つあるパッケージ

「図9-43 オーバーロードされたプロシージャが2つあるパッケージ」の説明

図9-44に示すように、「ソース」タブを参照する際にはパッケージのどのAPIが選択されているかにかかわらず、PL/SQLパッケージ全体のコードが表示されます。プロシージャ名に一致するテキストが強調表示されています。

図9-44 オーバーロードされたプロシージャのソース・コードの表示

「図9-44 オーバーロードされたプロシージャのソース・コードの表示」の説明

プロシージャまたはファンクションを選択して「OK」をクリックすると、図9-45に示すように、APIの情報が表示されます。スキーマ、プロシージャ名およびパラメータのリストが表示されます。プロシージャ名がパッケージ名でどのように修飾されているかに注意してください(PACKAGE.OVERLOAD)。「戻る」または「参照」をクリックして修正するか、「次へ」をクリックします。任意の詳細オプションの値を入力します。「次へ」をクリックし、「終了」をクリックして終了します。

図9-45 アダプタ構成ウィザードにおけるプロシージャまたはファンクションの詳細の表示

「図9-45 アダプタ構成ウィザードにおけるプロシージャまたはファンクションの詳細の表示」の説明

アダプタ構成ウィザードの使用が終了すると、次のファイルが既存のプロジェクトに追加されます。

Overload.wsdl、Overload_db.jca
SCOTT_PACKAGE_OVERLOAD_2.xsd

XSDファイル名ではプロシージャ名の後に_2が追加され、オーバーロードされたAPIと区別されています。数値索引は、オーバーロードされたAPIをそれぞれ区別するために使用されます。

9.7.2 サポートされるサード・パーティ・データベース

ストアド・プロシージャの場合、Oracle、DB2、Informix Dynamic Server、MySQL、Microsoft SQL ServerおよびSybase Adaptive Server Enterpriseのデータベースがサポートされています。認証されている特定のバージョンについては、サポートに問い合せてください。特定のバージョンがここに記載されているバージョンよりも新しい場合、そのバージョンがサポートされている可能性があります。

サード・パーティJDBCおよびデータベースに対するOracle JCAアダプタのサポートの詳細は、「JDBCドライバとデータベース接続の構成」を参照してください。

この項には次のトピックが含まれます:

9.7.2.1 使用される用語

ProductName

これはデータベースの名前です。

データベース名	サポート対象データベース
IBM DB2	IBM DB2 v 10.1
Microsoft SQL Server	SQLServer 2012
MySQL	MySQL v5.6*

DriverClassName

これはJDBCドライバ・クラスの名前です。

データベース名	JDBCドライバ
IBM DB2	`weblogic.jdbcx.db2.DB2DataSource`
Microsoft SQL Server	`weblogic.jdbcx.sqlserver.SQLServerDataSource`
MySQL	`com.mysql.jdbc.Driver` / `com.mysql.jdbc.jdbc2.optional.MysqlXADataSource`

ConnectionString

これはJDBC接続URLです。

データベース名	接続文字列
IBM DB2	`jdbc:weblogic:db2://<host>:<port>`
Microsoft SQL Server	`jdbc:weblogic:sqlserver://<host>:<port>`
MySQL	`jdbc:mysql://host:port/database-name`

Username

データベース・ユーザー名です。

Password

ユーザー名に関連付けられているパスワードです。

ProcedureName

ストアド・プロシージャ名またはファンクション名です。

ServiceName

必要な操作のサービス名です。

DatabaseConnection

接続のJNDI名です。たとえば、eis/DB/<DatabaseConnection>です。

Destination

これは、生成されるファイルの接続先ディレクトリです。たとえば、C:\Tempなどです。

Parameters

ストアド・プロシージャのパラメータです(バージョン5.2.6より前のMySQLのみ)。

QueryTimeout

JDBC問合せタイムアウト値(秒単位)です。QueryTimeoutプロパティは、JDBCドライバが、指定されたストアド・プロシージャまたはファンクションの実行を待機する最大秒数を指定します。しきい値に達すると、SQLExceptionがスローされます。値が0の場合は、ドライバは無期限で待機します。

9.7.2.2 重要な注意点

アダプタ構成ウィザードでは、Oracle Database、IBM DB2、AS/400、DB2/ZOS、Microsoft SQL Server、Sybase 15.7、Informix 11.7+、Progress Db 10およびMySQL v5.6以上がサポートされます。

この項には次のトピックが含まれます:

9.7.2.2.1 Microsoft SQL Server

表9-15に、SQL Serverのストアド・プロシージャおよびファンクションでサポートされるデータ型を示します。

表9-15 SQL Serverのストアド・プロシージャおよびファンクションのデータ型

SQLデータ型	XMLスキーマ型
`BIGINT`	`long`
`BINARY` `IMAGE` `TIMESTAMP` `VARBINARY`	`base64Binary`
`BIT`	`boolean`
`CHAR` `SQL_VARIANT` `SYSNAME` `TEXT` `UNIQUEIDENTIFIER` `VARCHAR` `XML (2005のみ)`	`string`
`DATETIME` `SMALLDATETIME`	`dateTime`
`DECIMAL` `MONEY` `NUMERIC` `SMALLMONEY`	`decimal`
`FLOAT` `REAL`	`float`
`INT`	`int`
`SMALLINT`	`short`
`TINYINT`	`unsignedByte`

9.7.2.2.2 DB2のデータ型

表9-16に、DB2 SQLのストアド・プロシージャでサポートされるデータ型を示します。

表9-16 DB2 SQLのストアド・プロシージャのデータ型

SQLデータ型	XMLスキーマ型
`BIGINT`	`long`
`BLOB` `CHAR` `FOR` `BIT` `DATA` `VARCHAR` `FOR` `BIT` `DATA`	`base64Binary`
`CHARACTER` `CLOB` `VARCHAR`	`string`
`DATE` `TIME` `TIMESTAMP`	`dateTime`
`DECIMAL`	`decimal`
`DOUBLE`	`double`
`INTEGER`	`int`
`REAL`	`float`
`SMALLINT`	`short`

他のデータ型の名前も暗黙的にサポートされています。たとえば、NUMERICは(DECおよびNUMと同様に)DECIMALに相当します。

IBM DB2は、構造化されたデータ型(ユーザー定義)をサポートしています。ただし、JDBCドライバではこれらの型に対するサポートがありません。したがって、構造化されたデータ型をストアド・プロシージャのパラメータのデータ型として使用することはできません。IBM DB2では、ユーザー定義ファンクションもサポートしています。ただし、アダプタではこれらのファンクションがサポートされません。

アダプタ構成ウィザードではストアド・プロシージャはデータベース・ユーザーごとにグループ化されます。IBM DB2のスキーマは、Oracleのスキーマと同等のものです。どちらも、データベース・ユーザーの名前を表します。

IBM DB2の場合、<Default Schema>は現在のデータベース・ユーザーを指します。

別のデータベース・ユーザーを選択するには、「<デフォルト・スキーマ>」をクリックします。「参照」ページには、JDBC接続URLの<database>で指定されたデータベースにデータベース・ユーザーが作成したストアド・プロシージャが表示されます。

アダプタ構成ウィザードでは、別のデータベースへの変更はサポートされていません。

図9-46に示すように、「ストアド・プロシージャ」ダイアログでストアド・プロシージャを選択します。引数は「引数」タブに表示されます。指定のデータベース内でユーザーが作成したデータベース・ストアド・プロシージャを検索するには、「検索」をクリックします。たとえば、d%とD%のどちらによってもDEMOストアド・プロシージャが検索されます。「すべて表示」をクリックすると、指定のデータベース内で現在のユーザーが作成したすべてのストアド・プロシージャが表示されます。

図9-46 「ストアド・プロシージャ」ダイアログ

「図9-46 「ストアド・プロシージャ」ダイアログ」の説明

図9-47に示すように、「ソース」タブをクリックすると、ストアド・プロシージャのソース・コードを表示できます。

図9-47 ストアド・プロシージャのソース・コード

「図9-47 ストアド・プロシージャのソース・コード」の説明

9.7.2.2.3 IBM DB2 AS/400

表9-17に、IBM DB2 AS/400のストアド・プロシージャでサポートされるデータ型を示します。

表9-17 IBM DB2 AS/400のストアド・プロシージャのデータ型

SQLデータ型	XMLスキーマ型
`BINARY` `BINARY LARGE OBJECT` `BINARY VARYING`	`base64Binary`
`CHARACTER` `CHARACTER LARGE OBJECT` `CHARACTER VARYING`	`string`
`DATE` `TIME` `TIMESTAMP`	`dateTime`
`DECIMAL` `NUMERIC`	`decimal`
`DOUBLE PRECISION`	`double`
`BIGINT`	`long`
`INTEGER`	`int`
`REAL`	`float`
`SMALLINT`	`short`

個別データ型も、CREATE DISTINCT TYPE文を使用して作成されるデータ型でサポートされています。これらのデータ型は、IBM DB2の場合と同様の振舞いをします。

IBM DB2 AS/400の実装は、QSYS2スキーマのカタログ表からの問合せをベースにしています。アダプタで、QSYS2.SCHEMATA表が存在するかどうかが確認されます。存在する場合は、アダプタ構成ウィザードでQSYS2スキーマの表に問合せが行われます。したがって、IBM DB2 AS/400データベースでQSYS2スキーマがサポートされている場合は、アダプタ構成ウィザードとアダプタ・ランタイムの両方が機能します。

アダプタ構成ウィザードでは、最初にSYSCATスキーマがチェックされ、次にQSYS2スキーマがチェックされます。アダプタでは、SYSIBMスキーマのカタログ表はサポートされていません。

9.7.2.3 データベース接続の作成

アダプタ構成ウィザードを機能させるために必要なカタログ表にアクセスするには、JDeveloperでデータベース接続を作成する必要があります。

JDeveloperを使用してデータベース接続を作成する手順は、次のとおりです。

「表示」から「データベース・ナビゲータ」を選択します。
アプリケーション名を右クリックして「新規」と「接続」を順番にクリックします。「データベース接続」を選択します。

図9-48に示すように、「データベース接続の作成」ページが表示されます。

図9-48 データベース接続の作成

「図9-48 データベース接続の作成」の説明
「接続名」フィールドに接続名を入力します。例: sqlserver。
「接続タイプ」リストから、「接続タイプ」として「汎用JDBC」を選択します。
「ユーザー名」、「パスワード」およびロール情報を入力します。
「ドライバ・クラス」で「新規」をクリックします。図9-49に示すように、「JDBCドライバの登録」ダイアログが表示されます。

図9-49 「JDBCドライバの登録」ダイアログ

「図9-49 「JDBCドライバの登録」ダイアログ」の説明
ドライバ・クラスを入力します(たとえば、com.microsoft.sqlserver.jdbc.SQLServerDriver)。
次の手順に従って、ライブラリを作成するか、既存のライブラリを編集します。
1. 「JDBCドライバの登録」ダイアログで「参照」をクリックします。
2. 「ライブラリの選択」ダイアログで「新規」をクリックします。
  
  図9-50に示すように、「ライブラリの選択」ダイアログが表示されます。
  
  図9-50 「ライブラリの選択」ダイアログ
  
  「図9-50 「ライブラリの選択」ダイアログ」の説明
3. 既存のライブラリを選択するか、「新規」をクリックしてライブラリを作成します。
  
  「ライブラリの作成」ダイアログが表示されます。
4. ライブラリ名を入力します。たとえば、SQL Server JDBCと入力します。
5. 「エントリの追加」をクリックして、JDBC JARファイルをクラスパスに追加します。
6. 「OK」を2回クリックして「ライブラリの作成」ウィンドウを終了します。
7. 「OK」をクリックして「JDBCドライバの登録」ウィンドウを終了します。
「JDBC URL」に接続文字列名を入力します。
「接続のテスト」をクリックします。
接続が成功すると、図9-51に示す画面が表示されます。

図9-51 「データベース接続の作成」ダイアログ

「図9-51 データベース接続の作成」の説明
「OK」をクリックし、「終了」をクリックします。

9.7.3 設計時: 成果物の生成

「アダプタ構成ウィザード - ストアド・プロシージャ」では、ストアド・プロシージャまたはファンクションのシグネチャを説明するWSDLファイルおよび有効なXSDファイルを作成できます。次の項では、WSDLファイルとXSDファイル両方の関連する構造およびコンテンツと、それぞれのリレーションシップを説明します。

この項には次のトピックが含まれます:

9.7.3.1 WSDLとXSDのリレーションシップ

後続の段落では、前述の例で引用された操作名Factorialおよびプロシージャ名Factorialを使用します(図9-40を参照)。生成されたWSDLにより、XSDファイルがインポートされます。

<types>
  <schema xmlns="http://www.w3.org/2001/XMLSchema">
    <import namespace="http://xmlns.oracle.com/pcbpel/adapter/db/SCOTT/FACTORIAL/"
      schemaLocation="xsd/SCOTT_FACTORIAL.xsd"/>
  </schema>
</types>

ネームスペースはスキーマ、パッケージおよびプロシージャ名から導出され、生成されたXSDではtargetNamespaceと表示されます。

InputParametersというルート要素が、ストアド・プロシージャのINおよびIN/OUTパラメータに対応する要素を指定するためにXSDファイルに作成されます。OutputParametersという別のルート要素も、IN/OUTまたはOUTパラメータがある場合にのみ、要素を指定するためにXSDファイルに作成されます。IN/OUTパラメータはどちらのルート要素にも出現します。

これらのルート要素は、XSDファイルでは無名のcomplexType定義として表現されます。定義の順序には、各パラメータの要素が1つ含まれます。INパラメータもIN/OUTパラメータもない場合は、InputParametersルート要素が作成されますが、complexTypeは空になります。XSDファイルのコメントで、そのようなパラメータはないことが示されます。ルート要素の例を次に示します。

<element name="InputParameters"
  <complexType>
    <sequence>
      <element …>
       …
    </sequence>
  </complexType>
</element>

WSDLでは、パートがこれら2つのルート要素によって定義されるメッセージ・タイプが定義されます。

<message name="args_in_msg"
  <part name="InputParameters" element="InputParameters"/>
</message>
<message name="args_out_msg"
  <part name="OutputParameters" element="OutputParameters"/>
</message>

dbネームスペースは、生成されたXSDのtargetNamespaceと同じです。args_out_msgはXSDファイルでOutputParametersルート要素が生成された場合にのみ含まれるのに対し、args_in_msgメッセージ・タイプは、常にWSDLに含まれます。

操作はWSDLで定義されます。このWSDLは、アダプタ・サービスと同じ名前で、入力および出力メッセージがこれら2つのメッセージ・タイプに関して定義されます。

<portType name="Factorial_ptt">
  <operation name="Factorial">
    <input message="tns:args_in_msg"/>
    <output message="tns:args_out_msg"/>
  </operation>
</portType>

出力メッセージはXSDファイルでのOutputParametersルート要素の存在に依存しますが、入力メッセージは常に表示されます。tnsネームスペースは操作名から導出され、WSDLで次のように定義されます。

xmlns:tns="http://xmlns.oracle.com/pcbpel/adapter/db/Factorial/"

XSDファイルのルート要素は、メッセージで使用されるパートの構造を定義します。このメッセージは、WSDLでカプセル化されたWebサービスで送受信されます。

WSDLの入力メッセージは、XSDファイルのInputParametersルート要素に対応します。インスタンスXMLは、ストアド・プロシージャのINおよびIN/OUTパラメータの値を提供します。出力メッセージは、OutputParametersルート要素に対応します。これは、ストアド・プロシージャが実行された後に生成されるXMLファイルです。任意のIN/OUTおよびOUTパラメータの値が保持されます。

9.7.3.2 JCAファイル

JCAファイルは、サービス用のアダプタ構成情報を提供します。コネクション・ファクトリが指定されているため、次の例に示すようにアダプタ・ランタイムがデータベースに接続できます。JCAファイルで管理対象外の接続プロパティを直接指定しないでください。かわりに、アプリケーション・サーバー上にコネクション・ファクトリを作成し、JCAファイルで名前を指定して参照します(<connection-factory location)。

<connection-factory location="eis/DB/oracle" UIConnectionName="oracle"
adapterRef="">
</connection-factory>

JNDI名eis/DB/oracleをアダプタ構成ウィザードでサービス接続として指定しています。

相互作用のエンドポイント・プロパティも指定されます。次の例に示すように、スキーマ、パッケージおよびプロシージャの名前が指定されます。操作名により、JCAファイルがサービスWSDLに関連付けられます。

<connection-factory location="eis/db/oracle" UIConnectionName="oracle" 
adapterRef=""/>
<endpoint-interaction portType="Factorial_ptt" operation="Factorial">
  <interaction-spec
    className="oracle.tip.adapter.db.DBStoredProcedureInteractionSpec">
      <property name="ProcedureName" value="FACTORIAL"/>
      <property name="GetActiveUnitOfWork="false"/>
  </interaction-spec>
  </output>
</endpoint-interaction>

操作名とプロシージャ名に注意してください。明示的なスキーマが選択されている場合、またはパッケージ内でプロシージャが定義されている場合は、これらのプロパティの値もここに示されます。

注意:

JDeveloperを通常モードで起動すると、管理対象外の接続の詳細はDBAdapter.jcaファイルに作成されません。ただし、JDeveloperをプレビュー・モードで起動すると、管理対象外の接続の詳細がDBAdapter.jcaファイルに作成されます。

9.7.3.3 Oracleのデータ型

多くのプリミティブ・データ型には、詳細に定義されたマッピングが用意されているため、設計時および実行時のコンポーネントのどちらでもサポートされています。また、VARRAY、ネストされた表およびOBJECTなどのユーザー定義タイプを使用できます。

表9-18に、Oracleのストアド・プロシージャおよびファンクションでサポートされるデータ型を示します。

表9-18 Oracleのストアド・プロシージャおよびファンクションのデータ型

SQLまたはPL/SQLタイプ	XMLスキーマ型
`BINARY_DOUBLE` `DOUBLE PRECISION`	`double`
`BINARY_FLOAT` `FLOAT` `REAL`	`float`
`BINARY_INTEGER` `INTEGER` `PLS_INTEGER` `SMALLINT`	`int`
`BLOB` `LONG RAW` `RAW`	`base64Binary`
`CHAR` `CLOB` `LONG` `STRING` `VARCHAR2`	`string`
`DATE` `TIMESTAMP` `TIMESTAMPWITHTIMEZONE`	`dateTime`
`DECIMAL` `NUMBER`	`decimal`

9.7.3.4 生成されたXSD属性

表9-19に、生成されたXSDで使用される属性をリスト表示します。

表9-19 生成されたXSD属性

属性	例	意味
`name`	`name="param"`	要素の名前
`type`	`type="string"`	XMLスキーマ型
`db:type`	`db:type="VARCHAR2"`	SQLまたはPL/SQLタイプ
`db:index`	`db:index="1"`	パラメータの位置
`db:default`	`db:default="true"`	デフォルト句がある場合
`minOccurs`	`minOccurs="0"`	最小発生数
`maxOccurs`	`maxOccurs="1"`	最大発生数
`nillable`	`nillable="true"`	NULL値の許可

dbネームスペースは、実行中に使用される属性と標準のXMLスキーマ属性の区別に使用されます。db:type属性は、データベース・タイプの特定に使用されるため、実行時に適切なJDBCタイプ・マッピングを取得できます。db:index属性は、設計時および実行時のコンポーネントの両方で最適化として使用され、パラメータが適切な順序に配置されていることを確認できます。パラメータ索引は、プロシージャでは1から、ファンクションでは0から開始されます。ファンクションの戻り値は、nameがファンクションの名前で、db:indexが0のOutputParameter要素として表現されます。db:default属性は、パラメータにデフォルト句があるかどうかを特定するために使用されます。

minOccurs値は、XMLファイルからのINパラメータの削除を可能にするために0に設定されます。これは、パラメータにパラメータの値を定義するデフォルト句(X IN INTEGER DEFAULT 0など)がある場合に便利です。実行時にXMLファイルのパラメータに要素が指定されていない場合、そのパラメータはストアド・プロシージャの起動から除外されるため、デフォルト値の使用が可能になります。各パラメータを、ストアド・プロシージャまたはファンクションの起動に使用できるのは最大で一度です。そのため、デフォルト値が常に1のmaxOccursは、パラメータを表す要素から常に除外されます。

nillable属性は、インスタンスXMLの対応する要素にNULL値(<X/>または<X></X>など)を許可するために、常にtrueに設定されています。ただし、NULL値のあるこのような要素を渡すには、(<X xsi:nil="true"/>のように)明示的に宣言する必要がある場合があります。nillable属性に使用されるネームスペースxsiは、インスタンスXMLに(xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"のように)明示的に宣言する必要があります。

9.7.3.5 ユーザー定義タイプ

アダプタ構成ウィザードでも、コレクション(VARRAYおよびネストされた表)およびOBJECTなどのユーザー定義タイプに有効な定義を生成できます。XSDファイルではcomplexType定義として作成されます。

VARRAYの場合、complexType定義によりその順序内にname_ITEMという単一の要素が定義されます。ここでnameはVARRAY要素の名前です。XMLファイルのすべての配列要素でそのように名前が付けられます。次のようなVARRAYタイプ定義があるとします。

SQL> CREATE TYPE FOO AS VARRAY (5) OF VARCHAR2 (10);

タイプがFOOのVARRAY要素Xの場合、次のようなcomplexTypeが生成されます。

<complexType name="FOO">
  <sequence>
    <element name="X_ITEM" db:type="VARCHAR2" 
               minOccurs="0" maxOccurs="5" 
nillable="true"/>
      <simpleType>
        <restriction base="string">
          <maxLength value="10"/>
        </restriction>
      </simpleType>
  </sequence>
</complexType>

空のコレクションを許可するため、minOccurs値は0です。maxOccurs値は、コレクションで保持できる最大のアイテム数に設定されます。db:index属性は使用されていません。nillableをtrueに設定すると、VARRAYの個々のアイテムでNULL値を使用できます。

VARRAYの要素FOOで指定されている制限の使用に注意してください。これは、VARRAY(またはネストされた表)の宣言で長さがわかる、CHARおよびVARCHAR2などのタイプに使用されます。要素のタイプや最大長が指定されます。指定された長さを超える要素値は、スキーマ検証中にインスタンスXMLが停止する原因になります。

タイプFOOとして宣言されたパラメータの属性値は、生成されたXSDでは次のようになります。

<element name="X" type="db:FOO" db:type="Array" db:index="1"
          minOccurs="0" 
nillable="true"/>

typeおよびdb:typeの値は、パラメータがXSDファイルでFOOというcomplexTypeによって定義済の配列として表現されていることを示します。db:indexの値は、ストアド・プロシージャにおけるそのパラメータの位置です。

ネストされた表は、VARRAYとほぼ同じように処理されます。次にネストされた表のタイプ定義を示します。

SQL> CREATE TYPE FOO AS TABLE OF VARCHAR2 (10);

これは、その順序に単一の要素を含む、name_ITEMというcomplexTypeとしても生成されます。ネストされた表が任意のサイズであるためバインドされていないmaxOccurs値を除き、その要素にはVARRAYの例と同じ属性があります。

<complexType name="FOO">
  <sequence>
    <element name="X_ITEM" … maxOccurs="unbounded" nillable="true">
      …
    </element>
  </sequence>
</complexType>

VARRAYのX_ITEM要素には同じ制限が生成されます。このタイプとして宣言されたXパラメータの属性は、VARRAYの例と同じです。

PL/SQLパッケージ仕様の内側で定義されたcollections (Varrayおよびネストした表)はサポートされません。次に例を示します。

SQL> create package pkg as
   >   type vary is varray(10) of number;
   >   type ntbl is table of varchar2(100;
   >   procedure test(v in vary, n in ntbl);
   > end;
   > /

ユーザーがアダプタ構成ウィザードでストアド・プロシージャについてtestプロシージャを選択すると、そのタイプがサポートされていないことを示すエラーが発生します。ただし、パッケージ外部のルート・レベルでvaryおよびntblタイプ定義が定義されている場合は、testプロシージャを選択しても問題なく動作します。次の例に、コレクション・タイプ(Varrayおよびネストした表)についてサポートされている使用方法を示します。

SQL> create type vary as varray(10) of number;
SQL> create type ntbl as table of varchar2(10);
SQL> create package pkg as
   >   procedure test(v in vary, n in ntbl);
   > end;
   /

OBJECT定義もcomplexTypeとして生成されます。その順序には、OBJECTの各属性に1つの要素が保持されています。

次にOBJECTを示します。

SQL> CREATE TYPE FOO AS OBJECT (X VARCHAR2 (10), Y NUMBER);

これは、順序要素が2つあるFOOというcomplexType定義として表現されています。

<complexType name="FOO">
  <sequence>
    <element name="X" db:type="VARCHAR2" minOccurs="0"
                             nillable="true"/>
      <simpleType>
        <restriction base="string">
          <maxLength value="10"/>
        </restriction>
      </simpleType>
    <element name="Y" type="decimal" db:type="NUMBER" 
                    minOccurs="0"
nillable="true"/>
  </sequence>
</complexType>

XMLファイルからの要素の削除を許可するため、minOccurs値は0です。これにより、OBJECTの対応する属性の値が実行時にNULLに設定されます。XMLファイルに空の要素を許可するためnillable値はtrueであり、要素の値がNULLであることを示すためにxsi:nil属性で注釈が付けられています。ここでも、db:index属性は使用されていません。

VARCHAR2属性の制限の使用に注意してください。OBJECTの属性の宣言から長さがわかります。

9.7.3.6 複雑なユーザー定義タイプ

ユーザー定義タイプは、必要に応じて複雑に定義できます。OBJECTには、前述の任意のユーザー定義タイプとして定義されているタイプの属性を含めることができます。OBJECTの属性のタイプが別のOBJECT、VARRAYまたはネストされた表などになります。VARRAYまたはネストされた表のベース・タイプも、OBJECTになる可能性があります。コレクションのベース・タイプが別のコレクションになることを許可することで、多次元のコレクションがサポートされます。

9.7.3.7 オブジェクト・タイプの継承

アダプタ構成ウィザードでは、OBJECTタイプの継承を使用してタイプが定義されているパラメータの有効なXSDを生成できます。次のようなタイプの階層があるとします。

SQL> CREATE TYPE A AS OBJECT (A1 NUMBER, A2 VARCHAR2 (10)) NOT FINAL;
SQL> CREATE TYPE B UNDER A (B1 VARCHAR2 (10));

また、プロシージャにはタイプがBのパラメータXが含まれるとします。

SQL> CREATE PROCEDURE P (X IN B) AS BEGIN … END;

アダプタ構成ウィザードでは、パラメータXにInputParameters要素が次のように生成されます。

<element name="X" type="db:B" db:index="1" db:type="Struct" 
     minOccurs="0" 
nillable="true"/>

ここで、XSDファイルのOBJECTタイプBの定義は、次に示すcomplexTypeとして生成されます。

<complexType name="B">
  <sequence>
    <element name="A1" type="decimal" db:type="NUMBER" minOccurs="0" 
nillable="true"/>
    <element name="A2" db:type="VARCHAR2" minOccurs="0"  nillable="true">
      ...
    </element>
    <element name="B1" db:type="VARCHAR2" minOccurs="0"  nillable="true">
      ...
    </element>
  </sequence>
</complexType>

属性A2およびB1の最大長の制限が適切に追加されています。OBJECTタイプの階層が、階層全体のすべての属性に対応する要素の単一の順序にフラット化されていることに注意してください。

9.7.3.8 オブジェクト参照

アダプタ構成ウィザードでは、OBJECTタイプへの参照(オブジェクト参照など)であるパラメータや、定義にオブジェクト参照が含まれるユーザー定義タイプのパラメータの有効なXSDも生成できます。次に例を示します。

SQL> CREATE TYPE FOO AS OBJECT (…);
SQL> CREATE TYPE BAR AS OBJECT (F REF FOO, …);
SQL> CREATE PROCEDURE PROC (X OUT BAR, Y OUT REF FOO) AS BEGIN … END;

アダプタ構成ウィザードでは、FOOおよびBARのcomplexType定義が前述したように生成されます。ただし、BARでは、属性の要素Fは次のように生成されます。

<element name="F" type="db:FOO" db:type="Ref" minOccurs="0" nillable="true"/>

ここで、typeおよびdb:type属性値は、FがOBJECTタイプFOOへの参照であることを示します。

プロシージャPROCでは、XSDファイルのOutputParametersルート要素に次の要素が生成されます。

<element name="X" type="db:BAR" db:index="1" db:type="Struct" minOccurs="0" 
nillable="true"/>
<element name="Y" type="db:FOO" db:index="2" db:type="Ref" minOccurs="0" 
nillable="true"/>

Yでは、db:type属性の値がRefになっています。type属性とともに、要素定義ではYがFOOへの参照であることが示されています。

オブジェクト参照の使用には、パラメータ・モードがOUTのみに限られる制限があります。直接的なREFのAPI、またはパラメータ・タイプがユーザー定義の場合はそのタイプの定義にREFが含まれているAPIに、INまたはIN/OUTパラメータを渡すことはできません。

9.7.3.9 別のスキーマのタイプの参照

アクセスに必要な権限が付与されている場合には、別のスキーマに定義されているタイプを参照できます。たとえば、SCHEMA1でタイプOBJが宣言されたとします。

SQL> CREATE TYPE OBJ AS OBJECT (…);

SCHEMA2で宣言されているストアド・プロシージャのパラメータ・タイプを、SCHEMA1のタイプOBJにすることも可能です。

CREATE PROCEDURE PROC (O IN SCHEMA1.OBJ) AS BEGIN … END;

これは、SCHEMA1によりSCHEMA2にタイプOBJにアクセスする権限が付与された場合にのみ可能です。

SQL> GRANT EXECUTE ON OBJ TO SCHEMA2;

必要な権限が付与されていない場合には、SCHEMA2にプロシージャPROCの作成を試行するとエラーが発生します。

PLS-00201: identifier "SCHEMA1.OBJ" must be declared

権限が付与されていないので、SCHEMA1のOBJ型はSCHEMA2からは見えません。したがって、SCHEMA2はパラメータOの宣言においてこれを参照することはできません。

9.7.3.10 XSDプルーニングの最適化

一部のユーザー定義オブジェクト・タイプは、多数の属性を持つ場合があります。これらの属性は、同じく多数の属性を持つ他のオブジェクト・タイプによって定義することもできます。つまり、あるオブジェクト・タイプが、その定義の深さと複雑度によっては極端に大きくなる場合があります。

状況によっては、ラージ・オブジェクト・タイプの多数の属性が不要な場合もあります。これらの属性をオブジェクトのスキーマ定義から省略することが望ましい場合があります。そのためには、オブジェクト・タイプの定義から不要なXSD要素を物理的に削除します。

次の例では、ストアド・プロシージャが複雑なユーザー定義型のパラメータを持っています。

SQL> CREATE TYPE OBJ AS OBJECT (A, NUMBER, B <SqlType>, C <SqlType>, ...);
SQL> CREATE PROCEDURE PROC (O OBJ) AS BEGIN ... END;

InputParametersルート要素には、APIのシグネチャからのパラメータOの単一要素が含まれます。complexType定義は、次のコード・スニペットに示すようにオブジェクト・タイプの生成XSDに追加されます。

<complexType name="OBJ">
  <sequence>
    <element name="A" type="decimal" db:type="NUMBER" minOccurs="0"  
nillable="true"/>
    <element name="B" .../>
    <element name="C" .../>
    ...
  </sequence>
</complexType>

属性BおよびCが不要な場合は、OBJのcomplexType定義から対応する要素をタイプに関係なく削除できます。これらの属性の値は、インスタンスXMLでは不要です。パラメータOが出力パラメータだった場合、プルーニングされた属性に対応する要素も生成XMLでは省略されます。

パラメータAのタイプがユーザー定義オブジェクト・タイプでもあり、次の例に示すようにOBJの定義がそれに従って変更されたとします。

SQL> CREATE TYPE FOO AS OBJECT (X NUMBER, Y NUMBER, Z NUMBER);
SQL> CREATE TYPE OBJ AS OBJECT (A FOO, B <SqlType>, C <SqlType, ...);

その場合、APIに変更はありません。FOOの定義内で不要な属性に対応する要素も、そのタイプに関係なく削除できます。そのため、たとえばYが不要であれば、FOOのcomplexType定義内で対応する要素をXSDファイルから削除できます。

この方法でXSDファイルをプルーニングすると、アダプタの実行時パフォーマンスが向上し、メモリー使用量も大幅に削減できます。

注意:

プルーニングできるのは、ユーザー定義オブジェクト・タイプの属性のみです。対応する要素をInputParametersルート要素から削除することでストアド・プロシージャのパラメータをプルーニング(削除)することはできません。対応する要素を削除すると、パラメータにデフォルト句がない場合は実行時エラーになる可能性があります。

9.7.4 実行時: ストアド・プロシージャの起動前

この項では、ストアド・プロシージャのサポートに関する重要事項と、ストアド・プロシージャまたはファンクションの起動前に発生する動作に関する重要事項の概要を説明します。

この項には次のトピックが含まれます:

9.7.4.1 値のバインディング

XMLファイルからの値の抽出と、それらの値が実行時にどのように作用するかを検討します。タイプがサポートされているプリミティブ・データ型であるパラメータ値に対応するXMLファイルのデータの場合、次の状況が想定されます。

要素の値が指定されています(<X>100</X>など、この例ではX=100)。
要素の値が指定されていません(<X/>など、この例ではX=NULL)。
値がNULLとして明示的に指定されています(<X xsi:nil="true"/>など、この例ではX=NULL)。
要素がXMLファイルで指定されていません(X = <default value>など)。

注意:

Microsoft SQL ServerとIBM DB2、MySQLおよびAS/400には、顕著な違いが1つあります。SQL Serverでは、ストアド・プロシージャの定義にデフォルト値を含めることのできるパラメータがサポートされています。IBM DB2、MySQLおよびAS/400ではパラメータのデフォルトがサポートされていないため、すべてのパラメータはインスタンスXMLで要素として表現する必要があります。

1つ目のケースでは、値はXMLファイルからそのまま取得され、タイプに応じて適切なオブジェクトに変換されます。そのオブジェクトは、ストアド・プロシージャ起動の準備中に、対応するパラメータにバインドされます。

2つ目と3つ目のケースでは、XMLファイルから抽出された実際の値はNULLです。タイプ・コンバータではNULLが許容され、変換されずに返されます。NULL値はタイプにかかわらず対応するパラメータにバインドされます。基本的に、これはパラメータXにNULLを渡すのと同じです。

4つ目のケースには2つの可能性があります。パラメータにデフォルト句がある場合とない場合です。パラメータにデフォルト句がある場合、そのパラメータをストアド・プロシージャの起動から除外できます。これにより、パラメータにデフォルト値が使用されます。パラメータを指定した場合は、かわりにそのパラメータの値が使用されます。パラメータにデフォルト句がない場合は、プロシージャの起動にパラメータを追加指定する必要があります。ファンクションのすべてのパラメータの要素を指定する必要があります。インスタンスXMLの要素に欠落がある場合、ファンクションは予想よりも少数の引数を使用して起動されます。

NULL値はデフォルトでパラメータにバインドされます。

SQL> CREATE PROCEDURE PROC (X IN INTEGER DEFAULT 0) AS BEGIN … END;

ここでは、パラメータにバインドされる値はありません。実際に、パラメータはストアド・プロシージャの起動から除外できます。これにより、0値がパラメータXのデフォルトに設定されます。

内容をまとめるため、次のPL/SQLが3つのケースのそれぞれで実行されたとします。

"BEGIN PROC (X=>?); END;" - X = 100
"BEGIN PROC (X=>?); END;" - X = null
2つの可能性があります。
1. "BEGIN PROC (); END;" - X = 0 (Xにはデフォルト句がある)
2. "BEGIN PROC (X=>?); END;" - X = null (Xにはデフォルト句がない)

デフォルト句の処理を例外として、これらの一般的なセマンティクスは、コレクションのアイテム値、またはタイプがサポートされているプリミティブ・データ型であるOBJECTの属性値にも適用されます。ただし、タイプがユーザー定義の場合、<X/>のセマンティクスは大きく異なります。

コレクションの場合、次のタイプ定義だと仮定すると、VARRAYまたはネストされた表のいずれでも、後続の動作が予測されます。

SQL> CREATE TYPE ARRAY AS VARRAY (5) OF VARCHAR2 (10);

また、タイプがARRAYのパラメータXのXMLは次のようになります。

<X>
    <X_ITEM xsi:nil="true"/>
    <X_ITEM>Hello</X_ITEM>
    <X_ITEM xsi:nil="true"/>
    <X_ITEM>World</X_ITEM>
</X>

VARRAYの1つ目と3つ目の要素はNULLに設定されています。2つ目と4つ目には、それぞれの値が割り当てられています。XMLファイルでは5つ目の要素が指定されていないため、VARRAYインスタンスにある要素は4つのみです。

次のようなOBJECT定義であると仮定します。

SQL> CREATE TYPE OBJ AS OBJECT (A INTEGER, B INTEGER, C INTEGER);

また、タイプがOBJのパラメータXのXMLは次のようになります。

<X>
    <A>100</A>
    <C xsi:nil="true"/>
</X>

値100が属性Aに、NULLが属性BおよびCに割り当てられています。属性BのインスタンスXMLには要素がないため、NULL値が割り当てられています。

2つ目のケースでは、Xのタイプがユーザー定義の場合、<X/>の動作は異なります。XにNULLが割り当てられるのではなく、ユーザー定義タイプの初期化されたインスタンスが作成されてバインドされます。

前述のVARRAYの例では、<X/>または<X></X>が指定されている場合、Xにバインドされる値はVARRAYの空のインスタンスです。PL/SQLで、タイプ・コンストラクタを呼び出してXに値を割り当てるのと同等です。例:

X := ARRAY();

同様に、前述のOBJECTの例では、属性値すべてにNULLが割り当てられているOBJの初期化されたインスタンスは、Xにバインドされます。VARRAYのケースと同様に、タイプ・コンストラクタの呼出しと同等です。例:

X := OBJ(NULL, NULL, NULL);

Xのタイプがユーザー定義の場合にXに明示的にNULL値を割り当てるには、次のようにしてXMLファイルの要素にxsi:nil属性を追加します。

<X xsi:nil="true"/>

9.7.4.2 データ型の変換

この項では、CLOB、DATE、TIMESTAMPなどのデータ型、RAW、LONG RAW、BLOBなどのバイナリ・データ型、およびサード・パーティ・データベースでサポートされている類似のデータ型の変換について説明します。

Microsoft SQL Server、IBM DB2、AS/400およびMySQLでは、様々な書式のバイナリおよび日付データ型をストアド・プロシージャのパラメータにバインドする操作がサポートされています。これを表9-20にまとめます。

表9-20 サード・パーティ・データベース: バイナリ値および日付値とストアド・プロシージャのパラメータとのバインディング

XMLスキーマ型 IBM DB2のデータ型 AS/400のデータ型 Microsoft SQL Server Serverデータ型 MySQLデータ型

XMLスキーマ型	IBM DB2のデータ型	AS/400のデータ型	Microsoft SQL Server Serverデータ型	MySQLデータ型
`base64Binary`	`BLOB` `CHAR` `FOR BIT DATA` `VARCHAR` `FOR BIT DATA`	`BINARY` `BINARY LARGE OBJECT` `BINARY VARYING`	`BINARY` `IMAGE` `TIMESTAMP` `VARBINARY`	`BINARY` `TINYBLOB` `BLOB` `MEDIUMBLOB` `LONGBLOB` `VARBINARY`
`dateTime`	`DATE` `TIME` `TIMESTAMP`	`DATE` `TIME` `TIMESTAMP`	`DATETIME` `SMALLDATETIME`	`DATE` `DATETIME` `TIMESTAMP`

base64Binary

BLOB

CHAR FOR BIT DATA

VARCHAR FOR BIT DATA

BINARY

BINARY LARGE OBJECT

BINARY VARYING

BINARY

IMAGE

TIMESTAMP

VARBINARY

BINARY

TINYBLOB

BLOB

MEDIUMBLOB

LONGBLOB

VARBINARY

dateTime

DATE

TIME

TIMESTAMP

DATE

TIME

TIMESTAMP

DATETIME

SMALLDATETIME

DATE

DATETIME

TIMESTAMP

CLOBパラメータについては、CLOBパラメータの長さが4KB未満の場合、XMLファイルから抽出されたテキストが追加の処理なしでString型としてこのパラメータにバインドされます。CLOBパラメータの長さが4KBより大きい場合、またはこのパラメータのモードがIN/OUTの場合は、一時CLOBパラメータが作成されます。その後、CLOBが対応するパラメータにバインドされる前に、XMLファイルのデータが一時CLOBに書き込まれます。一時CLOBパラメータは相互作用が完了すると解放されます。CHARおよびVARCHAR2など、その他のキャラクタ・タイプの場合には、データが必要に応じて抽出されてバインドされます。XMLドキュメントはCLOBパラメータ(または、十分な大きさの場合にはVARCHAR2)にバインドできます。ただし、まず<、>などを適切に置き換える必要があります(たとえば、<は<に、>は>に)。

値を対応するパラメータにバインドする前に、特別な処理を必要とするデータ型がいくつかあります。たとえば、XMLスキーマ型base64BinaryおよびdateTimeで表されるデータ型などです。

XMLスキーマ型dateTimeは、TIME、DATEおよびTIMESTAMPを表しています。これらのデータ型のXML値はdateTimeのXMLスキーマ表現に準拠する必要があります。そのため、単純なDATE文字列01-JAN-05は無効です。XMLスキーマでは、dateTimeはYYYY-MM-DDTHH:mm:ssとして定義されます。そのため、適切なDATE値は2005-01-01T00:00:00です。これらのパラメータの値は、この書式を使用してインスタンスXML内で指定する必要があります。

バイナリ・データ型のデータは、人間が理解できる方法で表現する必要があります。バイナリ・データの選択されたXMLスキーマ表現はbase64Binaryです。タイプ・コンバータでは、javax.mail.internet.MimeUtilityエンコードおよびデコードAPIを使用してバイナリ・データが処理されます。エンコードAPIは、すべてのバイナリ・データのbase64Binary形式へのエンコードに使用する必要があるため、XMLファイルでも使用できます。タイプ・コンバータでは、XMLデータのバイト配列へのデコードにデコードAPIが使用されます。base64Binaryデータのバイト配列への変換には、デコードAPIが使用されます。

BLOBパラメータについては、デコード値を含む長さが2KB未満である場合、バイト配列は追加の処理なしでそのパラメータにバインドされます。バイト配列の長さが2KBより大きい場合、またはパラメータのモードがIN/OUTの場合は、一時BLOBが作成されます。バイト配列はその後、対応するパラメータにバインドされる前に、BLOBに書き込まれます。一時BLOBは相互作用が完了すると解放されます。その他のバイナリ・データ型(RAWやLONG RAWなど)については、base64Binaryデータはバイト配列へとデコードされ、必要に応じてバインドされます。

その他のデータ型の変換は簡単なため、追加情報は必要ありません。

9.7.5 実行時: ストアド・プロシージャの起動後

プロシージャ(またはファンクション)を実行すると、任意のIN/OUTおよびOUTパラメータの値が取得されます。これらは、生成されたXSDのOutputParametersルート要素の要素値に対応します。

この項には次のトピックが含まれます:

9.7.5.1 データ型の変換

取得されたデータの変換は簡単です。ただし、CLOB(および他の文字データ)、RAW、LONG RAWおよびBLOBの変換と、サード・パーティ・データベースでサポートされている類似のデータ型の変換には特別な注意が必要です。

CLOBが取得されると、そのCLOBのコンテンツ全体が生成されたXMLの対応する要素に書き込まれます。標準のDOM APIを使用してXMLファイルが構成されます。したがって、CLOB、CHARおよびVARCHAR2などのタイプに関しては、値が有効であり後続の処理でXMLファイルに使用できるようにするため、必要に応じて文字データが伝達され、必要な置換えが行われます。そのため、たとえば、CLOBで保存されたXMLドキュメントの<および>の置換えが行われ、関連するパラメータの生成されたXML内の要素に使用された値は有効になります。

RAWおよびLONG RAWデータ型などのRAWデータは、バイト配列として取得されます。BLOBの場合、まずBLOBが取得され、そのコンテンツはバイト配列として取得されます。バイト配列は、javax.mail.internet.MimeUtilityエンコードAPIを使用してbase64Binary形式にエンコードされます。エンコードされた値は、すべて対応する要素のXMLファイルに配置されます。この値をバイト配列にデコードするには、MimeUtilityデコードAPIを使用する必要があります。

その他のデータ型の変換は簡単なため、追加情報は必要ありません。

9.7.5.2 NULL値

値がNULLの要素は、生成されたXMLでは空の要素として表示され、xsi:nil属性で注釈が付けられます。したがって、生成されるXMLファイルではxsiネームスペースが宣言されます。単一のOUTパラメータXがあり、値がNULLのプロシージャPROCの生成されたXMLは次のようになります。

<OutputParameters … xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <X xsi:nil="true"/>
</OutputParameters>

任意のタイプ(ユーザー定義タイプも含む)のパラメータのXML要素は、値がNULLの場合にはこのように表示されます。

9.7.5.3 ファンクションの戻り値

ファンクションの戻り値は、nameがファンクション自体の名前で、位置が0のOUTパラメータとして処理されます。例:

CREATE FUNCTION FACTORIAL (X IN INTEGER) RETURN INTEGER AS
BEGIN
    IF (X <= 0) THEN RETURN 1;
    ELSE RETURN FACTORIAL (X - 1);
    END IF;
END;

たとえば、値が5のこのファンクションの起動は、値が120になり、生成されたXMLのOutputParametersルート要素では<FACTORIAL>120</FACTORIAL>と表示されます。

9.7.6 実行時: サード・パーティ・データベースの共通機能

実行時のサード・パーティ・データベースの共通機能は、次のとおりです。

9.7.6.1 ResultSetsの処理

すべてのサード・パーティ・データベースは、ResultSetsの処理について同じ機能を共有しています。ResultSetを戻すAPIのSQL Serverの例を次に示します。

 1> create procedure foo ... as select ... from ...;
 2> go

生成されたXSDで定義されているRowSetはResultSetを表します。RowSetは、それぞれ1列以上を含む0(ゼロ)行以上で構成されます。行は問合せで戻される行に対応します。列は問合せの列項目に対応します。次の例に、前述の例に示したAPIの実行後に生成されたXMLを示します。

<RowSet>
  <Row>
    <Column name="<column name>" sqltype="<sql datatype">value</Column>
    ...
  </Row>
    ...
</RowSet>
…

name属性には問合せに表示される列の名前が格納されますが、sqltype属性にはその列のSQLデータ型(INTなど)が格納されます。valueは、その列の値となります。

APIでは複数のResultSetsが戻される場合があります。その場合、RowSetは生成されたXML内のResultSetごとに1つずつとなります。生成されたXMLでは、すべてのRowSetsが常に先頭に表示されます。

9.7.6.2 INTEGERステータス値の戻し

一部のデータベースでは、ストアド・プロシージャでRETURN文を使用してINTEGERステータス値を戻すことができます。Microsoft SQL ServerとAS/400は、両方ともこの機能をサポートしています。いずれの場合も、アダプタ構成ウィザードでは、ストアド・プロシージャがステータス値を戻すかどうかを決定できません。このため、ストアド・プロシージャが値を戻すことを指定する必要があります。これはチェック・ボックスを使用して指定できます。

「ストアド・プロシージャ」ダイアログでストアド・プロシージャを選択すると、図9-52に示す「ストアド・プロシージャの指定」ページが表示されます。前述のチェック・ボックスはページの下部にあります。このチェック・ボックスを選択して、プロシージャにRETURN文を含めることを指定します。RETURN文が存在するかどうかを確認するには、プロシージャのソース・コードを表示します。

このチェック・ボックスは、この機能をサポートするデータベースのストアド・プロシージャに対してのみ表示されます。ファンクションに対しては、このチェック・ボックスは表示されません。ストアド・プロシージャによって戻された値は、生成されたXSDのOutputParametersルート要素内の要素として表示されます。要素の名前は、ストアド・プロシージャの名前になります。このチェック・ボックスを選択しない場合は、return文の値がストアド・プロシージャの実行後に消失します。

図9-52 「ストアド・プロシージャの指定」ページ

「図9-52 「ストアド・プロシージャの指定」ページ」の説明

9.7.7 高度なトピック

この項では、Oracleデータベース・アダプタで提供されているストアド・プロシージャ機能を使用して、直接にはサポートされていないタイプのシナリオについて説明します。次の各項では、これらのデータ型を使用する必要がある場合に取り組む解決策を説明します。

9.7.7.1 強い型指定のXSDを使用した行セットのサポート

REF CURSORはどのような結果セットもサポートできるため、設計時に生成されるXSDは弱い型指定となります。

行セットはすべての結果セットを表現できますが、一部のプロシージャについては、結果セットの構造が毎回同じであることが想定できるため、強い型指定のXSDを使用して記述することも可能です。一般的に、後で結果セットを別のXSDに変換する場合は、強い型指定のXSDが必要となります。アダプタ構成ウィザードを使用して、REF CURSORに対して強い型指定のXSDを生成できます。

使用例において、弱い型指定のXSDで十分である場合は、「弱い型指定のXSDを使用した行セットのサポート」を参照してください。

この項には次のトピックが含まれます:

詳細は、「強い型指定のXSDまたは弱い型指定のXSDを使用した行セットのサポート」を参照してください。

9.7.7.1.1 設計時

選択したストアド・プロシージャまたはファンクションに、タイプがRowSetの出力パラメータが含まれる場合、このREF CURSORに対して強い型指定のXSDを次のように定義できます。

アダプタ構成ウィザードを使用して、タイプがRowSetの出力パラメータを含むストアド・プロシージャまたはファンクションを選択します。

「最上位のスタンドアロンAPIの使用」のステップ1から8を参照してください。

「Next」をクリックします。図9-53に示すように、「RowSets」ページが表示されます。

デフォルトで、アダプタ構成ウィザードでは、「XSD」テキスト・フィールドに表示されるこのREF CURSORのための、弱い型指定のXSDが生成されます。次の例は、このデフォルトの弱い型指定のXSDを示しています。

図9-53 「RowSets」ページ

「図9-53 「RowSets」ページ」の説明

例 - デフォルトの弱い型指定のXSD

<schema targetNamespace="http://xmlns.oracle.com/pcbpel/adapter/db/SYS/MOVIES_
CURSORS/MOVIES_QUERY/" xmlns="http://www.w3.org/2001/XMLSchema" 
xmlns:db="http://xmlns.oracle.com/pcbpel/adapter/db/SYS/MOVIES_CURSORS/MOVIES_QUERY/" 
elementFormDefault="qualified">
   <element name="InputParameters">
      <complexType>
         <sequence>
            <element name="EXAMPLE" type="db:SYS.MOVIESOBJ" db:index="1" db:type="Struct" 
minOccurs="0" nillable="true"/>
         </sequence>
      </complexType>
   </element>
   <element name="OutputParameters">
      <complexType>
         <sequence>
            <element name="MOVIES" type="db:RowSet" db:index="2" db:type="RowSet" 
minOccurs="0" nillable="true"/>
         </sequence>
      </complexType>
   </element>
   <complexType name="RowSet">
      <sequence>
         <element name="Row" minOccurs="0" maxOccurs="unbounded">
            <complexType>
               <sequence>
                  <element name="Column" maxOccurs="unbounded" nillable="true">
                     <complexType>
                        <simpleContent>
                           <extension base="string">
                              <attribute name="name" type="string" use="required"/>
                              <attribute name="sqltype" type="string" use="required"/>
                           </extension>
                        </simpleContent>
                     </complexType>
                  </element>
               </sequence>
            </complexType>
         </element>
      </sequence>
   </complexType>
   <complexType name="SYS.MOVIESOBJ">
      <sequence>
         <element name="TITLE" db:type="VARCHAR2" minOccurs="0" nillable="true">
            <simpleType>
               <restriction base="string">
                  <maxLength value="30"/>
               </restriction>
            </simpleType>
         </element>
         <element name="DIRECTOR" db:type="VARCHAR2" minOccurs="0" nillable="true">
            <simpleType>
               <restriction base="string">
                  <maxLength value="30"/>
               </restriction>
            </simpleType>
         </element>
         <element name="STARRING" db:type="VARCHAR2" minOccurs="0" nillable="true">
            <simpleType>
               <restriction base="string">
                  <maxLength value="30"/>
               </restriction>
            </simpleType>
         </element>
      </sequence>
   </complexType>
</schema>

ストアド・プロシージャまたはファンクションの各引数に対して、次の手順を実行します。
- 対応する「値」の列をダブルクリックします。
- 引数の値を入力します。
  
  数値や文字列を直接入力したり、日付をリテラルとして(2009/11/11など)入力したり、MYOBJ('a', 'b')のような構造体を入力します。
- [Enter]を押します。
注意:
引数のタイプに対して有効であり、かつデータベース内に存在する値を選択する必要があります。

適切なストアド・プロシージャまたはファンクションのシグネチャが確実に実行されるようにするために、すべての引数に対して値を指定することをお薦めします。

「イントロスペクト」をクリックします。

アダプタ構成ウィザードによって、指定した引数を使用するストアド・プロシージャまたはファンクションが実行されます。

ストアド・プロシージャまたはファンクションによって少なくとも1行を含む行セットが返される場合、「RowSets」ページが更新され、「XSD」テキスト・フィールドに強い型指定のXSDが表示されます。次の例に、前の例に示されているデフォルトの弱い型指定のXSDを置換する、強い型指定のXSDを示します。

図9-54 「RowSets」ページ: 正常なイントロスペクション

「図9-54 「RowSets」ページ: 正常なイントロスペクション」の説明

例 - 強い型指定のXSD

<schema targetNamespace="http://xmlns.oracle.com/pcbpel/adapter/db/SYS/MOVIES_
CURSORS/MOVIES_QUERY/" xmlns="http://www.w3.org/2001/XMLSchema" 
xmlns:db="http://xmlns.oracle.com/pcbpel/adapter/db/SYS/MOVIES_CURSORS/MOVIES_
QUERY/" elementFormDefault="qualified">
   <element name="InputParameters">
      <complexType>
         <sequence>
            <element name="EXAMPLE" type="db:SYS.MOVIESOBJ" db:index="1" 
db:type="Struct" minOccurs="0" nillable="true"/>
         </sequence>
      </complexType>
   </element>
   <element name="OutputParameters">
      <complexType>
         <sequence>
            <element name="MOVIES" type="db:MOVIES_RowSet" db:index="2" 
db:type="RowSet" minOccurs="0" nillable="true"/>
         </sequence>
      </complexType>
   </element>
   <complexType name="MOVIES_RowSet">
      <sequence>
         <element name="MOVIES_Row" minOccurs="0" maxOccurs="unbounded">
            <complexType>
               <sequence>
                  <element name="TITLE" db:type="VARCHAR2" minOccurs="0" 
nillable="true">
                     <simpleType>
                        <restriction base="string">
                           <maxLength value="50"/>
                        </restriction>
                     </simpleType>
                  </element>
                  <element name="DIRECTOR" db:type="VARCHAR2" minOccurs="0" 
nillable="true">
                     <simpleType>
                        <restriction base="string">
                           <maxLength value="20"/>
                        </restriction>
                     </simpleType>
                  </element>
                  <element name="STARRING" db:type="VARCHAR2" minOccurs="0" 
nillable="true">
                     <simpleType>
                        <restriction base="string">
                           <maxLength value="100"/>
                        </restriction>
                     </simpleType>
                  </element>
                  <element name="SYNOPSIS" db:type="VARCHAR2" minOccurs="0" 
nillable="true">
                     <simpleType>
                        <restriction base="string">
                           <maxLength value="255"/>
                        </restriction>
                     </simpleType>
                  </element>
                  <element name="GENRE" db:type="VARCHAR2" minOccurs="0" 
nillable="true">
                     <simpleType>
                        <restriction base="string">
                           <maxLength value="70"/>
                        </restriction>
                     </simpleType>
                  </element>
                  <element name="RUN_TIME" type="decimal" db:type="NUMBER" 
minOccurs="0" nillable="true"/>
                  <element name="RELEASE_DATE" type="dateTime" db:type="DATE" 
minOccurs="0" nillable="true"/>
                  <element name="RATED" db:type="VARCHAR2" minOccurs="0" 
nillable="true">
                     <simpleType>
                        <restriction base="string">
                           <maxLength value="6"/>
                        </restriction>
                     </simpleType>
                  </element>
                  <element name="RATING" db:type="VARCHAR2" minOccurs="0" 
nillable="true">
                     <simpleType>
                        <restriction base="string">
                           <maxLength value="4"/>
                        </restriction>
                     </simpleType>
                  </element>
                  <element name="VIEWER_RATING" db:type="VARCHAR2" minOccurs="0" 
nillable="true">
                     <simpleType>
                        <restriction base="string">
                           <maxLength value="5"/>
                        </restriction>
                     </simpleType>
                  </element>
                  <element name="STATUS" db:type="VARCHAR2" minOccurs="0" 
nillable="true">
                     <simpleType>
                        <restriction base="string">
                           <maxLength value="11"/>
                        </restriction>
                     </simpleType>
                  </element>
                  <element name="TOTAL_GROSS" type="decimal" db:type="NUMBER" 
minOccurs="0" nillable="true"/>
                  <element name="DELETED" db:type="VARCHAR2" minOccurs="0" 
nillable="true">
                     <simpleType>
                        <restriction base="string">
                           <maxLength value="5"/>
                        </restriction>
                     </simpleType>
                  </element>
                  <element name="SEQUENCENO" type="decimal" db:type="NUMBER" 
minOccurs="0" nillable="true"/>
                  <element name="LAST_UPDATED" type="dateTime" db:type="DATE" 
minOccurs="0" nillable="true"/>
                  <element name="POLLING_STRATEGY" db:type="VARCHAR2" 
minOccurs="0" nillable="true">
                     <simpleType>
                        <restriction base="string">
                           <maxLength value="30"/>
                        </restriction>
                     </simpleType>
                  </element>
               </sequence>
            </complexType>
         </element>
      </sequence>
   </complexType>
   <complexType name="SYS.MOVIESOBJ">
      <sequence>
         <element name="TITLE" db:type="VARCHAR2" minOccurs="0" nillable="true">
            <simpleType>
               <restriction base="string">
                  <maxLength value="30"/>
               </restriction>
            </simpleType>
         </element>
         <element name="DIRECTOR" db:type="VARCHAR2" minOccurs="0" 
nillable="true">
            <simpleType>
               <restriction base="string">
                  <maxLength value="30"/>
               </restriction>
            </simpleType>
         </element>
         <element name="STARRING" db:type="VARCHAR2" minOccurs="0" 
nillable="true">
            <simpleType>
               <restriction base="string">
                  <maxLength value="30"/>
               </restriction>
            </simpleType>
         </element>
      </sequence>
   </complexType>
</schema>

ステップ5に進みます。

行が返されない場合、図9-55に示すように、「イントロスペクトに失敗しました」ダイアログが表示されます。

図9-55 「イントロスペクトに失敗しました」ダイアログ

「図9-55 「イントロスペクトに失敗しました」ダイアログ」の説明

アダプタ構成ウィザードでは、弱い型指定のXSDが生成され、デフォルトで「XSD」テキスト・フィールドに表示され、前のバージョンのXSDに対して行ったすべての編集が上書きされます。

ステップ3に戻り、少なくとも1行を含む行セットを返すテスト引数値を入力します。
ストアド・プロシージャまたはファンクションによって例外がスローされると、図9-56に示すように、イントロスペクション・エラー・ダイアログが表示されます。

図9-56 イントロスペクション・エラー・ダイアログ

「図9-56 「イントロスペクション・エラー・ダイアログ」の説明

アダプタ構成ウィザードでは、弱い型指定のXSDが生成され、デフォルトで「XSD」テキスト・フィールドに表示され、前のバージョンのXSDに対して行ったすべての編集が上書きされます。

ステップ3に戻り、少なくとも1行を含む行セットを返すテスト引数値を入力します。

必要に応じて、「XSD」テキスト・フィールドに表示されるスキーマを手動で編集することによって、強い型指定のXSDを微調整します。
「最上位のスタンドアロンAPIの使用」のステップ10に進みます。

9.7.7.1.2 実行時

次のパッケージがあるとします。

CREATE PACKAGE PKG AS
       TYPE REF_CURSOR IS REF CURSOR;
       PROCEDURE TEST(C OUT REF_CURSOR);
END;

CREATE PACKAGE BODY PKG AS
       ROCEDURE TEST(C OUT REF_CURSOR) AS
       BEGIN
           OPEN C FOR SELECT DEPTNO, DNAME FROM DEPT;
       END;
END;

アダプタ構成ウィザードを使用して強い型指定のXSDを定義し、プロシージャを実行した後、パラメータCについて次のXMLが生成されます。

<C>
    <C_Row>
        <DEPTNO>10</DEPTNO>
        <DNAME>ACCOUNTING</DNAME>
    </C_Row>
    <C_Row>
        <DEPTNO>11</DEPTNO>
        <DNAME>DEVELOPMENT</DNAME>
    </C_Row>
    …
</C>

実行時にOracleデータベース・アダプタを使用する場合、強い型指定のREF CURSORを記述するXSDがインライン化されるかインポートされるかは問題ではありません。

強い型指定のXSDがSOAランタイムによって適用され、Oracle Enterprise Managerコンソールの適切な場所に表示されます。たとえば、図9-57に、強い型指定のXSDを使用したREF CURSORペイロードを返すinvokeの監査証跡を示します。

図9-57 強い型指定のペイロードの監査証跡

「図9-57 強い型指定のペイロードの監査証跡」の説明

9.7.7.2 弱い型指定のXSDを使用した行セットのサポート

REF CURSORはどのような結果セットもサポートできるため、設計時に生成されるXSDは弱い型指定となります。デフォルトでは、アダプタ構成ウィザードによってREF CURSORに対して弱い型指定のXSDが生成されます。

行セットはすべての結果セットを表現できますが、一部のプロシージャについては、結果セットの構造が毎回同じであることが想定できるため、強い型指定のXSDを使用して記述することも可能です。一般的に、後で結果セットを別のXSDに変換する場合は、強い型指定のXSDが必要となります。

使用例において、強い型指定のXSDがより適している場合は、「強い型指定のXSDを使用した行セットのサポート」を参照してください。

この項には次のトピックが含まれます:

詳細は、「強い型指定のXSDまたは弱い型指定のXSDを使用した行セットのサポート」を参照してください。

9.7.7.2.1 設計時

選択したストアド・プロシージャまたはファンクションに、タイプがResultSetである出力パラメータが含まれている場合は、このREF CURSORのための弱い型指定のXSDを次のように定義できます。

アダプタ構成ウィザードを使用して、タイプがResultSetの出力パラメータを含むストアド・プロシージャまたはファンクションを選択します。
「最上位のスタンドアロンAPIの使用」のステップ1から8を参照してください。
「次」を選択します。図9-58に示すように、「RowSets」ページが表示されます。
デフォルトで、アダプタ構成ウィザードでは、「XSD」テキスト・フィールドに表示されるこのREF CURSORのための、弱い型指定のXSDが生成されます。

図9-58 「RowSets」ページ

「図9-58 「RowSets」ページ」の説明
必要に応じて、「XSD」テキスト・フィールドに表示されるスキーマを手動で編集することによって、弱い型指定のXSDを微調整します。
「最上位のスタンドアロンAPIの使用」のステップ10に進みます。

9.7.7.2.2 実行時

次のパッケージがあるとします。

CREATE PACKAGE PKG AS
       TYPE REF_CURSOR IS REF CURSOR;
       PROCEDURE TEST(C OUT REF_CURSOR);
END;

CREATE PACKAGE BODY PKG AS
       ROCEDURE TEST(C OUT REF_CURSOR) AS
       BEGIN
           OPEN C FOR SELECT DEPTNO, DNAME FROM DEPT;
       END;
END;

REF_CURSORは、問合せが指定されていないため弱い型指定のカーソル変数です。プロシージャの実行後、パラメータCについて次のXMLが生成されます。

<C>
    <Row>
        <Column name="DEPTNO" sqltype="NUMBER">10</Column>
        <Column name="DNAME" sqltype="VARCHAR2">ACCOUNTING</Column>
    </Row>
    <Row>
        <Column name="DEPTNO" sqltype="NUMBER">20</Column>
        <Column name="DNAME" sqltype="VARCHAR2">RESEARCH</Column>
    </Row>
    …
</C>

合計4行があり、各行が2つの列DEPTNOおよびDNAMEで構成されています。

REF CURSORは、Java ResultSetsで表されます。JDBCドライバで提供されるAPIを使用してResultSetをプログラムで作成することはできません。したがって、REF CURSORをストアド・プロシージャにINとして渡すことはできません。IN/OUTおよびOUTパラメータとしてのみ渡すことができますが、1つ注意点があります。IN/OUT REF CURSORは、OUTパラメータとしてのみ処理されます。IN/OUTパラメータではIN値を提供できないため、そのパラメータにはストアド・プロシージャの起動時にNULLがバインドされます。

9.7.7.3 PL/SQLブール、PL/SQLレコードおよびPL/SQL表タイプのサポート

アダプタ構成ウィザードには、これらのタイプが使用され、Oracle JPublisherが起動して必要なラッパーが自動的に生成される時期を検出するメカニズムがあります。Oracle JPublisherでは、スキーマ・オブジェクトの生成用とその削除用の2つのSQLファイルが生成されます。スキーマ・オブジェクトを作成するSQLはアダプタ構成ウィザード内で自動的に実行され、XSDファイルが生成される前にデータベース・スキーマにスキーマ・オブジェクトが作成されます。たとえば、次のパッケージ仕様が宣言されたとします。

CREATE PACKAGE PKG AS
  TYPE REC IS RECORD (X NUMBER, Y VARCHAR2 (10));
  TYPE TBL IS TABLE OF NUMBER INDEX BY PLS_INTEGER;
  PROCEDURE PLSQL (R REC, T TBL, B BOOLEAN);
END;

図9-59に、PKGパッケージのPROCプロシージャが選択されると表示されるアダプタ構成ウィザードでの手順を示します。

図9-59 アダプタ構成ウィザードにおけるストアド・プロシージャの指定

「図9-59 アダプタ構成ウィザードにおけるストアド・プロシージャの指定」の説明

図9-59に示すように、元のプロシージャ名は完全修飾され、PKG.PLSQLとなっています。パラメータ・タイプRはRECORDの名前です。タイプTはTABLEの名前です。タイプBはBooleanです。生成されているラッパー・パッケージの名前は、サービス名bpel_ServiceName(bpel_UseJPubなど)から導出されます。これは、生成されたパッケージの名前で、ラッパー・プロシージャが含まれています。チェック・ボックスは、スキーマ・オブジェクトの作成時に、アダプタ構成ウィザードで既存のパッケージの上書きを強制する際に使用できます。

図9-60に示すように、「次へ」をクリックすると、アダプタ構成ウィザードの「終了」ページが表示されます。

図9-60 データベース・アダプタ・サービスの定義: 「終了」ページ

「図9-60 データベース・アダプタ・サービスの定義: 「終了」ページ」の説明

このページのコンテンツでは、アダプタ構成ウィザードで検出されたものと、「終了」ボタンがクリックされると実行される処理が説明されます。次に、このページのコンテンツをまとめます。

生成されたWSDLの名前はUseJPub.wsdlです。
JCAファイルの名前はUseJPub_db.jcaです。
2つのSQLスクリプトが作成され、BPELプロセス・プロジェクトに追加されます。
1. BPEL_USEJPUB.sql - スキーマ・オブジェクトが作成されます。
2. BPEL_USEJPUB_drop.sql - スキーマ・オブジェクトが削除されます。
生成されたXSDの名前はSCOTT_USEJPUB_PKG-24PLSQL.xsdです。

「終了」をクリックすると、Oracle JPublisherが起動され、SQLファイルが生成されてデータベースにスキーマ・オブジェクトがロードされます。ラッパーの生成プロセスは、完了に時間がかかります。初期ラッパーが同じパッケージ内の別のプロシージャに生成された後は、通常、同じパッケージに生成されるラッパーの処理時間は短くなります。

注意:

Oracleデータベース・アダプタを再作成するときには、BPEL_XXXX_drop.sqlを実行する必要があります。これは、キャッシュを使用してラッパーを生成するJPublisher機能に備えて実行します。

次に示すユーザー定義タイプは、PL/SQLタイプを元のプロシージャから置き換えるために生成されます。

SQL> CREATE TYPE PKG_REC AS OBJECT (X NUMBER, Y VARCHAR2 (10));
SQL> CREATE TYPE PKG_TBL AS TABLE OF NUMBER;

これらのタイプのネーミング規則は、OriginalPackageName_OriginalTypeNameです。Booleanは、ラッパー・プロシージャでINTEGERに置き換えられます。

現在はINTEGERである、元のBooleanパラメータの許容値は、FALSEが0でTRUEが0以外のINTEGER値です。1以外の値はfalseとみなされます。生成されたラッパー・プロシージャでは、SYS.SQLJUTLパッケージのAPIが使用され、INTEGERとBooleanが相互に変換されます。

PKG$PPLSQLというプロシージャPLSQLのラッパー、およびPL/SQLタイプとユーザー定義タイプの相互変換を行う変換APIが含まれる、BPEL_USEJPUBという新しいラッパー・パッケージが作成されます。元のプロシージャがルートレベルのプロシージャの場合、生成されたラッパー・プロシージャの名前はTOPLEVEL$OriginalProcedureNameです。

生成されたXSDは、元のプロシージャではなく、ラッパー・プロシージャPKG$PLSQLのシグネチャを表します。XSDファイルの名前はURLエンコードされ、$が-24に置き換えられます。

生成された成果物のネーミング規則を示します。

サービス名は、WSDLおよびSQLファイルの名前に使用されます。ラッパー・パッケージの名前にも使用されます。
生成されたXSDの名前は、スキーマ名、サービス名、および元のパッケージ名とプロシージャ名から導出されます。
SQLオブジェクトまたはコレクション・データ・タイプの名前は、元のパッケージ名および対応するPL/SQLタイプの名前から導出されます。
ラッパー・プロシージャの名前は、元のパッケージ名とプロシージャ名から導出されます。TOPLEVEL$は、ルートレベルのプロシージャに使用されます。

注意:

アダプタ構成を使用する前に、JCAファイルを調べて、それを生成されたSQLスクリプトと比較してください。JCAファイルのパラメータの値が、生成されたSQLファイルにあることを確認してください。たとえば、パラメータは次のような値を持つ必要があります。

	<property name="PackageName" value="BEPL_USEJPUB"/>
	<property name="ProcedureName" value="PKG$PLSQL"/>

生成されたラッパー・パッケージの名前は30文字に制限されます。ラッパー・プロシージャの名前は29文字に制限されます。Oracle JPublisherで生成された名前がこれらの制限よりも長い場合は、切り捨てられます。

プロシージャに関連付けられたサービスに対応するPartnerLinkが起動されると、生成されたラッパー・プロシージャは元のプロシージャのかわりに実行されます。

9.7.7.3.1 ラッパー・プロシージャのデフォルト句

プロシージャにラッパーの生成を必要とする特殊な型が含まれている場合は、いずれのパラメータのデフォルト句もラッパーには持ち越されません。たとえば、次のようなプロシージャがあるとします

SQL> CREATE PROCEDURE NEEDSWRAPPER (
        >     B BOOLEAN DEFAULT TRUE, N NUMBER DEFAULT 0) IS BEGIN … END;

これがルートレベルのプロシージャであると仮定すると、生成されるラッパー・プロシージャのシグネチャは次のようになります。

TOPLEVEL$NEEDSWRAPPER (B INTEGER, N NUMBER)

BooleanタイプがINTEGERに置き換えられています。生成されたラッパーには、どちらのパラメータのデフォルト句もありません。元のプロシージャにデフォルト句があったとしても、生成されるラッパー・プロシージャのパラメータには、デフォルト句はありません。

この例で、いずれかのパラメータの要素がインスタンスXMLに指定されていない場合、指定した引数の数が正しくないことを示すエラーが発生します。元のプロシージャに指定されているパラメータのデフォルト値は使用されません。

この状況に対応するには、デフォルト句をラッパー・プロシージャのパラメータにリストアして、ラッパーを作成する生成されたSQLファイルを編集する必要があります。その後、ラッパーおよびその他のスキーマ・オブジェクトをデータベース・スキーマにリロードする必要があります。SQLファイルの編集後、ラッパー・プロシージャのシグネチャは次のようになります。

TOPLEVEL$NEEDSWRAPPER (B INTEGER DEFAULT 1, N NUMBER DEFAULT 0)

Booleanパラメータの場合、trueのデフォルト値は1で、falseのデフォルト値は0です。

最後の手順として、ラッパーに生成されたXSDファイルを編集する必要があります。デフォルト句を持つパラメータを表す要素に、特別な属性を追加する必要があります。デフォルト句を持つパラメータを表す各要素にdb:default="true"を追加します。例:

<element name="B" … db:default="true" …/>
<element name="N" … db:default="true" …/>

この属性は、インスタンスXMLに要素がない場合、プロシージャ・コールから対応するパラメータを除外する必要があることを示すために実行時に使用されます。これらの要素のその他の属性は元のままです。

9.8 Oracleデータベース・アダプタの使用例

この項では、Oracleデータベース・アダプタとOracleデータベース・アダプタ - ストアド・プロシージャの使用例について説明します。

この項には次のトピックが含まれます:

9.8.1 Oracleデータベース・アダプタの使用例

Oracleデータベース・アダプタの使用例を入手するには、Oracle SOA Sample Codeサイトにアクセスします。

表9-21には、そのサンプル・コード・サイトのデータベース・アダプタの例をまとめています。

表9-21 サンプル・ページ・サイトのアダプタの例

サンプル	説明
adapters-db-101-MasterDetail.zip	MasterDetailチュートリアルは、1つのデータベースの1セットの表のデータを同じ/別のデータベースの表にレプリケートする単純なシナリオを示しています。
adapters-db-103-File2StoredProcedure.zip	この例は、ストアド・プロシージャの起動とのインタフェースとなるファイル・アダプタの使用について説明しています。
adapters-db-102-Select.zip	Selectチュートリアルは、より大きなBPELプロセスの一部として、あるいはWebサービス呼出しとして独立してDMLの選択/挿入/更新/削除を起動する方法を示しています。
adapters-db-104-InformixStoredProcedure.zip	このシナリオは、Informixインスタンスでストアド・プロシージャを起動するデータベース・アダプタのパートナ(アウトバウンド・アダプタ・サービス)を示しています。
adapters-db-105-SybaseStoredProcedure.zip	このシナリオは、Sybaseインスタンスでストアド・プロシージャを起動するデータベース・アダプタのパートナ(アウトバウンド・アダプタ・サービス)を示しています。
adapters-db-107-Polling.zip	この例は、3つの基本ポーリング戦略や、データベース上のイベントをBPELプロセスまたはSOAプロセスの開始インスタンスに変換する方法を示しています。
adapters-db-201-MovieImages.zip	この例では、SOAを使用してJPGなどのバイナリ・ファイルをデータベース内のBLOB列に読み込む方法と、その表からファイルに読み戻す方法が示されています。
adapters-db-203-RefCursors.zip	Ref Cursorチュートリアルは、行セットを返すストアド・プロシージャの使用方法を示しています。
adapters-db-207-AdvancedPolling.zip	この例は107-Pollingの続きで、コア・ポーリング戦略のより現実的かつ高度なバージョンが示されています。
adapters-db-307-ExpertPolling.zip	このボーナス・サンプルは207-AdvancedPollingの続きで、イベントのポーリングをUI内で公開されるもの以外でカスタマイズするいくつかの方法が示されています。

9.8.2 Oracleデータベース・アダプタ - ストアド・プロシージャの使用例

この項には、次の項目が含まれます。

この項で説明する使用例の他に、Oracle SOA Sample Codeサイトにアクセスして入手できるサンプルのOracleデータベース・アダプタ使用例も参照してください。

表9-22に、Oracle BPEL PMおよびメディエータで提供されているOracleデータベース・アダプタのストアド・プロシージャのサンプルを示します。

表9-22 Oracleデータベース・アダプタの使用例 - ストアド・プロシージャ

チュートリアル名	説明
`JPublisherWrapper`	PL/SQL `RECORD`タイプの使用に関する解決策を説明します。JPublisherは、属性が`RECORD`のフィールドに一致する対応する`OBJECT`型、および`RECORD`と`OBJECT`の相互変換を行う変換APIの作成に使用されます。また、JPublisherでは`OBJECT`を許可し、両方向で変換APIを使用して基礎となるメソッドを起動するラッパー・プロシージャ(またはファンクション)が生成されます。起動されたメソッドが、(Oracle Liteではない)Oracleデータベースにインストールされている必要があります。
`RefCursors`	強い型指定のXSDまたは弱い型指定のXSDを使用した`REF CURSOR`を使用する方法について説明します。アダプタ構成ウィザードを使用して、Oracleデータベースのストアド・プロシージャまたはファンクションの`REF CURSOR`変数によって返される行セットのための、強い型指定のXSDを作成できます。詳細は、「強い型指定のXSDまたは弱い型指定のXSDを使用した行セットのサポート」を参照してください。
`ResultSetConverter`	`REF CURSOR`の使用に関する解決策を説明します。解決策には、対応する`java.sql.ResultSet`をOBJECTの集合(`VARRAY`または`NESTED TABLE`)に変換するJavaストアド・プロシージャの使用が関連します。

使用例の多くで使用されているMOVIES表の構造は、表9-4を参照してください。ほとんどのサンプルに含まれているreadme.txtファイルには、説明が記載されています。

9.8.2.1 JDeveloper BPELデザイナにおけるストアド・プロシージャの作成および構成

この使用例では、JDeveloper BPELデザイナを使用したBPEL Process Managerへのストアド・プロシージャの統合方法について説明します。

この使用例には、次の項目が含まれます。

9.8.2.1.1 前提条件

この使用例を実行するには、SCOTTスキーマ内で次のストアド・プロシージャを定義する必要があります。

SQL> CREATE PROCEDURE hello (name IN VARCHAR2, greeting OUT VARCHAR2) AS
  2  BEGIN
  3     greeting := 'Hello ' || name;
  4  END;
  5/

9.8.2.1.2 アプリケーションおよびSOAコンポジットの作成

SOAコンポジットを含んだJDeveloperアプリケーションを作成する必要があります。使用例のアプリケーションとプロジェクトを作成する手順は、次のとおりです。

JDeveloperの「アプリケーション・ナビゲータ」で、「新規アプリケーション」をクリックします。
「汎用アプリケーションの作成 - アプリケーションの名前付け」ページが表示されます。
「アプリケーション名」フィールドにMyHelloAppと入力して「次へ」をクリックします。
「汎用アプリケーションの作成 - プロジェクトの名前付け」ページが表示されます。
「プロジェクト名」フィールドにHelloProjectと入力します。
「プロジェクト・テクノロジ」タブの「選択可能」リストで「SOA」をダブルクリックし、「選択済」リストに移動します。
「次へ」をクリックします。
「汎用アプリケーションの作成 - SOA設定の構成」ページが表示されます。
「コンポジット・テンプレート」ボックスで「BPELを使用するコンポジット」を選択して「終了」をクリックします。「BPELプロセスの作成」ページが表示されます。
「名前」フィールドにGreetと入力し、「テンプレート」ボックスから「同期BPELプロセス」を選択します。
「OK」をクリックします。
図9-61に示すように、MyHelloAppのHelloProject内のGreet BPELプロセスが設計領域に表示されます。

図9-61 JDeveloper - composite.xml

「図9-61 JDeveloper - composite.xml」の説明

9.8.2.1.3 アウトバウンドOracleデータベース・アダプタ・サービスの作成

次の手順に従ってアウトバウンドOracleデータベース・アダプタ・サービスを作成します。

「コンポーネント・パレット」から、「データベース・アダプタ」を「外部参照」スイムレーンにドラッグ・アンド・ドロップします。

アダプタ構成ウィザードの「ようこそ」ページが表示されます。
「Next」をクリックします。

「サービス名」ページが表示されます。
「サービス名」フィールドにHelloと入力します。
「Next」をクリックします。

「サービス接続」ページが表示されます。

注意:
このアプリケーションをデプロイする前に、weblogic-ra.xmlファイル内でJNDI名を構成していることを確認してください。

詳細は、「データソースの作成」および「Oracle JCAアダプタで使用するデータソースの推奨設定」を参照してください。
「新規データベース接続を作成します。」アイコンをクリックします。

「データベース接続の作成」ダイアログが表示されます。
「データベース接続の作成」ダイアログで次の詳細を入力します。
1. 「接続名」フィールドに接続名を入力します。例: Myconnection。
2. 接続タイプとして「Oracle (JDBC)」を選択します。
3. ユーザー名およびパスワードとしてscott/tigerと入力します。
4. 「ホスト名」フィールドにホスト名を入力し、「JDBCポート」フィールドにJDBCポートを入力します。
5. 「SID」を選択してSID名を入力します。または、「サービス名」を選択してサービス名を入力します。
6. 「接続のテスト」をクリックします。「ステータス」ペインに成功メッセージが表示されます。
7. 「OK」をクリックします。
「接続」フィールドにMyConnection接続が移入され、「JNDI」フィールドにeis/DB/MyConnectionが移入されます。
「Next」をクリックします。

「操作タイプ」ページが表示されます。
「ストアド・プロシージャまたはファンクションの呼出し」を選択して、「次へ」をクリックします。

「ストアド・プロシージャの指定」ページが表示されます。
「参照」をクリックします。「ストアド・プロシージャ」ペインでHELLOを選択します。

「引数」タブにストアド・プロシージャのパラメータが表示され、「ソース」タブにストアド・プロシージャのソース・コードが表示されます。
「OK」をクリックします。

「ストアド・プロシージャの指定」ページが表示されます。「プロシージャ」フィールドにHELLOストアド・プロシージャが移入され、HELLOストアド・プロシージャの引数も表示されます。
「Next」をクリックします。

「詳細オプション」ページが表示されます。
任意の追加の詳細オプションを指定して、「次へ」をクリックします。

アダプタ構成ウィザードの「終了」ページが表示されます。
「終了」をクリックします。

「パートナ・リンクの作成」ダイアログ・ボックスが表示されます。パートナ・リンク名は、サービス名と同じHelloです。
「OK」をクリックします。

アウトバウンドOracleデータベース・アダプタが構成され、Greet BPELプロセスが表示されます。

9.8.2.1.4 invokeアクティビティの追加

次の手順に従ってinvokeアクティビティを追加します。

「コンポーネント・パレット」から、invokeアクティビティを設計領域のreceiveInputアクティビティとreplyOutputアクティビティの間にドラッグ・アンド・ドロップします。
invokeアクティビティをダブルクリックします。
「Invokeの編集」ダイアログが表示されます。
「名前」フィールドにInputと入力します。
「Invoke」ボックスで、「入力変数」フィールドの右にある「入力変数の自動作成」アイコンをクリックします。
「変数の作成」ダイアログが表示されます。
デフォルトの変数名を選択し、「OK」をクリックします。
「入力変数」フィールドにデフォルトの変数名が移入されます。「Invoke」ダイアログが表示されます。
同じ手順を繰り返して、「出力変数」フィールドで出力変数を選択します。
「Invokeの編集」ダイアログの「変数」セクションに、入力変数名と出力変数名が表示されます。
「OK」をクリックします。
図9-62に示すように、Helloパートナ・リンクに接続された右矢印付きの線が表示されます。

図9-62 「Greet.bpel」ページ

「図9-62 「Greet.bpel」ページ」の説明

9.8.2.1.5 リクエスト・メッセージのメッセージ・パートの変更

リクエストのペイロードがInputParametersと一致する場合、すべてのINパラメータがリクエストに含まれます。この例では、INパラメータはnameのみです。

次の手順に従って、GreetRequestMessageメッセージのメッセージ・パートを変更します。

Greet BPELプロセスの「構造」ペイン(「アプリケーション」ペインの下)で、「メッセージ・タイプ」、「プロセスWSDL - Greet.wsdl」および「GreetRequestMessage」を順番に開きます。
「payload」を選択して「編集」アイコンをクリックします。
「メッセージ・パートの編集 - payload」ダイアログが表示されます。
「要素」を選択して「検索」アイコンをクリックします。
「タイプ・チューザ」ダイアログが表示されます。
「プロジェクトのスキーマ・ファイル」と「SCOTT_HELLO.xsd」を順番に開き、「InputParameters」を選択します。
「OK」をクリックします。
「メッセージ・パートの編集 - payload」ダイアログが表示されます。
「OK」をクリックします。

9.8.2.1.6 レスポンス・メッセージのメッセージ・パートの変更

レスポンスのペイロードがOutputParametersと一致する場合、すべてのOUTパラメータがレスポンスに含まれます。この例では、OUTパラメータはgreetingのみです。

GreetResponseMessageメッセージ・パートに関する手順はGreetRequestMessageの場合と同じですが、次の例外があります。

「GreetResponseMessage」メッセージ・タイプを開き、「payload」を選択します。
「タイプ・チューザ」ダイアログで「SCOTT_HELLO.xsd」を開き、「OutputParameters」を選択します。
「OutputParameters」を選択します。

9.8.2.1.7 入力変数のassignアクティビティの追加

次の手順に従って入力変数のassignアクティビティを追加します。

「コンポーネント・パレット」から、assignアクティビティを設計領域のreceiveInputおよびGreetというinvokeアクティビティの間にドラッグ・アンド・ドロップします。
assignアクティビティをダブルクリックします。
「Assign」ダイアログが表示されます。
「一般」をクリックし、「名前」フィールドで名前をNAMEに変更します。
「コピー操作」タブでプラス・アイコンをクリックし、表示された操作リストから「コピー操作」を選択します。
「コピー操作の作成」ダイアログが表示されます。
「From」領域で、「変数」、「inputVariable」および「payload」を順番に開いて「ns2:InputParameters」を選択します。
「To」領域で、「変数」、「Input_Hello_InputVariable」および「InputParameters」を順番に開いて「ns2:InputParameters」を選択します。
「OK」をクリックします。
入力パラメータへの値の割当てを完了しました。

図9-63に示すように、「Assign」ダイアログが表示されます。このダイアログには、inputVariableのペイロードからInput_Hello_InputVariableのペイロードへの割当てが表示されます。

図9-63 「コピー操作の作成」ダイアログ

「図9-63 「コピー操作の作成」ダイアログ」の説明
「ファイル」、「すべて保存」を順番にクリックします。

9.8.2.1.8 出力変数のassignアクティビティの追加

2つ目のassignアクティビティでは、出力パラメータに値を割り当てます。

出力パラメータに値を割り当てる手順は、入力パラメータに値を割り当てる場合と同じですが、次の例外があります。

「コンポーネント・パレット」から、assignアクティビティを設計領域のGreet invokeアクティビティとreplyOutputアクティビティの間にドラッグ・アンド・ドロップします。
assignアクティビティをダブルクリックします。
「Assign」ダイアログが表示されます。
「名前」フィールドにGreetingと入力します。
「コピー操作」タブでプラス・アイコンをクリックし、表示された操作リストから「コピー操作」を選択します。
「コピー操作の作成」ダイアログが表示されます。
図9-64に示すように、「From」ペインで「Input_Hello_OutputVariable」および「OutputParameters」を順番に開いて「ns2:OutputParameters」を選択します。
図9-64に示すように、「To」ペインで「outputVariable」および「payload」を順番に開いて「ns2:OutputParameters」を選択します
図9-64 「コピー操作の作成」ダイアログ

「図9-64 「コピー操作の作成」ダイアログ」の説明
「OK」をクリックします。
出力パラメータへの値の割当てを完了しました。
「ファイル」、「すべて保存」を順番にクリックします。
BPELプロセスのモデル化を完了しました。図9-65に示すように、最終的なBPELプロセスが表示されます。

図9-65 最終的なBPELプロセスの画面

「図9-65 最終的なBPELプロセスの画面」の説明

9.8.2.1.9 JDeveloperを使用したデプロイ

前述の手順で作成したSOAプロジェクトおよびアプリケーションについて、アプリケーション・プロファイルをデプロイする必要があります。JDeveloperを使用してアプリケーション・プロファイルをデプロイするには、次の手順を実行する必要があります。

「Oracle JCAアダプタ用のアプリケーション・サーバー接続の作成」で説明されている手順を使用して、アプリケーション・サーバー接続を作成します。
JDeveloperからのOracle JCAアダプタ・アプリケーションのデプロイで説明されている手順を使用して、アプリケーションをデプロイします。

9.8.2.1.10 Oracle WebLogic Server管理コンソールでのデータソースの作成

HelloProjectをテストする前に、Oracle WebLogic Server管理コンソールを使用してデータソースを作成する必要があります。

手順は次のとおりです。

Webブラウザにhttp://<hostname>:<port>/consoleと入力します。
ユーザー名とパスワードを入力して「ログイン」をクリックします。
管理コンソールが表示されます。
「JDBC」の下の「サービス」領域で「データ・ソース」をクリックします。
「JDBCデータ・ソースの概要」が表示されます。
「新規」をクリックします。
「新しいJDBCデータ・ソースの作成」ページが表示されます。
「新しいJDBCデータ・ソースの作成」ページで、次の詳細を入力します。
- 「名前」フィールドにMyDataSourceと入力します。
- 「JNDI名」フィールドにjdbc/MyDataSourceと入力します。
- 「データベースのタイプ」はOracleです。
- 「データベース・ドライバ」は、Oracle's Driver (Thin XA) for Instance Connections; Versions 9.0.1, 9.2.0, 10, 11です。
「次へ」をクリックします。
別のトランザクション構成オプションはないことを示すメッセージが表示されます。
「次へ」をクリックします。
「新しいデータ・ソースの作成」ページが表示されます。
次の詳細を入力します。
- データベース名: 通常はSIDです。
- ホスト名: ホスト・コンピュータ名を入力します。
- ポート番号: ポート番号を入力します。
  
  デフォルト・ポートは1521です。
- データベース・ユーザー名: SCOTTと入力します。
- パスワード: TIGERと入力します。
- パスワードの確認: TIGERと入力します。
「次へ」をクリックします。
データソース構成の概要が表示されます。
「構成のテスト」をクリックします。
「メッセージ」領域に、接続テストに成功したことが示されます。
「次」を選択します。「AdminServer」チェック・ボックスを選択してターゲットとして選択します。
「終了」をクリックします。
これで、前述の手順で作成したMyDataSourceデータソースがJDBCデータソースの概要に含まれます。

9.8.2.1.11 Fusion Middleware Controlコンソールを使用した監視

Fusion Middleware Controlコンソールを使用して、デプロイ済のSOAコンポジットを監視できます。次の手順を実行します。

http://servername:portnumber/emにナビゲートします。前述の手順で作成したHelloProject[1.0]を含めて、SOAコンポジットのリストが表示されます。
「HelloProject[1.0]」リンクをクリックします。図9-66に示すように、「ダッシュボード」タブが表示されます。
図9-66 HelloProject[1.0]プロジェクトの「ダッシュボード」タブ

「図9-66 HelloProject[1.0]プロジェクトの「ダッシュボード」タブ」の説明
「テスト」をクリックします。新規のブラウザ・ウィンドウが表示されます。
xsd:stringでマーク付けされている「NAME」フィールドに名前を入力し、「呼出し」をクリックします。
ブラウザ・ウィンドウにテスト結果が表示されます。
読取り可能な書式のXMLファイルを表示するには、「フォーマット済XML」をクリックします。図9-67に、フォーマット済XMLファイルを示します。
図9-67 フォーマット済XMLファイル

「図9-67 フォーマット済XMLファイル」の説明

9.8.2.2 ファイルからストアド・プロシージャへの使用例

この使用例では、Oracleストアド・プロシージャの実行について説明します。ストアド・プロシージャへの入力は、ファイル・アダプタを使用してファイルを読み取ることで取得されます。ストアド・プロシージャが実行されると、表に入力パラメータからのデータが移入されます。

adapter-db-101-file2storedprocedureの使用例を入手するには、Oracle SOA Sample Codeサイトにアクセスします。

この使用例には、次の項目が含まれます。

9.8.2.2.1 前提条件

ファイルからストアド・プロシージャへの使用例を実行するには、JDeveloperを使用してBPELコンポジットをモデル化する前に、次のスキーマ・オブジェクトとストアド・プロシージャをSCOTT/TIGERスキーマ内で定義する必要があります。

create type address as object
(
  street varchar2(20),
  city   varchar2(15),
  state  char(2),
  zip    char(5)
);
create type customer as object
(
  fname varchar2(10),
  lname varchar2(10),
  loc   address,
  email varchar2(25),
  phone varchar2(15)
);
create type collection as table of customer;
create table customers
(
  name  varchar2(25),
  loc   varchar2(45),
  email varchar2(25),
  phone varchar2(15)
);
create procedure add_customers(c in collection) as
begin
  for i in c.first .. c.last loop
    insert into customers values (
      c(i).lname || ', ' || c(i).fname,
      c(i).loc.street || ', ' || c(i).loc.city || ', ' || c(i).loc.state || ' ' ||
 c(i).loc.zip,
      c(i).email,
      c(i).phone    );
  end loop;
end;

これらのスキーマ・オブジェクトとストアド・プロシージャは、Oracle SOA Sample Codeサイトにアクセスして入手できるadapters-db-101-file2storedprocedureサンプルのadapters-db-101-file2storedprocedure/artifacts/sql/customers.sqlファイルを使用して定義できます。

9.8.2.2.2 アプリケーションおよびSOAプロジェクトの作成

SOAコンポジットを含んだJDeveloperアプリケーションを作成する必要があります。次の手順に従って新規アプリケーションとSOAプロジェクトを作成します。

JDeveloperを開きます。
「アプリケーション・ナビゲータ」で、「新規アプリケーション」をクリックします。「汎用アプリケーションの作成 - アプリケーションの名前付け」ページが表示されます。
「アプリケーション名」フィールドにFile2SPAppと入力します。
「アプリケーション・テンプレート」リストで、「汎用アプリケーション」を選択します。
「次へ」をクリックします。
「汎用アプリケーションの作成 - プロジェクトの名前付け」ページが表示されます。
「プロジェクト名」フィールドにわかりやすい名前を入力します。例: File2SPProject。
「プロジェクト・テクノロジ」タブの「選択可能」リストで「SOA」をダブルクリックし、「選択済」リストに移動します。
「次」を選択します。「汎用アプリケーションの作成 - SOA設定の構成」ページが表示されます。
「コンポジット・テンプレート」リストから「BPELを使用するコンポジット」を選択して、「終了」をクリックします。
新規アプリケーションおよびSOAプロジェクトが作成されました。これにより、SOAコンポジットが自動的に作成されます。

「BPELプロセスの作成」ページが表示されます。
「名前」フィールドにBPELプロセスの名前を入力します。例: File2SP。
「テンプレート」リストで「サービスを後で定義」を選択し、「OK」をクリックします。
File2SPAppのFile2SPProject内のFile2SP BPELプロセスが設計領域に表示されます。

9.8.2.2.3 アウトバウンドOracleデータベース・アダプタ・サービスの作成

次の手順に従ってアウトバウンドOracleデータベース・アダプタ・サービスを作成します。

「データベース・アダプタ」を、「サービス・アダプタ」リストから「公開されたサービス」スイムレーンにドラッグ・アンド・ドロップします。アダプタ構成ウィザードの「ようこそ」ページが表示されます。
「Next」をクリックします。「サービス名」ページが表示されます。
「サービス名」フィールドにFile2SPServiceと入力します。
「Next」をクリックします。

「サービス接続」ページが表示されます。
「新規データベース接続を作成します。」アイコンをクリックします。

「データベース接続の作成」ダイアログが表示されます。
「データベース接続の作成」ダイアログで次の詳細を入力します。
1. 「接続名」フィールドに接続名を入力します。例: MyConnection。
2. 接続タイプとして「Oracle (JDBC)」を選択します。
3. ユーザー名およびパスワードとしてscott/tigerと入力します。
4. 「ホスト名」フィールドにホスト名を入力し、「JDBCポート」フィールドにJDBCポートを入力します。
5. 「SID」を選択してSID名を入力します。または、「サービス名」を選択してサービス名を入力します。
6. 「接続のテスト」をクリックします。「ステータス」ペインに成功メッセージが表示されます。
7. 「OK」をクリックします。
「接続」フィールドにMyConnection接続が移入され、「JNDI」フィールドにeis/DB/MyConnectionが移入されます。
「Next」をクリックします。

「アダプタ・インタフェース」ページが表示されます。
「アダプタ・インタフェース」ページで、「操作およびスキーマから定義(後で指定)」を選択し、「次へ」をクリックします。

「操作タイプ」ページが表示されます。
図9-68に示すように、「ストアド・プロシージャまたはファンクションの呼出し」を選択して「次へ」をクリックします。

「ストアド・プロシージャの指定」ページが表示されます。

図9-68 「アダプタ構成ウィザード - 操作タイプ」ページ

「図9-68 「アダプタ構成ウィザード - 操作タイプ」ページ」の説明
「参照」をクリックします。「ストアド・プロシージャ」ペインでADD_CUSTOMERSを選択します。

「引数」タブにストアド・プロシージャのパラメータが表示され、「ソース」タブにストアド・プロシージャのソース・コードが表示されます。
「OK」をクリックします。

「ストアド・プロシージャの指定」ページが表示されます。

「プロシージャ」フィールドにADD_CUSTOMERSストアド・プロシージャが移入され、ADD_CUSTOMERSストアド・プロシージャの引数も表示されます。
「Next」をクリックします。

「詳細オプション」ページが表示されます。
任意の追加のオプションを指定して、「次へ」をクリックします。

「終了」ページが表示されます。
「終了」をクリックします。

「パートナ・リンクの作成」ダイアログが表示されます。

パートナ・リンク名は、サービス名と同じFile2SPServiceです。
「OK」をクリックします。

アウトバウンドOracleデータベース・アダプタが構成され、File2SP BPELプロセスが表示されます。

9.8.2.2.4 Invokeアクティビティの作成

invokeアクティビティを作成してBPELプロセスを完成する必要があります。これにより、入力変数が作成されます。

次の手順に従ってinvokeアクティビティを作成します。

「ファイル」、「すべて保存」を順番にクリックします。
「コンポーネント・パレット」から設計領域にinvokeアクティビティをドラッグ・アンド・ドロップします。
invokeアクティビティの右にある右矢印をドラッグし、File2SPServiceパートナ・リンクに接続します。
「Invokeの編集」ダイアログが表示されます。
「名前」フィールドにInvokeと入力します。
「Invoke」ダイアログで、「入力変数」フィールドの右にある「入力変数の自動作成」アイコンをクリックします。
「変数の作成」ダイアログが表示されます。
デフォルトの変数名を選択し、「OK」をクリックします。
「Invokeの編集」ダイアログの「変数」領域に入力変数名が表示されます。
「OK」をクリックします。
File2SPServiceパートナ・リンクに接続されている右矢印付きの線が表示されます。

9.8.2.2.5 インバウンド・ファイル・アダプタ・サービスの作成

次の手順に従ってインバウンド・ファイル・アダプタ・サービスを作成します。これにより、ファイル・ディレクトリから入力XMLを読み取るサービスが作成されます。

「コンポーネント・パレット」から、「ファイル・アダプタ」を「外部参照」スイムレーンにドラッグ・アンド・ドロップします。
アダプタ構成ウィザードの「ようこそ」ページが表示されます。
「次」を選択します。「サービス名」ページが表示されます。
「サービス名」フィールドにReadCustomersと入力します。
「次へ」をクリックします。
「アダプタ・インタフェース」ページが表示されます。
「操作およびスキーマから定義(後で指定)」を選択し、「次へ」をクリックします。「操作」ページが表示されます。
操作タイプとして「Read File」を選択し、操作名として「Read」を選択します。他のチェック・ボックスは選択しないでください。
「次へ」をクリックします。
「ファイル・ディレクトリ」ページが表示されます。
「物理パス」を選択して、「着信ファイル用のディレクトリ(物理パス)」フィールドに物理パスを入力します。
「ファイルを再帰的に処理します」および「正常な配信後にファイルを削除」を選択して、「次へ」をクリックします。
「ファイルのフィルタ処理」ページが表示されます。
ファイル・ワイルドカードを指定して、customers.xmlを「インクルード・ファイルの名前パターン」フィールドに入力し、次に、「次へ」をクリックします。
「ファイル・ポーリング」ページが表示されます。
「ポーリング頻度」フィールドで任意の値を指定して「次へ」をクリックします。
「メッセージ」ページが表示されます。
「URL」フィールドの端に表示される「スキーマ・ファイルを参照」をクリックします。
「タイプ・チューザ」ダイアログが表示されます。
「プロジェクトのスキーマ・ファイル」、「SCOTT_ADD_CUSTOMERS.xsd」および「InputParameters」を順番にクリックします。
「OK」をクリックします。
「メッセージ」ページが再表示されます。URLはxsd/SCOTT_ADD_CUSTOMERS.xsdで、「スキーマ要素」はInputParametersとなっています。
「次へ」をクリックします。
「終了」ページが表示されます。
「終了」をクリックします。
インバウンド・ファイル・アダプタ・サービスが終了します。
「OK」をクリックしてパートナ・リンクを完了します。
「ファイル」、「すべて保存」を順番にクリックします。

9.8.2.2.6 receiveアクティビティの追加

ファイル・アダプタ・サービスはreceiveアクティビティに入力を提供し、receiveアクティビティは残りのBPELプロセスを開始します。

次の手順に従ってreceiveアクティビティを追加します。

「File2SP」をダブルクリックします。「File2SP.bpel」ページが表示されます。
「コンポーネント・パレット」から設計領域にreceiveアクティビティをドラッグ・アンド・ドロップします。
receiveアクティビティの左にある左矢印をドラッグし、ReadCustomersパートナ・リンクに接続します。
「Receiveの編集」ダイアログが表示されます。
「名前」フィールドにReceiveと入力します。
「Receiveの編集」ダイアログで、「変数」フィールドの右にある「入力変数の自動作成」アイコンをクリックします。
「変数の作成」ダイアログが表示されます。
デフォルトの変数名を選択し、「OK」をクリックします。
「変数」フィールドにデフォルトの変数名が移入されます。
「インスタンスの作成」を選択して「OK」をクリックします。JDeveloperの「File2SP.bpel」ページが表示されます。
receiveアクティビティを追加した後、図9-69に示すようにJDeveloperウィンドウが表示されます。

図9-69 receiveアクティビティの追加

「図9-69 receiveアクティビティの追加」の説明
「ファイル」、「すべて保存」を順番にクリックします。

9.8.2.2.7 assignアクティビティの追加

次に、入力パラメータに値を割り当てる必要があります。

次の手順に従ってassignアクティビティを追加します。

「コンポーネント・パレット」から、assignアクティビティを設計領域のreceiveアクティビティとinvokeアクティビティの間にドラッグ・アンド・ドロップします。
assignアクティビティをダブルクリックします。
「Assign」ダイアログが表示されます。
「一般」をクリックし、「名前」フィールドでCUSTOMERをクリックします。
「コピー操作」タブをクリックします。
図9-70に示すように、「Assign」ダイアログが表示されます。

図9-70 「Assign」ダイアログ - 「コピー操作」タブ

「図9-70 「Assign」ダイアログ - 「コピー操作」タブ」の説明
図9-70に示すように、プラス記号付きのアイコンをクリックして「コピー操作」を選択します。
「コピー操作の作成」ダイアログが表示されます。
「From」領域で、「プロセス」、「変数」、「Receive_Read_InputVariable」および「body」を順番に開きます。
「ns3:InputParameters」を選択します。
「To」領域で、「プロセス」、「変数」、「Invoke_File2SPService_InputVariable」および「InputParameters」を順番に開きます。
「ns3:InputParameters」を選択します。
「OK」をクリックします。図9-71に示すように、Assignダイアログが表示されます。
図9-71 「Assign」ダイアログ

「図9-71 「Assign」ダイアログ」の説明
「OK」をクリックします。
図9-72に示すように、JDeveloperの「File2SP.bpel」ページが表示されます。

図9-72 JDeveloper - File2SP.bpel

「図9-72 JDeveloper - File2SP.bpel」の説明
「ファイル」、「すべて保存」を順番にクリックします。

9.8.2.2.8 サービスとアクティビティのワイヤリング

作成した3つのコンポーネント(インバウンド・アダプタ・サービス、BPELプロセスおよびアウトバウンド・アダプタ参照)をアセンブルまたは接続する必要があります。コンポーネントを接続する手順は、次のとおりです。

「公開されたサービス」領域にあるReadCustomer内の小さい三角形を、「コンポーネント」領域のBPELプロセス内に緑の三角形として表示されるドロップ・ゾーンにドラッグします。
「コンポーネント」領域にあるBPELプロセス内の小さい三角形を、「外部参照」領域のFile2SPService内に緑の三角形として表示されるドロップ・ゾーンにドラッグします。
「ファイル」、「すべて保存」を順番にクリックします。

9.8.2.2.9 JDeveloperを使用したデプロイ

「Oracle JCAアダプタ用のアプリケーション・サーバー接続の作成」で説明されている手順を使用して、アプリケーション・サーバー接続を作成します。
JDeveloperからのOracle JCAアダプタ・アプリケーションのデプロイで説明されている手順を使用して、アプリケーションをデプロイします。

9.8.2.2.10 データソースの作成

File2SPProjectをテストする前に、Oracle WebLogic Server管理コンソールを使用して、次の手順でデータソースを作成する必要があります。

http://servername:portnumber/consoleにナビゲートします。
必要な資格証明を使用して、Oracle WebLogic Server管理コンソールのホーム・ページを開きます。
図9-73に示すように、Oracle WebLogic Server管理コンソールのホーム・ページが表示されます。

図9-73 Oracle WebLogic Server管理コンソールのホーム・ページ

「図9-73 Oracle WebLogic Server管理コンソールのホーム・ページ」の説明
「ドメイン構造」で、「サービス」、「JDBC」を選択し、「データ・ソース」をクリックします。
図9-74に示すように、「JDBCデータ・ソースの概要」ページが表示されます。

図9-74 「JDBCデータ・ソースの概要」ページ

「図9-74 「JDBCデータ・ソースの概要」ページ」の説明
「新規」をクリックします。
「新しいJDBCデータ・ソースの作成」ページが表示されます。
新しいJDBCデータソースの識別に使用するプロパティについて次の値を入力します。
- 「名前」フィールドにMyDataSourceと入力します。
- 「JNDI名」フィールドにjdbc/MyDataSourceと入力します。
- 「データベースのタイプ」にはデフォルト値のOracleを保持します。
- 「データベース・ドライバ」には、デフォルト値のOracle's Driver (Thin XA) for Instance Connections; Versions 9.0.1, 9.2.0, 10, 11を保持します。
「次へ」をクリックします。
「新しいJDBCデータ・ソースの作成 - トランザクション・オプション」ページが表示されます。他のトランザクション構成オプションがないことを示すメッセージが表示されます。
「次へ」をクリックします。
「新しいJDBCデータ・ソースの作成 - 接続プロパティ」ページが表示されます。
「接続プロパティ」ページで、次の接続プロパティを入力します。
- 「データベース名」フィールドに名前(通常はSID)を入力します。
- 「ホスト名」フィールドにホスト名を入力します。
- 「ポート」フィールドにポート番号を入力します。
- 「データベース・ユーザー名」フィールドにSCOTTと入力します。
- 「パスワード」フィールドにTIGERと入力します。
- 「パスワードの確認」フィールドにTIGERと入力します。
「次」を選択します。「新しいJDBCデータ・ソースの作成 - データベース接続のテスト」ページが表示されます。
「構成のテスト」をクリックし、データベースの可用性および指定した接続プロパティをテストします。「新しいJDBCデータ・ソースの作成 - データベース接続のテスト」ページの上部に「接続テストが成功しました。」という内容のメッセージが表示されます。
「次へ」をクリックします。
「新しいJDBCデータ・ソースの作成 - ターゲットの選択」ページが表示されます。
ターゲットとして「AdminServer」を選択し、「終了」をクリックします。
「JDBCデータ・ソースのサマリー」ページが表示されます。このページは、このドメインで作成されたJDBCデータ・ソース・オブジェクトについて要約しています。作成したデータ・ソースがこのリストに表示されます。

9.8.2.2.11 接続インスタンスの追加

データベース・アダプタには、データソースを指すインスタンス・エントリが必要です。

次の手順に従って接続インスタンスを追加します。

beahome/でDbAdapter.rarを検索します。
ファイルを解凍します。

次の例に示すように、META-INF/weblogic-ra.xml(および、場合によってはra.xml)を編集します。

<connection-instance>
                <jndi-name>eis/DB/MyConnection</jndi-name>
                <connection-properties>
                    <properties>
                        <property>
                            <name>xADataSourceName</name>
                            <value>jdbc/MyDataSource</value>
                        </property>
                    </properties>
                </connection-properties>
            </connection-instance>

JNDI名と同じデータベース接続名MyConnectionを使用します。
xADataSourceNameと同じデータソース名MyDataSourceを使用します。
このファイルから再びJARを作成します。
アプリケーション・サーバーを再起動します。
新規データベース・アダプタ・インスタンスは、Oracle WebLogic Server管理コンソールを使用して作成することもできます。

9.8.2.2.12 ファイル・アダプタ・サービスとSQL*Plusを使用したテスト

ファイル・アダプタの入力ファイルを用意して、BPELプロセスをテストする必要があります。BPELプロセスの結果は、表からの単純な問合せを使用して表示されます。customers.xmlファイルには、次の入力が含まれています。

<InputParameters xmlns="http://xmlns.oracle.com/pcbpel/adapter/db/SCOTT/ADD_CUSTOMERS/">
  <C>
    <C_ITEM>
      <FNAME>John</FNAME>
      <LNAME>Doe</LNAME>
      <LOC>
        <STREET>123 Main Street</STREET>
        <CITY>Anytown</CITY>
        <STATE>CA</STATE>
        <ZIP>12345</ZIP>
      </LOC>
      <EMAIL>john.smith@gmail.com</EMAIL>
      <PHONE>567-123-9876</PHONE>
    </C_ITEM>
    <C_ITEM>
      <FNAME>Jane</FNAME>
      <LNAME>Doe</LNAME>
      <LOC>
        <STREET>987 Sunset Blvd</STREET>
        <CITY>Sometown</CITY>
        <STATE>CA</STATE>
        <ZIP>34567</ZIP>
      </LOC>
      <EMAIL>JaneDoe@yahoo.com</EMAIL>
      <PHONE>567-123-9876</PHONE>
    </C_ITEM>
  </C>
</InputParameters>

次の手順に従って、作成したBPELプロセスをテストします。

customers.xmlのコピーを、インバウンド・ファイル・アダプタ・サービスの作成時に指定した入力ディレクトリに置きます。
Oracleファイル・アダプタにより新規ファイルについてディレクトリがポーリングされます。ファイル・アダプタ・サービスによりファイルが受信されると、receiveアクティビティによりBPELプロセスが開始されます。
すべての顧客に関するデータは、ストアド・プロシージャのInputParametersに割り当てられます。
ストアド・プロシージャが実行されます。各顧客のデータが変換され、顧客データが表に挿入されます。

表を問い合せると、次の結果が表示されます。

SQL> select * from customers;

NAME                      LOC
------------------------- ---------------------------------------------
EMAIL                     PHONE
------------------------- ---------------
Doe, John                 123 Main Street, Anytown, CA 12345
john.smith@gmail.com      567-123-9876

Doe, Jane                 987 Sunset Blvd, Sometown, CA 34567
JaneDoe@yahoo.com         567-123-9876

9.8.2.2.13 Fusion Middleware Controlコンソールを使用した監視

Fusion Middleware Controlコンソールを使用して、デプロイ済のEMコンポジットを監視できます。次の手順を実行します。

http://servername:portnumber/emにナビゲートします。
前述の手順で作成したFile2SPProject[1.0]を含めて、SOAコンポジットのリストが表示されます。
「File2SPProject[1.0]」をクリックします。
「ダッシュボード」が表示されます。「最新のインスタンス」領域で「インスタンスID」の値をメモします。
「インスタンス」タブをクリックします。
「検索」ダイアログが表示されます。デフォルトの検索では、すべてのインスタンスがインスタンスIDで表示されます。
書き留めた「インスタンスID」を選択します。
新規ウィンドウが開きます。フォルトがあればそれ(または「フォルトが見つかりません」)が表示され、インスタンスの「監査証跡」を表示できます。インスタンスのトレースが新規ウィンドウに表示されます。
インスタンス・ツリーは、「ReadCustomers」(サービス)、「File2SP」(BPELコンポーネント)、「File2SPService」(参照)へと順番に開かれています。
「File2SP」 BPELコンポーネントをクリックします。
プロセスの「監査証跡」が表示されます。
図9-75に示すように、「<payload>」ノードを開いて、ストアド・プロシージャに提供された入力を確認します。
図9-75 「監査証跡」タブ

「図9-75 「監査証跡」タブ」の説明
さらに、図9-76に示すように、「フロー」タブをクリックしてプロセス・フローを表示します。
図9-76 プロセス・フローの表示

「図9-76 プロセス・フローの表示」の説明

9.8.3 データベース・アダプタ/Coherence統合

Exalogicシステム上のCoherenceキャッシュとともにデータベース・アダプタを使用するとパフォーマンスが向上します。このパフォーマンス向上をもたらす機能は、データベース・アダプタ/Coherence統合と呼ばれます。

Exalogicシステム上のCoherenceキャッシュとともにデータベース・アダプタを使用した場合、2つの特定の使用例で効果が得られます。具体的には、次の操作の実行時にパフォーマンスを向上させることができます。

データベースに対する挿入/更新
主キーによる選択

9.8.3.1 データベースに対する挿入/更新

データベース・アダプタおよびCoherenceキャッシュを使用してデータベースに対して挿入および更新を実行した場合、仲介サービスであるCoherenceデータソースが内部的に使用されてパフォーマンスが向上します(このデータソースはCoherenceキャッシュと呼ばれ、基本的にはインメモリー・データベースに該当します)。

通常、挿入/削除/更新の各操作はデータベースに対して直接実行します。パフォーマンスを向上させるには、この前面に配置されたCoherenceのインメモリー・データベース(write-behindマップ)に対して最初にこれらの操作を実行することで、キャッシュを利用した読取り/書込み操作を有効にします。

注意:

Coherence Write-Behindでのアウトバウンド挿入にデータベース・アダプタを使用する場合は、データベース表に主キー列の索引があることを確認してください。

このようなCoherenceマップを使用すると、挿入/削除/更新の各操作を実行するBPEL/OSBプロセスによって、データベースとのやりとりが行われることなくすぐにコール元に結果が返されるため、これらのプロセスの待機時間が改善します(実際には、かわりにCoherenceキャッシュ仲介サービスによってデータベースが集中的に更新されます)。

大量のレコードをまとめて処理する場合には、この方法でCoherenceを使用して、レコードの更新をより簡単かつ効率的に行うことができます。

注意:

Coherenceキャッシュによる効果が見込めないデータベース・アダプタの使用例には、インバウンド・ポーリング、Pure SQLの起動、ストアド・プロシージャ・コール、複数の行を返す通常のSELECTなどの操作があります。

9.8.3.1.1 選択の最適化

データベース・アダプタ/Coherence統合によって改善する2つ目の使用例は、問合せパフォーマンスであり、特にSELECT文の使用例が最適化されます。データベース・アダプタ/Coherence統合では、多数の異なるプロセス・インスタンスによって頻繁にアクセスされる可能性があるデータをキャッシュすることによって、問合せパフォーマンスを向上させています。

データベース・アダプタ/Coherence統合による選択の最適化を使用した場合、データベース・アダプタでは、問合せを最適化するために、データベースに進む前にまず読取り専用のCoherenceキャッシュ(L2読取りキャッシュ)を使用してキャッシュ・ヒットの有無をチェックします。つまり、問い合せるデータがCoherenceキャッシュ内に存在するかどうかを最初にチェックしてそこに見つからなかった場合に同じデータをデータベース内でチェックする方法によって、問合せを最適化しています。

Coherenceでキャッシュ・ミスが発生した場合、そのデータがデータベースから読み取られてCoherenceキャッシュにロードされます。一般的にキャッシュ・ミスに対するキャッシュ参照の比率は高いため、データベースに対して問合せを実行するよりもCoherenceキャッシュをチェックする方が高速になるということがこの処理の前提になっています。

9.8.3.1.2 Coherenceとデータベース・アダプタの統合による効果が得られない問合せ

すべての問合せにおいてキャッシュ参照、つまりCoherenceとデータベース・アダプタの統合による効果が得られるわけではありません。Coherenceキャッシュにヒットした場合でも、指定した問合せ条件を満たすすべてのレコードがそこに含まれていたかどうかは不明であり、データベース内にヒットする追加のレコードが存在していてもそれがキャッシュ内に存在しなかったために返されなかった可能性もあります。

このため、問合せ最適化機能では、「主キーによる選択」という新しい種類のデータベース・アダプタ操作を利用できます。既存の「選択」およびqueryByExample操作とは異なり、「主キーによる選択」の使用時には1行のみを返すことができます。主キーを選択して1行を返すことで、実際には、より具体的なレコードがCoherenceキャッシュから返されるようにリクエストしていることになるため、キャッシュに対して機能のパフォーマンスが向上します。

9.8.3.2 データベース・アダプタ/Coherence統合のアーキテクチャ

データベース・アダプタ/Coherence統合を使用するかどうかは、データベース・アダプタ・ウィザードの「操作タイプ」画面で「なし」、「読取り」または「読取り-書込み」を選択することによって簡単に指定できます。ただし、データベース・アダプタ/Coherence統合のアーキテクチャに関するいくつかの背景を知っておくことは有益であるため、次の各項ではそれらの詳細について説明します。

EclipseLinkの詳細は、http://www.oracle.com/technetwork/middleware/toplink/documentation/index.htmlを参照してください

Coherenceに関するいくつかの背景は、http://www.oracle.com/technetwork/middleware/coherence/overview/index.htmlに記載されています

9.8.3.2.1 WebLogic Server 10.3.5とのCoherenceデータベース・アダプタ統合の使用

WebLogic Server 10.3.5とともにCoherenceデータベース・アダプタを使用するには、次の手順を実行する必要があります。

WebLogic Server 10.3.5とともにOracle 11.1.1.7.1 SOA Suiteをインストールします。
SOAインストールでDbAdapter.rarを検索します。
```
cd $BEAHOME/AS11gR1SOA/soa/connectors
mkdir tmp
```
バンドルされた10.3.6バージョンのtoplink-grid.jarをDbAdapter.rarから次のように削除します。
```
unzip DbAdapter.rar -d tmp
cd tmp
rm toplink-grid.jar 
```

既存のマニフェストとともにDbAdapter.rarを再構築します。これにより、共有ライブラリのTopLink Gridを検索します。

cd $BEAHOME/AS11gR1SOA/soa
cd $BEAHOME/AS11gR1SOA/soa/connectors
mkdir tmp
jar cvmf META-INF/MANIFEST.MF DbAdapter.rar *
mv DbAdapter.rar ..
cd .. 
rm -rf tmp

$BEAHOME/modules/com.oracle.toplinkgrid_1.0.0.0_11-1-1-5-0.jarをtoplink-gridという名前の共有ライブラリとしてWebLogic Serverホスト・コンソールからデプロイします。
toplink-gridという名前の共有ライブラリ(「デプロイメント」→「インストール」)から行います。
WebLogic Serverを再起動します。

9.8.3.2.2 データベース・アダプタの現在の設計(Coherenceキャッシュなし)

データベース・アダプタの現在の設計では、アダプタによって選択および挿入をEclipseLinkレイヤーに対して実行し、そこからCoherenceキャッシュなしで直接データソースと通信します。

データベース構成ウィザードの「操作タイプ」画面で「キャッシュの使用方法」ドロップダウンから「なし」を選択することで、キャッシュを使用しないように指定できます。

9.8.3.2.3 読取り/書込み用Coherenceキャッシュとデータベース・アダプタの統合

データベース・アダプタ・ウィザードの「操作タイプ」画面で「キャッシュの使用方法」ドロップダウンから「読取り-書込み」を選択すると、読取り/書込みキャッシュを使用できます。

EclipseLinkは2つのレイヤー内にあり、これらの2つのレイヤー間にCoherenceキャッシュ(Coherenceキャッシュ・ストア)があります。実際にはEclipseLinkプロジェクトは1つだけですが、そのプロジェクトのコピーが2つ存在します。

EclipseLinkの上側のコピーでは、データ・ストアからの挿入/選択の問合せはすべてCoherenceキャッシュにリダイレクトされます。
EclipseLinkの下側のコピーでは、Coherenceキャッシュからのリクエストを処理し、IDに基づいてデータベースから特定のレコードをロードするかデータベースに特定のレコードを格納します。

読取り/書込みシナリオで選択を実行する場合、取得する行が一意に識別されない可能性があります。

たとえば、SELECT *またはSELECT where total gross > ?などがこれに該当します

write-behind Coherenceキャッシュでは、IDに基づいてレコードをロードするためのリクエストのみを受信できます。そのため、これらのいずれの場合においても、すべての問合せがCoherenceキャッシュに向けられると、返される結果が0になります。この場合は、問合せがデータソースに対して直接行われ、その後Coherenceキャッシュが更新されます。

9.8.3.2.4 読取り用Coherenceキャッシュとデータベース・アダプタの統合

データベース・アダプタ・ウィザードの「操作タイプ」画面で「キャッシュの使用方法」ドロップダウンから「読取り」を選択すると、読取りキャッシュを使用できます。

読取りキャッシュでは、データベース・アダプタによってデータベースにレコードを挿入する場合、またはデータベースからレコードを選択する場合に、Coherenceキャッシュが更新されます。行を識別する(つまり、主キーを指定する)すべての問合せにおいて、まずCoherenceキャッシュがチェックされ、可能な場合にデータベースとのやりとりが回避されます。Coherenceキャッシュは分散型の単なるハッシュ・マップとみなすことができるため、特定の主キーを選択することで、Coherenceキャッシュ・マップを通じたルックアップの高速化が可能になります。

9.8.3.2.5 「操作タイプ」画面を使用したキャッシュなしの有効化

図9-77は、データベース・アダプタ・ウィザードの「操作タイプ」画面に表示されたキャッシュなしオプション(「なし」を選択)を示しています。

図9-77 キャッシュなしが選択されたデータベース・アダプタ構成ウィザードの「操作タイプ」画面

「図9-77 キャッシュなしが選択されたデータベース・アダプタ構成ウィザードの「操作タイプ」画面」の説明

この画面では「なし」オプションが選択されており、すべてのアウトバウンド操作が有効です。このオプションを選択して「次へ」または「終了」を選択すると、選択した操作のいずれにもプロパティCacheUsageは含まれなくなります。このプロパティが存在しない状態は、JCAアクティブ化プロパティCacheUsageが値noneになっているのと同じです。

「キャッシュの使用方法」として「なし」オプションを選択した場合、次のオプションの操作のみが事前に選択されます。

マージ
挿入のみ
選択

9.8.3.2.6 「操作タイプ」画面を使用した読取り/書込みキャッシュの有効化

「操作タイプ」画面では、読取り/書込みキャッシュを有効化できます。図9-78を参照してください。このオプションを選択して「次へ」または「終了」を押すと、JCAプロパティCacheUsageの値がread-writeに設定されます。

図9-78 「操作タイプ」画面を使用した読取り/書込みキャッシュの有効化

「図9-78 「操作タイプ」画面を使用した読取り/書込みキャッシュの有効化」の説明

この画面で「キャッシュの使用方法」ドロップダウンから「読取り-書込み」オプションを選択した場合の各操作の使用方法を理解するには、次のリストを参照してください。

「挿入または更新(マージ)」は有効であり、ラベルの末尾には「キャッシュの使用」という文字列が付加されます。
「挿入のみ」は無効であり、基礎となるキャッシュ・ストアによって常にマージが実行されます。
「更新のみ」は無効であり、基礎となるキャッシュ・ストアによって常にマージが実行されます。
「削除」は選択可能ですが、事前には選択されておらず、選択すると末尾に「キャッシュの使用」という文字列が付加されます。
「選択」は無効であり、この問合せは、Coherenceマップで実行されるCoherenceフィルタに変換されます。
「例による問合せ」は無効であり、データベース・アダプタ/Coherence統合の問合せは、Coherenceマップで実行されるCoherenceフィルタに変換されます。
「主キーによる選択」のラベルの末尾には、「キャッシュの使用」という文字列が付加されます。

9.8.3.2.7 「操作タイプ」画面を使用した読取りキャッシュの有効化

「操作タイプ」画面の「キャッシュの使用方法」オプションを使用すると、読取りキャッシュを有効化できます。図9-79を参照してください。画面上でこのオプションを選択して「次へ」または「終了」を押すと、JCAプロパティCacheUsageの値がreadに設定されます。

図9-79 「操作タイプ」画面を使用した読取り/書込みキャッシュの有効化

「図9-79 「操作タイプ」画面を使用した読取り/書込みキャッシュの有効化」の説明

読取りキャッシュ・オプションでは、「主キーによる選択」操作のみが事前に選択されています。他の操作でキャッシュを更新することは可能ですが、キャッシュを通じたCoherenceとデータベース・アダプタの統合機能によって実行する意味がある操作は「主キーによる選択」のみです。読取りキャッシュはキャッシュの変更を伴わないため、この画面の「操作タイプ」の各操作は無効になります。

「選択」および「例による問合せ」は無効にはなりませんが、キャッシュは直接更新されません。データベース・アダプタ/Coherence統合機能では「選択」をデータベースに対して実行しますが、返される任意の行でCoherenceキャッシュを更新します。

読取りキャッシュの一般的な操作では、返されたオブジェクトがCoherenceキャッシュに存在した場合、データベース・アダプタ/Coherence統合機能により結果セットから新しいコピーが作成されるのではなくキャッシュ内のオブジェクトが返されます。

この操作により、マスター・データベース・レコードに複数の詳細がある場合に、その詳細に対する問合せを再度行う必要がないため、パフォーマンスが向上します。

問合せの動作は「選択」と同じになります。たとえば、主キーが設定されている(キャッシュ・ヒットが得られない)XMLデータにこれが当てはまります。

9.8.3.2.8 Coherence/データベース・アダプタ統合でのXAトランザクション、読取り/書込みおよび読取り操作

データベース・アダプタ/Coherence統合を使用している場合、XAトランザクションを読取り/書込み操作とともに使用することはできません。これは、データベース・アダプタをCoherenceと統合した場合、挿入がCoherenceキャッシュ、データベースの順に実行されますが、この順番がXAトランザクションの規定に違反するためです。

ただし、データベース・アダプタ/Coherence統合を使用して、XAトランザクションを読取り操作とともに使用することはできます。

データベース・アダプタ/Coherence統合を伴わない、データベース・アダプタを使用したデータベース・トランザクションでも、引き続きXAトランザクション・モデルを使用できます。

9.8.3.2.9 Coherenceキャッシュのライフサイクルおよび構成

cacheUsageの「読取り」または「読取り-書込み」を使用してコンポジット・アプリケーションを含むデータベース・アダプタをデプロイする場合は、専用のCoherenceキャッシュが作成されます。その名前は、DbAdapter/WriteBehindCache/<serviceName>/<tableName>(「読取り-書込み」キャッシュの場合)またはDbAdapter/L2Cache/<serviceName>/<tableName>(「読取り」キャッシュの場合)になります。

このキャッシュ名は、次のとおり、or-mappings.xmlに適切に格納されます。

<properties> 
<property name="eclipselink.coherence.cache.name"> 
<value>DBAdapter/WriteBehindCache/insertReference.Movies</value> 
</property> 
</properties>

2つのキャッシュ構成テンプレートは、fabric-runtime.jarにあるsoa-coherence-cache-config.xmlで定義されています。1つのテンプレートはDbAdapter/WriteBehindCache/(読取り-書込み)で始まるすべてのキャッシュ名に対応し、もう1つのテンプレートはDbAdapter/L2Cache (読取り)で始まるすべてのキャッシュ名に対応します。

これらの定義を編集するか、or-mappings.xml内のキャッシュ名を変更することで、新しい定義を作成できます。次の例に、soa-coherence-cache-config.xmlで定義されている2つのテンプレートを示します。

例 - soa-coherence-cache-conifg.xmlのテンプレート

<cache-mapping> 
 <cache-name>DBAdapter/WriteBehindCache/*</cache-name> 
   <scheme-name>db-adapter-write-behind-cache</scheme-name> 
</cache-mapping> 
<cache-mapping> 
  <cache-name>DBAdapter/L2Cache/*</cache-name> 
  <scheme-name>db-adapter-l2-cache</scheme-name> 
</cache-mapping> 
 
<distributed-scheme> 
<scheme-name>db-adapter-write-behind-cache</scheme-name> 
<backup-count-after-write-behind>0</backup-count-after-write-behind> 
<!-- for DbAdapter must be true on SOA nodes and false on dedicated Coherence nodes.--> 
<local-storage>true</local-storage> 
<thread-count>1</thread-count> 
<task-hung-threshold>20000</task-hung-threshold> 
<backing-map-scheme> 
<read-write-backing-map-scheme> 
 
<internal-cache-scheme> 
<local-scheme> 
<eviction-policy>HYBRID</eviction-policy> 
<high-units>10000</high-units> 
<low-units></low-units> 
<unit-calculator>FIXED</unit-calculator> 
<expiry-delay>120s</expiry-delay> 
</local-scheme> 
</internal-cache-scheme> 
<cachestore-scheme> 
<class-scheme> 
<class-name>oracle.tip.adapter.db.toplinkext.coherence.DBAdapterCacheStore</class-name> 
<init-params> 
<init-param> 
<param-type>java.lang.String</param-type> 
<param-value>{cache-name}</param-value> 
</init-param> 
</init-params> 
</class-scheme> 
</cachestore-scheme> 
<write-delay>5s</write-delay> 
<write-batch-factor>0.1</write-batch-factor> 
<write-requeue-threshold>1000</write-requeue-threshold> 
</read-write-backing-map-scheme> 
</backing-map-scheme> 
<autostart>false</autostart> 
</distributed-scheme> 
 
<distributed-scheme> 
<scheme-name>db-adapter-l2-cache</scheme-name> 
<!-- for DbAdapter must be true on SOA nodes and false on dedicated Coherence nodes.--> 
<local-storage>true</local-storage> 
<thread-count>4</thread-count> 
<task-hung-threshold>500</task-hung-threshold> 
<backing-map-scheme> 
<local-scheme> 
<eviction-policy>HYBRID</eviction-policy> 
<high-units>1000</high-units> 
<low-units>1000</low-units> 
<unit-calculator>FIXED</unit-calculator> 
<expiry-delay>120s</expiry-delay> 
</local-scheme> 
 
</backing-map-scheme> 
<autostart>true</autostart> 
</distributed-scheme> 
</caching-schemes>

独自の定義を定義している場合は、local-storage trueを設定する必要があります。

オブジェクトのライフサイクルは、CacheUsageか有効化されたプロジェクトによって異なります。第1に、更新されたor-mappings.xmlファイルで同じコンポジットが再デプロイされたとしても、コンポジット・アプリケーションと関連付けられたEclipseLinkプロジェクト(or-mappings.xml)がロードされるのは1回のみです。通常、コンポジットの各デプロイメントは、すべてのアーティファクトをクリーンに再デプロイしたものとなります。

第2に、CacheUsageコンポジットをアンデプロイしてもCoherenceキャッシュは破棄されません。手動で行う必要があります。つまり、コンポジットは再デプロイが可能で、基礎となるCoherenceキャッシュも、再デプロイの前に所有していたコンテンツとともに残すことができます。他のデータベース・アダプタのユース・ケースとは異なるため、複数のデータベース・アダプタ参照を1つまたは複数のコンポジット間で所有して、同じCoherence名のキャッシュに接続できます。

したがって、EclipseLinkプロジェクトのライフサイクル(or-mappings.xml)およびCoherenceキャッシュは、コンポジットのリビジョン/デプロイメントではなくWebLogic Applicationサーバーの再起動に基づきます。

最後に、データベース・アダプタでは、データ・ストアに挿入するオブジェクトの表示に実際のJavaクラスではなくバイトコード生成を使用します。これにより、データベース・アダプタの外部で、同じCoherence NamedCacheにプログラムで直接接続することが難しくなります。これは、クラスの定義がデシリアライゼーションに簡単に使用できないためです。ただし、前述のとおり、類似したor-mappings.xmlプロジェクトを持つ複数のデータベース・アダプタ参照では同じCoherenceキャッシュを共有できます。

9.8.3.3 例による問合せ

例による問合せを使用すると、問合せで使用する属性のみを移入したサンプル・オブジェクト・インスタンスの形式で、問合せ選択基準を指定できます。EclipseLinkの例による問合せサポートには、ユーザーが変更できる例による問合せポリシーも含まれています。EclipseLinkユーザーは、このポリシーを編集して、例による問合せのデフォルト動作を変更できます。

データベース・アダプタは、基本的に、例による問合せ操作の基本セットを提供して、例による問合せポリシーの実装またはカプセル化を提供します。次の操作のタイプが含まれます。

LIKEなどの演算子を使用して、属性を比較する場合。デフォルトでは、例による問合せで使用できるのはEQUALSのみです。
例による問合せで無視される値のセット(IGNOREセット)を変更する場合。デフォルトで無視される値は、ゼロ(0)、空の文字列およびFALSEです。
属性の値がIGNOREセットに含まれるものであっても、例による問合せでその値を強制的に考慮する場合。
属性値としてisNullまたはnotNullを使用する場合。(ただし、「使用に関する制約事項」を参照)。

データベース・アダプタでは、データベース・アダプタ構成ウィザードの高度な操作画面で使用可能な既存の操作と値に、追加の操作と値を追加して、この機能が提供されます。

データベース・アダプタ構成ウィザードで「例による問合せ」オプションを選択すると、追加の問合せを使用するか、または問合せと作成した他の問合せを組み合せることができます。

注意:

QueryByExampleでは、複数の表の使用はサポートされません。関連表の場合は、例による問合せに対してPureSQLを使用する方が適切です。

図9-80 「例による問合せ」が選択されたデータベース・アダプタ構成ウィザードの「操作タイプ」画面

「図9-80 「例による問合せ」が選択されたデータベース・アダプタ構成ウィザードの「操作タイプ」画面」の説明

DBReadinteractionSpecにdb.jca.propertiesが追加されている次のタイプの問合せ内で、次の問合せを示されているとおりに使用できます。

QueryByExampleTextOperator
QueryByExampleNumericOperator
QuerybyExampleDateOperator

これらのタイプの各問合せに、次の例による問合せの値のいずれか1つを設定できます。

equal
notEqual
equalsIgnoreCase
lessThan
lessThanEqual
greaterThan
greaterThanEqual
like
likeIgnoreCase
containsAllKeyWords
containsAnyKeyWords
containsSubstring
containsSubstringIgnoringCase

JDeveloper UIで、任意の問合せおよび問合せが実行できる操作を選択できます。高度な操作画面の各操作には、比較演算子のドロップダウン・リストがあります。図9-81を参照してください。

図9-81 「例による問合せ比較演算子」に「lessThan」が指定されたデータベース・アダプタ構成ウィザードの高度な操作画面

「図9-81 「例による問合せ比較演算子」に「lessThan」が指定されたデータベース・アダプタ構成ウィザードの高度な操作画面」の説明

数値のlikeIgnoreCaseなど、一部の組合せは意味をなしていませんが、使用に対する制限は設定されていません。

リストされているパラメータ演算子だけでなく、org.eclipse.persistence.expressions.Expressionにある単一のパラメータ演算子を選択できます。これらの演算子のいずれか1つを設定するには、JCAファイルを直接編集します。

「equal」はデフォルトであるため、終了を選択したときに値がJCAファイルに表示されません。これらのプロパティがない古いプロジェクトには、自動的に追加されます。

9.8.3.3.1 例による問合せと通常の問合せの組合せ

JDev式ビルダーと例による問合せを組み合せて使用できます。たとえば、問合せがWHERE some_column IS NOT NULL操作を実行する場合は、この最初の操作を通常のSelectを使用してモデル化し、例による問合せ操作も選択できます。JCAファイルで、次の選択操作のQueryNameプロパティを例による問合せ操作にコピーします。

<property name="IsQueryByExample" value="true"/>
<property name="QueryName" value="dbReferenceSelect"/>

例による問合せとは異なり、アクティブ化ファイルに操作をコピーする必要はありません。

9.8.3.3.2 使用に関する制約事項

レコード例に次が含まれる場合、

<someOtherColumn>someOtherValue</someOtherColumn>

生成されるSQLは次のようになります。

WHERE some_column IS NOT NULL AND some_other_column = 'someOtherValue'

これは、通常のSelect文に入力パラメータがない場合にのみ使用できます。

オブジェクト例の特定の列に重要なNULLを指定できるQueryByExampleポリシーは、現在サポートされていません。

NULL属性は無視されますが、EclipseLinkサポートによって、その他の2つのAPIの組合せによってIS NULLおよびIS NOT NULLを生成できます。これらのAPIは公開されませんが、これらの文を通常の問合せと組み合せて使用できます。重要な値(NULL以外)が含まれている場合でも、特定の列を常に除外するAPIはありません。明示的な問合せを作成する方が適切です。

9.8.3.4 UTF16文字データ挿入のor-mappings.xmlファイルの変更

UTF16でデータベース・アダプタを使用して、WE8DEなど、AL16UTF16以外の文字セットを使用するデータベースにデータを挿入する場合、自動文字変換によって誤ったデータがデータベースに挿入されます。解決策は、JDeveloperアダプタ構成ウィザードで生成された-or-mappings.xmlファイルを変更することです。制限の1つとして、使用しているOracle DatabaseのバージョンがOracle 9 Database以降である必要があります。

示されている解決策を実行するには、次の手順を実行します。

プロジェクトのファイル・システムで-or-mappings.xmlファイルを検索し、エディタで開きます(デフォルトではJDeveloperを使用してこのファイルを変更することはできません)。
<attribute-name>field name</attribute-name>でUTF16文字が含まれているデータベース・ファイルを検索します。

次の属性があります

 <attribute-classification>java.lang.String</attribute-classification>

これを次のように置換します

<attribute-classification>org.eclipse.persistence.platform.database.oracle. NString</attribute-classification>

プロジェクトを保存し、再デプロイします。

-or-mappings.xmlファイルは、データベース・アダプタ構成ウィザードによって自動的に生成されるため、データベース・アダプタ構成ウィザードの実行時にこれらの手順を繰り返す必要があります。

9 Oracle JCA Adapter for Database

9.1 Oracleデータベース・アダプタの概要

9.1.1 機能概要

9.1.1.1 Oracleデータベース・アダプタとOracle BPEL PMの統合

9.1.2 設計の概要

9.2 データベース・アダプタ構成ウィザードの概要

9.2.1 アプリケーションおよびSOAプロジェクトの作成

9.2.2 Oracleデータベース・アダプタの定義

9.2.3 データベースへの接続

9.2.4 操作タイプの選択

9.2.5 表の選択およびインポート

9.2.6 主キーの定義

9.2.6.1 主キーとしてのROWIDの使用

9.2.6.1.1 「主キー」ページでのROWIDの使用

9.2.7 リレーションシップの作成

9.2.7.1 リレーションシップが作成または削除された際の動作

9.2.7.2 様々なタイプの1対1マッピング

9.2.7.3 外部キーが主キーである場合

9.2.8 属性フィルタの作成

9.2.9 WHERE句の定義

9.2.10 読取り後戦略の選択

9.2.10.1 読取り済の行の削除

9.2.10.2 表のフィールドの更新(論理削除)

9.2.10.3 順序表の更新

9.2.10.4 異なるデータベースにある外部順序表の更新

9.2.10.5 順序ファイルの更新

9.2.11 ポーリング・オプションの指定

9.2.12 詳細オプションの指定

9.2.13 Pure SQL操作に必要なSQL文字列の入力

9.3 Oracleデータベース・アダプタの機能

9.3.1 トランザクション・サポート

9.3.1.1 グローバル・トランザクションへの関与のためのOracleデータベース・アダプタの構成

9.3.1.2 両方を同じグローバル・トランザクションで起動

9.3.1.3 失敗時のロールバックが必須

9.3.1.3.1 両方の起動に対する同一セッションの使用

9.3.1.4 トランザクション/XAサポート

9.3.1.4.1 グローバル・トランザクションに関与するようにOracleデータベース・アダプタを構成

9.3.1.4.2 失敗時のロールバックが必須

9.3.2 Pure SQL - XMLタイプのサポート

9.3.3 強い型指定のXSDまたは弱い型指定のXSDを使用した行セットのサポート

9.3.4 プロキシ認証のサポート

9.3.5 大きなペイロードのストリーミング

9.3.6 スキーマ検証

9.3.7 高可用性

9.3.8 スケーラビリティ

9.3.8.1 分散ポーリングのベスト・プラクティス1: SELECT FOR UPDATE (SKIP LOCKED)

9.3.8.1.1 SKIP LOCKEDの詳細

9.3.8.1.2 Oracle以外のデータベース

9.3.8.1.3 PollingInterval、MaxTransactionSizeおよびActivationInstancesの詳細な構成

9.3.8.1.4 パーティション・フィールド

9.3.8.1.5 activationInstances

9.3.8.1.6 索引付けおよびNULL値

9.3.8.1.7 ロッキングのスキップの無効化

9.3.8.1.8 MarkReservedValueとロッキングのスキップ

9.3.8.1.9 SequencingPollingStrategy (最終読取りまたは最終更新)

9.3.8.2 分散ポーリングのベスト・プラクティス2: 最初に単一ノードをチューニングする

9.3.9 パフォーマンス・チューニング

9.3.10 detectOmissions機能

9.3.11 OutputCompletedXml機能

9.3.12 インバウンドおよびアウトバウンド・トランザクションのQueryTimeout

9.3.13 BPELへの同期ポストの実行(順序配信の許可)

9.4 Oracleデータベース・アダプタの説明

9.4.1 リレーショナルからXMLへのマッピング

9.4.1.1 リレーショナル型からXMLスキーマ型へ

9.4.1.2 任意のリレーショナル・スキーマの任意のXMLスキーマへのマッピング

9.4.1.3 複数の表の問合せ

9.4.1.3.1 リレーションシップの問合せを使用する方法(TopLinkのデフォルト)

9.4.1.3.2 オリジナルのselectを利用する方法(TopLinkのバッチ属性読取り)

9.4.1.3.3 単一結果セットを戻す方法(TopLinkの結合属性読取り)

9.4.1.3.4 複数の表の問合せに使用した方法の比較

9.4.2 WebサービスとしてのSQL操作

9.4.2.1 DML操作

9.4.2.2 ポーリング戦略

9.5 データベース・アダプタ・デプロイメント

9.5.1 サード・パーティ・データベースを使用したデプロイメント

9.6 JDBCドライバとデータベース接続の構成

9.6.1 ネイティブまたはバンドルされたOracle WebLogic Server JDBCドライバを使用したデータベース接続の作成

9.6.2 サード・パーティJDBCドライバを使用したデータベース接続の作成

9.6.3 サード・パーティJDBCドライバおよびデータベース接続情報の概要

9.6.3.1 Microsoft SQL Serverの使用方法

9.3.10 `detectOmissions`機能

9.3.11 `OutputCompletedXml`機能