Oracleデータベース・アダプタを使用すると、SOAコンポジット・アプリケーションでJDBCを介してOracle Databaseまたはサード・パーティ・データベースと通信できます。
この項では、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データベース・アダプタの詳細は、次の各項を参照してください。
Oracleデータベース・アダプタは、データベース・イベントのポーリング(通常は入力表に対するINSERT
操作)とプロセスの開始を行うために使用される場合、公開サービスと呼ばれます。Oracle BPELプロセスでは、Oracleデータベース・アダプタはreceiveアクティビティに関連付けられるパートナ・リンクです。通常は、式inbound
(データベースからSOAへ)が使用されます。
Oracleデータベース・アダプタは、INSERT
またはSELECT
などの1回かぎりのDML文の起動用として使用される場合、メディエータ・コンポーネントまたはSOAコンポーネントでは、サービス参照と呼ばれます。Oracle BPELプロセスでは、Oracleデータベース・アダプタはinvokeアクティビティに関連付けられたパートナ・リンクです。式outbound
(SOAからデータベースへ)が使用されます。
この項では、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コンポジットのアダプタ成果物
ファイル | 説明 |
---|---|
|
これは、操作および入出力XML要素の名前によってサービス・エンドポイントを定義する抽象WSDLです。 |
|
これには、これらの入出力XML要素のXMLファイル・スキーマが含まれます。これらの両ファイルは、SOAプロジェクトの残りへのインタフェースを形成します。 |
|
これは内部ファイルです。リレーショナル・スキーマとXMLスキーマ間のマッピングを記述するために使用されるTopLink固有のファイルです。これは実行時に使用されます。 |
|
これには、抽象WSDLの内部実装詳細が含まれます。これには、場所と操作に関する2つのメイン・セクションがあります。場所は、アダプタ・インスタンスのJNDI名( |
|
これも内部ファイルです。表のインポート時に作成され、表に関する情報が保存されます。設計時にのみ使用されます。 実行時には、前述の場所を使用して、サービスを実行するアダプタ・インスタンスが参照されます。 |
アダプタ構成ウィザードを概観し、アダプタ構成ウィザードでOracleデータベース・アダプタを定義する方法を学びます。
この項では、Oracleデータベース・アダプタの様々な概念を使用例を通じて説明します。これにより、アダプタ構成ウィザードの概要を示します。さらに、この使用例では、アダプタ構成ウィザードを使用して、データベースからの表のインポート、複数の表にわたるリレーションシップの指定、対応するXMLスキーマ定義の生成、および必要なSQLまたはデータベース操作を公開するサービスの作成を行う方法についても説明します。これらのサービスは、BPELプロセスで使用されるパートナ・リンクの定義に使用されます。アダプタ・サービスの作成および編集のどちらにもアダプタ構成ウィザードを使用します。
SOAコンポジットを含んだOracle JDeveloper (JDeveloper)アプリケーションを作成する必要があります。次の手順に従ってアプリケーションとSOAプロジェクトを作成します。
次のステップは、Oracleデータベース・アダプタ・サービスを定義することです。次の手順に従ってOracleデータベース・アダプタ・サービスを作成します。
アダプタ構成ウィザードの使用を続行するには、「データベースへの接続」を参照してください。
図9-7に、サービスで使用するデータベース接続を選択する場所を示します。これは、サービスを構成する表をインポートするデータベースです。これは、サービスを構成する表をインポートするデータベースです。ここで、作成する新しいJDeveloperアプリケーションごとにデータベースを再作成できます。
データベース接続を識別するJava Naming and Directory Interface (JNDI)の名前を指定できます。デフォルト名はeis/DB/<ConnectionNameInJDev>
です。
詳細は、「データベース・アダプタ・デプロイメント」を参照してください。
次の点に注意してください。
本番環境では、アダプタのデプロイメント・ディスクリプタ(weblogic-ra.xml
)にJNDIエントリを追加することをお薦めします。この場合、管理モードで作業することでOracleデータベース・アダプタのパフォーマンスが向上します。
データソースとアウトバウンド接続プールの作成の詳細は、「アダプタ・コネクション・ファクトリの追加」を参照してください。
「次へ」をクリックすると、データベースへの接続が試行されます。接続できない場合は、既存のパートナ・リンクを編集している場合でも、次のウィンドウには進めません。
アダプタ構成ウィザードの使用を続行するには、「操作タイプの選択」を参照してください。
図9-8に、このサービスに構成する操作タイプを指定する場所を示します。
次の操作タイプを使用できます。
ストアド・プロシージャまたはファンクションの呼出し
サービスでストアド・プロシージャまたはファンクションを実行する場合にこのオプションを選択します。詳細は、「ストアド・プロシージャおよびファンクションのサポート」を参照してください。
表に対して操作を実行
このオプションは、アウトバウンド操作に対して選択します。「挿入/更新」、「挿入のみ」、「更新のみ」、「削除」、「選択」またはこの6つのオプションを任意に組み合せて選択できます。これらの操作は、同等のSQL操作であるMERGE
、INSERT
、UPDATE
、DELETE
およびSELECT
に変換されます。
詳細は、「DML操作」を参照してください。
注意:
「更新のみ」操作では、子レコードに対する挿入または削除が実行されることがあります。これは、マスターの更新に伴い、ディテールが追加または削除されることがあるためです。したがって、更新対象の入力に含まれるディテール・レコードが1つのみの場合は、表内の他のディテール・レコードが削除されます。
表の新規レコードまたは更新されたレコードをポーリング
この操作は、インバウンド操作(つまり、receiveアクティビティと関連付けられている操作)に対して選択します。この操作タイプでは、指定された表がポーリングされ、追加された任意の新しい行の処理用に返されます。また、ポーリング間隔も指定できます。
詳細は、「ポーリング戦略」を参照してください。
図9-9に示すように、データベースからデータが読み取られた後に実行できるポーリング操作は次のとおりです。
Pure SQLの実行
任意の複雑な文、集計問合せ(結果は行ベースではありません)およびXMLType
列を処理する場合に役立ちます。アダプタ構成ウィザードのこの使用方法は、「Pure SQL - XMLタイプのサポート」を参照してください。
注意:
スキーマ・バインドXML表はサポートされていません。
アダプタ構成ウィザードのこれ以外の使用方法は、「表の選択およびインポート」を参照してください。
図9-10に、操作のルート・データベース表を選択する場所を示します。複数の関連する表を使用している場合は、これがリレーションシップ・ツリーの最上位の表(または最上位の親表)になります。
「表のインポート」を選択すると、サブウィザードが起動します。このウィザードで、データベースからインポートする複数の表を検索および選択できます。表を削除すると、残された関連する表にあるリレーションシップが削除されます(元に戻されます)。このウィザードを編集モードで実行している間に基礎となる表が変更された場合、その変更内容を示す警告が表示されます。調整するには、表を再度インポートします。「表のインポート」をクリックして複数の表を選択すると、外部キーの制約に基づいてそれらの表の間のリレーションシップが推測されます。ただし、インポートした表ごとに「表のインポート」を起動する場合は、リレーションシップは推測されません。
注意:
表を再インポートすると、その表に対して任意で定義したカスタムのリレーションシップとカスタムWHERE
句はすべて失われます(インポートする表がルート表の場合)。
アダプタ構成ウィザードの使用を続行するには、「主キーの定義」を参照してください。
インポートした表にデータベースで定義された主キーがない場合、図9-11に示すように、各表に主キーを指定するよう求められます。インポートしたすべての表に主キーを指定する必要があります。複数のフィールドを選択すると、マルチパートの主キーを指定できます。
ここで指定する主キーは、オフライン・データベース表に記録され、データベース・スキーマには保存されないため、データベース・スキーマは変更されません。
アダプタ構成ウィザードの使用を続行するには、「リレーションシップの作成」を参照してください。
注意:
Oracleデータベース・アダプタでは、主キーが定義されている表のみがサポートされることに注意してください。表で主キー制約が明示的に定義されていない場合は、設計時にアダプタ構成ウィザードを使用してOracleデータベース・アダプタを定義する際に指定する必要があります。有効な主キーを指定しなければ、一意の制約は保証されず、これにより実行時にメッセージが失われる可能性があります。つまり、重複する主キー値を持つ行が失われる可能性があります。また、主キーが100バイト未満であることを確認する必要があります。
注意:
主キー列にはchar
ではなくvarchar
を使用することをお薦めします。charを使用する場合は、weblogic-ra.xml
プロパティのshouldTrimStrings
をfalse
に設定する必要があります。後続のスペースが切り捨てられることによって主キーが不適切に読み取られ、読取り行を処理済として更新できなくなることがあります。
Oracleデータベース・アダプタのROWIDサポートによって、ROWIDを特定のサポート対象の操作の主キーとして選択できます。
主キー制約がない表をインポートすると、行を一意に識別するために使用できる一連の列を選択するよう求められます(図9-12を参照)。統合シナリオの場合、ターゲット・スキーマに関する知識がより必要となることがあり、エラーが発生する可能性があります。たとえば、ここで一意でない列を選択すると、意図しない複数の行を更新する操作、または一部の行を2回返しその他の行は返さない選択となる可能性があります。
Oracle Databaseでは、エラーが発生しにくいROWID疑似列を主キーとして使用するよう選択できます。ROWIDは直接物理アドレスであるため、通常の索引よりも高速である場合があります。
ROWIDは、Oracle表の疑似列です。疑似列は、ユーザーが直接更新できない列であり、ユーザーが作成した列ではありません。また、疑似列は列のメタデータ・ビューに表示されず、select *問合せから返されます。
ROWIDの使用には、特定の制限があります。このような場合は、ユーザー・インタフェースのオプションがグレー表示され、選択できません。
ROWIDは、行を一意に識別する必要がない操作(挿入、選択)または同じトランザクションですでに読み取られている行のみを識別する必要がある操作(ほとんどのポーリング操作)に対してのみ使用できます。物理アドレスはデータベースの外部で意味を持たず、行の一部ではない(値がトランザクション内で安定している)ため、行自体の列を使用して行を一意に識別する必要がある操作では使用できません(マージ、削除、主キーによる選択)。
表間のリレーションシップでは行に明示的な主キーが必要なため、ROWIDは、単一の表との組合せでのみ使用できます。
ROWIDサポートは、Pure SQLまたはストアド・プロシージャには適用されません。
主キー・セットのない表をインポートすると、ウィザードに「主キー」ページが表示されます。図9-12を参照してください。
このページでは、次のいずれかを実行できます。
主キーを構成する列を選択するラジオ・ボタンをクリックして、主キーを作成する列を選択します。
主キーとして、疑似列ROWIDを使用するラジオ・ボタンをクリックして、主キーとしてROWIDを選択します。
この場合も、ROWIDは、インバウンド・ポーリング、挿入または選択操作でのみ使用できます。
主キーを構成する列を選択する場合は、各列の横に、NOT NULL
、INDEXED
、AUTO INCREMENT
、UNIQUE INDEXED
などの可能なヒントが表示されます。
後者の場合、列のチェック・ボックスがデフォルトで自動的に選択され、確認するよう求められます。
図9-13に、ルート・データベース表およびその他の関連する表に定義されたリレーションシップを示します。「リレーションシップの作成…」をクリックして2つの表の間にリレーションシップを作成したり、「リレーションシップの削除」をクリックしてリレーションシップを削除できます。リレーションシップの名前を変更するには、「リレーションシップの名前変更」をクリックします。
リレーションシップの作成に関して次の事項に注意してください。
データベース上に表間の外部キー制約が存在する場合、表をインポートすると、ソース表(外部キー制約を含む表)からターゲット表に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に、リレーションシップを作成する場所を示します。
リレーションシップを作成する手順は次のとおりです。
注意:
親表として選択できるのは、ルート表からアクセス可能な表のみです。
アダプタ構成ウィザードに最初に表がインポートされると、データベースの各フィールドに対応する、TopLinkのフィールドへの直接的なマッピングが作成されます。図9-15および図9-16に示すスキーマがあるとします。
これら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
オブジェクト全体を表します。)
リレーションシップが削除されると、外部キーへのダイレクト・マッピングがリストアされます。
リレーションシップが自動的に作成される場合、1対多リレーションシップは、外部キーを持たない表からのものになります。ただし、このマッピング(技術的には1対多)を1対1として宣言できます。このためには、1対1(外部キーはターゲット上)を選択します。
インポートされるすべての表が第3正規形(3NF)であるとはかぎりません。まれに、複数の表が同じ主キーを共有しており、個別の外部キー列が存在しない場合があります。ルート表から関連するすべての表への1対1(外部キーはターゲット上)リレーションシップを作成することをお薦めします。これには、2つの理由があります。1つ目は、ルート上の主キーを外部キーとして(ソース上に1対1で)宣言する場合、マッピングが削除されるため、主キーはルート・レコードには存在せず、子レコードにのみ存在することになるためです。2つ目は、外部キーは単一の表のみを指すことができるためです。ある列を外部キーの一部として宣言すると、外部キーは削除されるため、新しいリレーションシップで再使用できなくなります。ルート表に1対1リレーションシップ(外部キーはソース上)を作成すると、主キー列が表示されなくなります。また、ルート表をその他の表に結合できなくなる可能性があります。
図9-17に、インポートされた表の定義から作成された属性フィルタを示します。これには定義したリレーションシップも含まれます。
オブジェクト・フィルタにセルフ・リレーションシップ(従業員対従業員の管理者のリレーションシップなど)が含まれる場合、ツリーではループとして表示されます。XSDファイルではループは表示されません。これはディスクリプタ・オブジェクト・モデルであり、XSDファイルではありません。
このページでは、入力(MERGE
、INSERT
)であるか出力(SELECT
)であるかに関係なく、XMLファイルに表示する列を選択します。不要な列や読取り専用(変更不可)の列の選択をここで解除できます。
アダプタ構成ウィザードの使用を続行するには、「WHERE句の定義」を参照してください。
サービスにSELECT
問合せ(インバウンド・ポーリング・サービスまたはSELECT
を含むアウトバウンド・サービスなど)が含まれる場合、SELECT
文のWHERE
句をカスタマイズできます。
注意:
Sequencing Table
/Update an External Sequencing Table
によるポーリングを使用する場合は、SELECT
問合せの表名が順序表のデータの大/小文字区別と一致することを確認してください。
図9-18に、アウトバウンド・サービスのWHERE
句を定義する場所を示します。
注意:
WHERE
句はSELECT
操作(新規または変更されたレコードのポーリング、または表におけるSELECT
操作の実行)にのみ適用されます。INSERT
、UPDATE
およびDELETE
操作には適用されません。
WHERE
句の最も基本的な式は、式の右側(RHS)の内容に応じて、次に示す3つのいずれかになります。
WHERE
句の作成を開始する前に「追加」をクリックして、WHERE
句で必要なパラメータを作成します。WHERE
句を作成するには、図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になります。
アダプタ構成ウィザードの使用を続行するには、「読取り後戦略の選択」を参照してください。
「表に対して操作を実行」を選択した場合は、手順を省略して「詳細オプションの指定」に進んでください。
インバウンド操作の構成時には、1つ以上の行が読み取られた後の処理に関して次のオプションがあります。
図9-20にこれらのオプションを示します。
アダプタ構成ウィザードの使用を続行するには、「ポーリング戦略」を参照してください。
このオプションでは、ルート・データベース表のフィールドを更新して、その行が読取り済であることを示します。図9-21に示すように、構成の完了後に問合せのWHERE
句が自動的に更新されます。
この方法を使用すると、データベース表は図9-22のようになります。
次の点に注意してください。
行150および153はすでに読み取られて処理されています。
STATUS列にUNPROCESSED
と表示されているため、次のポーリング・イベントで、行152が読み取られて処理されます。Unread Value
が明示的に指定されているため、行151は読み取られません。
行154にはLOCKED
というフラグが付いているため読み取られません。表が他のプロセスに使用されている場合、この予約値を使用できます。
このオプションでは、別の順序表の最終読取り行を追跡します。図9-23に指定する情報を示します。構成が完了すると、問合せのWHERE
句が自動的に更新されます。
これらの設定を使用すると、順序表は図9-24のようになります。
行が読み取られるたびに、この表は読み取られたIDで更新されます。次のポーリング・イベントが発生すると、最終読取りID (154)より大きなIDの行が検索されます。
使用される一般的な列は、event_id
、transaction_id
、scn
(システム変更番号)、id
またはlast_updated
です。通常、これらの列には順序番号またはsysdate
が移入され、値は(一定量で)増加します。
この操作は、順序表: 最終更新戦略を採用するときに選択します。図9-25に、アダプタ構成ウィザードの「外部順序表」ページを示します。このページで、この操作の実行に必要な詳細を指定します。
このオプションは、順序ファイルを更新する場合に使用します。図9-26に、アダプタ構成ウィザードの「順序ファイルの更新」ページを示します。このページで、この操作の実行に必要な詳細を指定します。
追加のポーリング・オプションがある場合は、このページで指定できます。図9-27に、アダプタ構成ウィザードの「ポーリング・オプション」ページを示します。
このページでは、新規の行またはイベントに関してデータベース表をポーリングする方法の詳細を指定します。
「ポーリング頻度」リストから、新規のレコードまたはイベントのポーリング頻度を選択します。
「XML文書ごとのデータベース行数」フィールドで、Oracle BPEL PMまたはメディエータにイベントを送信する際の、XML文書ごとの行数を指定します。これは、データベース・アダプタとコンシューマ(Oracle BPEL PMまたはメディエータ)の間のバッチ設定です。
「トランザクションごとのデータベース行数」フィールドで、「無制限」を選択するか、または1回のトランザクションで処理する表の行数を示す値を入力します。
イベントに関してデータベースをポーリングする場合は、「ソート順」リストを使用して、戻される行を選択した列でソートできます。ベスト・プラクティスは、追加の構成なしではメッセージの順序付けが保証されないため、「<順序付けなし>」を選択することです。
「SQL」フィールドには、SQL構文が正しくない場合にメッセージが赤で表示されます。
ポーリング・オプションの指定の詳細は、「ポーリング・オプション」ページで「ヘルプ」をクリックするか、[F1]を押します。
詳細オプションを指定できます。図9-28に、アダプタ構成ウィザードの「詳細オプション」ページを示します。このページでは、JDBCおよびDBアダプタの詳細オプションを指定し、再試行を構成し、ネイティブ順序付けを構成できます。
「JDBCオプション」セクションでJDBCオプションを指定する必要があります。下位レベルのJDBCオプションはデータベースへのコール時に設定します。このページに表示されるオプションは、選択した操作によって決まります。
「自動再試行」セクションでは、タイムアウト時の自動再試行の値を指定します。接続関連のフォルトが発生した場合は、invokeアクティビティを回数制限付きで自動的に再試行できます。このセクションのフィールドでは、次の値を指定できます。
無限に再試行するには、「試行」フィールドにunlimited
と入力します。
「間隔」は、再試行間の遅延です。
「バックオフ係数: x」を指定すると、再試行間の待ち時間を延長できます。開始間隔に1、バックオフに2を指定して9回再試行すると、1、2、4、8、16、32、64、128および256 (28)秒後に再試行されます。
「相互作用オプション」では、相互作用オプションを次のように指定します。
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]を押します。
「カスタムSQL」ページで、「Pure SQLの実行」操作を実行するためのSQL文字列を入力できます。図9-29に、アダプタ構成ウィザードの「カスタムSQL」ページを示します。
「SQL」フィールドにカスタムSQL文字列を入力します。SQL入力のXSDスキーマが「XSD」フィールドに自動的に作成されます。
「XSD」フィールドには、入力したカスタムSQL文字列のXSDスキーマが表示されます。結果のXSDは直接編集できます。ただし、以降にSQL文字列を変更すると、XSDの変更内容が失われます。
SQL文字列の入力の詳細は、「カスタムSQL」ページで「ヘルプ」をクリックするか、[F1]を押します。
この項では、Oracleデータベース・アダプタの機能について説明します。
Oracleデータベース・アダプタにより、固有のデータ処理とともにトランザクション・サポートが可能になります。これにより、それぞれの変更の結果が明確に定義されており、結果は成功か失敗のいずれかになるため、潜在的なデータ破損が防止され、他の変更から独立して実行され、完了後は別のトランザクションが発生するまで基礎となるデータが同じ状態で維持されることが保証されます。
トランザクション・サポートには、XAトランザクション・サポートとローカル・トランザクション・サポートの2つのタイプがあります。XAトランザクション・サポートでは、トランザクションをリソース・アダプタの外部にあるトランザクション・マネージャで管理できます。これに対して、ローカル・トランザクション・サポートでは、アプリケーション・サーバーでリソース・アダプタに対してローカルなリソースを管理できます。
2つのOracleデータベース・アダプタによりコミットまたはロールバックが1単位として確実に起動されるようにするには、次を実行する必要があります。
両方のOracleデータベース・アダプタの起動を、グローバル・トランザクションに関与するように構成する必要があります。
両方のOracleデータベース・アダプタの起動が、同じグローバル・トランザクションに関与する必要があります。
いずれかの起動に失敗した場合は、グローバル・トランザクションをロールバックする必要があります。
注意:
XA以外のドライバはSOALocalTxDataSource
パラメータとともに使用する必要があります。XAドライバに切り替えると、製品の機能が破損します。
デプロイメント・ディスクリプタ(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管理コンソールを使用してデータソースを作成する必要があります。
両方のOracleデータベース・アダプタの起動が1単位としてコミットまたはロールバックするためにグローバル・トランザクションに関与する場合は、同じグローバル・トランザクションに関与する必要があります。BPELでは、そのためにトランザクション境界の位置、つまりチェックポイントでデハイドレーション・ストアに書き込み、現行のグローバル・トランザクションをコミットし、新規トランザクションを開始する位置を認識する必要があります。
BPELプロセスでのトランザクション境界は、ReceiveアクティビティまたはReceiveアクティビティの前、あるいはonMessage
またはPickアクティビティの前に発生します。次のサンプル・コードに示すように、パートナ・リンク上でbpel.config.transaction
プロパティが設定されていないかぎり、これは同期の子BPELプロセスの起動時にも発生することがあります。
<property name="bpel.config.transaction">required</property>
それ以外の場合は、親プロセスが2つのトランザクションに分割され、子プロセスは固有のトランザクションで実行されます。
最後に、両方のOracleデータベース・アダプタの起動が同じグローバル・トランザクションに関与していても、一方の起動に失敗するとグローバル・トランザクションをロールバックできない場合があります。
失敗により実際にグローバル・ロールバックが発生可能なのは、次の場合のみです。
ある書込みには成功しても他の書込みに失敗した後で、1回の起動の一部として複数の表を挿入または更新するOracleデータベース・アダプタ操作に失敗した場合。この場合、起動操作はアトミックでなく、コミットするとデータが破損する可能性があるため、Oracleデータベース・アダプタはグローバル・トランザクションをロールバックのみとしてマーク付けします。
データベース停止のシナリオで、グローバル・トランザクションがタイムアウトしてロールバックされるまで、起動が数回再試行される場合。
BPELプロセス内で明示的なbpelx:rollback
フォルトがスローされる場合。
両方のOracleデータベース・アダプタの起動に同じセッションまたは接続を使用可能にするには、GetActiveUnitOfWork
JCAパラメータをtrueに設定する必要があります。
GetActiveUnitOfWork
は、すべてのDBInteractionSpec
に設定できる拡張JCAプロパティです。これにより、2フェーズ・コミット・コールバックに自己登録する起動とデータベースへのすべての書込みが、2フェーズ・コミットの一部として実行されます。障害発生時にこのプロパティを設定することで、この段階でフォルトを処理する方法がないため、トランザクションが自動的にロールバックされます。同様に、両方の起動には同じ基礎となるTopLinkセッションが使用されます。これは、同じオブジェクトを2回マージする場合、挿入または更新されるのは1回であることを意味します。GetActiveUnitOfWork
がtrueに設定されているすべてのマージの起動は、累積的です。
2つのOracleデータベース・アダプタの起動が1単位としてコミットまたはロールバックされるようにするには、両方のOracleデータベース・アダプタの起動がグローバル・トランザクションに関与するよう構成されていること、両方の起動が同じグローバル・トランザクションに関与していること、およびいずれかの起動に失敗した場合はグローバル・トランザクションがロールバックされるようになっていることが必要です。
デプロイメント・ディスクリプタ(weblogic-ra.xml)で、xADataSourceName
を設定する必要があります。対応するデータソース・エントリは、グローバル・トランザクションに関与するように構成する必要があります。
実際のXA: 2フェーズ(XA)コミットと1フェーズ(エミュレート)コミットの違い
XAは2フェーズ・コミット・プロトコルで、1フェーズ・コミット/エミュレート・プロトコルよりも堅牢です。その違いは、1フェーズ・プロトコルでは、メッセージが消失したりロールバック/コミットの不整合が発生することは非常にまれではありますが、その割合は通常、1000当たり1程度はある点です。
Oracle RACの構成
Oracle RACの構成の詳細は、Oracle Database高可用性概要の実際のアプリケーション・クラスタを参照してください。
サード・パーティのドライバを使用した実際のXA構成
サード・パーティのドライバ(Microsoft SQL Server 2008やIBM DB2など)に対して実際のXA構成を構成する場合、javax.sql.XADataSource
を実装するクラスがドライバのJarに含まれることを確認します。
データ直接ドライバの場合、ネーミングはcom.oracle.ias.jdbcx.db2.DB2DataSource
またはcom.oracle.ias.jdbcx.sqlserver.SQLServerDataSource
である可能性があります。
最後に、両方の起動が同じグローバル・トランザクションに関与していても、一方の起動に失敗するとグローバル・トランザクションをロールバックできない場合があります。
失敗により実際にグローバル・ロールバックが発生可能なのは、次の場合のみです。
ある書込みには成功しても他の書込みに失敗した後で、1回の起動の一部として複数の表を挿入または更新するOracleデータベース・アダプタ操作に失敗した場合。この場合、起動操作はアトミックでなく、コミットするとデータが破損する可能性があるため、アダプタはグローバル・トランザクションをロールバックのみとしてマーク付けします。
データベース停止のシナリオで、グローバル・トランザクションがタイムアウトしてロールバックされるまで、起動が数回再試行される場合。
BPELプロセス内で明示的なbpelx:rollback
フォルトがスローされる場合。WSDL内のGetActiveUnitOfWork="true"
。
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をインポートできます。
詳細は、次を参照してください。
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
詳細は、次を参照してください。
このリリースでは、プロキシ認証を使用して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-27に示すように、ポーリング・オプションを指定する際に「ストリーミングの有効化」チェック・ボックスを選択する必要があります。この機能を有効化すると、ペイロードはメモリーDOM内のSOAランタイムで操作されるかわりにデータベースにストリーミングされます。この機能は、大きなペイロードの処理中に使用します。「ストリーミングの有効化」チェック・ボックスを選択すると、対応するブール・プロパティStreamPayload
がそれぞれの.jca
ファイルに定義されているActivationSpecプロパティに追加されます。
SchemaValidation
[false/true]プロパティは、新しく追加されたアクティブ化仕様プロパティで、.jca
ファイルで構成できます。trueに設定すると、ポーリングOracleデータベース・アダプタ(receiveアクティビティ用)により生成されたXMLファイルはすべて、XSDファイルと対照して検証されます。失敗時には、XMLレコードは拒否されますが、引き続きOracleデータベース・アダプタにより処理済としてマーク付けされます。
データベースには構造化された記憶域が用意されており、XSDファイルはOracleデータベース・アダプタ・ウィザード自体により生成されます。ただし、自動生成XSDを編集して独自の制限を追加する場合、検証を開始する必要があります。たとえば、VARCHAR(50)フィールドをインポートする場合、自動生成XSDには最大長が50という制限があります。ただし、なんらかの理由でBPELプロセスで固定長22の値の処理のみが可能な場合は、XMLファイルを検証する必要があります。
Oracle Databaseアダプタは、アクティブ/アクティブ設定での高可用性をサポートします。アクティブ/アクティブ設定では、インバウンド・データベース・アダプタに対して分散ポーリング技術を使用して、同一データが重複して取得されないようにできます。詳細は、「分散ポーリングのベスト・プラクティス1: SELECT FOR UPDATE(SKIP LOCKED)」を参照してください。他のアダプタと同様、Oracle Databaseアダプタをアクティブ/パッシブ設定内でのシングルトン動作に対して構成することもできます。これにより、アクティブ/パッシブ設定で動作するパフォーマンスの高いマルチスレッドのインバウンドOracleデータベース・アダプタ・インスタンスは、展開パターンに従ってクラスタ全体で複数のコンポジット・インスタンスを起動できます。Oracle Databaseアダプタは、データベース障害時や再起動時にも、高可用性機能をサポートします。DBアダプタは、メッセージを損失することなく、再度メッセージを取得します。
次の各項では、複数のOracle BPEL PMまたはメディエータ・ノードに複数のOracleデータベース・アダプタ・プロセス・インスタンスをデプロイするためのベスト・プラクティスについて説明します。
複数の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
では、同時スレッドにより、使用可能な行の選択およびロックがそれぞれ試行されますが、ロックはフェッチ時にのみ取得されます。フェッチしようとしている行がロックされている場合、かわりに次のロックされていない行がロックおよびフェッチされます。複数のスレッドがすべて同じポーリング問合せを同時に実行する場合、各スレッドは、処理されていない行の非結合サブセットを比較的迅速に取得する必要があります。
ロックのスキップに固有な点は、各スレッドが、その他のスレッドがすでに取得しているロックをスキップし、各スレッドが独自にロック済行のセットを取得できることです。その他のロック方法では、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の詳細な構成」を参照してください
Oracle以外のデータベースでは、SELECT FOR UPDATE
によって、同じ行が複数回処理できないことが安全に保証されますが、スケーラビリティが低下する場合があります。パーティション・フィールドを追加して使用するか、または2つ目のベスト・プラクティス、つまり、基本的には単一ノード上でマルチスレッド処理と展開を使用するかを検討する必要があります(「分散ポーリングのベスト・プラクティス2: 最初に単一ノードでチューニングする」を参照)。
注意:
分散アプローチによって、複数のアクティブ化インスタンスで同じ行が処理されないようにします。
このベスト・プラクティスを構成する場合は、次の各項も参照してください。
分散シナリオの場合、各ポーリング・インスタンスでは、処理されていないすべての行をそのインスタンス単独で処理しようと試みるのではなく、負荷の分散が試行されます。このため、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 |
1 |
順次ルーティングを使用する場合。 10行の場合、個別のインスタンスが10個使用され、10個のXMLレコードがSOAを通過します。 |
100 |
- |
パラレル・ルーティングを使用する場合。 |
>= 100 |
|
アダプタを使用してできるかぎり迅速に行をストリーミングする場合。 |
ロード・バランシングが目的である場合は、1つの分散環境でMaxTransactionSize
の設定が小さすぎると、その分散環境によって速度が制限されるため、適切ではありません。MaxTransactionSize
は、ビジネス・プロセス全体の各CPUスループットに近い値に設定するのが最適です。このようにすると、ロード・バランシングは必要なときにのみ発生します。
分散ポーリングが設定されていない場合、アダプタでは、処理されていないすべての行を単一のポーリング間隔で処理しようとします。
分散シナリオでは、複数のサーバー上にポーリング・インスタンスが存在しますが、サーバーごとに複数のスレッドを構成することもできます。これらのアクティブ化インスタンスを構成すると、個別に行を処理することによって、ある程度の連携が可能となり、スケーリングが向上する場合があります。
そのためには、単に次のプロパティ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使用率が増加することによって、コストがかかるためです。
T
アダプタ・フレームワーク・レベル・プロパティactivationInstances
(composite.xml
内で構成)は、分散シナリオ用のNumberOfThreads
と置換え可能です。
activationInstances
を5に、NumberOfThreads
を5に設定することは、一方を25に、もう一方を1に設定するのと同じです。追加の作業インスタンスはデータベース・アダプタの外部に作成されるため、これらはいかなる方法でも連携しません。したがって、マルチスレッドの単一ノード・シナリオでは、常にNumberOfThreads
のみを構成してください。分散ポーリングを有効化することによるデータベース・レベルの同時実行性制御がない場合は、重複が読み取られます。
注意:
分散クラスタ・シナリオでは、NumberOfThreads
とactivationInstances
のどちらを構成しても効果は同じです。非分散シナリオでは、NumberOfThreads
を使用する必要があります。したがって、常にNumberOfThreads
を使用し、activationInstances
は使用しないようにするのが無難と言えます。
詳細は、「アダプタ内でのシングルトン(アクティブ/パッシブ)インバウンド・エンドポイント・ライフサイクルのサポート」を参照してください。
主キー、および結合表へのすべての外部キーに索引付け(および/またはこれらのキーに対してデータベース上に明示的な制約を追加)します。論理削除ポーリングを使用する場合は、状態列に索引付けします。NULL以外のMarkUnreadValue
およびMarkReadValue
を構成します。
アウトバウンド・データベース・アダプタ上の最適なパフォーマンスのすべての操作(INSERTを除く)において、データベース・アダプタの主キーとして選択されている列のデータベースに索引を作成する必要があります。
索引がなく、かつ索引を作成しないことが適切である場合は、単一ノードのマルチスレッドのアプローチを使用できます(「分散ポーリングのベスト・プラクティス2: 最初に単一ノードをチューニングする」を参照)。この方法では、ポーリング問合せの1度の実行で全表スキャンが行われることがありますが、その場合、複数のスレッドで、すべての行を処理するまで結果セット全体が使用されます。分散アプローチを使用する場合は、行が排他的にロックされている(つまり、時間が指定されたトランザクションでロックされている)間にすべての作業が完了する必要があります。分散シナリオでは、選択が何度も繰り返して実行されるため、選択ごとに全表スキャンが実行されると、パフォーマンスに悪影響を及ぼす場合があります。
注意:
MarkUnreadValue
がNULLとして構成されている場合は、パフォーマンスが著しく低下します。
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 <= ?
句がない場合、戻される行は、行が挿入された順番になります。
論理削除ポーリングを使用していて、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}
などの複雑な変数を構成する必要があります。
この分散アプローチは、削除または論理削除に基づくポーリング戦略で機能します。
順序付けポーリングに基づく戦略の作業は、最初にレコードが順番に処理されるため、分散できません。
たとえば、2つ目の行が1つ目の行よりも先に処理済としてマークされることはありません(最終読取りIDを2に設定することは、2だけでなく、1も処理済であることを意味します)。
ただし、順序付けポーリング戦略は、ソース表に対して更新後または削除後の処理を行う必要がなく簡潔であるため、非常に高速です。
順序付けポーリング戦略は、単一ノードでクラスタ上の展開とともに使用します。クラスタでの使用は引き続き安全ですが、ヘルパー表の最終読取りIDにアクセスするときには、かわりにSELECT FOR UPDATEが適用されます。
複数のOracle BPEL PMまたはメディエータ・ノードに複数のOracleデータベース・アダプタ・プロセス・インスタンスをデプロイするための次のベスト・プラクティスは、最初に単一ノードをチューニングする方法です。
Oracleデータベース・アダプタに高い負荷がかかるプロセス(データベース同士の統合など)では、単一Java仮想マシン(JVM)をチューニングして|NumberOfThreads|を大きくし、MaxTransactionSize
およびMaxRaiseSize
に高い値を設定するのみで、パフォーマンスを10から100倍に向上できます。
「分散ポーリングのベスト・プラクティス1: SELECT FOR UPDATE (SKIP LOCKED)」で説明するように、単一ノードでのパフォーマンスを向上させ、必要に応じてクラスタ内の複数のノードに展開することが最適である場合があります。データベースの同時実行性制御機能(ロックなど)への依存性が高くなる可能性がありますが、これらの機能は、通常、パフォーマンスの高いスケーラビリティよりもデータ整合性を保持することを重視して設計されています。
クラスタ内の単一ノード上でポーリングを行うことが最適となるケースとして、煩雑でない順序付けポーリング戦略、索引付けされていない大規模な表のポーリング、または同時実行性が高いロック(ロックのスキップなど)が備えられていないOracle以外のバックエンド・データベースを使用するケースなどがあります。
注意:
クラスタ環境でポーリング操作を使用するOracleデータベース・アダプタの場合は、アダプタ構成ウィザードで「分散ポーリング」チェック・ボックスを選択して、分散ポーリングのオプションを使用する必要があります。
必要であれば、「アダプタ内でのシングルトン(アクティブ/パッシブ)インバウンド・エンドポイント・ライフサイクルのサポート」も参照してください。
Oracleデータベース・アダプタは、多くのパフォーマンス最適化で事前構成されています。ただし、パフォーマンス・チューニングを実装することで、変更を加えてデータベースへのラウンドトリップの回数を減らせます。
パフォーマンス・チューニングの詳細は、データベース・アダプタのパフォーマンスとチューニングを参照してください。
detectOmissions
機能detectOmission
機能の特長は、次のとおりです。
使用可能なリリース
リリース10.1.3以上
構成可能
はい
デフォルト値
設計時: true
(明示的にfalse
に設定しない場合)
使用例
ユーザーは、マージ、更新または挿入対象とする不完全または部分的なXMLを渡して、XMLで未指定の各列がデータベースでNULLに設定されていることを確認できます。
この機能により、DBAdapter
のmerge、insertまたはupdateでは、XML文書内のnull
値と欠落値(省略)を区別できます。XML内のどの情報が有効で、どの情報が無効であるかは、事例ごとに判別されます。このようにして、XMLは完全な表現ではなくデータベース行の部分表現とみなされます。次の表に、NULL値と省略可能な値の例を示します。
表9-3 NULL値の例
要素タイプ | 省略 | NULL |
---|---|---|
列 |
|
|
1-1 |
<!-- dept> … </dept --> |
|
1-M |
|
|
注意:
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
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
が優先されます。
アダプタ構成ウィザードの「詳細オプション」ページでQueryTimeout
を構成できます。この機能により、同じ名前のjava.sql.Statement
レベル・プロパティが公開されます。基本的には、QueryTimeout
を使用するとコール時のタイムアウトを構成できます。
Oracleデータベース・アダプタの考え方を概観します。
この項には、リレーショナルからXMLへのマッピングに関する次の項目が含まれます。
フラット表またはスキーマでは、リレーショナルからXMLへのマッピングを簡単に参照できます。表の各行は複合XML要素になります。各列の値はXML要素のテキスト・ノードになります。列値およびテキスト要素のどちらもプリミティブ型です。
表9-4に、MOVIES
表の構造を示します。この表は、この章で説明する使用例で使用されます。詳細は、Oracleデータベース・アダプタの使用例を参照してください。
表9-4 MOVIES表の説明
名前 | NULLかどうか | タイプ |
---|---|---|
|
NULL以外 |
|
|
-- |
|
|
-- |
|
|
-- |
|
|
-- |
|
|
-- |
|
|
-- |
|
|
-- |
|
|
-- |
|
|
-- |
|
|
-- |
|
|
-- |
|
|
-- |
|
|
-- |
|
|
-- |
|
対応する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かどうか | タイプ |
---|---|---|
|
NULL以外 |
|
|
-- |
|
|
-- |
|
|
-- |
|
|
-- |
|
|
-- |
|
|
-- |
|
|
-- |
|
表9-6 DEPT表の説明
名前 | NULLかどうか | タイプ |
---|---|---|
|
NULL以外 |
|
|
-- |
|
|
-- |
|
前の表定義が示すように、典型的な正規化されたリレーショナル・スキーマであるため、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-7に、データベースから表をインポートする際に、データベースのデータ型がどのようにXMLのプリミティブ型に変換されるかを示します。
表9-7 データベースのデータ型のXMLのプリミティブ型へのマッピング
データベース・タイプ | XMLタイプ(接頭辞はxs:) |
---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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
でエンコードされ、文字データとして渡されます。
Oracleデータベース・アダプタでは、リレーショナル・データベース上の任意のリレーショナル・スキーマの、任意のXMLスキーマへのマッピングがサポートされています。ただし、要素のレイアウトに対する明確なユーザー制御がない状態でアダプタ構成ウィザードによりXMLスキーマが生成されるため、ユーザーはXMLスキーマを選択できません。
スキーマのマッピング方法は、「アダプタ構成ウィザード」で制御することも、後からTopLink Workbenchで制御することもできます。トランスフォーメーション・ステップとOracleデータベース・アダプタを関連付けることで、任意のリレーショナル・スキーマを任意のXMLスキーマにマッピングできます。
複数の関連表に対するSQL select
文を実行する場合、SQLを作成するには次の3つの方法があります。これらの方法は、マスター・レコードに対する問合せ時にディテール・レコードを取り込む方法に関係しています。
以降の各項では、この3つの方法を比較しながら説明します。単一表から行を選択する場合は、複数の表から選択する場合のような問題が存在しません。
単一の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に変更してください。
これはデフォルト機能で、次の例に示すように、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に編集します。
ディテール表はオリジナルの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
表面上は、単一結果セットを戻すのが最善の方法(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
設定が存在します。ただし、この設定は大きなリスクを伴います。
リレーショナル・スキーマをXMLとしてマッピングした後、基本的なSQL操作もWebサービスとしてマッピングする必要があります。いくつかの操作では直接SQL等価に変換されますが、その他はより複雑です。
この項には次のトピックが含まれます:
データ操作言語(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
機能では、ユーザーは結果を返す行の最大数の制限を設定できません。このため、多数の行が返されます。これに伴って、行を処理するためのメモリー要件も増加します。
インバウンドの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;
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管理コンソール内での「アウトバウンド接続プール」へのナビゲーションを示しています。これが実際のデータベース・アダプタ構成ページであり、ここから後続のページに移動してデータベース・アダプタのプロパティを編集できます。
2つ目のスクリーンショットは、必要に応じて編集する、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データベース・アダプタのプロパティ
プロパティ名 | タイプ |
---|---|
|
Boolean |
|
Boolean |
|
Boolean |
|
Boolean |
|
Boolean |
|
文字列 |
|
Boolean |
|
Integer |
|
文字列 |
|
Boolean |
|
Boolean |
|
文字列 |
|
Integer |
|
文字列 |
|
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-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を含む) |
|
Oracle9以上(オプション) |
|
DB2 |
|
DB2 (AS400e上) |
|
Informix |
|
SQLServer |
|
MySQL |
|
Derby |
|
z/OS上のDB2 |
|
その他のデータベース |
|
主要なデータベースおよびバージョンのみが動作確認されています。他のデータベースでの作業は、作業用のJDBCドライバが用意されており、コアANSI SQLリレーショナル機能(表やビューに対する作成、読取り、更新および削除(CRUD)の各操作など)に依存している場合、実行可能です。問題の多くは、データベース・メタデータ・イントロスペクションが、必ずしもすべてのJDBCドライバで同じように実装されていないことによって、発生する傾向があります。ただし、動作確認されたデータベース上に一致する表をインポートした後、動作確認されていないデータベースを実行時に参照することができます。
ネイティブまたはバンドルされたOracle WebLogic Server 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 |
|
Sybase |
|
Informix |
|
IBM DB2 |
|
MySQL |
MySQLのドライバ(タイプ4) バージョン: |
Derby |
Derbyのドライバ(タイプ4 XA) |
DB2/AS400 |
オンラインのドライバjt400Native.jarをダウンロードして、user_projects/domains/<domain_name>/lib/にコピーします。 注意: WLSからのjndiの作成中に |
DB2/ ZOS |
オンラインのドライバ 注意: WebLogic ServerからのJNDIの作成中に |
ProgressDb |
Progressインストールのドライバ 注意: WebLogic ServerからのJNDIの作成中に |
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トランザクションを正常に実行するには、次の手順も実行する必要があります。
trxn
、sqlserver
)。URL: jdbc:weblogic:sqlserver://<host>:<port>
ドライバ・クラス: weblogic.jdbcx.sqlserver.SQLServerDataSource
ドライバJar: wlsqlserver.jar
はWebLogic Serverにバンドルされており、インストール時に提供されます。
その場所は、/<install_dir>/oracle_common/modules/datadirect
です。
この項には次のトピックが含まれます:
この項には次のトピックが含まれます:
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ドライバの詳細は、次のリンクを参照してください。
この項には次のトピックが含まれます:
URL: jdbc:weblogic:db2://<host>:<port>ドライバ・クラス: weblogic.jdbcx.db2.DB2DataSourceDriver Jar: wldb2.jar
はサーバーでバンドルされています。インストールとともに提供されます。場所: /<install_dir>/oracle_common/modules/datadirect
DataDirectドライバについては、次のリンクを参照してください。
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
を使用します。
次の情報を使用します。
URL: jdbc:mysql://
hostname
:3306
/dbname
ドライバ・クラス: com.mysql.jdbc.Driver
/ com.mysql.jdbc.jdbc2.optional.MysqlXADataSource
ドライバJar: mysql-connector-java-<version_number>-bin.jar
次の情報を使用します。
URL: jdbc:derby://<host>:<port><location of schema>
ドライバ・クラス: org.apache.derby.jdbc.ClientXADataSource
ドライバJar: Derby.jar, derbyclient.jar
この項では、JDBC JARファイルの場所と、実行時および設計時のクラスパスの設定について説明します。
実行時
WindowsとLinuxの場合は、どちらも次の手順を実行する必要があります。
user_projects/domains/soainfra/lib
ディレクトリに移動します。<Weblogic_Home>/server/lib
に移動します。<Weblogic_HOME>/common/bin/commEnv.sh
に含めます設計時
WindowsとLinuxの場合は、どちらもJDBC JARをOracle/Middleware/jdeveloper/jdev/lib/patches
ディレクトリに移動します。
ここでは、Oracleデータベース・アダプタが、ストアド・プロシージャと関数の使用にどのように対応しているかを学びます。
「アダプタ構成ウィザード - ストアド・プロシージャ」は、アダプタ・サービスWSDLおよび必要なXSDの生成に使用されます。アダプタ・サービスWSDLは、基礎となるストアド・プロシージャまたはファンクションをWSIF JCAバインディングのあるWebサービスとしてカプセル化します。XSDファイルには、すべてのパラメータおよびそのタイプを含む、プロシージャまたはファンクションが記述されています。このXSDには、実行時にOracleデータベース・アダプタに発行されるインスタンスXMLの作成に使用される定義が指定されています。
この項には次のトピックが含まれます:
この項では、PL/SQLパッケージに定義されていないAPIを持つアダプタ構成ウィザードの使用方法を説明します。「アダプタ構成ウィザード - ストアド・プロシージャ」を使用し、プロシージャまたはファンクションを選択してXSDファイルを生成します。アダプタ構成ウィザードの起動方法については、Oracleデータベース・アダプタの使用例を参照してください。
アダプタ構成ウィザードを使用してストアド・プロシージャまたはファンクションを選択するには、次の手順を実行します。
パッケージで定義されたAPIの使用は、スタンドアロンAPIの使用と似ています。唯一の違いは、図9-43に示すように、パッケージ名を開いて、パッケージに定義されているすべてのAPIのリストを参照できることです。
同じ名前でパラメータが異なるAPIは、オーバーロードされたAPIと呼ばれます。図9-43に示すように、PACKAGEというパッケージには、OVERLOADというオーバーロードされたプロシージャが2つあります。
図9-44に示すように、「ソース」タブを参照する際にはパッケージのどのAPIが選択されているかにかかわらず、PL/SQLパッケージ全体のコードが表示されます。プロシージャ名に一致するテキストが強調表示されています。
プロシージャまたはファンクションを選択して「OK」をクリックすると、図9-45に示すように、APIの情報が表示されます。スキーマ、プロシージャ名およびパラメータのリストが表示されます。プロシージャ名がパッケージ名でどのように修飾されているかに注意してください(PACKAGE.OVERLOAD)。「戻る」または「参照」をクリックして修正するか、「次へ」をクリックします。任意の詳細オプションの値を入力します。「次へ」をクリックし、「終了」をクリックして終了します。
アダプタ構成ウィザードの使用が終了すると、次のファイルが既存のプロジェクトに追加されます。
Overload.wsdl
、Overload_db.jca
SCOTT_PACKAGE_OVERLOAD_2.xsd
XSDファイル名ではプロシージャ名の後に_2
が追加され、オーバーロードされたAPIと区別されています。数値索引は、オーバーロードされたAPIをそれぞれ区別するために使用されます。
ストアド・プロシージャの場合、Oracle、DB2、Informix Dynamic Server、MySQL、Microsoft SQL ServerおよびSybase Adaptive Server Enterpriseのデータベースがサポートされています。認証されている特定のバージョンについては、サポートに問い合せてください。特定のバージョンがここに記載されているバージョンよりも新しい場合、そのバージョンがサポートされている可能性があります。
サード・パーティJDBCおよびデータベースに対するOracle JCAアダプタのサポートの詳細は、「JDBCドライバとデータベース接続の構成」を参照してください。
この項には次のトピックが含まれます:
ProductName
これはデータベースの名前です。
データベース名 | サポート対象データベース |
---|---|
IBM DB2 |
IBM DB2 v 10.1 |
Microsoft SQL Server |
SQLServer 2012 |
MySQL |
MySQL v5.6* |
DriverClassName
これはJDBCドライバ・クラスの名前です。
データベース名 | JDBCドライバ |
---|---|
IBM DB2 |
|
Microsoft SQL Server |
|
MySQL |
|
ConnectionString
これはJDBC接続URLです。
データベース名 | 接続文字列 |
---|---|
IBM DB2 |
|
Microsoft SQL Server |
|
MySQL |
|
Username
データベース・ユーザー名です。
Password
ユーザー名に関連付けられているパスワードです。
ProcedureName
ストアド・プロシージャ名またはファンクション名です。
ServiceName
必要な操作のサービス名です。
DatabaseConnection
接続のJNDI名です。たとえば、eis/DB/<DatabaseConnection>
です。
Destination
これは、生成されるファイルの接続先ディレクトリです。たとえば、C:\Temp
などです。
Parameters
ストアド・プロシージャのパラメータです(バージョン5.2.6より前のMySQLのみ)。
QueryTimeout
JDBC問合せタイムアウト値(秒単位)です。QueryTimeout
プロパティは、JDBCドライバが、指定されたストアド・プロシージャまたはファンクションの実行を待機する最大秒数を指定します。しきい値に達すると、SQLException
がスローされます。値が0の場合は、ドライバは無期限で待機します。
アダプタ構成ウィザードでは、Oracle Database、IBM DB2、AS/400、DB2/ZOS、Microsoft SQL Server、Sybase 15.7、Informix 11.7+、Progress Db 10およびMySQL v5.6以上がサポートされます。
この項には次のトピックが含まれます:
表9-15に、SQL Serverのストアド・プロシージャおよびファンクションでサポートされるデータ型を示します。
表9-15 SQL Serverのストアド・プロシージャおよびファンクションのデータ型
SQLデータ型 | XMLスキーマ型 |
---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
表9-16に、DB2 SQLのストアド・プロシージャでサポートされるデータ型を示します。
表9-16 DB2 SQLのストアド・プロシージャのデータ型
SQLデータ型 | XMLスキーマ型 |
---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
他のデータ型の名前も暗黙的にサポートされています。たとえば、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-47に示すように、「ソース」タブをクリックすると、ストアド・プロシージャのソース・コードを表示できます。
表9-17に、IBM DB2 AS/400のストアド・プロシージャでサポートされるデータ型を示します。
表9-17 IBM DB2 AS/400のストアド・プロシージャのデータ型
SQLデータ型 | XMLスキーマ型 |
---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
個別データ型も、CREATE DISTINCT TYPE
文を使用して作成されるデータ型でサポートされています。これらのデータ型は、IBM DB2の場合と同様の振舞いをします。
IBM DB2 AS/400の実装は、QSYS2
スキーマのカタログ表からの問合せをベースにしています。アダプタで、QSYS2.SCHEMATA
表が存在するかどうかが確認されます。存在する場合は、アダプタ構成ウィザードでQSYS2
スキーマの表に問合せが行われます。したがって、IBM DB2 AS/400データベースでQSYS2
スキーマがサポートされている場合は、アダプタ構成ウィザードとアダプタ・ランタイムの両方が機能します。
アダプタ構成ウィザードでは、最初にSYSCAT
スキーマがチェックされ、次にQSYS2
スキーマがチェックされます。アダプタでは、SYSIBM
スキーマのカタログ表はサポートされていません。
アダプタ構成ウィザードを機能させるために必要なカタログ表にアクセスするには、JDeveloperでデータベース接続を作成する必要があります。
JDeveloperを使用してデータベース接続を作成する手順は、次のとおりです。
「表示」から「データベース・ナビゲータ」を選択します。
アプリケーション名を右クリックして「新規」と「接続」を順番にクリックします。「データベース接続」を選択します。
図9-48に示すように、「データベース接続の作成」ページが表示されます。
「接続名」フィールドに接続名を入力します。たとえば、sqlserver
と入力します。
「接続タイプ」リストから、「接続タイプ」として「汎用JDBC」を選択します。
「ユーザー名」、「パスワード」およびロール情報を入力します。
「ドライバ・クラス」で「新規」をクリックします。図9-49に示すように、「JDBCドライバの登録」ダイアログが表示されます。
ドライバ・クラスを入力します(たとえば、com.microsoft.sqlserver.jdbc.SQLServerDriver
)。
次の手順に従って、ライブラリを作成するか、既存のライブラリを編集します。
「JDBCドライバの登録」ダイアログで「参照」をクリックします。
「ライブラリの選択」ダイアログで「新規」をクリックします。
図9-50に示すように、「ライブラリの選択」ダイアログが表示されます。
既存のライブラリを選択するか、「新規」をクリックしてライブラリを作成します。
「ライブラリの作成」ダイアログが表示されます。
ライブラリ名を入力します。たとえば、SQL Server JDBC
と入力します。
「エントリの追加」をクリックして、JDBC JARファイルをクラスパスに追加します。
「OK」を2回クリックして「ライブラリの作成」ウィンドウを終了します。
「OK」をクリックして「JDBCドライバの登録」ウィンドウを終了します。
「JDBC URL」に接続文字列名を入力します。
「接続のテスト」をクリックします。
接続が成功すると、図9-51に示す画面が表示されます。
「OK」をクリックし、「終了」をクリックします。
「アダプタ構成ウィザード - ストアド・プロシージャ」では、ストアド・プロシージャまたはファンクションのシグネチャを説明するWSDLファイルおよび有効なXSDファイルを作成できます。次の項では、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
パラメータの値が保持されます。
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
ファイルに作成されます。
多くのプリミティブ・データ型には、詳細に定義されたマッピングが用意されているため、設計時および実行時のコンポーネントのどちらでもサポートされています。また、VARRAY
、ネストされた表およびOBJECT
などのユーザー定義タイプを使用できます。
表9-18に、Oracleのストアド・プロシージャおよびファンクションでサポートされるデータ型を示します。
表9-18 Oracleのストアド・プロシージャおよびファンクションのデータ型
SQLまたはPL/SQLタイプ | XMLスキーマ型 |
---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
表9-19に、生成されたXSDで使用される属性をリスト表示します。
表9-19 生成されたXSD属性
属性 | 例 | 意味 |
---|---|---|
|
|
要素の名前 |
|
|
XMLスキーマ型 |
|
|
SQLまたはPL/SQLタイプ |
|
|
パラメータの位置 |
|
|
デフォルト句がある場合 |
|
|
最小発生数 |
|
|
最大発生数 |
|
|
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"のように)明示的に宣言する必要があります。
アダプタ構成ウィザードでも、コレクション(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
の属性の宣言から長さがわかります。
ユーザー定義タイプは、必要に応じて複雑に定義できます。OBJECT
には、前述の任意のユーザー定義タイプとして定義されているタイプの属性を含めることができます。OBJECT
の属性のタイプが別のOBJECT
、VARRAY
またはネストされた表などになります。VARRAY
またはネストされた表のベース・タイプも、OBJECT
になる可能性があります。コレクションのベース・タイプが別のコレクションになることを許可することで、多次元のコレクションがサポートされます。
アダプタ構成ウィザードでは、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
タイプの階層が、階層全体のすべての属性に対応する要素の単一の順序にフラット化されていることに注意してください。
アダプタ構成ウィザードでは、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
パラメータを渡すことはできません。
アクセスに必要な権限が付与されている場合には、別のスキーマに定義されているタイプを参照できます。たとえば、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
の宣言においてこれを参照することはできません。
一部のユーザー定義オブジェクト・タイプは、多数の属性を持つ場合があります。これらの属性は、同じく多数の属性を持つ他のオブジェクト・タイプによって定義することもできます。つまり、あるオブジェクト・タイプが、その定義の深さと複雑度によっては極端に大きくなる場合があります。
状況によっては、ラージ・オブジェクト・タイプの多数の属性が不要な場合もあります。これらの属性をオブジェクトのスキーマ定義から省略することが望ましい場合があります。そのためには、オブジェクト・タイプの定義から不要な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
ルート要素から削除することでストアド・プロシージャのパラメータをプルーニング(削除)することはできません。対応する要素を削除すると、パラメータにデフォルト句がない場合は実行時エラーになる可能性があります。
この項では、ストアド・プロシージャのサポートに関する重要事項と、ストアド・プロシージャまたはファンクションの起動前に発生する動作に関する重要事項の概要を説明します。
この項には次のトピックが含まれます:
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つの可能性があります。
"BEGIN PROC (); END;" - X = 0
(X
にはデフォルト句がある)
"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"/>
この項では、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データ型 |
---|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
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
データはバイト配列へとデコードされ、必要に応じてバインドされます。
その他のデータ型の変換は簡単なため、追加情報は必要ありません。
プロシージャ(またはファンクション)を実行すると、任意のIN/OUT
およびOUT
パラメータの値が取得されます。これらは、生成されたXSDのOutputParameters
ルート要素の要素値に対応します。
この項には次のトピックが含まれます:
取得されたデータの変換は簡単です。ただし、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を使用する必要があります。
その他のデータ型の変換は簡単なため、追加情報は必要ありません。
値が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の場合にはこのように表示されます。
関数の戻り値は、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>
と表示されます。
実行時のサード・パーティ・データベースの共通機能は、次のとおりです。
すべてのサード・パーティ・データベースは、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
が常に先頭に表示されます。
一部のデータベースでは、ストアド・プロシージャでRETURN
文を使用してINTEGER
ステータス値を戻すことができます。Microsoft SQL ServerとAS/400は、両方ともこの機能をサポートしています。いずれの場合も、アダプタ構成ウィザードでは、ストアド・プロシージャがステータス値を戻すかどうかを決定できません。このため、ストアド・プロシージャが値を戻すことを指定する必要があります。これはチェック・ボックスを使用して指定できます。
「ストアド・プロシージャ」ダイアログでストアド・プロシージャを選択すると、図9-52に示す「ストアド・プロシージャの指定」ページが表示されます。前述のチェック・ボックスはページの下部にあります。このチェック・ボックスを選択して、プロシージャにRETURN
文を含めることを指定します。RETURN
文が存在するかどうかを確認するには、プロシージャのソース・コードを表示します。
このチェック・ボックスは、この機能をサポートするデータベースのストアド・プロシージャに対してのみ表示されます。ファンクションに対しては、このチェック・ボックスは表示されません。ストアド・プロシージャによって戻された値は、生成されたXSDのOutputParameters
ルート要素内の要素として表示されます。要素の名前は、ストアド・プロシージャの名前になります。このチェック・ボックスを選択しない場合は、return
文の値がストアド・プロシージャの実行後に消失します。
この項では、Oracleデータベース・アダプタで提供されているストアド・プロシージャ機能を使用して、直接にはサポートされていないタイプのシナリオについて説明します。次の各項では、これらのデータ型を使用する必要がある場合に取り組む解決策を説明します。
REF CURSOR
はどのような結果セットもサポートできるため、設計時に生成されるXSDは弱い型指定となります。
ただし、ここからのXML出力を使用するのは困難です。弱い型指定のXSDに基づき、要素名ではなく列名を属性値としてXpath式またはXSLを作成することは非常に困難です。
行セットはすべての結果セットを表現できますが、一部のプロシージャについては、結果セットの構造が毎回同じであることが想定できるため、強い型指定のXSDを使用して記述することも可能です。一般的に、後で結果セットを別のXSDに変換する場合は、強い型指定のXSDが必要となります。アダプタ構成ウィザードを使用して、REF CURSOR
に対して強い型指定のXSDを生成できます。
使用例において、弱い型指定のXSDで十分である場合は、「弱い型指定のXSDを使用した行セットのサポート」を参照してください。
この項には次のトピックが含まれます:
詳細は、「強い型指定のXSDまたは弱い型指定のXSDを使用した行セットのサポート」を参照してください。
選択したストアド・プロシージャまたはファンクションに、タイプがRowSet
の出力パラメータが含まれる場合、このREF CURSORに対して強い型指定のXSDを次のように定義できます。
アダプタ構成ウィザードを使用して、タイプがRowSet
の出力パラメータを含むストアド・プロシージャまたはファンクションを選択します。
「最上位のスタンドアロンAPIの使用」のステップ1から8を参照してください。
「Next」をクリックします。図9-53に示すように、「RowSets」ページが表示されます。
デフォルトで、アダプタ構成ウィザードでは、「XSD」テキスト・フィールドに表示されるこのREF CURSORのための、弱い型指定のXSDが生成されます。次の例は、このデフォルトの弱い型指定のXSDを示しています。
例 - デフォルトの弱い型指定の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を示します。
例 - 強い型指定の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に示すように、「イントロスペクトに失敗しました」ダイアログが表示されます。
アダプタ構成ウィザードでは、弱い型指定のXSDが生成され、デフォルトで「XSD」テキスト・フィールドに表示され、前のバージョンのXSDに対して行ったすべての編集が上書きされます。
ステップ3に戻り、少なくとも1行を含む行セットを返すテスト引数値を入力します。
ストアド・プロシージャまたはファンクションによって例外がスローされると、図9-56に示すように、イントロスペクション・エラー・ダイアログが表示されます。
アダプタ構成ウィザードでは、弱い型指定のXSDが生成され、デフォルトで「XSD」テキスト・フィールドに表示され、前のバージョンのXSDに対して行ったすべての編集が上書きされます。
ステップ3に戻り、少なくとも1行を含む行セットを返すテスト引数値を入力します。
必要に応じて、「XSD」テキスト・フィールドに表示されるスキーマを手動で編集することによって、強い型指定のXSDを微調整します。
「最上位のスタンドアロンAPIの使用」のステップ10に進みます。
次のパッケージがあるとします。
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の監査証跡を示します。
REF CURSOR
はどのような結果セットもサポートできるため、設計時に生成されるXSDは弱い型指定となります。デフォルトでは、アダプタ構成ウィザードによってREF CURSOR
に対して弱い型指定のXSDが生成されます。
ただし、ここからのXML出力を使用するのは困難です。弱い型指定のXSDに基づき、要素名ではなく列名を属性値としてXpath式またはXSLを作成することは非常に困難です。
行セットはすべての結果セットを表現できますが、一部のプロシージャについては、結果セットの構造が毎回同じであることが想定できるため、強い型指定のXSDを使用して記述することも可能です。一般的に、後で結果セットを別のXSDに変換する場合は、強い型指定のXSDが必要となります。
使用例において、強い型指定のXSDがより適している場合は、「強い型指定のXSDを使用した行セットのサポート」を参照してください。
この項には次のトピックが含まれます:
詳細は、「強い型指定のXSDまたは弱い型指定のXSDを使用した行セットのサポート」を参照してください。
選択したストアド・プロシージャまたはファンクションに、タイプがResultSet
である出力パラメータが含まれている場合は、このREF CURSORのための弱い型指定のXSDを次のように定義できます。
次のパッケージがあるとします。
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がバインドされます。
アダプタ構成ウィザードには、これらのタイプが使用され、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に示すように、元のプロシージャ名は完全修飾され、PKG.PLSQL
となっています。パラメータ・タイプR
はRECORD
の名前です。タイプT
はTABLE
の名前です。タイプB
はBoolean
です。生成されているラッパー・パッケージの名前は、サービス名bpel_
ServiceName
(bpel_UseJPub
など)から導出されます。これは、生成されたパッケージの名前で、ラッパー・プロシージャが含まれています。チェック・ボックスは、スキーマ・オブジェクトの作成時に、アダプタ構成ウィザードで既存のパッケージの上書きを強制する際に使用できます。
図9-60に示すように、「次へ」をクリックすると、アダプタ構成ウィザードの「終了」ページが表示されます。
このページのコンテンツでは、アダプタ構成ウィザードで検出されたものと、「終了」ボタンがクリックされると実行される処理が説明されます。次に、このページのコンテンツをまとめます。
生成されたWSDLの名前はUseJPub.wsdl
です。
JCAファイルの名前はUseJPub_db.jca
です。
2つのSQLスクリプトが作成され、BPELプロセス・プロジェクトに追加されます。
BPEL_USEJPUB.sql
- スキーマ・オブジェクトが作成されます。
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が起動されると、生成されたラッパー・プロシージャは元のプロシージャのかわりに実行されます。
プロシージャにラッパーの生成を必要とする特殊な型が含まれている場合は、いずれのパラメータのデフォルト句もラッパーには持ち越されません。たとえば、次のようなプロシージャがあるとします
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に要素がない場合、プロシージャ・コールから対応するパラメータを除外する必要があることを示すために実行時に使用されます。これらの要素のその他の属性は元のままです。
ここでは、Oracleデータベース・アダプタと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内で公開されるもの以外でカスタマイズするいくつかの方法が示されています。 |
この項には、次の項目が含まれます。
この項で説明する使用例の他に、Oracle SOA Sample Codeサイトにアクセスして入手できるサンプルのOracleデータベース・アダプタ使用例も参照してください。
表9-22に、Oracle BPEL PMおよびメディエータで提供されているOracleデータベース・アダプタのストアド・プロシージャのサンプルを示します。
表9-22 Oracleデータベース・アダプタの使用例 - ストアド・プロシージャ
チュートリアル名 | 説明 |
---|---|
|
PL/SQL |
|
強い型指定のXSDまたは弱い型指定のXSDを使用した |
|
|
使用例の多くで使用されているMOVIES
表の構造は、表9-4を参照してください。ほとんどのサンプルに含まれているreadme.txt
ファイルには、説明が記載されています。
この使用例では、JDeveloper BPELデザイナを使用したBPEL Process Managerへのストアド・プロシージャの統合方法について説明します。
この使用例には、次の項目が含まれます。
この使用例を実行するには、SCOTTスキーマ内で次のストアド・プロシージャを定義する必要があります。
SQL> CREATE PROCEDURE hello (name IN VARCHAR2, greeting OUT VARCHAR2) AS 2 BEGIN 3 greeting := 'Hello ' || name; 4 END; 5/
SOAコンポジットを含んだJDeveloperアプリケーションを作成する必要があります。使用例のアプリケーションとプロジェクトを作成する手順は、次のとおりです。
次の手順に従ってアウトバウンドOracleデータベース・アダプタ・サービスを作成します。
「コンポーネント・パレット」から、「データベース・アダプタ」を「外部参照」スイムレーンにドラッグ・アンド・ドロップします。
アダプタ構成ウィザードの「ようこそ」ページが表示されます。
「Next」をクリックします。
「サービス名」ページが表示されます。
「サービス名」フィールドにHello
と入力します。
「Next」をクリックします。
「サービス接続」ページが表示されます。
注意:
このアプリケーションをデプロイする前に、weblogic-ra.xml
ファイル内でJNDI名を構成していることを確認してください。
詳細は、「データソースの作成」および「Oracle JCAアダプタで使用するデータソースの推奨設定」を参照してください。
「新規データベース接続を作成します。」アイコンをクリックします。
「データベース接続の作成」ダイアログが表示されます。
「データベース接続の作成」ダイアログで次の詳細を入力します。
「接続名」フィールドに接続名を入力します。たとえば、Myconnection
と入力します。
接続タイプとして「Oracle (JDBC)」を選択します。
ユーザー名およびパスワードとしてscott
/tiger
と入力します。
「ホスト名」フィールドにホスト名を入力し、「JDBCポート」フィールドにJDBCポートを入力します。
「SID」を選択してSID名を入力します。または、「サービス名」を選択してサービス名を入力します。
「接続のテスト」をクリックします。「ステータス」ペインに成功メッセージが表示されます。
「OK」をクリックします。
「接続」フィールドにMyConnection接続が移入され、「JNDI」フィールドにeis/DB/MyConnectionが移入されます。
「Next」をクリックします。
「操作タイプ」ページが表示されます。
「ストアド・プロシージャまたはファンクションの呼出し」を選択して、「次へ」をクリックします。
「ストアド・プロシージャの指定」ページが表示されます。
「参照」をクリックします。「ストアド・プロシージャ」ペインでHELLO
を選択します。
「引数」タブにストアド・プロシージャのパラメータが表示され、「ソース」タブにストアド・プロシージャのソース・コードが表示されます。
「OK」をクリックします。
「ストアド・プロシージャの指定」ページが表示されます。「プロシージャ」フィールドにHELLOストアド・プロシージャが移入され、HELLOストアド・プロシージャの引数も表示されます。
「Next」をクリックします。
「詳細オプション」ページが表示されます。
任意の追加の詳細オプションを指定して、「次へ」をクリックします。
アダプタ構成ウィザードの「終了」ページが表示されます。
「終了」をクリックします。
「パートナ・リンクの作成」ダイアログ・ボックスが表示されます。パートナ・リンク名は、サービス名と同じHelloです。
「OK」をクリックします。
アウトバウンドOracleデータベース・アダプタが構成され、Greet BPELプロセスが表示されます。
リクエストのペイロードがInputParametersと一致する場合、すべてのINパラメータがリクエストに含まれます。この例では、INパラメータはnameのみです。
次の手順に従って、GreetRequestMessage
メッセージのメッセージ・パートを変更します。
レスポンスのペイロードがOutputParametersと一致する場合、すべてのOUTパラメータがレスポンスに含まれます。この例では、OUTパラメータはgreetingのみです。
GreetResponseMessage
メッセージ・パートに関する手順はGreetRequestMessageの場合と同じですが、次の例外があります。
2つ目のassignアクティビティでは、出力パラメータに値を割り当てます。
出力パラメータに値を割り当てる手順は、入力パラメータに値を割り当てる場合と同じですが、次の例外があります。
前述の手順で作成したSOAプロジェクトおよびアプリケーションについて、アプリケーション・プロファイルをデプロイする必要があります。JDeveloperを使用してアプリケーション・プロファイルをデプロイするには、次の手順を実行する必要があります。
HelloProject
をテストする前に、Oracle WebLogic Server管理コンソールを使用してデータソースを作成する必要があります。
手順は次のとおりです。
この使用例では、Oracleストアド・プロシージャの実行について説明します。ストアド・プロシージャへの入力は、ファイル・アダプタを使用してファイルを読み取ることで取得されます。ストアド・プロシージャが実行されると、表に入力パラメータからのデータが移入されます。
adapter-db-101-file2storedprocedure
の使用例を入手するには、Oracle SOA Sample Codeサイトにアクセスします。
この使用例には、次の項目が含まれます。
ファイルからストアド・プロシージャへの使用例を実行するには、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ファイルを使用して定義できます。
SOAコンポジットを含んだJDeveloperアプリケーションを作成する必要があります。次の手順に従って新規アプリケーションとSOAプロジェクトを作成します。
次の手順に従ってアウトバウンドOracleデータベース・アダプタ・サービスを作成します。
「データベース・アダプタ」を、「サービス・アダプタ」リストから「公開されたサービス」スイムレーンにドラッグ・アンド・ドロップします。アダプタ構成ウィザードの「ようこそ」ページが表示されます。
「Next」をクリックします。「サービス名」ページが表示されます。
「サービス名」フィールドにFile2SPService
と入力します。
「Next」をクリックします。
「サービス接続」ページが表示されます。
「新規データベース接続を作成します。」アイコンをクリックします。
「データベース接続の作成」ダイアログが表示されます。
「データベース接続の作成」ダイアログで次の詳細を入力します。
「接続名」フィールドに接続名を入力します。たとえば、MyConnection
と入力します。
接続タイプとして「Oracle (JDBC)」を選択します。
ユーザー名およびパスワードとしてscott
/tiger
と入力します。
「ホスト名」フィールドにホスト名を入力し、「JDBCポート」フィールドにJDBCポートを入力します。
「SID」を選択してSID名を入力します。または、「サービス名」を選択してサービス名を入力します。
「接続のテスト」をクリックします。「ステータス」ペインに成功メッセージが表示されます。
「OK」をクリックします。
「接続」フィールドにMyConnection接続が移入され、「JNDI」フィールドにeis/DB/MyConnectionが移入されます。
「Next」をクリックします。
「アダプタ・インタフェース」ページが表示されます。
「アダプタ・インタフェース」ページで、「操作およびスキーマから定義(後で指定)」を選択し、「次へ」をクリックします。
「操作タイプ」ページが表示されます。
図9-68に示すように、「ストアド・プロシージャまたはファンクションの呼出し」を選択して「次へ」をクリックします。
「ストアド・プロシージャの指定」ページが表示されます。
「参照」をクリックします。「ストアド・プロシージャ」ペインでADD_CUSTOMERS
を選択します。
「引数」タブにストアド・プロシージャのパラメータが表示され、「ソース」タブにストアド・プロシージャのソース・コードが表示されます。
「OK」をクリックします。
「ストアド・プロシージャの指定」ページが表示されます。
「プロシージャ」フィールドにADD_CUSTOMERS
ストアド・プロシージャが移入され、ADD_CUSTOMERS
ストアド・プロシージャの引数も表示されます。
「Next」をクリックします。
「詳細オプション」ページが表示されます。
任意の追加のオプションを指定して、「次へ」をクリックします。
「終了」ページが表示されます。
「終了」をクリックします。
「パートナ・リンクの作成」ダイアログが表示されます。
パートナ・リンク名は、サービス名と同じFile2SPServiceです。
「OK」をクリックします。
アウトバウンドOracleデータベース・アダプタが構成され、File2SP BPELプロセスが表示されます。
invokeアクティビティを作成してBPELプロセスを完成する必要があります。これにより、入力変数が作成されます。
次の手順に従ってinvokeアクティビティを作成します。
次の手順に従ってインバウンド・ファイル・アダプタ・サービスを作成します。これにより、ファイル・ディレクトリから入力XMLを読み取るサービスが作成されます。
ファイル・アダプタ・サービスはreceiveアクティビティに入力を提供し、receiveアクティビティは残りのBPELプロセスを開始します。
次の手順に従ってreceiveアクティビティを追加します。
作成した3つのコンポーネント(インバウンド・アダプタ・サービス、BPELプロセスおよびアウトバウンド・アダプタ参照)をアセンブルまたは接続する必要があります。コンポーネントを接続する手順は、次のとおりです。
ReadCustomer
内の小さい三角形を、「コンポーネント」領域のBPELプロセス内に緑の三角形として表示されるドロップ・ゾーンにドラッグします。File2SPService
内に緑の三角形として表示されるドロップ・ゾーンにドラッグします。前述の手順で作成したSOAプロジェクトおよびアプリケーションについて、アプリケーション・プロファイルをデプロイする必要があります。JDeveloperを使用してアプリケーション・プロファイルをデプロイするには、次の手順を実行する必要があります。
File2SPProject
をテストする前に、Oracle WebLogic Server管理コンソールを使用して、次の手順でデータソースを作成する必要があります。
ファイル・アダプタの入力ファイルを用意して、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プロセスをテストします。
Exalogicシステム上のCoherenceキャッシュとともにデータベース・アダプタを使用するとパフォーマンスが向上します。このパフォーマンス向上をもたらす機能は、データベース・アダプタ/Coherence統合と呼ばれます。
Exalogicシステム上のCoherenceキャッシュとともにデータベース・アダプタを使用した場合、2つの特定の使用例で効果が得られます。具体的には、次の操作の実行時にパフォーマンスを向上させることができます。
データベースに対する挿入/更新
主キーによる選択
データベース・アダプタおよびCoherenceキャッシュを使用してデータベースに対して挿入および更新を実行した場合、仲介サービスであるCoherenceデータソースが内部的に使用されてパフォーマンスが向上します(このデータソースはCoherenceキャッシュと呼ばれ、基本的にはインメモリー・データベースに該当します)。
通常、挿入/削除/更新の各操作はデータベースに対して直接実行します。パフォーマンスを向上させるには、この前面に配置されたCoherenceのインメモリー・データベース(write-behindマップ)に対して最初にこれらの操作を実行することで、キャッシュを利用した読取り/書込み操作を有効にします。
注意:
Coherence Write-Behindでのアウトバウンド挿入にデータベース・アダプタを使用する場合は、データベース表に主キー列の索引があることを確認してください。
このようなCoherenceマップを使用すると、挿入/削除/更新の各操作を実行するBPEL/OSBプロセスによって、データベースとのやりとりが行われることなくすぐにコール元に結果が返されるため、これらのプロセスの待機時間が改善します(実際には、かわりにCoherenceキャッシュ仲介サービスによってデータベースが集中的に更新されます)。
大量のレコードをまとめて処理する場合には、この方法でCoherenceを使用して、レコードの更新をより簡単かつ効率的に行うことができます。
注意:
Coherenceキャッシュによる効果が見込めないデータベース・アダプタの使用例には、インバウンド・ポーリング、Pure SQLの起動、ストアド・プロシージャ・コール、複数の行を返す通常のSELECTなどの操作があります。
データベース・アダプタ/Coherence統合によって改善する2つ目の使用例は、問合せパフォーマンスであり、特にSELECT文の使用例が最適化されます。データベース・アダプタ/Coherence統合では、多数の異なるプロセス・インスタンスによって頻繁にアクセスされる可能性があるデータをキャッシュすることによって、問合せパフォーマンスを向上させています。
データベース・アダプタ/Coherence統合による選択の最適化を使用した場合、データベース・アダプタでは、問合せを最適化するために、データベースに進む前にまず読取り専用のCoherenceキャッシュ(L2読取りキャッシュ)を使用してキャッシュ・ヒットの有無をチェックします。つまり、問い合せるデータがCoherenceキャッシュ内に存在するかどうかを最初にチェックしてそこに見つからなかった場合に同じデータをデータベース内でチェックする方法によって、問合せを最適化しています。
Coherenceでキャッシュ・ミスが発生した場合、そのデータがデータベースから読み取られてCoherenceキャッシュにロードされます。一般的にキャッシュ・ミスに対するキャッシュ参照の比率は高いため、データベースに対して問合せを実行するよりもCoherenceキャッシュをチェックする方が高速になるということがこの処理の前提になっています。
すべての問合せにおいてキャッシュ参照、つまりCoherenceとデータベース・アダプタの統合による効果が得られるわけではありません。Coherenceキャッシュにヒットした場合でも、指定した問合せ条件を満たすすべてのレコードがそこに含まれていたかどうかは不明であり、データベース内にヒットする追加のレコードが存在していてもそれがキャッシュ内に存在しなかったために返されなかった可能性もあります。
このため、問合せ最適化機能では、「主キーによる選択」という新しい種類のデータベース・アダプタ操作を利用できます。既存の「選択」およびqueryByExample操作とは異なり、「主キーによる選択」の使用時には1行のみを返すことができます。主キーを選択して1行を返すことで、実際には、より具体的なレコードが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に記載されています
WebLogic Server 10.3.5とともにCoherenceデータベース・アダプタを使用するには、次の手順を実行する必要があります。
データベース・アダプタの現在の設計では、アダプタによって選択および挿入をEclipseLinkレイヤーに対して実行し、そこから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キャッシュが更新されます。
データベース・アダプタ・ウィザードの「操作タイプ」画面で「キャッシュの使用方法」ドロップダウンから「読取り」
を選択すると、読取りキャッシュを使用できます。
読取りキャッシュでは、データベース・アダプタによってデータベースにレコードを挿入する場合、またはデータベースからレコードを選択する場合に、Coherenceキャッシュが更新されます。行を識別する(つまり、主キーを指定する)すべての問合せにおいて、まずCoherenceキャッシュがチェックされ、可能な場合にデータベースとのやりとりが回避されます。Coherenceキャッシュは分散型の単なるハッシュ・マップとみなすことができるため、特定の主キーを選択することで、Coherenceキャッシュ・マップを通じたルックアップの高速化が可能になります。
図9-77は、データベース・アダプタ・ウィザードの「操作タイプ」画面に表示されたキャッシュなしオプション(「なし」
を選択)を示しています。
図9-77 キャッシュなしが選択されたデータベース・アダプタ構成ウィザードの「操作タイプ」画面
この画面では「なし」
オプションが選択されており、すべてのアウトバウンド操作が有効です。このオプションを選択して「次へ」
または「終了」
を選択すると、選択した操作のいずれにもプロパティCacheUsage
は含まれなくなります。このプロパティが存在しない状態は、JCAアクティブ化プロパティCacheUsage
が値none
になっているのと同じです。
「キャッシュの使用方法」として「なし」
オプションを選択した場合、次のオプションの操作のみが事前に選択されます。
Merge
Insert Only
Select
「操作タイプ」画面では、読取り/書込みキャッシュを有効化できます。図9-78を参照してください。このオプションを選択して「次へ」
または「終了」
を押すと、JCAプロパティCacheUsage
の値がread-write
に設定されます。
この画面で 「キャッシュの使用方法」
ドロップダウンから「読取り-書込み」
オプションを選択した場合の各操作の使用方法を理解するには、次のリストを参照してください。
「挿入または更新(マージ)」
は有効であり、ラベルの末尾には「キャッシュの使用」
という文字列が付加されます。
「挿入のみ」
は無効であり、基礎となるキャッシュ・ストアによって常にマージが実行されます。
「更新のみ」
は無効であり、基礎となるキャッシュ・ストアによって常にマージが実行されます。
「削除」
は選択可能ですが、事前には選択されておらず、選択すると末尾に 「キャッシュの使用」
という文字列が付加されます。
「選択」
は無効であり、この問合せは、Coherenceマップで実行されるCoherenceフィルタに変換されます。
「例による問合せ」
は無効であり、データベース・アダプタ/Coherence統合の問合せは、Coherenceマップで実行されるCoherenceフィルタに変換されます。
「主キーによる選択」
のラベルの末尾には、「キャッシュの使用」
という文字列が付加されます。
「操作タイプ」画面の「キャッシュの使用方法」
オプションを使用すると、読取りキャッシュを有効化できます。図9-79を参照してください。画面上でこのオプションを選択して「次へ」
または「終了」
を押すと、JCAプロパティCacheUsage
の値がread
に設定されます。
読取りキャッシュ・オプションでは、「主キーによる選択」
操作のみが事前に選択されています。他の操作でキャッシュを更新することは可能ですが、キャッシュを通じたCoherenceとデータベース・アダプタの統合機能によって実行する意味がある操作は「主キーによる選択」
のみです。読取りキャッシュはキャッシュの変更を伴わないため、この画面の「操作タイプ」の各操作は無効になります。
「選択」
および「例による問合せ」
は無効にはなりませんが、キャッシュは直接更新されません。データベース・アダプタ/Coherence統合機能では「選択」
をデータベースに対して実行しますが、返される任意の行でCoherenceキャッシュを更新します。
読取りキャッシュの一般的な操作では、返されたオブジェクトがCoherenceキャッシュに存在した場合、データベース・アダプタ/Coherence統合機能により結果セットから新しいコピーが作成されるのではなくキャッシュ内のオブジェクトが返されます。
この操作により、マスター・データベース・レコードに複数の詳細がある場合に、その詳細に対する問合せを再度行う必要がないため、パフォーマンスが向上します。
問合せの動作は「選択」
と同じになります。たとえば、主キーが設定されている(キャッシュ・ヒットが得られない)XMLデータにこれが当てはまります。
データベース・アダプタ/Coherence統合を使用している場合、XAトランザクションを読取り/書込み操作とともに使用することはできません。これは、データベース・アダプタをCoherenceと統合した場合、挿入がCoherenceキャッシュ、データベースの順に実行されますが、この順番がXAトランザクションの規定に違反するためです。
ただし、データベース・アダプタ/Coherence統合を使用して、XAトランザクションを読取り操作とともに使用することはできます。
データベース・アダプタ/Coherence統合を伴わない、データベース・アダプタを使用したデータベース・トランザクションでも、引き続きXAトランザクション・モデルを使用できます。
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キャッシュを共有できます。
例による問合せを使用すると、問合せで使用する属性のみを移入したサンプル・オブジェクト・インスタンスの形式で、問合せ選択基準を指定できます。EclipseLinkの例による問合せサポートには、ユーザーが変更できる例による問合せポリシーも含まれています。EclipseLinkユーザーは、このポリシーを編集して、例による問合せのデフォルト動作を変更できます。
データベース・アダプタは、基本的に、例による問合せ操作の基本セットを提供して、例による問合せポリシーの実装またはカプセル化を提供します。次の操作のタイプが含まれます。
LIKEなどの演算子を使用して、属性を比較する場合。デフォルトでは、例による問合せで使用できるのはEQUALSのみです。
例による問合せで無視される値のセット(IGNOREセット)を変更する場合。デフォルトで無視される値は、ゼロ(0)、空の文字列およびFALSEです。
属性の値がIGNOREセットに含まれるものであっても、例による問合せでその値を強制的に考慮する場合。
属性値としてisNullまたはnotNullを使用する場合。(ただし、「使用に関する制約事項」を参照)。
データベース・アダプタでは、データベース・アダプタ構成ウィザードの高度な操作画面で使用可能な既存の操作と値に、追加の操作と値を追加して、この機能が提供されます。
データベース・アダプタ構成ウィザードで「例による問合せ」オプションを選択すると、追加の問合せを使用するか、または問合せと作成した他の問合せを組み合せることができます。
注意:
QueryByExampleでは、複数の表の使用はサポートされません。関連表の場合は、例による問合せに対してPureSQLを使用する方が適切です。
図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」が指定されたデータベース・アダプタ構成ウィザードの高度な操作画面
数値のlikeIgnoreCase
など、一部の組合せは意味をなしていませんが、使用に対する制限は設定されていません。
リストされているパラメータ演算子だけでなく、org.eclipse.persistence.expressions.Expression
にある単一のパラメータ演算子を選択できます。これらの演算子のいずれか1つを設定するには、JCAファイルを直接編集します。
「equal」はデフォルトであるため、終了を選択したときに値がJCAファイルに表示されません。これらのプロパティがない古いプロジェクトには、自動的に追加されます。
JDev式ビルダーと例による問合せを組み合せて使用できます。たとえば、問合せがWHERE some_column IS NOT NULL
操作を実行する場合は、この最初の操作を通常のSelect
を使用してモデル化し、例による問合せ操作も選択できます。JCAファイルで、次の選択操作のQueryName
プロパティを例による問合せ操作にコピーします。
<property name="IsQueryByExample" value="true"/> <property name="QueryName" value="dbReferenceSelect"/>
例による問合せとは異なり、アクティブ化ファイルに操作をコピーする必要はありません。
レコード例に次が含まれる場合、
<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はありません。明示的な問合せを作成する方が適切です。
データベース・アダプタでは、文字列の表示にUTF-16形式が使用されます。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ファイルは、データベース・アダプタ構成ウィザードによって自動的に生成されるため、データベース・アダプタ構成ウィザードの実行時にこれらの手順を繰り返す必要があります。