この章では、Oracle BPEL Process ManagerおよびOracle Mediator(メディエータ)とともに機能するOracle JCA Adapter for Database(Oracleデータベース・アダプタ)について説明します。この章では、ストアド・プロシージャおよびファンクション(Oracleデータベースのみ)のサポートについても説明します。また、Oracleデータベース・アダプタおよびストアド・プロシージャの使用例も参照できます。
この章には、次の項目が含まれます。
Oracleデータベース・アダプタを使用すると、Oracleデータベースまたはサード・パーティのデータベースとBPELプロセスとのJDBCを介した通信が可能になります。Oracleデータベース・アダプタ・サービスは、Oracle BPEL Process Manager(Oracle BPEL PM)のアダプタ構成ウィザードを使用してBPELプロセスのパートナ・リンク内で定義されます。
この項には、次の項目が含まれます。
この項では、Oracleデータベース・アダプタの機能概要について説明します。Oracleデータベース・アダプタを使用すると、Oracle SOA SuiteおよびOracle Fusion Middlewareとデータベース・エンドポイントとの通信が可能になります。データベース・エンドポイントとしては、ANSI SQL標準に準拠し、JDBCドライバを備えたOracleデータベース・サーバーおよびリレーショナル・データベースがあげられます。
Oracleデータベース・アダプタの表やビューは原則的に、できるかぎり透過的でノン・イントルーシブにSOA表およびSQLに対して公開されます。表およびSQLはリレーショナル・データベース製品に必ず備わっているため、統合の観点からは、標準にフォーカスした一般的なソリューションを作成すると、最も大きな影響を及ぼすことができます。データベースをSOAに対して公開する場合、一般的なソリューションとは、情報の問合せに最適なSQLのテクノロジと、情報の転送および表現に最適なXMLのテクノロジを統合することです。ストアド・プロシージャのサポートは各種データベースの中ではそれほど標準的ではありませんが、Oracleデータベース・アダプタでは、このマニュアルで説明するように、ストアド・プロシージャがサポートされています。
Oracleデータベース・アダプタは、Oracle Application Server上で動作するJCA 1.5コネクタです。これは、データベース通信を実現するために、基礎となるJDBCコネクタ/ドライバに依存します。JDBCとは対照的に、それは非プログラム的です。相互作用(一連のSELECT
、UPDATE
、INSERT
)の概略は、アダプタ構成ウィザードを使用してモデル化されます。入力/出力はXMLであり、XMLが入力パラメータとして使用されたり、XMLに変換された結果セットという形式が最もよく見られます。これらのXMLの入出力により、Oracleデータベース・アダプタ・サービスをOracle Fusion Middlewareにプラグインできるようになります。
既存のリレーショナル・スキーマにアクセスするには、アプリケーションおよびSOAプロジェクトを作成し、アダプタ構成ウィザードを使用して次の手順を実行します。
リレーショナル・スキーマ(1つ以上の関連表)をインポートしXMLスキーマ(XSD)としてマップ
詳細は、第9.4.1項「リレーショナルからXMLへのマッピング」を参照してください。
SELECT
、INSERT
およびUPDATE
などのSQL操作をWebサービスとして抽出
詳細は、第9.4.2項「WebサービスとしてのSQL操作」を参照してください。
データベース・イベントによるOracle Fusion Middlewareプロセスの開始
第9.1.1.1項「Oracleデータベース・アダプタとBPEL PMの統合」で説明するように、Oracleデータベース・アダプタは現在、SOAプロセスのコンテキスト内でのみ使用できます。
Oracle Streams Advanced Queuing(Oracle AQ)はOracle Databaseの機能ですが、Oracle AQと統合するには、個別に特化されたOracle JCA Adapter for AQを使用します。詳細は、第7章「Oracle JCA Adapter for AQ」を参照してください。
非リレーショナル・データベースとレガシー・システム(AS/400上のDB2など少数の例外は除く)の場合は、アプリケーション・アダプタおよびメインフレーム・アダプタを使用できます。アプリケーション・アダプタおよびメインフレーム・アダプタの詳細は、次の各項を参照してください。
Oracleデータベース・アダプタの詳細は、次の各項を参照してください。
Oracleデータベース・アダプタは、データベース・イベントのポーリング(通常は入力表に対するINSERT
操作)とプロセスの開始を行うために使用される場合、メディエータ・コンポーネントまたはSOAコンポジットでは、公開サービスと呼ばれます。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の取得が必要です。
詳細は、第9.6項「JDBCドライバとデータベース接続の構成」を参照してください。
ただし、場合によっては、weblogic-ra.xml
エントリには、基礎となるデータソースの単なる名前以外のものも含まれます。これらのプロパティの詳細は、第9.5項「デプロイメント」を参照してください。
実行時には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プロジェクトを作成します。
JDeveloperを開きます。
「アプリケーション・ナビゲータ」で、「新規アプリケーション」をクリックします。
図9-2に示すように、「汎用アプリケーションの作成 - アプリケーションの名前付け」ページが表示されます。
「アプリケーション名」フィールドにアプリケーションの名前を入力します。
「アプリケーション・テンプレート」リストで、「汎用アプリケーション」を選択します。
「次へ」をクリックします。
図9-3に示すように、「汎用アプリケーションの作成 - プロジェクトの名前付け」ページが表示されます。
「プロジェクト名」フィールドにわかりやすい名前を入力します。
「プロジェクト・テクノロジ」タブの「選択可能」リストで「SOA」をダブルクリックし、「選択済」リストに移動します。
「次へ」をクリックします。図9-4に示すように、「汎用アプリケーションの作成 - SOA設定の設定」ページが表示されます。
「コンポジット・テンプレート」リストから「BPELを使用するコンポジット」を選択して「終了」をクリックします。
新規アプリケーションおよびSOAプロジェクトが作成されました。これにより、SOAコンポジットが自動的に作成されます。
図9-5に示すように、「BPELプロセスの作成」ページが表示されます。
「名前」フィールドにBPELプロセスの名前を入力します。
「テンプレート」リストで「サービスを後で定義」を選択し、「OK」をクリックします。
BPELプロセスが作成されました。
次のステップは、Oracleデータベース・アダプタ・サービスを定義することです。次の手順に従ってOracleデータベース・アダプタ・サービスを作成します。
「コンポーネント・パレット」で、「SOA」を選択します。
「サービス・アダプタ」リストから、「データベース・アダプタ」を「composite.xml」ページの公開されたコンポーネント・スイムレーンにドラッグ・アンド・ドロップします。
「アダプタ構成ウィザード」が表示されます。
注意: Oracleデータベース・アダプタ・サービスをBPELプロセスの一部として作成するには、「サービス・コンポーネント」から「コンポーネント」にBPELプロセスをドラッグ・アンド・ドロップします。それをダブルクリックします。次に、BPELの「コンポーネント・パレット」で、「データベース・アダプタ」を「BPELサービス」から「パートナ・リンク」スイムレーンにドラッグ・アンド・ドロップします。 |
「次へ」をクリックします。図9-6に示すように、「サービス名」ページが表示されます。次の情報を入力します。
「サービス名」フィールドにサービス名を入力し、「次へ」をクリックします。「サービス接続」ページが表示されます。
アダプタ構成ウィザードの使用を続行するには、第9.2.3項「データベースへの接続」を参照してください。
図9-7に、サービスで使用するデータベース接続を選択する場所を示します。これは、サービスを構成する表をインポートするデータベースです。これは、サービスを構成する表をインポートするデータベースです。ここで、作成する新しいJDeveloperアプリケーションごとにデータベースを再作成できます。
データベース接続を識別するJava Naming and Directory Interface(JNDI)の名前を指定できます。デフォルト名はeis/DB/<ConnectionNameInJDev>
です。
詳細は、第9.5項「デプロイメント」を参照してください。
次の事項に注意してください。
本番環境では、アダプタのデプロイメント・ディスクリプタ(weblogic-ra.xml
)にJNDIエントリを追加することをお薦めします。この場合、管理モードで作業することでOracleデータベース・アダプタのパフォーマンスが向上します。
データソースとアウトバウンド接続プールについては、第2.18項「アダプタ・コネクション・ファクトリの追加」を参照してください。
「次へ」をクリックすると、データベースへの接続が試行されます。接続できない場合は、既存のパートナ・リンクを編集している場合でも、次のウィンドウには進めません。
アダプタ構成ウィザードの使用を続行するには、第9.2.4項「操作タイプの選択」を参照してください。
図9-8に、このサービスに構成する操作タイプを指定する場所を示します。
次の操作タイプを使用できます。
ストアド・プロシージャまたはファンクションの呼出し
サービスでストアド・プロシージャまたはファンクションを実行する場合にこのオプションを選択します。詳細は、第9.7項「ストアド・プロシージャおよびファンクションのサポート」を参照してください。
表に対して操作を実行
このオプションは、アウトバウンド操作に対して選択します。「挿入/更新」、「挿入のみ」、「更新のみ」、「削除」、「選択」またはこの6つのオプションを任意に組み合せて選択できます。これらの操作は、同等のSQL操作であるMERGE
、INSERT
、UPDATE
、DELETE
およびSELECT
に変換されます。
詳細は、第9.4.2.1項「DML操作」を参照してください。
注意:
|
表の新規レコードまたは更新されたレコードをポーリング
この操作は、インバウンド操作(つまり、receiveアクティビティと関連付けられている操作)に対して選択します。この操作タイプでは、指定された表がポーリングされ、追加された任意の新しい行の処理用に返されます。また、ポーリング間隔も指定できます。
詳細は、第9.4.2.2項「ポーリング計画」を参照してください。
図9-9に示すように、データベースからデータが読み取られた後に実行できるポーリング操作は次のとおりです。
Pure SQLの実行
任意の複雑な文、集計問合せ(結果は行ベースではありません)およびXMLType
列を処理する場合に役立ちます。アダプタ構成ウィザードのこの使用方法は、第9.3.2項「Pure SQL - XMLタイプのサポート」を参照してください。
注意: スキーマ・バインドXML表はサポートされていません。 |
アダプタ構成ウィザードのこれ以外の使用方法は、第9.2.5項「表の選択およびインポート」を参照してください。
図9-10に、操作のルート・データベース表を選択する場所を示します。複数の関連する表を使用している場合は、これがリレーションシップ・ツリーの最上位の表(または最上位の親表)になります。
「表のインポート」を選択すると、サブウィザードが起動します。このウィザードで、データベースからインポートする複数の表を検索および選択できます。表を削除すると、残された関連する表にあるリレーションシップが削除されます(元に戻されます)。このウィザードを編集モードで実行している間に基礎となる表が変更された場合、その変更内容を示す警告が表示されます。調整するには、表を再度インポートします。「表のインポート」をクリックして複数の表を選択すると、外部キーの制約に基づいてそれらの表の間のリレーションシップが推測されます。ただし、インポートした表ごとに「表のインポート」を起動する場合は、リレーションシップは推測されません。
注意: 表を再インポートすると、その表に対して任意で定義したカスタムのリレーションシップとカスタム |
アダプタ構成ウィザードの使用を続行するには、第9.2.6項「主キーの定義」を参照してください。
インポートした表にデータベースで定義された主キーがない場合、図9-11に示すように、各表に主キーを指定するよう求められます。インポートしたすべての表に主キーを指定する必要があります。複数のフィールドを選択すると、マルチパートの主キーを指定できます。
ここで指定する主キーは、オフライン・データベース表に記録され、データベース・スキーマには保存されないため、データベース・スキーマは変更されません。
アダプタ構成ウィザードの使用を続行するには、第9.2.7項「リレーションシップの作成」を参照してください。
注意: Oracleデータベース・アダプタでは、主キーが定義されている表のみがサポートされることに注意してください。表で主キー制約が明示的に定義されていない場合は、設計時にアダプタ構成ウィザードを使用してOracleデータベース・アダプタを定義する際に指定する必要があります。有効な主キーを指定しなければ、一意の制約は保証されず、これにより実行時にメッセージが失われる可能性があります。つまり、重複する主キー値を持つ行が失われる可能性があります。 |
注意: 主キー列には |
図9-12に、ルート・データベース表およびその他の関連する表に定義されたリレーションシップを示します。「リレーションシップの作成…」をクリックして2つの表の間にリレーションシップを作成したり、「リレーションシップの削除」をクリックしてリレーションシップを削除できます。リレーションシップの名前を変更するには、「リレーションシップの名前変更」をクリックします。
リレーションシップの作成に関して次の事項に注意してください。
データベース上に表間の外部キー制約が存在する場合、表をインポートすると、ソース表(外部キー制約を含む表)からターゲット表に1対1(1:1)、ターゲット表からソース表に1対多(1:M)の2つのリレーションシップが自動的に作成されます。
図9-12に示すように、ルート・データベース表からアクセス可能なリレーションシップのみが表示されます。リレーションシップを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-13に、リレーションシップを作成する場所を示します。
リレーションシップを作成する手順は次のとおりです。
親表と子表を選択します。
マッピング・タイプ(1対多、1対1または子表に外部キーのある1対1)を選択します。
外部キー・フィールドを主キー・フィールドに関連付けます。
オプションでリレーションシップに名前を付けます(デフォルト名が生成されます)。
注意: 親表として選択できるのは、ルート表からアクセス可能な表のみです。 |
アダプタ構成ウィザードに最初に表がインポートされると、データベースの各フィールドに対応する、TopLinkのフィールドへの直接的なマッピングが作成されます。図9-14および図9-15に示すスキーマがあるとします。
これら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-16に、インポートされた表の定義から作成された属性フィルタを示します。これには定義したリレーションシップも含まれます。
オブジェクト・フィルタにセルフ・リレーションシップ(従業員対従業員の管理者のリレーションシップなど)が含まれる場合、ツリーではループとして表示されます。XSDファイルではループは表示されません。これはディスクリプタ・オブジェクト・モデルであり、XSDファイルではありません。
このページでは、入力(MERGE
、INSERT
)であるか出力(SELECT
)であるかに関係なく、XMLファイルに表示する列を選択します。不要な列や読取り専用(変更不可)の列の選択をここで解除できます。
アダプタ構成ウィザードの使用を続行するには、第9.2.9項「WHERE句の定義」を参照してください。
サービスにSELECT
問合せ(インバウンド・ポーリング・サービスまたはSELECT
を含むアウトバウンド・サービスなど)が含まれる場合、SELECT
文のWHERE
句をカスタマイズできます。
注意:
|
図9-17に、アウトバウンド・サービスのWHERE
句を定義する場所を示します。
注意:
|
WHERE
句の最も基本的な式は、式の右側(RHS)の内容に応じて、次に示す3つのいずれかになります。
EMP.ID = 123
この場合、RHSはリテラル値です。このRHSは、図9-18に示す「リテラル」オプションです。
EMP.ADDR_ID = ADDR.ID
この場合、RHSは別のデータベース・フィールドです。このRHSは、図9-18に示す「問合せキー」オプションです。
EMP.ID = ?
この場合、RHSの値は実行時に指定する必要があります。これは、図9-18に示す「パラメータ」オプションです。
WHERE
句の作成を開始する前に「追加」をクリックして、WHERE
句で必要なパラメータを作成します。WHERE
句を作成するには、図9-18に示すように、「編集…」をクリックして「式ビルダー」を起動します。
より複雑なWHERE
句(サブSELECT文およびFUNCION文)をモデル化する場合、およびORDER BY
句を追加する場合は、SQLプロシージャを編集して「次へ」をクリックします。ただし、この場合、ハードコードされたSQL
によって後からメンテナンス・オーバーヘッドが発生し、プラットフォーム非依存性を失う可能性があります。
FROM
句に記述されている列の変更は、列数と各列の列型が変更されなければ可能です。より複雑な変更については、任意のSQL
を直接入力できる「Pure SQLの実行」オプションの使用を検討してください。
単一結果セットを戻す方法
複数の関連表の問合せ時にTopLink
で使用される文の合計数に影響する拡張機能を使用するには、「選択条件の定義」ページで「外部結合を使用してマスター表とディテール表の両方の単一結果セットを返す」を選択する必要があります。最も安全な方法はデフォルト(表ごとに1)を使用することで、この機能ではすべての関連表が単一の結果セットに外部結合されることで合計が1になります。
アダプタ構成ウィザードの使用を続行するには、第9.2.10項「読取り後計画の選択」を参照してください。
「表に対して操作を実行」を選択した場合は、手順を省略して第9.2.12項「詳細オプションの指定」に進んでください。
インバウンド操作の構成時には、1つ以上の行が読み取られた後の処理に関して次のオプションがあります。
図9-19にこれらのオプションを示します。
アダプタ構成ウィザードの使用を続行するには、第9.4.2.2項「ポーリング計画」を参照してください。
このオプションでは、ルート・データベース表のフィールドを更新して、その行が読取り済であることを示します。図9-20に示すように、構成の完了後に問合せのWHERE
句が自動的に更新されます。
この方法を使用すると、データベース表は図9-21のようになります。
次の事項に注意してください。
行150および153はすでに読み取られて処理されています。
STATUS列にUNPROCESSED
と表示されているため、次のポーリング・イベントで、行152が読み取られて処理されます。Unread Value
が明示的に指定されているため、行151は読み取られません。
行154にはLOCKED
というフラグが付いているため読み取られません。表が他のプロセスに使用されている場合、この予約値を使用できます。
このオプションでは、別の順序表の最終読取り行を追跡します。図9-22に指定する情報を示します。構成が完了すると、問合せのWHERE
句が自動的に更新されます。
これらの設定を使用すると、順序表は図9-23のようになります。
行が読み取られるたびに、この表は読み取られたIDで更新されます。次のポーリング・イベントが発生すると、最終読取りID(154)より大きなIDの行が検索されます。
使用される一般的な列は、event_id
、transaction_id
、scn
(システム変更番号)、id
またはlast_updated
です。通常、これらの列には順序番号またはsysdate
が移入され、値は(一定量で)増加します。
この操作は、順序表: 最終更新計画を採用するときに選択します。図9-24に、アダプタ構成ウィザードの「外部順序表」ページを示します。このページで、この操作の実行に必要な詳細を指定します。
このオプションは、順序ファイルを更新する場合に使用します。図9-25に、アダプタ構成ウィザードの「順序ファイルの更新」ページを示します。このページで、この操作の実行に必要な詳細を指定します。
追加のポーリング・オプションがある場合は、このページで指定できます。図9-26に、アダプタ構成ウィザードの「ポーリング・オプション」ページを示します。
このページでは、新規の行またはイベントに関してデータベース表をポーリングする方法の詳細を指定します。
「ポーリング頻度」リストから、新規のレコードまたはイベントのポーリング頻度を選択します。
「XML文書ごとのデータベース行数」フィールドで、Oracle BPEL PMまたはメディエータにイベントを送信する際の、XML文書ごとの行数を指定します。これは、データベース・アダプタとコンシューマ(Oracle BPEL PMまたはメディエータ)の間のバッチ設定です。
「トランザクションごとのデータベース行数」フィールドで、「無制限」を選択するか、または1回のトランザクションで処理する表の行数を示す値を入力します。
イベントに関してデータベースをポーリングする場合は、「ソート順」リストを使用して、戻される行を選択した列でソートできます。ベスト・プラクティスは、追加の構成なしではメッセージの順序付けが保証されないため、「<順序付けなし>」を選択することです。
「SQL」フィールドには、SQL構文が正しくない場合にメッセージが赤で表示されます。
ポーリング・オプションの指定の詳細は、「ポーリング・オプション」ページで「ヘルプ」をクリックするか、[F1]を押します。
詳細オプションを指定できます。図9-27に、アダプタ構成ウィザードの「詳細オプション」ページを示します。このページでは、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-28に、アダプタ構成ウィザードの「カスタム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以外のドライバは |
デプロイメント・ディスクリプタ(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データソースの推奨設定については、第2.20項「Oracle JCAアダプタで使用するデータソースの推奨設定」を参照してください。
Oracle WebLogic Serverではdata-sources.xml
ファイルを編集できません。第2.18.1項「データソースの作成」の説明に従って、Oracle WebLogic Server管理コンソールを使用してデータソースを作成する必要があります。
両方のOracleデータベース・アダプタの起動が1単位としてコミットまたはロールバックするためにグローバル・トランザクションに関与する場合は、同じグローバル・トランザクションに関与する必要があります。BPELでは、そのためにトランザクション境界の位置、つまりチェックポイントでデハイドレーション・ストアに書き込み、現行のグローバル・トランザクションをコミットし、新規トランザクションを開始する位置を認識する必要があります。
BPELプロセスでのトランザクション境界は、receiveアクティビティまたはwaitアクティビティの前、あるいは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スキーマからリレーショナル・スキーマを生成できます。
注意: スキーマ・バインド |
詳細は、次を参照してください。
REF CURSOR
はどのような結果セットもサポートできるため、設計時に生成されるXSDでもこれが許可され、例9-1に示すようなXSDになります。
注意: Oracle Databaseのストアド・プロシージャによって返される結果セットは、 |
例9-1 弱い型指定のXSD
<refCursorOutputParam> <Row> <Column name="DEPTNO" sqltype="NUMBER">20</Column> ... </Row> </refCursorOutputParam>
ただし、ここからのXML出力を使用するのは困難です。弱い型指定のXSDに基づき、要素名ではなく列名を属性値としてXpath式またはXSLを作成することは非常に困難です。
行セットはすべての結果セットを表現できますが、一部のプロシージャについては、結果セットの構造が毎回同じであることが想定できるため、強い型指定のXSDを使用して記述することも可能です。一般的に、後で結果セットを別のXSDに変換する場合は、強い型指定のXSDが必要となります。強い型指定のXSDは例9-2に示すようなXSDになります。
例9-2 強い型指定の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開発者ガイドおよびリファレンス』の第10章「プロキシ認証」を参照してください。
ペイロードのストリーミングのサポートを有効化するには、図9-26に示すように、ポーリング・オプションを指定する際に「ストリーミングの有効化」チェック・ボックスを選択する必要があります。この機能を有効化すると、ペイロードはメモリー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データベース・アダプタでは、アクティブ/アクティブ設定で高可用性がサポートされます。アクティブ/アクティブ設定では、インバウンド・データベース・アダプタに分散ポーリング・テクニックを使用して、同じデータが複数回取得されないことを保証できます。詳細は、第9.3.8.1項「分散ポーリングのベスト・プラクティス1: SELECT FOR UPDATE(SKIP LOCKED)」を参照してください。他のアダプタと同様に、Oracle Database Adapterもアクティブ/パッシブ設定内でシングルトン動作に構成できます。これにより、アクティブ/パッシブ設定で動作するパフォーマンスの高いマルチスレッドのインバウンドOracleデータベース・アダプタ・インスタンスは、展開パターンに従ってクラスタ全体で複数のコンポジット・インスタンスを起動できます。また、Oracleデータベース・アダプタは、データベースに障害が発生した場合やデータベースが再起動した場合も高可用性機能をサポートします。DBアダプタが再起動し、メッセージも失いません。
次の各項では、複数のOracle BPEL PMまたはメディエータ・ノードに複数のOracleデータベース・アダプタ・プロセス・インスタンスをデプロイするためのベスト・プラクティスについて説明します。
複数のOracle BPEL PMまたはメディエータ・ノードに複数のOracleデータベース・アダプタ・プロセス・インスタンスをデプロイするための1つ目のベスト・プラクティスは、アダプタ構成ウィザードを使用して、アダプタ構成ウィザードの「分散ポーリング」チェック・ボックスを設定し、さらにMaxTransactionSize
を設定することです。adapter _db.JCA
プロパティNumberOfThreads
を設定することによって、アダプタ同時実行性が向上します。
この場合、Oracleデータベースでは、自動的に構文SELECT FOR UPDATE SKIP LOCKED
が使用されます。同時スレッドにより、使用可能な行の選択およびロックがそれぞれ試行されますが、ロックはフェッチ時にのみ取得されます。フェッチしようとしている行がロックされている場合、かわりに次のロックされていない行がロックおよびフェッチされます。複数のスレッドがすべて同じポーリング問合せを同時に実行する場合、各スレッドは、処理されていない行の非結合サブセットを比較的迅速に取得する必要があります。
Oracle以外のデータベースでは、SELECT FOR UPDATE
によって、同じ行が複数回処理できないことが安全に保証されますが、スケーラビリティが低下する場合があります。パーティション・フィールドを追加して使用するか、または2つ目のベスト・プラクティス、つまり、基本的には単一ノード上でマルチスレッド処理と展開を使用するかを検討する必要があります(第9.3.8.2項「分散ポーリングのベスト・プラクティス2: 最初に単一ノードでチューニングする」を参照)。
注意: 複数のアクティブ化インスタンスで同じ行が処理されないようにするには、分散アプローチが必要となります。 |
このベスト・プラクティスを構成する場合は、次の各項を参照してください。
分散シナリオの場合、各ポーリング・インスタンスでは、処理されていないすべての行をそのインスタンス単独で処理しようと試みるのではなく、負荷の分散が試行されます。このことは、1つのインスタンスで一度にフェッチされる行数が、最大でもMaxTransactionSize
の行数のみとなることを意味します。
ロッキングのスキップを使用すると、完全なMaxTransactionSize
行がフェッチされた場合、次のMaxTransactionSize
行をただちに連続してフェッチできます。これは、ロッキングのスキップを使用する場合、同時スレッドは相互にブロックされないので、1つのインスタンスがすべての行をフェッチする危険がないためです。
ただし、ロッキングのスキップを無効にしている場合は、すべてのスレッドが同じ行をロックしようとし、そのうちの1つだけがロックに成功します。その後、そのスレッドがMaxTransactionSize
の行数を処理し終えると、そのスレッドは次のポーリング間隔まで一時停止し、他のスレッドが行のロックと処理を行えるようになります。
したがって、分散ポーリングを有効にし、ロッキングのスキップを無効にしている場合の最大スループットは次のようになります。
NumberOfThreads x MaxTransactionSize/PollingInterval
注意:
|
ロード・バランシングが目的である場合は、ロッキングのスキップを無効化した状態で分散環境の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に設定するのと同じです。追加の作業インスタンスはDbAdapterの外部に作成されるため、これらはいかなる方法でも連携しません。したがって、マルチスレッドの単一ノード・シナリオでは、常にNumberOfThreads
のみを構成してください。分散ポーリングを有効化することによるデータベース・レベルの同時実行性制御がない場合は、重複が読み取られます。
注意: 分散クラスタ・シナリオでは、 |
詳細は、第2.13項「アダプタ内でのシングルトン(アクティブ/パッシブ)インバウンド・エンドポイント・ライフサイクルのサポート」を参照してください。
主キー、および結合表へのすべての外部キーに索引付け(および/またはこれらのキーに対してデータベース上に明示的な制約を追加)します。論理削除ポーリングを使用する場合は、状態列に索引付けします。NULL以外のMarkUnreadValue
およびMarkReadValue
を構成します。
アウトバウンド・データベース・アダプタ上の最適なパフォーマンスのすべての操作(INSERTを除く)において、データベース・アダプタの主キーとして選択されている列のデータベースに索引を作成する必要があります。
索引がなく、かつ索引を作成しないことが適切である場合は、単一ノードのマルチスレッドのアプローチを使用できます(第9.3.8.2項「分散ポーリングのベスト・プラクティス2: 最初に単一ノードをチューニングする」を参照)。この方法では、ポーリング問合せの1度の実行で全表スキャンが行われることがありますが、その場合、複数のスレッドで、すべての行を処理するまで結果セット全体が使用されます。分散アプローチを使用する場合は、行が排他的にロックされている(つまり、時間が指定されたトランザクションでロックされている)間にすべての作業が完了する必要があります。分散シナリオでは、選択が何度も繰り返して実行されるため、選択ごとに全表スキャンが実行されると、パフォーマンスに悪影響を及ぼす場合があります。
注意:
|
Oracle Databaseでは、Oracle 8以降にロッキングのスキップを使用できるようになりましたが、ドキュメント化はOracle 11で行われました。互換性のない機能を無効化することが必要となる状況はほとんど発生しません。このような状況が発生した場合は、例9-3に示すように、アプリケーションでデプロイしたra.xml
ファイルでOracleデータベース・アダプタのコネクタ・プロパティusesSkipLocking
をfalse
に設定できます。
例9-3 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 Fusion Middleware Oracle WebLogic Serverリソース・アダプタのプログラミング』のra.xmlファイルの構成に関する項
『Oracle Fusion Middleware Oracle WebLogic Serverリソース・アダプタのプログラミング』のリソース・アダプタのパッケージ化およびデプロイに関する項
論理削除ポーリングを使用していて、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倍に向上できます。
第9.3.8.1項「分散ポーリングのベスト・プラクティス1: SELECT FOR UPDATE(SKIP LOCKED)」で説明するように、単一ノードでのパフォーマンスを向上させ、必要に応じてクラスタ内の複数のノードに展開することが最適である場合があります。データベースの同時実行性制御機能(ロックなど)への依存性が高くなる可能性がありますが、これらの機能は、通常、パフォーマンスの高いスケーラビリティよりもデータ整合性を保持することを重視して設計されています。
クラスタ内の単一ノード上でポーリングを行うことが最適となるケースとして、煩雑でない順序付けポーリング計画、索引付けされていない大規模な表のポーリング、または同時実行性が高いロック(ロックのスキップなど)が備えられていないOracle以外のバックエンド・データベースを使用するケースなどがあります。
注意: クラスタ環境でポーリング操作を使用するOracleデータベース・アダプタの場合は、アダプタ構成ウィザードで「分散ポーリング」チェック・ボックスを選択して、分散ポーリングのオプションを使用する必要があります。 |
必要であれば、第2.13項「アダプタ内でのシングルトン(アクティブ/パッシブ)インバウンド・エンドポイント・ライフサイクルのサポート」も参照してください。
Oracleデータベース・アダプタは、多くのパフォーマンス最適化で事前構成されています。ただし、パフォーマンス・チューニングを実装することで、変更を加えてデータベースへのラウンドトリップの回数を減らせます。
パフォーマンス・チューニングの詳細は、次の各項を参照してください。
『Oracle Fusion Middlewareパフォーマンスおよびチューニング・ガイド』のOracle JCA Adapter for Databaseのチューニングに関する項
『Oracle Fusion Middlewareパフォーマンスおよびチューニング・ガイド』のインバウンド・データベース・アダプタのチューニングに関する項
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の表現 |
省略と見なされた値は、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ファイルに |
詳細は、次を参照してください。
また、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ファイルに表示されます。
デフォルト値
TopLink
の順序付けがデータベース順序からのinsertに主キーを割り当てるように構成されている場合はtrue
、それ以外の場合はfalse
です。
問題点
データベース順序からのinsert
に主キーを自動割当てできます。ただし、insert
/merge
には出力メッセージがなく、どの主キーが割り当てられたかを指示する手段がないため、この機能の有用性は減少しています。
注意: 順序付け(リンク)の構成後にアダプタ構成ウィザードを再実行してください。これにより、出力メッセージと |
パフォーマンス
output
XML
が提供されるのは、output
XML
が大幅に異なる場合のみです。そのため、TopLink
の順序付けが使用されない場合、この機能は無効化され、パフォーマンス・ヒットはありません。また、この機能は明示的に無効化することも可能です。同様に、オリジナルの入力XML
が更新されて戻され、まったく新しいXML
が作成されることはありません。また、主キーがディテール・レコードに割り当てられている場合は、XML
のシャロー・アップデートのみが実行され、出力XML
には反映されません。
互換性のない相互作用
DirectSQL="true"
および"OutputCompletedXml"
- OutputCompletedXml
が優先されます。
アダプタ構成ウィザードの「詳細オプション」ページでQueryTimeout
を構成できます。この機能により、同じ名前のjava.sql.Statement
レベル・プロパティが公開されます。基本的には、QueryTimeout
を使用するとコール時のタイムアウトを構成できます。
この機能では、起動全体が単一スレッドとグローバル・トランザクションで実行されます。デフォルトでは、開始は非同期で、BPELプロセスは別のグローバル・トランザクションで起動されます。これはOracle BPELプロセスにのみ固有であるため、Oracle Mediatorを使用する場合、これは通常は同期起動です。
この機能を有効化するには、アダプタ構成ウィザードの「操作」ページで「BPELへの同期ポストの実行(順序配信の許可)」オプションをクリックします。
この項には、Oracleデータベース・アダプタの概念に関する次の項目が含まれます。
この項には、リレーショナルからXMLへのマッピングに関する次の項目が含まれます。
フラット表またはスキーマでは、リレーショナルからXMLへのマッピングを簡単に参照できます。表の各行は複合XML要素になります。各列の値はXML要素のテキスト・ノードになります。列値およびテキスト要素のどちらもプリミティブ型です。
表9-4に、MOVIES
表の構造を示します。この表は、この章で説明する使用例で使用されます。詳細は、「Oracleデータベース・アダプタの使用例」を参照してください。
表9-4 MOVIES表の説明
名前 | NULLかどうか | タイプ |
---|---|---|
|
NULL以外 |
|
|
-- |
|
|
-- |
|
|
-- |
|
|
-- |
|
|
-- |
|
|
-- |
|
|
-- |
|
|
-- |
|
|
-- |
|
|
-- |
|
|
-- |
|
|
-- |
|
|
-- |
|
|
-- |
|
対応するXMLスキーマの定義(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:maxLength value="6"/> </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以外 |
|
|
-- |
|
|
-- |
|
|
-- |
|
|
-- |
|
|
-- |
|
|
-- |
|
|
-- |
|
前の表定義が示すように、典型的な正規化されたリレーショナル・スキーマであるため、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
型は明確にサポートされていません。
注意: ユーザー定義の |
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が所有するすべて( 解釈の誤りは、TopLinkの動作に発生します。式ビルダーでは、表1の選択基準しか指定できず、表1が所有する表2は制御されないため、この部分は自動的に実行されます。 ただし、次の2つのアプローチのいずれかを使用すると、予期した結果を取得できます。 1.)選択基準にstatus = 1を使用して表2を直接問い合せます。つまり、表1を通過して表1が所有する表2を取得することはしません。 2.)次の例のように直接(カスタム 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度に戻される情報が多すぎるという共通の問題があります。DBAdapter
receive
では、maxTransactionSize
プロパティを設定して、1度にカーソル付き結果セットから読み取られてメモリー内で処理される行数を制限できます。select
文の1回の起動用に、類似のmax-rows
設定が存在します。ただし、この設定は大きなリスクを伴います。
リレーショナル・スキーマをXMLとしてマッピングした後、基本的なSQL操作もWebサービスとしてマッピングする必要があります。次の項で説明する各操作には、対応するチュートリアルとREADMEファイルがあります。ここで説明されている作業から開始し、この項を読み進めながら実際に1つ以上行ってみることをお薦めします。チュートリアルで説明するように、いくつかの操作では直接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
では、まずデータベースの対応するレコードが読み取られて変更箇所が算出され、最低限の更新が実行されます。INSERT
、UPDATE
およびMERGE
は、単一の行および表が作業対象の場合に最も適切です。ただし、XMLには複合型が含まれ、複数の表の複数の行にマッピングされます。たとえば、DEPT
に多数のEMPS
があり、それらのそれぞれにADDRESS
があるとします。この場合、変更された可能性のある行がどのくらいで、どの行を挿入、更新または削除すればよいかを算出する必要があります。特定の行が変更されなかったか、1つのフィールドのみが変更された場合、DMLコールは最小限になります。
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>
インバウンドの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>
また、アクティブ化自体を構成し、最上位(マスター行)のみの削除、またはすべての削除を実行することもできます。
receive操作はインバウンドJCAでは次のように表示されます。
<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>
この操作は、論理削除ポーリング計画を採用するときに選択します。この計画には、処理された各行の特別なフィールドの更新、および処理済の行を除外するための実行時の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で使用されている接続の名前です。
DBアダプタ・インスタンスを作成するには、第2.18項「アダプタ・コネクション・ファクトリの追加」の説明に従ってOracle WebLogic Server管理コンソールを使用するか、weblogic-ra.xml
ファイルを直接編集します。次の手順に続く各スクリーンショットは、Oracle WebLogic Server管理コンソールによるアダプタ・インスタンスの作成方法を示しています。weblogic-ra.xml
を編集する手順は、次のとおりです。
fmwhome
/でDbAdapter.rar
を検索します。
ファイルを解凍します。
META-INF
/weblogic-ra.xml
(および、場合によってはra.xml
)を編集します。
このファイルから再びJARを作成します。
アプリケーション・サーバーを再起動します。
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コンソールの編集プロパティを示しています。プロパティごとに名前、タイプおよび値が表示されます。
図9-30 Oracle WebLogic Server管理コンソールのデータベース・アダプタのプロパティ
最も一般的なミス
デプロイメントに関する最も一般的なミスとして、次の2つがあります。
db.jca
ファイル内の場所属性に一致するアダプタ・インスタンス・エントリが作成されていません(または、エントリが1つも作成されていません)。
db.jca
ファイル内の場所属性にデータソース名を直接設定しています。
Oracle以外のデータベースに接続する際、platformClassNameを変更していません。
後者の場合は、アダプタ・インスタンス名(eis/DB/...
)を指定し、このインスタンス名がデータソース・プール(jdbc/...
)を指すというように間接的に指定する必要があります。一般的なミスは、このように間接的に指定せず、名前jdbc/...
を場所属性に直接指定することです。
データソースの構成
アプリケーション・サーバーの関連データ・ソース構成については、第9.6項「JDBCドライバとデータベース接続の構成」を参照してください。Oracleデータ・ソースを構成するときは、必ずThin XA
オプションを使用してください。
その他のアダプタ・インスタンス・プロパティ
この項では、xADataSourceName
、dataSourceName
およびplatformClassName
以外のDBアダプタ・インスタンスのプロパティについて簡単に説明します。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データベース・アダプタのインスタンス・プロパティの詳細は、付録Aの「Oracleデータベース・アダプタのプロパティ」を参照してください。そこに述べられているプロパティとは別に、次の表にリストされているプロパティも追加できます。
表9-12 Toplink DatabaseLoginオブジェクトに表示されるOracleデータベース・アダプタのプロパティ
プロパティ名 | タイプ |
---|---|
|
Boolean |
|
Boolean |
|
Boolean |
|
Boolean |
|
Boolean |
|
String |
|
Boolean |
|
Integer |
|
String |
|
Boolean |
|
Boolean |
|
String |
|
Integer |
|
String |
|
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 |
|
その他のデータベース |
|
このリリースでは、Oracle JCAアダプタはOracle WebLogic Serverタイプ4 JDBCドライバを使用する次のサード・パーティ・データベースで動作確認されています。
Microsoft SQL Server 2005および2008 (すべてのSPレベルを含む)
Sybase 15
Informix 11.5
DB2 9.7およびそれ以降のFixPaks
MySQL 5.x以上
注意: 主要なデータベースおよびバージョンのみが動作確認されています。他のデータベースでの作業は、作業用のJDBCドライバが用意されており、コアANSI SQLリレーショナル機能(表やビューに対する作成、読取り、更新および削除(CRUD)の各操作など)に依存している場合、実行可能です。問題の多くは、データベース・メタデータ・イントロスペクションが、必ずしもすべてのJDBCドライバで同じように実装されていないことによって、発生する傾向があります。ただし、動作確認されたデータベース上に一致する表をインポートした後、動作確認されていないデータベースを実行時に参照することができます。動作確認されていないデータベースに関してこの項で説明する情報は、ガイドとしてのみ参照してください。 |
詳細は、次の項目を参照してください。
ネイティブまたはバンドルされたOracle WebLogic Server JDBCドライバを使用している場合にデータベース接続を作成するには、次のようにします。
適切なJDBCドライバJARファイルがインストールされてクラスパスが設定されていることを確認します。
詳細は、次を参照してください。
『Oracle Fusion Middleware Oracle WebLogic Server JDBCデータ・ソースの構成と管理』
『Oracle Fusion Middleware Oracle WebLogic Serverタイプ4 JDBCドライバ』
『Oracle Fusion Middleware Oracle WebLogic Server JDBCのプログラミング』
「ファイル」メニューの「新規」をクリックします。
「新規ギャラリ」ページが表示されます。
「すべてのテクノロジ」タブで、「一般」カテゴリの「接続」を選択します。
「新規ギャラリ」ページの右側にある「項目」ペインに、確立できる様々な接続のリストが表示されます。
「データベース接続」を選択し、「OK」をクリックします。
「データベース接続の作成」ページが表示されます。
「接続の作成場所」で、「IDE接続」を選択します。
「接続名」フィールドにこの接続の名前を入力します。
たとえば、SQLServer
を選択します。
「接続タイプ」メニューから適切なドライバを選択します。
資格証明(必要に応じてユーザー名、パスワードおよびロールなど)を入力します。
接続情報を入力します。
たとえば、jdbc:sqlserver://
HOST-NAME
:
PORT
;databaseName=
DATABASE-NAME
と入力します。
詳細は、次を参照してください。
デプロイメント・ディスクリプタ・ファイル(weblogic-ra.xml
)のサンプルのエントリ。
「接続のテスト」をクリックします。
正常に接続した場合は、「OK」をクリックします。
サード・パーティJDBCドライバを使用している場合にデータベース接続を作成するには、次のようにします。
適切なJDBCドライバJARファイルをインストールしてクラスパスを設定します。
詳しくは、第9.6.4項「JDBCドライバJARファイルの場所とクラスパスの設定」を参照してください。
「ファイル」メニューの「新規」をクリックします。
「新規ギャラリ」ページが表示されます。
「すべてのテクノロジ」タブで、「一般」カテゴリの「接続」を選択します。
「新規ギャラリ」ページの右側にある「項目」ペインに、確立できる様々な接続のリストが表示されます。
「データベース接続」を選択し、「OK」をクリックします。
「データベース接続の作成」ページが表示されます。
「接続の作成場所」で、「IDE接続」を選択します。
「接続名」フィールドにこの接続の名前を入力します。
たとえば、SQLServer
を選択します。
「接続タイプ」から「汎用JDBC」を選択します。
ユーザー名、パスワードおよびロール情報を入力します。
「ドライバ・クラス」で「新規」をクリックします。
「JDBCドライバの登録」ダイアログが表示されます。
「ドライバ・クラス」にドライバ名(some
.jdbc.
Driver
など)を入力します。
たとえば、com.microsoft.sqlserver.jdbc.SQLServerDriver
と入力します。
「ライブラリ」で「参照」をクリックします。
「ライブラリの選択」ダイアログが表示されます。
「新規」をクリックしてライブラリを作成します。
「ライブラリの作成」ダイアログが表示されます。
「ライブラリ名」フィールドに名前を入力します。
たとえば、SQL Server JDBC
と入力します。
「クラスパス」をクリックしてから「エントリの追加」をクリックしてドライバの各JARファイルをクラスパスに追加します。
「パス・エントリの選択」ダイアログが表示されます。
JDBCクラス・ファイルを選択して「選択」をクリックします。
たとえば、「sqljdbc.jar
」を選択します。
すべてのクラス・ファイルを「クラスパス」フィールドに追加した後、「OK」をクリックします。
「OK」をクリックして「ライブラリの作成」ダイアログを終了します。
「OK」をクリックして「ライブラリの選択」ダイアログを終了します。
「OK」をクリックして「JDBCドライバの登録」ダイアログを終了します。
「JDBC URL」に接続文字列名を入力して、「次へ」をクリックします。
たとえば、jdbc:sqlserver://
HOST-NAME
:
PORT
;databaseName=
DATABASE-NAME
と入力します。
詳細は、次を参照してください。
デプロイメント・ディスクリプタ・ファイル(weblogic-ra.xml
)のサンプルのエントリ。
「接続のテスト」をクリックします。
正常に接続した場合は、「OK」をクリックします。
表9-14「(Weblogic Serverコンソールからの)データベース・ドライバの選択」に、一般的なサード・パーティ・データベースに関する接続情報をまとめます。
PlatformClassName
の詳細は、表9-13「データベース・プラットフォーム名」を参照してください。
詳細は、次を参照してください。
表9-14 (Weblogic Serverコンソールからの)データベース・ドライバの選択
データベース | JDBCドライバ |
---|---|
Microsoft SQL Server |
|
Sybase |
|
Informix |
|
IBM DB2 |
|
MySQL |
MySQLのドライバ(タイプ4) バージョン: |
SQL Serverデータベースに接続する際は次の点に注意する必要があります。
ユーザー名およびパスワード
SQL Server 2005では、デフォルトでWindows認証もインストールされます。そのため、ユーザー名とパスワードでログインしません。Windowsのユーザー・アカウントに権限があるかないかのどちらかです。JDBCではユーザー名とパスワードの入力が必要です。
接続文字列
次の例に示すように、sqlcmd
ログインから接続文字列を推測できます。
例1:
sqlcmd 1> jdbc:microsoft:sqlserver://localhost:1433
例2:
sqlcmd -S user.example.com\SQLExpress 1> jdbc:microsoft:sqlserver://user.example.com\SQLExpress:1433
例3:
sqlcmd -S user.example.com\SQLExpress -d master 1> jdbc:microsoft:sqlserver://user.example.com\SQLExpress:1433;databasename= master
完全なURLは次のとおりです。
jdbc:microsoft:sqlserver://serverName[\instanceName]:tcpPort[;SelectMethod=cursor][;databasename=databaseName]
データベース名
データベース名を明示的に指定する必要があり、それがわからない場合は、次の場所に移動します。
C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Data
master.mdf
という名前のファイルがあった場合、データベース名の1つはmaster
です。
TCPポート
SQL Server Browserが実行されていて、SQL ServerサービスがTCP/IPに対応しており、静的ポート1433でリスニングしていることを確認します。動的ポートを無効にします。SQLネイティブ・クライアントの構成/クライアント・プロトコルでは、TCP/IP対応でデフォルト・ポートが1433であることを確認します。
JDBCドライバ
JDBCドライバを個別にダウンロードする必要があります。www.microsoft.com
から、「Downloads」をクリックし、jdbcを検索します。DataDirectドライバの使用を試すこともできます。
この項には、次の項目が含まれます。
URL: jdbc:sybase:Tds:
SERVER-NAME
:
PORT
/
DATABASE-NAME
ドライバ・クラス: com.sybase.jdbc.SybDriver
ドライバJar: jConnect-6_0\classes\jconn3.jar
Sybase JConnect JDBCドライバの詳細は、次のリンクを参照してください。
この項には、次の項目が含まれます。
URL: jdbc:informix-sqli://
HOST-NAME-OR-IP
:
PORT-OR-SERVICE-NAME
/
DATABASE-NAME
:INFORMIXSERVER=
SERVER-NAME
ドライバ・クラス: com.informix.jdbc.IfxDriver
ドライバJar: ifxjdbc.jar
Informix JDBCドライバの詳細は、次のリンクを参照してください。
この項には、次の項目が含まれます。
URL: jdbc:db2:localhost:NAME
ドライバ・クラス: com.ibm.db2.jcc.DB2Driver
ドライバJar(v8.1): db2jcc.jar
、db2jcc_javax.jar
、db2jcc_license_cu.jar
DataDirectドライバについては、次のリンクを参照してください。
URL: jdbc:as400://
hostname;
translate binary=true
ドライバ・クラス: com.ibm.as400.access.AS400JDBCDriver
ドライバJar: jt400.jar
キャラクタ・セットを適切に変換するには、translate binary=true
を使用します。
URL: jdbc:db2://
hostname:port
/schemaname
ドライバ・クラス: com.ibm.db2.jcc.DB2Driver
ドライバJar: db2jcc.jar
, db2jcc4.jar
and db2java.zip
次の情報を使用します。
URL: jdbc:mysql://
hostname
:3306
/dbname
ドライバ・クラス: com.mysql.jdbc.Driver
ドライバJar: mysql-connector-java-3.1.10-bin.jar
この項では、JDBC JARファイルの場所と、実行時および設計時のクラスパスの設定について説明します。
実行時
WindowsとLinuxの場合は、どちらも次の手順を実行する必要があります。
ベンダー固有のドライバJARファイルをuser_projects/domains/soainfra/lib
ディレクトリに移動します。
ベンダー固有のドライバJARファイルを<Weblogic_Home>/server/lib
に移動します。
クラスパスを編集し、ベンダー固有のjarファイルを<Weblogic_HOME>/common/bin/commEnv.sh
に含めます。
設計時
WindowsとLinuxの場合は、どちらもJDBC JARをOracle/Middleware/jdeveloper/jdev/lib/patches
ディレクトリに移動します。
この項では、Oracleデータベース・アダプタで、ストアド・プロシージャとファンクションの使用がどのようにサポートされているかについて説明します。
この項には、次の項目が含まれます。
「アダプタ構成ウィザード - ストアド・プロシージャ」は、アダプタ・サービスWSDLおよび必要なXSDの生成に使用されます。アダプタ・サービスWSDLは、基礎となるストアド・プロシージャまたはファンクションをWSIF JCAバインディングのあるWebサービスとしてカプセル化します。XSDファイルには、すべてのパラメータおよびそのタイプを含む、プロシージャまたはファンクションが記述されています。このXSDには、実行時にOracleデータベース・アダプタに発行されるインスタンスXMLの作成に使用される定義が指定されています。
この項には、次の項目が含まれます。
この項では、PL/SQLパッケージに定義されていないAPIを持つアダプタ構成ウィザードの使用方法を説明します。「アダプタ構成ウィザード - ストアド・プロシージャ」を使用し、プロシージャまたはファンクションを選択してXSDファイルを生成します。アダプタ構成ウィザードの起動方法については、第9.8項「Oracle Databaseの使用例」を参照してください。
アダプタ構成ウィザードを使用してストアド・プロシージャまたはファンクションを選択するには、次の手順を実行します。
「サービス・アダプタ」リストから「データベース・アダプタ」を「composite.xml」ページの「公開されたサービス」スイムレーンにドラッグ・アンド・ドロップします。
図9-31に示すように、アダプタ構成ウィザードが表示されます。
「次へ」をクリックします。図9-32に示すように、「サービス名」ページが表示されます。
注意: データベースまたはユーザー定義データ型を参照するストアド・プロシージャまたはパッケージの名前には、文字$を使用できないことに注意してください。名前に$が含まれていると、XSDファイルの生成に失敗します。 |
「サービス名」フィールドにサービス名を入力し、「次へ」をクリックします。「サービス接続」ページが表示されます。
図9-33に示すように、接続をサービスに関連付けます。アダプタ・サービスを構成するにはデータベース接続が必要です。リストから既存の接続を選択するか、新規の接続を作成してください。
「次へ」をクリックします。「操作タイプ」ページが表示されます。
図9-34に示すように、「操作タイプ」に「ストアド・プロシージャまたはファンクションの呼出し」を選択します。
「次へ」をクリックします。図9-35に示すように、「ストアド・プロシージャの指定」ページが表示されます。このページで、ストアド・プロシージャまたはファンクションを指定します。
次に、スキーマと、プロシージャまたはファンクションを選択します。リストからスキーマを選択するか、「<デフォルト・スキーマ>」を選択します。この場合、接続に関連付けられているスキーマが使用されます。プロシージャ名がわかっている場合は、「プロシージャ」フィールドに入力します。プロシージャがパッケージ内に定義されている場合は、EMPLOYEE.GET_NAME
のようにパッケージ名を含める必要があります。
スキーマ名およびプロシージャ名が不明である場合は、「参照」をクリックして、図9-36に示すように、「ストアド・プロシージャ」ウィンドウにアクセスします。
リストからスキーマを選択するか、「<デフォルト・スキーマ>」を選択します。使用可能なプロシージャのリストが左側のウィンドウに表示されます。APIの長いリストから特定のAPIを検索するには、「検索」フィールドに検索基準を入力します。たとえば、XX
で始まるすべてのAPIを検索するには、XX%
と入力し「検索」ボタンをクリックします。「すべて表示」ボタンをクリックすると、使用可能なすべてのAPIが表示されます。
図9-37に、FACTORIALファンクションの選択方法を示します。「引数」タブには、ファンクションのパラメータが表示されます。表示されるパラメータは、名前、型、モード(IN
、IN/OUT
またはOUT
)およびプロシージャの定義におけるパラメータの数値位置です。ファンクションの戻り値は、名前がなく、常に位置がゼロ(0)のOUT
パラメータです。
図9-38に、ファンクションを実装するコードが「ソース」タブでどのように表示されるかを示します。ファンクション名に一致するテキストが強調表示されています。
ストアド・プロシージャまたはファンクションを選択して、「OK」をクリックします。図9-39に示すように、APIに関する情報が表示されます。修正するには、「戻る」または「参照」をクリックします。
「次へ」をクリックします。ストアド・プロシージャまたはファンクションに、行セット・タイプの出力パラメータ(Oracle DatabaseではREF CURSOR
)が含まれる場合、図9-40に示すように、このREF CURSORに対して強い型指定のXSDまたは弱い型指定のXSDを定義できます。
図9-40 アダプタ構成ウィザードにおけるプロシージャまたはファンクションの詳細の表示: 行セット・タイプの場合
詳細は、次を参照してください。
「次へ」をクリックします。図9-41に示すように、「詳細オプション」ページが表示されます。JDBCの「問合せタイムアウト」
の値など、任意の詳細オプションを入力します。その他のオプションとしては、再試行回数や再試行間隔などの再試行パラメータがあります。
すべてのオプションを指定した後、「次へ」をクリックし、「終了」をクリックしてアダプタ構成ウィザードを終了します。
アダプタ構成ウィザードの使用が終了すると、次の3つのファイルが既存のプロジェクトに追加されます。
servicename
.wsdl
(Factorial.wsdl
など)
service_name_db
.jca
(Factorial_db.jca
など)
schema_package_procedurename
.xsd
(SCOTT_FACTORIAL.xsd
など)
パッケージで定義されたAPIの使用は、スタンドアロンAPIの使用と似ています。唯一の違いは、図9-42に示すように、パッケージ名を開いて、パッケージに定義されているすべてのAPIのリストを参照できることです。
同じ名前でパラメータが異なるAPIは、オーバーロードされたAPIと呼ばれます。図9-42に示すように、PACKAGEというパッケージには、OVERLOADというオーバーロードされたプロシージャが2つあります。
図9-43に示すように、「ソース」タブを参照する際にはパッケージのどのAPIが選択されているかにかかわらず、PL/SQLパッケージ全体のコードが表示されます。プロシージャ名に一致するテキストが強調表示されています。
プロシージャまたはファンクションを選択して「OK」をクリックすると、図9-44に示すように、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アダプタのサポートの詳細は、第9.6項「JDBCドライバとデータベース接続の構成」を参照してください。
この項には、次の項目が含まれます。
ProductName
これはデータベースの名前です。
データベース名 | サポート対象データベース |
---|---|
IBM DB2 |
IBM DB2 v 9.x |
Microsoft SQL Server |
SQLServer 2000または2005 |
MySQL |
MySQL v5.6 |
DriverClassName
これはJDBCドライバ・クラスの名前です。
データベース名 | JDBCドライバ |
---|---|
IBM DB2 |
|
Microsoft SQL Server |
|
MySQL |
|
ConnectionString
これはJDBC接続URLです。
データベース名 | 接続文字列 |
---|---|
IBM DB2 |
|
Microsoft SQL Server |
|
MySQL |
|
ユーザー名
データベース・ユーザー名です。
パスワード
ユーザー名に関連付けられているパスワードです。
ProcedureName
ストアド・プロシージャ名またはファンクション名です。
ServiceName
必要な操作のサービス名です。
DatabaseConnection
接続のJNDI名です。たとえば、eis/DB/<DatabaseConnection>
です。
宛先
これは、生成されるファイルの接続先ディレクトリです。たとえば、C:\Temp
などです。
パラメータ
ストアド・プロシージャのパラメータです(バージョン5.2.6より前のMySQLのみ)。
QueryTimeout
JDBC問合せタイムアウト値(秒単位)です。QueryTimeout
プロパティは、JDBCドライバが、指定されたストアド・プロシージャまたはファンクションの実行を待機する最大秒数を指定します。しきい値に達すると、SQLException
がスローされます。値が0の場合は、ドライバは無期限で待機します。
アダプタ構成ウィザードでは、Oracle Database、IBM DB2、AS/400、Microsoft SQL ServerおよびMySQL v5.2.6以上がサポートされます。
この項には、次の項目が含まれます。
表9-15に、SQL Serverのストアド・プロシージャおよびファンクションでサポートされるデータ型を示します。
表9-15 SQL Serverのストアド・プロシージャおよびファンクションのデータ型
SQLデータ型 | XMLスキーマ型 |
---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
前述の表に示したデータ型の他に、別名データ型もサポートされています。別名データ型は、sp_addtype
データベース・エンジン・ストアド・プロシージャまたはCREATE TYPE
Transact-SQL文(SQL Server 2005の場合のみ)を使用して作成されます。Transact-SQL文の使用は、別名データ型の推奨作成方法です。sp_addtype
の使用は推奨されていません。
表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-45に示すように、「ストアド・プロシージャ」ダイアログでストアド・プロシージャを選択します。引数は「引数」タブに表示されます。指定のデータベース内でユーザーが作成したデータベース・ストアド・プロシージャを検索するには、「検索」をクリックします。たとえば、d%とD%のどちらによってもDEMO
ストアド・プロシージャが検索されます。「すべて表示」をクリックすると、指定のデータベース内で現在のユーザーが作成したすべてのストアド・プロシージャが表示されます。
図9-46に示すように、「ソース」タブをクリックすると、ストアド・プロシージャのソース・コードを表示できます。
表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
スキーマのカタログ表はサポートされていません。
アダプタ構成ウィザードでは、INFORMATION_SCHEMA
スキーマのカタログ表を使用して、MySQL v5.6以降のストアド・プロシージャにアクセスできます。v5.6より前のバージョンのMySQLには、INFORMATION_SCHEMA
スキーマ内にPARAMETERS
表がありません。
PARAMETERS
表がない場合、MySQLデータベースでは、ストアド・プロシージャのパラメータに関する情報は提供されません。したがって、プロパティ・ファイル内で必須プロパティを使用して、この情報を提供する必要があります。Parameters
プロパティには、ストアド・プロシージャのシグネチャが含まれています。
プロパティ | 説明 |
---|---|
|
APIがファンクションであるかプロシージャであるかを指定します。 |
|
APIが定義されているデータベースの名前です。 |
|
ストアド・プロシージャのパラメータです。 |
Parameters
プロパティの値はカンマ区切りのパラメータ・リストで、それぞれの構文は次のとおりです。
Parameter ::= {IN | INOUT | OUT} Parameter_Name SQL_Datatype
パラメータ定義の3つの要素がすべて必須です。
次のMySQLストアド・プロシージャを例にします。
CREATE PROCEDURE demo (IN x VARCHAR (10), INOUT y INT, OUT z CHAR (20)) BEGIN ... END
Parametersプロパティは、次の例に示すように指定する必要があります。
Parameters=IN x VARCHAR (10), INOUT y INT, OUT z CHAR (20)
パラメータのプロパティにパラメータを正しく指定しないかぎり、ストアド・プロシージャの生成XSDは無効です。MySQLのプロパティ・ファイルのサンプルを次に示します。
ProductName=MySQL DriverClassName=com.mysql.jdbc.Driver ConnectionString=jdbc:mysql://<host>:<port>/<database> Username=<username> Password=<password> SchemaName=<database> ProcedureName=demo Parameters=IN x VARCHAR(10),INOUT y INT,OUT z TEXT(20) ServiceName=MySQLDemoService DatabaseConnection=mysql
注意: MySQLの場合、 |
表9-18に、MySQLのストアド・プロシージャでサポートされるデータ型を示します。
表9-18 MySQLのストアド・プロシージャのデータ型
SQLデータ型 | XMLスキーマ型 |
---|---|
|
|
|
boolean |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
STRING
に対応するSQLデータ型の文字の長さは、VARCHAR (20)
のように、Parameters
プロパティで(#)表記法を使用して指定できます。他のSQLデータ型の場合、長さの指定は無効です。
UNSIGNED
整数データ型は、アダプタ構成ウィザードを使用している場合にはSIGNED
整数データ型として扱われます。
MySQLのストアド・プロシージャは、JDBC接続URLに<database>として指定されたデータベースによってグループ化されます。MySQLの場合、「<デフォルト・スキーマ>」はユーザーの接続先データベース(通常はJDBC接続URLで指定)を指します。別のデータベースを選択するには、「<デフォルト・スキーマ>」をクリックします。JDBC接続URLに指定されたデータベースの現在のデータベース内の特定のストアド・プロシージャを検索するには、「検索」をクリックします。たとえば、d%またはD%と入力した場合は、dまたはDで始まるストアド・プロシージャが検索されます。「すべて表示」を選択すると、現在のデータベース内のすべてのストアド・プロシージャが表示されます。
アダプタ構成ウィザードを機能させるために必要なカタログ表にアクセスするには、JDeveloperでデータベース接続を作成する必要があります。
JDeveloperを使用してデータベース接続を作成する手順は、次のとおりです。
「表示」から「データベース・ナビゲータ」を選択します。
アプリケーション名を右クリックして「新規」と「接続」を順番にクリックします。「データベース接続」を選択します。
図9-47に示すように、「データベース接続の作成」ページが表示されます。
「接続名」フィールドに接続名を入力します。たとえば、sqlserver
と入力します。
「接続タイプ」リストから、「接続タイプ」として「汎用JDBC」を選択します。
「ユーザー名」、「パスワード」およびロール情報を入力します。
「ドライバ・クラス」で「新規」をクリックします。図9-48に示すように、「JDBCドライバの登録」ダイアログが表示されます。
ドライバ・クラスを入力します(たとえば、com.microsoft.sqlserver.jdbc.SQLServerDriver
)。
次の手順に従って、ライブラリを作成するか、既存のライブラリを編集します。
「JDBCドライバの登録」ダイアログで「参照」をクリックします。
「ライブラリの選択」ダイアログで「新規」をクリックします。
図9-49に示すように、「ライブラリの選択」ダイアログが表示されます。
既存のライブラリを選択するか、「新規」をクリックしてライブラリを作成します。
「ライブラリの作成」ダイアログが表示されます。
ライブラリ名を入力します。たとえば、SQL Server JDBC
と入力します。
「エントリの追加」をクリックして、JDBC JARファイルをクラスパスに追加します。
「OK」を2回クリックして「ライブラリの作成」ウィンドウを終了します。
「OK」をクリックして「JDBCドライバの登録」ウィンドウを終了します。
「JDBC URL」に接続文字列名を入力します。
「接続のテスト」をクリックします。
接続が成功すると、図9-50に示す画面が表示されます。
「OK」をクリックし、「終了」をクリックします。
「アダプタ構成ウィザード - ストアド・プロシージャ」では、ストアド・プロシージャまたはファンクションのシグネチャを説明するWSDLファイルおよび有効なXSDファイルを作成できます。次の項では、WSDLファイルとXSDファイル両方の関連する構造およびコンテンツと、それぞれのリレーションシップを説明します。
この項には、次の項目が含まれます。
後続の段落では、前述の例で引用された操作名Factorial
およびプロシージャ名Factorial
を使用します(図9-39を参照)。生成された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を通常モードで起動すると、管理対象外の接続の詳細は |
多くのプリミティブ・データ型には、詳細に定義されたマッピングが用意されているため、設計時および実行時のコンポーネントのどちらでもサポートされています。また、VARRAY
、ネストされた表およびOBJECT
などのユーザー定義タイプを使用できます。
表9-19に、Oracleのストアド・プロシージャおよびファンクションでサポートされるデータ型を示します。
表9-19 Oracleのストアド・プロシージャおよびファンクションのデータ型
SQLまたはPL/SQLタイプ | XMLスキーマ型 |
---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
表9-20に、生成されたXSDで使用される属性をリスト表示します。
表9-20 生成された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ファイルをプルーニングすると、アダプタの実行時パフォーマンスが向上し、メモリー使用量も大幅に削減できます。
注意: プルーニングできるのは、ユーザー定義オブジェクト・タイプの属性のみです。対応する要素を |
この項では、ストアド・プロシージャのサポートに関する重要事項と、ストアド・プロシージャまたはファンクションの起動前に発生する動作に関する重要事項の概要を説明します。
この項には、次の項目が含まれます。
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-21にまとめます。
表9-21 サード・パーティ・データベース: バイナリ値および日付値とストアド・プロシージャのパラメータとのバインディング
XMLスキーマ型 | IBM DB2のデータ型 | AS/400のデータ型 | Microsoft SQL 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-51に示す「ストアド・プロシージャの指定」ページが表示されます。前述のチェック・ボックスはページの下部にあります。このチェック・ボックスを選択して、プロシージャにRETURN
文を含めることを指定します。RETURN
文が存在するかどうかを確認するには、プロシージャのソース・コードを表示します。
このチェック・ボックスは、この機能をサポートするデータベースのストアド・プロシージャに対してのみ表示されます。ファンクションに対しては、このチェック・ボックスは表示されません。ストアド・プロシージャによって戻された値は、生成されたXSDのOutputParameters
ルート要素内の要素として表示されます。要素の名前は、ストアド・プロシージャの名前になります。このチェック・ボックスを選択しない場合は、return
文の値がストアド・プロシージャの実行後に消失します。
この項では、Oracleデータベース・アダプタで提供されているストアド・プロシージャ機能を使用して、直接にはサポートされていないタイプのシナリオについて説明します。次の各項では、これらのデータ型を使用する必要がある場合に取り組む解決策を説明します。
REF CURSOR
はどのような結果セットもサポートできるため、設計時に生成されるXSDは弱い型指定となります。
ただし、ここからのXML出力を使用するのは困難です。弱い型指定のXSDに基づき、要素名ではなく列名を属性値としてXpath式またはXSLを作成することは非常に困難です。
行セットはすべての結果セットを表現できますが、一部のプロシージャについては、結果セットの構造が毎回同じであることが想定できるため、強い型指定のXSDを使用して記述することも可能です。一般的に、後で結果セットを別のXSDに変換する場合は、強い型指定のXSDが必要となります。アダプタ構成ウィザードを使用して、REF CURSOR
に対して強い型指定のXSDを生成できます。
使用例において、弱い型指定のXSDで十分である場合は、第9.7.7.2項「弱い型指定のXSDを使用した行セットのサポート」を参照してください。
この項には、次の項目が含まれます。
詳細は、第9.3.3項「強い型指定のXSDまたは弱い型指定のXSDを使用した行セットのサポート」を参照してください。
選択したストアド・プロシージャまたはファンクションに、タイプがRowSet
の出力パラメータが含まれる場合、このREF CURSORに対して強い型指定のXSDを次のように定義できます。
アダプタ構成ウィザードを使用して、タイプがRowSet
の出力パラメータを含むストアド・プロシージャまたはファンクションを選択します。
第9.7.1.1項「最上位のスタンドアロンAPIの使用」のステップ1から8を参照してください。
「次へ」をクリックします。図9-52に示すように、「RowSets」ページが表示されます。
デフォルトで、アダプタ構成ウィザードでは、「XSD」テキスト・フィールドに表示されるこのREF CURSORのための、弱い型指定のXSDが生成されます。図9-4は、このデフォルトの弱い型指定のXSDを示しています。
例9-4 デフォルトの弱い型指定の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が表示されます。例9-5に、例9-4に示すデフォルトの弱い型指定のXSDを置換する、強い型指定のXSDを示します。
例9-5 強い型指定の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-54に示すように、「イントロスペクトに失敗しました」ダイアログが表示されます。
アダプタ構成ウィザードでは、弱い型指定のXSDが生成され、デフォルトで「XSD」テキスト・フィールドに表示され、前のバージョンのXSDに対して行ったすべての編集が上書きされます。
ステップ3に戻り、少なくとも1行を含む行セットを返すテスト引数値を入力します。
ストアド・プロシージャまたはファンクションによって例外がスローされると、図9-55に示すように、イントロスペクション・エラー・ダイアログが表示されます。
アダプタ構成ウィザードでは、弱い型指定のXSDが生成され、デフォルトで「XSD」テキスト・フィールドに表示され、前のバージョンのXSDに対して行ったすべての編集が上書きされます。
ステップ3に戻り、少なくとも1行を含む行セットを返すテスト引数値を入力します。
必要に応じて、「XSD」テキスト・フィールドに表示されるスキーマを手動で編集することによって、強い型指定のXSDを微調整します。
第9.7.1.1項「最上位のスタンドアロン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-56に、強い型指定のXSDを使用したREF CURSORペイロードを返すinvokeの監査証跡を示します。
REF CURSOR
はどのような結果セットもサポートできるため、設計時に生成されるXSDは弱い型指定となります。デフォルトでは、アダプタ構成ウィザードによってREF CURSOR
に対して弱い型指定のXSDが生成されます。
ただし、ここからのXML出力を使用するのは困難です。弱い型指定のXSDに基づき、要素名ではなく列名を属性値としてXpath式またはXSLを作成することは非常に困難です。
行セットはすべての結果セットを表現できますが、一部のプロシージャについては、結果セットの構造が毎回同じであることが想定できるため、強い型指定のXSDを使用して記述することも可能です。一般的に、後で結果セットを別のXSDに変換する場合は、強い型指定のXSDが必要となります。
使用例において、強い型指定のXSDがより適している場合は、第9.7.7.1項「強い型指定のXSDを使用した行セットのサポート」を参照してください。
この項には、次の項目が含まれます。
詳細は、第9.3.3項「強い型指定のXSDまたは弱い型指定のXSDを使用した行セットのサポート」を参照してください。
選択したストアド・プロシージャまたはファンクションに、タイプがResultSet
である出力パラメータが含まれている場合は、このREF CURSORのための弱い型指定のXSDを次のように定義できます。
アダプタ構成ウィザードを使用して、タイプがResultSet
の出力パラメータを含むストアド・プロシージャまたはファンクションを選択します。
第9.7.1.1項「最上位のスタンドアロンAPIの使用」のステップ1から8を参照してください。
「次へ」をクリックします。図9-57に示すように、「RowSets」ページが表示されます。
デフォルトで、アダプタ構成ウィザードでは、「XSD」テキスト・フィールドに表示されるこのREF CURSORのための、弱い型指定のXSDが生成されます。
必要に応じて、「XSD」テキスト・フィールドに表示されるスキーマを手動で編集することによって、弱い型指定のXSDを微調整します。
第9.7.1.1項「最上位のスタンドアロン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;
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-58に、PKG
パッケージのPROC
プロシージャが選択されると表示されるアダプタ構成ウィザードでの手順を示します。
図9-58に示すように、元のプロシージャ名は完全修飾され、PKG.PLSQL
となっています。パラメータ・タイプR
はRECORD
の名前です。タイプT
はTABLE
の名前です。タイプB
はBoolean
です。生成されているラッパー・パッケージの名前は、サービス名bpel_
ServiceName
(bpel_UseJPub
など)から導出されます。これは、生成されたパッケージの名前で、ラッパー・プロシージャが含まれています。チェック・ボックスは、スキーマ・オブジェクトの作成時に、アダプタ構成ウィザードで既存のパッケージの上書きを強制する際に使用できます。
図9-59に示すように、「次へ」をクリックすると、アダプタ構成ウィザードの「終了」ページが表示されます。
このページのコンテンツでは、アダプタ構成ウィザードで検出されたものと、「終了」ボタンがクリックされると実行される処理が説明されます。次に、このページのコンテンツをまとめます。
生成された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データベース・アダプタを再作成するときには、 |
次に示すユーザー定義タイプは、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$
は、ルートレベルのプロシージャに使用されます。
生成されたラッパー・パッケージの名前は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-22には、そのサンプル・コード・サイトのデータベース・アダプタの例をまとめています。
表9-22 サンプル・ページ・サイトのアダプタの例
サンプル | 説明 |
---|---|
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-23に、Oracle BPEL PMおよびメディエータで提供されているOracleデータベース・アダプタのストアド・プロシージャのサンプルを示します。
表9-23 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アプリケーションを作成する必要があります。使用例のアプリケーションとプロジェクトを作成する手順は、次のとおりです。
JDeveloperの「アプリケーション・ナビゲータ」で、「新規アプリケーション」をクリックします。
「汎用アプリケーションの作成 - アプリケーションの名前付け」ページが表示されます。
「アプリケーション名」フィールドにMyHelloApp
と入力して「次へ」をクリックします。
「汎用アプリケーションの作成 - プロジェクトの名前付け」ページが表示されます。
「プロジェクト名」フィールドにHelloProject
と入力します。
「プロジェクト・テクノロジ」タブの「選択可能」リストで「SOA」をダブルクリックし、「選択済」リストに移動します。
「次へ」をクリックします。
「汎用アプリケーションの作成 - SOA設定の設定」ページが表示されます。
「コンポジット・テンプレート」ボックスで「BPELを使用するコンポジット」を選択して「終了」をクリックします。「BPELプロセスの作成」ページが表示されます。
「名前」フィールドにGreet
と入力し、「テンプレート」ボックスから「同期BPELプロセス」を選択します。
「OK」をクリックします。
図9-60に示すように、MyHelloAppのHelloProject内のGreet BPELプロセスが設計領域に表示されます。
次の手順に従ってアウトバウンドOracleデータベース・アダプタ・サービスを作成します。
「コンポーネント・パレット」から、「データベース・アダプタ」を「外部参照」スイムレーンにドラッグ・アンド・ドロップします。
アダプタ構成ウィザードの「ようこそ」ページが表示されます。
「次へ」をクリックします。
「サービス名」ページが表示されます。
「サービス名」フィールドにHello
と入力します。
「次へ」をクリックします。
「サービス接続」ページが表示されます。
注意: このアプリケーションをデプロイする前に、 詳細は、第2.18.1項「データソースの作成」および第2.20項「Oracle JCAアダプタで使用するデータソースの推奨設定」を参照してください。 |
「新規データベース接続を作成します。」アイコンをクリックします。
「データベース接続の作成」ダイアログが表示されます。
「データベース接続の作成」ダイアログで次の詳細を入力します。
「接続名」フィールドに接続名を入力します。たとえば、Myconnection
と入力します。
接続タイプとして「Oracle (JDBC)」を選択します。
ユーザー名およびパスワードとしてscott
/tiger
と入力します。
「ホスト名」フィールドにホスト名を入力し、「JDBCポート」フィールドにJDBCポートを入力します。
「SID」を選択してSID名を入力します。または、「サービス名」を選択してサービス名を入力します。
「接続のテスト」をクリックします。「ステータス」ペインに成功メッセージが表示されます。
「OK」をクリックします。
「接続」フィールドにMyConnection接続が移入され、「JNDI」フィールドにeis/DB/MyConnectionが移入されます。
「次へ」をクリックします。
「操作タイプ」ページが表示されます。
「ストアド・プロシージャまたはファンクションの呼出し」を選択して、「次へ」をクリックします。
「ストアド・プロシージャの指定」ページが表示されます。
「参照」をクリックします。「ストアド・プロシージャ」ペインでHELLO
を選択します。
「引数」タブにストアド・プロシージャのパラメータが表示され、「ソース」タブにストアド・プロシージャのソース・コードが表示されます。
「OK」をクリックします。
「ストアド・プロシージャの指定」ページが表示されます。「プロシージャ」フィールドにHELLOストアド・プロシージャが移入され、HELLOストアド・プロシージャの引数も表示されます。
「次へ」をクリックします。
「詳細オプション」ページが表示されます。
任意の追加の詳細オプションを指定して、「次へ」をクリックします。
アダプタ構成ウィザードの「終了」ページが表示されます。
「終了」をクリックします。
「パートナ・リンクの作成」ダイアログ・ボックスが表示されます。パートナ・リンク名は、サービス名と同じHelloです。
「OK」をクリックします。
アウトバウンドOracleデータベース・アダプタが構成され、Greet BPELプロセスが表示されます。
次の手順に従ってinvokeアクティビティを追加します。
「コンポーネント・パレット」から、invokeアクティビティを設計領域のreceiveInput
アクティビティとreplyOutput
アクティビティの間にドラッグ・アンド・ドロップします。
invokeアクティビティをダブルクリックします。
「Invokeの編集」ダイアログが表示されます。
「名前」
フィールドにInputと入力します。
「Invoke」ボックスで、「入力変数」フィールドの右にある「入力変数の自動作成」アイコンをクリックします。
「変数の作成」ダイアログが表示されます。
デフォルトの変数名を選択して「OK」をクリックします。
「入力変数」フィールドにデフォルトの変数名が移入されます。「Invoke」ダイアログが表示されます。
同じ手順を繰り返して、「出力変数」フィールドで出力変数を選択します。
「Invokeの編集」ダイアログの「変数」セクションに、入力変数名と出力変数名が表示されます。
「OK」をクリックします。
図9-61に示すように、Helloパートナ・リンクに接続された右矢印付きの線が表示されます。
リクエストのペイロードがInputParametersと一致する場合、すべてのINパラメータがリクエストに含まれます。この例では、INパラメータはnameのみです。
次の手順に従って、GreetRequestMessage
メッセージのメッセージ・パートを変更します。
Greet BPELプロセスの「構造」ペイン(「アプリケーション」ペインの下)で、「メッセージ・タイプ」、「プロセスWSDL - Greet.wsdl」および「GreetRequestMessage」を順番に開きます。
「payload」を選択して「編集」アイコンをクリックします。
「メッセージ・パートの編集 - payload」ダイアログが表示されます。
「要素」を選択して「検索」アイコンをクリックします。
「タイプ・チューザ」ダイアログが表示されます。
「プロジェクトのスキーマ・ファイル」と「SCOTT_HELLO.xsd」を順番に開き、「InputParameters」を選択します。
「OK」をクリックします。
「メッセージ・パートの編集 - payload」ダイアログが表示されます。
「OK」をクリックします。
レスポンスのペイロードがOutputParametersと一致する場合、すべてのOUTパラメータがレスポンスに含まれます。この例では、OUTパラメータはgreetingのみです。
GreetResponseMessage
メッセージ・パートに関する手順はGreetRequestMessageの場合と同じですが、次の例外があります。
「GreetResponseMessage」メッセージ・タイプを開き、「payload」を選択します。
「タイプ・チューザ」ダイアログで「SCOTT_HELLO.xsd」を開き、「OutputParameters」を選択します。
「OutputParameters」を選択します。
次の手順に従って入力変数のassignアクティビティを追加します。
「コンポーネント・パレット」から、assignアクティビティを設計領域のreceiveInputおよびGreetというinvokeアクティビティの間にドラッグ・アンド・ドロップします。
assignアクティビティをダブルクリックします。
「Assign」ダイアログが表示されます。
「一般」をクリックし、「名前」フィールドで名前をNAME
に変更します。
「コピー操作」タブでプラス・アイコンをクリックし、表示された操作リストから「コピー操作」を選択します。
「コピー操作の作成」ダイアログが表示されます。
「From」領域で、「変数」、「inputVariable」および「payload」を順番に開いて「ns2:InputParameters」を選択します。
「To」領域で、「変数」、「Input_Hello_InputVariable」および「InputParameters」を順番に開いて「ns2:InputParameters」を選択します。
「OK」をクリックします。
入力パラメータへの値の割当てを完了しました。
図9-62に示すように、「Assign」ダイアログが表示されます。このダイアログには、inputVariableのペイロードからInput_Hello_InputVariableのペイロードへの割当てが表示されます。
「ファイル」、「すべて保存」を順番にクリックします。
2つ目のassignアクティビティでは、出力パラメータに値を割り当てます。
出力パラメータに値を割り当てる手順は、入力パラメータに値を割り当てる場合と同じですが、次の例外があります。
「コンポーネント・パレット」から、assignアクティビティを設計領域のGreet invokeアクティビティとreplyOutputアクティビティの間にドラッグ・アンド・ドロップします。
assignアクティビティをダブルクリックします。
「Assign」ダイアログが表示されます。
「名前」フィールドにGreeting
と入力します。
「コピー操作」タブでプラス・アイコンをクリックし、表示された操作リストから「コピー操作」を選択します。
「コピー操作の作成」ダイアログが表示されます。
図9-63に示すように、「From」ペインで「Input_Hello_OutputVariable」および「OutputParameters」を順番に開いて「ns2:OutputParameters」を選択します。
図9-63に示すように、「To」ペインで「outputVariable」および「payload」を順番に開いて「ns2:OutputParameters」を選択します。
「OK」をクリックします。
出力パラメータへの値の割当てを完了しました。
「ファイル」、「すべて保存」を順番にクリックします。
BPELプロセスのモデル化を完了しました。図9-64に示すように、最終的なBPELプロセスが表示されます。
前述の手順で作成したSOAプロジェクトおよびアプリケーションについて、アプリケーション・プロファイルをデプロイする必要があります。JDeveloperを使用してアプリケーション・プロファイルをデプロイするには、次の手順に従います。
第2章の「Oracle JCAアダプタ用のアプリケーション・サーバー接続の作成」で説明されている手順を使用して、アプリケーション・サーバー接続を作成します。
第2.7項「Oracle JDeveloperからのOracle JCAアダプタ・アプリケーションのデプロイ」で説明されている手順を使用して、アプリケーションをデプロイします。
HelloProject
をテストする前に、Oracle WebLogic Server管理コンソールを使用してデータソースを作成する必要があります。
手順は次のとおりです。
Webブラウザにhttp://<
hostname
>:
<
port
>/console
と入力します。
ユーザー名とパスワードを入力して「ログイン」をクリックします。
管理コンソールが表示されます。
「JDBC」の下の「サービス」領域で「データ・ソース」をクリックします。
「JDBCデータ・ソースの概要」が表示されます。
「新規作成」をクリックします。
「新しいJDBCデータ・ソースの作成」ページが表示されます。
「新しいJDBCデータ・ソースの作成」ページで、次の詳細を入力します。
「名前」フィールドにMyDataSource
と入力します。
「JNDI名」フィールドにjdbc/MyDataSource
と入力します。
「データベースのタイプ」はOracle
です。
「データベース・ドライバ」は、Oracle's Driver (Thin XA) for Instance Connections; Versions 9.0.1, 9.2.0, 10, 11
です。
「次へ」をクリックします。
別のトランザクション構成オプションはないことを示すメッセージが表示されます。
「次へ」をクリックします。
「新しいデータ・ソースの作成」ページが表示されます。
次の詳細を入力します。
データベース名: 通常はSID
です。
ホスト名: ホスト・コンピュータ名を入力します。
ポート番号: ポート番号を入力します。
デフォルト・ポートは1521
です。
データベース・ユーザー名: SCOTT
と入力します。
パスワード: TIGER
と入力します。
パスワードの確認: TIGER
と入力します。
「次へ」をクリックします。
データソース構成の概要が表示されます。
「構成のテスト」をクリックします。
「メッセージ」領域に、接続テストに成功したことが示されます。
「次へ」をクリックします。「AdminServer」チェック・ボックスを選択してターゲットとして選択します。
「終了」をクリックします。
これで、前述の手順で作成したMyDataSourceデータソースがJDBCデータソースの概要に含まれます。
Fusion Middleware Controlコンソールを使用して、デプロイ済のSOAコンポジットを監視できます。次の手順を実行します。
http://
servername
:
portnumber
/em
にナビゲートします。前述の手順で作成したHelloProject[1.0]を含めて、SOAコンポジットのリストが表示されます。
「HelloProject[1.0]」リンクをクリックします。図9-65に示すように、「ダッシュボード」タブが表示されます。
「テスト」をクリックします。新規のブラウザ・ウィンドウが表示されます。
xsd:string
でマーク付けされている「NAME」フィールドに名前を入力し、「呼出し」をクリックします。
ブラウザ・ウィンドウにテスト結果が表示されます。
読取り可能な書式のXMLファイルを表示するには、「フォーマット済XML」をクリックします。図9-66に、フォーマット済XMLファイルを示します。
この使用例では、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プロジェクトを作成します。
JDeveloperを開きます。
「アプリケーション・ナビゲータ」で、「新規アプリケーション」をクリックします。「汎用アプリケーションの作成 - アプリケーションの名前付け」ページが表示されます。
「アプリケーション名」フィールドにFile2SPApp
と入力します。
「アプリケーション・テンプレート」リストで、「汎用アプリケーション」を選択します。
「次へ」をクリックします。
「汎用アプリケーションの作成 - プロジェクトの名前付け」ページが表示されます。
「プロジェクト名」フィールドにわかりやすい名前を入力します。たとえば、File2SPProject
と入力します。
「プロジェクト・テクノロジ」タブの「選択可能」リストで「SOA」をダブルクリックし、「選択済」リストに移動します。
「次へ」をクリックします。「汎用アプリケーションの作成 - SOA設定の設定」ページが表示されます。
「コンポジット・テンプレート」リストから「BPELを使用するコンポジット」を選択して「終了」をクリックします。
新規アプリケーションおよびSOAプロジェクトが作成されました。これにより、SOAコンポジットが自動的に作成されます。
「BPELプロセスの作成」ページが表示されます。
「名前」フィールドにBPELプロセスの名前を入力します。たとえば、File2SP
と入力します。
「テンプレート」リストで「サービスを後で定義」を選択し、「OK」をクリックします。
File2SPApp
のFile2SPProject
内のFile2SP
BPELプロセスが設計領域に表示されます。
次の手順に従ってアウトバウンドOracleデータベース・アダプタ・サービスを作成します。
「データベース・アダプタ」を、「サービス・アダプタ」リストから「公開されたサービス」スイムレーンにドラッグ・アンド・ドロップします。アダプタ構成ウィザードの「ようこそ」ページが表示されます。
「次へ」をクリックします。「サービス名」ページが表示されます。
「サービス名」フィールドにFile2SPService
と入力します。
「次へ」をクリックします。
「サービス接続」ページが表示されます。
「新規データベース接続を作成します。」アイコンをクリックします。
「データベース接続の作成」ダイアログが表示されます。
「データベース接続の作成」ダイアログで次の詳細を入力します。
「接続名」フィールドに接続名を入力します。たとえば、MyConnection
と入力します。
接続タイプとして「Oracle (JDBC)」を選択します。
ユーザー名およびパスワードとしてscott
/tiger
と入力します。
「ホスト名」フィールドにホスト名を入力し、「JDBCポート」フィールドにJDBCポートを入力します。
「SID」を選択してSID名を入力します。または、「サービス名」を選択してサービス名を入力します。
「接続のテスト」をクリックします。「ステータス」ペインに成功メッセージが表示されます。
「OK」をクリックします。
「接続」フィールドにMyConnection接続が移入され、「JNDI」フィールドにeis/DB/MyConnectionが移入されます。
「次へ」をクリックします。
「アダプタ・インタフェース」ページが表示されます。
「アダプタ・インタフェース」ページで、「操作およびスキーマから定義(後で指定)」を選択し、「次へ」をクリックします。
「操作タイプ」ページが表示されます。
図9-67に示すように、「ストアド・プロシージャまたはファンクションの呼出し」を選択して「次へ」をクリックします。
「ストアド・プロシージャの指定」ページが表示されます。
「参照」をクリックします。「ストアド・プロシージャ」ペインでADD_CUSTOMERS
を選択します。
「引数」タブにストアド・プロシージャのパラメータが表示され、「ソース」タブにストアド・プロシージャのソース・コードが表示されます。
「OK」をクリックします。
「ストアド・プロシージャの指定」ページが表示されます。
「プロシージャ」フィールドにADD_CUSTOMERS
ストアド・プロシージャが移入され、ADD_CUSTOMERS
ストアド・プロシージャの引数も表示されます。
「次へ」をクリックします。
「詳細オプション」ページが表示されます。
任意の追加のオプションを指定して、「次へ」をクリックします。
「終了」ページが表示されます。
「終了」をクリックします。
「パートナ・リンクの作成」ダイアログが表示されます。
パートナ・リンク名は、サービス名と同じFile2SPServiceです。
「OK」をクリックします。
アウトバウンドOracleデータベース・アダプタが構成され、File2SP BPELプロセスが表示されます。
invokeアクティビティを作成してBPELプロセスを完成する必要があります。これにより、入力変数が作成されます。
次の手順に従ってinvokeアクティビティを作成します。
「ファイル」、「すべて保存」を順番にクリックします。
「コンポーネント・パレット」から設計領域にinvokeアクティビティをドラッグ・アンド・ドロップします。
invokeアクティビティの右にある右矢印をドラッグし、File2SPService
パートナ・リンクに接続します。
「Invokeの編集」ダイアログが表示されます。
「名前」フィールドにInvoke
と入力します。
「Invoke」ダイアログで、「入力変数」フィールドの右にある「入力変数の自動作成」アイコンをクリックします。
「変数の作成」ダイアログが表示されます。
デフォルトの変数名を選択して「OK」をクリックします。
「Invokeの編集」ダイアログの「変数」領域に入力変数名が表示されます。
「OK」をクリックします。
File2SPService
パートナ・リンクに接続されている右矢印付きの線が表示されます。
次の手順に従ってインバウンド・ファイル・アダプタ・サービスを作成します。これにより、ファイル・ディレクトリから入力XMLを読み取るサービスが作成されます。
「コンポーネント・パレット」から、「ファイル・アダプタ」を「外部参照」スイムレーンにドラッグ・アンド・ドロップします。
アダプタ構成ウィザードの「ようこそ」ページが表示されます。
「次へ」をクリックします。「サービス名」ページが表示されます。
「サービス名」フィールドにReadCustomers
と入力します。
「次へ」をクリックします。
「アダプタ・インタフェース」ページが表示されます。
「操作およびスキーマから定義(後で指定)」を選択し、「次へ」をクリックします。「操作」ページが表示されます。
操作タイプとして「Read File」を選択し、操作名として「Read」を選択します。他のチェック・ボックスは選択しないでください。
「次へ」をクリックします。
「ファイル・ディレクトリ」ページが表示されます。
「物理パス」を選択して、「着信ファイル用のディレクトリ(物理パス)」フィールドに物理パスを入力します。
「ファイルを再帰的に処理します」および正常な配信後にファイルを削除を選択して、「次へ」をクリックします。
「ファイルのフィルタ処理」ページが表示されます。
「ファイル・ワイルドカード(po*.txt)」を指定して、customers.xml
を「インクルード・ファイルの名前パターン」フィールドに入力し、次に、「次へ」をクリックします。
「ファイル・ポーリング」ページが表示されます。
「ポーリング頻度」フィールドで任意の値を指定して「次へ」をクリックします。
「メッセージ」ページが表示されます。
「URL」フィールドの端に表示される「スキーマ・ファイルを参照」をクリックします。
「タイプ・チューザ」ダイアログが表示されます。
「プロジェクトのスキーマ・ファイル」、「SCOTT_ADD_CUSTOMERS.xsd」および「InputParameters」を順番にクリックします。
「OK」をクリックします。
「メッセージ」ページが再表示されます。URLはxsd/SCOTT_ADD_CUSTOMERS.xsd
で、「スキーマ要素」はInputParameters
となっています。
「次へ」をクリックします。
「終了」ページが表示されます。
「終了」をクリックします。
インバウンド・ファイル・アダプタ・サービスが終了します。
「OK」をクリックしてパートナ・リンクを完了します。
「ファイル」、「すべて保存」を順番にクリックします。
ファイル・アダプタ・サービスはreceiveアクティビティに入力を提供し、receiveアクティビティは残りのBPELプロセスを開始します。
次の手順に従ってreceiveアクティビティを追加します。
「File2SP」をダブルクリックします。「File2SP.bpel」ページが表示されます。
「コンポーネント・パレット」から設計領域にreceiveアクティビティをドラッグ・アンド・ドロップします。
receiveアクティビティの左にある左矢印をドラッグし、ReadCustomers
パートナ・リンクに接続します。
「Receiveの編集」ダイアログが表示されます。
「名前」フィールドにReceive
と入力します。
「Receiveの編集」ダイアログで、「変数」フィールドの右にある「入力変数の自動作成」アイコンをクリックします。
「変数の作成」ダイアログが表示されます。
デフォルトの変数名を選択して「OK」をクリックします。
「変数」フィールドにデフォルトの変数名が移入されます。
「インスタンスの作成」を選択して「OK」をクリックします。JDeveloperの「File2SP.bpel」ページが表示されます。
receiveアクティビティを追加した後、図9-68に示すようにJDeveloperウィンドウが表示されます。
「ファイル」、「すべて保存」を順番にクリックします。
次に、入力パラメータに値を割り当てる必要があります。
次の手順に従ってassignアクティビティを追加します。
「コンポーネント・パレット」から、assignアクティビティを設計領域のreceiveアクティビティとinvokeアクティビティの間にドラッグ・アンド・ドロップします。
assignアクティビティをダブルクリックします。
「Assign」ダイアログが表示されます。
「一般」をクリックし、「名前」フィールドでCUSTOMER
をクリックします。
「コピー操作」タブをクリックします。
図9-69に示すように、「Assign」ダイアログが表示されます。
図9-69に示すように、プラス・サイン付きのアイコンをクリックして「コピー操作」を選択します。
「コピー操作の作成」ダイアログが表示されます。
「From」領域で、「プロセス」、「変数」、「Receive_Read_InputVariable」および「body」を順番に開きます。
「ns3:InputParameters」を選択します。
「To」領域で、「プロセス」、「変数」、「Invoke_File2SPService_InputVariable」および「InputParameters」を順番に開きます。
「ns3:InputParameters」を選択します。
「OK」をクリックします。図9-70に示すように、「Assign」ダイアログが表示されます。
「OK」をクリックします。
図9-71に示すように、JDeveloperの「File2SP.bpel」ページが表示されます。
「ファイル」、「すべて保存」を順番にクリックします。
作成した3つのコンポーネント(インバウンド・アダプタ・サービス、BPELプロセスおよびアウトバウンド・アダプタ参照)をアセンブルまたは接続する必要があります。コンポーネントを接続する手順は、次のとおりです。
「公開されたサービス」領域にあるReadCustomer
内の小さい三角形を、「コンポーネント」領域のBPELプロセス内に緑の三角形として表示されるドロップ・ゾーンにドラッグします。
「コンポーネント」領域にあるBPELプロセス内の小さい三角形を、「外部参照」領域のFile2SPService
内に緑の三角形として表示されるドロップ・ゾーンにドラッグします。
「ファイル」、「すべて保存」を順番にクリックします。
前述の手順で作成したSOAプロジェクトおよびアプリケーションについて、アプリケーション・プロファイルをデプロイする必要があります。JDeveloperを使用してアプリケーション・プロファイルをデプロイするには、次の手順に従います。
第2章の「Oracle JCAアダプタ用のアプリケーション・サーバー接続の作成」で説明されている手順を使用して、アプリケーション・サーバー接続を作成します。
第2.7項「Oracle JDeveloperからのOracle JCAアダプタ・アプリケーションのデプロイ」で説明されている手順を使用して、アプリケーションをデプロイします。
File2SPProject
をテストする前に、Oracle WebLogic Server管理コンソールを使用して、次の手順でデータソースを作成する必要があります。
http://
servername
:
portnumber
/console
にナビゲートします。
必要な資格証明を使用して、Oracle WebLogic Server管理コンソールのホーム・ページを開きます。
図9-72に示すように、Oracle WebLogic Server管理コンソールのホーム・ページが表示されます。
「ドメイン構造」で、「サービス」、「JDBC」を選択し、「データ・ソース」をクリックします。
図9-73に示すように、「JDBCデータ・ソースの概要」ページが表示されます。
「新規作成」をクリックします。
「新しいJDBCデータ・ソースの作成」ページが表示されます。
新しいJDBCデータソースの識別に使用するプロパティについて次の値を入力します。
「名前」フィールドにMyDataSource
と入力します。
「JNDI名」フィールドにjdbc/MyDataSource
と入力します。
「データベースのタイプ」にはデフォルト値のOracle
を保持します。
「データベース・ドライバ」には、デフォルト値のOracle's Driver (Thin XA) for Instance Connections; Versions 9.0.1, 9.2.0, 10, 11
を保持します。
「次へ」をクリックします。
「新しいJDBCデータ・ソースの作成 - トランザクション・オプション」ページが表示されます。他のトランザクション構成オプションがないことを示すメッセージが表示されます。
「次へ」をクリックします。
「新しいJDBCデータ・ソースの作成 - 接続プロパティ」ページが表示されます。
「接続プロパティ」ページで、次の接続プロパティを入力します。
「データベース名」フィールドに名前(通常はSID)を入力します。
「ホスト名」フィールドにホスト名を入力します。
「ポート」フィールドにポート番号を入力します。
「データベース・ユーザー名」フィールドにSCOTT
と入力します。
「パスワード」フィールドにTIGER
と入力します。
「パスワードの確認」フィールドにTIGER
と入力します。
「次へ」をクリックします。「新しいJDBCデータ・ソースの作成 - データベース接続のテスト」ページが表示されます。
「構成のテスト」をクリックし、データベースの可用性および指定した接続プロパティをテストします。「新しいJDBCデータ・ソースの作成 - データベース接続のテスト」ページの上部に「接続テストが成功しました。」という内容のメッセージが表示されます。
「次へ」をクリックします。
「新しいJDBCデータ・ソースの作成 - ターゲットの選択」ページが表示されます。
ターゲットとして「AdminServer
」を選択し、「終了」をクリックします。
「JDBCデータ・ソースの概要」ページが表示されます。このページには、このドメインに作成されているJDBCデータソース・オブジェクトがまとめられています。このリストには、作成したデータソースが表示されます。
データベース・アダプタには、データソースを指すインスタンス・エントリが必要です。
次の手順に従って接続インスタンスを追加します。
beahome/でDbAdapter.rarを検索します。
ファイルを解凍します。
次の例に示すように、META-INF/weblogic-ra.xml
(および、場合によってはra.xml
)を編集します。
<connection-instance> <jndi-name>eis/DB/MyConnection</jndi-name> <connection-properties> <properties> <property> <name>xADataSourceName</name> <value>jdbc/MyDataSource</value> </property> </properties> </connection-properties> </connection-instance>
JNDI名と同じデータベース接続名MyConnectionを使用します。
xADataSourceName
と同じデータソース名MyDataSourceを使用します。
このファイルから再びJARを作成します。
アプリケーション・サーバーを再起動します。
新規データベース・アダプタ・インスタンスは、Oracle WebLogic Server管理コンソールを使用して作成することもできます。
ファイル・アダプタの入力ファイルを用意して、BPELプロセスをテストする必要があります。BPELプロセスの結果は、表からの単純な問合せを使用して表示されます。customers.xml
ファイルには、次の入力が含まれています。
<InputParameters xmlns="http://xmlns.oracle.com/pcbpel/adapter/db/SCOTT/ADD_CUSTOMERS/"> <C> <C_ITEM> <FNAME>John</FNAME> <LNAME>Doe</LNAME> <LOC> <STREET>123 Main Street</STREET> <CITY>Anytown</CITY> <STATE>CA</STATE> <ZIP>12345</ZIP> </LOC> <EMAIL>john.smith@gmail.com</EMAIL> <PHONE>567-123-9876</PHONE> </C_ITEM> <C_ITEM> <FNAME>Jane</FNAME> <LNAME>Doe</LNAME> <LOC> <STREET>987 Sunset Blvd</STREET> <CITY>Sometown</CITY> <STATE>CA</STATE> <ZIP>34567</ZIP> </LOC> <EMAIL>JaneDoe@yahoo.com</EMAIL> <PHONE>567-123-9876</PHONE> </C_ITEM> </C> </InputParameters>
次の手順に従って、作成したBPELプロセスをテストします。
customers.xml
のコピーを、インバウンド・ファイル・アダプタ・サービスの作成時に指定した入力ディレクトリに置きます。
Oracleファイル・アダプタにより新規ファイルについてディレクトリがポーリングされます。ファイル・アダプタ・サービスによりファイルが受信されると、receiveアクティビティによりBPELプロセスが開始されます。
すべての顧客に関するデータは、ストアド・プロシージャのInputParametersに割り当てられます。
ストアド・プロシージャが実行されます。各顧客のデータが変換され、顧客データが表に挿入されます。
表を問い合せると、次の結果が表示されます。
SQL> select * from customers; NAME LOC ------------------------- --------------------------------------------- EMAIL PHONE ------------------------- --------------- Doe, John 123 Main Street, Anytown, CA 12345 john.smith@gmail.com 567-123-9876 Doe, Jane 987 Sunset Blvd, Sometown, CA 34567 JaneDoe@yahoo.com 567-123-9876
Fusion Middleware Controlコンソールを使用して、デプロイ済のEMコンポジットを監視できます。次の手順を実行します。
http://
servername
:portnumber
/em
にナビゲートします。
前述の手順で作成したFile2SPProject[1.0]
を含めて、SOAコンポジットのリストが表示されます。
「File2SPProject[1.0]」をクリックします。
「ダッシュボード」が表示されます。「最新のインスタンス」領域で「インスタンスID」の値をメモします。
「インスタンス」タブをクリックします。
「検索」ダイアログが表示されます。デフォルトの検索では、すべてのインスタンスがインスタンスIDで表示されます。
前述の「インスタンスID」を選択します。
新規ウィンドウが開きます。フォルトがあればそれ(または「フォルトが見つかりません」)が表示され、インスタンスの「監査証跡」を表示できます。インスタンスのトレースが新規ウィンドウに表示されます。
インスタンス・ツリーは、「ReadCustomers」(サービス)、「File2SP」(BPELコンポーネント)、「File2SPService」(参照)へと順番に開かれています。
「File2SP」 BPELコンポーネントをクリックします。
プロセスの「監査証跡」が表示されます。
図9-74に示すように、「<payload>」ノードを開いて、ストアド・プロシージャに提供された入力を確認します。
さらに、図9-75に示すように、「フロー」タブをクリックしてプロセス・フローを表示します。
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データベース・アダプタを使用するには、次の手順を実行する必要があります。
WebLogic Server 10.3.5とともにOracle 11.1.1.7.1 SOA Suiteをインストールします。
SOAインストールでDbAdapter.rar
を検索します。
cd $BEAHOME/AS11gR1SOA/soa/connectors mkdir tmp
バンドルされた10.3.6バージョンのtoplink-grid.jar
をDbAdapter.rar
から次のように削除します。
unzip DbAdapter.rar -d tmp cd tmp rm toplink-grid.jar
既存のマニフェストとともにDbAdapter.rar
を再構築します。これにより、共有ライブラリのTopLink Gridを検索します。
cd $BEAHOME/AS11gR1SOA/soa cd $BEAHOME/AS11gR1SOA/soa/connectors mkdir tmp jar cvmf META-INF/MANIFEST.MF DbAdapter.rar * mv DbAdapter.rar .. cd .. rm -rf tmp
$BEAHOME/modules/com.oracle.toplinkgrid_1.0.0.0_11-1-1-5-0.jarをtoplink-grid
という名前の共有ライブラリとしてWebLogic Serverホスト・コンソールからデプロイします。
toplink-gridという名前の共有ライブラリ(「デプロイメント」→「インストール」)から行います。
WebLogic Serverを再起動します。
データベース・アダプタの現在の設計では、アダプタによって選択および挿入を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-76は、データベース・アダプタ・ウィザードの「操作タイプ」画面に表示されたキャッシュなしオプション(「なし」
を選択)を示しています。
図9-76 キャッシュなしが選択されたデータベース・アダプタ構成ウィザードの「操作タイプ」画面
この画面では「なし」
オプションが選択されており、すべてのアウトバウンド操作が有効です。このオプションを選択して「次へ」
または「終了」
を選択すると、選択した操作のいずれにもプロパティCacheUsage
は含まれなくなります。このプロパティが存在しない状態は、JCAアクティブ化プロパティCacheUsage
が値none
になっているのと同じです。
「キャッシュの使用方法」として「なし」
オプションを選択した場合、次のオプションの操作のみが事前に選択されます。
Merge
挿入のみ
選択
「操作タイプ」画面では、読取り/書込みキャッシュを有効化できます。図9-77を参照してください。このオプションを選択して「次へ」
または「終了」
を押すと、JCAプロパティCacheUsage
の値がread-write
に設定されます。
この画面で「キャッシュの使用方法」
ドロップダウンから「読取り-書込み」
オプションを選択した場合の各操作の使用方法を理解するには、次のリストを参照してください。
「挿入または更新(マージ)」
は有効であり、ラベルの末尾には「キャッシュの使用」
という文字列が付加されます。
「挿入のみ」
は無効であり、基礎となるキャッシュ・ストアによって常にマージが実行されます。
「更新のみ」
は無効であり、基礎となるキャッシュ・ストアによって常にマージが実行されます。
「削除」
は選択可能ですが、事前には選択されておらず、選択すると末尾に「キャッシュの使用」
という文字列が付加されます。
「選択」
は無効であり、この問合せは、Coherenceマップで実行されるCoherenceフィルタに変換されます。
「例による問合せ」
は無効であり、データベース・アダプタ/Coherence統合の問合せは、Coherenceマップで実行されるCoherenceフィルタに変換されます。
「主キーによる選択」
のラベルの末尾には、「キャッシュの使用」
という文字列が付加されます。
「操作タイプ」画面の「キャッシュの使用方法」
オプションを使用すると、読取りキャッシュを有効化できます。図9-78を参照してください。画面上でこのオプションを選択して「次へ」
または「終了」
を押すと、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つのテンプレートを次に示します。
<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キャッシュを共有できます。