4 Oracle Application Server Adapter for Databases

この章では、Oracle BPEL Process ManagerおよびOracle Enterprise Service Busと連携して機能するOracle Application Server Adapter for Databases（データベース・アダプタ）について説明します。ストアド・プロシージャおよびファンクション（Oracleデータベースのみ）のサポートについても説明します。データベース・アダプタおよびストアド・プロシージャの使用例も参照できます。

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

第4.1項「データベース・アダプタの概要」
第4.2項「データベース・アダプタの説明」
第4.3項「Oracle BPEL Process Managerでのデータベース・アダプタの使用例」
第4.4項「Oracle Enterprise Service Busでのデータベース・アダプタの使用例」
第4.5項「高度な構成」
第4.6項「サード・パーティJDBCドライバとデータベース接続の構成」
第4.7項「ストアド・プロシージャおよびファンクションのサポート」
第4.8項「JDeveloper BPEL Designerにおけるストアド・プロシージャの作成および構成の使用例」

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

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

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

データベース・アダプタの機能
設計の概要
データベース・アダプタとOracle BPEL Process Managerの統合
データベース・アダプタとOracle Enterprise Service Busの統合

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

データベース・アダプタは、任意のリレーショナル・データベースと接続できます。非リレーショナル・データベースやレガシー・システムの場合は、アプリケーション・アダプタおよびメインフレーム・アダプタを使用できます。アプリケーションおよびメインフレーム用のアダプタの詳細は、『Oracle Application Server Adapter概要』を参照してください。

既存のリレーショナル・スキーマにアクセスするには、アダプタ構成ウィザードを使用して次の手順を実行します。

リレーショナル・スキーマをインポートしXMLスキーマ（XSD）としてマップ

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

詳細は、「WebサービスとしてのSQL操作」を参照してください。

BPELプロセスによりXMLが処理されてWebサービスが起動される間、データベース行と値の問合せ、挿入および更新が行われます。固定スキーマ、ストアド・プロシージャ、ストリームまたは問合せによるデータへのアクセス方法が提供されているその他のソリューションとは異なり、データベース・アダプタでは、直接的かつ透過的に表データにアクセスできます。

データベース・アダプタには次の特徴があります。

オープン・スタンダードに準拠。データベース・アダプタはJCA 1.5コネクタの実装です。Oracle BPEL Process Managerと連携するその他のアダプタ同様、データベース・アダプタはBPEL、WSIFおよびWSDLなどのオープン・スタンダードに準拠しています。
JDBC、またはSun JdbcOdbcBridgeを使用したODBCを介する、任意のリレーショナル（SQL 92）データベースへの接続性。
既存のリレーショナル・スキーマのXMLへのマップ機能。マッピングによるスキーマへの影響はなく、スキーマに変更を加える必要はありません。
SQL操作のWebサービス抽出。生成されるWSDL操作は、merge、insert、update、write、delete、select、queryByExampleおよびインバウンド・ポーリングです。インバウンド・ポーリングには、物理削除、論理削除および順序付けベースのポーリング計画が含まれます。
TopLinkテクノロジを利用した、オブジェクトからリレーショナルへの高度な永続フレームワーク。基礎となるTopLinkプロジェクトにアクセスし、TopLink Workbenchインタフェースを使用して、高度なマッピングと構成、順序付け、バッチおよび結合されたリレーションシップの読取り、バッチ書込み、パラメータ・バインディング、文のキャッシュ、接続プーリング、外部トランザクション制御（JTSおよびJTA）、最小更新用のUnitOfWork、キャッシング、オプティミスティック・ロック、詳細な問合せのサポートおよび例示問合せを実行できます。
任意のsqlの実行。

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

Oracle BPEL Process Managerフォーラム

http://forums.oracle.com/forums/forum.jsp?forum=212

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

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

http://www.oracle.com/technology

4.1.1.1 複数の表の問合せ

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

リレーションシップの問合せを使用する方法（TopLinkのデフォルト）
オリジナルのselectを利用する方法（TopLinkのバッチ属性読取り）
単一結果セットを戻す方法（TopLinkの結合属性読取り）

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

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

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

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

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

このサンプルはマスターごとに次のようになります。

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

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

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

オリジナルの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では、これらのマッピングすべてにデフォルトでこのプロパティが設定されています。

単一結果セットを戻す方法（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列の値が次のように戻されます。

（マスターの列数＋ディテールの列数×マスター1行に対するディテールの行数）=
（     100    +       2      x             100            ）  =  300

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

Master                                                                    Detail

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

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

（（マスターの列数＋ディテールの列数）×マスター1行に対するディテールの行数）=
（（    100     +      2     ） x             100             ）=  10,200

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

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

        （Masterの列数＋Detail1の列数＋Detail2の列数＋...） ×
                Master1行に対するDetail1の行数×
                Master1行に対するDetail2の行数×...
膨張度＝_________________________________________________________________________

       （Masterの列数＋Detail1の列数×Master1行に対するDetail1の行数＋
               Detail2の列数×Master1行に対するDetail2の行数＋...）

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

               (2 + 100) x 4        408
膨張度 =        ____________  = ___________  ~=  1
               (2 + 100 x 4)        402

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

構成

たとえば、MoviesにmovieReviewsCollectionという1-M属性を設定して、MoviesおよびMovieReviewsをインポートしたとします。これを構成する手順は、次のとおりです。

BPELプロジェクトで、「アプリケーション・ソース」を選択して「TopLink」をクリックします。
「構造」パネルで「Movies」をクリックし、「movieReviewsCollection」をダブルクリックします。

「バッチ読取りの使用」チェック・ボックスを含むビューが表示されます。デフォルトでは、このボックスは有効化されます。バッチ属性読取り（SQLの変更）を無効化するには、このチェック・ボックスの選択を解除する必要があります。

1-1関係の場合は、「バッチ読取りの使用」オプションの下に「結合の使用」オプションも表示されることがあります。これは単一の結果セットを戻す場合に類似していますが、次のような重要な違いがあります。

設定は、query/wsdl操作ごとではなく属性ごとです。
この設定を使用できるのは1-1属性の場合のみです。
この設定では内部結合が実行されます。つまり、DetailのないMasterがあると、そのMasterはオリジナルのselect文からフィルタで除外されます。

単一の結果セットを戻すように構成するには、wsdlを編集し、次のようにタイプDBActivationSpecまたはDBReadInteractionSpecのjca操作ごとにプロパティReturnSingleResultSet="true"を追加します。

<operation name="SelectAllByTitleServiceSelect_title">
            <jca:operation
                InteractionSpec="oracle.tip.adapter.db.DBReadInteractionSpec"

                DescriptorName="SelectAllByTitle.Movies"
                QueryName="SelectAllByTitleServiceSelect"
                ReturnSingleResultSet="true"
                MappingsMetaDataURL="toplink_mappings.xml" />
            <input/>
        </operation>

この設定により、オリジナルのselect（バッチ属性読取り）文の変更がオーバーライドされます。

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

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

ユーザー定義SQLの変更

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

SQLの表示

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

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

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

4.1.2 設計の概要

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

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

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

データベース・アダプタは独立したJCA 1.5コネクタです。インストール時にアプリケーション・サーバーにデプロイされ、oc4j-ra.xmlを使用して構成されます。oc4j-ra.xmlファイルは、Oracle Application Server用のデータベース・アダプタのデプロイメント・ディスクリプタ・ファイルです。

oc4j-ra.xmlの各エントリには、Java Naming and Directory Interface（JNDI）名（場所）およびセッションとログインのプロパティがあり、単一のデータベースおよびデータベース・アダプタ・インスタンスを表しています。コネクタはアプリケーション・サーバーに関連付けられているため、単独で使用できますが、oc4j-ra.xmlを変更するにはアプリケーション・サーバーを再起動する必要があります。このファイルは、Oracle BPEL Serverが始めて起動される際に、アプリケーション・サーバーによって作成されます。そのため、スタンドアロンのインストールでは、少なくとも一度Oracle BPEL Serverを起動するまではこのファイルは表示されません。

Oracle BPEL Process Managerでビジネス・プロセスが実行されると、（WSIFを使用して）データベースに対してWebサービス（WSDL）が起動されます。WSDLのjca:addressタグはアダプタ・インスタンスの検索に使用され、WSDLのjca:operationタグは、JCAインタフェースを使用したデータベース・アダプタでの相互作用（アウトバウンド）またはアクティブ化（インバウンド）の設定に使用されます。 jca:operationタグには、XMLデータとリレーショナル・スキーマ間の通信の問合せを実行するための、TopLinkメタデータへのリンクが含まれます。

toplink_mappings.xmlファイルおよびWSDL（カスタムのjca:operationおよびjca:addressタグ付き）は設計時に作成されます。JDeveloper BPEL Designerで、データベースと通信するためのエンドポイントまたはパートナ・リンクを作成します。各パートナ・リンクにはそれぞれのWSDLがあります。WSDLには、データベースで実行可能なすべての操作（問合せ）が定義されています。

WSDLを作成するには、アダプタ構成ウィザードを使用します。ウィザードでリレーショナル・スキーマをインポートし、XMLスキーマにマップして1つ以上の操作を定義します。これにより、スキーマを表すXSDとtoplink_mappings.xmlファイルが作成されます。

「アダプタ構成ウィザード」により、TopLink Workbenchプロジェクト（.mwpファイル）がJDeveloper BPEL Designerプロジェクトの一部として作成されます。 JDeveloper BPEL Designerの.jprファイルと同様に、遡って視覚的にマッピングを変更することや、TopLinkを利用して高度なプロパティを設定することが可能です。MWPプロジェクトを保存してもtoplink_mappings.xmlは再生成されません。編集モードで、再度ウィザードの最初からやりなおす必要があります。（最初からやりなおすのみで、変更する必要はありません。）

デプロイ中、toplink_mappings.xmlのコピーはBPELスーツケースに含められます。後でデータベース・アダプタが読み取り、メタデータがキャッシュされます。

データベース・アダプタは、リレーショナルからXMLへのマッピングに使用されるため、Javaクラス・ファイルは不要です。データベース・アダプタにより、ディスクリプタの情報に基づいてメモリー内のクラスにバイトコードが生成されます。データベース・アダプタを使用している間は、クラス・ファイルのコンパイルやクラスパスの問題の処理は行いません。JDeveloper BPEL DesignerプロジェクトのMWPプロジェクトでは、ウィザードを使用すると副産物としてJavaファイルが作成されますが、設計時以外は不要です。

4.1.3 データベース・アダプタとOracle BPEL Process Managerの統合

J2CA 1.5リソース・アダプタとBPEL Process Managerを双方向で統合するために、アダプタ・フレームワークが使用されています。アダプタ・フレームワークは規格に準拠しており、基盤となるJ2CA相互作用をWebサービスとして公開するためのWeb service Invocation Framework（WSIF）テクノロジが使用されています。

データベース・アダプタのアーキテクチャ、Oracle BPEL Process Managerとのアダプタの統合、およびアダプタのデプロイの詳細は、『Oracle Application Server Adapter概要』を参照してください。

4.1.4 データベース・アダプタとOracle Enterprise Service Busの統合

Oracle Enterprise Service BusサーバーはOracleアダプタをサポートしており、それぞれのインバウンドおよびアウトバウンドのアダプタ・サービスを定義できます。インバウンド・アダプタ・サービスでは、外部データソースからデータが受信されてXMLメッセージに変換されます。アウトバウンド・アダプタ・サービスでは、XMLメッセージが特定のアダプタのネイティブ・フォーマットに変換され、データがターゲット・アプリケーションに送信されます。

Oracle Enterprise Service Busサーバーを使用すると、Oracle Database表から抽出したメッセージまたはストアド・プロシージャを実行して作成したメッセージを送受信できます。

ESBはBPELの後継であり、このマニュアルのほとんどの部分およびサンプルはBPELを使用することを想定しています。ただし、アダプタの動作はBPELでもESBでも同じです。ここでBPELに言及している箇所は、ESBで置き換えてかまいません。

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

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

リレーショナルからXMLへのマッピング
WebサービスとしてのSQL操作

「リレーショナルからXMLへのマッピング」に含まれる高度なトピックについては、「高度な構成」の「リレーショナルからXMLへのマッピング（toplink_mappings.xml）」を参照してください。

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

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

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

表4-1 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）は次のとおりです。

<xs:complexType name="Movies">
  <xs:sequence>
    <xs:element name="director" type="xs:string" minOccurs="0" nillable="true"/>
    <xs:element name="genre" type="xs:string" minOccurs="0" nillable="true"/>
    <xs:element name="rated" type="xs:string" minOccurs="0" nillable="true"/>
    <xs:element name="rating" type="xs:string" minOccurs="0" nillable="true"/>
    <xs:element name="releaseDate" type="xs:dateTime" minOccurs="0" nillable="true"/>
    <xs:element name="runTime" type="xs:double" minOccurs="0" nillable="true"/>
    <xs:element name="starring" type="xs:string" minOccurs="0" nillable="true"/>
    <xs:element name="status" type="xs:string" minOccurs="0" nillable="true"/>
    <xs:element name="synopsis" type="xs:string" minOccurs="0" nillable="true"/>
    <xs:element name="title" type="xs:string"/>
    <xs:element name="totalGross" type="xs:double" minOccurs="0" nillable="true"/>
    <xs:element name="viewerRating" type="xs:string" minOccurs="0" nillable="true"/>
  </xs:sequence>
</xs:complexType>

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

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

