ヘッダーをスキップ
Oracle® Fusion Middlewareテクノロジ・アダプタ・ユーザーズ・ガイド
11g リリース1 (11.1.1.5.0)
B55918-04
  目次へ移動
目次		 索引へ移動
索引
前
前 		 次
次		  

9 Oracle JCA Adapter for Database

この章では、Oracle BPEL Process ManagerおよびOracle Mediator(メディエータ)と連携して機能するOracle JCA Adapter for Database(Oracleデータベース・アダプタ)について説明します。この章では、ストアド・プロシージャおよびファンクション(Oracleデータベースのみ)のサポートについても説明します。また、Oracleデータベース・アダプタおよびストアド・プロシージャの使用例も参照できます。

この章には、次の項目が含まれます。

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

Oracleデータベース・アダプタを使用すると、Oracleデータベースまたはサード・パーティのデータベースとBPELプロセスとのJDBCを介した通信が可能になります。Oracleデータベース・アダプタ・サービスは、Oracle BPEL Process Manager(Oracle BPEL PM)のアダプタ構成ウィザードを使用してBPELプロセスのパートナ・リンク内で定義されます。

この項には、次の項目が含まれます。

9.1.1機能概要

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プロジェクトを作成し、アダプタ構成ウィザードを使用して次の手順を実行します。

第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データベース・アダプタの詳細は、次の各項を参照してください。

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

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

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

9.1.2 設計の概要

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

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

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

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

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

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

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

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

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

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

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

ファイル 説明

<serviceName>.wsdl

これは、操作および入出力XML要素の名前によってサービス・エンドポイントを定義する抽象WSDLです。

<serviceName>_table.xsd

これには、これらの入出力XML要素のXMLファイル・スキーマが含まれます。これらの両ファイルは、SOAプロジェクトの残りへのインタフェースを形成します。

<serviceName>_or-mappings.xml

これは内部ファイルです。リレーショナル・スキーマとXMLスキーマ間のマッピングを記述するために使用されるTopLink固有のファイルです。実行時に使用されます。

<serviceName>_db.jca

これには、抽象WSDLの内部実装詳細が含まれます。これには、場所と操作に関する2つのメイン・セクションがあります。場所は、アダプタ・インスタンスのJNDI名(eis/DB/SOADemo)です。操作は、エンドポイントに対して実行するアクション(INSERT、UPDATE、SELECTおよびPOLLなど)です。db.jcaファイルの内容は、アダプタ構成ウィザードの実行時に行った選択によってすべて決定されます。

<serviceName>.properties

これも内部ファイルです。表のインポート時に作成され、表に関する情報が保存されます。設計時にのみ使用されます。

実行時には、前述の場所を使用して、サービスを実行するアダプタ・インスタンスが参照されます。db.jcaファイルおよびリンクされているor-mappings.xmlファイルのプロパティに基づいて、<seviceName>.propertiesにより実行対象として正しいSQLが生成され、入力XMLが解析されて、XSDファイルに一致する出力XMLファイルが作成されます。SQLを実行するために、プールされているSQL接続が基礎となるデータソースから取得されます。

9.2 アダプタ構成ウィザードの概要

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

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

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

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

  1. JDeveloperを開きます。

  2. 「アプリケーション・ナビゲータ」で、「新規アプリケーション」をクリックします。

    図9-2に示すように、「汎用アプリケーションの作成 - アプリケーションの名前付け」ページが表示されます。

  3. 「アプリケーション名」フィールドにアプリケーションの名前を入力します。

  4. 「アプリケーション・テンプレート」リストで、「汎用アプリケーション」を選択します。

    図9-2 「汎用アプリケーションの作成 - アプリケーションの名前付け」ページ

    図9-2の説明が続きます
    「図9-2 「汎用アプリケーションの作成 - アプリケーションの名前付け」ページ」の説明

  5. 「次へ」をクリックします。

    図9-3に示すように、「汎用アプリケーションの作成 - プロジェクトの名前付け」ページが表示されます。

  6. 「プロジェクト名」フィールドにわかりやすい名前を入力します。

  7. 「プロジェクト・テクノロジ」タブの「選択可能」リストで「SOA」をダブルクリックし、「選択済」リストに移動します。

    図9-3 「汎用アプリケーションの作成 - 汎用プロジェクトの名前付け」ページ

    図9-3の説明が続きます
    「図9-3 「汎用アプリケーションの作成 - 汎用プロジェクトの名前付け」ページ」の説明

  8. 「次へ」をクリックします。図9-4に示すように、「汎用アプリケーションの作成 - SOA設定の設定」ページが表示されます。

    図9-4 「汎用アプリケーションの作成 - SOA設定の設定」ページ

    図9-4の説明が続きます
    「図9-4 「汎用アプリケーションの作成 - SOA設定の設定」ページ」の説明

  9. 「コンポジット・テンプレート」リストから「BPELを使用するコンポジット」を選択して「終了」をクリックします。

    新規アプリケーションおよびSOAプロジェクトが作成されました。これにより、SOAコンポジットが自動的に作成されます。

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

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

    図9-5の説明が続きます
    「図9-5 「BPELプロセスの作成」ページ」の説明

  10. 「名前」フィールドにBPELプロセスの名前を入力します。

  11. 「テンプレート」リストで「サービスを後で定義」を選択し、「OK」をクリックします。

    BPELプロセスが作成されました。

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

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

  1. 「コンポーネント・パレット」で、「SOA」を選択します。

  2. 「サービス・アダプタ」リストから、「データベース・アダプタ」を「composite.xml」ページの公開されたコンポーネント・スイムレーンにドラッグ・アンド・ドロップします。

    「アダプタ構成ウィザード」が表示されます。


    注意:

    Oracleデータベース・アダプタ・サービスをBPELプロセスの一部として作成するには、「サービス・コンポーネント」から「コンポーネント」にBPELプロセスをドラッグ・アンド・ドロップします。それをダブルクリックします。次に、BPELの「コンポーネント・パレット」で、「データベース・アダプタ」を「BPELサービス」からいずれかの「パートナ・リンク」スイムレーンにドラッグ・アンド・ドロップします。

  3. 「次へ」をクリックします。図9-6に示すように、「サービス名」ページが表示されます。次の情報を入力します。

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

    図9-6の説明が続きます
    「図9-6 サービス名の指定」の説明

  4. 「サービス名」フィールドにサービス名を入力し、「次へ」をクリックします。「サービス接続」ページが表示されます。

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

9.2.3 データベースへの接続

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

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

詳細は、第9.5項「デプロイメント」を参照してください。

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

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

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

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

    データソースとアウトバウンド接続プールについては、第2.19項「アダプタ・コネクション・ファクトリの追加」を参照してください。

  • 「次へ」をクリックすると、データベースへの接続が試行されます。接続を確立できないと、既存のパートナ・リンクを編集している場合でも次のウィンドウに進めません。

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

9.2.4 操作タイプの選択

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

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

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

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

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

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

  • 表に対して操作を実行

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

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


    注意:

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

  • 表の新規レコードまたは更新されたレコードをポーリング

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

    詳細は、第9.4.2.2項「ポーリング計画」を参照してください。

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

    図9-9 ポーリング操作

    図9-9の説明が続きます
    「図9-9 ポーリング操作」の説明

  • Pure SQLの実行

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


    注意:

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

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

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

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

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

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

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


注意:

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

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

9.2.6 主キーの定義

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

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

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

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

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


注意:

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

row idフィールドを主キーとして使用する方法を示すサンプルを入手するには、Oracle SOA Sample Codeサイトにアクセスし、「Adapters」タブを選択します。


注意:

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

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

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

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

図9-12の説明が続きます
「図9-12 「アダプタ構成ウィザード - リレーションシップ」ページ」の説明

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

  • データベース上に表間の外部キー制約がすでに存在する場合、表をインポートすると、ソース表(外部キー制約を含む表)からターゲット表に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に、新しいリレーションシップを作成する場所を示します。

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

図9-13の説明が続きます
「図9-13 「リレーションシップの作成」ダイアログ」の説明

新しいリレーションシップを作成するには、次のようにします。

  1. 親表と子表を選択します。

  2. マッピング・タイプ(1対多、1対1または子表に外部キーのある1対1)を選択します。

  3. 外部キー・フィールドを主キー・フィールドに関連付けます。

  4. オプションでリレーションシップに名前を付けます(デフォルト名が生成されます)。


注意:

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

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

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

図9-14 EMPLOYEEスキーマ

図9-14の説明が続きます
「図9-14 EMPLOYEEスキーマ」の説明

図9-15 ADDRESSスキーマ

図9-15の説明が続きます
「図9-15 ADDRESSスキーマ」の説明

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

Employee:

  • id (IDフィールドへのダイレクト・マッピング。たとえば、151)

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

  • addrId (ADDR_IDフィールドへのダイレクト・マッピング。たとえば、345)

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

Employee:

  • id

  • name

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

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

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

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

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

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

9.2.8 属性フィルタの作成

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

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

図9-16の説明が続きます
「図9-16 「アダプタ構成ウィザード - 属性のフィルタ処理」ページ」の説明

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

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

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

9.2.9 WHERE句の定義

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


注意:

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

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

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

図9-17の説明が続きます
「図9-17 「アダプタ構成ウィザード - 選択条件の定義」ページ」の説明


注意:

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

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

  1. EMP.ID = 123

    この場合、RHSはリテラル値です。このRHSは、図9-18に示す「リテラル」オプションです。

  2. EMP.ADDR_ID = ADDR.ID

    この場合、RHSは別のデータベース・フィールドです。このRHSは、図9-18に示す「問合せキー」オプションです。

  3. EMP.ID = ?

    この場合、RHSの値は実行時に指定する必要があります。これは、図9-18に示す「パラメータ」オプションです。

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

図9-18 式ビルダー

図9-18の説明が続きます
「図9-18 式ビルダー」の説明

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

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

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

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

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

9.2.10 読取り後計画の選択

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

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

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

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

図9-19の説明が続きます
「図9-19 「アダプタ構成ウィザード - 読取り後」ページ」の説明

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

9.2.10.1 読取り済の行の削除

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

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

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

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

図9-20の説明が続きます
「図9-20 「アダプタ構成ウィザード - 論理削除」ページ」の説明

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

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

図9-21の説明が続きます
「図9-21 表のフィールドの更新」の説明

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

  • 行150および153はすでに読み取られて処理されています。

  • STATUS列にUNPROCESSEDと表示されているため、次のポーリング・イベントで、行152が読み取られて処理されます。Unread Valueが明示的に指定されているため、行151は読み取られません。

  • 行154にはLOCKEDというフラグが付いているため読み取られません。表が他のプロセスに使用されている場合、この予約値を使用できます。

9.2.10.3 順序表の更新

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

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

図9-22の説明が続きます
「図9-22 「アダプタ構成ウィザード - 順序表」ページ」の説明

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

図9-23 順序表の更新

図9-23の説明が続きます
「図9-23 順序表の更新」の説明

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

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

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

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

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

図9-24の説明が続きます
「図9-24 「アダプタ構成ウィザード - 外部順序表」ページ」の説明

9.2.10.5 順序ファイルの更新

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

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

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

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

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

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

図9-26の説明が続きます
「図9-26 ポーリング・オプションの指定」の説明

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

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

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

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

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

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

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

9.2.12 詳細オプションの指定

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

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

図9-27の説明が続きます
「図9-27 詳細オプションの指定」の説明

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

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

  • 無限に再試行するには、「試行」フィールドにunlimitedと入力します。

  • 「間隔」は、再試行間の遅延です。

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

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

  • 「アクティブな作業ユニットの取得」は、同じグローバル・トランザクションの全invokeアクティビティで同じデータベースに接続する場合に、同じSQL接続を使用するように強制する詳細設定です。これにより、後のinvokeアクティビティで前のinvokeアクティビティの変更を確認できることを保証するのが容易になりますが、この設定がまったく不要な場合もあります(エミュレート2フェーズ・コミットを使用する場合は、自動的に同じ接続になります)。もう1つの相違点は、MERGEおよびINSERTの場合、グローバル・トランザクションがコミットされるまですべての変更が書き込まれないため、この設定を使用するとWRITE操作の発生時期も変化することです。

  • 「省略の検出」を選択すると、MERGEおよびINSERT操作で入力ペイロード内の空または欠落しているXML要素を無視できます。MERGE操作の場合は、これにより有効だが未指定の値がNULLで上書きされなくなります。INSERT操作の場合は、これらの値がINSERT文から省略され、デフォルト値を有効にすることができます。

  • 「マージの最適化」は、MERGEのパフォーマンス全般の強化であるため(主キーの存在チェックの問合せに使用)、常に選択する必要があります。

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

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

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

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

図9-28 SQL文字列の入力

図9-28の説明が続きます
「図9-28 SQL文字列の入力」の説明

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

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

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

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

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

次の項目が含まれます。

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

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

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

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

  • 両方のOracleデータベース・アダプタの起動を、グローバル・トランザクションに関与するように構成する必要があります。

  • 両方のOracleデータベース・アダプタの起動が、同じグローバル・トランザクションに関与する必要があります。

  • いずれかの起動に失敗した場合は、グローバル・トランザクションをロールバックする必要があります。


注意:

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

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

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

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


注意:

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

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

Oracle WebLogic Serverではdata-sources.xmlファイルを編集できないことに注意してください。第2.19.1項「データソースの作成」の説明に従って、Oracle WebLogic Server管理コンソールを使用してデータソースを作成する必要があります。

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

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

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

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

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

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

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

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

  • ある書込みには成功しても他の書込みに失敗した後で、1回の起動の一部として複数の表を挿入または更新するOracleデータベース・アダプタ操作に失敗した場合。この場合、起動操作はアトミックでなく、コミットするとデータが破損する可能性があるため、Oracleデータベース・アダプタはグローバル・トランザクションをロールバックのみとしてマーク付けします。

  • データベース停止のシナリオで、グローバル・トランザクションがタイムアウトしてロールバックされるまで、起動が数回再試行される場合。

  • BPELプロセス内で明示的なbpelx:rollbackフォルトがスローされる場合。

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

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

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

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

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

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

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

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

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

RAC構成

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である可能性があります。

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

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

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

  • ある書込みには成功しても他の書込みに失敗した後で、1回の起動の一部として複数の表を挿入または更新するOracleデータベース・アダプタ操作に失敗した場合。この場合、起動操作はアトミックでなく、コミットするとデータが破損する可能性があるため、アダプタはグローバル・トランザクションをロールバックのみとしてマーク付けします。

  • データベース停止のシナリオで、グローバル・トランザクションがタイムアウトしてロールバックされるまで、起動が数回再試行される場合。

  • BPELプロセス内で明示的なbpelx:rollbackフォルトがスローされる場合。WSDL内のGetActiveUnitOfWork="true"。

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

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

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

  • 単純なデータ予測スタイルのレポート問合せ

  • select count(*)のように結果セットが表指向でない場合

  • update allまたはdelete allを実行する場合

  • XMLType列とxqueryで作業する場合

  • アダプタ構成ウィザードの式ビルダーでモデル化されていない複雑なSQLを使用する場合

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

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


注意:

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

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

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

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


注意:

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

例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

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

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

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

  • jca.db.ProxyUserName: OracleConnection.PROXYTYPE_USER_PASSWORDプロキシ・タイプを使用するには、このプロパティをjava.lang.Stringとしてプロキシ・ユーザー名に設定します。

  • jca.db.ProxyPassword: OracleConnection.PROXYTYPE_USER_PASSWORDプロキシ・タイプを使用するには、このプロパティをjava.lang.Stringとしてプロキシ・ユーザー・パスワードに設定します。

  • jca.db.ProxyCertificate: OracleConnection.PROXYTYPE_CERTIFICATEプロキシ・タイプを使用するには、このプロパティをbase64Binaryでエンコードされた、有効な証明書を含むbyte[]配列に設定します。

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

  • jca.db.ProxyDistinguishedName: OracleConnection.PROXYTYPE_DISTINGUISHED_NAMEプロキシ・タイプを使用するには、このプロパティをjava.lang.Stringとしてプロキシ識別名に設定します。

    この識別名は、プロキシされるユーザーのパスワードにかわるグローバル名です。

  • jca.db.ProxyRoles: 使用するプロキシ・タイプに関係なく、このプロパティを必要に応じて設定し、プロキシ・ユーザーに関連付けられるロールをString[]配列として定義できます。この配列内の各java.lang.Stringがロール名に対応します。

  • jca.db.ProxyIsThickDriver: OCIドライバを使用している場合、JDBCレベルのAPIにおけるthickドライバとthinドライバの差異に対応するには、このプロパティを値trueに設定します。

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

詳細は、『Oracle Database JDBC開発者ガイドおよびリファレンス』の第10章「プロキシ認証」を参照してください。

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

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

9.3.6 スキーマ検証

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

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

9.3.7 高可用性

Oracleデータベース・アダプタでは、アクティブ/アクティブ設定で高可用性がサポートされます。アクティブ/アクティブ設定では、インバウンド・データベース・アダプタに分散ポーリング・テクニックを使用して、同じデータが複数回取得されないことを保証できます。詳細は、第9.3.8.1項「分散ポーリングのベスト・プラクティス1: SELECT FOR UPDATE(SKIP LOCKED)」を参照してください。他のアダプタと同様に、Oracleデータベース・アダプタもアクティブ/パッシブ設定でシングルトン動作用に構成できます。これにより、アクティブ/パッシブ設定で動作するパフォーマンスの高いマルチスレッドのインバウンドOracleデータベース・アダプタ・インスタンスは、展開パターンに従ってクラスタ全体で複数のコンポジット・インスタンスを起動できます。また、Oracleデータベース・アダプタは、データベースに障害が発生した場合やデータベースが再起動した場合も高可用性機能をサポートします。DBアダプタが再起動し、メッセージも失いません。XAおよび非XAデータ・ソースの詳細は、第2.21項「Oracle JCAアダプタで使用するデータソースの推奨設定」を参照してください。

9.3.8 スケーラビリティ

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

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

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

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

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


注意:

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

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

9.3.8.1.1 PollingInterval、MaxTransactionSizeおよびActivationInstancesの構成

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

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

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

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

NumberOfThreads x MaxTransactionSize/PollingInterval


注意:

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

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

表9-2 MaxTransactionSize値とMaxRaiseSize値

MaxTransactionSize MaxRaiseSize 説明

10

1

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

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

100

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

>= 100

MaxTransactionSize

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

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

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

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

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

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

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

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

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

および

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

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

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

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

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

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

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

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

9.3.8.1.3 activationInstances

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

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


注意:

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

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

9.3.8.1.4 索引付けおよびNULL値

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

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


注意:

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

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

Oracle Databaseでは、8以降にロッキングのスキップを使用できるようになりましたが、ドキュメント化は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リソース・アダプタのプログラミング』のリソース・アダプタのパッケージ化およびデプロイに関する項

9.3.8.1.6 MarkReservedValue

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

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

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

ロッキングのスキップを予約値よりも優先して使用するメリットは、次のとおりです。

  • ロッキングのスキップを使用すると、クラスタ内および負荷の高い状況において、スケーリングが向上します。

  • 更新/予約した後、コミットし、新しいトランザクションで選択、という手順とは対照的に、すべての作業が1つのトランザクションに含まれます。このため、HA環境においてリカバリ不能の状況が発生するリスクが最小化されます。

  • 一意のMarkReservedValueを指定する必要はありません。この指定を有効にするには、R${weblogic.Name-2}-${IP-2}-${instance}などの複雑な変数を構成する必要があります。

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

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

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

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

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

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

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

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

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

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

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