表4-2 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)`

表4-3 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では循環が許可されていないため、要素はそれ自体を含むことはできません。これはデータベース・アダプタにより自動的に処理されます。ただし、重複の可能性があります（つまり、異なるマスター・レコードで、同じXMLディテール・レコードが2回以上出現するということです）。たとえば、問合せで同じ部門で働く2人の従業員が返された場合、返されたXMLではどちらのEMPレコードにも同じDEPTレコードがインラインで出現します。

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

<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つは、ディテール・レコードを完全に元に戻すのではなく、外部キーを元に戻すことで十分な場合にのみ適切です。

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

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

表4-4 データベースのデータ型の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、USER DEFINED、OBJECT、STRUCT、VARRAYおよびREF型は明確にサポートされていません。

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

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

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

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

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

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

アウトバウンド起動操作の使用例
ポーリング計画の使用例

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

DML操作
ポーリング計画

4.2.2.1 DML操作

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

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

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

Merge

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

querybyExample

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

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

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

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

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

Input 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_Home\bpel\samples\tutorials\122.DBAdapter

注意:

DBアウトバウンド・アダプタ・サービスを定義する際には、サービスに指定するJNDI値が次のファイルで宣言されていることを確認してください。

j2ee\home\application-deployments\default\DBAdapter\oc4j-ra.xml

アウトバウンド・アダプタ・サービスでは、oc4j_ra.xmlに定義されているxADataSource定義を使用してデータソースがルックアップされます。 JNDI値がoc4j_ra.xmlに定義されていなければ、データベース・アダプタではXAトランザクションをサポートしていない非管理データソースが使用されます。

Pure SQLでの使用例

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

UpdateAll
SelectCount
SelectGroupBy
SelectStar

これらのファイルを参照するには、次の場所へ移動します。

Oracle_Home\bpel\samples\tutorials\122.DBAdapter

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

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

InsertWithClobs
XAInsert
NativeSequencingInsert

これらのファイルを参照するには、次の場所へ移動します。

Oracle_Home\bpel\samples\tutorials\122.DBAdapter\advanced\dmlInvoke

4.2.2.2 ポーリング計画

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

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

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

注意:

データベースに複数のレコードを挿入しようとすると、DBWriteInteractionSpec Execute Failed例外がスローされます。この例外の解決策を次に示します。

次のbpel/system/config/collaxa-config.xml設定を介して再試行回数をチューニングできます。

<property id="nonFatalConnectionMaxRetry">
        <name>Non fatal connection retry limit</name>
        <value>2</value>
        <comment>
        <![CDATA[The maximum number of times a non-fatal connection
error can be retried before failing. Non-fatal connections errors
may be thrown when the dehydration store is a RAC installation and
the node the application server is pointing to is shutdown. The
engine will resubmit messages that failed as a result of the
connection error.
        <p/>
        The default value is 2.
        ]]>
        </comment>
</property>

この値を相当大きい値に増やすと、この例外を回避できます。

この項では、次に示すポーリング計画と、特定の状況でどの計画を採用するかの判断基準を説明します。

物理削除
論理削除
順序表: 最終読取りID
順序表: 最終更新
制御表

物理削除

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

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

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

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

注意:

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

同時ポーリングは、削除ポーリング計画と論理削除ポーリング計画のどちらにも構成できます。

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

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

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

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

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

<operation name="receive">
   <jca:operation
      ActivationSpec="oracle.tip.adapter.db.DBActivationSpec"
         …      PollingStrategyName="DeletePollingStrategy"
      DeleteDetailRows="true"

論理削除

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

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

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

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

注意:

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

更新のポーリング: トリガーの追加

子の更新のポーリング: トリガーの追加

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

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

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

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

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

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

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

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

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

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

<operation name="receive">
   <jca:operation
      ActivationSpec="oracle.tip.adapter.db.DBActivationSpec"
         …
      PollingStrategyName="LogicalDeletePollingStrategy"
      MarkReadField="STATUS"
      MarkUnreadValue="UNPROCESSED"
      MarkReservedValue="RESERVED-1"
      MarkReadValue="PROCESSED"

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

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

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

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

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

順序表: 最終読取りID

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

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

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

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

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

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

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

<operation name="receive">
<jca:operation
ActivationSpec="oracle.tip.adapter.db.DBActivationSpec"
…
PollingStrategyName="SequencingPollingStrategy"
SequencingFieldName="MODIFIED_DATE"
SequencingFieldType="java.sql.Date"
SequencingTableNameFieldValue="EMPLOYEE"
SequencingTableName="SEQUENCING_HELPER"
SequencingTableNameFieldName="TABLE_NAME"
SequencingTableValueFieldName="LAST_READ_DATE"

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

データベース構成: 指定されたデータベースに対して、順序付け表を一度構成する必要があります。複数のプロセスで同じ表を共有できます。前述の例で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列があるため、この計画は変更を伴わないポーリングに使用されます。処理済の行のフィールドをデータベース・アダプタで変更する必要はありません。

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

事前条件および構成の詳細は、「順序表: 最終読取りID」を参照してください。

制御表

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

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

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

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

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

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

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

この設定では、削除ポーリング計画が便利です。制御表を小さく維持することが重要です。オプションshouldDeleteDetailRows="false"が使用されている場合には、変更を伴わない削除（削除が実際の表にはカスケードされない）が実行され、制御行のみが削除されます。

複数のマスター表に同じ制御表を再利用できます。 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_Home\bpel\samples\tutorials\122.DBAdapter

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

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

DistributedPolling
PollingExternalSequencing
PollingFileSequencingStrategy
PollingForChildUpdates
PollingNoAfterReadStrategy
PollingOracleSCNStrategy
PollingPureSQLOtherTableInsert
PollingPureSQLSysdateLogicalDelete
PollingWithParameters

これらのファイルを参照するには、次の場所へ移動します。

Oracle_Home\bpel\samples\tutorials\122.DBAdapter\advanced\polling

4.3 Oracle BPEL Process Managerでのデータベース・アダプタの使用例

122.DBAdapterチュートリアルで説明されているデータベース・アダプタを使用するには、次の場所に移動します。

Oracle_Home\bpel\samples\tutorials\122.DBAdapter

表4-9に、Oracle BPEL Process Managerで提供されているデータベース・アダプタのサンプルを示します。

表4-9 データベース・アダプタの使用例

チュートリアル名	説明
`Delete`	データベース・アダプタのアウトバウンドの`delete`操作を説明します。XMLレコードが操作に渡され、同じ主キーを持つデータベースの行が削除されます。
`File2StoredProcedure`	ストアド・プロシージャ`ADDEMPLOYEES`へのインスタンスXMLの提供にファイル・アダプタが使用され、そのストアド・プロシージャが実行されるサンプル・シナリオを説明します。インスタンスXMLは、ストアド・プロシージャのパラメータ値を指定します。`ADDEMPLOYEES`プロシージャが、（Oracle Liteではない）Oracleデータベースにインストールされている必要があります。
`File2Table`	カスタム形式で定義されているネイティブ（CSV）データの入力ファイルの使用方法を説明します。入力ファイルは注文書で、ファイル・アダプタによって処理され、FIle2Table BPELプロセスにXMLメッセージとして公開されます。メッセージは別の注文書形式に変換され、`invoke`アクティビティにルーティングされます。
`Insert`	データベース・アダプタのアウトバウンドの`insert`操作を説明します。XMLレコードは操作に渡され、リレーショナル・データとしてデータベースに挿入されます。（JDeveloper BPEL Designerでは、`Merge`（`Insert`または`Update`）が指定されます。）
`InsertWithCatch`	BPELプロセスへのフォルト処理の追加に必要な追加の手順（`Insert`チュートリアルに基づく）を説明します。
`JPublisherWrapper`	PL/SQLレコード型の使用に関する解決策を説明します。JPublisherは、属性がRECORDのフィールドに一致する対応するOBJECT型、およびRECORDとOBJECTの相互変換を行う変換APIの作成に使用されます。また、JPublisherではOBJECTを許可し、両方向で変換APIを使用して基礎となるメソッドを起動するラッパー・プロシージャ（またはファンクション）が生成されます。起動されたメソッドが、（Oracle Liteではない）Oracleデータベースにインストールされている必要があります。
`MasterDetail`	一連の表から別の表へデータを移動する方法を説明します。サンプルでは、データベース・アダプタを使用して、一連の表からデータを読み取って処理し、アダプタを使用して別のデータベース表に書き込みを行っています。
`Merge`	データベース・アダプタのアウトバウンドの`merge`操作を説明します。XMLレコードが操作に渡され、データベースの対応する行が挿入または更新されます。
`PollingControlTableStrategy`	`MOVIES`表からXMLインスタンスをポーリングするインバウンドのポーリング操作を説明します。`MOVIES`表に新しい行が挿入されると、ポーリング操作によりOracle BPEL Process Managerに伝達されます。この計画では、まだ処理されていないすべての行の主キーの保存に制御表が使用されます。（主キーにより）制御表とソース表が自然結合しているため、制御表に対するポーリングは、実際にはソース表を直接ポーリングすることと同じです。
`PollingLastReadIdStrategy`	`MOVIES`表からXMLインスタンスをポーリングするインバウンドのポーリング操作を説明します。`MOVIES`表に新しい行が挿入されるたびに、ポーリング操作によりOracle BPEL Process Managerに伝達されます。この計画では、順序値の保存にヘルパー表が使用されます。
`PollingLastUpdatedStrategy`	`MOVIES`表からXMLインスタンスをポーリングするインバウンドのポーリング操作を説明します。`MOVIES`表に新しい行が挿入されるたびに、ポーリング操作によりOracle BPEL Process Managerに伝達されます。この計画では、`last_updated`値の保存にヘルパー表の使用が関連します。
`PollingLogicalDeleteStrategy`	`MOVIES`表からXMLインスタンスをポーリングするインバウンドのポーリング操作を説明します。`MOVIES`表に新しい行が挿入されるたびに、ポーリング操作によりOracle BPEL Process Managerに伝達されます。この計画には、処理された各行の特別なフィールドの更新、および処理済の行を除外するための実行時の`WHERE`句の更新が関連します。
`PureSQLPolling`	日付フィールドに基づいて表をポーリングする方法を説明します。
`PureSQLSelect`	`SELECT`操作に任意で複雑なSQL文字列を指定する際に、JDeveloper BPEL Designerの`WHERE`句ビルダーを使用しない方法を説明します。
`QueryByExample`	データベース・アダプタのアウトバウンドの`queryByExample`操作を説明します。`SELECT` SQL問合せは、サンプルのXMLレコードに設定されているフィールドに基づいて動的に作成され、一致するレコードが返されます。
`ResultSetConverter`	REF CURSORの使用に関する解決策を説明します。解決策には、対応する`java.sql.ResultSet`をOBJECTの集合（`VARRAY`または`NESTED TABLE`）に変換するJavaストアド・プロシージャの使用が関連します。
`SelectAll`	データベース・アダプタのアウトバウンドの`SelectAll`操作を説明します。`WHERE`句がない場合、`MOVIES`表のすべての行がXMLとして返されます。
`SelectAllByTitle`	データベース・アダプタのアウトバウンドの`SelectAllByTitle`操作を説明します。選択されたタイトルのある`MOVIES`表の行はXMLとして返されます。
`Update`	データベース・アダプタのアウトバウンドの`Update`操作を説明します。XMLレコードが操作に渡され、同じ主キーを持つデータベースの行は更新されます。（JDeveloper BPEL Designerでは、`Merge`（`Insert`または`Update`）が指定されます。）

使用例の多くで使用されているMOVIES表の構造は、表4-1を参照してください。ほとんどのサンプルに含まれているreadme.txtファイルには、説明が記載されています。

この項は、次の2つの使用例で構成されています。

使用例: 1
使用例: 2

4.3.1 使用例: 1

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

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

アダプタ構成ウィザードの起動
データベースへの接続
操作タイプの選択
表の選択およびインポート
主キーの定義
リレーションシップの作成
オブジェクト・フィルタの作成
WHERE句の定義
読取り後計画の選択
設計時の内部処理

4.3.2 「アダプタ構成ウィザード」の起動

JDeveloper BPEL DesignerでBPELプロジェクトを作成したら、データベース・アダプタの定義を開始できます。ウィンドウが隠れてしまった場合は、[Alt]キーを押しながら[Tab]キーを押して再度表示します。

アダプタ構成ウィザードを起動するには、次のようにします。

「コンポーネント・パレット」セクションのドロップダウン・リストで「All Process Activities」が選択されていることを確認します。
デザイナ・ウィンドウの右側に、PartnerLinkアクティビティをドラッグ・アンド・ドロップします。
「パートナ・リンクの作成」ウィンドウに名前を入力します。
「アダプタ・サービスの定義」アイコンをクリックして、アダプタ構成ウィザードを起動します。

図adapter_service.gifの説明
「ようこそ」ウィンドウの「次へ」をクリックします。
「アダプタ・タイプ」に「データベース・アダプタ」を選択して、「次へ」をクリックします。
「サービス名」ウィンドウで、サービスの名前と説明を入力します。

説明はオプションです。
「次へ」をクリックします。「サービス接続」ウィザードが表示されます。

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

4.3.3 データベースへの接続

図4-2に、サービスで使用するデータベース接続を選択する場所を示します。これは、サービスを構成する表をインポートするデータベースです。

データベース接続を識別するJava Naming and Directory Interface（JNDI）の名前を指定するか、指定されたデフォルト名を使用できます。JNDI名は、サービスがOracle BPEL Serverにデプロイされる際に使用される接続のプレースホルダとして機能します。これにより、開発と本番に異なるデータベースを使用できます。アダプタ構成ウィザードにより、生成されたWSDLの設計時の接続も取得され、実行時の検索に失敗した場合に予備として機能します。

図4-2 アダプタ構成ウィザード: サービス接続

「図4-2 アダプタ構成ウィザード: サービス接続」の説明

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

本番環境では、アダプタのデプロイメント・ディスクリプタ（oc4j-ra.xml）にJNDIエントリを追加することをお薦めします。この場合、管理モードで作業することでデータベース・アダプタのパフォーマンスが向上します。管理モード以外の場合、データベース・アダプタでは設計時の接続情報が使用されます。
「次へ」をクリックすると、データベースへの接続が試行されます。接続を確立できないと、既存のパートナ・リンクを編集している場合でも次のウィンドウに進めません。

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

4.3.4 操作タイプの選択

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

図4-3 アダプタ構成ウィザード: 操作タイプ

「図4-3 アダプタ構成ウィザード: 操作タイプ」の説明

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

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

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

表に対して操作を実行

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

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

「挿入/更新」を選択すると、merge、insert、updateおよびwrite操作が作成されます。
前述の起動ウィンドウでは、MergeServiceサービス名が選択操作、つまりMergeServiceSelectの一部として表示されています。
queryByExample操作は、すべてのWSDLに表示されます。
「操作」リストが空の場合は、パートナ・リンクを再度選択して「操作」リストを再度クリックします。

注意:

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

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

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

ウィザードの使用を続行するには、「表の選択およびインポート」を参照してください。

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

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

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

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

このウィンドウには、JDeveloper BPEL Designerプロジェクトに前もってインポートされていた表がすべて表示されます（他のパートナ・リンク用にインポートされていた表も含みます）。これにより、指定されたBPELプロジェクトの複数のパートナ・リンク全体で、構成された表定義を再利用できます。これらは生成されたTopLinkディスクリプタです。

この操作に使用するルート・データベース表がインポート済でない場合は、「表のインポート」をクリックします。表を再度インポートする必要がある場合（データベースで表構造が変更されていた場合など）は、再度インポートします。表を再度インポートして、以前に構成された表定義を上書きできます。

注意:

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

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

4.3.6 主キーの定義

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

図4-5 アダプタ構成ウィザード: 主キーの定義

「図4-5 アダプタ構成ウィザード: 主キーの定義」の説明

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

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

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

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

図4-6 アダプタ構成ウィザード: リレーションシップ

「図4-6 アダプタ構成ウィザード: リレーションシップ」の説明

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

データベース上に表間の外部キー制約がすでに存在する場合、表をインポートすると、ソース表（外部キー制約を含む表）からターゲット表に1対1（1:1）、ターゲット表からソース表に1対多（1:M）の2つのリレーションシップが自動的に作成されます。
図4-6に示すように、ルート・データベース表からアクセス可能なリレーションシップのみが表示されます。リレーションシップを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を削除すると、リレーションシップは表示されなくなります。

図4-7に、新しいリレーションシップを作成する場所を示します。

図4-7 リレーションシップの作成

「図4-7 リレーションシップの作成」の説明

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

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

注意:

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

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

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

図4-8 EMPLOYEEスキーマ

「図4-8 EMPLOYEEスキーマ」の説明

図4-9 ADDRESSスキーマ

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

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

Employee:

id（151などのIDフィールドへのダイレクト・マッピング）
name（Stephen KingなどのNAMEフィールドへのダイレクト・マッピング）
addrId（345などのADDR_IDフィールドへのダイレクト・マッピング）

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

Employee:

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

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

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

1対1リレーションシップの指定では、次のような方法がサポートされています。

図4-10および図4-11に示すように、親表に外部キーが存在します。
図4-12および図4-13に示すように、子表に外部キーが存在します。

図4-10 親表EMPLOYEEの外部キー

「図4-10 親表EMPLOYEEの外部キー」の説明

図4-11 親表ADDRESSの外部キー

「図4-11 親表ADDRESSの外部キー」の説明

図4-12 子表EMPLOYEEの外部キー

「図4-12 子表EMPLOYEEの外部キー」の説明

図4-13 子表ADDRESSの外部キー

「図4-13 子表ADDRESSの外部キー」の説明

4.3.8 オブジェクト・フィルタの作成

図4-14に、インポートされた表の定義から作成されたオブジェクト・フィルタを示します。これには定義したリレーションシップも含まれます。

図4-14 アダプタ構成ウィザード: オブジェクトのフィルタ

「図4-14 アダプタ構成ウィザード: オブジェクトのフィルタ」の説明

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

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

4.3.9 WHERE句の定義

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

図4-15に、アウトバウンド・サービスのWHERE句を定義する場所を示します。インバウンド・サービスでは、「パラメータ」セクションは表示されません。

図4-15 アダプタ構成ウィザード: WHERE句の定義

「図4-15 アダプタ構成ウィザード: WHERE句の定義」の説明

注意:

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

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

EMP.ID = 123

この場合、RHSはリテラル値です。このRHSは、図4-16に示す「リテラル」オプションです。
EMP.ADDR_ID = ADDR.ID

この場合、RHSは別のデータベース・フィールドです。このRHSは、図4-16に示す「問合せキー」オプションです。
EMP.ID = ?

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

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

図4-16 式ビルダー

「図4-16 式ビルダー」の説明

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

OTNのTopLinkのページ

http://www.oracle.com/technology/products/ias/toplink/index.html

TopLinkのマニュアル
```
http://download.oracle.com/docs/cd/B14099_04/web.htm#toplink
```
このサイトには、XPath式ビルダーを使用した式の構成に関するマニュアルが含まれます。

ウィザードの使用を続行するには、「読取り後計画の選択」を参照してください。

4.3.10 読取り後計画の選択

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

読取り済の行の削除
表のフィールドの更新（論理削除）
順序表の更新

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

図4-17 アダプタ構成ウィザード: 読取り後

「図4-17 アダプタ構成ウィザード: 読取り後」の説明

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

4.3.10.1 読取り済の行の削除

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

4.3.10.2 表のフィールドの更新（論理削除）

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

図4-18 アダプタ構成ウィザード: 論理削除

「図4-18 アダプタ構成ウィザード: 論理削除」の説明

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

図4-19 表のフィールドの更新

「図4-19 表のフィールドの更新」の説明

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

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

4.3.10.3 順序表の更新

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

図4-20 アダプタ構成ウィザード: 最終読取りID表

「図4-20 アダプタ構成ウィザード: 最終読取りID表」の説明

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

図4-21 順序表の更新

「図4-21 順序表の更新」の説明

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

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

4.3.11 設計時の内部処理

この項では、アダプタ構成ウィザードを使用してデータベース・アダプタを構成する際に、設計時に内部的に発生することを説明します。

4.3.11.1 表のインポート

表をインポートすると、JDeveloper BPEL Designerのオフライン表のサポートにより、データベース表のオフライン・スナップショットが作成されます。このオフライン・バージョンの表は、実データベース表に影響を与えずに変更できます（たとえば、外部キー制約を追加できます）。これにより、この表のTopLinkディスクリプタおよび関連するJavaソース・ファイルが作成され、ディスクリプタのすべての属性が対応するデータベース列に自動的にマッピングされます。TopLinkディスクリプタにより、Javaクラスがオフライン・データベース表にマッピングされます。

最も一般的なデータ列が、フィールドへの直接マッピングとしてマッピングされます。つまり、データベース列の値が直接属性にマッピングされます。たとえば、データベースのSALARY列はオブジェクト・モデルのsalary属性にマッピングされ、その属性にはこの列の値が含まれます。

インポートされた表にすでに外部キー制約がある場合、表の間でリレーションシップのマッピングが自動的に生成されます。できるだけ多くのシナリオを網羅するため、既存の各外部キー制約には、ソース表からターゲット表への1対1マッピングと、逆方向への1対多マッピングの2つのマッピングが生成されます。これが完了すると、BPELプロジェクトにTopLink Workbenchプロジェクトが作成されています。

注意:

ディスクリプタ生成処理の一部として作成されるJavaクラスは、実際には、プロセスとともにデプロイされることも実行時に使用されることもありません。 TopLink Workbenchでは、各ディスクリプタがJavaクラスと関連付けられていることを前提としているため、設計時に存在します。プロセスがデプロイされると、マッピング・メタデータはtoplink_mappings.xmlに保存されます。

表のインポートが終了したら、ルート・データベース表を選択する必要があります。その際、実際には、どのTopLinkディスクリプタに自動生成された問合せを格納するかを選択しています。

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

リレーションシップの作成または削除の際、実際には、TopLinkディスクリプタのマッピングを変更しています。新しいリレーションシップの作成では、次のことが行われています。

オフライン・データベース表に外部キー制約が作成されます。
ディスクリプタに1対1または1対多マッピングが追加されます。
外部キー・フィールドへの直接マッピングが削除されます。

リレーションシップ・マッピングの削除では、次のことが行われます。

ディスクリプタから1対1または1対多マッピングが削除されます。
オフライン・データベース表から外部キー制約が削除されます。
リレーションシップに関連する各外部キー・フィールドへの直接マッピングが追加されます。

4.3.11.3 設計時成果物の生成

次のファイルが生成されます。

service_name.wsdl: データベース・アダプタのサービス定義が含まれます。
RootTable.xsd: ルート・オブジェクトのXMLタイプの定義です。
toplink_mappings.xml: BPELプロジェクトのTopLinkマッピング・メタデータが含まれます。サーバーにデプロイされる唯一のToplink成果物です。

4.3.12 使用例: 2

この項では、ポーリング・ファイル順序付け計画という高度な使用例について説明します。この使用例は次の場所にあります。

Oracle_Home\bpel\samples\tutorials\122.DBAdapter\advanced/polling/PollingFileSequencingStrategy

このシナリオは、変更を伴わないポーリングを実行することを意図しています。この例の順序付け計画で注意する必要があるのは、last read id/sequence valueという1つの情報のみです。この情報を同一データベースまたは異なるデータベースの表に格納するか、単にファイルに格納できます。

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

前提条件
新規BPELプロジェクトの作成
アダプタ構成ウィザードの起動

4.3.12.1 前提条件

次のディレクトリにあるsqlスクリプトsetup.sqlおよびreset.sqlを実行していることを確認します。

Oracle_Home\bpel\samples\tutorials\122.DBAdapter\sql

4.3.12.2 新規BPELプロジェクトの作成

次の手順に従って新規BPELプロジェクトを作成します。

Oracle JDeveloperを開きます。
「ファイル」メニューから「新規」を選択します。

「新規ギャラリ」ダイアログ・ボックスが表示されます。
「フィルタ方法」ボックスから「すべてのテクノロジ」を選択します。使用可能なカテゴリのリストが表示されます。
「General」ノードを開いて「Projects」を選択します。
「項目」グループから「BPELプロジェクト」を選択します。
「OK」をクリックします。

「BPELプロジェクト作成」ダイアログ・ボックスが表示されます。
「OK」をクリックします。

新規BPELプロジェクトが作成されました。

4.3.12.3 「アダプタ構成ウィザード」の起動

Oracle JDeveloperでBPELプロジェクトを作成した後、データベース・アダプタの定義を開始できます。データベース・アダプタを定義するには、次の手順を実行します。

「コンポーネント・パレット」からデザイナ・ウィンドウに「データベース・アダプタ」をドラッグ・アンド・ドロップします。

「アダプタ構成ウィザード - ようこそ」画面が表示されます。
「次へ」をクリックします。

「サービス名」ダイアログ・ボックスが表示されます。
図4-22のようにサービス名を入力します。「説明」フィールドはオプションです。

図4-22 サービス名の入力

「図4-22 サービス名の入力」の説明
「次へ」をクリックします。

「サービス接続」ダイアログ・ボックスが表示されます。
プロジェクトに定義済のデータベース接続を選択するか、新規接続を作成します。
「次へ」をクリックします。

「操作タイプ」ダイアログ・ボックスが表示されます。
図4-23のように、「表の新規レコードまたは更新されたレコードをポーリング」を選択します。

図4-23 操作タイプの選択

「図4-23 操作タイプの選択」の説明
「次へ」をクリックします。

「表の選択」ダイアログ・ボックスが表示されます。
「表のインポート」をクリックします。

「表のインポート」ダイアログ・ボックスが表示されます。
図4-24のように、「MOVIES」表をダブルクリックして選択します。

図4-24 「表のインポート」ダイアログ・ボックス

「図4-24 「表のインポート」ダイアログ・ボックス」の説明
「OK」をクリックします。

図4-25のように、MOVIES表が選択された状態で「表の選択」ダイアログ・ボックスが表示されます。

図4-25 「表の選択」ダイアログ・ボックス

「図4-25 「表の選択」ダイアログ・ボックス」の説明
「次へ」をクリックします。

「リレーションシップ」ダイアログ・ボックスが表示されます。
「リレーションシップ」ダイアログ・ボックスで、ルート・データベースからアクセス可能なリレーションシップを定義できます。ただし、この例ではリレーションシップを定義しません。「次へ」をクリックします。
表示される「オブジェクトのフィルタ」ダイアログ・ボックスで「次へ」をクリックします。

「読取り後」ダイアログ・ボックスが表示されます。
「順序ファイルの更新」を選択して「次へ」をクリックします。

「順序ファイル」ダイアログ・ボックスが表示されます。
次の情報を入力します。
- 順序ファイル: 順序ファイルの場所を指定します。この例では、次のように指定します。
```
Oracle_Home\bpel\samples\tutorials\122.DBAdapter\advanced\polling\PollingFileSequencingStrategy\lastReadId.txt
```
- 順序IDフィールド: 「LATST_UPDATED」を選択します。
図4-26に、値が移入された後の「順序ファイル」ダイアログ・ボックスを示します。

図4-26 「順序ファイル」ダイアログ・ボックス

「図4-26 「順序ファイル」ダイアログ・ボックス」の説明
「次へ」をクリックします。

図4-27に示す「ポーリング・オプション」ダイアログ・ボックスが表示されます。

図4-27 「ポーリング・オプション」ダイアログ・ボックス

「図4-27 「ポーリング・オプション」ダイアログ・ボックス」の説明
「ポーリング・オプション」ダイアログ・ボックスで、デフォルト値を保持して「次へ」をクリックします。

図4-28に示す「選択条件の定義」ダイアログ・ボックスが表示されます。

図4-28 「選択条件の定義」ダイアログ・ボックス

「図4-28 「選択条件の定義」ダイアログ・ボックス」の説明
デフォルト値を保持して「次へ」をクリックします。

図4-29に示す「アダプタ構成ウィザード - 終了」画面が表示されます。

図4-29 「アダプタ構成ウィザード - 終了」画面

「図4-29 「アダプタ構成ウィザード - 終了」画面」の説明
「終了」をクリックします。

すべてのフィールドが移入済の状態で、図4-30に示す「パートナ・リンクの作成」ダイアログ・ボックスが表示されます。

図4-30 「パートナ・リンクの作成」ダイアログ・ボックス

「図4-30 「パートナ・リンクの作成」ダイアログ・ボックス」の説明
「OK」をクリックします。

画面は図4-31のようになります。

図4-31 「アプリケーション」画面

「図4-31 「アプリケーション」画面」の説明
プロジェクトを右クリックして「デプロイ」を選択し、「ServerConnection1」をポイントして「Defaultドメインにデプロイ」をクリックします。
Oracle BPEL Controlは図4-32のようになります。

図4-32 Oracle BPEL Control

「図4-32 Oracle BPEL Control」の説明

4.4 Oracle Enterprise Service Busでのデータベース・アダプタの使用例

この使用例では、あるデータベースの表1セットのデータを別のデータベースの表にレプリケートする単純なシナリオを示します。このシナリオでは、ソース表でのインバウンドのポーリング読取りと、宛先表へのアウトバウンドの書込みまたはマージを行います。

この使用例では、2組の部門表と従業員表があります。一方はインバウンド・データに使用されるSENDER_EMPおよびSENDER_DEPTで、他方はアウトバウンド・データに使用されるRECEIVER_EMPおよびRECEIVER_DEPTです。

各表セットに対する操作は個別のWSDLに定義されており、固有のデータベース・アダプタJNDI（接続）名を定義できることに注意してください。つまり、各表セットを個別のデータベース・スキーマまたはインスタンスに置くことができます。

この項には、次のステップが含まれます。

前提条件
新規ESBプロジェクトの作成
インバウンド・データベース・アダプタの作成
アウトバウンド・データベース・アダプタ・サービスの作成
ルーティング・サービスの構成
ESB Consoleのチェック
ESB Controlでの実行チェック

4.4.1 前提条件

アプリケーションを作成する前に、次の場所にあるストアド・プロシージャcreate_schemas.sqlを実行する必要があります。

OracleAS_1\bpel\samples\tutorials\122.DBAdapter\MasterDetail\sql\oracle

このストアド・プロシージャにより4つの表が作成されます。SENDER_EMPおよびSENDER_DEPTはインバウンド・データベース・アダプタによりデータが読み取られる表で、RECEIVER_EMPおよびRECEIVER_DEPTはアウトバウンド・データベース・アダプタによる新規データの格納元となる表です。

4.4.2 新規ESBプロジェクトの作成

次の手順に従って新規ESBプロジェクトを作成します。

Oracle JDeveloperを開きます。
「ファイル」メニューから「新規」を選択します。

「新規ギャラリ」ダイアログ・ボックスが表示されます。
「フィルタ方法」ボックスから「すべてのテクノロジ」を選択します。使用可能なカテゴリのリストが表示されます。
「General」ノードを開いて「Projects」を選択します。
図4-33のように、「項目」グループから「ESBプロジェクト」を選択します。

図4-33 新規ESBプロジェクトの作成

「図4-33 新規ESBプロジェクトの作成」の説明
「OK」をクリックします。

「ESBプロジェクトの作成」ダイアログ・ボックスが表示されます。
「プロジェクト名」フィールドにわかりやすい名前を入力します。たとえば、MasterDetailsと入力します。
「OK」をクリックします。

新規ESBプロジェクトMasterDetailsが作成されました。

4.4.3 インバウンド・データベース・アダプタの作成

次の手順に従ってインバウンド・データベース・アダプタを作成します。

「コンポーネント・パレット」から「アダプタ・サービス」を選択し、「データベース・アダプタ」をMasterDetails.esbプロジェクトにドラッグ・アンド・ドロップします。

「データベース・アダプタ・サービスの作成」ダイアログ・ボックスが表示されます。
「データベース・アダプタ・サービスの作成」ダイアログ・ボックスで次の情報を指定します。
- 名前: サービスの名前を入力します。この例では、InboundServicesと入力します。
- システム/グループ: デフォルト値を保持します。
図4-34に、「名前」および「システム/グループ」フィールドに情報を入力した後の「データベース・アダプタ・サービスの作成」ダイアログ・ボックスを示します。

図4-34 データベース・アダプタ・サービスの定義

「図4-34 データベース・アダプタ・サービスの定義」の説明
「アダプタ・サービスのWSDL」で「アダプタ・サービスのWSDLの構成」アイコンをクリックします。

「アダプタ構成ウィザード」の「ようこそ」ページが表示されます。
「次へ」をクリックします。

「サービス名」フィールドが入力済の状態で「サービス名」ダイアログ・ボックスが表示されます。
サービス名を保持して「次へ」をクリックします。

図4-35に示す「サービス接続」ダイアログ・ボックスが表示されます。

図4-35 「サービス接続」ダイアログ・ボックス

「図4-35 「サービス接続」ダイアログ・ボックス」の説明
「新規」をクリックしてデータベース接続を定義します。

「データベース接続の作成」ウィザードの「ようこそ」ページが表示されます。
「次へ」をクリックします。

「タイプ」ダイアログ・ボックスが表示されます。
「タイプ」ダイアログ・ボックスに次の情報を入力します。
1. 「接続名」フィールドで、データベース接続に使用する一意の名前を指定します。この例では、masterdetailsと入力します。
2. 「接続タイプ」ボックスから「Oracle (JDBC)」を選択します。
  
  図4-36に「タイプ」ダイアログ・ボックスを示します。
  
  図4-36 接続名と接続タイプの指定
  
  「図4-36 接続名と接続タイプの指定」の説明
「次へ」をクリックします。

「認証」ダイアログ・ボックスが表示されます。
次のフィールドに認証の資格証明を入力します。
1. 「ユーザー名」フィールドで、データベース接続に使用する一意の名前を指定します。この例では、scottと入力します。
2. 「パスワード」フィールドで、データベース接続に使用するパスワードを指定します。この例では、tigerと入力します。
3. 「ロール」フィールドは空白にしておきます。
4. 「パスワードを配布」を選択します。
図4-37に、各資格証明フィールドに値が移入された後の「認証」ダイアログ・ボックスを示します。

図4-37 認証資格証明の指定

「図4-37 認証資格証明の指定」の説明
「次へ」をクリックします。

「接続」ダイアログ・ボックスが表示されます。
次のフィールドに情報を入力します。
1. 「ドライバ」リストで、デフォルト値の「thin」を保持します。
2. 「ホスト名」フィールドでデフォルト値の「localhost」を保持します。
3. 「JDBCポート」フィールドで、データベース接続に使用するポート番号を指定します。この例では、1521と入力します。
4. 「SID」フィールドで、データベース接続に使用する一意のSID値を指定します。この例では、ORCLと入力します。
図4-38に「接続」ダイアログ・ボックスを示します。

図4-38 新規データベース接続情報の指定

「図4-38 新規データベース接続情報の指定」の説明
「次へ」をクリックします。

「テスト」ダイアログ・ボックスが表示されます。
「接続のテスト」をクリックし、指定した情報によりデータベースとの接続が確立されるかどうかを確認します。
「終了」をクリックして新規データベース接続の作成プロセスを完了します。

図4-39のように、「サービス接続」ダイアログ・ボックスが表示され、データベース接続のサマリーが示されます。

図4-39 「サービス接続」ダイアログ・ボックス

「図4-39 「サービス接続」ダイアログ・ボックス」の説明
「次へ」をクリックします。

図4-40に示す「操作」ダイアログ・ボックスが表示されます。

図4-40 操作タイプの指定

「図4-40 操作タイプの指定」の説明
「表の新規レコードまたは更新されたレコードをポーリング」を選択して「次へ」をクリックします。

「表の選択」ダイアログ・ボックスが表示されます。
「表のインポート」をクリックして表をインポートします。

図4-41に示す「表のインポート」ダイアログ・ボックスが表示されます。

図4-41 「表のインポート」ダイアログ・ボックス

「図4-41 「表のインポート」ダイアログ・ボックス」の説明
「表のインポート」ダイアログ・ボックスで次の問合せパラメータを選択します。
- スキーマ: 「SCOTT」を選択します。
- 名前フィルタ: 「問合せ」をクリックしてデータベースからオブジェクトを取得します。
  
  使用可能な表のリストが表示されます。
「使用可能」列でRECEIVER_DEPTおよびRECEIVER_EMPを選択し、「追加」ボタンをクリックして「選択」列に移動します。

図4-42に「追加」ボタンを示します。

図4-42 「追加」ボタン

「図4-42 「追加」ボタン」の説明

図4-43のように、選択した表が「選択」列に表示されます。

図4-43 スキーマからの必須表の追加

「図4-43 スキーマからの必須表の追加」の説明
「OK」をクリックします。

図4-44のように、インポートした表を含む「表の選択」ダイアログ・ボックスが表示されます。

図4-44 インポートされた表を含む「表の選択」ダイアログ・ボックス

「図4-44 インポートされた表を含む「表の選択」ダイアログ・ボックス」の説明
ルート表を選択して「次へ」をクリックします。この例では「SCOTT.RECEIVER_DEPT」を選択します。

図4-45に示す「リレーションシップ」ダイアログ・ボックスが表示されます。

図4-45 「リレーションシップ」ダイアログ・ボックス

「図4-45 「リレーションシップ」ダイアログ・ボックス」の説明
「次へ」をクリックします。

図4-46に示す「オブジェクトのフィルタ」ダイアログ・ボックスが表示されます。

図4-46 「オブジェクトのフィルタ」ダイアログ・ボックス

「図4-46 「オブジェクトのフィルタ」ダイアログ・ボックス」の説明
「次へ」をクリックします。

「読取り後」ダイアログ・ボックスが表示されます。
「読取り後」ダイアログ・ボックスで、図4-47のように「読取り済の行の削除」を選択して「次へ」をクリックします。

図4-47 「読取り後」ダイアログ・ボックス

「図4-47 「読取り後」ダイアログ・ボックス」の説明

図4-48に示す「ポーリング・オプション」ダイアログ・ボックスが表示されます。

図4-48 「ポーリング・オプション」ダイアログ・ボックス

「図4-48 「ポーリング・オプション」ダイアログ・ボックス」の説明
「ポーリング・オプション」ダイアログ・ボックスで、デフォルト値を保持して「次へ」をクリックします。

図4-49に示す「選択条件の定義」ダイアログ・ボックスが表示されます。

図4-49 「選択条件の定義」ダイアログ・ボックス

「図4-49 「選択条件の定義」ダイアログ・ボックス」の説明
デフォルトの問合せを保持して「次へ」をクリックします。ただし、独自の式を定義するには「編集」をクリックします。

図4-50に示す「アダプタ構成ウィザード - 終了」画面が表示されます。

図4-50 アダプタ構成ウィザード - 終了

「図4-50 アダプタ構成ウィザード - 終了」の説明

4.4.4 アウトバウンド・データベース・アダプタ・サービスの作成

次の手順に従ってインバウンド・データベース・アダプタを作成します。

「コンポーネント・パレット」から「アダプタ・サービス」を選択し、「データベース・アダプタ」をMasterDetails.esbプロジェクトにドラッグ・アンド・ドロップします。

「データベース・アダプタ・サービスの作成」ダイアログ・ボックスが表示されます。
「データベース・アダプタ・サービスの作成」ダイアログ・ボックスで次の情報を指定します。
- 名前: サービスの名前を入力します。この例では、OutboundServicesと入力します。
- システム/グループ: デフォルト値を保持します。
「アダプタ・サービスのWSDL」で「アダプタ・サービスのWSDLの構成」アイコンをクリックします。

「アダプタ構成ウィザード」の「ようこそ」ページが表示されます。
「次へ」をクリックします。

「サービス名」フィールドが入力済の状態で「サービス名」ダイアログ・ボックスが表示されます。
サービス名を保持して「次へ」をクリックします。

「サービス接続」ダイアログ・ボックスが表示されます。
作成済の接続を選択して「次へ」をクリックします。

図4-51に示す「操作」ダイアログ・ボックスが表示されます。

図4-51 操作タイプの指定

「図4-51 操作タイプの指定」の説明
「表に対して操作を実行」を選択して「次へ」をクリックします。

「表の選択」ダイアログ・ボックスが表示されます。
「表のインポート」をクリックして表をインポートします。

「表のインポート」ダイアログ・ボックスが表示されます。
「表のインポート」ダイアログ・ボックスで次の問合せパラメータを選択します。
- スキーマ: 「SCOTT」を選択します。
- 名前フィルタ: 「問合せ」をクリックしてデータベースからオブジェクトを取得します。
  
  使用可能な表のリストが表示されます。
「使用可能」列でSENDER_DEPTおよびSENDER_EMPを選択し、「追加」ボタンをクリックして「選択」列に移動します。

図4-52のように、選択した表が「選択」列に表示されます。

図4-52 スキーマからの必須表の追加

「図4-52 スキーマからの必須表の追加」の説明
「OK」をクリックします。

図4-53のように、インポートした表を含む「表の選択」ダイアログ・ボックスが表示されます。

図4-53 インポートされた表を含む「表の選択」ダイアログ・ボックス

「図4-53 インポートされた表を含む「表の選択」ダイアログ・ボックス」の説明
ルート表を選択して「次へ」をクリックします。この例では「SCOTT.SENDER_DEPT」を選択します。

図4-55に示す「リレーションシップ」ダイアログ・ボックスが表示されます。

図4-54 「リレーションシップ」ダイアログ・ボックス

「図4-54 「リレーションシップ」ダイアログ・ボックス」の説明
「次へ」をクリックします。

図4-55に示す「オブジェクトのフィルタ」ダイアログ・ボックスが表示されます。

図4-55 「オブジェクトのフィルタ」ダイアログ・ボックス

「図4-55 「オブジェクトのフィルタ」ダイアログ・ボックス」の説明
「次へ」をクリックします。

図4-56に示す「選択条件の定義」ダイアログ・ボックスが表示されます。

図4-56 「選択条件の定義」ダイアログ・ボックス

「図4-56 「選択条件の定義」ダイアログ・ボックス」の説明
「次へ」をクリックします。

図4-57のように、アウトバウンド・サービスの作成を確認する「終了」画面が表示されます。

図4-57 「アダプタ構成ウィザード - 終了」画面

「図4-57 「アダプタ構成ウィザード - 終了」画面」の説明

4.4.5 ルーティング・サービスの構成

次の手順に従ってルーティング・サービスを構成します。

「InboundServices」ルーティング・サービスをダブルクリックします。

図4-58のように、「アプリケーション」ウィンドウの中央ペインに「ルーティング・サービス」ウィンドウが表示されます。

図4-58 ルーティング・スクリーン・ウィンドウ

「図4-58 ルーティング・スクリーン・ウィンドウ」の説明
「ルーティング・ルール」タブを選択し、「+」アイコンをクリックしてルールを追加します。

「ターゲット・サービス操作の参照」ダイアログ・ボックスが表示されます。
図4-59のように、「マージ」サービスを選択して「OK」をクリックします。

図4-59 「ターゲット・サービス操作の参照」ダイアログ・ボックス

「図4-59 「ターゲット・サービス操作の参照」ダイアログ・ボックス」の説明
「OK」をクリックします。

「アプリケーション」ウィンドウの中央ペインは図4-60のようになります。

図4-60 トランスフォーメーション・マップの選択

「図4-60 トランスフォーメーション・マップの選択」の説明
「トランスフォーメーション」アイコンをダブルクリックし、「新規マッパー・ファイルの作成」アイコンをクリックします。

図4-61に示す「リクエスト・トランスフォーメーション・マップ」ダイアログ・ボックスが表示されます。

図4-61 「リクエスト・トランスフォーメーション・マップ」ダイアログ・ボックス

「図4-61 「リクエスト・トランスフォーメーション・マップ」ダイアログ・ボックス」の説明
「新規マッパー・ファイルの作成」オプションを選択します。
デフォルト値を受け入れて「OK」をクリックします。

図4-62に示す「トランスフォーメーション」ウィンドウが表示されます。

図4-62 トランスフォーメーション定義

「図4-62 トランスフォーメーション定義」の説明
マッパーの左側で要素を選択し、右側の要素へドラッグしてマップ・プリファレンスを設定します。

「アプリケーション」ウィンドウの中央ペインは図4-63のようになります。

図4-63 マップ・プリファレンスの設定

「図4-63 マップ・プリファレンスの設定」の説明
マッパーの設定を保存してタブを閉じます。
ルーティング・サービスの設定を保存してタブを閉じます。

MasterDetailsプロジェクトの中央ペインは図4-64のようになります。

図4-64 マップ・プリファレンス設定後のMasterDetailsプロジェクト

「図4-64 マップ・プリファレンス設定後のMasterDetailsプロジェクト」の説明
oc4j-ra.xmlを編集してデータベース接続を反映させます。次に例を示します。
```
eis/DB/masterdetails
```
oc4j-ra.xmlは、OracleASのインストール場所にあります。次に例を示します。
```
C:\product\10.1.3.1\OracleAS_1\j2ee\home\application-deployments\default\DbAdapter\oc4j-ra.xml
```
プロジェクトを右クリックし、図4-65のように「ESBに登録」を選択して「LocalESBServer」をクリックします。

図4-65 プロジェクトのデプロイ

「図4-65 プロジェクトのデプロイ」の説明

図4-66に示す「成功」ページが表示されます。

図4-66 「ESB登録サマリー」ページ

「図4-66 「ESB登録サマリー」ページ」の説明

4.4.6 ESB Consoleのチェック

ESB Controlをチェックするには、ESB Consoleを開きます。例: http://localhost:8888/esb/esb/EsbConsole.html

図4-67のようなサービス・ウィンドウが表示されます。

図4-67 ESB Console

「図4-67 ESB Console」の説明

4.4.7 ESB Controlでの実行チェック

次の手順に従ってESB Controlで実行をチェックします。

ESB Consoleを開きます。
右上隅の「インスタンス」をクリックします。
「検索」の横にある緑の矢印をクリックします。

図4-68のようなインスタンスが表示されます。

図4-68 ESB Controlのインスタンス

「図4-68 ESB Controlのインスタンス」の説明

4.5 高度な構成

BPELプロセスの一部としてデータベース・アダプタを使用するために必要なものは、すべてアダプタ構成ウィザードで生成されます。次の項では、パフォーマンスの問題とともに、ウィザードの使用時にバックグラウンドで行われることについて説明します。

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

TopLink Workbenchプロジェクト
リレーショナルからXMLへのマッピング（toplink_mappings.xml）
サービス定義（WSDL）
XMLスキーマ定義（XSD）
デプロイ
パフォーマンス
detectOmissions機能
OutputCompletedXml機能

4.5.1 TopLink Workbenchプロジェクト

ウィザードは、TopLink WorkbenchプロジェクトをBPELプロセス・プロジェクトの一部として作成することで機能します。このTopLinkプロジェクトには、データベース・スキーマをオブジェクト/XMLにマッピングするためのメタデータが含まれています。

TopLinkマッピングは2つの形式で保存されます。toplink_mappings.mwpファイルは設計時プロジェクトで、JDeveloper BPEL Designerで視覚的に編集できます。一方、toplink_mappings.xmlファイルはプロジェクトのXML表現で実行時に使用されます。ファイルが1つのみの.bpelファイルの編集ほど簡単ではありませんが、ダイアグラム・ビューとソースを切り替えられます。

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

toplink_mappings.xmlファイルを直接編集するよりも、toplink_mappings.mwpを視覚的に編集し、すべてのBPEL成果物を再生成して変更を反映することをお薦めします。パートナ・リンクをダブルクリックして編集モードでアダプタ構成ウィザードを開き、「終了」が表示されるまでクリックしてウィザードを進めることで、これを実行できます。MWPバージョンを変更しても、編集モードでウィザードを最後まで進めるまでXMLバージョンは更新されません。
ウィザードの実行中に、TopLinkプロジェクトに影響のある変更（表のインポート、マッピングの作成または削除、式の指定など）を行うとすぐに適用されます。ウィザードを取り消しても元に戻りません。

4.5.1.1 ディスクリプタの削除

ディスクリプタを削除すると、そのディスクリプタを共有している他のパートナ・リンクに影響を与える可能性があるため、ウィザード内でプロジェクトからTopLinkディスクリプタを削除することはできません。ディスクリプタを明示的に削除するには、次のようにします。

「アプリケーション - ナビゲータ」で、プロジェクトの下にある「アプリケーション・ソース」の下の「TopLinkマッピング」ノードをクリックします。
「TopLinkマッピング - 構造」ペインのツリーからディスクリプタを選択します。
右クリックして「削除」を選択します。

図adapter_wizard4.gifの説明

4.5.1.2 問合せ中に返される部分オブジェクト

現在、アダプタ構成ウィザードには、表から特定のフィールドのみを返す部分オブジェクトの読取りに対するビルトイン・サポートがありません。結果セットに不要な属性を手動でアンマップすることで、この機能を取得できます。リレーションシップ・マッピングは、「リレーションシップ」ウィンドウでそれらを削除することでアンマップできますが、ダイレクト・マッピングはTopLinkディスクリプタで明示的にアンマップする必要があります。

属性をアンマップするには、次のようにします。

「アプリケーション - ナビゲータ」で、プロジェクトの下にある「アプリケーション・ソース」の下の「TopLinkマッピング」ノードをクリックします。
「TopLinkマッピング - 構造」ペインのツリーから、アンマップする属性を含むディスクリプタを選択します。
アンマップする属性を右クリックして、「マップ」→「アンマップ」を選択します。

図adapter_wizard11.gifの説明

属性を再マップするには、次のようにします。

「アプリケーション - ナビゲータ」で、プロジェクトの下にある「アプリケーション・ソース」の下の「TopLinkマッピング」ノードをクリックします。
「TopLinkマッピング - 構造」ペインのツリーから、再マップする属性を含むディスクリプタを選択します。
再マップする属性を右クリックして、「マップ」→「フィールドへ直接」を選択します。

JDeveloper BPEL DesignerのウィンドウにTopLink Mappings Editorが自動的に開かれます。
「データベース・フィールド」から、属性をマップする列を選択します。

図adapter_wizard12.gifの説明

4.5.1.3 マッピング名の変更

対応するJavaソース・ファイルを開いて名前を変更します。「構造/マッピング」ペインに移動すると、新しい名前の属性が表示されます。その属性を右クリックし、「マップ」を選択して再マップします。その後、保存してBPEL成果物を再生成します。

「TopLinkマッピング - 構造」ウィンドウからアクセスできるビューには、プロジェクト・ビュー、表/ディスクリプタ・ビュー、個別属性/列ビューおよびJavaソース・ビューの4つがあります。Javaソース・ビューは正確にはTopLinkビューではありませんが、（マッピング名の変更時には）TopLinkビューとして扱うことも可能です。

4.5.1.4 オフライン・データベース表の構成

オフライン・データベース表は、TopLink Workbenchプロジェクトの内部にあります。ウィザードを実行すると、TopLinkプロジェクトが作成されます。表をインポートすると、オフライン表定義として保存されます。

オフライン・データベース表は、データベースのデータ型からXML型への小規模なマッピングの制御に使用できます。サード・パーティのデータベースを使用している場合は、回避策としてこれらのオブジェクトを編集する必要があります。たとえば、サード・パーティのデータベースのserialフィールドはIntegerとしてマッピングする必要があります。これにより、ウィザードで認識されてxs:integerにマッピングされます。詳細は、「サード・パーティのデータベース表をインポートする際の問題」を参照してください。

一度ウィザードを実行します。これによって、JDeveloper BPEL Designerプロジェクトにdatabase/schemaName/schemaName.schemaを追加します。

プロジェクトに追加された後の表名をクリックし（図4-69を参照）、任意の列の型を変更します。ウィザードを（編集モードで）再度実行して「終了」をクリックすると、新しいデータベースのデータ型に基づいてtoplink_mappings.xmlおよびXSDファイルが再マップされます。

図4-69 オフライン表の構成

「図4-69 オフライン表の構成」の説明

ConnectionManagerからアクセス可能な表ではなく、JDeveloper BPEL Designerプロジェクトでオフライン表を編集します（図4-70を参照）。前者の場合、オフライン形式ではなく表自体を編集しているため、列の型は編集できません。

図4-70 オフライン表の編集

「図4-70 オフライン表の編集」の説明

4.5.2 リレーショナルからXMLへのマッピング（toplink_mappings.xml）

データベース・アダプタはTopLinkを使用して実装されます。各ビジネス・プロジェクトには、基礎となるTopLinkプロジェクトがあり、データベース・スキーマをオブジェクト/XMLにマッピングするメタデータが含まれています。

TopLinkの用語では、toplink_mappings.xmlはXMLデプロイメント・ファイルです。実行時に使用するために.mwpプロジェクト・ファイルから生成されます。プロジェクトをTopLink Workbenchで編集し、toplink_mappings.xmlを定期的にリフレッシュすることをお薦めします。

toplink_mappings.xmlファイルは、TopLink Workbenchプロジェクトのランタイム・バージョンです。このファイルを直接編集する場合、変更内容が設計時のtoplink_mappings.mwpには反映されないことに注意してください。そのため、パートナ・リンクを編集すると変更が失われます。

toplink_mappings.xmlファイルは、一連のディスクリプタおよびマッピングで構成されています。ディスクリプタはデータベース・スキーマの単一の表を表し、マッピングは表の単一の列（フィールドへ直接）、または別の表への1対1や1対多リレーションシップ（外部参照）を表します。

toplink_mappings.xmlファイルを変更する場合は、TopLink Workbenchを使用することをお薦めします。次に、toplink_mappings.xmlファイルのマッピングおよびディスクリプタの例を示します。

<mappings>
   <database-mapping>
      <attribute-name>fname</attribute-name>
      <read-only>false</read-only>
      <field-name>ACTOR.FNAME</field-name>
      <attribute-classification>java.lang.String</attribute-classification>
      <type>oracle.toplink.mappings.DirectToFieldMapping</type>
   </database-mapping>

および

<descriptor>
   <java-class>BusinessProcess.Actor</java-class>
   <tables>
      <table>ACTOR</table>
   </tables>
   <primary-key-fields>
      <field>ACTOR.ID</field>
      <field>ACTOR.PROGRAM_ID</field>
      <field>ACTOR.PROGRAM_TYPE</field>
   </primary-key-fields>

ただし、TopLink Workbenchから作業することをお薦めします。

次に、外部参照マッピング（1対1、1対多）の有用な属性を示します。

<privately-owned>false/true

リレーションシップがプライベートに所有されている場合、ソース行が削除されるたびにターゲット行も削除されます。

Emp行を削除する前にDeptを削除すると、子レコードの検出という制約の例外が発生するため、1対多リレーションシップでは重要な事項です。

privately-ownedをtrueに設定すると、ソース行が削除される前にデータベース・アダプタにより子レコードが自動的に削除されます。XMLでは、すべてがプライベートに所有されているとみなされるため、このタグはデフォルトでtrueに設定されています。
<uses-batch-reading>false/trueおよび<uses-joining>false/true

データベースからディテール行とともに行を読み取ることに関して、2つの主要な最適化方法があります。

次に、TopLinkで2つの部門オブジェクト（1と2）およびその従業員の読取りに使用されるSELECT文を示します。

最適化前:
```
SELECT DEPT_COLUMNS FROM DEPT WHERE (subQuery)
SELECT EMP_COLUMNS FROM EMP WHERE (DEPTID = 1)
SELECT EMP_COLUMNS FROM EMP WHERE (DEPTID = 2)
```
バッチ読取り:
```
SELECT DEPT_COLUMNS FROM DEPT WHERE (subQuery)
SELECT EMP_COLUMNS FROM EMP e, DEPT d WHERE ((subQuery) AND (e.DEPTID =
d.DEPTID))
```
結合読取り:
```
SELECT DEPT_COLUMNS, EMP_COLUMNS FROM DEPT d, EMP e WHERE ((subQuery) AND
e.DEPTID = d.DEPTID))
```
結合読取りはより高度ですが、現状では1対1マッピングでしか機能しません。また、結合が外部結合ではないため、ディテール・レコードはNULLにできません。

そのため、デフォルトでは結合読取りではなく、バッチ読取りが有効になっています。パフォーマンスを向上させるため、簡単に変更できます。

問合せに実際のSQLを指定すると、その問合せに対してはバッチ読取りも結合読取りも行われません。バッチ読取りまたは結合読取りを使用するには、実際のSQLを使用できません。

toplink_mappings.xmlに別のプロパティを設定できます。

4.5.3 サービス定義（WSDL）

アダプタ構成ウィザードによって生成されたWSDLにより、アダプタ・サービスが定義されます。このWSDLでは、サービスによって公開される様々な操作が指定されます。表4-10に、ウィザードでの選択内容に基づいて生成される操作を指定します。

表4-10 アダプタ構成ウィザードによって生成されるWSDL操作

アダプタ構成ウィザードの選択内容	生成されるWSDL操作
挿入/更新	`insert、update、merge、write、queryByExample`
削除	`delete、queryByExample`
選択	`serviceNameSelect、queryByExample`
表の新規レコードまたは更新されたレコードをポーリング	`receive`

前述の操作のreceiveはBPELのreceiveアクティビティと関連付けられています。一方、その他の操作はBPELのinvokeアクティビティと関連付けられています。前述の操作の詳細は、「WebサービスとしてのSQL操作」を参照してください。

この項では、生成されるWSDLのデータベース・アダプタ固有のパラメータを説明します。これは、生成されるWSDLのすべてのパラメータの情報が必要な上級ユーザーを対象としています。

指定されたデータベース・アダプタ・サービスは、データソースの継続的なポーリング（JCAアクティブ化への変換）、または一度のみのDML操作の実行（JCA相互作用への変換）のいずれかです。継続的にポーリングする場合、WSDLに含まれるのは、バインディング・セクションで定義された対応するアクティブ化仕様が指定された1つのreceive操作のみです。一度のみのDML操作の場合、WSDLに含まれるのは複数の操作で、そのすべてにバインディング・セクションで定義された対応する相互作用の仕様があります。

表4-11に、前述の各操作に関連付けられたJCAアクティブ化/相互作用の仕様を示します。

表4-11 操作およびJCAアクティブ化/相互作用の仕様

WSDL操作	JCAアクティブ化/相互作用の仕様
`insert、update、merge、write、delete`	`oracle.tip.adapter.db.DBWriteInteractionSpec`
`select、queryByExample`	`oracle.tip.adapter.db.DBReadInteractionSpec`
`receive`	`oracle.tip.adapter.db.DBActivationSpec`

4.5.3.1 DBWriteInteractionSpec

次のコード・サンプルで、Movies表に書込みを行うmovieサービスに対応するバインディング・セクションを示します。

    <binding name="movie_binding" type="tns:movie_ptt">
        <jca:binding />
        <operation name="merge">
            <jca:operation
                InteractionSpec="oracle.tip.adapter.db.DBWriteInteractionSpec"
                DescriptorName="BPELProcess1.Movies"
                DmlType="merge"
                MappingsMetaDataURL="toplink_mappings.xml" />
            <input/>
        </operation>
        <operation name="insert">
            <jca:operation
                InteractionSpec="oracle.tip.adapter.db.DBWriteInteractionSpec"
                DescriptorName="BPELProcess1.Movies"
                DmlType="insert"
                MappingsMetaDataURL="toplink_mappings.xml" />
            <input/>
        </operation>
        <operation name="update">
            <jca:operation
                InteractionSpec="oracle.tip.adapter.db.DBWriteInteractionSpec"
                DescriptorName="BPELProcess1.Movies"
                DmlType="update"
                MappingsMetaDataURL="toplink_mappings.xml" />
            <input/>
        </operation>
        <operation name="write">
            <jca:operation
                InteractionSpec="oracle.tip.adapter.db.DBWriteInteractionSpec"
                DescriptorName="BPELProcess1.Movies"
                DmlType="write"
                MappingsMetaDataURL="toplink_mappings.xml" />
            <input/>
        </operation>
        <operation name="delete">
            <jca:operation
                InteractionSpec="oracle.tip.adapter.db.DBWriteInteractionSpec"
                DescriptorName="BPELProcess1.Movies"
                DmlType="delete"
                MappingsMetaDataURL="toplink_mappings.xml" />
            <input/>
    </binding>

表4-12で、DBWriteInteractionSpecパラメータを説明します。

表4-12 DBWriteInteractionSpecパラメータ

パラメータ	説明	更新メカニズム
`DescriptorName`	書込み対象のルート・データベース表への間接参照	ウィザードにより自動的に更新されます。手動で変更しないでください。
`DmlType`	操作のDML型（`insert`、`update`、`merge`、`write`）	ウィザードにより自動的に更新されます。手動で変更しないでください。
`MappingsMetaDataURL`	リレーショナルからXMLへのマッピングを含むファイルへの参照（`toplink_mappings.xml`）	ウィザードにより自動的に更新されます。手動で変更しないでください。

4.5.3.2 DBReadInteractionSpec

次のコード例は、Movies表への問合せを行うmovieサービスに対応します。

 <binding name="movie_binding" type="tns:movie_ptt">
        <jca:binding />
        <operation name="movieSelect">
            <jca:operation
                InteractionSpec="oracle.tip.adapter.db.DBReadInteractionSpec"
                DescriptorName="BPELProcess1.Movies"
                QueryName="movieSelect"
                MappingsMetaDataURL="toplink_mappings.xml" />
            <input/>
        </operation>
        <operation name="queryByExample">
            <jca:operation
                InteractionSpec="oracle.tip.adapter.db.DBReadInteractionSpec"
                DescriptorName="BPELProcess1.Movies"
                IsQueryByExample="true"
                MappingsMetaDataURL="toplink_mappings.xml" />
            <input/>
        </operation>
    </binding>

表4-13で、DBReadInteractionSpecパラメータを説明します。

表4-13 DBReadInteractionSpecパラメータ

パラメータ	説明	更新メカニズム
`DescriptorName`	問合せ対象のルート・データベース表への間接参照	ウィザードにより自動的に更新されます。手動で変更しないでください。
`QueryName`	リレーショナルからXMLへのマッピングのファイル内の`SELECT`問合せへの参照	ウィザードにより自動的に更新されます。手動で変更しないでください。
`IsQueryByExample`	この問合せが`queryByExample`かどうかを識別	ウィザードにより自動的に更新されます。手動で変更しないでください。このパラメータは`queryByExample`にのみ必要です。
`MappingsMetaDataURL`	リレーショナルからXMLへのマッピングを含むファイルへの参照（`toplink_mappings.xml`）	ウィザードにより自動的に更新されます。手動で変更しないでください。

4.5.3.3 DBActivationSpec

次のコード例で、DeletePollingStrategyを使用してMovies表のポーリングを行うMovieFetchサービスに対応するバインディング・セクションを示します。

    <binding name="MovieFetch_binding" type="tns:MovieFetch_ptt">
        <pc:inbound_binding/>
        <operation name="receive">
            <jca:operation
                ActivationSpec="oracle.tip.adapter.db.DBActivationSpec"
                DescriptorName="BPELProcess1.Movies"
                QueryName="MovieFetch"
                PollingStrategyName="DeletePollingStrategy"
                MaxRaiseSize="1"
                MaxTransactionSize="unlimited"
                PollingInterval="5"
                MappingsMetaDataURL="toplink_mappings.xml" />
        <input/>
        </operation>
    </binding>

表4-14で、DBActivationSpecパラメータを説明します。

表4-14 DBActivationSpecパラメータ

パラメータ	説明	更新メカニズム
`DescriptorName`	問合せ対象のルート・データベース表への間接参照	ウィザードにより自動的に更新されます。手動で変更しないでください。
`QueryName`	リレーショナルからXMLへのマッピングのファイル内の`SELECT`問合せへの参照	ウィザードにより自動的に更新されます。手動で変更しないでください。
`PollingStrategyName`	使用するポーリング計画を識別	ウィザードにより自動的に更新されます。手動で変更しないでください。
`PollingInterval`	新規イベントでルート・データベース表をポーリングする頻度を指定（秒単位）	ウィザードにより自動的に更新されます。手動で変更しないでください。
`MaxRaiseSize`	BPELエンジンに一度に渡すデータベース・レコードの最大数を指定	生成されたWSDLで手動で変更します。
`MaxTransactionSize`	1つのデータベース・トランザクションの一部として処理する行の最大数を指定	生成されたWSDLで手動で変更します。
`MappingsMetaDataURL`	リレーショナルからXMLへのマッピングを含むファイルへの参照（`toplink_mappings.xml`）	ウィザードにより自動的に更新されます。手動で変更しないでください。

次のコード例で、LogicalDeletePollingStrategyを使用してMovies表のポーリングを行うMovieFetchサービスに対応するバインディング・セクションを示します。

    <binding name="PollingLogicalDeleteService_binding"
             type="tns:PollingLogicalDeleteService_ptt">
        <pc:inbound_binding/>
        <operation name="receive">
            <jca:operation
                ActivationSpec="oracle.tip.adapter.db.DBActivationSpec"
                DescriptorName="PollingLogicalDeleteStrategy.Movies"
                QueryName="PollingLogicalDeleteService"
                PollingStrategyName="LogicalDeletePollingStrategy"
                MarkReadFieldName="DELETED"
                MarkReadValue="TRUE"
                MarkReservedValue="MINE"
                MarkUnreadValue="FALSE"
                MaxRaiseSize="1"
                MaxTransactionSize="unlimited"
                PollingInterval="10"
                MappingsMetaDataURL="toplink_mappings.xml" />
        <input/>
        </operation>
    </binding>

表4-15で、LogicalDeletePollingStrategyのその他すべてのDBActivationSpecパラメータを説明します。

表4-15 LogicalDeletePollingStrategyのDBActivationSpecパラメータ

パラメータ	説明	更新メカニズム
`MarkReadFieldName`	行を読取りとマークする際に使用するデータベース列を指定。	ウィザードにより自動的に更新されます。手動で変更しないでください。
`MarkReadValue`	データベース列が行を読取りとマークするよう設定される値を指定。	ウィザードにより自動的に更新されます。手動で変更しないでください。
`MarkReservedValue`	データベース列が行を予約済とマークするよう設定される値を指定。このパラメータはオプションです。複数のアダプタ・インスタンスで同じデータベース・アダプタ・サービスを提供している際に使用できます。	ウィザードにより自動的に更新されます。手動で変更しないでください。
`MarkUnreadValue`	データベース列が行を未読取りとマークするよう設定される値を指定。このパラメータはオプションです。データベース・アダプタで処理する必要のある特定の行を確認する際に使用します。	ウィザードにより自動的に更新されます。手動で変更しないでください。

次のコード例で、SequencingPollingStrategyを使用してMovies表のポーリングを行うMovieFetchサービスに対応するバインディング・セクションを示します。

    <binding name="PollingLastReadIdStrategyService_binding"
             type="tns:PollingLastReadIdStrategyService_ptt">
        <pc:inbound_binding/>
        <operation name="receive">
            <jca:operation
                ActivationSpec="oracle.tip.adapter.db.DBActivationSpec"
                DescriptorName="PollingLastReadIdStrategy.Movies"
                QueryName="PollingLastReadIdStrategyService"
                PollingStrategyName="SequencingPollingStrategy"
                SequencingFieldName="SEQUENCENO"
                SequencingTableNameFieldValue="MOVIES"
                SequencingTableName="PC_SEQUENCING"
                SequencingTableNameFieldName="TABLE_NAME"
                SequencingTableValueFieldName="LAST_READ_ID"
                MaxRaiseSize="1"
                MaxTransactionSize="unlimited"
                PollingInterval="10"
                MappingsMetaDataURL="toplink_mappings.xml" />
        <input/>
        </operation>
    </binding>

表4-16で、SequencingPollingStrategyのその他すべてのDBActivationSpecパラメータを説明します。

表4-16 SequencingPollingStrategyのDBActivationSpecパラメータ

パラメータ	説明	更新メカニズム
`SequencingFieldName`	一定量で増加するデータベース列を指定。	ウィザードにより自動的に更新されます。手動で変更しないでください。
`SequencingFieldType`	一定量で増加するデータベース列の型を指定。このパラメータはオプションです。型が`NUMBER`でない場合に使用します。	ウィザードにより自動的に更新されます。手動で変更しないでください。
`SequencingTableNameFieldValue`	このポーリング問合せのルート・データベース表を指定。	ウィザードにより自動的に更新されます。手動で変更しないでください。
`SequencingTableName`	ヘルパー表として機能しているデータベース表の名前。	ウィザードにより自動的に更新されます。手動で変更しないでください。
`SequencingTableNameFieldName`	ルート・データベース表の名前の保存に使用されているヘルパー表のデータベース列を指定。	ウィザードにより自動的に更新されます。手動で変更しないでください。
`SequencingTableValueFieldName`	ルート・データベース表の名前の最終処理行の順序番号の保存に使用されているヘルパー表のデータベース列を指定。	ウィザードにより自動的に更新されます。手動で変更しないでください。

WSDLのserviceセクションの詳細は、「デプロイ」を参照してください。

4.5.4 XMLスキーマ定義（XSD）

ウィザードにより、データベース・スキーマからオブジェクトのXMLスキーマ表現が生成されます。このスキーマはBPELプロセスによって使用されます。

たとえば、Moviesという名前の表からは次のXMLスキーマ表現が生成されます。

<?xml version = '1.0' encoding = 'UTF-8'?>
<xs:schema
targetNamespace="http://xmlns.oracle.com/pcbpel/adapter/db/top/SelectAllByTitle"
xmlns="http://xmlns.oracle.com/pcbpel/adapter/db/top/SelectAllByTitle"
elementFormDefault="unqualified" attributeFormDefault="unqualified"
xmlns:xs="http://www.w3.org/2001/XMLSchema">
   <xs:element name="MoviesCollection" type="MoviesCollection"/>
   <xs:element name="Movies" type="Movies"/>
   <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="director" type="xs:string" minOccurs="0"
                     nillable="true"/>
         <xs:element name="genre" type="xs:string" minOccurs="0" nillable="true"/>
         <xs:element name="rated" type="xs:string" minOccurs="0" nillable="true"/>
         <xs:element name="rating" type="xs:string" minOccurs="0"
                     nillable="true"/>
         <xs:element name="releaseDate" type="xs:dateTime" minOccurs="0"
                     nillable="true"/>
         <xs:element name="runTime" type="xs:double" minOccurs="0"
                     nillable="true"/>
         <xs:element name="starring" type="xs:string" minOccurs="0"
                     nillable="true"/>         <xs:element name="status" type="xs:string" minOccurs="0"
                     nillable="true"/>
         <xs:element name="synopsis" type="xs:string" minOccurs="0"
                     nillable="true"/>
         <xs:element name="title" type="xs:string"/>
         <xs:element name="totalGross" type="xs:double" minOccurs="0"
                     nillable="true"/>
         <xs:element name="viewerRating" type="xs:string" minOccurs="0"
                     nillable="true"/>
      </xs:sequence>
   </xs:complexType>
   <xs:element name="findAllInputParameters" type="findAll"/>
   <xs:complexType name="findAll">
      <xs:sequence/>
   </xs:complexType>
   <xs:element name="SelectAllByTitleServiceSelect_titleInputParameters"
type="SelectAllByTitleServiceSelect_title"/>
   <xs:complexType name="SelectAllByTitleServiceSelect_title">
      <xs:sequence>
         <xs:element name="title" type="xs:string" minOccurs="1" maxOccurs="1"/>
      </xs:sequence>
   </xs:complexType>
</xs:schema>

これは生成されたファイルです。このファイルを変更しても、アダプタの動作に影響はありません。データベース・アダプタによって生成および消費されるXMLファイルの宣言です。

基礎となるtoplink_mappings.xmlを更新した場合、XSDファイルを変更する必要があります。その場合、アダプタ構成ウィザードを編集モードで再実行し、両方のファイルを再生成します。

生成されたXSDにより、必須である主キー属性を除き、すべての要素にminOccurs=0のオプションとしてフラグが設定されます。

注意:

XSDファイルを手動で変更してデータベース・アダプタを構成しないでください。

4.5.5 デプロイ

データベース・アダプタ・サービスの定義およびBPELプロセスの設計が完了したら、プロセスをコンパイルしてOracle BPEL Serverにデプロイします。JDeveloper BPEL Designerの「アプリケーション・ナビゲータ」で、BPELプロジェクトを右クリックして「デプロイ」を選択します。デプロイの詳細は、『Oracle BPEL Process Manager開発者ガイド』の第19章「BPELプロセスのデプロイおよびドメイン管理」を参照してください。

4.5.5.1 データベース・アダプタによる接続情報の取得方法

図4-71に、以降の各項で説明するように、WSDLファイル、oc4j-ra.xmlファイルまたはdata-sources.xmlファイルの3つの可能性のあるソースから、データベース・アダプタがどのようにして接続情報を取得するかを示します。

図4-71 データベース・アダプタによる接続情報の取得方法

「図4-71 データベース・アダプタによる接続情報の取得方法」の説明

4.5.5.2 デフォルトでのデプロイ

データベース・アダプタを使用してプロセスをデプロイする場合は、個別のデータベース・アダプタ・インスタンスがデプロイ済でアプリケーション・サーバー上で使用可能かどうかに応じて、デプロイの性質が異なります。本番のデプロイの詳細は、「本番のデプロイ」を参照してください。

注意:

デフォルトでのデプロイの場合は、例4-1に示すように、データベース・アダプタ・ウィザードを実行する際に、データベースから表をインポートするための接続情報が必要です。便利な機能として、wsdlファイルが書き込まれる際に、設計時に使用した接続情報が含まれます。このように、wsdlには正常な実行に必要な情報がすべて含まれているため、ビジネス・プロセスを即時にデプロイできます。

デフォルトでのデプロイが使用されるのは、本番のデプロイが適切に設定されるまでの間のみです。本番では、この接続情報（mcf.*プロパティ）をwsdlから削除し、本番のデプロイに必要な場所属性のみを残すことができます。本番には本番のデプロイを使用する必要があります。

例4-1に、WSDLのmcf.*プロパティに指定されたデータベース接続情報を示します。

例4-1 mcf.*プロパティのデータベース接続情報を示すWSDLのコード例

<!-- Your runtime connection is declared in
J2EE_HOME/application-deployments/default/DbAdapter/oc4j-ra.xml.
These 'mcf' properties here are from your design time connection and save you from
having to edit that file and restart the application server if eis/DB/scott is
missing.
These 'mcf' properties are safe to remove.
-->
<service name="get">
  <port name="get_pt" binding="tns:get_binding">
    <jca:address location="eis/DB/scott"
      UIConnectionName="scott"
      ManagedConnectionFactory="oracle.tip.adapter.db.DBManagedConnectionFactory"
      mcf.DriverClassName="oracle.jdbc.driver.OracleDriver"
      mcf.PlatformClassName="oracle.toplink.oraclespecific.Oracle9Platform"
      mcf.ConnectionString="jdbc:oracle:thin:@mypc.home.com:1521:orcl"
      mcf.UserName="scott"
      mcf.Password="7347B141D0FBCEA077C118A5138D02BE"
    />
  </port>
</service>

注意:

データベース・アダプタでWSDLに指定されている接続情報が使用される場合、接続プーリングはありません。

4.5.5.3 本番のデプロイ

第4.1.2項「設計の概要」を参照してください。設計時には、「アダプタ構成ウィザード: サービス接続」ページでeis/DB/<JdevConnectionName>などを指定しました。本番のデプロイでは、そのJNDI名を持つデータベース・アダプタ・インスタンスがデプロイ済で、アプリケーション・サーバー上で使用可能になっている必要があります。この項では、この前提条件を満たす方法を説明します。

接続プールがdata-sources.xml内で構成されるのと同様の方法で、ランタイム・インスタンスがデータベース・アダプタのoc4j-ra.xmlファイル内で構成されます。これらは、JNDIを介してdata-sources.xml内の接続プール名を参照します。

Oracle BPEL Process Managerの場合、oc4j-ra.xmlは次の場所にあります。

Oracle_Home\bpel\system\appserver\oc4j\j2ee\home\
application-deployments\default\DbAdapter\oc4j-ra.xml

BPEL Process Manager for OracleAS Middle Tierインストールの場合、oc4j-ra.xmlは次の場所にあります。

Oracle_Home\j2ee\OC4J_BPEL\application-deployments\default\DBAdapter\oc4j-ra.xml

oc4j-ra.xmlファイルの接続情報は、アダプタ構成ウィザードでは生成されません。このファイルを手動で更新し、Oracle BPEL Serverを再起動してoc4j-ra.xmlへの更新内容を反映します。

アプリケーション・サーバーは、すべてのアプリケーションの接続を管理してプーリングします。これにより、単一の接続プール、高可用性、特殊なRAC構成、XA/トランザクションのサポート、パスワード・インダイレクションおよび単一構成ファイルdata-sources.xmlが、アプリケーション間で共有されます。そのため、データベース、AQおよびJMSアダプタのoc4j-ra.xmlファイルが接続情報を含む必要はなく、単にデータソースが名前で参照されます。これは、リリース10.1.3.1の推奨アプローチでありデフォルトです。

注意:

WSDLはJCAアダプタ（oc4j-ra.xml内のeis/DB/BPELSamples）を指し、JCAアダプタはデータソース（data-sources.xml内のjdbc/BPELSamples）を指します。一般的に犯しやすい過ちは、ウィザードでJNDI名をデータソース名に直接設定することです。

デプロイメント・ディスクリプタ・ファイル（oc4j-ra.xml）には、4つの重要なプロパティlocation、xADataSourceName、dataSourceNameおよびplatformClassNameがあります。

location

ウィザードの実行時にランタイムのJNDI名を入力したことに注意してください。これはeis/DB/<JdeveloperConnectionName>にデフォルト設定されます。本番時には、oc4j-ra.xmlデプロイメント・ディスクリプタに対応するエントリが存在することを確認してください。

xADataSourceNameおよびnonXaDataSourceName

xADataSourceNameおよびdataSourceNameは、それぞれグローバル・トランザクションとローカル・トランザクションのデータソースを指します。

Oracle BPEL Process Managerの場合、data-sources.xmlは次の場所にあります。

Oracle_Home\bpel\system\appserver\oc4j\j2ee\home\config\data-sources.xml

Oracle BPEL Process Manager for OracleAS Middle Tierインストールの場合、data-sources.xmlは次の場所にあります。

Oracle_Home\j2ee\OC4J_BPEL\config\data-sources.xml

data-sources.xmlに次のコードが含まれているとします。

<!-- Connection pool for oracle lite -->

  <connection-pool name="BPELPM_CONNECTION_POOL">
    <connection-factory factory-class="oracle.lite.poljdbc.POLJDBCDriver"
      user="system"
      password="any"
      url="jdbc:polite4@127.0.0.1:100:orabpel" />
  </connection-pool>

  <managed-data-source name="BPELServerDataSource"
          connection-pool-name="BPELPM_CONNECTION_POOL"
      jndi-name="jdbc/BPELServerDataSource" tx-level="global"/>

  <managed-data-source name="BPELServerDataSourceWorkflow"
          connection-pool-name="BPELPM_CONNECTION_POOL"
      jndi-name="jdbc/BPELServerDataSourceWorkflow" tx-level="local"/>

この場合、oc4j-ra.xmlのエントリは次のようになります。

<connector-factory location="eis/DB/BPELSamples" connector-name="Database
Adapter">
<config-property name="xADataSourceName" value="jdbc/BPELServerDataSource"/>
<config-property name="dataSourceName"
                 value="jdbc/BPELServerDataSourceWorkflow"/>
...

常にxADataSourceNameを使用する（tx-level="global"データソースを指す）ことをお薦めします。 xADataSourceNameおよびdataSourceNameを指定すると（tx-level="local"データソースを指すと）、パフォーマンスの読取りにdataSourceNameが使用されることがあります（複数のインバウンド・ポーリング・スレッドの場合）。データベース・アダプタがグローバル・トランザクションと同期化されないのは、dataSourceNameを指定した場合のみです。

PlatformClassName

これは、接続先がOracle、DB2、SQLServer、他のデータベースのいずれであるかを示します。

表4-17に、データベース・プラットフォームの変数である、高度なプロパティを示します。次の変数のいずれかにDatabasePlatform名を設定します。

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

データベース	PlatformClassName
Oracle9以上（10gを含む）	`oracle.toplink.platform.database.Oracle9Platform`
Oracle9+（オプション） `select`での（`VARCHAR2`ではなく）`CHAR`値のパディングを回避するには、付録A「トラブルシューティングおよび解決策」の「CHAR(X)またはNCHAR列に対するアウトバウンドのSELECTで行が返されない」を参照してください。	`oracle.toplink.platform.database.Oracle9Platform`
Oracle8	`oracle.toplink.platform.database.Oracle8Platform`
Oracle7	`oracle.toplink.platform.database.OraclePlatform`
DB2	oracle.toplink.platform.database.DB2Platform
AS400上のDB2	oracle.tip.adapter.db.toplinkext.DB2AS400Platform
Informix	`oracle.toplink.platform.database.InformixPlatform`
Sybase	`oracle.toplink.platform.database.SybasePlatform`
SQLServer	`oracle.toplink.platform.database.SQLServerPlatform`
その他のデータベース	`oracle.toplink.platform.database.DatabasePlatform`

4.5.5.4 oc4j-ra.xmlファイルの高度なプロパティ

この項では、oc4j-ra.xmlファイルの次の高度なプロパティについて説明します。

管理対象のコネクション・ファクトリ・エントリを使用して構成可能なプロパティ
ra.xmlおよびoc4j-ra.xml内のプロパティ名の大/小文字区別
Oracle Enterprise Managerを介したoc4j-ra.xmlの編集

管理対象のコネクション・ファクトリ・エントリを使用して構成可能なプロパティ

次のプロパティは、oc4j-ra.xmlファイルの管理対象のコネクション・ファクトリ・エントリを使用して構成できます。

String connectionString
String userName
String password
String encryptionClassName
Integer minConnections
Integer maxConnections
Boolean useReadConnectionPool
Integer minReadConnections
Integer maxReadConnections
String dataSourceName
String driverClassName
Integer cursorCode
String databaseName
String driverURLHeader
Integer maxBatchWritingSize
String platformClassName
String sequenceCounterFieldName
String sequenceNameFieldName
Integer sequencePreallocationSize
String sequenceTableName
String serverName
Boolean shouldBindAllParameters
Boolean shouldCacheAllStatements
Boolean shouldIgnoreCaseOnFieldComparisons
Boolean shouldForceFieldNamesToUpperCase
Boolean shouldOptimizeDataConversion
Boolean shouldTrimStrings
Integer statementCacheSize
Integer stringBindingSize
String tableQualifier
Integer transactionIsolation
Boolean usesBatchWriting
Boolean usesByteArrayBinding
Boolean usesDirectDriverConnect
Boolean usesExternalConnectionPooling
Boolean usesExternalTransactionController
Boolean usesJDBCBatchWriting
Boolean usesNativeSequencing
Boolean usesNativeSQL
Boolean usesStreamsForBinding
Boolean usesStringBinding

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

DBConnectionFactory JavadocおよびDatabaseLogin Javadocの情報は、次のサイトにある「TopLink API Reference」を参照してください。

http://download-east.oracle.com/docs/cd/B10464_02/web.904/b10491/index.html

前述の任意のプロパティを構成するには、次にようにします。

ra.xmlファイルに次の内容を追加します。

<config-property>
    <config-property-name>usesJDBCBatchWriting</config-property-name>
    <config-property-type>java.lang.Boolean</config-property-type>
    <config-property-value>true</config-property-value>
  </config-property>

Oracle BPEL Process Managerの場合、ra.xmlは次の場所にあります。

Oracle_Home\bpel\system\appserver\oc4j\j2ee\home\connectors\
DbAdapter\DbAdapter\META-INF\ra.xml

BPEL Process Manager for OracleAS Middle Tierの場合、ra.xmlは次の場所にあります。

Oracle_Home\j2ee\OC4J_BPEL\connectors\DbAdapter\DbAdapter\META-INF\ra.xml

oc4j-ra.xmlファイルに次の内容を追加します。

<config-property name="usesJDBCBatchWriting" value="true"/>
Oracle BPEL Serverを再起動して変更内容を反映します。

データベース・アダプタのデプロイ前に、デフォルトのoc4j-ra.xmlおよびra.xmlファイルも更新できます。この方法では、一度デプロイしたら、アプリケーション・サーバーを再起動する必要はありません。

ra.xmlおよびoc4j-ra.xml内のプロパティ名の大/小文字区別

すべてのプロパティ名の大/小文字区別は、ra.xmlおよびoc4j-ra.xmlファイル内で正確に一致する必要があります。一致しないと、実行時にdomain.logファイルに次のようなエラー・メッセージが書き込まれます。

Type=Dequeue_ptt, operation=Dequeue
<2005-03-14 15:20:43,484> <ERROR> <default.collaxa.cube.activation>
<AdapterFram
ework::Inbound> Error while performing endpoint Activation: ORABPEL-12510<br>
Unable to locate the JCA Resource Adapter via WSDL port element jca:address.
The Adapter Framework is unable to startup the Resource Adapter specified in
the WSDL jca:address element:
@ {http://xmlns.oracle.com/pcbpel/wsdl/jca/}address:
location='eis/aqSample'

たとえば、AQアダプタ用のOracle_Home\bpel\system\appserver\oc4j\j2ee\home\application-deployments\default\AqAdapter\oc4j-ra.xmlファイルで、userNameプロパティに次の大/小文字規則が使用されているとします。

<config-property name="userName" value="scott"/>

この大/小文字区別は、AQアダプタ用の対応するOracle_Home\bpel\system\appserver\oc4j\j2ee\home\connectors\default\AqAdapter\AqAdapter\META-INF\ra.xmlファイル内のuserNameプロパティと一致する必要があります。

<config-property-name>userName</config-property-name>

Oracle Enterprise Managerを介したoc4j-ra.xmlの編集

Oracle Enterprise Managerからもリソース・アダプタをデプロイおよびアンデプロイできます。次の手順は、Oracle Enterprise Managerを介してdata-sources.xmlおよびoc4j-ra.xmlの両方を編集する方法を示しています。

BPELサーバー・プロセスを起動します。
インストール後に、「スタート」→「設定」→「コントロールパネル」→「管理ツール」→「サービス」を開きます。
Oracle-nnnProcessManager start upオプションを手動に変更します（nnnは、インスタンス名です）。次回のリブート時には、OPMNは起動しません。起動するには、次の手順を実行します。
1. 「スタート」→「ファイル名を指定して実行」をクリックします。
2. cmdと入力して「OK」をクリックし、コマンド・プロンプトを起動します。
3. 次のコマンドを入力してインストール・ディレクトリに移動します。
```
cd %SOAHOME%\opmn\bin
```
  %SOAHOME%を実際のパスで置き換えてください。次に例を示します。
```
cd c:\oracle\product\soabeta\opmn\bin
```
4. 次のコマンドを入力します。
```
opmnctl startall
```
5. 次のコマンドを入力して、サービスが正常に開始されたことを確認します。
```
opmnctl status
```
  注意:
  すべてのサービスを停止するには、次のように入力します。
  opmnctl stopall
次のURLを入力してOracle Enterprise Managerにログインします。

http://<host>:<port>/em

デフォルトのポートは8888、デフォルトのログイン・ユーザーIDはoc4jadmin、パスワードはwelcome1です。

次の手順に従って接続プールとデータソースを作成します。

「ホーム」リンクを選択します。
「管理」リンクを選択します。
「サービス/JDBCリソース」の「タスクに移動」アイコンをクリックします。
「接続プール」で「作成」ボタンをクリックします。
デフォルトを受け入れて「続行」をクリックします。

次の表に示す情報を入力します。

フィールド	値
名前	`appsSample_pool`
JDBC URL	データベースのURL 次に例を示します。 jdbc:oracle:thin:@<host>:1521:<sid>
ユーザー名	`apps`
パスワード	`apps`

残りのフィールドではデフォルトを受け入れます。

「終了」をクリックします。
新規接続プールの「接続テスト」アイコンをクリックします。
新規画面で「テスト」をクリックします。

メイン・ページに戻ります。接続成功メッセージが表示されます。エラー・メッセージが表示された場合は、URLと資格証明をチェックし、正しい情報を入力したことを確認します。
「終了」をクリックします。
「データソース」で「作成」をクリックします。
デフォルトを受け入れて「続行」をクリックします。
次の表に示す情報を入力します。

フィールド値

名前 appsDemoDS

JNDIロケーション jdbc/appsSampleDataSource

接続プール appsSample_pool

残りのフィールドではデフォルトを受け入れます。
「終了」をクリックします。

次の手順に従ってOracle Applicationsアダプタを作成します。
1. ページ上部で「OC4J: ホーム」ブレッドクラム・リンクを選択します。
2. 「アプリケーション」リンクを選択します。
3. アプリケーション・ツリーで「デフォルト」リンクを選択します。
4. 「モジュール」の下で「AppsAdapter」リンクを選択します。
5. 「コネクション・ファクトリ」リンクを選択します。
6. 「コネクション・ファクトリ」で「作成」をクリックします。
  
  「共有接続プール」セクションの「作成」ボタンではなく、画面上部の「作成」ボタンを使用する必要があることに注意してください。
7. デフォルトをすべて受け入れて「続行」をクリックします。
8. 「JNDIロケーション」にeis/Apps/appsSampleと入力します。
9. 「構成プロパティ」の下で、「xADataSourceName」にjdbc/appsSampleDataSourceと入力します。
  
  他のすべてのフィールドはデフォルト・エントリのままにします。
10. 「終了」をクリックします。

フィールド	値
名前	`appsDemoDS`
JNDIロケーション	j`dbc/appsSampleDataSource`
接続プール	appsSample_pool

4.5.5.5 比較: リリース10.1.3より前とリリース10.1.3以降

Oracle BPEL Process Manager 10.1.3では、デプロイメント・ディスクリプタにローカル接続情報（driverClassName、userName、password、connectionUrl、minConnections、maxConnections、minReadConnections、maxReadConnectionsなど）が含まれていません。かわりに、デプロイメント・ディスクリプタは別のファイルdata-sources.xmlを指します。これは、接続構成とプーリングをアプリケーション・サーバーに残すためです。また、推奨機能であるXAのサポート（同一トランザクションでの複数データベースへのコミット）には、アプリケーション・サーバーの接続プールを使用する必要があります。

したがって、これらのTopLink内部プーリング・プロパティは削除されていますが、ra.xmlに再び追加して高度なプロパティとして使用することもできます。

10.1.3よりも前のリリースでは、XAおよびアプリケーション・サーバーのプーリングは、dataSourceName、usesExternalConnectionPoolingおよびusesExternalTransactionControllerの組合せによりサポートされていました。これらは削除され、xaDataSourceNameおよびnonXaDataSourceNameのみで置き換えられています。

Oracle BPEL Process Manager 10.1.3への移行時に変更する必要のあるプロパティを表に示します。

表4-18 Oracle BPEL Process Manager 10.1.3で使用されるプロパティ

10.1.3よりも前のリリース	リリース10.1.3以降
`dataSourceName`は空でなく、`usesExternalConnectionPooling` = `true`、`useExternalTransactionController` = `true`	`xADataSourceName`を指定。TopLink以外の使用例で新規の読取り接続プーリング・サポートを利用するには、オプションで`dataSourceName`を追加。
`dataSourceName`は空でなく、`usesExternalConnectionPooling` = `true`、`useExternalTransactionController` = `false`	`dataSourceName`のみを指定。
dataSourceName`は空でなく、usesExternalConnectionPooling = false、useExternalTransactionController = false`	`xADataSourceName`および`dataSourceName`を空の文字列に設定。ローカル接続情報（`driverClassName`、`userName`、`password`、`connectionUrl`、`minConnections`、`maxConnections`、`minReadConnections`、`maxReadConnections`）を高度なプロパティとして再び追加。

4.5.6 パフォーマンス

データベース・アダプタは、多くのパフォーマンス最適化で事前構成されています。ただし、次の項で説明するように、変更を加えてデータベースへのラウンドトリップの回数を減らせます。

4.5.6.1 パフォーマンスに関する使用例

パフォーマンス・チューニングは、次に示すチュートリアルで説明されています。

DirectSQLPerformance
MultiTablesPerformance
../polling/DistributedPolling

リリース10.1.3.1には新規のコード・パスが追加されています。ここでは、単純なシナリオ（delete polling strategy、insert、flat tablesなど）が最大パフォーマンスを得るために大幅に最適化されています。そのため、2つの主なパフォーマンス・サンプル（一方はダイレクトSQLに関連、他方はより高機能のアダプタ全般に関連）は存在しません。アダプタでは、やや高速なコード・パスが許可される構成に含まれている場合は自動検出されます。

これらのファイルを参照するには、次の場所へ移動します。

Oracle_Home\bpel\samples\tutorials\122.DBAdapter\advanced\endToEnd

4.5.6.2 パフォーマンス・ヒット・リスト

次のパフォーマンス・ヒット・リストは、MultiTablesPerformanceのREADMEから抜粋したものです。このリストには、最善の構成と、各種パフォーマンス・オプションの相対的な効果に関する情報が含まれています。理想的（毎秒280行のスループット）な構成からの単一の変更によるバリエーションを次に示します。

他のマシン上のOracle 10g Windowsデータベース（ping時間は約40ミリ秒）（同一マシン上のデータベースと比較）: 毎秒70行（10,000行）-75%の低下/+300%の向上
MaxTransactionSize/MaxRaiseSize=2/2（100/100と比較）: 毎秒80行（10,000行）-71% / +250%
batch-reading=false（toplink_mappings.xmlでtrueに設定した場合と比較）: 毎秒104行（10,000行）-63% / +169%
DeletePollingStrategy（LogicalDelete、NumberOfThreads=1と比較）: 毎秒120行（10,000行）-57% / +133%
usesBatchWriting =false（oc4j-ra.xmlでtrueに設定した場合と比較）: 毎秒127行（10,000行）-55% / +120%
OptimizeMerge="false"（trueに設定した場合と比較）: 毎秒175行（10,000行）-38% / +60%
BPEL dehydration on（offに設定した場合と比較）: 毎秒222行（10,000行）-21% / +26%
NumberOfThreads=1（6に設定した場合と比較）: 毎秒227行（10,000行） * -19% / +23%

注意:
理想的とは、DeletePollingStrategyの最善の構成（スループットは毎秒120行）と同じ構成です。
データベース上で主/外部キーを指定しない場合（指定した場合と比較）: 毎秒270行（10,000行）-4% / +4%（毎秒267行（20,000行））
Insert（Mergeと比較）: 毎秒303行（10,000行）-8% / +8%
UseBatchDestroy="false"（trueに設定した場合と比較）: 毎秒312行（10,000行）-10% / +11%

前述した最初の7つのパフォーマンス・ヒットはいずれも、ほぼデータベースへのラウンドトリップ回数および各トリップのネットワーク・コストにのみ直接関係します。また、deleteはきわめて高コストの操作のように思われ、外部キー制約NumberOfThreadsを1に設定する必要もあります。

4.5.6.3 アウトバウンド書込み: merge、writeまたはinsertからの選択

アダプタ構成ウィザードを使用して「挿入/更新」を選択した場合、WSDLにはmerge（デフォルト）、insert、updateおよびwriteの操作が含まれるWSDLが提供されます。単純なシナリオでは不要な高度な機能を回避するために、最後の3つでは同じ名前のTopLink問合せが呼び出されます。invokeアクティビティをダブルクリックし、別の操作を選択することで変更できます。mergeは最も負荷が高く、writeおよびinsertが続きます。

mergeでは、まず各要素の読取りおよび変更箇所の算出が行われます。行が変更されていない場合、更新されていません。（存在チェックの）追加読取りおよび複雑な変更の算出では、オーバーヘッドがかなり増加します。単純な場合では、安全に回避できます。変更したのが2行のみの場合、5行すべてを更新しても問題ではありません。ただし、複雑な場合は、同じではありません。ディテール・レコードが100のマスター・レコードがあり、マスターで2行、1つのディテールで2行のみ変更した場合、mergeでは2行でそれら4列の更新が行われます。writeでは、101行のすべての列で書込みが行われます。また、mergeの速度は遅くなりますが、書込み数を最小化することで実際にはデータベースの負荷を軽減できます。

insertでは、存在チェックが使用されず追加のオーバーヘッドもないため、最も負荷の少ない操作です。読取りはなく書込みのみです。挿入操作が多いことがわかっている場合は、insertを使用してBPELプロセス内の一意のキー制約のSQL例外を取得します。かわりにmergeまたはupdateを実行できます。新規と既存のオブジェクトが混在している場合（新規のディテール行が複数含まれるマスター行など）は、mergeを使用します。updateはinsertと似ています。

パフォーマンスを監視するには、デバッグ・ロギングを有効にし、様々な入力に対するSQLを監視します。

4.5.6.4 TopLinkキャッシュ: 使用する時期

キャッシュはTopLinkの重要なパフォーマンス機能です。ただし、失効データの問題は管理が難しい場合があります。デフォルトでは、データベース・アダプタはWeakIdentityMapを使用します。これは、キャッシュが循環参照の解決にのみ使用され、エントリはJava仮想マシンによって即座に再利用されることを意味します。循環がない場合は、NoIdentityMapに切り替えられます（XMLには循環がないことが理想です）。TopLinkのデフォルトはSoftCacheWeakIdentityMapです。これにより、データベースで最も頻繁に使用される行が、キャッシュに存在する可能性が高くなります。

キャッシュに関するより詳細な記事は、次のサイトを参照してください。

http://www.oracle.com/technology/tech/java/newsletter/november04.html

4.5.6.5 存在チェック

mergeのパフォーマンスを最適化する方法の1つは、データベースをチェックする存在チェックを行わないことです。行が新規の場合には、行全体ではなく主キーのみが返されるため、存在チェックの問題点もやや改善されます。ただし、mergeの性質上、存在チェックが終了すると、いずれにせよ行全体が読み込まれて変更箇所が算出されます。そのため、merge操作中は、更新するすべての行でデータベースへのラウンドトリップが1つ追加されます。

AがマスターでBがプライベートに所有される子である場合、ルート・ディスクリプタ/表および任意の子表ではキャッシュのチェックを使用することをお薦めします。Aが存在しない場合、Bも存在しません。また、Aが存在する場合、Aの読取りの一部としてBもすべてロードされるため、キャッシュのチェックを使用できます。

4.5.6.6 インバウンド・ポーリング: maxRaiseSize

このパラメータでは、BPELエンジンに一度に渡すXMLレコードの最大数を指定します。たとえば、maxRaiseSize = 10と設定すると、一度に10のデータベース・レコードが渡されます。読取り（インバウンド）では、maxRaiseSize = 0（バインドなし）と設定できます。これは、1000行読み取ると、要素が1000のXMLが1つ作成されることを意味し、そのXMLは単一のOracle BPEL Process Managerインスタンスを介して渡されます。アウトバウンド側のmergeでは、1000すべてが1つのグループに取り込まれ、バッチ書込みで一度に書き込まれます。

大きなペイロードの公開には、maxRaiseSizeパラメータを使用します。

4.5.6.7 インバウンド・ポーリング: ポーリング計画の選択

ポーリング計画の選択も重要です。各行を個別に削除する必要があるため、削除ポーリング計画は使用しません。順序付けポーリング計画は、ヘルパー表への更新が1つある1000行を破損する可能性があります。

4.5.6.8 リレーションシップの読取り（バッチ属性および結合属性の読取り）

1対多および1対1リレーションシップのバッチ読取りは、デフォルトでオンになっています。1対1リレーションシップには、パフォーマンスが多少向上する結合読取りも使用できます。

4.5.6.9 接続プーリング

アダプタのローカル接続プールまたはアプリケーション・サーバーのデータソースを使用している場合は、接続プールを構成できます。データベース接続の作成は負荷の高い操作です。負荷の高い状態でも、上限を超えるのはminConnectionsのみが理想的です。一度にそれ以上の接続を常時使用している場合には、接続の設定と解除に時間がかかる可能性があります。データベース・アダプタにも読取り接続プールがあります。読取りでは1つの接続を同時に使用するユーザー数には制限がないため、読取り接続はより負荷が低く、ほとんどのJDBCドライバでサポートされている機能です。

4.5.6.10 インバウンド分散ポーリング

データベース・アダプタは、データベース上の未処理の行数を計算するよう設計されています。デフォルトでは、1つまたは10,000のデータベース行を、データベースへの3回のラウンドトリップで読み取って処理できます。最も負荷の高い操作は定数に制限されています。また、データベース・アダプタを分散環境用に構成できます。

ロード・バランシング: MaxTransactionSizeおよびペシミスティック・ロック

図4-72に示すように、最初のポーリング問合せでロックを取得することで、データベース・アダプタが分散環境で安全に機能することを可能にする単純なオプションを設定できます。SQL用語で言い換えると、最初のSELECTをSELECT...FOR UPDATEに変更します。

図4-72 ロックの取得

「図4-72 ロックの取得」の説明

すべてのポーリング計画の動作は次のとおりです。

未処理の行をすべて読取ります。
それらの行を処理します。
コミットします。

あるインスタンスが手順1から3を行っている間に、その他の任意のアダプタ・インスタンスが手順1を実行すると、処理の重複が起こります。この問題は、最初の操作でロックを取得しコミットで解放することにより解決されます。また、ポーリング・インスタンスも自然に順序付けされます。

ペシミスティック・ロックを有効にするには、一度ウィザードを最初から最後まで進めてインバウンド・ポーリング問合せを作成します。「アプリケーション・ナビゲータ」ウィンドウで、「アプリケーション・ソース」の次に「TopLink」を開き、「TopLinkマッピング」クリックします。「構造」ウィンドウで表名をクリックします。「ダイアグラム・ビュー」で、「TopLinkマッピング」タブ→「問合せ」タブ→「名前付き問合せ」タブ→「オプション」タブ→「詳細」ボタンをクリックし、「ペシミスティック・ロック」で「ロックの取得」をクリックします。「アイデンティティ・マップの問合せ結果のリフレッシュを設定しますか。」というメッセージが表示されます。問合せがペシミスティック・ロックを使用する場合、アイデンティティ・マップの問合せ結果をリフレッシュする必要があります。「「アイデンティティ・マップの問合せ結果のリフレッシュ」および「リモート・アイデンティティ・マップの問合せ結果のリフレッシュ」をtrueに設定しますか。」というメッセージが表示される場合は、「OK」をクリックします。ウィザードを再度実行してすべてを再生成します。新しいtoplink_mappings.xmlファイルで、問合せに<lock-mode>1</lock-mode>と表示されます。

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

前述の手順は、最初の操作が読取りのすべてのポーリング計画で実行されます。
順序付けベースのポーリング計画では、ヘルパー表でのみSELECT FOR UPDATEがSELECTに適用されます。表に対するwriteアクセス権がないため、ポーリングされた表のSELECTではロックを取得できません。
レコードのポーリング中にアダプタ・インスタンスが停止した場合、それらのレコードは未処理のプールに返されます（コミットされません）。
いずれの個別アダプタ・インスタンスも特別ではありません。理想的な分散システムでは、インスタンス間の調整は最小限です（ここではロックに影響されています）。弱いリンクとして機能するマスターはなく、どの部分も同じように構成されているため交換可能です。
分散環境では、データベース・アダプタによりSELECT FOR UPDATE以外の追加の読取りや書込みが行われることはありません。

ロード・バランシング: MaxTransactionSizeおよびペシミスティック・ロック

ポーリング問合せでペシミスティック・ロックを有効にすると、maxTransactionSizeアクティブ化プロパティが自動的に異なる動作をします。

ポーリング間隔の開始時に行が10,000あり、maxTransactionSizeが100であるとします。スタンドアロン・モードでは、作業が10,000行を100で割った100の順序トランザクション・ユニットに分割され、10,000行がすべて処理されるまでの100行ずつの反復的な読取りと処理にカーソルが使用されます。分散環境では、最初の100行の読取りと処理にカーソルが使用されます。ただし、アダプタ・インスタンスは、次のポーリング間隔または別のアダプタ・インスタンスに9,900の未処理の行（または99のトランザクション・ユニット）を残してカーソルを解放します。

ロード・バランシングを目的とした場合、分散環境でmaxTransactionSizeを必要以上に低く設定するのは危険です（maxTransactionSizeが速度の制限になるため）。maxTransactionSizeは、ビジネス・プロセス全体のCPU当たりのスループットに近い値に設定するのが最良です。これにより、ロード・バランシングは必要な場合にのみ機能します。

4.5.7 `detectOmissions`機能

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

使用可能なリリース

リリース10.1.3以上

構成可能

◎

デフォルト値

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

使用例

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

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

要素タイプ省略 NULL

列

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

<director></director>

<director />

<director xsi:nil="true" />

1-1  <dept xsi:nil="true" />

1-M

<!-- empCollection>…

</empCollection -->

</empCollection>

</empCollection>（空）

注意:

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

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

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

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

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

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

パフォーマンス

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

互換性のない相互作用

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

DetectOmissionsMerge
IgnoreNullsMerge
OptimizeMerge

注意:

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

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

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

Oracle BPEL Process Managerフォーラム

http://forums.oracle.com/forums/forum.jsp?forum=212

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

http://www.oracle.com/technology

4.5.8 `OutputCompletedXml`機能

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

使用可能なリリース

リリース10.1.2.0.2以上

構成可能

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

デフォルト値

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が優先されます。

4.6 サード・パーティJDBCドライバとデータベース接続の構成

次の項では、サード・パーティのデータベースへの接続方法を説明します。BPELプロセスはデータベース・プラットフォームに依存しないため、設計時と実行時に別々のベンダーのデータベースを使用できます。

注意:

Oracle Liteデータベース接続を作成するには、サード・パーティJDBCドライバの手順に従います（Oracle Liteデータベースの既存のウィザードおよびライブラリには追加の構成が必要なため）。表4-19に、Oracle Liteデータベースに接続するための情報を示します。

詳細は、「サード・パーティのデータベース表をインポートする際の問題」を参照してください。

一般的に、次の手順は、サード・パーティJDBCドライバを使用してデータベース接続を作成する際に適用します。特定のサード・パーティのデータベースの場合は、次のトピックを参照してください。

Microsoft SQL Serverの使用方法
IBM DB2データベースの使用方法
Sybaseデータベースの使用方法
InterSystems Cachéデータベースの使用方法
MySQL 4データベースの使用方法
サード・パーティおよびOracle Liteデータベースの接続情報のまとめ
JDBCドライバJARファイルの場所とクラスパスの設定

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

「表示」から「接続ナビゲータ」を選択します。
「データベース」を右クリックして「データベース接続の作成」を選択します。
「ようこそ」ウィンドウの「次へ」をクリックします。
接続名を入力します。
「接続タイプ」から「サード・パーティJDBCドライバ」を選択します。
ユーザー名、パスワードおよびロール情報を入力します。
「ドライバ・クラス」で「新規」をクリックします。
「ドライバ・クラス」にドライバ名（some.jdbc.Driverなど）を入力します。
「ライブラリ」で「新規」をクリックします。
「編集」をクリックして、ドライバの各JARファイルを「クラスパス」に追加します。
「OK」を2回クリックして「ライブラリの作成」ウィンドウを終了します。
「OK」をクリックして「JDBCドライバの登録」ウィンドウを終了します。
「URL」に接続文字列名を入力して、「次へ」をクリックします。

一般的に使用されるURLは、表4-19を参照してください。また、デプロイメント・ディスクリプタ・ファイル（oc4j-ra.xml）にサンプルのエントリが表示されます。
「接続のテスト」をクリックします。
正常に接続したら、「終了」をクリックします。

4.6.1 Microsoft SQL Serverの使用方法

Microsoft SQL Serverデータベースを使用している場合は、「設計時: コマンドライン・ユーティリティの使用方法」のデータベース接続の手順に従い、次の情報を使用します。

MS JDBCドライバ
DataDirectドライバ

4.6.1.1 MS JDBCドライバ

URL: jdbc:microsoft:sqlserver://localhost\NAME:1433;SelectMethod=cursor;databasename=???

ドライバ・クラス: com.microsoft.jdbc.sqlserver.SQLServerDriver

ドライバJar: .\SQLServer2000\msbase.jar、msutil.jar、mssqlserver.jar

4.6.1.2 DataDirectドライバ

URL: jdbc:oracle:sqlserver://localhost

ドライバ・クラス: com.oracle.ias.jdbc.sqlserver.SQLServerDriver

ドライバJar: .\DataDirect\YMbase.jar、YMoc4j.jar、YMutil.jar、YMsqlserver.jar

SQL Serverデータベースに接続する際は次の点に注意してください。

ユーザー名およびパスワード
- SQL Server 2005では、デフォルトでWindows認証もインストールされます。そのため、ユーザー名とパスワードでログインしません。Windowsのユーザー・アカウントに権限があるかないかのどちらかです。JDBCではユーザー名とパスワードの入力が必要です。
  
  support.microsoft.comによると、Microsoft SQL Server 2000 driver for JDBCではWindows NT認証を使用した接続はサポートされていません。次のサイトを参照してください。
```
http://support.microsoft.com/default.aspx?scid=kb;en-us;313100
```
  ただし、DataDirectドライバの仕様にはサポートしていると記載されています。
  
  Windowsのユーザー名とパスワードを使用すると、次のようなメッセージが表示されます。
```
[Microsoft][SQLServer 2000 Driver for JDBC][SQLServer]Login failed for user
'DOMAIN\USER'. The user is not associated with a trusted SQL Server
connection.[Microsoft][SQLServer 2000 Driver for JDBC]
An error occured while attempting to log onto the database.
```
  クリーン・インストールでmixed mode authenticationを選択する必要があります。
- Microsoft SQL Server 2000 Express Editionインストールでは、システム・ユーザー名はsaでパスワードは指定できます。

接続文字列

次の例に示すように、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ドライバも試用できます。

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

IBM DB2データベースを使用している場合は、「設計時: コマンドライン・ユーティリティの使用方法」のデータベース接続の手順に従い、次の情報を使用します。

4.6.2.1 DataDirectドライバ

URL: jdbc:db2:localhost:NAME

ドライバ・クラス: COM.ibm.db2.jdbc.net.DB2Driver

ドライバJar（v8.1）: .\IBM-net\db2java_81.zip, db2jcc_81.jar

4.6.2.2 JT400ドライバ（AS400 DB2）

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

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

ドライバJar: jt400.jar

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

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

Sybaseデータベースを使用している場合は、「設計時: コマンドライン・ユーティリティの使用方法」のデータベース接続の手順に従い、次の情報を使用します。

4.6.3.1 jconnドライバ

URL: jdbc:sybase:Tds:localhost:5001/NAME

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

ドライバJar: .\Sybase-jconn\jconn2.jar

4.6.3.2 DataDirectドライバ

URL: jdbc:oracle:sybase://localhost:5001

ドライバ・クラス: com.oracle.ias.jdbc.sybase.SybaseDriver

ドライバJar: .\DataDirect\YMbase.jar、YMoc4j.jar、YMutil.jar、YMsybase.jar

4.6.4 InterSystems Cachéデータベースの使用方法

InterSystems Cachéデータベースを使用している場合は、「設計時: コマンドライン・ユーティリティの使用方法」のデータベース接続の手順に従い、次の情報を使用します。

URL: jdbc:Cache://machinename_running_Cache_DB_Server:1972/Cache_Namespace

ドライバ・クラス: com.intersys.jdbc.CacheDriver

ドライバJar: C:\CacheSys\Dev\Java\Lib\CacheDB.jar

デフォルト・ログインは_SYSTEM/sysです。

4.6.5 MySQL 4データベースの使用方法

MySQL 4データベースを使用している場合は、「設計時: コマンドライン・ユーティリティの使用方法」のデータベース接続の手順に従い、次の情報を使用します。

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

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

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

4.6.6 サード・パーティおよびOracle Liteデータベースの接続情報のまとめ

表4-19に、一般的なサード・パーティのデータベースおよびOracle Oliteに関する前述の接続情報をまとめます。 PlatformClassNameの詳細は、表4-17「データベース・プラットフォーム名」も参照してください。

表4-19 サード・パーティのデータベースおよびOracle Oliteデータベースに接続するための情報

データベース	URL	ドライバ・クラス	ドライバJar
Microsoft SQL Server	MS JDBCドライバ: jdbc:microsoft:sqlserver:// localhost\NAME:1433; SelectMethod=cursor; databasename=??? DataDirectドライバ: jdbc:oracle:sqlserver:// localhost	MS JDBCドライバ: com.microsoft.jdbc.sqlserver. SQLServerDriver DataDirectドライバ: com.oracle.ias.jdbc.sqlserver. SQLServerDriver	MS JDBCドライバ: .\SQLServer2000\msbase. jar, msutil.jar, mssqlserver.jar DataDirectドライバ: .\DataDirect\YMbase.jar, YMoc4j.jar, YMutil.jar, YMsqlserver.jar
IBM DB2	DataDirectドライバ: jdbc:db2:localhost:NAME JT400ドライバ（AS400 DB2）: jdbc:as400://hostname; translate binary=true 例: jdbc:as400://localhost; translate binary=true	DataDirectドライバ: COM.ibm.db2.jdbc.net.DB2Driver JT400ドライバ（AS400 DB2）: com.ibm.as400.access. AS400JDBCDriver	DataDirectドライバ（v8.1）: .\IBM-net\db2java_81.zip, db2jcc_81.jar JT400ドライバ（AS400 DB2）: jt400.jar
Sybase	jconnドライバ: jdbc:sybase:Tds:localhost:5001/NAME DataDirectドライバ: jdbc:oracle:sybase:// localhost:5001	jconnドライバ: com.sybase.jdbc2.jdbc.SybDriver DataDirectドライバ: com.oracle.ias.jdbc.sybase. SybaseDriver	jconnドライバ: .\Sybase-jconn\jconn2.jar DataDirectドライバ: .\DataDirect\YMbase.jar, YMoc4j.jar, YMutil.jar, YMsybase.jar
InterSystems Caché	jdbc:Cache:// machinename_running_ Cache_DB_Server:1972/ Cache_Namespace ここで、`1972`はデフォルト・ポートです。例: jdbc:Cache://127.0.0.1:1972/ Samples	com.intersys.jdbc.CacheDriver	C:\CacheSys\Dev\Java\Lib\ CacheDB.jar
MySQL 4	jdbc:mysql://hostname:3306/ dbname 例: jdbc:mysql://localhost:3306/ test	com.mysql.jdbc.Driver	mysql-connector-java- 3.1.10-bin.jar
Oracle Oliteデータベース	jdbc:polite4@localhost:100: orabpel	oracle.lite.poljdbc. POLJDBCDriver	`Oracle_Home`\ bpel\lib\olite40.jar

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

実行時、ドライバJARファイルをアプリケーション・サーバーのクラスパスに、次のいずれかの方法で配置します。

次のファイルのクラスパスを編集します。

Oracle BPEL Process Managerの場合は、次の場所に移動します。
```
Oracle_Home/bpel/system/appserver/oc4j/j2ee/home/config/
server.xml
```
Oracle BPEL Process Manager for OracleAS Middle Tierインストールの場合は、次の場所に移動します。
```
Oracle_Home/j2ee/OC4J_BPEL/config/server.xml
```
または
JARファイルを次のディレクトリに移動します。

Oracle BPEL Process Managerの場合は、次の場所に移動します。
```
Oracle_Home/bpel/system/appserver/oc4j/j2ee/home/applib
```
Oracle BPEL Process Manager for OracleAS Middle Tierインストールの場合は、次の場所に移動します。
```
Oracle_Home/j2ee/OC4J_BPEL/applib
```

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

この項では、データベース・アダプタで、Oracleデータベースのみに対するストアド・プロシージャおよびファンクションの使用がどのようにサポートされているかを説明します。Oracle以外のデータベースに対するストアド・プロシージャおよびファンクションは、現在はサポートされていません。

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

設計時: アダプタ構成ウィザードの使用
設計時: コマンドライン・ユーティリティの使用方法
設計時: WSDLおよびXSDの生成
実行時: ストアド・プロシージャの起動前
実行時: ストアド・プロシージャの起動後
高度なトピック

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

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

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

最上位のスタンドアロンAPIの使用
パッケージ化されたAPIの使用およびオーバーロード

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

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

ウィザードでは、図4-73に示すように「データベース・アダプタ」を選択します。

図4-73 「アダプタ構成ウィザード」における「データベース・アダプタ」の選択

「図4-73 「アダプタ構成ウィザード」における「データベース・アダプタ」の選択」の説明

サービス名（ProcedureProcなど）およびサービスのオプションの説明を入力後、図4-74に示すように、接続をサービスと関連付けます。リストから既存の接続を選択するか、新しい接続を作成できます。

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

「図4-74 「アダプタ構成ウィザード」におけるデータベース接続の設定」の説明

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

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

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

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

スキーマおよびプロシージャ名がわからない場合は、「参照」をクリックして、図4-76に示す「ストアド・プロシージャ」ウィンドウにアクセスします。

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

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

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

図4-77に、PROCプロシージャを選択して、「引数」タブをクリックする方法を示します。「引数」タブには、プロシージャのパラメータが表示されます。表示されるパラメータは、名前、型、モード（IN、IN/OUTまたはOUT）およびプロシージャの定義におけるパラメータの数値位置です。

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

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

図4-78に、プロシージャを実装するコードが「ソース」タブでどのように表示されるかを示します。プロシージャ名に一致するテキストが強調表示されています。

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

「図4-78 選択したプロシージャのソース・コードの表示」の説明

プロシージャまたはファンクションを選択して「OK」をクリックすると、図4-79に示すように、APIの情報が表示されます。「戻る」または「参照」を使用してリビジョンを作成するか、「次へ」→「終了」をクリックして終了します。

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

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

アダプタ構成ウィザードの使用が終了すると、servicename.wsdl（ProcedureProc.wsdlなど）および生成されたXSDの2つのファイルが既存のプロジェクトに追加されます。生成されたXSDファイルの名前は、schema_package_procedurename.xsdです。この場合、生成されるXSDファイルの名前はSCOTT_PROC.xsdです。

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

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

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

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

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

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

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

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

プロシージャまたはファンクションを選択して「OK」をクリックすると、図4-82に示すように、APIの情報が表示されます。スキーマ、プロシージャ名およびパラメータのリストが表示されます。プロシージャ名がパッケージ名でどのように修飾されているかに注意してください（PACKAGE.OVERLOAD）。「戻る」または「参照」を使用してリビジョンを作成するか、「次へ」→「終了」をクリックして終了します。

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

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

アダプタ構成ウィザードの使用が終了すると、Overload.wsdlおよびSCOTT_PACKAGE_OVERLOAD_2.xsdの2つのファイルが既存のプロジェクトに追加されます。XSDファイル名ではプロシージャ名の後に_2が追加され、オーバーロードされたAPIと区別されています。

4.7.2 設計時: コマンドライン・ユーティリティの使用方法

コマンドライン・ユーティリティの起動には、プロパティ・ファイルと、必要なサービスWSDLの作成に使用されるテンプレートWSDLのファイル名を使用します。この項には、次の項目が含まれます。

共通のコマンドライン機能
生成される出力
サポートされるサード・パーティ・データベース

4.7.2.1 共通のコマンドライン機能

追加データベースは、それぞれコマンドライン・ユーティリティで提供される一部の共通機能を共有します。すべてのサポート対象データベースで共有されるプロパティもいくつかあります。サポート対象データベースで共有されるプロパティのリストを次に示します。

ProductName

追加データベースの名前です。 ProductNameでは、IBM DB2（IBM DB2v8.2）およびMicrosoft SQL Server（SQL Server 2000または2005）がサポートされます。

DriverClassName

JDBCドライバのクラス名です。

ConnectionString

JDBC接続のURLです。

Username

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

Password

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

ProcedureName

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

ServiceName

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

DatabaseConnection

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

Destination

生成されるファイルの宛先ディレクトリ（C:\Tempなど）です。

C:\java oracle.tip.adapter.db.sp.artifacts.GenerateArtifacts <properties>

<properties>はプロパティ・ファイル名です。ユーティリティでは、データベース固有のプロパティなど、すべての必須プロパティが存在することも確認されます。

4.7.2.2 生成される出力

コマンドライン・ユーティリティでは、3つのファイル（選択したAPIのシグネチャを表すXSD、アダプタ・サービスWSDL、サービスWSDLでインポートされるプロジェクトWSDL）が生成されます。生成されるWSDLの名前は、ServiceNameプロパティの値から導出されます。 XSDの名前は、ProcedureNameプロパティとデータベース固有の他のプロパティ値から導出されます。たとえば、Oracleデータベースのスキーマ名とパッケージ名などです。

生成されるサービスWSDLの内容は、WSDLテンプレートと必須プロパティの値を使用して導出されます。 XSDの内容は、修飾プロシージャ名および使用するデータベース固有のタイプ・マッピング表から導出されます。ストアド・プロシージャのパラメータを表す要素の属性の数とタイプは、アダプタ・ウィザードを使用して生成されるものと同じです。

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

コマンドライン・ユーティリティを使用すると、IBM DB2 v8.2、SQL Server 2000およびSQL Server 2005に必要なサービス成果物を生成できます。サポートされるデータ型とプロパティは、データベースごとに異なります。この項には、次の項目が含まれます。

Microsoft SQL Server 2000および2005
IBM DB2 v8.2

4.7.2.3.1 Microsoft SQL Server 2000および2005

SQL Serverは、ストアド・プロシージャのみでなくファンクションもサポートしています。コマンドライン・ユーティリティに対して、選択したAPIがプロシージャではなくファンクションであることを示すプロパティが必要です。次の表に、Microsoft SQL Serverで使用される追加プロパティを示します。

プロパティ	説明
`IsFunction`	APIがファンクションの場合、値はデフォルトで`true`または`false`です。
`DatabaseName`	APIが定義されているデータベースの名前です。
`SchemaName`	プロシージャが属しているスキーマの名前です。

IsFunctionプロパティはオプションです。デフォルト値はfalseです。 APIがプロシージャの場合、このプロパティを指定する必要はありません。 APIがファンクションであるか、値を戻すプロシージャである場合、このプロパティをtrue、TrueまたはTRUEに設定する必要があります。値を戻すプロシージャの例を次に示します。

1> create procedure … as begin …;return 1; end
2> go

IsFunctionの値が設定されていない場合や、falseまたは他のなんらかの値に設定されている場合、戻り値はAPIの実行後に生成されるXMLに含まれません。

SchemaNameおよびDatabaseNameプロパティは、ストアド・プロシージャをさらに修飾するために使用されます。たとえば、<DatabaseName>.<SchemaName>.<ProcedureName>などとなります。これらのプロパティはオプションであるため、指定しなくてもかまいません。

表4-20に、SQL Serverデータベースで使用するストアド・プロシージャについてのみサポートされるデータ型を示します。

表4-20 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の使用は廃止されています。

ストアド・プロシージャのパラメータのデータ型が別名データ型を使用して定義されている場合は、基礎となるベースSQLデータ型が判別され、このデータ型およびマッピングが生成XSDのパラメータに使用されます。次の例を考えてみます。

1>create type myint from int
2>go
3>create procedure aliastype @x myint as …
4>go

前述の例では、プロシージャのパラメータの型はエイリアス型myintです。基礎となるデータベースSQLでのmyintのデータ型は次の例に示すようにINTで、そのタイプ・マッピングはストアド・プロシージャで対応するパラメータに使用されます。

<element name="x" type="int" … db:type="INT" … />

SQL Server 2005では、構造化されたデータ型（ユーザー定義）が導入されています。ただし、コマンドライン・ユーティリティではサポートされていません。したがって、構造化されたデータ型をストアド・プロシージャのパラメータの型として使用することはできません。

4.7.2.3.2 IBM DB2 v8.2

IBM DB2では、追加プロパティを使用してストアド・プロシージャをさらに修飾します。サポートされるのがSQLストアド・プロシージャのみであることに注意してください。外部プロシージャとユーザー定義ファンクションはサポートされません。

IBM DB2では、SchemaNameプロパティは必須です。 SchemaNameは、プロシージャが属しているスキーマの名前です。コマンドライン・ユーティリティでは、プロシージャの存在を確認できるように、ストアド・プロシージャの修飾に使用されます。表4-21に、DB2データベースで使用するストアド・プロシージャについてのみサポートされるデータ型を示します。

表4-21 IBM DB2データベースでストアド・プロシージャについてサポートされているデータ型

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

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

個別データ型も、ストアド・プロシージャについてのみサポートされています。これらは、SQL Serverの別名データ型に似ています。次の例に示すように、作成にはCREATE DISTINCT TYPE文を使用します。

db2 => create distinct type myint as integer with comparisons
db2 => create procedure distincttype(in x myint, …) begin … end

基礎となるデータベースSQLでのmyintのデータ型はINTEGERで、そのタイプ・マッピングはストアド・プロシージャで対応するパラメータに使用されます。

<element name="X" type="int" … db:type="INTEGER" … />

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

4.7.3 設計時: WSDLおよびXSDの生成

「アダプタ構成ウィザード - ストアド・プロシージャ」では、ストアド・プロシージャまたはファンクションのシグネチャを説明するWSDLおよび有効なXSDを作成できます。次の項では、WSDLとXSD両方の関連する構造およびコンテンツと、それぞれのリレーションシップを説明します。

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

WSDLとXSDのリレーションシップ
サポートされているプリミティブ・データ型
生成されたXSD属性
ユーザー定義タイプ
複雑なユーザー定義タイプ
オブジェクト・タイプの継承
オブジェクト参照
別のスキーマのタイプの参照

4.7.3.1 WSDLとXSDのリレーションシップ

後続の段落では、前述の例で引用された操作名ProcedureProcおよびプロシージャ名PROCを使用します（図4-79参照）。生成されたWSDLにより、XSDがインポートされます。

<types>
  <schema xmlns="http://www.w3.org/2001/XMLSchema">
    <import namespace="http://xmlns.oracle.com/pcbpel/adapter/db/SCOTT/PROC/"
      schemaLocation="SCOTT_PROC.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="db:InputParameters"/>
</message>
<message name="args_out_msg"
  <part name="OutputParameters" element="db:OutputParameters"/>
</message>

dbネームスペースは、生成されたXSDのtargetNamespaceと同じです。args_out_msgはXSDでOutputParametersルート要素が生成された場合にのみ含まれるのに対し、args_in_msgメッセージ・タイプは、常にWSDLに含まれることに注意してください。

操作はWSDLで定義されます。このWSDLは、アダプタ・サービスと同じ名前で、入力および出力メッセージがこれら2つのメッセージ・タイプに関して定義されます。

<portType name="ProcedureProc_ptt">
  <operation name="ProcedureProc">
    <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/ProcedureProc/"

XSDのルート要素は、メッセージで使用されるパートの構造を定義します。このメッセージは、WSDLでカプセル化されたWebサービスで送受信されます。

WSDLの入力メッセージは、XSDのInputParametersルート要素に対応します。インスタンスXMLは、ストアド・プロシージャのINおよびIN/OUTパラメータの値を提供します。出力メッセージは、OutputParametersルート要素に対応します。これは、ストアド・プロシージャが実行された後に生成されるXMLです。任意のIN/OUTおよびOUTパラメータの値が保持されます。

4.7.3.2 サポートされているプリミティブ・データ型

多くのプリミティブ・データ型には、詳細に定義されたマッピングが用意されているため、設計時および実行時のコンポーネントのどちらでもサポートされています。また、VARRAY、ネストされた表およびOBJECTなどのユーザー定義タイプを使用できます。表4-22に、ストアド・プロシージャのデータベース・アダプタによってサポートされているプリミティブ・データ型をリスト表示します。

表4-22 ストアド・プロシージャのデータベース・アダプタによってサポートされているプリミティブ・データ型

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` `VARCHAR2`	`string`
`DATE` `TIMESTAMP`	`dateTime`
`DECIMAL` `NUMBER`	`decimal`