注意:

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

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


単一ノードでのチューニング方法を示すMultiTablesPerformanceおよびDirectSQLPerformanceサンプルを入手するには、Oracle SOA Sample Codeサイトにアクセスし、「Adapters」タブを選択します。

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

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

パフォーマンス・チューニングの詳細は、次の各項を参照してください。

  • 『Oracle Fusion Middlewareパフォーマンスおよびチューニング・ガイド』のOracle JCA Adapter for Databaseのチューニングに関する項

  • 『Oracle Fusion Middlewareパフォーマンスおよびチューニング・ガイド』のインバウンド・データベース・アダプタのチューニングに関する項

9.3.10 detectOmissions機能

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

使用可能なリリース

リリース10.1.3以上

構成可能

はい

デフォルト値

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

使用例

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

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

要素タイプ 省略 NULL
列 <director></director>

<director />

<!-- director>…</director -->

 <director xsi:nil="true" />
1-1 <!-- dept> … </dept --> <dept xsi:nil="true" />
1-M <!-- empCollection>…

</empCollection -->

 </empCollection>

</empCollection>(空)


注意:

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

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

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

すべてのnull値を省略として扱うには、カスタムTopLinkプラグインに付属するIgnoreNullsMergeサンプルをチェックアウトします。プラグインの動作はこの機能に似ていますが、nullとomissionとの細かい区別を検出できません。

IgnoreNullsMergeサンプル・コードを入手するには、Oracle SOA Sample Codeサイトにアクセスし、「Adapters」タブを選択します。

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

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

パフォーマンス

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

互換性のない相互作用

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

  • DetectOmissionsMerge

  • IgnoreNullsMerge

  • OptimizeMerge


注意:

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

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

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

http://www.oracle.com/technology

9.3.11 OutputCompletedXml機能

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

使用可能なリリース

リリース10.1.2.0.2以上

構成可能

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

デフォルト値

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

問題点

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


注意:

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

パフォーマンス

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

互換性のない相互作用

DirectSQL="true"および"OutputCompletedXml": OutputCompletedXmlが優先されます。

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

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

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

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

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

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

この項には、次の項目が含まれます。

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

この項には、次の項目が含まれます。

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

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

表9-3 MOVIES表の説明

名前 NULLかどうか タイプ

TITLE

NULL以外

VARCHAR2(50)

DIRECTOR

--

VARCHAR2(20)

STARRING

--

VARCHAR2(100)

SYNOPSIS

--

VARCHAR2(255)

GENRE

--

VARCHAR2(70)

RUN_TIME

--

NUMBER

RELEASE_DATE

--

DATE

RATED

--

VARCHAR2(6)

RATING

--

VARCHAR2(4)

VIEWER_RATING

--

VARCHAR2(5)

STATUS

--

VARCHAR2(11)

TOTAL_GROSS

--

NUMBER

DELETED

--

VARCHAR2(5)

SEQUENCENO

--

NUMBER

LAST_UPDATED

--

DATE

対応するXMLスキーマの定義(XSD)は次のとおりです。

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

表9-4 EMP表の説明

名前 NULLかどうか タイプ

EMPNO

NULL以外

NUMBER(4)

ENAME

--

VARCHAR2(10)

JOB

--

VARCHAR2(9)

MGR

--

NUMBER(4)

HIREDATE

--

DATE

SAL

--

NUMBER(7,2)

COMM

--

NUMBER(7,2)

DEPTNO

--

NUMBER(2)

表9-5 DEPT表の説明

名前 NULLかどうか タイプ

DEPTNO

NULL以外

NUMBER(2)

DNAME

--

VARCHAR2(14)

LOC

--

VARCHAR2(13)

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

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

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

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

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

リレーションシップを表現することで人間がXMLを読み取ることが可能になり、データを情報の1つのパケットとして送信できます。XMLファイルでは循環が許可されていないため、要素はそれ自体を含むことはできません。これはOracleデータベース・アダプタにより自動的に処理されます。ただし、重複の可能性があります(つまり、異なるマスター・レコードで、同じXMLディテール・レコードが2回以上出現するということです)。たとえば、問合せで同じ部門で働く2人の従業員が返された場合、返されたXMLではどちらのEMPレコードにも同じDEPTレコードがインラインで出現します。

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

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

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

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

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

  • 複数の表をインポートします。EMPのみをインポートすると、DEPTが表示されません。

  • アダプタ構成ウィザードで、EMPとDEPTのリレーションシップを削除します。これでリレーションシップは削除されますが、外部キー列が元に戻ります。

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

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

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

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

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

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

データベース・タイプ XMLタイプ(接頭辞はxs:)

VARCHAR、VARCHAR2、CHAR、NCHAR、NVARCHAR、NVARCHAR2、MEMO、TEXT、CHARACTER、CHARACTER VARYING、UNICHAR、UNIVARCHAR、SYSNAME、NATIONAL CHARACTER、NATIONAL CHAR、NATIONAL CHAR VARYING、NCHAR VARYING、LONG、CLOB、NCLOB、LONGTEXT、LONGVARCHAR、NTEXT

string

BLOB、BINARY、IMAGE、LONGVARBINARY、LONG RAW、VARBINARY、GRAPHIC、VARGRAPHIC、DBCLOB、BIT VARYING

base64Binary

BIT、NUMBER(1) DEFAULT 0、SMALLINT DEFAULT 0、SMALLINT DEFAULT 0

boolean

TINYINT、BYTE

byte

SHORT、SMALLINT

short

INT、SERIAL

int

INTEGER、BIGINT

integer

NUMBER、NUMERIC、DECIMAL、MONEY、SMALLMONEY、UNIQUEIDENTIFIER

decimal

FLOAT FLOAT16、FLOAT(16)、FLOAT32、FLOAT(32)、DOUBLE、DOUBLE PRECIS、REAL

double

TIME、DATE、DATETIME、TIMESTAMP、TIMESTAMP(6)、SMALLDATETIME、TIMESTAMPTZ、TIMESTAMPLTZ、TIMESTAMP WITH TIME ZONE、TIMESTAMP WITH LOCAL TIME ZONE

dateTime

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

ここで説明されていない型は、デフォルトでjava.lang.Stringおよびxs:stringになります。サポートされているのがxs:dateTime形式のみであるため、タイムスタンプのサポートは基本的です。BFILE型は明確にサポートされていません。


注意:

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

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

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

Oracleデータベース・アダプタでは、リレーショナル・データベース上の任意のリレーショナル・スキーマの、任意のXMLスキーマへのマッピングがサポートされています。ただし、要素のレイアウトに対する明確なユーザー制御がない状態でアダプタ構成ウィザードによりXMLスキーマが生成されるため、ユーザーはXMLスキーマを選択できません。スキーマのマッピング方法は、「アダプタ構成ウィザード」で制御することも、後からTopLink Workbenchで制御することもできます。トランスフォーメーション・ステップとOracleデータベース・アダプタを関連付けることで、任意のリレーショナル・スキーマを任意のXMLスキーマにマッピングできます。

9.4.1.3 複数の表の問合せ

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

以降の各項では、この3つの方法を比較しながら説明します。ただし、単一表から行を選択する場合は、複数の表から選択する場合のような問題が存在しないことに注意してください。

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

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

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

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

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

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

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

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

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

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

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

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

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

メリット

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

  • すべてのデータがデータベースへの2回のラウンドトリップで読み取られます。

  • これは、リリース10.1.2.0.2のデフォルト機能です。

デメリット

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

  • maxTransactionSize(RECEIVEのポーリング時)またはmaxRows(SELECTの起動時)を使用してメモリーに1回にロードされる行数を制限する場合、この設定ではバッチ属性問合せの持ち越しが容易ではありません。結果セットが1つのみの場合は、カーソル付きの結果を操作する方が容易です。(オリジナルの問合せにORDER BY句があると、複数カーソルの使用が困難な場合があります)。

  • TopLinkでSQL文を変更できるのは、認識可能なフォーマットが使用されている場合のみです。ハイブリッドSQLアプローチを使用し、ルートselectにカスタムSQLを設定すると、TopLinkでは、そのSQLを解析してバッチselectを作成することができません。

  • バッチ問合せでは、2つのマスターがどちらも同じディテールを指している場合に、同じディテールが2回戻されないように、DISTINCT句を使用します。結果セットでLOBを戻す場合、DISTINCT句は使用できません。

構成

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

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

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

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

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

メリット

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

  • ポーリング中にmaxTransactionSizeを使用する場合、単一カーソルの処理によるメリットが大きくなります。

  • ハイブリッドSQLのルートをたどってカスタムSQL文に入る場合、処理する必要のあるSQL文は1つのみですが、通常、TopLinkでは非表示の一連のSQL文をさらに使用して関連行を取り込みます。

  • read一貫性: 様々な表について異なるインスタンスで読み取るのではなく、同時にすべての関連行を読み取ることができます。

  • データベースへのラウンドトリップが1回のみですむためパフォーマンスは理想的ですが、バッチ属性読取りは問合せ対象の表ごとに1回ずつ必要です。

デメリット

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

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

Master
Column1 column2 ….. column100

Master1 ...

Detail

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

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

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

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

Master                                             Detail

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

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

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

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

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

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

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

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

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

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

構成

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


注意:

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

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

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

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

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

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

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

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

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

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