4.7.3.3 生成されたXSD属性

表4-23に、生成されたXSDで使用される属性をリスト表示します。接頭辞がdb:の属性は、データベース・アダプタ固有です。

表4-23 生成された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"のように）明示的に宣言する必要があります。

4.7.3.4 ユーザー定義タイプ

ウィザードでも、コレクション（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の属性の宣言から長さがわかります。

4.7.3.5 複雑なユーザー定義タイプ

ユーザー定義タイプは、必要に応じて複雑に定義できます。OBJECTには、前述の任意のユーザー定義タイプとして定義されているタイプの属性を含めることができます。これは、OBJECTの属性のタイプが別のOBJECT、VARRAYまたはネストされた表などになることを意味します。VARRAYまたはネストされた表のベース・タイプも、OBJECTになる可能性があります。コレクションのベース・タイプが別のコレクションになることを許可することで、多次元のコレクションがサポートされます。

4.7.3.6 オブジェクト・タイプの継承

ウィザードでは、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タイプの階層が、階層全体のすべての属性に対応する要素の単一の順序にフラット化されていることに注意してください。

4.7.3.7 オブジェクト参照

ウィザードでは、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パラメータを渡すことはできません。

4.7.3.8 別のスキーマのタイプの参照

アクセスに必要な権限が付与されている場合には、別のスキーマに定義されているタイプを参照できます。たとえば、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の宣言でOBJを参照できません。

4.7.4 実行時: ストアド・プロシージャの起動前

この項では、ストアド・プロシージャのサポートに関する重要事項と、ストアド・プロシージャまたはファンクションの起動前に発生する動作に関する重要事項の概要を説明します。

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

値のバインディング
データ型の変換

4.7.4.1 値のバインディング

XMLからの値の抽出と、それらの値が実行時にどのように作用するかを検討します。タイプがサポートされているプリミティブ・データ型のいずれかの値であるパラメータ値に対応するXMLのデータの場合、次の状況が想定されます。

要素の値が指定されている（<X>100</X>など、この例ではX=100）。
要素の値が指定されていない（<X/>など、この例ではX=NULL）。
値がNULLとして明示的に指定されている（<X xsi:nil="true"/>など、この例ではX=NULL）。
要素がXMLで指定されていない（X = <default value>など）。

1つ目のケースでは、値はXMLからそのまま取得され、タイプに応じて適切なオブジェクトに変換されます。そのオブジェクトは、ストアド・プロシージャ起動の準備中に、対応するパラメータにバインドされます。

2つ目と3つ目のケースでは、XMLから抽出された実際の値はNULLです。タイプ・コンバータではNULLが許容され、変換されずに返されます。NULL値はタイプにかかわらず対応するパラメータにバインドされます。基本的に、これはパラメータXにNULLを渡すのと同じです。