表面上は、単一結果セットを戻すのが最善の方法(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設定が存在します。ただし、この設定は大きなリスクを伴います。

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

リレーショナル・スキーマをXMLとしてマッピングした後、基本的なSQL操作もWebサービスとしてマッピングする必要があります。次の項で説明する各操作には、対応するチュートリアルとREADMEファイルがあります。ここで説明されている作業から開始し、この項を読み進めながら実際に1つ以上行ってみることをお薦めします。チュートリアルで説明するように、いくつかの操作では直接SQL等価に変換されますが、その他はより複雑です。

この項には、次の項目が含まれます。

9.4.2.1 DML操作

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

この項には、次の項目が含まれます。

マージ

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

querybyExample

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

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

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

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

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

入力xmlRecord:

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

出力のxmlRecord:

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

アウトバウンド起動操作の使用例

アウトバウンドの起動操作は、次に示すチュートリアル・ファイルで説明されています。

  • Insert

  • Update

  • Delete

  • Merge

  • SelectAll

  • SelectAllByTitle

  • PureSQLSelect

  • QueryByExample

これらのファイルを入手するには、Oracle SOA Sample Codeサイトにアクセスし、「Adapters」タブを選択します。

Pure SQLでの使用例

リリース10.1.3.1の新規オプションを使用すると、任意のSQL文字列を指定して、SQLへの入力と出力を表すXMLを生成できます。Pure SQLの操作は、次に示すチュートリアル・ファイルで説明されています。

  • UpdateAll

  • SelectCount

  • SelectGroupBy

  • SelectStar

これらのファイルを入手するには、Oracle SOA Sample Codeサイトにアクセスし、「Adapters」タブを選択します。

アウトバウンド起動操作の高度な使用例

高度なアウトバウンドの起動操作は、次に示すチュートリアル・ファイルで説明されています。

  • InsertWithClobs

  • XAInsert

  • NativeSequencingInsert

これらのファイルを入手するには、Oracle SOA Sample Codeサイトにアクセスし、「Adapters」タブを選択します。

9.4.2.2 ポーリング計画

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

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

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

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

読取り済の行の削除

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

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

表9-7 削除ポーリング計画の事前条件

一致する要件 競合

挿入のポーリング

ソースでの削除は不可

シャロー・デリート

ソースでの更新は不可

カスケード削除

更新のポーリング

最小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>

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

この操作は、論理削除ポーリング計画を採用するときに選択します。この計画には、処理された各行の特別なフィールドの更新、および処理済の行を除外するための実行時のWHERE句の更新が関連します。アプリケーション行はほとんど削除されないが、状態列isDeletedがtrueに設定されている論理削除に似ています。状態列と読取り値は指定する必要がありますが、変更されたWHERE句と読取り後の更新はOracleデータベース・アダプタにより自動的に処理されます。

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

表9-8 論理削除ポーリング計画の事前条件

一致する要件 競合

挿入のポーリング

ソースでの更新は不可

ソースでの削除は不可

削除のポーリング

最小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-9に、順序付けポーリング計画を使用するための要件を示します。

表9-9 順序付けポーリング計画の事前条件

一致する要件 競合

挿入のポーリング

削除のポーリング

更新のポーリング

実際の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-10に、制御表ポーリング計画を使用するための要件を示します。

表9-10 制御表ポーリング計画の事前条件

一致する要件 競合

挿入のポーリング

高度な構成: データベースのネイティブ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;

ポーリング計画の使用例

ポーリング計画は、次に示すチュートリアルで説明されています。

  • PollingLogicalDeleteStrategy

  • PollingLastUpdatedStrategy

  • PollingLastReadIdStrategy

  • PollingControlTableStrategy

  • MasterDetail(論理削除ポーリング計画)

これらのファイルを入手するには、Oracle SOA Sample Codeサイトにアクセスし、「Adapters」タブを選択します。

ポーリング計画の高度な使用例

高度なポーリング計画は、次に示すチュートリアルで説明されています。

  • DistributedPolling

  • PollingExternalSequencing

  • PollingFileSequencingStrategy

  • PollingForChildUpdates

  • PollingNoAfterReadStrategy

  • PollingOracleSCNStrategy

  • PollingPureSQLOtherTableInsert

  • PollingPureSQLSysdateLogicalDelete

  • PollingWithParameters

これらのファイルを入手するには、Oracle SOA Sample Codeサイトにアクセスし、「Adapters」タブを選択します。

9.5 デプロイメント

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

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

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

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

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

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

  1. fmwhome/でDbAdapter.rarを検索します。

  2. ファイルを解凍します。

  3. META-INF/weblogic-ra.xml(および、場合によってはra.xml)を編集します。

  4. このファイルから再びJARを作成します。

  5. アプリケーション・サーバーを再起動します。

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-11「データベース・プラットフォーム名」を参照してください。

最も一般的なミス

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

後者の場合は、アダプタ・インスタンス名(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データベース・アダプタのプロパティ」を参照してください。付録Aに記載されているプロパティの他に、次の表に示すプロパティも追加できます。

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

前述のプロパティは、oracle.toplink.sessions.DatabaseLoginオブジェクトに出現します。DBConnectionFactory JavadocおよびDatabaseLogin Javadocの情報は、「TopLink API Reference」(http://download.oracle.com/docs/cd/B10464_02/web.904/b10491/index.html)を参照してください。

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

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

データベース PlatformClassName

Oracle10以上(11gを含む)

org.eclipse.persistence.platform.database.Oracle10Platform

Oracle9+(オプション)

org.eclipse.persistence.platform.database.Oracle9Platform

Oracle8

org.eclipse.persistence.platform.database.Oracle8Platform

Oracle7

org.eclipse.persistence.platform.database.OraclePlatform

DB2

org.eclipse.persistence.platform.database.DB2Platform

DB2(AS400e上)

oracle.tip.adapter.db.toplinkext.DB2AS400Platform

Informix

org.eclipse.persistence.platform.database.InformixPlatform

SQLServer

org.eclipse.persistence.platform.database.SQLServerPlatform

MySQL

org.eclipse.persistence.platform.database.MySQLPlatform

その他のデータベース

org.eclipse.persistence.platform.database.DatabasePlatform

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

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


注意:

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

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

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

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

  1. 適切なJDBCドライバJARファイルがインストールされてクラスパスが設定されていることを確認します。

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

    • 『Oracle Fusion Middleware Oracle WebLogic Server JDBCデータ・ソースの構成と管理』

    • 『Oracle Fusion Middleware Oracle WebLogic Serverタイプ4 JDBCドライバ』

    • 『Oracle Fusion Middleware Oracle WebLogic Server JDBCのプログラミング』

  2. 「ファイル」メニューの「新規」をクリックします。

    「新規ギャラリ」ページが表示されます。

  3. 「すべてのテクノロジ」タブで、「一般」カテゴリの「接続」を選択します。

    「新規ギャラリ」ページの右側にある「項目」ペインに、確立できる様々な接続のリストが表示されます。

  4. 「データベース接続」を選択し、「OK」をクリックします。

    「データベース接続の作成」ページが表示されます。

  5. 「接続の作成場所」で、「IDE接続」を選択します。

  6. 「接続名」フィールドにこの接続の名前を入力します。

    たとえば、SQLServerを選択します。

  7. 「接続タイプ」メニューから適切なドライバを選択します。

  8. 資格証明(必要に応じてユーザー名、パスワードおよびロールなど)を入力します。

  9. 接続情報を入力します。

    たとえば、jdbc:sqlserver://HOST-NAME:PORT;databaseName=DATABASE-NAMEと入力します。

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

  10. 「接続のテスト」をクリックします。

  11. 正常に接続した場合は、「OK」をクリックします。

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

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

  1. 適切なJDBCドライバJARファイルをインストールしてクラスパスを設定します。

    詳しくは、第9.6.4項「JDBCドライバJARファイルの場所とクラスパスの設定」を参照してください。

  2. 「ファイル」メニューから「新規」を選択します。

    「新規ギャラリ」ページが表示されます。

  3. 「すべてのテクノロジ」タブで、「一般」カテゴリの「接続」を選択します。

    「新規ギャラリ」ページの右側にある「項目」ペインに、確立できる様々な接続のリストが表示されます。

  4. 「データベース接続」を選択し、「OK」をクリックします。

    「データベース接続の作成」ページが表示されます。

  5. 「接続の作成場所」で、「IDE接続」を選択します。

  6. 「接続名」フィールドにこの接続の名前を入力します。

    たとえば、SQLServerを選択します。

  7. 「接続タイプ」から「汎用JDBC」を選択します。

  8. ユーザー名、パスワードおよびロール情報を入力します。

  9. 「ドライバ・クラス」で「新規」をクリックします。

    「JDBCドライバの登録」ダイアログが表示されます。

    「JDBCドライバの登録」ダイアログでステップ10、11および19を実行します。

  10. 「ドライバ・クラス」にドライバ名(some.jdbc.Driverなど)を入力します。

    たとえば、com.microsoft.sqlserver.jdbc.SQLServerDriverと入力します。

  11. 「ライブラリ」で「参照」をクリックします。

    「ライブラリの選択」ダイアログが表示されます。

    「ライブラリの選択」ダイアログでステップ12および18を実行します。

  12. 「新規」をクリックして新規ライブラリを作成します。

    「ライブラリの作成」ダイアログが表示されます。

    「ライブラリの作成」ダイアログでステップ13から17を実行します。

  13. 「ライブラリ名」フィールドに名前を入力します。

    たとえば、SQL Server JDBCと入力します。

  14. 「クラスパス」をクリックしてから「エントリの追加」をクリックしてドライバの各JARファイルをクラスパスに追加します。

    「パス・エントリの選択」ダイアログが表示されます。

  15. JDBCクラス・ファイルを選択して「選択」をクリックします。

    たとえば、「sqljdbc.jar」を選択します。

  16. すべてのクラス・ファイルを「クラスパス」フィールドに追加した後、「OK」をクリックします。

  17. 「OK」をクリックして「ライブラリの作成」ダイアログを終了します。

  18. 「OK」をクリックして「ライブラリの選択」ダイアログを終了します。

  19. 「OK」をクリックして「JDBCドライバの登録」ダイアログを終了します。

  20. 「JDBC URL」に接続文字列名を入力して、「次へ」をクリックします。

    たとえば、jdbc:sqlserver://HOST-NAME:PORT;databaseName=DATABASE-NAMEと入力します。

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

  21. 「接続のテスト」をクリックします。

  22. 正常に接続した場合は、「OK」をクリックします。

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

表9-12「(Weblogic Serverコンソールからの)データベース・ドライバの選択」に、一般的なサード・パーティ・データベースに関する接続情報をまとめます。

PlatformClassNameの詳細は、表9-11「データベース・プラットフォーム名」を参照してください。

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

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

データベース JDBCドライバ

Microsoft SQL Server

  • OracleのMS SQL Serverドライバ(タイプ4 XA)

  • OracleのMS SQL Serverドライバ(タイプ4)

Sybase

  • OracleのSybaseドライバ(タイプ4 XA)

  • OracleのSybaseドライバ(タイプ4)

Informix

  • OracleのInformixドライバ(タイプ4 XA)

  • OracleのInformixドライバ(タイプ4)

IBM DB2

  • OracleのDB2ドライバ(タイプ4 XA)

  • OracleのDB2ドライバ(タイプ4)

MySQL

MySQLのドライバ(タイプ4)

バージョン: com.mysql.jdbc.Driverを使用

9.6.3.1 Microsoft SQL Serverの使用方法

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

  • ユーザー名およびパスワード

    • SQL Server 2005では、デフォルトでWindows認証もインストールされます。そのため、ユーザー名とパスワードでログインしません。Windowsのユーザー・アカウントに権限があるかないかのどちらかです。JDBCではユーザー名とパスワードの入力が必要です。

  • 接続文字列

    次の例に示すように、sqlcmdログインから接続文字列を推測できます。

    例1:

    sqlcmd
1>
jdbc:microsoft:sqlserver://localhost:1433

    例2:

    sqlcmd -S user.mycompany.com\SQLExpress
1>
jdbc:microsoft:sqlserver://user.mycompany.com\SQLExpress:1433

    例3:

    sqlcmd -S user.mycompany.com\SQLExpress -d master
1>
jdbc:microsoft:sqlserver://user.mycompany.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ドライバの使用を試すこともできます。

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

この項には、次の項目が含まれます。

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

URL: jdbc:sybase:Tds:SERVER-NAME:PORT/DATABASE-NAME

ドライバ・クラス: com.sybase.jdbc.SybDriver

ドライバJar: jConnect-6_0\classes\jconn3.jar

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

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

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

この項には、次の項目が含まれます。

9.6.3.3.1 Informix 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ドライバの詳細は、次のリンクを参照してください。

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

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

この項には、次の項目が含まれます。

9.6.3.4.1 IBM DB2ドライバ

URL: jdbc:db2:localhost:NAME

ドライバ・クラス: com.ibm.db2.jcc.DB2Driver

ドライバJar(v8.1): db2jcc.jar、db2jcc_javax.jar、db2jcc_license_cu.jar

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

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

9.6.3.4.2 JT400ドライバ(AS400 DB2)

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

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

ドライバJar: jt400.jar

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

9.6.3.4.3 IBM Universalドライバ

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

ドライバ・クラス: com.ibm.db2.jcc.DB2Driver

ドライバJar: db2jcc.jar, db2jcc4.jar and db2java.zip

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

次の情報を使用します。

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

ドライバ・クラス: com.mysql.jdbc.Driver

ドライバJar: mysql-connector-java-3.1.10-bin.jar

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

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

実行時

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

  1. ベンダー固有のドライバJARファイルをuser_projects/domains/soainfra/libディレクトリに移動します。

  2. ベンダー固有のドライバJARファイルを<Weblogic_Home>/server/libに移動します。

  3. クラスパスを編集し、ベンダー固有のjarファイルを<Weblogic_HOME>/common/bin/commEnv.shに含めます。

設計時

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

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

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

この項には、次の項目が含まれます。

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

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

この項には、次の項目が含まれます。

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

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

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

  1. 「サービス・アダプタ」リストから「データベース・アダプタ」を「composite.xml」ページの「公開されたサービス」スイムレーンにドラッグ・アンド・ドロップします。

    図9-29に示すように、アダプタ構成ウィザードが表示されます。

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

    図9-29の説明が続きます
    「図9-29 アダプタ構成ウィザード」の説明

  2. 「次へ」をクリックします。図9-30に示すように、「サービス名」ページが表示されます。


    注意:

    データベースまたはユーザー定義データ型を参照するストアド・プロシージャまたはパッケージの名前には、文字$を使用できないことに注意してください。名前に$が含まれていると、XSDファイルの生成に失敗します。

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

    図9-30の説明が続きます
    「図9-30 サービス名の指定」の説明

  3. 「サービス名」フィールドにサービス名を入力し、「次へ」をクリックします。「サービス接続」ページが表示されます。

    図9-31に示すように、接続をサービスに関連付けます。アダプタ・サービスを構成するにはデータベース接続が必要です。リストから既存の接続を選択するか、新規の接続を作成してください。

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

    図9-31の説明が続きます
    「図9-31 アダプタ構成ウィザードにおけるデータベース接続の設定」の説明

  4. 「次へ」をクリックします。「操作タイプ」ページが表示されます。

  5. 図9-32に示すように、「操作タイプ」に「ストアド・プロシージャまたはファンクションの呼出し」を選択します。

    図9-32 アダプタ構成ウィザードにおけるストアド・プロシージャまたはファンクションの呼出し

    図9-32の説明が続きます
    「図9-32 アダプタ構成ウィザードにおけるストアド・プロシージャまたはファンクションの呼出し」の説明

  6. 「次へ」をクリックします。図9-33に示すように、「ストアド・プロシージャの指定」ページが表示されます。このページで、ストアド・プロシージャまたはファンクションを指定します。

    図9-33 「ストアド・プロシージャの指定」ページ

    図9-33の説明が続きます
    「図9-33 「ストアド・プロシージャの指定」ページ」の説明

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

    スキーマ名およびプロシージャ名が不明である場合は、「参照」をクリックして、図9-34に示すように、「ストアド・プロシージャ」ウィンドウにアクセスします。

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

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

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

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

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

    図9-35の説明が続きます
    「図9-35 選択したプロシージャの引数の表示」の説明

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

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

    図9-36の説明が続きます
    「図9-36 選択したプロシージャのソース・コードの表示」の説明

  8. ストアド・プロシージャまたはファンクションを選択して、「OK」をクリックします。図9-37に示すように、APIに関する情報が表示されます。修正するには、「戻る」または「参照」をクリックします。

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

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

  9. 「次へ」をクリックします。ストアド・プロシージャまたはファンクションに、行セット・タイプの出力パラメータ(Oracle DatabaseではREF CURSOR)が含まれる場合、図9-38に示すように、このREF CURSORに対して強い型指定のXSDまたは弱い型指定のXSDを定義できます。

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

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

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

  10. 「次へ」をクリックします。図9-39に示すように、「詳細オプション」ページが表示されます。JDBCの「問合せタイムアウト」の値など、任意の詳細オプションを入力します。その他のオプションとしては、再試行回数や再試行間隔などの再試行パラメータがあります。

    図9-39 「詳細オプション」ページ

    図9-39の説明が続きます
    「図9-39 「詳細オプション」ページ」の説明

  11. すべてのオプションを指定した後、「次へ」をクリックし、「終了」をクリックしてアダプタ構成ウィザードを終了します。

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

    • servicename.wsdl(Factorial.wsdlなど)

    • service_name_db.jca(Factorial_db.jcaなど)

    • schema_package_procedurename.xsd(SCOTT_FACTORIAL.xsdなど)

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

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

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

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

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

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

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

図9-41の説明が続きます
「図9-41 オーバーロードされたプロシージャのソース・コードの表示」の説明

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

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

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

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

  • Overload.wsdl、Overload_db.jca

  • SCOTT_PACKAGE_OVERLOAD_2.xsd

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

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

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

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

この項には、次の項目が含まれます。

9.7.2.1 使用される用語

ProductName

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

データベース名 サポート対象データベース
IBM DB2 IBM DB2 v 9.x
Microsoft SQL Server SQLServer 2000または2005
MySQL MySQL v5.6

DriverClassName

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

データベース名 JDBCドライバ
IBM DB2 com.ibm.db2.jcc.DB2Driver
Microsoft SQL Server com.microsoft.sqlserver.jdbc.SQLServerDriver
MySQL com.mysql.jdbc.Driver

ConnectionString

これはJDBC接続URLです。

データベース名 接続文字列
IBM DB2 jdbc:db2://hostname:port/database-name
Microsoft SQL Server jdbc:sqlserver://hostname:port;databaseName=name
MySQL jdbc:mysql://host:port/database-name

ユーザー名

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

パスワード

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

ProcedureName

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

ServiceName

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

DatabaseConnection

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

宛先

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

パラメータ

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

QueryTimeout

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

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

アダプタ構成ウィザードでは、Oracle Database、IBM DB2、AS/400、Microsoft SQL ServerおよびMySQL v5.2.6以上がサポートされます。

この項には、次の項目が含まれます。

9.7.2.2.1 Microsoft SQL Server

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

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

SQLデータ型 XMLスキーマ型

BIGINT

long

BINARY

IMAGE

TIMESTAMP

VARBINARY

base64Binary

BIT

boolean

CHAR

SQL_VARIANT

SYSNAME

TEXT

UNIQUEIDENTIFIER

VARCHAR

XML(2005のみ)

string

DATETIME

SMALLDATETIME

dateTime

DECIMAL

MONEY

NUMERIC

SMALLMONEY

decimal

FLOAT

REAL

float

INT

int

SMALLINT

short

TINYINT

unsignedByte

前述の表に示したデータ型の他に、別名データ型もサポートされています。別名データ型は、sp_addtypeデータベース・エンジン・ストアド・プロシージャまたはCREATE TYPE Transact-SQL文(SQL Server 2005の場合のみ)を使用して作成されます。Transact-SQL文の使用は、別名データ型の推奨作成方法であることに注意してください。sp_addtypeの使用は推奨されていません。

9.7.2.2.2 DB2のデータ型

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

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

SQLデータ型 XMLスキーマ型

BIGINT

long

BLOB

CHAR FOR BIT DATA

VARCHAR FOR BIT DATA

base64Binary

CHARACTER

CLOB

VARCHAR

string

DATE

TIME

TIMESTAMP

dateTime

DECIMAL

decimal

DOUBLE

double

INTEGER

int

REAL

float

SMALLINT

short

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

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

アダプタ構成ウィザードではストアド・プロシージャはデータベース・ユーザーごとにグループ化されます。IBM DB2のスキーマは、Oracleのスキーマと同等のものです。どちらも、データベース・ユーザーの名前を表します。

IBM DB2の場合、<Default Schema>は現在のデータベース・ユーザーを指します。

別のデータベース・ユーザーを選択するには、「<デフォルト・スキーマ>」をクリックします。「参照」ページには、JDBC接続URLの<database>で指定されたデータベースにデータベース・ユーザーが作成したストアド・プロシージャが表示されます。

アダプタ構成ウィザードでは、別のデータベースへの変更はサポートされていません。

図9-43に示すように、「ストアド・プロシージャ」ダイアログでストアド・プロシージャを選択します。引数は「引数」タブに表示されます。指定のデータベース内でユーザーが作成したデータベース・ストアド・プロシージャを検索するには、「検索」をクリックします。たとえば、d%とD%のどちらによってもDEMOストアド・プロシージャが検索されます。「すべて表示」をクリックすると、指定のデータベース内で現在のユーザーが作成したすべてのストアド・プロシージャが表示されます。

図9-43 「ストアド・プロシージャ」ダイアログ

図9-43の説明が続きます
「図9-43 「ストアド・プロシージャ」ダイアログ」の説明

図9-44に示すように、「ソース」タブをクリックすると、ストアド・プロシージャのソース・コードを表示できます。

図9-44 ストアド・プロシージャのソース・コード

図9-44の説明が続きます
「図9-44 ストアド・プロシージャのソース・コード」の説明

9.7.2.2.3 IBM DB2 AS/400

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

表9-15 IBM DB2 AS/400のストアド・プロシージャのデータ型

SQLデータ型 XMLスキーマ型

BINARY

BINARY LARGE OBJECT

BINARY VARYING

base64Binary

CHARACTER

CHARACTER LARGE OBJECT

CHARACTER VARYING

string

DATE

TIME

TIMESTAMP

dateTime

DECIMAL

NUMERIC

decimal

DOUBLE PRECISION

double

BIGINT

long

INTEGER

int

REAL

float

SMALLINT

short

個別データ型も、CREATE DISTINCT TYPE文を使用して作成されるデータ型でサポートされています。これらのデータ型は、IBM DB2の場合と同様の振舞いをします。

IBM DB2 AS/400の実装は、QSYS2スキーマのカタログ表からの問合せをベースにしています。アダプタで、QSYS2.SCHEMATA表が存在するかどうかが確認されます。存在する場合は、アダプタ構成ウィザードでQSYS2スキーマの表に問合せが行われます。したがって、IBM DB2 AS/400データベースでQSYS2スキーマがサポートされている場合は、アダプタ構成ウィザードアダプタ・ランタイムの両方が機能します。

アダプタ構成ウィザードでは、最初にSYSCATスキーマがチェックされ、次にQSYS2スキーマがチェックされることに注意してください。アダプタでは、SYSIBMスキーマのカタログ表はサポートされていません。

9.7.2.2.4 MySQL

アダプタ構成ウィザードでは、INFORMATION_SCHEMAスキーマのカタログ表を使用して、MySQL v5.6以降のストアド・プロシージャにアクセスできます。v5.6より前のバージョンのMySQLには、INFORMATION_SCHEMAスキーマ内にPARAMETERS表がありません。

PARAMETERS表がない場合、MySQLデータベースでは、ストアド・プロシージャのパラメータに関する情報は提供されません。したがって、プロパティ・ファイル内で必須プロパティを使用して、この情報を提供する必要があります。Parametersプロパティには、ストアド・プロシージャのシグネチャが含まれています。

プロパティ 説明
IsFunction APIがファンクションであるかプロシージャであるかを指定します。
SchemaName APIが定義されているデータベースの名前です。
Parameters ストアド・プロシージャのパラメータです。

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の場合、SchemaName、ParametersおよびIsFunctionプロパティはすべて必須プロパティです。

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

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

SQLデータ型 XMLスキーマ型

BINARY

BLOB

LONGBLOB

MEDIUMBLOB

TINYBLOB

VARBINARY

base64Binary

BOOLEAN

boolean

CHAR

LONGTEXT

MEDIUMTEXT

TEXT

TINYTEXT

VARCHAR

string

DATE

DATETIME

TIMESTAMP

dateTime

DECIMAL

NUMERIC

REAL

decimal

DOUBLE

double

FLOAT

float

TINYINT

byte

TINYINT UNSIGNED

unsigned_byte

SMALLINT

short

SMALLINT UNSIGNED

unsigned_short

INTEGER

INT

MEDIUMINT

int

INTEGER UNSIGNED

INT UNSIGNED

MEDIUMINT UNSIGNED

unsigned_int

BIGINT

long

BIGINT UNSIGNED

unsigned_long

STRINGに対応するSQLデータ型の文字の長さは、VARCHAR (20)のように、Parametersプロパティで(#)表記法を使用して指定できます。他のSQLデータ型の場合、長さの指定は無効です。

UNSIGNED整数データ型は、アダプタ構成ウィザードを使用している場合にはSIGNED整数データ型として扱われます。

MySQLのストアド・プロシージャは、JDBC接続URLに<database>として指定されたデータベースによってグループ化されます。MySQLの場合、「<デフォルト・スキーマ>」はユーザーの接続先データベース(通常はJDBC接続URLで指定)を指します。別のデータベースを選択するには、「<デフォルト・スキーマ>」をクリックします。JDBC接続URLに指定されたデータベースの現在のデータベース内の特定のストアド・プロシージャを検索するには、「検索」をクリックします。たとえば、d%またはD%と入力した場合は、dまたはDで始まるストアド・プロシージャが検索されます。「すべて表示」を選択すると、現在のデータベース内のすべてのストアド・プロシージャが表示されます。

9.7.2.3 データベース接続の作成

アダプタ構成ウィザードを機能させるために必要なカタログ表にアクセスするには、JDeveloperでデータベース接続を作成する必要があります。

JDeveloperを使用してデータベース接続を作成する手順は、次のとおりです。

  1. 「表示」から「データベース・ナビゲータ」を選択します。

  2. アプリケーション名を右クリックして「新規」と「接続」を順番にクリックします。「データベース接続」を選択します。

    図9-45に示すように、「データベース接続の作成」ページが表示されます。

    図9-45 データベース接続の作成

    図9-45の説明が続きます
    「図9-45 データベース接続の作成」の説明

  3. 「接続名」フィールドに接続名を入力します。たとえば、sqlserverと入力します。

  4. 「接続タイプ」リストから、「接続タイプ」として「汎用JDBC」を選択します。

  5. 「ユーザー名」、「パスワード」およびロール情報を入力します。

  6. 「ドライバ・クラス」で「新規」をクリックします。図9-46に示すように、「JDBCドライバの登録」ダイアログが表示されます。

    図9-46 「JDBCドライバの登録」ダイアログ

    図9-46の説明が続きます
    「図9-46 「JDBCドライバの登録」ダイアログ」の説明

  7. ドライバ・クラスを入力します(たとえば、com.microsoft.sqlserver.jdbc.SQLServerDriver)。

  8. 次の手順に従って、新しいライブラリを作成するか、既存のライブラリを編集します。

    1. 「JDBCドライバの登録」ダイアログで「参照」をクリックします。

    2. 「ライブラリの選択」ダイアログで「新規」をクリックします。

      図9-47に示すように、「ライブラリの選択」ダイアログが表示されます。

      図9-47 「ライブラリの選択」ダイアログ

      図9-47の説明が続きます
      「図9-47 「ライブラリの選択」ダイアログ」の説明

    3. 既存のライブラリを選択するか、「新規」をクリックして新しいライブラリを作成してください。

      「ライブラリの作成」ダイアログが表示されます。

    4. ライブラリ名を入力します。たとえば、SQL Server JDBCと入力します。

    5. 「エントリの追加」をクリックして、JDBC JARファイルをクラスパスに追加します。

    6. 「OK」を2回クリックして「ライブラリの作成」ウィンドウを終了します。

    7. 「OK」をクリックして「JDBCドライバの登録」ウィンドウを終了します。

  9. 「JDBC URL」に接続文字列名を入力します。

  10. 「接続のテスト」をクリックします。

  11. 接続が成功すると、図9-48に示す画面が表示されます。

    図9-48 「データベース接続の作成」ダイアログ

    図9-48の説明が続きます
    「図9-48 データベース接続の作成」の説明

  12. 「OK」をクリックし、「終了」をクリックします。

9.7.3 設計時: 成果物の生成

「アダプタ構成ウィザード - ストアド・プロシージャ」では、ストアド・プロシージャまたはファンクションのシグネチャを説明するWSDLファイルおよび有効なXSDファイルを作成できます。次の項では、WSDLファイルとXSDファイル両方の関連する構造およびコンテンツと、それぞれのリレーションシップを説明します。

この項には、次の項目が含まれます。

9.7.3.1 WSDL–XSDリレーションシップ

後続の段落では、前述の例で引用された操作名Factorialおよびプロシージャ名Factorialを使用します(図9-37を参照)。生成されたWSDLにより、XSDファイルがインポートされます。

<types>
  <schema xmlns="http://www.w3.org/2001/XMLSchema">
    <import namespace="http://xmlns.oracle.com/pcbpel/adapter/db/SCOTT/FACTORIAL/"
      schemaLocation="xsd/SCOTT_FACTORIAL.xsd"/>
  </schema>
</types>

ネームスペースはスキーマ、パッケージおよびプロシージャ名から導出され、生成されたXSDではtargetNamespaceと表示されます。

InputParametersというルート要素が、ストアド・プロシージャのINおよびIN/OUTパラメータに対応する要素を指定するためにXSDファイルに作成されます。OutputParametersという別のルート要素も、IN/OUTまたはOUTパラメータがある場合にのみ、要素を指定するためにXSDファイルに作成されます。IN/OUTパラメータはどちらのルート要素にも出現することに注意してください。

これらのルート要素は、XSDファイルでは無名のcomplexType定義として表現されます。定義の順序には、各パラメータの要素が1つ含まれます。INパラメータもIN/OUTパラメータもない場合は、InputParametersルート要素が作成されますが、complexTypeは空になります。XSDファイルのコメントで、そのようなパラメータはないことが示されます。これらのルート要素の一例を示します。

<element name="InputParameters"
  <complexType>
    <sequence>
      <element …>
       …
    </sequence>
  </complexType>
</element>

WSDLでは、パートがこれら2つのルート要素によって定義されるメッセージ・タイプが定義されます。

<message name="args_in_msg"
  <part name="InputParameters" element="InputParameters"/>
</message>
<message name="args_out_msg"
  <part name="OutputParameters" element="OutputParameters"/>
</message>

dbネームスペースは、生成されたXSDのtargetNamespaceと同じです。args_out_msgはXSDファイルでOutputParametersルート要素が生成された場合にのみ含まれるのに対し、args_in_msgメッセージ・タイプは、常にWSDLに含まれることに注意してください。

操作はWSDLで定義されます。このWSDLは、アダプタ・サービスと同じ名前で、入力および出力メッセージがこれら2つのメッセージ・タイプに関して定義されます。

<portType name="Factorial_ptt">
  <operation name="Factorial">
    <input message="tns:args_in_msg"/>
    <output message="tns:args_out_msg"/>
  </operation>
</portType>

出力メッセージはXSDファイルでのOutputParametersルート要素の存在に依存しますが、入力メッセージは常に表示されます。tnsネームスペースは操作名から導出され、WSDLで次のように定義されます。

xmlns:tns="http://xmlns.oracle.com/pcbpel/adapter/db/Factorial/"

XSDファイルのルート要素は、メッセージで使用されるパートの構造を定義します。このメッセージは、WSDLでカプセル化されたWebサービスで送受信されます。

WSDLの入力メッセージは、XSDファイルのInputParametersルート要素に対応します。インスタンスXMLは、ストアド・プロシージャのINおよびIN/OUTパラメータの値を提供します。出力メッセージは、OutputParametersルート要素に対応します。これは、ストアド・プロシージャが実行された後に生成されるXMLファイルです。任意のIN/OUTおよびOUTパラメータの値が保持されます。

9.7.3.2 JCAファイル

JCAファイルは、サービス用のアダプタ構成情報を提供します。コネクション・ファクトリが指定されているため、次の例に示すようにアダプタ・ランタイムがデータベースに接続できます。JCAファイルで管理対象外の接続プロパティを直接指定しないでください。かわりに、アプリケーション・サーバー上にコネクション・ファクトリを作成し、JCAファイルで名前を指定して参照します(<connection-factory location)。

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

JNDI名eis/DB/oracleをアダプタ構成ウィザードでサービス接続として指定していることに注意してください。

相互作用のエンドポイント・プロパティも指定されます。次の例に示すように、スキーマ、パッケージおよびプロシージャの名前が指定されます。操作名により、JCAファイルがサービスWSDLに関連付けられます。

<connection-factory location="eis/db/oracle" UIConnectionName="oracle" adapterRef=""/>
<endpoint-interaction portType="Factorial_ptt" operation="Factorial">
  <interaction-spec
    className="oracle.tip.adapter.db.DBStoredProcedureInteractionSpec">
      <property name="ProcedureName" value="FACTORIAL"/>
      <property name="GetActiveUnitOfWork="false"/>
  </interaction-spec>
  </output>
</endpoint-interaction>

操作名とプロシージャ名に注意してください。明示的なスキーマが選択されている場合、またはパッケージ内でプロシージャが定義されている場合は、これらのプロパティの値もここに示されます。


注意:

JDeveloperを通常モードで起動すると、管理対象外の接続の詳細はDBAdapter.jcaファイルに作成されません。ただし、JDeveloperをプレビュー・モードで起動すると、管理対象外の接続の詳細がDBAdapter.jcaファイルに作成されます。

9.7.3.3 Oracleのデータ型

多くのプリミティブ・データ型には、詳細に定義されたマッピングが用意されているため、設計時および実行時のコンポーネントのどちらでもサポートされています。また、VARRAY、ネストされた表およびOBJECTなどのユーザー定義タイプを使用できます。

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

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

SQLまたはPL/SQLタイプ XMLスキーマ型

BINARY_DOUBLE

DOUBLE PRECISION

double

BINARY_FLOAT

FLOAT

REAL

float

BINARY_INTEGER

INTEGER

PLS_INTEGER

SMALLINT

int

BLOB

LONG RAW

RAW

base64Binary

CHAR

CLOB

LONG

STRING

VARCHAR2

string

DATE

TIMESTAMP

TIMESTAMP WITH TIME ZONE

dateTime

DECIMAL

NUMBER

decimal

9.7.3.4 生成されたXSD属性

表9-18に、生成されたXSDで使用される属性をリスト表示します。

表9-18 生成されたXSD属性

属性 例 意味

name

name="param"

要素の名前

type

type="string"

XMLスキーマ型

db:type

db:type="VARCHAR2"

SQLまたはPL/SQLタイプ

db:index

db:index="1"

パラメータの位置

db:default

db:default="true"

デフォルト句がある場合

minOccurs

minOccurs="0"

最小発生数

maxOccurs

maxOccurs="1"

最大発生数

nillable

nillable="true"

NULL値の許可

dbネームスペースは、実行中に使用される属性と標準のXMLスキーマ属性の区別に使用されます。db:type属性は、データベース・タイプの特定に使用されるため、実行時に適切なJDBCタイプ・マッピングを取得できます。db:index属性は、設計時および実行時のコンポーネントの両方で最適化として使用され、パラメータが適切な順序に配置されていることを確認できます。パラメータ索引は、プロシージャでは1から、ファンクションでは0から開始されます。ファンクションの戻り値は、nameがファンクションの名前で、db:indexが0のOutputParameter要素として表現されます。db:default属性は、パラメータにデフォルト句があるかどうかを特定するために使用されます。

minOccurs値は、XMLファイルからのINパラメータの削除を可能にするために0に設定されます。これは、パラメータにパラメータの値を定義するデフォルト句(X IN INTEGER DEFAULT 0など)がある場合に便利です。実行時にXMLファイルのパラメータに要素が指定されていない場合、そのパラメータはストアド・プロシージャの起動から除外されるため、デフォルト値の使用が可能になります。各パラメータを、ストアド・プロシージャまたはファンクションの起動に使用できるのは最大で一度です。そのため、デフォルト値が常に1のmaxOccursは、パラメータを表す要素から常に除外されます。

nillable属性は、インスタンスXMLの対応する要素にNULL値(<X/>または<X></X>など)を許可するために、常にtrueに設定されています。ただし、NULL値のあるこのような要素を渡すには、(<X xsi:nil="true"/>のように)明示的に宣言する必要がある場合があります。nillable属性に使用されるネームスペースxsiは、インスタンスXMLに(xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"のように)明示的に宣言する必要があります。

9.7.3.5 ユーザー定義タイプ

アダプタ構成ウィザードでも、コレクション(VARRAYおよびネストされた表)およびOBJECTなどのユーザー定義タイプに有効な定義を生成できます。XSDファイルではcomplexType定義として作成されます。

VARRAYの場合、complexType定義によりその順序内にname_ITEMという単一の要素が定義されます。ここでnameはVARRAY要素の名前です。XMLファイルのすべての配列要素でそのように名前が付けられます。次のようなVARRAYタイプ定義があるとします。

SQL> CREATE TYPE FOO AS VARRAY (5) OF VARCHAR2 (10);

タイプがFOOのVARRAY要素Xの場合、次のようなcomplexTypeが生成されます。

<complexType name="FOO">
  <sequence>
    <element name="X_ITEM" db:type="VARCHAR2" minOccurs="0" maxOccurs="5" nillable="true"/>
      <simpleType>
        <restriction base="string">
          <maxLength value="10"/>
        </restriction>
      </simpleType>
  </sequence>
</complexType>

空のコレクションを許可するため、minOccurs値は0です。maxOccurs値は、コレクションで保持できる最大のアイテム数に設定されます。db:index属性が使用されていないことに注意してください。nillableをtrueに設定すると、VARRAYの個々のアイテムでNULL値を使用できます。

VARRAYの要素FOOで指定されている制限の使用に注意してください。これは、VARRAY(またはネストされた表)の宣言で長さがわかる、CHARおよびVARCHAR2などのタイプに使用されます。要素のタイプや最大長が指定されます。指定された長さを超える要素値は、スキーマ検証中にインスタンスXMLが停止する原因になります。

タイプFOOとして宣言されたパラメータの属性値は、生成されたXSDでは次のようになります。

<element name="X" type="db:FOO" db:type="Array" db:index="1" minOccurs="0" nillable="true"/>

typeおよびdb:typeの値は、パラメータがXSDファイルでFOOというcomplexTypeによって定義済の配列として表現されていることを示します。db:indexの値は、ストアド・プロシージャにおけるそのパラメータの位置です。

ネストされた表は、VARRAYとほぼ同じように処理されます。次にネストされた表のタイプ定義を示します。

SQL> CREATE TYPE FOO AS TABLE OF VARCHAR2 (10);

これは、その順序に単一の要素を含む、name_ITEMというcomplexTypeとしても生成されます。ネストされた表が任意のサイズであるためバインドされていないmaxOccurs値を除き、その要素にはVARRAYの例と同じ属性があります。

<complexType name="FOO">
  <sequence>
    <element name="X_ITEM" … maxOccurs="unbounded" nillable="true">
      …
    </element>
  </sequence>
</complexType>

VARRAYのX_ITEM要素には同じ制限が生成されます。このタイプとして宣言されたXパラメータの属性は、VARRAYの例と同じです。

PL/SQLパッケージ仕様の内側で定義されたcollections(Varrayおよびネストした表)はサポートされないことに注意してください。例:

SQL> create package pkg as
   >   type vary is varray(10) of number;
   >   type ntbl is table of varchar2(100;
   >   procedure test(v in vary, n in ntbl);
   > end;
   > /

ユーザーがアダプタ構成ウィザードでストアド・プロシージャについてtestプロシージャを選択すると、そのタイプがサポートされていないことを示すエラーが発生します。ただし、パッケージ外部のルート・レベルでvaryおよびntblタイプ定義が定義されている場合は、testプロシージャを選択しても問題なく動作します。次の例に、コレクション・タイプ(Varrayおよびネストした表)についてサポートされている使用方法を示します。

SQL> create type vary as varray(10) of number;
SQL> create type ntbl as table of varchar2(10);
SQL> create package pkg as
   >   procedure test(v in vary, n in ntbl);
   > end;
   /

OBJECT定義もcomplexTypeとして生成されます。その順序には、OBJECTの各属性に1つの要素が保持されています。

次にOBJECTを示します。

SQL> CREATE TYPE FOO AS OBJECT (X VARCHAR2 (10), Y NUMBER);

これは、順序要素が2つあるFOOというcomplexType定義として表現されています。

<complexType name="FOO">
  <sequence>
    <element name="X" db:type="VARCHAR2" minOccurs="0" nillable="true"/>
      <simpleType>
        <restriction base="string">
          <maxLength value="10"/>
        </restriction>
      </simpleType>
    <element name="Y" type="decimal" db:type="NUMBER" minOccurs="0"
nillable="true"/>
  </sequence>
</complexType>

XMLファイルからの要素の削除を許可するため、minOccurs値は0です。これにより、OBJECTの対応する属性の値が実行時にNULLに設定されます。XMLファイルに空の要素を許可するためnillable値はtrueであり、要素の値がNULLであることを示すためにxsi:nil属性で注釈が付けられています。ここでも、db:index属性は使用されていません。

VARCHAR2属性の制限の使用に注意してください。OBJECTの属性の宣言から長さがわかります。

9.7.3.6 複雑なユーザー定義タイプ

ユーザー定義タイプは、必要に応じて複雑に定義できます。OBJECTには、前述の任意のユーザー定義タイプとして定義されているタイプの属性を含めることができます。これは、OBJECTの属性のタイプが別のOBJECT、VARRAYまたはネストされた表などになることを意味します。VARRAYまたはネストされた表のベース・タイプも、OBJECTになる可能性があります。コレクションのベース・タイプが別のコレクションになることを許可することで、多次元のコレクションがサポートされます。

9.7.3.7 オブジェクト・タイプの継承

アダプタ構成ウィザードでは、OBJECTタイプの継承を使用してタイプが定義されているパラメータの有効なXSDを生成できます。次のようなタイプの階層があるとします。

SQL> CREATE TYPE A AS OBJECT (A1 NUMBER, A2 VARCHAR2 (10)) NOT FINAL;
SQL> CREATE TYPE B UNDER A (B1 VARCHAR2 (10));

また、プロシージャにはタイプがBのパラメータXが含まれるとします。

SQL> CREATE PROCEDURE P (X IN B) AS BEGIN … END;

アダプタ構成ウィザードでは、パラメータXにInputParameters要素が次のように生成されます。

<element name="X" type="db:B" db:index="1" db:type="Struct" minOccurs="0" nillable="true"/>

ここで、XSDファイルのOBJECTタイプBの定義は、次に示すcomplexTypeとして生成されます。

<complexType name="B">
  <sequence>
    <element name="A1" type="decimal" db:type="NUMBER" minOccurs="0" nillable="true"/>
    <element name="A2" db:type="VARCHAR2" minOccurs="0"  nillable="true">
      ...
    </element>
    <element name="B1" db:type="VARCHAR2" minOccurs="0"  nillable="true">
      ...
    </element>
  </sequence>
</complexType>

属性A2およびB1の最大長の制限が適切に追加されています。OBJECTタイプの階層が、階層全体のすべての属性に対応する要素の単一の順序にフラット化されていることに注意してください。

9.7.3.8 オブジェクト参照

アダプタ構成ウィザードでは、OBJECTタイプへの参照(オブジェクト参照など)であるパラメータや、定義にオブジェクト参照が含まれるユーザー定義タイプのパラメータの有効なXSDも生成できます。次に例を示します。

SQL> CREATE TYPE FOO AS OBJECT (…);
SQL> CREATE TYPE BAR AS OBJECT (F REF FOO, …);
SQL> CREATE PROCEDURE PROC (X OUT BAR, Y OUT REF FOO) AS BEGIN … END;

アダプタ構成ウィザードでは、FOOおよびBARのcomplexType定義が前述したように生成されます。ただし、BARでは、属性の要素Fは次のように生成されます。

<element name="F" type="db:FOO" db:type="Ref" minOccurs="0" nillable="true"/>

ここで、typeおよびdb:type属性値は、FがOBJECTタイプFOOへの参照であることを示します。

プロシージャPROCでは、XSDファイルのOutputParametersルート要素に次の要素が生成されます。

<element name="X" type="db:BAR" db:index="1" db:type="Struct" minOccurs="0" nillable="true"/>
<element name="Y" type="db:FOO" db:index="2" db:type="Ref" minOccurs="0" nillable="true"/>

Yでは、db:type属性の値がRefになっています。type属性とともに、要素定義ではYがFOOへの参照であることが示されています。

オブジェクト参照の使用には、パラメータ・モードがOUTのみ限られる制限があることに注意してください。直接的なREFのAPI、またはパラメータ・タイプがユーザー定義の場合はそのタイプの定義にREFが含まれているAPIに、INまたはIN/OUTパラメータを渡すことはできません。

9.7.3.9 別のスキーマのタイプの参照

アクセスに必要な権限が付与されている場合には、別のスキーマに定義されているタイプを参照できます。たとえば、SCHEMA1でタイプOBJが宣言されたとします。

SQL> CREATE TYPE OBJ AS OBJECT (…);

SCHEMA2で宣言されているストアド・プロシージャのパラメータ・タイプを、SCHEMA1のタイプOBJにすることも可能です。

CREATE PROCEDURE PROC (O IN SCHEMA1.OBJ) AS BEGIN … END;

これは、SCHEMA1によりSCHEMA2にタイプOBJにアクセスする権限が付与された場合にのみ可能です。

SQL> GRANT EXECUTE ON OBJ TO SCHEMA2;

必要な権限が付与されていない場合には、SCHEMA2にプロシージャPROCの作成を試行するとエラーが発生します。

PLS-00201: identifier "SCHEMA1.OBJ" must be declared

権限が付与されていないので、SCHEMA1のOBJ型はSCHEMA2からは見えません。したがって、SCHEMA2はパラメータOの宣言においてこれを参照することはできません。

9.7.3.10 XSDプルーニングの最適化

一部のユーザー定義オブジェクト・タイプは、多数の属性を持つ場合があります。これらの属性は、同じく多数の属性を持つ他のオブジェクト・タイプによって定義することもできます。つまり、あるオブジェクト・タイプが、その定義の深さと複雑度によっては極端に大きくなる場合があります。

状況によっては、ラージ・オブジェクト・タイプの多数の属性が不要な場合もあります。したがって、これらの属性をオブジェクトのスキーマ定義からまとめて省略することが望ましい場合があります。そのためには、オブジェクト・タイプの定義から不要なXSD要素を物理的に削除します。

次の例を考えてみます。この例では、ストアド・プロシージャが複雑なユーザー定義型のパラメータを持っています。

SQL> CREATE TYPE OBJ AS OBJECT (A, NUMBER, B <SqlType>, C <SqlType>, ...);
SQL> CREATE PROCEDURE PROC (O OBJ) AS BEGIN ... END;

InputParametersルート要素には、APIのシグネチャからのパラメータOの単一要素が含まれます。complexType定義は、次のコード・スニペットに示すようにオブジェクト・タイプの生成XSDに追加されます。

<complexType name="OBJ">
  <sequence>
    <element name="A" type="decimal" db:type="NUMBER" minOccurs="0"  nillable="true"/>
    <element name="B" .../>
    <element name="C" .../>
    ...
  </sequence>
</complexType>

属性BおよびCが不要な場合は、OBJのcomplexType定義から対応する要素をタイプに関係なく削除できます。これらの属性の値は、インスタンスXMLでは不要です。パラメータOが出力パラメータだった場合、プルーニングされた属性に対応する要素も生成XMLでは省略されます。

パラメータAのタイプがユーザー定義オブジェクト・タイプでもあり、次の例に示すようにOBJの定義がそれに従って変更されたとします。

SQL> CREATE TYPE FOO AS OBJECT (X NUMBER, Y NUMBER, Z NUMBER);
SQL> CREATE TYPE OBJ AS OBJECT (A FOO, B <SqlType>, C <SqlType, ...);

その場合、APIに変更はありません。FOOの定義内で不要な属性に対応する要素も、そのタイプに関係なく削除できます。そのため、たとえばYが不要であれば、FOOのcomplexType定義内で対応する要素をXSDファイルから削除できます。

この方法でXSDファイルをプルーニングすると、アダプタの実行時パフォーマンスが向上し、メモリー使用量も大幅に削減できます。


注意:

プルーニングできるのは、ユーザー定義オブジェクト・タイプの属性のみです。対応する要素をInputParametersルート要素から削除することでストアド・プロシージャのパラメータをプルーニング(削除)することはできません。対応する要素を削除すると、パラメータにデフォルト句がない場合は実行時エラーになる可能性があります。

9.7.4 実行時: ストアド・プロシージャの起動前

この項では、ストアド・プロシージャのサポートに関する重要事項と、ストアド・プロシージャまたはファンクションの起動前に発生する動作に関する重要事項の概要を説明します。

この項には、次の項目が含まれます。

9.7.4.1 値のバインディング

XMLファイルからの値の抽出と、それらの値が実行時にどのように作用するかを検討します。タイプがサポートされているプリミティブ・データ型のいずれかであるパラメータ値に対応するXMLファイルのデータの場合、次の状況が想定されます。

  1. 要素の値が指定されています(<X>100</X>など、この例ではX=100)。

  2. 要素の値が指定されていません(<X/>など、この例ではX=NULL)。

  3. 値がNULLとして明示的に指定されています(<X xsi:nil="true"/>など、この例ではX=NULL)。

  4. 要素が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つのケースのそれぞれで実行されたとします。

  1. "BEGIN PROC (X=>?); END;" - X = 100

  2. "BEGIN PROC (X=>?); END;" - X = null

  3. 2つの可能性があります。

    1. "BEGIN PROC (); END;" - X = 0(Xにはデフォルト句がある)

    2. "BEGIN PROC (X=>?); END;" - X = null(Xにはデフォルト句がない)

デフォルト句の処理の例外で、これらの一般的なセマンティクスは、コレクションのアイテム値、またはタイプがサポートされているプリミティブ・データ型の1つであるOBJECTの属性値にも適用されます。ただし、タイプがユーザー定義の場合、<X/>のセマンティクスは大きく異なります。

コレクションの場合、次のタイプ定義だと仮定すると、VARRAYまたはネストされた表のいずれでも、後続の動作が予測されます。

SQL> CREATE TYPE ARRAY AS VARRAY (5) OF VARCHAR2 (10);

また、タイプがARRAYのパラメータXのXMLは次のようになります。

<X>
    <X_ITEM xsi:nil="true"/>
    <X_ITEM>Hello</X_ITEM>
    <X_ITEM xsi:nil="true"/>
    <X_ITEM>World</X_ITEM>
</X>

VARRAYの1つ目と3つ目の要素はNULLに設定されています。2つ目と4つ目には、それぞれの値が割り当てられています。XMLファイルでは5つ目の要素が指定されていないため、VARRAYインスタンスにある要素は4つのみです。

次のようなOBJECT定義であると仮定します。

SQL> CREATE TYPE OBJ AS OBJECT (A INTEGER, B INTEGER, C INTEGER);

また、タイプがOBJのパラメータXのXMLは次のようになります。

<X>
    <A>100</A>
    <C xsi:nil="true"/>
</X>

値100が属性Aに、NULLが属性BおよびCに割り当てられています。属性BのインスタンスXMLには要素がないため、NULL値が割り当てられています。

2つ目のケースでは、Xのタイプがユーザー定義の場合、<X/>の動作は異なります。XにNULLが割り当てられるのではなく、ユーザー定義タイプの初期化されたインスタンスが作成されてバインドされます。

前述のVARRAYの例では、<X/>または<X></X>が指定されている場合、Xにバインドされる値はVARRAYの空のインスタンスです。PL/SQLで、タイプ・コンストラクタを呼び出してXに値を割り当てるのと同等です。例:

X := ARRAY();

同様に、前述のOBJECTの例では、属性値すべてにNULLが割り当てられているOBJの初期化されたインスタンスは、Xにバインドされます。VARRAYのケースと同様に、タイプ・コンストラクタの呼出しと同等です。例:

X := OBJ(NULL, NULL, NULL);

Xのタイプがユーザー定義の場合にXに明示的にNULL値を割り当てるには、次のようにしてXMLファイルの要素にxsi:nil属性を追加します。

<X xsi:nil="true"/>

9.7.4.2 データ型の変換

この項では、CLOB、DATE、TIMESTAMPなどのデータ型、RAW、LONG RAW、BLOBなどのバイナリ・データ型、およびサード・パーティ・データベースでサポートされている類似のデータ型の変換について説明します。

Microsoft SQL Server、IBM DB2、AS/400およびMySQLでは、様々な書式のバイナリおよび日付データ型をストアド・プロシージャのパラメータにバインドする操作がサポートされています。これを表9-19にまとめます。

表9-19 サード・パーティ・データベース: バイナリ値および日付値とストアド・プロシージャのパラメータとのバインディング

XMLスキーマ型 IBM DB2のデータ型 AS/400のデータ型 Microsoft SQL Serverのデータ型 MySQLのデータ型

base64Binary

BLOB

CHAR FOR BIT DATA

VARCHAR FOR BIT DATA

BINARY

BINARY LARGE OBJECT

BINARY VARYING

BINARY

IMAGE

TIMESTAMP

VARBINARY

BINARY

TINYBLOB

BLOB

MEDIUMBLOB

LONGBLOB

VARBINARY

dateTime

DATE

TIME

TIMESTAMP

DATE

TIME

TIMESTAMP

DATETIME

SMALLDATETIME

DATE

DATETIME

TIMESTAMP

CLOBパラメータについては、CLOBパラメータの長さが4KB未満の場合、XMLファイルから抽出されたテキストが追加の処理なしでString型としてこのパラメータにバインドされます。CLOBパラメータの長さが4KBより大きい場合、またはこのパラメータのモードがIN/OUTの場合は、一時CLOBパラメータが作成されます。その後、CLOBが対応するパラメータにバインドされる前に、XMLファイルのデータが一時CLOBに書き込まれます。一時CLOBパラメータは相互作用が完了すると解放されます。CHARおよびVARCHAR2など、その他のキャラクタ・タイプの場合には、データが必要に応じて抽出されてバインドされます。XMLドキュメントはCLOBパラメータ(または、十分な大きさの場合にはVARCHAR2)にバインドできます。ただし、まず<、>などを適切に置き換える必要があります(たとえば、<は&lt;に、>は&gt;に)。

値を対応するパラメータにバインドする前に、特別な処理を必要とするデータ型がいくつかあります。たとえば、XMLスキーマ型base64BinaryおよびdateTimeで表されるデータ型などです。

XMLスキーマ型dateTimeは、TIME、DATEおよびTIMESTAMPを表しています。これは、これらのデータ型のXML値がdateTimeのXMLスキーマ表現に準拠する必要があることを意味します。そのため、単純なDATE文字列01-JAN-05は無効です。XMLスキーマでは、dateTimeはYYYY-MM-DDTHH:mm:ssとして定義されます。そのため、適切なDATE値は2005-01-01T00:00:00です。これらのパラメータの値は、この書式を使用してインスタンスXML内で指定する必要があります。

バイナリ・データ型のデータは、人間が理解できる方法で表現する必要があります。バイナリ・データの選択されたXMLスキーマ表現はbase64Binaryです。タイプ・コンバータでは、javax.mail.internet.MimeUtilityエンコードおよびデコードAPIを使用してバイナリ・データが処理されます。エンコードAPIは、すべてのバイナリ・データのbase64Binary形式へのエンコードに使用する必要があるため、XMLファイルでも使用できます。タイプ・コンバータでは、XMLデータのバイト配列へのデコードにデコードAPIが使用されます。base64Binaryデータのバイト配列への変換には、デコードAPIが使用されます。

BLOBパラメータについては、デコード値を含む長さが2KB未満である場合、バイト配列は追加の処理なしでそのパラメータにバインドされます。バイト配列の長さが2KBより大きい場合、またはパラメータのモードがIN/OUTの場合は、一時BLOBが作成されます。バイト配列はその後、対応するパラメータにバインドされる前に、BLOBに書き込まれます。一時BLOBは相互作用が完了すると解放されます。その他のバイナリ・データ型(RAWやLONG RAWなど)については、base64Binaryデータはバイト配列へとデコードされ、必要に応じてバインドされます。

その他のデータ型の変換は簡単なため、追加情報は必要ありません。

9.7.5 実行時: ストアド・プロシージャの起動後

プロシージャ(またはファンクション)を実行すると、任意のIN/OUTおよびOUTパラメータの値が取得されます。これらは、生成されたXSDのOutputParametersルート要素の要素値に対応します。

この項には、次の項目が含まれます。

9.7.5.1 データ型の変換

取得されたデータの変換は簡単です。ただし、サード・パーティ・データベースでサポートされている類似のデータ型の変換と同様に、CLOB(および他の文字データ)、RAW、LONG RAWおよびBLOBの変換には特別な注意が必要です。

CLOBが取得されると、そのCLOBのコンテンツ全体が生成されたXMLの対応する要素に書き込まれます。標準のDOM APIを使用してXMLファイルが構成されます。これは、CLOB、CHARおよびVARCHAR2などのタイプに関しては、必要な置換えを行うために文字データが必要であると伝達されたため、値は有効で後続の処理でXMLファイルに使用できることを意味します。そのため、たとえば、CLOBで保存されたXMLドキュメントの<および>の置換えが行われ、関連するパラメータの生成されたXML内の要素に使用された値は有効になります。

RAWおよびLONG RAWデータ型などのRAWデータは、バイト配列として取得されます。BLOBの場合、まずBLOBが取得され、そのコンテンツはバイト配列として取得されます。バイト配列は、javax.mail.internet.MimeUtilityエンコードAPIを使用してbase64Binary形式にエンコードされます。エンコードされた値は、すべて対応する要素のXMLファイルに配置されます。この値をバイト配列にデコードするには、MimeUtilityデコードAPIを使用する必要があります。

その他のデータ型の変換は簡単なため、追加情報は必要ありません。

9.7.5.2 NULL値

値がNULLの要素は、生成されたXMLでは空の要素として表示され、xsi:nil属性で注釈が付けられます。つまり、xsiネームスペースは生成されるXMLファイルで宣言されます。単一のOUTパラメータXがあり、値がNULLのプロシージャPROCの生成されたXMLは次のようになります。

<OutputParameters … xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <X xsi:nil="true"/>
</OutputParameters>

任意のタイプ(ユーザー定義タイプも含む)のパラメータのXML要素は、値がNULLの場合にはこのように表示されます。

9.7.5.3 ファンクションの戻り値

ファンクションの戻り値は、nameがファンクション自体の名前で、位置が0のOUTパラメータとして処理されます。例:

CREATE FUNCTION FACTORIAL (X IN INTEGER) RETURN INTEGER AS
BEGIN
    IF (X <= 0) THEN RETURN 1;
    ELSE RETURN FACTORIAL (X - 1);
    END IF;
END;

たとえば、値が5のこのファンクションの起動は、値が120になり、生成されたXMLのOutputParametersルート要素では<FACTORIAL>120</FACTORIAL>と表示されます。

9.7.6 実行時: サード・パーティ・データベースの共通機能

実行時のサード・パーティ・データベースの共通機能は、次のとおりです。

9.7.6.1 ResultSetsの処理

すべてのサード・パーティ・データベースは、ResultSetsの処理について同じ機能を共有しています。ResultSetを戻すAPIのSQL Serverの例を次に示します。

 1> create procedure foo ... as select ... from ...;
 2> go

生成されたXSDで定義されているRowSetはResultSetを表します。RowSetは、それぞれ1列以上を含む0(ゼロ)行以上で構成されます。行は問合せで戻される行に対応します。列は問合せの列項目に対応します。次の例に、前述の例に示したAPIの実行後に生成されたXMLを示します。

<RowSet>
  <Row>
    <Column name="<column name>" sqltype="<sql datatype">value</Column>
    ...
  </Row>
    ...
</RowSet>
…

name属性には問合せに表示される列の名前が格納されますが、sqltype属性にはその列のSQLデータ型(INTなど)が格納されます。valueは、その列の値となります。

APIでは複数のResultSetsが戻される場合があることに注意してください。その場合、RowSetは生成されたXML内のResultSetごとに1つずつとなります。生成されたXMLでは、すべてのRowSetsが常に先頭に表示されます。

9.7.6.2 INTEGERステータス値の戻し

一部のデータベースでは、ストアド・プロシージャでRETURN文を使用してINTEGERステータス値を戻すことができます。Microsoft SQL ServerとAS/400は、両方ともこの機能をサポートしています。いずれの場合も、アダプタ構成ウィザードでは、ストアド・プロシージャがステータス値を戻すかどうかを決定できません。このため、ストアド・プロシージャが値を戻すことを指定する必要があります。これはチェック・ボックスを使用して指定できます。

「ストアド・プロシージャ」ダイアログでストアド・プロシージャを選択すると、図9-49に示す「ストアド・プロシージャの指定」ページが表示されます。前述のチェック・ボックスはページの下部にあります。このチェック・ボックスを選択して、プロシージャにRETURN文を含めることを指定します。RETURN文が存在するかどうかを確認するには、プロシージャのソース・コードを表示します。

このチェック・ボックスは、この機能をサポートするデータベースのストアド・プロシージャに対してのみ表示されます。ファンクションに対しては、このチェック・ボックスは表示されません。ストアド・プロシージャによって戻された値は、生成されたXSDのOutputParametersルート要素内の要素として表示されます。要素の名前は、ストアド・プロシージャの名前になります。このチェック・ボックスを選択しない場合は、return文の値がストアド・プロシージャの実行後に消失します。

図9-49 「ストアド・プロシージャの指定」ページ

図9-49の説明が続きます
「図9-49 「ストアド・プロシージャの指定」ページ」の説明

9.7.7 高度なトピック

この項では、Oracleデータベース・アダプタで提供されているストアド・プロシージャ機能を使用して、直接にはサポートされていないタイプのシナリオについて説明します。次の項では、これらのデータ型を使用する必要がある場合に取り組む解決策を説明します。

9.7.7.1 強い型指定のXSDを使用した行セットのサポート

REF CURSORはどのような結果セットもサポートできるため、設計時に生成されるXSDは弱い型指定となります。

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

行セットはすべての結果セットを表現できますが、一部のプロシージャについては、結果セットの構造が毎回同じであることが想定できるため、強い型指定のXSDを使用して記述することも可能です。通常、後で結果セットを別のXSDに変換する場合は、強い型指定のXSDが必要となります。アダプタ構成ウィザードを使用して、REF CURSORに対して強い型指定のXSDを生成できます。

使用例において、弱い型指定のXSDで十分である場合は、第9.7.7.2項「弱い型指定のXSDを使用した行セットのサポート」を参照してください。

この項には、次の項目が含まれます。

詳細は、第9.3.3項「強い型指定のXSDまたは弱い型指定のXSDを使用した行セットのサポート」を参照してください。

9.7.7.1.1 設計時

選択したストアド・プロシージャまたはファンクションに、タイプがRowSetの出力パラメータが含まれる場合、このREF CURSORに対して強い型指定のXSDを次のように定義できます。

  1. アダプタ構成ウィザードを使用して、タイプがRowSetの出力パラメータを含むストアド・プロシージャまたはファンクションを選択します。

    第9.7.1.1項「最上位のスタンドアロンAPIの使用」のステップ1から8を参照してください。

  2. 「次へ」をクリックします。図9-50に示すように、「RowSets」ページが表示されます。

    デフォルトで、アダプタ構成ウィザードでは、「XSD」テキスト・フィールドに表示されるこのREF CURSORのための、弱い型指定のXSDが生成されます。図9-4は、このデフォルトの弱い型指定のXSDを示しています。

    図9-50 「RowSets」ページ

    図9-50の説明が続きます
    「図9-50 「RowSets」ページ」の説明

    例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>

  3. ストアド・プロシージャまたはファンクションの各引数に対して、次の手順を実行します。

    • 対応する「値」の列をダブルクリックします。

    • 引数に対して有効な値を入力します。

      数値や文字列を直接入力したり、日付をリテラルとして(2009/11/11など)入力したり、MYOBJ('a', 'b')のような構造体を入力します。

    • [Enter]を押します。


    注意:

    引数のタイプに対して有効であり、かつデータベース内に存在する値を選択する必要があります。

    適切なストアド・プロシージャまたはファンクションのシグネチャが確実に実行されるようにするために、すべての引数に対して値を指定することをお薦めします。

  4. 「イントロペクト」をクリックします。

    アダプタ構成ウィザードによって、指定した引数を使用するストアド・プロシージャまたはファンクションが実行されます。

    1. ストアド・プロシージャまたはファンクションによって少なくとも1行を含む行セットが返される場合、「RowSets」ページが更新され、「XSD」テキスト・フィールドに強い型指定のXSDが表示されます。例9-5に、例9-4に示すデフォルトの弱い型指定のXSDを置換する、強い型指定のXSDを示します。

      図9-51 「RowSets」ページ: 正常なイントロスペクション

      図9-51の説明が続きます
      「図9-51 「RowSets」ページ: 正常なイントロスペクション」の説明

      例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に進みます。

    2. 行が返されない場合、図9-52に示すように、「イントロスペクトに失敗しました」ダイアログが表示されます。

      図9-52 「イントロスペクトに失敗しました」ダイアログ

      図9-52の説明が続きます
      「図9-52 「イントロスペクトに失敗しました」ダイアログ」の説明

      アダプタ構成ウィザードでは、弱い型指定のXSDが生成され、デフォルトで「XSD」テキスト・フィールドに表示され、前のバージョンのXSDに対して行ったすべての編集が上書きされます。

      ステップ3に戻り、少なくとも1行を含む行セットを返すテスト引数値を入力します。

    3. ストアド・プロシージャまたはファンクションによって例外がスローされると、図9-53に示すように、イントロスペクション・エラー・ダイアログが表示されます。

      図9-53 イントロスペクション・エラー・ダイアログ

      図9-53の説明が続きます
      「図9-53 「イントロスペクション・エラー・ダイアログ」の説明

      アダプタ構成ウィザードでは、弱い型指定のXSDが生成され、デフォルトで「XSD」テキスト・フィールドに表示され、前のバージョンのXSDに対して行ったすべての編集が上書きされます。

      ステップ3に戻り、少なくとも1行を含む行セットを返すテスト引数値を入力します。

  5. 必要に応じて、「XSD」テキスト・フィールドに表示されるスキーマを手動で編集することによって、強い型指定のXSDを微調整します。

  6. 第9.7.1.1項「最上位のスタンドアロンAPIの使用」のステップ10に進みます。

9.7.7.1.2 実行時

次のパッケージがあるとします。

CREATE PACKAGE PKG AS
       TYPE REF_CURSOR IS REF CURSOR;
       PROCEDURE TEST(C OUT REF_CURSOR);
END;

CREATE PACKAGE BODY PKG AS
       ROCEDURE TEST(C OUT REF_CURSOR) AS
       BEGIN
           OPEN C FOR SELECT DEPTNO, DNAME FROM DEPT;
       END;
END;

アダプタ構成ウィザードを使用して強い型指定のXSDを定義し、プロシージャを実行した後、パラメータCについて次のXMLが生成されます。

<C>
    <C_Row>
        <DEPTNO>10</DEPTNO>
        <DNAME>ACCOUNTING</DNAME>
    </C_Row>
    <C_Row>
        <DEPTNO>11</DEPTNO>
        <DNAME>DEVELOPMENT</DNAME>
    </C_Row>
    …
</C>

実行時にOracleデータベース・アダプタを使用する場合、強い型指定のREF CURSORを記述するXSDがインライン化されるかインポートされるかは問題ではありません。

強い型指定のXSDがSOAランタイムによって適用され、Oracle Enterprise Managerコンソールの適切な場所に表示されます。たとえば、図9-54に、強い型指定のXSDを使用したREF CURSORペイロードを返すinvokeの監査証跡を示します。

図9-54 強い型指定のペイロードの監査証跡

図9-54の説明が続きます
「図9-54 強い型指定のペイロードの監査証跡」の説明

9.7.7.2 弱い型指定のXSDを使用した行セットのサポート

REF CURSORはどのような結果セットもサポートできるため、設計時に生成されるXSDは弱い型指定となります。デフォルトでは、アダプタ構成ウィザードによってREF CURSORに対して弱い型指定のXSDが生成されます。

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

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

使用例において、強い型指定のXSDがより適している場合は、第9.7.7.1項「強い型指定のXSDを使用した行セットのサポート」を参照してください。

この項には、次の項目が含まれます。

詳細は、第9.3.3項「強い型指定のXSDまたは弱い型指定のXSDを使用した行セットのサポート」を参照してください。

9.7.7.2.1 設計時

選択したストアド・プロシージャまたはファンクションに、タイプがResultSetである出力パラメータが含まれている場合は、このREF CURSORのための弱い型指定のXSDを次のように定義できます。

  1. アダプタ構成ウィザードを使用して、タイプがResultSetの出力パラメータを含むストアド・プロシージャまたはファンクションを選択します。

    第9.7.1.1項「最上位のスタンドアロンAPIの使用」のステップ1から8を参照してください。

  2. 「次へ」をクリックします。図9-55に示すように、「RowSets」ページが表示されます。

    デフォルトで、アダプタ構成ウィザードでは、「XSD」テキスト・フィールドに表示されるこのREF CURSORのための、弱い型指定のXSDが生成されます。

    図9-55 「RowSets」ページ

    図9-55の説明が続きます
    「図9-55 「RowSets」ページ」の説明

  3. 必要に応じて、「XSD」テキスト・フィールドに表示されるスキーマを手動で編集することによって、弱い型指定のXSDを微調整します。

  4. 第9.7.1.1項「最上位のスタンドアロンAPIの使用」のステップ10に進みます。

9.7.7.2.2 実行時

次のパッケージがあるとします。

CREATE PACKAGE PKG AS
       TYPE REF_CURSOR IS REF CURSOR;
       PROCEDURE TEST(C OUT REF_CURSOR);
END;

CREATE PACKAGE BODY PKG AS
       ROCEDURE TEST(C OUT REF_CURSOR) AS
       BEGIN
           OPEN C FOR SELECT DEPTNO, DNAME FROM DEPT;
       END;
END;

REF_CURSORは、問合せが指定されていないため弱い型指定のカーソル変数です。プロシージャの実行後、パラメータCについて次のXMLが生成されます。

<C>
    <Row>
        <Column name="DEPTNO" sqltype="NUMBER">10</Column>
        <Column name="DNAME" sqltype="VARCHAR2">ACCOUNTING</Column>
    </Row>
    <Row>
        <Column name="DEPTNO" sqltype="NUMBER">20</Column>
        <Column name="DNAME" sqltype="VARCHAR2">RESEARCH</Column>
    </Row>
    …
</C>

合計4行があり、各行が2つの列DEPTNOおよびDNAMEで構成されています。

REF CURSORは、Java ResultSetsで表されます。JDBCドライバで提供されるAPIを使用してResultSetをプログラムで作成することはできません。したがって、REF CURSORをストアド・プロシージャにINとして渡すことはできません。IN/OUTおよびOUTパラメータとしてのみ渡すことができますが、1つ注意点があります。IN/OUT REF CURSORは、OUTパラメータとしてのみ処理されます。IN/OUTパラメータではIN値を提供できないため、そのパラメータにはストアド・プロシージャの起動時にNULLがバインドされます。

9.7.7.3 PL/SQLブール、PL/SQLレコードおよびPL/SQL表タイプのサポート

アダプタ構成ウィザードには、これらのタイプが使用され、Oracle JPublisherが起動されて必要なラッパーが自動的に生成される時期を検出するメカニズムがあります。Oracle JPublisherでは、スキーマ・オブジェクトの生成用とその削除用の2つのSQLファイルが生成されます。スキーマ・オブジェクトを作成するSQLはアダプタ構成ウィザード内で自動的に実行され、XSDファイルが生成される前にデータベース・スキーマにスキーマ・オブジェクトが作成されます。たとえば、次のパッケージ仕様が宣言されたとします。

CREATE PACKAGE PKG AS
  TYPE REC IS RECORD (X NUMBER, Y VARCHAR2 (10));
  TYPE TBL IS TABLE OF NUMBER INDEX BY PLS_INTEGER;
  PROCEDURE PLSQL (R REC, T TBL, B BOOLEAN);
END;

図9-56に、PKGパッケージのPROCプロシージャが選択されると表示されるアダプタ構成ウィザードでの手順を示します。

図9-56 アダプタ構成ウィザードにおけるストアド・プロシージャの指定

ストアド・プロシージャの指定: ステップ6。
「図9-56 アダプタ構成ウィザードにおけるストアド・プロシージャの指定」の説明

図9-56に示すように、元のプロシージャ名は完全修飾され、PKG.PLSQLとなっています。パラメータ・タイプRはRECORDの名前です。タイプTはTABLEの名前です。タイプBはBooleanです。生成されているラッパー・パッケージの名前は、サービス名bpel_ServiceName(bpel_UseJPubなど)から導出されます。これは、生成されたパッケージの名前で、ラッパー・プロシージャが含まれています。チェック・ボックスは、スキーマ・オブジェクトの作成時に、アダプタ構成ウィザードで既存のパッケージの上書きを強制する際に使用できます。

図9-57に示すように、「次へ」をクリックすると、アダプタ構成ウィザードの「終了」ページが表示されます。

図9-57 データベース・アダプタ・サービスの定義: 「終了」ページ

図9-57の説明が続きます
「図9-57 データベース・アダプタ・サービスの定義: 「終了」ページ」の説明

このページのコンテンツでは、アダプタ構成ウィザードで検出されたものと、「終了」ボタンがクリックされると実行される処理が説明されます。次に、このページのコンテンツをまとめます。

  1. 生成されたWSDLの名前はUseJPub.wsdlです。

  2. JCAファイルの名前はUseJPub_db.jcaです。

  3. 2つのSQLスクリプトが作成され、BPELプロセス・プロジェクトに追加されます。

    1. BPEL_USEJPUB.sql: スキーマ・オブジェクトが作成されます。

    2. BPEL_USEJPUB_drop.sql: スキーマ・オブジェクトが削除されます。

  4. 生成されたXSDの名前はSCOTT_USEJPUB_PKG-24PLSQL.xsdです。

「終了」をクリックすると、Oracle JPublisherが起動され、SQLファイルが生成されてデータベースにスキーマ・オブジェクトがロードされます。ラッパーの生成プロセスは、完了に時間がかかります。初期ラッパーが同じパッケージ内の別のプロシージャに生成された後は、通常、同じパッケージに生成されるラッパーの処理時間は短くなります。


注意:

Oracleデータベース・アダプタを再作成するときには、BPEL_XXXX_drop.sqlを実行する必要があります。これは、キャッシュを使用してラッパーを生成するJPublisher機能に備えて実行します。

次に示すユーザー定義タイプは、PL/SQLタイプを元のプロシージャから置き換えるために生成されます。

SQL> CREATE TYPE PKG_REC AS OBJECT (X NUMBER, Y VARCHAR2 (10));
SQL> CREATE TYPE PKG_TBL AS TABLE OF NUMBER;

これらのタイプのネーミング規則は、OriginalPackageName_OriginalTypeNameです。Booleanは、ラッパー・プロシージャでINTEGERに置き換えられます。

現在はINTEGERである、元のBooleanパラメータの許容値は、FALSEが0でTRUEが0以外のINTEGER値です。1以外の値はfalseとみなされます。生成されたラッパー・プロシージャでは、SYS.SQLJUTLパッケージのAPIが使用され、INTEGERとBooleanが相互に変換されます。

PL/SQLタイプとユーザー定義タイプの相互変換を行う変換APIとともに、PKG$PPLSQLというプロシージャPLSQLのラッパーが含まれる、BPEL_USEJPUBという新しいラッパー・パッケージが作成されます。元のプロシージャがルートレベルのプロシージャの場合、生成されたラッパー・プロシージャの名前はTOPLEVEL$OriginalProcedureNameです。

生成されたXSDは、元のプロシージャではなく、ラッパー・プロシージャPKG$PLSQLのシグネチャを表します。XSDファイルの名前はURLエンコードされ、$が-24に置き換えられます。

生成された成果物のネーミング規則を示します。

  • サービス名は、WSDLおよびSQLファイルの名前に使用されます。ラッパー・パッケージの名前にも使用されます。

  • 生成されたXSDの名前は、スキーマ名、サービス名、および元のパッケージ名とプロシージャ名から導出されます。

  • SQLオブジェクトまたはコレクション・データ・タイプの名前は、元のパッケージ名および対応するPL/SQLタイプの名前から導出されます。

  • ラッパー・プロシージャの名前は、元のパッケージ名とプロシージャ名から導出されます。TOPLEVEL$は、ルートレベルのプロシージャに使用されます。

生成されたラッパー・パッケージの名前は30文字に制限されます。ラッパー・プロシージャの名前は29文字に制限されます。Oracle JPublisherで生成された名前がこれらの制限よりも長い場合は、切り捨てられます。

プロシージャに関連付けられたサービスに対応するPartnerLinkが起動されると、生成されたラッパー・プロシージャは元のプロシージャのかわりに実行されます。

9.7.7.3.1 ラッパー・プロシージャのデフォルト句

プロシージャにラッパーの生成を必要とする特殊な型が含まれている場合は、いずれのパラメータのデフォルト句もラッパーには持ち越されません。たとえば、次のようなプロシージャがあるとします。

SQL> CREATE PROCEDURE NEEDSWRAPPER (
        >     B BOOLEAN DEFAULT TRUE, N NUMBER DEFAULT 0) IS BEGIN … END;

これがルートレベルのプロシージャであると仮定すると、生成されるラッパー・プロシージャのシグネチャは次のようになります。

TOPLEVEL$NEEDSWRAPPER (B INTEGER, N NUMBER)

BooleanタイプがINTEGERに置き換えられています。生成されたラッパーには、どちらのパラメータのデフォルト句もありません。元のプロシージャにデフォルト句があったとしても、生成されるラッパー・プロシージャのパラメータには、デフォルト句はありません。

この例で、いずれかのパラメータの要素がインスタンスXMLに指定されていない場合、指定した引数の数が正しくないことを示すエラーが発生します。元のプロシージャに指定されているパラメータのデフォルト値は使用されません。

この問題に対応するには、デフォルト句をラッパー・プロシージャのパラメータにリストアして、ラッパーを作成する生成されたSQLファイルを編集する必要があります。その後、ラッパーおよびその他のスキーマ・オブジェクトをデータベース・スキーマにリロードする必要があります。SQLファイルの編集後、ラッパー・プロシージャのシグネチャは次のようになります。

TOPLEVEL$NEEDSWRAPPER (B INTEGER DEFAULT 1, N NUMBER DEFAULT 0)

Booleanパラメータの場合、trueのデフォルト値は1で、falseのデフォルト値は0です。

最後の手順として、ラッパーに生成されたXSDファイルを編集する必要があります。デフォルト句を持つパラメータを表す要素に、特別な属性を追加する必要があります。デフォルト句を持つパラメータを表す各要素にdb:default="true"を追加します。例:

<element name="B" … db:default="true" …/>
<element name="N" … db:default="true" …/>

この属性は、インスタンスXMLに要素がない場合、プロシージャ・コールから対応するパラメータを除外する必要があることを示すために実行時に使用されます。これらの要素のその他の属性は元のままです。

9.8 Oracleデータベース・アダプタの使用例

この項では、Oracleデータベース・アダプタとOracleデータベース・アダプタ: ストアド・プロシージャの使用例について説明します。

この項には、次の項目が含まれます。

9.8.1 Oracleデータベース・アダプタの使用例

Oracle Database Adapterの使用例を入手するには、Oracle SOA Sample Codeサイトにアクセスし、「Adapters」タブを選択します。

表9-20に、Oracle BPEL PMおよびメディエータで提供されているOracleデータベース・アダプタのサンプルを示します。

表9-20 Oracleデータベース・アダプタの使用例

チュートリアル名 説明

Delete

Oracleデータベース・アダプタのアウトバウンドのdelete操作を説明します。XMLレコードが操作に渡され、同じ主キーを持つデータベースの行が削除されます。

File2Table

カスタム形式で定義されているネイティブ(CSV)データの入力ファイルの使用方法を説明します。入力ファイルは注文書で、ファイル・アダプタによって処理され、FIle2Table BPELプロセスにXMLメッセージとして公開されます。メッセージは別の注文書形式に変換され、invokeアクティビティにルーティングされます。

Insert

Oracleデータベース・アダプタのアウトバウンドのinsert操作を説明します。XMLレコードは操作に渡され、リレーショナル・データとしてデータベースに挿入されます。(JDeveloper BPEL Designerでは、Merge(InsertまたはUpdate)が指定されます。)

InsertWithCatch

BPELプロセスへのフォルト処理の追加に必要な追加の手順(Insertチュートリアルに基づく)を説明します。

JPublisherWrapper

PL/SQL RECORDタイプの使用に関する解決策を説明します。JPublisherは、属性がRECORDのフィールドに一致する対応するOBJECT型、およびRECORDとOBJECTの相互変換を行う変換APIの作成に使用されます。また、JPublisherではOBJECTを許可し、両方向で変換APIを使用して基礎となるメソッドを起動するラッパー・プロシージャ(またはファンクション)が生成されます。起動されたメソッドが、(Oracle Liteではない)Oracleデータベースにインストールされている必要があります。

MasterDetail

一連の表から別の表へデータを移動する方法を説明します。サンプルでは、Oracleデータベース・アダプタを使用して、一連の表からデータを読み取って処理し、アダプタを使用して別のデータベース表に書き込みを行っています。

Merge

Oracleデータベース・アダプタのアウトバウンドのmerge操作を説明します。XMLレコードが操作に渡され、データベースの対応する行が挿入または更新されます。

PollingControlTableStrategy

MOVIES表からXMLインスタンスをポーリングするインバウンドのポーリング操作を説明します。MOVIES表に新しい行が挿入されると、ポーリング操作によりOracle BPEL PMに伝達されます。この計画では、まだ処理されていないすべての行の主キーの保存に制御表が使用されます。(主キーにより)制御表とソース表が自然結合しているため、制御表に対するポーリングは、実際にはソース表を直接ポーリングすることと同じです。

PollingLastReadIdStrategy

MOVIES表からXMLインスタンスをポーリングするインバウンドのポーリング操作を説明します。MOVIES表に新しい行が挿入されるたびに、ポーリング操作によりOracle BPEL PMに伝達されます。この計画では、順序値の保存にヘルパー表が使用されます。

PollingLastUpdatedStrategy

MOVIES表からXMLインスタンスをポーリングするインバウンドのポーリング操作を説明します。MOVIES表に新しい行が挿入されるたびに、ポーリング操作によりOracle BPEL PMに伝達されます。この計画では、last_updated値の保存にヘルパー表の使用が関連します。

PollingLogicalDeleteStrategy

MOVIES表からXMLインスタンスをポーリングするインバウンドのポーリング操作を説明します。MOVIES表に新しい行が挿入されるたびに、ポーリング操作によりOracle BPEL PMに伝達されます。この計画には、処理された各行の特別なフィールドの更新、および処理済の行を除外するための実行時のWHERE句の更新が関連します。

PureSQLPolling

日付フィールドに基づいて表をポーリングする方法を説明します。

PureSQLSelect

SELECT操作に任意で複雑なSQL文字列を指定する際に、JDeveloper BPEL DesignerのWHERE句ビルダーを使用しない方法を説明します。

QueryByExample

Oracleデータベース・アダプタのアウトバウンドのqueryByExample操作を説明します。SELECT SQL問合せは、サンプルのXMLレコードに設定されているフィールドに基づいて動的に作成され、一致するレコードが返されます。

RefCursors

強い型指定のXSDまたは弱い型指定のXSDを使用したREF CURSORを使用する方法について説明します。アダプタ構成ウィザードを使用して、Oracleデータベースのストアド・プロシージャまたはファンクションのREF CURSOR変数によって返される行セットのための、強い型指定のXSDを作成できます。詳細は、第9.3.3項「強い型指定のXSDまたは弱い型指定のXSDを使用した行セットのサポート」を参照してください。

ResultSetConverter

REF CURSORの使用に関する解決策を説明します。解決策には、対応するjava.sql.ResultSetをOBJECTの集合(VARRAYまたはNESTED TABLE)に変換するJavaストアド・プロシージャの使用が関連します。

SelectAll

Oracleデータベース・アダプタのアウトバウンドのSelectAll操作を説明します。WHERE句がない場合、MOVIES表のすべての行がXMLとして返されます。

SelectAllByTitle

Oracleデータベース・アダプタのアウトバウンドのSelectAllByTitle操作を説明します。選択されたタイトルのあるMOVIES表の行はXMLとして返されます。

Update

Oracleデータベース・アダプタのアウトバウンドのUpdate操作を説明します。XMLレコードが操作に渡され、同じ主キーを持つデータベースの行は更新されます。(JDeveloper BPEL Designerでは、Merge(InsertまたはUpdate)が指定されます。)

使用例の多くで使用されているMOVIES表の構造は、表9-3を参照してください。ほとんどのサンプルに含まれているreadme.txtファイルには、説明が記載されています。

9.8.2 Oracleデータベース・アダプタ: ストアド・プロシージャの使用例

この項には、次の項目が含まれます。

この項で説明する使用例の他に、Oracle SOA Sample Codeサイトにアクセスし、「Adapters」タブを選択してアクセスできるサンプルのOracleデータベース・アダプタ使用例も参照してください。

表9-21に、Oracle BPEL PMおよびメディエータで提供されているOracleデータベース・アダプタのストアド・プロシージャのサンプルを示します。

表9-21 Oracleデータベース・アダプタの使用例: ストアド・プロシージャ

チュートリアル名 説明

JPublisherWrapper

PL/SQL RECORDタイプの使用に関する解決策を説明します。JPublisherは、属性がRECORDのフィールドに一致する対応するOBJECT型、およびRECORDとOBJECTの相互変換を行う変換APIの作成に使用されます。また、JPublisherではOBJECTを許可し、両方向で変換APIを使用して基礎となるメソッドを起動するラッパー・プロシージャ(またはファンクション)が生成されます。起動されたメソッドが、(Oracle Liteではない)Oracleデータベースにインストールされている必要があります。

RefCursors

強い型指定のXSDまたは弱い型指定のXSDを使用したREF CURSORを使用する方法について説明します。アダプタ構成ウィザードを使用して、Oracleデータベースのストアド・プロシージャまたはファンクションのREF CURSOR変数によって返される行セットのための、強い型指定のXSDを作成できます。詳細は、第9.3.3項「強い型指定のXSDまたは弱い型指定のXSDを使用した行セットのサポート」を参照してください。

ResultSetConverter

REF CURSORの使用に関する解決策を説明します。解決策には、対応するjava.sql.ResultSetをOBJECTの集合(VARRAYまたはNESTED TABLE)に変換するJavaストアド・プロシージャの使用が関連します。

使用例の多くで使用されているMOVIES表の構造は、表9-3を参照してください。ほとんどのサンプルに含まれているreadme.txtファイルには、説明が記載されています。

9.8.2.1 JDeveloper BPELデザイナにおけるストアド・プロシージャの作成および構成

この使用例では、JDeveloper BPELデザイナを使用したBPEL Process Managerへのストアド・プロシージャの統合方法について説明します。

この使用例には、次の項目が含まれます。

9.8.2.1.1 前提条件

この使用例を実行するには、SCOTTスキーマ内で次のストアド・プロシージャを定義する必要があります。

SQL> CREATE PROCEDURE hello (name IN VARCHAR2, greeting OUT VARCHAR2) AS
  2  BEGIN
  3     greeting := 'Hello ' || name;
  4  END;
  5/
9.8.2.1.2 アプリケーションおよびSOAコンポジットの作成

SOAコンポジットを含んだJDeveloperアプリケーションを作成する必要があります。使用例のアプリケーションとプロジェクトを作成する手順は、次のとおりです。

  1. JDeveloperの「アプリケーション・ナビゲータ」で、「新規アプリケーション」をクリックします。

    「汎用アプリケーションの作成 - アプリケーションの名前付け」ページが表示されます。

  2. 「アプリケーション名」フィールドにMyHelloAppと入力して「次へ」をクリックします。

    「汎用アプリケーションの作成 - プロジェクトの名前付け」ページが表示されます。

  3. 「プロジェクト名」フィールドにHelloProjectと入力します。

  4. 「プロジェクト・テクノロジ」タブの「選択可能」リストで「SOA」をダブルクリックし、「選択済」リストに移動します。

  5. 「次へ」をクリックします。

    「汎用アプリケーションの作成 - SOA設定の設定」ページが表示されます。

  6. 「コンポジット・テンプレート」ボックスで「BPELを使用するコンポジット」を選択して「終了」をクリックします。「BPELプロセスの作成」ページが表示されます。

  7. 「名前」フィールドにGreetと入力し、「テンプレート」ボックスから「同期BPELプロセス」を選択します。

  8. 「OK」をクリックします。

    図9-58に示すように、MyHelloAppのHelloProject内のGreet BPELプロセスが設計領域に表示されます。

    図9-58 JDeveloper: composite.xml

    図9-58の説明が続きます
    「図9-58 JDeveloper: composite.xml」の説明

9.8.2.1.3 アウトバウンドOracleデータベース・アダプタ・サービスの作成

次の手順に従ってアウトバウンドOracleデータベース・アダプタ・サービスを作成します。

  1. 「コンポーネント・パレット」から、「データベース・アダプタ」を「外部参照」スイムレーンにドラッグ・アンド・ドロップします。

    アダプタ構成ウィザードの「ようこそ」ページが表示されます。

  2. 「次へ」をクリックします。

    「サービス名」ページが表示されます。

  3. 「サービス名」フィールドにHelloと入力します。

  4. 「次へ」をクリックします。

    「サービス接続」ページが表示されます。


    注意:

    このアプリケーションをデプロイする前に、weblogic-ra.xmlファイル内でJNDI名を構成していることを確認してください。

    詳細は、第2.19.1項「データソースの作成」および第2.21項「Oracle JCAアダプタで使用するデータソースの推奨設定」を参照してください。

  5. 「新規データベース接続を作成します。」アイコンをクリックします。

    「データベース接続の作成」ダイアログが表示されます。

  6. 「データベース接続の作成」ダイアログで次の詳細を入力します。

    1. 「接続名」フィールドに接続名を入力します。たとえば、Myconnectionと入力します。

    2. 接続タイプとして「Oracle (JDBC)」を選択します。

    3. ユーザー名およびパスワードとしてscott/tigerと入力します。

    4. 「ホスト名」フィールドにホスト名を入力し、「JDBCポート」フィールドにJDBCポートを入力します。

    5. 「SID」を選択してSID名を入力します。または、「サービス名」を選択してサービス名を入力します。

    6. 「接続のテスト」をクリックします。「ステータス」ペインに成功メッセージが表示されます。

    7. 「OK」をクリックします。

    「接続」フィールドにMyConnection接続が移入され、「JNDI」フィールドにeis/DB/MyConnectionが移入されます。

  7. 「次へ」をクリックします。

    「操作タイプ」ページが表示されます。

  8. 「ストアド・プロシージャまたはファンクションの呼出し」を選択して、「次へ」をクリックします。

    「ストアド・プロシージャの指定」ページが表示されます。

  9. 「参照」をクリックします。「ストアド・プロシージャ」ペインでHELLOを選択します。

    「引数」タブにストアド・プロシージャのパラメータが表示され、「ソース」タブにストアド・プロシージャのソース・コードが表示されます。

  10. 「OK」をクリックします。

    「ストアド・プロシージャの指定」ページが表示されます。「プロシージャ」フィールドにHELLOストアド・プロシージャが移入され、HELLOストアド・プロシージャの引数も表示されます。

  11. 「次へ」をクリックします。

    「詳細オプション」ページが表示されます。

  12. 任意の追加の詳細オプションを指定して、「次へ」をクリックします。

    アダプタ構成ウィザードの「終了」ページが表示されます。

  13. 「終了」をクリックします。

    「パートナ・リンクの作成」ダイアログ・ボックスが表示されます。パートナ・リンク名は、サービス名と同じHelloです。

  14. 「OK」をクリックします。

    アウトバウンドOracleデータベース・アダプタが構成され、Greet BPELプロセスが表示されます。

9.8.2.1.4 invokeアクティビティの追加

次の手順に従ってinvokeアクティビティを追加します。

  1. 「コンポーネント・パレット」から、invokeアクティビティを設計領域のreceiveInputアクティビティとreplyOutputアクティビティの間にドラッグ・アンド・ドロップします。

  2. invokeアクティビティをダブルクリックします。

    「Invokeの編集」ダイアログが表示されます。

  3. 「名前」フィールドにInputと入力します。

  4. 「Invoke」ボックスで、「入力変数」フィールドの右にある「入力変数の自動作成」アイコンをクリックします。

    「変数の作成」ダイアログが表示されます。

  5. デフォルトの変数名を選択して「OK」をクリックします。

    「入力変数」フィールドにデフォルトの変数名が移入されます。「Invoke」ダイアログが表示されます。

  6. 同じ手順を繰り返して、「出力変数」フィールドで出力変数を選択します。

    「Invokeの編集」ダイアログの「変数」セクションに、入力変数名と出力変数名が表示されます。

  7. 「OK」をクリックします。

    図9-59に示すように、Helloパートナ・リンクに接続された右矢印付きの線が表示されます。

    図9-59 「Greet.bpel」ページ

    図9-59の説明が続きます
    「図9-59 「Greet.bpel」ページ」の説明

9.8.2.1.5 リクエスト・メッセージのメッセージ・パートの変更

リクエストのペイロードがInputParametersと一致する場合、すべてのINパラメータがリクエストに含まれます。この例では、INパラメータはnameのみです。

次の手順に従って、GreetRequestMessageメッセージのメッセージ・パートを変更します。

  1. Greet BPELプロセスの「構造」ペイン(「アプリケーション」ペインの下)で、「メッセージ・タイプ」、「プロセスWSDL - Greet.wsdl」および「GreetRequestMessage」を順番に開きます。

  2. 「payload」を選択して「編集」アイコンをクリックします。

    「メッセージ・パートの編集 - payload」ダイアログが表示されます。

  3. 「要素」を選択して「検索」アイコンをクリックします。

    「タイプ・チューザ」ダイアログが表示されます。

  4. 「プロジェクトのスキーマ・ファイル」と「SCOTT_HELLO.xsd」を順番に開き、「InputParameters」を選択します。

  5. 「OK」をクリックします。

    「メッセージ・パートの編集 - payload」ダイアログが表示されます。

  6. 「OK」をクリックします。

9.8.2.1.6 レスポンス・メッセージのメッセージ・パートの変更

レスポンスのペイロードがOutputParametersと一致する場合、すべてのOUTパラメータがレスポンスに含まれます。この例では、OUTパラメータはgreetingのみです。

GreetResponseMessageメッセージ・パートに関する手順はGreetRequestMessageの場合と同じですが、次の例外があります。

  1. 「GreetResponseMessage」メッセージ・タイプを開き、「payload」を選択します。

  2. 「タイプ・チューザ」ダイアログで「SCOTT_HELLO.xsd」を開き、「OutputParameters」を選択します。

  3. 「OutputParameters」を選択します。

9.8.2.1.7 入力変数のassignアクティビティの追加

次の手順に従って入力変数のassignアクティビティを追加します。

  1. 「コンポーネント・パレット」から、assignアクティビティを設計領域のreceiveInputおよびGreetというinvokeアクティビティの間にドラッグ・アンド・ドロップします。

  2. assignアクティビティをダブルクリックします。

    「Assign」ダイアログが表示されます。

  3. 「一般」をクリックし、「名前」フィールドで名前をNAMEに変更します。

  4. 「コピー操作」タブでプラス・アイコンをクリックし、表示された操作リストから「コピー操作」を選択します。

    「コピー操作の作成」ダイアログが表示されます。

  5. 「From」領域で、「変数」、「inputVariable」および「payload」を順番に開いて「ns2:InputParameters」を選択します。

  6. 「To」領域で、「変数」、「Input_Hello_InputVariable」および「InputParameters」を順番に開いて「ns2:InputParameters」を選択します。

  7. 「OK」をクリックします。

    入力パラメータへの値の割当てを完了しました。

    図9-60に示すように、「Assign」ダイアログが表示されます。このダイアログには、inputVariableのペイロードからInput_Hello_InputVariableのペイロードへの割当てが表示されます。

    図9-60 「コピー操作の作成」ダイアログ

    図9-60の説明が続きます
    「図9-60 「コピー操作の作成」ダイアログ」の説明

  8. 「ファイル」、「すべて保存」を順番にクリックします。

9.8.2.1.8 出力変数のassignアクティビティの追加

2つ目のassignアクティビティでは、出力パラメータに値を割り当てます。

出力パラメータに値を割り当てる手順は、入力パラメータに値を割り当てる場合と同じですが、次の例外があります。

  1. 「コンポーネント・パレット」から、assignアクティビティを設計領域のGreet invokeアクティビティとreplyOutputアクティビティの間にドラッグ・アンド・ドロップします。

  2. assignアクティビティをダブルクリックします。

    「Assign」ダイアログが表示されます。

  3. 「名前」フィールドにGreetingと入力します。

  4. 「コピー操作」タブでプラス・アイコンをクリックし、表示された操作リストから「コピー操作」を選択します。

    「コピー操作の作成」ダイアログが表示されます。

  5. 図9-61に示すように、「From」ペインで「Input_Hello_OutputVariable」および「OutputParameters」を順番に開いて「ns2:OutputParameters」を選択します。

  6. 図9-61に示すように、「To」ペインで「outputVariable」および「payload」を順番に開いて「ns2:OutputParameters」を選択します。

    図9-61 「コピー操作の作成」ダイアログ

    図9-61の説明が続きます
    「図9-61 「コピー操作の作成」ダイアログ」の説明

  7. 「OK」をクリックします。

    出力パラメータへの値の割当てを完了しました。

  8. 「ファイル」、「すべて保存」を順番にクリックします。

    BPELプロセスのモデル化を完了しました。図9-62に示すように、最終的なBPELプロセスが表示されます。

    図9-62 最終的なBPELプロセスの画面

    図9-62の説明が続きます
    「図9-62 最終的なBPELプロセスの画面」の説明

9.8.2.1.9 JDeveloperを使用したデプロイ

前述の手順で作成したSOAプロジェクトおよびアプリケーションについて、アプリケーション・プロファイルをデプロイする必要があります。JDeveloperを使用してアプリケーション・プロファイルをデプロイするには、次の手順に従います。

  1. 第2章の「Oracle JCAアダプタ用のアプリケーション・サーバー接続の作成」で説明されている手順を使用して、アプリケーション・サーバー接続を作成します。

  2. 第2.8項「Oracle JDeveloperからのOracle JCAアダプタ・アプリケーションのデプロイ」で説明されている手順を使用して、アプリケーションをデプロイします。

9.8.2.1.10 Oracle WebLogic Server管理コンソールでのデータソースの作成

HelloProjectをテストする前に、Oracle WebLogic Server管理コンソールを使用してデータソースを作成する必要があります。

手順は次のとおりです。

  1. Webブラウザにhttp://<hostname>:<port>/consoleと入力します。

  2. ユーザー名とパスワードを入力して「ログイン」をクリックします。

    管理コンソールが表示されます。

  3. 「JDBC」の下の「サービス」領域で「データ・ソース」をクリックします。

    「JDBCデータ・ソースの概要」が表示されます。

  4. 「新規作成」をクリックします。

    「新しいJDBCデータ・ソースの作成」ページが表示されます。

  5. 「新しいJDBCデータ・ソースの作成」ページで、次の詳細を入力します。

    • 「名前」フィールドにMyDataSourceと入力します。

    • 「JNDI名」フィールドにjdbc/MyDataSourceと入力します。

    • 「データベースのタイプ」はOracleです。

    • 「データベース・ドライバ」は、Oracle's Driver (Thin XA) for Instance Connections; Versions 9.0.1, 9.2.0, 10, 11です。

  6. 「次へ」をクリックします。

    別のトランザクション構成オプションはないことを示すメッセージが表示されます。

  7. 「次へ」をクリックします。

    「新しいデータ・ソースの作成」ページが表示されます。

  8. 次の詳細を入力します。

    • データベース名: 通常はSIDです。

    • ホスト名: ホスト・コンピュータ名を入力します。

    • ポート番号: ポート番号を入力します。

      デフォルト・ポートは1521です。

    • データベース・ユーザー名: SCOTTと入力します。

    • パスワード: TIGERと入力します。

    • パスワードの確認: TIGERと入力します。

  9. 「次へ」をクリックします。

    データソース構成の概要が表示されます。

  10. 「構成のテスト」をクリックします。

    「メッセージ」領域に、接続テストに成功したことが示されます。

  11. 「次へ」をクリックします。「AdminServer」チェック・ボックスを選択してターゲットとして選択します。

  12. 「終了」をクリックします。

    これで、前述の手順で作成したMyDataSourceデータソースがJDBCデータソースの概要に含まれます。

9.8.2.1.11 Fusion Middleware Controlコンソールを使用した監視

Fusion Middleware Controlコンソールを使用して、デプロイ済のSOAコンポジットを監視できます。次の手順を実行します。

  1. http://servername:portnumber/emにナビゲートします。前述の手順で作成したHelloProject[1.0]を含めて、SOAコンポジットのリストが表示されます。

  2. 「HelloProject[1.0]」リンクをクリックします。図9-63に示すように、「ダッシュボード」タブが表示されます。

    図9-63 HelloProject[1.0]プロジェクトの「ダッシュボード」タブ

    図9-63の説明が続きます
    「図9-63 HelloProject[1.0]プロジェクトの「ダッシュボード」タブ」の説明

  3. 「テスト」をクリックします。新規のブラウザ・ウィンドウが表示されます。

  4. xsd:stringでマーク付けされている「NAME」フィールドに名前を入力し、「呼出し」をクリックします。

    ブラウザ・ウィンドウにテスト結果が表示されます。

  5. 読取り可能な書式のXMLファイルを表示するには、「フォーマット済XML」をクリックします。図9-64に、フォーマット済XMLファイルを示します。

    図9-64 フォーマット済XMLファイル

    図9-64の説明が続きます
    「図9-64 フォーマット済XMLファイル」の説明

9.8.2.2 ファイルからストアド・プロシージャへの使用例

この使用例では、Oracleストアド・プロシージャの実行について説明します。ストアド・プロシージャへの入力は、ファイル・アダプタを使用してファイルを読み取ることで取得されます。ストアド・プロシージャが実行されると、表に入力パラメータからのデータが移入されます。

adapter-db-101-file2storedprocedure使用例を入手するには、Oracle SOA Sample Codeサイトにアクセスし、「Adapters」タブを選択します。

この使用例には、次の項目が含まれます。

9.8.2.2.1 前提条件

ファイルからストアド・プロシージャへの使用例を実行するには、JDeveloperを使用してBPELコンポジットをモデル化する前に、次のスキーマ・オブジェクトとストアド・プロシージャをSCOTT/TIGERスキーマ内で定義する必要があります。

create type address as object
(
  street varchar2(20),
  city   varchar2(15),
  state  char(2),
  zip    char(5)
);
create type customer as object
(
  fname varchar2(10),
  lname varchar2(10),
  loc   address,
  email varchar2(25),
  phone varchar2(15)
);
create type collection as table of customer;
create table customers
(
  name  varchar2(25),
  loc   varchar2(45),
  email varchar2(25),
  phone varchar2(15)
);
create procedure add_customers(c in collection) as
begin
  for i in c.first .. c.last loop
    insert into customers values (
      c(i).lname || ', ' || c(i).fname,
      c(i).loc.street || ', ' || c(i).loc.city || ', ' || c(i).loc.state || ' ' ||
 c(i).loc.zip,
      c(i).email,
      c(i).phone    );
  end loop;
end;

これらのスキーマ・オブジェクトとストアド・プロシージャは、Oracle SOA Sample Codeサイトにアクセスし、「Adapters」タブを選択してアクセスできるadapters-db-101-file2storedprocedureサンプルのadapters-db-101-file2storedprocedure/artifacts/sql/customers.sqlファイルを使用して定義できます。

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

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

  1. JDeveloperを開きます。

  2. 「アプリケーション・ナビゲータ」で、「新規アプリケーション」をクリックします。「汎用アプリケーションの作成 - アプリケーションの名前付け」ページが表示されます。

  3. 「アプリケーション名」フィールドにFile2SPAppと入力します。

  4. 「アプリケーション・テンプレート」リストで、「汎用アプリケーション」を選択します。

  5. 「次へ」をクリックします。

    「汎用アプリケーションの作成 - プロジェクトの名前付け」ページが表示されます。

  6. 「プロジェクト名」フィールドにわかりやすい名前を入力します。たとえば、File2SPProjectと入力します。

  7. 「プロジェクト・テクノロジ」タブの「選択可能」リストで「SOA」をダブルクリックし、「選択済」リストに移動します。

  8. 「次へ」をクリックします。「汎用アプリケーションの作成 - SOA設定の設定」ページが表示されます。

  9. 「コンポジット・テンプレート」リストから「BPELを使用するコンポジット」を選択して「終了」をクリックします。

    新規アプリケーションおよびSOAプロジェクトが作成されました。これにより、SOAコンポジットが自動的に作成されます。

    「BPELプロセスの作成」ページが表示されます。

  10. 「名前」フィールドにBPELプロセスの名前を入力します。たとえば、File2SPと入力します。

  11. 「テンプレート」リストで「サービスを後で定義」を選択し、「OK」をクリックします。

    File2SPAppのFile2SPProject内のFile2SP BPELプロセスが設計領域に表示されます。

9.8.2.2.3 アウトバウンドOracleデータベース・アダプタ・サービスの作成

次の手順に従ってアウトバウンドOracleデータベース・アダプタ・サービスを作成します。

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

  2. 「次へ」をクリックします。「サービス名」ページが表示されます。

  3. 「サービス名」フィールドにFile2SPServiceと入力します。

  4. 「次へ」をクリックします。

    「サービス接続」ページが表示されます。

  5. 「新規データベース接続を作成します。」アイコンをクリックします。

    「データベース接続の作成」ダイアログが表示されます。

  6. 「データベース接続の作成」ダイアログで次の詳細を入力します。

    1. 「接続名」フィールドに接続名を入力します。たとえば、MyConnectionと入力します。

    2. 接続タイプとして「Oracle (JDBC)」を選択します。

    3. ユーザー名およびパスワードとしてscott/tigerと入力します。

    4. 「ホスト名」フィールドにホスト名を入力し、「JDBCポート」フィールドにJDBCポートを入力します。

    5. 「SID」を選択してSID名を入力します。または、「サービス名」を選択してサービス名を入力します。

    6. 「接続のテスト」をクリックします。「ステータス」ペインに成功メッセージが表示されます。

    7. 「OK」をクリックします。

    「接続」フィールドにMyConnection接続が移入され、「JNDI」フィールドにeis/DB/MyConnectionが移入されます。

  7. 「次へ」をクリックします。

    「アダプタ・インタフェース」ページが表示されます。

  8. 「アダプタ・インタフェース」ページで、「操作およびスキーマから定義(後で指定)」を選択し、「次へ」をクリックします。

    「操作タイプ」ページが表示されます。

  9. 図9-65に示すように、「ストアド・プロシージャまたはファンクションの呼出し」を選択して「次へ」をクリックします。

    「ストアド・プロシージャの指定」ページが表示されます。

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

    図9-65の説明が続きます
    「図9-65 「アダプタ構成ウィザード - 操作タイプ」ページ」の説明

  10. 「参照」をクリックします。「ストアド・プロシージャ」ペインでADD_CUSTOMERSを選択します。

    「引数」タブにストアド・プロシージャのパラメータが表示され、「ソース」タブにストアド・プロシージャのソース・コードが表示されます。

  11. 「OK」をクリックします。

    「ストアド・プロシージャの指定」ページが表示されます。

    「プロシージャ」フィールドにADD_CUSTOMERSストアド・プロシージャが移入され、ADD_CUSTOMERSストアド・プロシージャの引数も表示されます。

  12. 「次へ」をクリックします。

    「詳細オプション」ページが表示されます。

  13. 任意の追加のオプションを指定して、「次へ」をクリックします。

    「終了」ページが表示されます。

  14. 「終了」をクリックします。

    「パートナ・リンクの作成」ダイアログが表示されます。

    パートナ・リンク名は、サービス名と同じFile2SPServiceです。

  15. 「OK」をクリックします。

    アウトバウンドOracleデータベース・アダプタが構成され、File2SP BPELプロセスが表示されます。

9.8.2.2.4 invokeアクティビティの作成

invokeアクティビティを作成してBPELプロセスを完成する必要があります。これにより、入力変数が作成されます。

次の手順に従ってinvokeアクティビティを作成します。

  1. 「ファイル」、「すべて保存」を順番にクリックします。

  2. 「コンポーネント・パレット」から設計領域にinvokeアクティビティをドラッグ・アンド・ドロップします。

  3. invokeアクティビティの右にある右矢印をドラッグし、File2SPServiceパートナ・リンクに接続します。

    「Invokeの編集」ダイアログが表示されます。

  4. 「名前」フィールドにInvokeと入力します。

  5. 「Invoke」ダイアログで、「入力変数」フィールドの右にある「入力変数の自動作成」アイコンをクリックします。

    「変数の作成」ダイアログが表示されます。

  6. デフォルトの変数名を選択して「OK」をクリックします。

    「Invokeの編集」ダイアログの「変数」領域に入力変数名が表示されます。

  7. 「OK」をクリックします。

    File2SPServiceパートナ・リンクに接続されている右矢印付きの線が表示されます。

9.8.2.2.5 インバウンド・ファイル・アダプタ・サービスの作成

次の手順に従ってインバウンド・ファイル・アダプタ・サービスを作成します。これにより、ファイル・ディレクトリから入力XMLを読み取るサービスが作成されます。

  1. 「コンポーネント・パレット」から、「ファイル・アダプタ」を「外部参照」スイムレーンにドラッグ・アンド・ドロップします。

    アダプタ構成ウィザードの「ようこそ」ページが表示されます。

  2. 「次へ」をクリックします。「サービス名」ページが表示されます。

  3. 「サービス名」フィールドにReadCustomersと入力します。

  4. 「次へ」をクリックします。

    「アダプタ・インタフェース」ページが表示されます。

  5. 「操作およびスキーマから定義(後で指定)」を選択し、「次へ」をクリックします。「操作」ページが表示されます。

  6. 操作タイプとして「Read File」を選択し、操作名として「Read」を選択します。他のチェック・ボックスは選択しないでください。

  7. 「次へ」をクリックします。

    「ファイル・ディレクトリ」ページが表示されます。

  8. 「物理パス」を選択して、「着信ファイル用のディレクトリ(物理パス)」フィールドに物理パスを入力します。

  9. 「ファイルを再帰的に処理します」および正常な配信後にファイルを削除を選択して、「次へ」をクリックします。

    「ファイルのフィルタ処理」ページが表示されます。

  10. 「ファイル・ワイルドカード(po*.txt)」を指定して、customers.xmlを「インクルード・ファイルの名前パターン」フィールドに入力し、次に、「次へ」をクリックします。

    「ファイル・ポーリング」ページが表示されます。

  11. 「ポーリング頻度」フィールドで任意の値を指定して「次へ」をクリックします。

    「メッセージ」ページが表示されます。

  12. 「URL」フィールドの端に表示される「スキーマ・ファイルを参照」をクリックします。

    「タイプ・チューザ」ダイアログが表示されます。

  13. 「プロジェクトのスキーマ・ファイル」、「SCOTT_ADD_CUSTOMERS.xsd」および「InputParameters」を順番にクリックします。

  14. 「OK」をクリックします。

    「メッセージ」ページが再表示されます。URLはxsd/SCOTT_ADD_CUSTOMERS.xsdで、「スキーマ要素」はInputParametersとなっています。

  15. 「次へ」をクリックします。

    「終了」ページが表示されます。

  16. 「終了」をクリックします。

    インバウンド・ファイル・アダプタ・サービスが終了します。

  17. 「OK」をクリックしてパートナ・リンクを完了します。

  18. 「ファイル」、「すべて保存」を順番にクリックします。

9.8.2.2.6 receiveアクティビティの追加

ファイル・アダプタ・サービスはreceiveアクティビティに入力を提供し、receiveアクティビティは残りのBPELプロセスを開始します。

次の手順に従ってreceiveアクティビティを追加します。

  1. 「File2SP」をダブルクリックします。「File2SP.bpel」ページが表示されます。

  2. 「コンポーネント・パレット」から設計領域にreceiveアクティビティをドラッグ・アンド・ドロップします。

  3. receiveアクティビティの左にある左矢印をドラッグし、ReadCustomersパートナ・リンクに接続します。

    「Receiveの編集」ダイアログが表示されます。

  4. 「名前」フィールドにReceiveと入力します。

  5. 「Receiveの編集」ダイアログで、「変数」フィールドの右にある「入力変数の自動作成」アイコンをクリックします。

    「変数の作成」ダイアログが表示されます。

  6. デフォルトの変数名を選択して「OK」をクリックします。

    「変数」フィールドにデフォルトの変数名が移入されます。

  7. 「インスタンスの作成」を選択して「OK」をクリックします。JDeveloperの「File2SP.bpel」ページが表示されます。

    receiveアクティビティを追加した後、図9-66に示すようにJDeveloperウィンドウが表示されます。

    図9-66 receiveアクティビティの追加

    図9-66の説明が続きます
    「図9-66 receiveアクティビティの追加」の説明

  8. 「ファイル」、「すべて保存」を順番にクリックします。

9.8.2.2.7 assignアクティビティの追加

次に、入力パラメータに値を割り当てる必要があります。

次の手順に従ってassignアクティビティを追加します。

  1. 「コンポーネント・パレット」から、assignアクティビティを設計領域のreceiveアクティビティとinvokeアクティビティの間にドラッグ・アンド・ドロップします。

  2. assignアクティビティをダブルクリックします。

    「Assign」ダイアログが表示されます。

  3. 「一般」をクリックし、「名前」フィールドでCUSTOMERをクリックします。

  4. 「コピー操作」タブをクリックします。

    図9-67に示すように、「Assign」ダイアログが表示されます。

    図9-67 「Assign」ダイアログ: 「コピー操作」タブ

    図9-67の説明が続きます
    「図9-67 「Assign」ダイアログ: 「コピー操作」タブ」の説明

  5. 図9-67に示すように、プラス・サイン付きのアイコンをクリックして「コピー操作」を選択します。

    「コピー操作の作成」ダイアログが表示されます。

  6. 「From」領域で、「プロセス」、「変数」、「Receive_Read_InputVariable」および「body」を順番に開きます。

  7. 「ns3:InputParameters」を選択します。

  8. 「To」領域で、「プロセス」、「変数」、「Invoke_File2SPService_InputVariable」および「InputParameters」を順番に開きます。

  9. 「ns3:InputParameters」を選択します。

  10. 「OK」をクリックします。図9-68に示すように、「Assign」ダイアログが表示されます。

    図9-68 「Assign」ダイアログ

    図9-68の説明が続きます
    「図9-68 「Assign」ダイアログ」の説明

  11. 「OK」をクリックします。

    図9-69に示すように、JDeveloperの「File2SP.bpel」ページが表示されます。

    図9-69 JDeveloper: File2SP.bpel

    図9-69の説明が続きます
    「図9-69 JDeveloper: File2SP.bpel」の説明

  12. 「ファイル」、「すべて保存」を順番にクリックします。

9.8.2.2.8 サービスとアクティビティのワイヤリング

作成した3つのコンポーネント(インバウンド・アダプタ・サービス、BPELプロセスおよびアウトバウンド・アダプタ参照)をアセンブルまたは接続する必要があります。コンポーネントを接続する手順は、次のとおりです。

  1. 「公開されたサービス」領域にあるReadCustomer内の小さい三角形を、「コンポーネント」領域のBPELプロセス内に緑の三角形として表示されるドロップ・ゾーンにドラッグします。

  2. 「コンポーネント」領域にあるBPELプロセス内の小さい三角形を、「外部参照」領域のFile2SPService内に緑の三角形として表示されるドロップ・ゾーンにドラッグします。

  3. 「ファイル」、「すべて保存」を順番にクリックします。

9.8.2.2.9 JDeveloperを使用したデプロイ

前述の手順で作成したSOAプロジェクトおよびアプリケーションについて、アプリケーション・プロファイルをデプロイする必要があります。JDeveloperを使用してアプリケーション・プロファイルをデプロイするには、次の手順に従います。

  1. 第2章の「Oracle JCAアダプタ用のアプリケーション・サーバー接続の作成」で説明されている手順を使用して、アプリケーション・サーバー接続を作成します。

  2. 第2.8項「Oracle JDeveloperからのOracle JCAアダプタ・アプリケーションのデプロイ」で説明されている手順を使用して、アプリケーションをデプロイします。

9.8.2.2.10 データソースの作成

File2SPProjectをテストする前に、Oracle WebLogic Server管理コンソールを使用して、次の手順でデータソースを作成する必要があります。

  1. http://servername:portnumber/consoleにナビゲートします。

  2. 必要な資格証明を使用して、Oracle WebLogic Server管理コンソールのホーム・ページを開きます。

    図9-70に示すように、Oracle WebLogic Server管理コンソールのホーム・ページが表示されます。

    図9-70 Oracle WebLogic Server管理コンソールのホーム・ページ

    図9-70の説明が続きます
    「図9-70 Oracle WebLogic Server管理コンソールのホーム・ページ」の説明

  3. 「ドメイン構造」で、「サービス」、「JDBC」を選択し、「データ・ソース」をクリックします。

    図9-71に示すように、「JDBCデータ・ソースの概要」ページが表示されます。

    図9-71 「JDBCデータ・ソースの概要」ページ

    図9-71の説明が続きます
    「図9-71 「JDBCデータ・ソースの概要」ページ」の説明

  4. 「新規作成」をクリックします。

    「新しいJDBCデータ・ソースの作成」ページが表示されます。

  5. 新しいJDBCデータソースの識別に使用するプロパティについて次の値を入力します。

    • 「名前」フィールドにMyDataSourceと入力します。

    • 「JNDI名」フィールドにjdbc/MyDataSourceと入力します。

    • 「データベースのタイプ」にはデフォルト値のOracleを保持します。

    • 「データベース・ドライバ」には、デフォルト値のOracle's Driver (Thin XA) for Instance Connections; Versions 9.0.1, 9.2.0, 10, 11を保持します。

  6. 「次へ」をクリックします。

    「新しいJDBCデータ・ソースの作成 - トランザクション・オプション」ページが表示されます。他のトランザクション構成オプションがないことを示すメッセージが表示されます。

  7. 「次へ」をクリックします。

    「新しいJDBCデータ・ソースの作成 - 接続プロパティ」ページが表示されます。

  8. 「接続プロパティ」ページで、次の接続プロパティを入力します。

    • 「データベース名」フィールドに名前(通常はSID)を入力します。

    • 「ホスト名」フィールドにホスト名を入力します。

    • 「ポート」フィールドにポート番号を入力します。

    • 「データベース・ユーザー名」フィールドにSCOTTと入力します。

    • 「パスワード」フィールドにTIGERと入力します。

    • 「パスワードの確認」フィールドにTIGERと入力します。

  9. 「次へ」をクリックします。「新しいJDBCデータ・ソースの作成 - データベース接続のテスト」ページが表示されます。

  10. 「構成のテスト」をクリックし、データベースの可用性および指定した接続プロパティをテストします。「新しいJDBCデータ・ソースの作成 - データベース接続のテスト」ページの上部に「接続テストが成功しました。」という内容のメッセージが表示されます。

  11. 「次へ」をクリックします。

    「新しいJDBCデータ・ソースの作成 - ターゲットの選択」ページが表示されます。

  12. ターゲットとして「AdminServer」を選択し、「終了」をクリックします。

    「JDBCデータ・ソースの概要」ページが表示されます。このページには、このドメインに作成されているJDBCデータソース・オブジェクトがまとめられています。このリストには、作成したデータソースが表示されます。

9.8.2.2.11 接続インスタンスの追加

データベース・アダプタには、データソースを指すインスタンス・エントリが必要です。

次の手順に従って接続インスタンスを追加します。

  1. beahome/でDbAdapter.rarを検索します。

  2. ファイルを解凍します。

  3. 次の例に示すように、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>

  4. JNDI名と同じデータベース接続名MyConnectionを使用します。

  5. xADataSourceNameと同じデータソース名MyDataSourceを使用します。

  6. このファイルから再びJARを作成します。

  7. アプリケーション・サーバーを再起動します。

    新規データベース・アダプタ・インスタンスは、Oracle WebLogic Server管理コンソールを使用して作成することもできます。

9.8.2.2.12 ファイル・アダプタ・サービスとSQL*Plusを使用したテスト

ファイル・アダプタの入力ファイルを用意して、BPELプロセスをテストする必要があります。BPELプロセスの結果は、表からの単純な問合せを使用して表示されます。customers.xmlファイルには、次の入力が含まれています。

<InputParameters xmlns="http://xmlns.oracle.com/pcbpel/adapter/db/SCOTT/ADD_CUSTOMERS/">
  <C>
    <C_ITEM>
      <FNAME>John</FNAME>
      <LNAME>Doe</LNAME>
      <LOC>
        <STREET>123 Main Street</STREET>
        <CITY>Anytown</CITY>
        <STATE>CA</STATE>
        <ZIP>12345</ZIP>
      </LOC>
      <EMAIL>john.smith@gmail.com</EMAIL>
      <PHONE>567-123-9876</PHONE>
    </C_ITEM>
    <C_ITEM>
      <FNAME>Jane</FNAME>
      <LNAME>Doe</LNAME>
      <LOC>
        <STREET>987 Sunset Blvd</STREET>
        <CITY>Sometown</CITY>
        <STATE>CA</STATE>
        <ZIP>34567</ZIP>
      </LOC>
      <EMAIL>JaneDoe@yahoo.com</EMAIL>
      <PHONE>567-123-9876</PHONE>
    </C_ITEM>
  </C>
</InputParameters>

次の手順に従って、作成したBPELプロセスをテストします。

  1. customers.xmlのコピーを、インバウンド・ファイル・アダプタ・サービスの作成時に指定した入力ディレクトリに置きます。

  2. Oracleファイル・アダプタにより新規ファイルについてディレクトリがポーリングされます。ファイル・アダプタ・サービスによりファイルが受信されると、receiveアクティビティによりBPELプロセスが開始されます。

  3. すべての顧客に関するデータは、ストアド・プロシージャのInputParametersに割り当てられます。

  4. ストアド・プロシージャが実行されます。各顧客のデータが変換され、顧客データが表に挿入されます。

  5. 表を問い合せると、次の結果が表示されます。

    SQL> select * from customers;

NAME                      LOC
------------------------- ---------------------------------------------
EMAIL                     PHONE
------------------------- ---------------
Doe, John                 123 Main Street, Anytown, CA 12345
john.smith@gmail.com      567-123-9876

Doe, Jane                 987 Sunset Blvd, Sometown, CA 34567
JaneDoe@yahoo.com         567-123-9876
9.8.2.2.13 Fusion Middleware Controlコンソールを使用した監視

Fusion Middleware Controlコンソールを使用して、デプロイ済のEMコンポジットを監視できます。次の手順を実行します。

  1. http://servername:portnumber/emにナビゲートします。

    前述の手順で作成したFile2SPProject[1.0]を含めて、SOAコンポジットのリストが表示されます。

  2. 「File2SPProject[1.0]」をクリックします。

    「ダッシュボード」が表示されます。「最新のインスタンス」領域で「インスタンスID」の値をメモします。

  3. 「インスタンス」タブをクリックします。

    「検索」ダイアログが表示されます。デフォルトの検索では、すべてのインスタンスがインスタンスIDで表示されます。

  4. 前述の「インスタンスID」を選択します。

    新規ウィンドウが開きます。フォルトがあればそれ(または「フォルトが見つかりません」)が表示され、インスタンスの「監査証跡」を表示できます。インスタンスのトレースが新規ウィンドウに表示されます。

  5. インスタンス・ツリーは、「ReadCustomers」(サービス)、「File2SP」(BPELコンポーネント)、「File2SPService」(参照)へと順番に開かれています。

  6. 「File2SP」 BPELコンポーネントをクリックします。

    プロセスの「監査証跡」が表示されます。

  7. 図9-72に示すように、「<payload>」ノードを開いて、ストアド・プロシージャに提供された入力を確認します。

    図9-72 「監査証跡」タブ

    図9-72の説明が続きます
    「図9-72 「監査証跡」タブ」の説明

  8. さらに、図9-73に示すように、「フロー」タブをクリックしてプロセス・フローを表示します。

    図9-73 プロセス・フローの表示

    図9-73の説明が続きます
    「図9-73 プロセス・フローの表示」の説明

  前
前 		 次
次
  目次へ移動
目次		 索引へ移動
索引