4つ目のケースには2つの可能性があります。パラメータにデフォルト句がある場合とない場合です。パラメータにデフォルト句がある場合、パラメータはストアド・プロシージャの起動から完全に除外されます。これにより、パラメータにデフォルト値が使用されます。一方、パラメータにデフォルト句がない場合、パラメータはプロシージャの起動に含まれます。ただし、ファンクションの場合、すべてのパラメータの要素を指定する必要があります。インスタンスXMLの要素に欠落がある場合、ファンクションは予想よりも少数の引数を使用して起動されます。 IBM DB2には、ストアド・プロシージャのパラメータのデフォルト値を指定するためのメカニズムがありません。したがって、各パラメータの要素がインスタンスXMLに存在する必要があります。

NULL値はデフォルトでパラメータにバインドされます。

SQL> CREATE PROCEDURE PROC (X IN INTEGER DEFAULT 0) AS BEGIN … END;

ここでは、パラメータにバインドされる値はありません。実際に、パラメータはストアド・プロシージャの起動から完全に除外されています。これにより、0値がパラメータXのデフォルトに設定されます。

内容をまとめるため、次のPL/SQLが4つのケースのそれぞれで実行されたとします。

"BEGIN PROC (X=>?); END;" - X = 100
"BEGIN PROC (X=>?); END;" - X = null
"BEGIN PROC (X=>?); END;" - X = null
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"/>

4.7.4.2 データ型の変換

この項では、CLOB、DATE、TIMESTAMPなどのデータ型、RAW、LONG RAW、BLOBなどのバイナリ・データ型、およびサード・パーティ・データベースでサポートされている類似のデータ型の変換について説明します。

CLOBパラメータでは、まず一時CLOBが作成されます。その後、CLOBが対応するパラメータにバインドされる前に、XMLから抽出されたデータが書き込まれます。一時CLOBは相互作用が完了すると解放されます。CHARおよびVARCHAR2など、その他のキャラクタ・タイプの場合には、データが必要に応じて抽出されてバインドされます。XMLドキュメントはCLOB（または、十分な大きさの場合にはVARCHAR2）にバインドできます。ただし、まず<、>などを適切に置き換える必要があります（たとえば、<は<に、>は>に）。

XMLスキーマ型dateTimeは、DATEおよびTIMESTAMPの両方を表しています。どちらのデータ型のXML値も、dateTimeのXMLスキーマ表現に準拠する必要があることを意味します。そのため、単純なDATE文字列01-JAN-05は無効です。XMLスキーマでは、dateTimeはYYYY-MM-DDTHH:mm:ssとして定義されます。そのため、適切なDATE値は2005-01-01T00:00:00です。

バイナリ・データ型のデータは、人間が理解できる方法で表現する必要があります。バイナリ・データの選択されたXMLスキーマ表現はbase64Binaryです。タイプ・コンバータでは、javax.mail.internet.MimeUtilityエンコードおよびデコードAPIを使用してバイナリ・データが処理されます。エンコードAPIは、すべてのバイナリ・データのbase64Binary形式へのエンコードに使用する必要があるため、XMLファイルでも使用できます。タイプ・コンバータでは、XMLデータのバイト配列へのデコードにデコードAPIが使用されます。これは、RAWおよびLONG RAWパラメータの場合と同様に直接バインドされるか、一時BLOBの作成に使用されてから、関連付けられているBLOBパラメータにバインドされます。一時BLOBは相互作用が完了すると解放されます。

その他のデータ型の変換は簡単なため、追加情報は必要ありません。

4.7.5 実行時: ストアド・プロシージャの起動後

プロシージャ（またはファンクション）を実行すると、任意のIN/OUTおよびOUTパラメータの値が取得されます。これらは、生成されたXSDのOutputParametersルート要素の要素値に対応します。

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

データ型の変換
NULL値
ファンクションの戻り値

4.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を使用する必要があります。

その他のデータ型の変換は簡単なため、追加情報は必要ありません。

4.7.5.2 NULL値

値がNULLの要素は、生成されたXMLでは空の要素として表示され、xsi:nil属性で注釈が付けられます。つまり、xsiネームスペースは生成されるXMLで宣言されます。単一のOUTパラメータXがあり、値がNULLのプロシージャPROCの生成されたXMLは次のようになります。

<db:OutputParameters … xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <X xsi:nil="true"/>
</db:OutputParameters>

dbネームスペースも宣言されます（xmlns:db="..."）。任意のタイプ（ユーザー定義タイプも含む）のパラメータのXML要素は、値がNULLの場合にはこのように表示されます。

4.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になり、OutputParametersに生成されたXMLでは<FACTORIAL>120</FACTORIAL>と表示されます。

4.7.6 実行時: サード・パーティ・データベースの共通機能

SQL ServerとDB2は、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が常に先頭に表示されます。

4.7.7 高度なトピック

この項では、データベース・アダプタで提供されているストアド・プロシージャ機能を使用して、直接にはサポートされていないタイプのシナリオを説明します。次の項では、これらのデータ型を使用する必要がある場合に取り組む解決策を説明します。

REF CURSORのサポート
PL/SQLブール、PL/SQLレコードおよびPL/SQL表タイプのサポート

4.7.7.1 REF CURSORのサポート

設計時および実行時のいずれのコンポーネントでも、REF CURSORタイプは直接サポートされていません。解決策は、OBJECTタイプのコレクションを使用することです。通常、REF CURSORによって返される行数は不明なため、コレクション・タイプとしてネストされた表を使用することをお薦めします。この解決策では、Javaストアド・プロシージャを使用して、ResultSetを宣言されたコレクション・タイプのインスタンスに変換します。次のディレクトリに、これを説明したサンプルのチュートリアルが用意されています。

Oracle_Home\bpel\samples\tutorials\122.DBAdapter\ResultSetConverter

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

設計時
実行時

4.7.7.1.1 設計時

PL/SQLのカーソル変数（REF CURSOR）は、RowSetsを使用してサポートされます。ウィザードでは、設計時にカーソル変数の問合せに含まれる列を判別できません。このため、カーソル変数の内容を表すXSDは生成できません。ただし、対応するRowSetの構造を一般化することはできます。

RowSetは0（ゼロ）行以上で構成されます。各行は1列以上で構成され、各列はカーソル変数の問合せの列項目に対応します。各列には名前やSQLデータ型などがあります。したがって、この一般化に対応する定義をXSDで作成できます。次の例を考えてみます。

<complexType name="RowSet">
    <sequence>
        <element name="Row" minOccurs="0" maxOccurs="unbounded" nillable="true">
            <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>

このXSDでは、XMLスキーマ型stringがすべての列値を表していることがわかります。これは、すべてのプリミティブ・データ型（NUMBER、INTEGERおよびTIMESTAMPなど）で許容されます。

単純なstringでは、Object、VarrayおよびNested Tableなどのユーザー定義データ型の構造を捕捉できません。これらのデータ型の構造はXSDの生成時には不明なため、その定義は生成できません。

ただし、実行時にユーザー定義データ型の構造を確定し、そのデータ型の値を含むstringを生成することはできます。したがって、これらのデータ型の値は実際の構造に似たXML文字列となります。この値自体がXML文字列であるため、生成されたXMLでは対応する要素に完全にエスケープされたXMLとして表示されます。

4.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;

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値を提供できないため、ストアド・プロシージャの起動時にNULLがバインドされます。

4.7.7.2 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 PROC (R REC, T TBL, B BOOLEAN);
END;

図4-83に、パッケージPKGのプロシージャPROCが選択されると表示されるウィザードでの手順を示します。

図4-83 「アダプタ構成ウィザード」におけるストアド・プロシージャの指定

「図4-83 「アダプタ構成ウィザード」におけるストアド・プロシージャの指定」の説明

図4-83に示すように、元のプロシージャ名は完全修飾され、PKG.PROCとなっています。パラメータ・タイプRはRECORDの名前です。タイプTはTABLEの名前です。タイプBはBOOLEANです。生成されているラッパー・パッケージの名前は、サービス名bpel_ServiceName（bpel_UseJPubなど）から導出されます。これは、生成されたパッケージの名前で、ラッパー・プロシージャが含まれています。チェック・ボックスは、スキーマ・オブジェクトの作成時に、ウィザードで既存のパッケージの上書きを強制する際に使用できます。

図4-84に示すように、「次へ」をクリックすると、ウィザードの「終了」ページが表示されます。

図4-84 データベース・アダプタ・サービスの定義: 「終了」ページ

「図4-84 データベース・アダプタ・サービスの定義: 「終了」ページ」の説明

このページのコンテンツでは、ウィザードで検出されたもの、「終了」ボタンがクリックされると実行される処理が説明されます。次に、このページのコンテンツをまとめます。

生成されたWSDLの名前はUseJPub.wsdlです。
2つのSQLスクリプトが作成され、BPELプロセス・プロジェクトに追加されます。
1. BPEL_USEJPUB.sql: スキーマ・オブジェクトが作成されます。
2. BPEL_USEJPUB_drop.sql: スキーマ・オブジェクトが削除されます。
生成されたXSDの名前はSCOTT_USEJPUB_PKG-24PROC.xsdです。

「終了」をクリックすると、Oracle JPublisherが起動され、SQLファイルが生成されてデータベースにスキーマ・オブジェクトがロードされます。ラッパーの生成プロセスは、完了に時間がかかります。初期ラッパーが同じパッケージ内の別のプロシージャに生成された後は、通常、同じパッケージに生成されるラッパーの処理時間は短くなります。

次に示すユーザー定義タイプは、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パラメータの許容値は、trueが1でfalseが0です。1以外の値はfalseとみなされます。生成されたラッパー・プロシージャでは、SYS.SQLJUTLパッケージのAPIが使用され、INTEGERとBOOLEANが相互に変換されます。

PL/SQLタイプとユーザー定義タイプの相互変換を行う変換APIとともに、PKG$PROCというプロシージャPROCのラッパーが含まれる、BPEL_USEJPUBという新しいラッパー・パッケージが作成されます。元のプロシージャがルートレベルのプロシージャの場合、生成されたラッパー・プロシージャの名前はTOPLEVEL$OriginalProcedureNameです。

生成されたXSDは、元のプロシージャではなく、ラッパー・プロシージャPKG$PROCのシグネチャを表します。XSDファイルの名前はURLエンコードされ、$が-24に置き換えられます。

生成された成果物のネーミング規則を示します。

サービス名は、WSDLおよびSQLファイルの名前に使用されます。ラッパー・パッケージの名前にも使用されます。
生成されたXSDの名前は、スキーマ名、サービス名、および元のパッケージ名とプロシージャ名から導出されます。
ユーザー定義タイプの名前は、元のパッケージ名および対応するPL/SQLタイプの名前から導出されます。
ラッパー・プロシージャの名前は、元のパッケージ名とプロシージャ名から導出されます。TOPLEVEL$は、ルートレベルのプロシージャに使用されます。

生成されたラッパー・パッケージの名前は30文字に制限されます。ラッパー・プロシージャの名前は29文字に制限されます。Oracle JPublisherで生成された名前がこれらの制限よりも長い場合は、切り捨てられます。

プロシージャに関連付けられたサービスに対応するPartnerLinkが起動されると、生成されたラッパー・プロシージャは元のプロシージャのかわりに実行されます。

4.7.7.2.1 ラッパー・プロシージャのデフォルト句

プロシージャにラッパーの生成が必要な特別なタイプが含まれる場合、パラメータのデフォルト句はラッパーには継承されません。たとえば、次のようなSQL文があるとします。

SQL> CREATE PROCEDURE NEEDSWRAPPER (
        >     B BOOLEAN DEFAULT TRUE, N NUMBER DEFAULT 0) IS BEGIN … END;

これがルートレベルのプロシージャであると仮定すると、生成されるラッパー・プロシージャのシグネチャは次のようになります。

TOPLEVEL$NEEDSWRAPPER (B INTEGER, N NUMBER)

BOOLEANタイプがINTEGERに置き換えられています。生成されたラッパーには、どちらのパラメータのデフォルト句もありません。元のプロシージャにデフォルト句があったとしても、生成されるラッパー・プロシージャのパラメータには、デフォルト句はありません。

この例で、インスタンスXMLにどちらのパラメータの要素も指定されていない場合、NULL値はラッパー・プロシージャの起動中にそのパラメータにバインドされます。元のプロシージャに指定されているパラメータのデフォルト値は使用されません。

この問題に対応するには、デフォルト句をラッパー・プロシージャのパラメータにリストアして、ラッパーを作成する生成された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に要素がない場合、プロシージャ・コールから対応するパラメータを除外する必要があることを示すために実行時に使用されます。これらの要素のその他の属性は元のままです。

4.8 JDeveloper BPEL Designerにおけるストアド・プロシージャの作成および構成の使用例

このチュートリアルでは、JDeveloper BPEL Designerを使用したOracle BPEL Process Managerへのストアド・プロシージャの統合方法を説明します。ストアド・プロシージャおよびファンクションを説明したその他のチュートリアルは、File2StoredProcedure、JPublisherWrapperおよびResultSetConverterです。次の場所に移動してください。

Oracle_Home\bpel\samples\tutorials\122.DBAdapter

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

ストアド・プロシージャの作成
新規BPELプロジェクトの作成
パートナ・リンクの作成
invokeアクティビティの作成
1つ目のassignアクティビティの作成
2つ目のassignアクティビティの作成
Greetingプロセスの検証、コンパイルおよびデプロイ
Greetingプロセスの実行

4.8.1 ストアド・プロシージャの作成

SQL*Plusを使用してOracleデータベースのscottスキーマに接続します。これは、ストアド・プロシージャの作成先のスキーマです。この例では、パスワードをtigerとします。
```
sqlplus scott/tiger
```

ストアド・プロシージャを作成します（Helloの後には空白があります）。

 SQL> CREATE PROCEDURE HELLO (NAME IN VARCHAR2, GREETING OUT VARCHAR2) AS
    2  BEGIN
    3      GREETING := 'Hello ' || NAME;
    4  END;
    5  /

  Procedure created.

4.8.2 新規BPELプロジェクトの作成

次の手順に従って新規BPELプロジェクトを作成します。

Oracle JDeveloperを開きます。
「ファイル」メニューから「新規」を選択します。

「新規ギャラリ」ダイアログ・ボックスが表示されます。
「フィルタ方法」ボックスから「すべてのテクノロジ」を選択します。使用可能なカテゴリのリストが表示されます。
「General」ノードを開いて「Projects」を選択します。
図4-85のように、「項目」グループから「ESBプロジェクト」を選択します。

図4-85 新規BPELプロジェクトの作成

「図4-85 新規BPELプロジェクトの作成」の説明
「OK」をクリックします。

「BPELプロジェクト作成ウィザード - プロジェクトの設定」ダイアログ・ボックスが表示されます。
- 名前: プロセス名を入力します。この例では、Greetingと入力します。
- ネームスペース: デフォルト値を保持します。
- テンプレート: 「同期BPELプロセス」を選択します。
「次へ」をクリックします。

「BPELプロジェクト作成ウィザード - 入力/出力要素」ダイアログ・ボックスが表示されます。
デフォルト値を受け入れて「終了」をクリックします。

図4-86のように、BPELプロジェクトの作成が完了しました。

図4-86 「アプリケーション」画面

「図4-86 「アプリケーション」画面」の説明

4.8.3 パートナ・リンクの作成

この項では、パートナ・リンクの作成方法を説明します。次の手順に従ってパートナ・リンクを作成します。

「コンポーネント・パレット」から「Services」を選択します。
サービス・リストからBPELプロジェクト・ウィンドウへ「PartnerLink」をドラッグ・アンド・ドロップします。

「パートナ・リンクの作成」ダイアログ・ボックスが表示されます。
「名前」フィールドにHelloと入力し、「WSDL設定」で「アダプタ・サービスの定義」アイコン（3番目のアイコン）をクリックします。

「アダプタ構成ウィザード - ようこそ」画面が表示されます。
「次へ」をクリックします。

「アダプタ・タイプ」ダイアログ・ボックスが表示されます。
図4-87のように、「データベース・アダプタ」を選択して「次へ」をクリックします。

図4-87 「アダプタ・タイプ」ダイアログ・ボックス

「図4-87 「アダプタ・タイプ」ダイアログ・ボックス」の説明
「サービス名」ウィンドウの「サービス名」フィールドにHelloと入力し、「次へ」をクリックします。これはパートナ・リンクのサービス名と同じ名前です。

「サービス接続」ダイアログ・ボックスが表示されます。
「新規」をクリックして新規接続を作成します。

「ようこそ」ダイアログ・ボックスが表示されます。
「次へ」をクリックします。

「タイプ」ダイアログ・ボックスが表示されます。
「タイプ」ダイアログ・ボックスの「接続名」フィールドに名前（myConnectionなど）を入力します。
「接続タイプ」リストからデータベースの接続タイプ（「Oracle (JDBC)」など）を選択して、「次へ」をクリックします。

「認証」ダイアログ・ボックスが表示されます。
「認証」ウィンドウの「ユーザー名」フィールドにscottと入力します。
「パスワード」フィールドにscottのパスワードを入力します（この例ではtiger）。
その他のフィールドはそのままにして、「次へ」をクリックします。

「接続」ダイアログ・ボックスが表示されます。
次の接続情報を入力します。この情報が不明な場合は、データベース管理者に連絡してください。

フィールド値の例

ドライバ thin

ホスト名 localhost

JDBCポート 1521

SID ORCL
「次へ」をクリックします。

「テスト」ダイアログ・ボックスが表示されます。
「テスト」ウィンドウの「接続のテスト」をクリックします。

正常に接続したら、次のメッセージが表示されます。
```
Success!
```
「終了」をクリックします。

すべてのフィールドが移入済の状態で、図4-88に示す「サービス接続」ダイアログ・ボックスが表示されます。

図4-88 「サービス接続」ダイアログ・ボックス

「図4-88 「サービス接続」ダイアログ・ボックス」の説明
「次へ」をクリックします。

「操作タイプ」ダイアログ・ボックスが表示されます。
「操作タイプ」ウィンドウで、「ストアド・プロシージャまたはファンクションの呼出し」を選択して「次へ」をクリックします。

「ストアド・プロシージャの指定」ダイアログ・ボックスが表示されます。
「プロシージャ」フィールドの右にある「参照」をクリックします。

「ストアド・プロシージャ」ダイアログ・ボックスが表示されます。
「スキーマ」リストに「<デフォルト・スキーマ>」が選択されたままにします。これは、ストアド・プロシージャが定義されているscottスキーマのデフォルトに設定されます。

フィールド	値の例
ドライバ	thin
ホスト名	localhost
JDBCポート	1521
SID	ORCL

「ストアド・プロシージャ」のナビゲーション・ツリーでHelloを選択します。

注意:

別の方法として、「検索」フィールドにHelloと入力して「検索」をクリックし、ストアド・プロシージャのナビゲーション・ツリーにこのストアド・プロシージャを表示して選択することもできます。

「引数」タブにストアド・プロシージャのパラメータが表示されます。

図storeproc1.gifの説明

「ソース」タブをクリックして、Helloストアド・プロシージャのソース・コードを表示します。これは、「ストアド・プロシージャの作成」でSQL*Plusを使用してストアド・プロシージャを作成した際に入力した構文です。

図4-89に、ストアド・プロシージャHelloのソース・コードを示します。

図4-89 ストアド・プロシージャHelloのソース・コード

「図4-89 ストアド・プロシージャHelloのソース・コード」の説明
「OK」をクリックします。

「ストアド・プロシージャの指定」ウィンドウに選択内容が表示されます。図4-90にその様子を示します。

図4-90 「ストアド・プロシージャの指定」ダイアログ・ボックス

「図4-90 「ストアド・プロシージャの指定」ダイアログ・ボックス」の説明
「次へ」をクリックします。

「終了」画面が表示されます。
「終了」をクリックしてアダプタ構成を完了します。

「パートナ・リンクの作成」ウィンドウが自動的に完了します。
「適用」をクリックします。
「OK」をクリックします。
「ファイル」メイン・メニューから「すべて保存」を選択します。

「アプリケーション・ナビゲータ」の「インテグレーション・コンテンツ」→「Greeting」の下に次のファイルが表示されます。これらのファイルには、アダプタ構成ウィザードで指定したパラメータが含まれます。
- Hello.wsdl
  
  新しいストアド・プロシージャのパートナ・リンクに対応
- SCOTT_HELLO.xsd
  
  パラメータを含むストアド・プロシージャの定義を指定

4.8.4 invokeアクティビティの作成

invokeアクティビティを作成して、（Helloパートナ・リンクで特定された）サービスに対して起動する操作を指定します。

図に示すように、invokeアクティビティをreceiveInputアクティビティの下へドラッグ・アンド・ドロップします。

図4-91 invokeアクティビティ

「図4-91 invokeアクティビティ」の説明
invokeアクティビティをダブルクリックして、「Invoke」ダイアログ・ボックスを表示します。
「Invoke」ダイアログ・ボックスで、次のアクションを実行するように指定します。
1. 「名前」フィールドにGreetと入力します。
2. 「パートナ・リンク」フィールドの右側にある「パートナ・リンクの参照」アイコンをクリックします。
  
  「パートナ・リンクの選択」ダイアログ・ボックスが表示されます。
3. 図4-92のように、「Hello」を選択して「OK」をクリックします。
  
  図4-92 「パートナ・リンクの選択」ダイアログ・ボックス
  
  「図4-92 「パートナ・リンクの選択」ダイアログ・ボックス」の説明
「名前」、「パートナ・リンク」および「操作」の各フィールドが入力済の状態で「Invoke」ダイアログ・ボックスが表示されます。「操作」フィールドには、値Helloが自動的に設定されています。
「入力変数」フィールドの右側にある「入力変数の自動作成」アイコン（最初のアイコン）をクリックします。

図autocreate.gifの説明

「変数の作成」ダイアログ・ボックスが表示されます。Greet_Hello_InputVariableという名前の変数が、「名前」フィールドに自動的に表示されます。この変数により、ストアド・プロシージャのinパラメータの値が指定されます。タイプはhttp://xmlns.oracle.com/pcbpel/adapter/db/Hello/}args_in_msgです。
「グローバル変数」が選択されていることを確認してください。
「変数の作成」ダイアログ・ボックスで「OK」をクリックします。
「出力変数」フィールドの右にある1つ目のアイコンをクリックします。
Greet_Hello_OutputVariableという名前の変数が、「名前」フィールドに自動的に表示されます。実行後、この変数にはプロシージャのoutパラメータの値が保持されます。タイプはhttp://xmlns.oracle.com/pcbpel/adapter/db/Hello/}args_out_msgです。
「グローバル変数」が選択されていることを確認してください。
「変数の作成」ダイアログ・ボックスで「OK」をクリックします。

図4-93のように「Invoke」ウィンドウの選択内容が表示されます。

図4-93 「Invoke」ウィンドウ

「図4-93 「Invoke」ウィンドウ」の説明
「Invoke」ウィンドウで「OK」をクリックします。
「ファイル」メイン・メニューから「すべて保存」を選択します。

プロセスにより、GreetというinvokeアクティビティからHelloパートナ・リンクへのリンクが表示されます。

4.8.5 1つ目のassignアクティビティの作成

assignアクティビティを作成し、ストアド・プロシージャのinパラメータに入力値を割り当てます。

Greetというinvokeアクティビティの上に、「コンポーネント・パレット」セクションからassignアクティビティをドラッグ・アンド・ドロップします。

図storeproc6.gifの説明
assignアイコンをダブルクリックして、「Assign」ウィンドウを表示します。
「一般」タブをクリックします。
「名前」フィールドにInputと入力します。
「適用」をクリックします。
「コピー・ルール」タブをクリックします。
「作成」ドロップダウン・リストから「コピー操作」を選択します。

「コピー操作の作成」ダイアログ・ボックスが表示されます。

次の値を入力します。

フィールド	値
From
タイプ	変数
変数	「変数」→inputVariable→payload→client:GreetingProcessRequest→client:inputを開いて選択します。
To
タイプ	変数
変数	「変数」→Greet_Hello_InputVariable→InputParameters→ns2:InputParameters→NAMEを開いて選択します。

「コピー操作の作成」ダイアログ・ボックスが次のように表示されます。

図storeproc7.gifの説明

「OK」をクリックして「コピー・ルールの作成」ウィンドウを終了します。
「OK」をクリックして「Assign」ウィンドウを終了します。
「ファイル」メイン・メニューから「すべて保存」を選択します。

4.8.6 2つ目のassignアクティビティの作成

assignアクティビティを作成し、ストアド・プロシージャのoutパラメータの値を取得します。

Greetというinvokeアクティビティの下に、「コンポーネント・パレット」セクションからassignアクティビティをドラッグ・アンド・ドロップします。

図storeproc8.gifの説明
assignアイコンをダブルクリックして、「Assign」ウィンドウを表示します。
「一般」タブをクリックします。
「名前」フィールドにOutputと入力します。
「適用」をクリックします。
「コピー・ルール」タブをクリックします。
「作成」をクリックして「コピー操作の作成」ダイアログ・ボックスを表示します。

次の値を入力します。

フィールド	値
From
タイプ	変数
変数	「変数」→Greet_Hello_OutputVariable→OutputParameters→ns2:OutputParameters→GREETINGを開いて選択します。
To
タイプ	変数
変数	「変数」→outputVariable→payload→client:GreetingProcessResponse→client:resultを開いて選択します。

「OK」をクリックして「コピー操作の作成」ダイアログ・ボックスを閉じます。
「OK」をクリックして「Assign」ウィンドウを終了します。

JDeveloper BPEL Designerで、Greetingプロセスが次のように表示されます。

図storeproc9.gifの説明
「ファイル」メイン・メニューから「すべて保存」を選択します。

4.8.7 Greetingプロセスの検証、コンパイルおよびデプロイ

「アプリケーション・ナビゲータ」セクションに移動します。
Greetingを右クリックします。
「デプロイ」→「LocalBPELServer」→「デフォルト・ドメインにデプロイ」を選択します。
必要な場合にはドメインのパスワードを入力します（最初はbpelに設定されています）。
「OK」をクリックします。

これにより、BPELプロセスがコンパイルされます。エラーがないかどうかウィンドウの下部を確認します。エラーがない場合は、正常にデプロイされています。

4.8.8 Greetingプロセスの実行

Internet Explorerを使用して「スタート」→「すべてのプログラム」→「Oracle - Oracle_Home」→「Oracle BPEL Process Manager」→「Oracle BPEL Control」を選択するか、UNIXの場合は$ORACLE_HOME/bpel/bin/startorabpel.shスクリプトを実行して、Oracle BPEL Controlにログインします。
必要な場合にはパスワードを入力します（最初はbpelに設定されています）。

Oracle BPEL Controlの「ダッシュボード」タブが表示されます。BPELプロセスGreetingが「デプロイ済のBPELプロセス」リストに表示されています。
Greetingをクリックします。

「開始」タブが選択された状態で「このBPELプロセスをテスト中」ページが表示されます。
inputフィールドに名前を入力します（Johnなど）。
「XMLメッセージの転送」をクリックします。

プロシージャが実行されてBPELプロセスが終了すると、次のような値が表示されます。
```
Value:  <GreetingProcessResponse>
          <result>Hello John<result>
        </GreetingProcessResponse>
```
「インスタンスの監査」をクリックします。

一連のプロセス・アクティビティとともに、Oracle BPEL Controlの「インスタンス」タブが表示されます。
ストアド・プロシージャからの入力および出力を確認するには、Greetアクティビティで「詳細」をクリックします。

<InputParameters>要素の中の<NAME>タグとその値に注意してください。これはinputVariableから導出され、Input Assignアクティビティによって設定された値です。

<OutputParameters>要素の中の<GREETING>タグとその値に注意してください。この値は、ストアド・プロシージャの出力パラメータから導出されています。この値は、Output AssignアクティビティによってoutputVariableに割り当てられています。

図storeproc10.gifの説明
プロセス・フローを表示するには、「フロー」タブをクリックします。

プロセス・ダイアグラムが表示されます。
BPELプロセスから渡されるXMLを表示するには任意のアクティビティをクリックします。たとえば、次のXMLを表示するには、Greetというinvokeアクティビティをクリックします。

図storeproc11.gifの説明

4 Oracle Application Server Adapter for Databases

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

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

4.1.1.1 複数の表の問合せ

4.1.2 設計の概要

4.1.3 データベース・アダプタとOracle BPEL Process Managerの統合

4.1.4 データベース・アダプタとOracle Enterprise Service Busの統合

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

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

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

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

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

4.2.2.1 DML操作

4.2.2.2 ポーリング計画

4.3 Oracle BPEL Process Managerでのデータベース・アダプタの使用例

4.3.1 使用例: 1

4.3.2 「アダプタ構成ウィザード」の起動

4.3.3 データベースへの接続

4.3.4 操作タイプの選択

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

4.3.6 主キーの定義

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

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

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

4.3.8 オブジェクト・フィルタの作成

4.3.9 WHERE句の定義

4.3.10 読取り後計画の選択

4.3.10.1 読取り済の行の削除

4.3.10.2 表のフィールドの更新（論理削除）

4.3.10.3 順序表の更新

4.3.11 設計時の内部処理

4.3.11.1 表のインポート

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

4.3.11.3 設計時成果物の生成

4.3.12 使用例: 2

4.3.12.1 前提条件

4.3.12.2 新規BPELプロジェクトの作成

4.3.12.3 「アダプタ構成ウィザード」の起動

4.4 Oracle Enterprise Service Busでのデータベース・アダプタの使用例

4.4.1 前提条件

4.4.2 新規ESBプロジェクトの作成

4.4.3 インバウンド・データベース・アダプタの作成

4.4.4 アウトバウンド・データベース・アダプタ・サービスの作成

4.4.5 ルーティング・サービスの構成

4.4.6 ESB Consoleのチェック

4.4.7 ESB Controlでの実行チェック

4.5 高度な構成

4.5.1 TopLink Workbenchプロジェクト

4.5.1.1 ディスクリプタの削除

4.5.1.2 問合せ中に返される部分オブジェクト

4.5.1.3 マッピング名の変更

4.5.1.4 オフライン・データベース表の構成

4.5.2 リレーショナルからXMLへのマッピング（toplink_mappings.xml）

4.5.3 サービス定義（WSDL）

4.5.3.1 DBWriteInteractionSpec

4.5.3.2 DBReadInteractionSpec

4.5.3.3 DBActivationSpec

4.5.4 XMLスキーマ定義（XSD）

4.5.5 デプロイ

4.5.5.1 データベース・アダプタによる接続情報の取得方法

4.5.5.2 デフォルトでのデプロイ

4.5.5.3 本番のデプロイ

4.5.5.4 oc4j-ra.xmlファイルの高度なプロパティ

4.5.5.5 比較: リリース10.1.3より前とリリース10.1.3以降

4.5.6 パフォーマンス

4.5.6.1 パフォーマンスに関する使用例

4.5.6.2 パフォーマンス・ヒット・リスト

4.5.6.3 アウトバウンド書込み: merge、writeまたはinsertからの選択

4.5.6.4 TopLinkキャッシュ: 使用する時期

4.5.6.5 存在チェック

4.5.6.6 インバウンド・ポーリング: maxRaiseSize

4.5.6.7 インバウンド・ポーリング: ポーリング計画の選択

4.5.6.8 リレーションシップの読取り（バッチ属性および結合属性の読取り）

4.5.6.9 接続プーリング

4.5.6.10 インバウンド分散ポーリング

4.5.7 detectOmissions機能

4.5.8 OutputCompletedXml機能

4.6 サード・パーティJDBCドライバとデータベース接続の構成

4.6.1 Microsoft SQL Serverの使用方法

4.6.1.1 MS JDBCドライバ

4.5.7 `detectOmissions`機能

4.5.8 `OutputCompletedXml`機能