Oracle Application Server Adapters for Files, FTP, DatabasesおよびEnterprise Messagingユーザーズ・ガイド 10g (10.1.3.1.0) B31889-01 |
|
![]() 戻る |
![]() 次へ |
この章では、Oracle BPEL Process ManagerおよびOracle Enterprise Service Busと連携して機能するOracle Application Server Adapter for Databases(データベース・アダプタ)について説明します。ストアド・プロシージャおよびファンクション(Oracleデータベースのみ)のサポートについても説明します。データベース・アダプタおよびストアド・プロシージャの使用例も参照できます。
この章には、次の項目が含まれます。
データベース・アダプタを使用すると、Oracleデータベースまたはサード・パーティのデータベースとBPELプロセスとのJDBCを介した通信が可能になります。データベース・アダプタ・サービスは、Oracle BPEL Process Managerのアダプタ構成ウィザードを使用してBPELプロセスのパートナ・リンク内で定義されます。
この項には、次の項目が含まれます。
データベース・アダプタは、任意のリレーショナル・データベースと接続できます。非リレーショナル・データベースやレガシー・システムの場合は、アプリケーション・アダプタおよびメインフレーム・アダプタを使用できます。アプリケーションおよびメインフレーム用のアダプタの詳細は、『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
複数の関連表に対するSQL select
文を実行する場合、SQLを作成するには次の3つの方法があります。 これらの方法は、マスター・レコードに対する問合せ時にディテール・レコードを取り込む方法に関係しています。
以降の各項では、この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に、データベース・アダプタが様々な設計時成果物およびデプロイ成果物とどのように対話するかを示します。
データベース・アダプタは独立した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ファイルが作成されますが、設計時以外は不要です。
J2CA 1.5リソース・アダプタとBPEL Process Managerを双方向で統合するために、アダプタ・フレームワークが使用されています。 アダプタ・フレームワークは規格に準拠しており、基盤となるJ2CA相互作用をWebサービスとして公開するためのWeb service Invocation Framework(WSIF)テクノロジが使用されています。
データベース・アダプタのアーキテクチャ、Oracle BPEL Process Managerとのアダプタの統合、およびアダプタのデプロイの詳細は、『Oracle Application Server Adapter概要』を参照してください。
Oracle Enterprise Service BusサーバーはOracleアダプタをサポートしており、それぞれのインバウンドおよびアウトバウンドのアダプタ・サービスを定義できます。 インバウンド・アダプタ・サービスでは、外部データソースからデータが受信されてXMLメッセージに変換されます。 アウトバウンド・アダプタ・サービスでは、XMLメッセージが特定のアダプタのネイティブ・フォーマットに変換され、データがターゲット・アプリケーションに送信されます。
Oracle Enterprise Service Busサーバーを使用すると、Oracle Database表から抽出したメッセージまたはストアド・プロシージャを実行して作成したメッセージを送受信できます。
ESBはBPELの後継であり、このマニュアルのほとんどの部分およびサンプルはBPELを使用することを想定しています。 ただし、アダプタの動作はBPELでもESBでも同じです。 ここでBPELに言及している箇所は、ESBで置き換えてかまいません。
この項には、次の項目が含まれます。
「リレーショナルからXMLへのマッピング」に含まれる高度なトピックについては、「高度な構成」の「リレーショナルからXMLへのマッピング(toplink_mappings.xml)」を参照してください。
フラット表またはスキーマでは、リレーショナルからXMLへのマッピングを簡単に参照できます。表の各行は複合XML要素になります。各列の値はXML要素のテキスト・ノードになります。列値およびテキスト要素のどちらもプリミティブ型です。
表4-1に、MOVIES
表の構造を示します。この表は、この章で説明する使用例で使用されます。 詳細は、「Oracle BPEL Process Managerでのデータベース・アダプタの使用例」を参照してください。
表4-1 MOVIES表の説明
名前 | NULLかどうか | タイプ |
---|---|---|
|
NULL以外 |
|
|
-- |
|
|
-- |
|
|
-- |
|
|
-- |
|
|
-- |
|
|
-- |
|
|
-- |
|
|
-- |
|
|
-- |
|
|
-- |
|
|
-- |
|
|
-- |
|
|
-- |
|
|
-- |
|
対応する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かどうか | タイプ |
---|---|---|
|
NULL以外 |
|
|
-- |
|
|
-- |
|
|
-- |
|
|
-- |
|
|
-- |
|
|
-- |
|
|
-- |
|
前の表定義が示すように、典型的な正規化されたリレーショナル・スキーマであるため、EMP表には従業員の部門番号が格納されていません。そのかわり、EMP
の列の1つ(DEPTNO
)は外部キーで、DEPT
の主キー(DEPTNO
)に相当します。
ただし、対応するXMLには主キーおよび外部キーに類似の概念はありません。このため、結果のXMLでは同一のデータが階層で表されます。したがって、リレーションシップは、マスター内部にインライン(埋込み)でディテール・レコードを取得することで保持します。
XML要素には、プリミティブ型(string
やdecimal
)または別のXML要素である複合型のいずれかの要素を含めることができます。そのため、従業員の要素に部門の要素を含めることができます。
対応するXMLで、リレーションシップがどのように表現され、インラインでどのように表示されるかを示します。EMP
からはDEPTNO
が削除され、DEPT
自体が表示されています。
<EmpCollection> <Emp> <comm xsi:nil = "true" ></comm> <empno >7369.0</empno> <ename >SMITH</ename> <hiredate >1980-12-17T00:00:00.000-08:00</hiredate> <job >CLERK</job> <mgr >7902.0</mgr <sal >800.0</sal> <dept> <deptno >20.0</deptno> <dname >RESEARCH</dname> <loc >DALLAS</loc> </dept> </Emp> ... </EmpCollection>
リレーションシップを表現することで人間がXMLを読み取ることが可能になり、データを情報の1つのパケットとして送信できます。XMLでは循環が許可されていないため、要素はそれ自体を含むことはできません。これはデータベース・アダプタにより自動的に処理されます。ただし、重複の可能性があります(つまり、異なるマスター・レコードで、同じ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-4に、データベースから表をインポートする際に、データベースのデータ型がどのようにXMLのプリミティブ型に変換されるかを示します。
表4-4 データベースのデータ型のXMLのプリミティブ型へのマッピング
データベース・タイプ | XMLタイプ(接頭辞はxs:) |
---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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
でエンコードされ、文字データとして渡されます。
データベース・アダプタでは、リレーショナル・データベース上の任意のリレーショナル・スキーマの、任意のXMLスキーマへのマッピングがサポートされています。ただし、要素のレイアウトに対する明確なユーザー制御がない状態でウィザードによりXMLスキーマが生成されるため、ユーザーはXMLスキーマを選択できません。 スキーマのマッピング方法は、「アダプタ構成ウィザード」で制御することも、後からTopLink Workbenchで制御することもできます。トランスフォーメーション・ステップとデータベース・アダプタを関連付けることで、任意のリレーショナル・スキーマを任意のXMLスキーマにマッピングできます。
リレーショナル・スキーマをXMLとしてマッピングした後、基本的なSQL操作もWebサービスとしてマッピングする必要があります。次の項で説明する各操作には、対応するチュートリアルとREADMEがあります。ここで説明されている作業から開始し、この項を読み進めながら実際に1つ以上行ってみることをお薦めします。チュートリアルで説明するように、いくつかの操作では直接SQL等価に変換されますが、その他はより複雑です。
詳細は、次の項を参照してください。
この項には、次の項目が含まれます。
データ操作言語(DML)の操作は、基本的なSQLのINSERT
、UPDATE
およびSELECT
操作と同等です。SQLのINSERT
、UPDATE
、DELETE
およびSELECT
は、すべて同じ名前のWebサービス操作にマッピングされます。WRITE
は、存在チェックの結果に基づき、INSERT
またはUPDATE
のいずれかになります。 アウトバウンド書込みと呼ばれるデータ操作とアウトバウンド読取りと呼ばれるSELECT
操作とで区別されます。merge
(アウトバウンド書込みのデフォルト)およびqueryByExample
に関するWebサービスとSQLとの関係は、基本的なSQLのINSERT
、UPDATE
およびSELECT
との関係ほど明確ではありません。
この項には、次の項目が含まれます。
Merge
では、まずデータベースの対応するレコードが読み取られて変更箇所が算出され、最低限の更新が実行されます。INSERT
、UPDATE
およびWRITE
は、単一の行および表が作業対象の場合に最も適切です。ただし、XMLには複合型が含まれ、複数の表の複数の行にマッピングされます。多数のEMPS
のあるDEPT
があり、EMPS
にはそれぞれADDRESS
があるとします。この場合、変更された可能性のある行がどのくらいで、どの行を挿入、更新または削除すればよいかを算出する必要があります。特定の行が変更されなかったか、1つのフィールドのみが変更された場合、DMLコールは最小限になります。
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 アウトバウンド・アダプタ・サービスでは、 |
リリース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
インバウンドのreceive操作では、データベース内のイベントや変更のリスニングおよび検出が可能で、言い換えればビジネス・プロセスを起動させる役割を果たします。これは一度のみのアクションではなく、アクティブ化です。新しい行またはイベントに関してデータベース表をポーリングする、ポーリング・スレッドが開始されます。
MOVIES
表に新しい行が挿入されるたびに、ポーリング操作によりOracle BPEL Process Managerに伝達されます。目的はすべてのレコードを一度ポーリングすることです。開始時に存在する行、および一定期間にわたり新しい行が挿入されるたびにそれらをすべて受信するには、最初のSELECT
を一定期間繰り返す必要があります。ただし、一度読み取られた新しい行は削除されないため、各ポーリングで繰り返し読み取られる可能性があります。
イベントをポーリングする様々な方法は、ポーリング計画、読取り後計画または公開計画とも呼ばれ、単純で変更を伴うものから複雑で変更を伴わないものまで多岐にわたります。各計画では、行やイベントの読取り後に次のポーリング間隔で再度検索しないためにはどうしたらよいかという問題に対して異なる解決策が採用されています。最も簡単(および変更を伴う)解決策は、行を削除して再度問い合せないようにすることです。
注意: データベースに複数のレコードを挿入しようとすると、DBWriteInteractionSpec Execute Failed 例外がスローされます。 この例外の解決策を次に示します。
次の <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> この値を相当大きい値に増やすと、この例外を回避できます。 |
この項では、次に示すポーリング計画と、特定の状況でどの計画を採用するかの判断基準を説明します。
物理削除ポーリング計画では、データベース表でレコードをポーリングし、処理後に削除します。この計画は、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');
このポーリング計画では、順序値の保存にヘルパー表の使用が関連します。ソース表は変更されませんが、別のヘルパー表で読取り済の行が記録されます。たとえば、順序値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
122.DBAdapter
チュートリアルで説明されているデータベース・アダプタを使用するには、次の場所に移動します。
Oracle_Home
\bpel\samples\tutorials\122.DBAdapter
表4-9に、Oracle BPEL Process Managerで提供されているデータベース・アダプタのサンプルを示します。
表4-9 データベース・アダプタの使用例
チュートリアル名 | 説明 |
---|---|
|
データベース・アダプタのアウトバウンドの |
|
ストアド・プロシージャ |
|
カスタム形式で定義されているネイティブ(CSV)データの入力ファイルの使用方法を説明します。入力ファイルは注文書で、ファイル・アダプタによって処理され、FIle2Table BPELプロセスにXMLメッセージとして公開されます。メッセージは別の注文書形式に変換され、 |
|
データベース・アダプタのアウトバウンドの |
|
BPELプロセスへのフォルト処理の追加に必要な追加の手順( |
|
PL/SQLレコード型の使用に関する解決策を説明します。JPublisherは、属性がRECORDのフィールドに一致する対応するOBJECT型、およびRECORDとOBJECTの相互変換を行う変換APIの作成に使用されます。また、JPublisherではOBJECTを許可し、両方向で変換APIを使用して基礎となるメソッドを起動するラッパー・プロシージャ(またはファンクション)が生成されます。起動されたメソッドが、(Oracle Liteではない)Oracleデータベースにインストールされている必要があります。 |
|
一連の表から別の表へデータを移動する方法を説明します。サンプルでは、データベース・アダプタを使用して、一連の表からデータを読み取って処理し、アダプタを使用して別のデータベース表に書き込みを行っています。 |
|
データベース・アダプタのアウトバウンドの |
|
|
|
|
|
|
|
|
|
日付フィールドに基づいて表をポーリングする方法を説明します。 |
|
|
|
データベース・アダプタのアウトバウンドの |
|
REF CURSORの使用に関する解決策を説明します。解決策には、対応する |
|
データベース・アダプタのアウトバウンドの |
|
データベース・アダプタのアウトバウンドの |
|
データベース・アダプタのアウトバウンドの |
使用例の多くで使用されているMOVIES
表の構造は、表4-1を参照してください。ほとんどのサンプルに含まれているreadme.txt
ファイルには、説明が記載されています。
この項は、次の2つの使用例で構成されています。
この使用例では、「アダプタ構成ウィザード」を使用して、データベースからの表のインポート、複数の表にわたるリレーションシップの指定、対応するXMLスキーマ定義の生成、および必要なSQLまたはデータベース操作を公開するサービスの作成を行う方法について説明します。これらのサービスは、BPELプロセスで使用されるパートナ・リンクの定義に使用されます。アダプタ・サービスの作成および編集のどちらにもアダプタ構成ウィザードを使用します。
この項には、次の項目が含まれます。
JDeveloper BPEL DesignerでBPELプロジェクトを作成したら、データベース・アダプタの定義を開始できます。 ウィンドウが隠れてしまった場合は、[Alt]
キーを押しながら[Tab]
キーを押して再度表示します。
アダプタ構成ウィザードを起動するには、次のようにします。
「コンポーネント・パレット」セクションのドロップダウン・リストで「All Process Activities」が選択されていることを確認します。
デザイナ・ウィンドウの右側に、PartnerLinkアクティビティをドラッグ・アンド・ドロップします。
「パートナ・リンクの作成」ウィンドウに名前を入力します。
「アダプタ・サービスの定義」アイコンをクリックして、アダプタ構成ウィザードを起動します。
「ようこそ」ウィンドウの「次へ」をクリックします。
「アダプタ・タイプ」に「データベース・アダプタ」を選択して、「次へ」をクリックします。
「サービス名」ウィンドウで、サービスの名前と説明を入力します。
説明はオプションです。
「次へ」をクリックします。 「サービス接続」ウィザードが表示されます。
ウィザードの使用を続行するには、「データベースへの接続」を参照してください。
図4-2に、サービスで使用するデータベース接続を選択する場所を示します。これは、サービスを構成する表をインポートするデータベースです。
データベース接続を識別するJava Naming and Directory Interface(JNDI)の名前を指定するか、指定されたデフォルト名を使用できます。JNDI名は、サービスがOracle BPEL Serverにデプロイされる際に使用される接続のプレースホルダとして機能します。これにより、開発と本番に異なるデータベースを使用できます。アダプタ構成ウィザードにより、生成されたWSDLの設計時の接続も取得され、実行時の検索に失敗した場合に予備として機能します。
次の事項に注意してください。
本番環境では、アダプタのデプロイメント・ディスクリプタ(oc4j-ra.xml
)にJNDIエントリを追加することをお薦めします。この場合、管理モードで作業することでデータベース・アダプタのパフォーマンスが向上します。管理モード以外の場合、データベース・アダプタでは設計時の接続情報が使用されます。
「次へ」をクリックすると、データベースへの接続が試行されます。接続を確立できないと、既存のパートナ・リンクを編集している場合でも次のウィンドウに進めません。
ウィザードの使用を続行するには、「操作タイプの選択」を参照してください。
図4-3に、このサービスに構成する操作タイプを指定する場所を示します。
次の操作タイプを使用できます。
ストアド・プロシージャまたはファンクションの呼出し
サービスでストアド・プロシージャまたはファンクションを実行する場合にこのオプションを選択します。 詳細は、「ストアド・プロシージャおよびファンクションのサポート」を参照してください。
表に対して操作を実行
このオプションは、アウトバウンド操作に対して選択します。 「挿入/更新」、「挿入のみ」、「更新のみ」、「削除」、「選択」、またはこの5つの任意の組合せを選択できます。これらの操作は、同等のSQL操作であるINSERT
、UPDATE
、DELETE
およびSELECT
に変換されます。 詳細は、「DML操作」を参照してください。
次の事項に注意してください。
「挿入/更新」を選択すると、merge、insert、updateおよびwrite操作が作成されます。
前述の起動ウィンドウでは、MergeService
サービス名が選択操作、つまりMergeServiceSelectの一部として表示されています。
queryByExample操作は、すべてのWSDLに表示されます。
「操作」リストが空の場合は、パートナ・リンクを再度選択して「操作」リストを再度クリックします。
注意: 「更新のみ」操作では、子レコードに対する挿入または削除が実行されることがあります。 これは、マスターの更新に伴い、ディテールが追加または削除されることがあるためです。 したがって、更新対象の入力に含まれるレコードが1つのみの場合は、表内の他のレコードが削除されます。 |
表の新規レコードまたは更新されたレコードをポーリング
この操作は、インバウンド操作(つまり、receiveアクティビティと関連付けられている操作)に対して選択します。この操作タイプでは、指定された表がポーリングされ、追加された任意の新しい行の処理用に返されます。また、ポーリング間隔も指定できます。 詳細は、「ポーリング計画」を参照してください。
ウィザードの使用を続行するには、「表の選択およびインポート」を参照してください。
図4-4に、操作のルート・データベース表を選択する場所を示します。複数の関連する表を使用している場合は、これがリレーションシップ・ツリーの最上位の表(または最上位の親表)になります。
このウィンドウには、JDeveloper BPEL Designerプロジェクトに前もってインポートされていた表がすべて表示されます(他のパートナ・リンク用にインポートされていた表も含みます)。これにより、指定されたBPELプロジェクトの複数のパートナ・リンク全体で、構成された表定義を再利用できます。これらは生成されたTopLinkディスクリプタです。
この操作に使用するルート・データベース表がインポート済でない場合は、「表のインポート」をクリックします。表を再度インポートする必要がある場合(データベースで表構造が変更されていた場合など)は、再度インポートします。表を再度インポートして、以前に構成された表定義を上書きできます。
注意: 表を再度インポートすると、その表に定義したカスタム・リレーションシップとカスタムのWHERE 句が失われます(インポートする表がルート表の場合)。 |
ウィザードの使用を続行するには、「主キーの定義」を参照してください。
インポートした表にデータベースで定義された主キーがない場合、図4-5に示すように、各表に主キーを指定するよう求められます。インポートしたすべての表に主キーを指定する必要があります。マルチパートの主キーを指定する必要がある場合には、複数のフィールドを選択できます。
ここで指定する主キーは、オフライン・データベース表に記録され、データベース・スキーマには保存されないため、データベース・スキーマは変更されません。
ウィザードの使用を続行するには、「リレーションシップの作成」を参照してください。
図4-6に、ルート・データベース表およびその他の関連する表に定義されたリレーションシップを示します。 「リレーションシップの作成」をクリックすると2つの表の間に新しいリレーションシップを作成でき、「リレーションシップの削除」をクリックするとリレーションシップを削除できます。
リレーションシップの作成に関して次の事項に注意してください。
データベース上に表間の外部キー制約がすでに存在する場合、表をインポートすると、ソース表(外部キー制約を含む表)からターゲット表に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に、新しいリレーションシップを作成する場所を示します。
新しいリレーションシップを作成するには、次のようにします。
親表と子表を選択します。
マッピング・タイプ(1対多、1対1または子表に外部キーのある1対1)を選択します。
外部キー・フィールドを主キー・フィールドに関連付けます。
オプションでリレーションシップに名前を付けます(デフォルト名が生成されます)。
注意: 親表として選択できるのは、ルート表からアクセス可能な表のみです。 |
ウィザードに最初に表がインポートされると、データベースの各フィールドに対応する、TopLinkのフィールドへの直接的なマッピングが作成されます。図4-8および図4-9に示すスキーマがあるとします。
これら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-14に、インポートされた表の定義から作成されたオブジェクト・フィルタを示します。これには定義したリレーションシップも含まれます。
オブジェクト・フィルタにセルフ・リレーションシップ(従業員対従業員の管理者のリレーションシップなど)が含まれる場合、ツリーではループとして表示されます。XSDではループは表示されません。これはディスクリプタ・オブジェクト・モデルであり、XSDではありません。
ウィザードの使用を続行するには、「WHERE句の定義」を参照してください。
サービスにSELECT
問合せ(インバウンド・ポーリング・サービスまたはSELECT
を含むアウトバウンド・サービスなど)が含まれる場合、SELECT
文の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に示すように、「編集」をクリックして「式ビルダー」を起動します。
詳細は、次を参照してください。
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式ビルダーを使用した式の構成に関するマニュアルが含まれます。
ウィザードの使用を続行するには、「読取り後計画の選択」を参照してください。
インバウンド操作の構成時には、1つ以上の行が読み取られた後の処理に関して次のオプションがあります。
図4-17にこれらのオプションを示します。
詳細は、「ポーリング計画」を参照してください。
このオプションでは、ルート・データベース表のフィールドを更新して、その行が読取り済であることを示します。図4-18に示すように、構成の完了後に問合せのWHERE
句が自動的に更新されます。
この方法を使用すると、データベース表は図4-19のようになります。
次の事項に注意してください。
行150および153はすでに読み取られて処理されています。
STATUS列にUNPROCESSED
と表示されているため、次のポーリング・イベントで、行152が読み取られて処理されます。Unread Value
が明示的に指定されているため、行151は読み取られません。
行154にはLOCKED
というフラグが付いているため読み取られません。表が他のプロセスに使用されている場合、この予約値を使用できます。
このオプションでは、別の順序表の最終読取り行を追跡します。図4-20に指定する情報を示します。構成が完了すると、問合せのWHERE
句が自動的に更新されます。
これらの設定を使用すると、順序表は図4-21のようになります。
行が読み取られるたびに、この表は読み取られたIDで更新されます。次のポーリング・イベントが発生すると、最終読取りID(154)より大きなIDの行が検索されます。
使用される一般的な列は、event_id
、transaction_id
、scn
(システム変更番号)、id
またはlast_updated
です。通常、これらの列には順序番号またはsysdate
が移入され、値は(一定量で)増加します。
この項では、アダプタ構成ウィザードを使用してデータベース・アダプタを構成する際に、設計時に内部的に発生することを説明します。
表をインポートすると、JDeveloper BPEL Designerのオフライン表のサポートにより、データベース表のオフライン・スナップショットが作成されます。このオフライン・バージョンの表は、実データベース表に影響を与えずに変更できます(たとえば、外部キー制約を追加できます)。これにより、この表のTopLinkディスクリプタおよび関連するJavaソース・ファイルが作成され、ディスクリプタのすべての属性が対応するデータベース列に自動的にマッピングされます。TopLinkディスクリプタにより、Javaクラスがオフライン・データベース表にマッピングされます。
最も一般的なデータ列が、フィールドへの直接マッピングとしてマッピングされます。つまり、データベース列の値が直接属性にマッピングされます。たとえば、データベースのSALARY
列はオブジェクト・モデルのsalary
属性にマッピングされ、その属性にはこの列の値が含まれます。
インポートされた表にすでに外部キー制約がある場合、表の間でリレーションシップのマッピングが自動的に生成されます。できるだけ多くのシナリオを網羅するため、既存の各外部キー制約には、ソース表からターゲット表への1対1マッピングと、逆方向への1対多マッピングの2つのマッピングが生成されます。 これが完了すると、BPELプロジェクトにTopLink Workbenchプロジェクトが作成されています。
注意: ディスクリプタ生成処理の一部として作成されるJavaクラスは、実際には、プロセスとともにデプロイされることも実行時に使用されることもありません。 TopLink Workbenchでは、各ディスクリプタがJavaクラスと関連付けられていることを前提としているため、設計時に存在します。プロセスがデプロイされると、マッピング・メタデータはtoplink_mappings.xml に保存されます。 |
表のインポートが終了したら、ルート・データベース表を選択する必要があります。その際、実際には、どのTopLinkディスクリプタに自動生成された問合せを格納するかを選択しています。
リレーションシップの作成または削除の際、実際には、TopLinkディスクリプタのマッピングを変更しています。新しいリレーションシップの作成では、次のことが行われています。
オフライン・データベース表に外部キー制約が作成されます。
ディスクリプタに1対1または1対多マッピングが追加されます。
外部キー・フィールドへの直接マッピングが削除されます。
リレーションシップ・マッピングの削除では、次のことが行われます。
ディスクリプタから1対1または1対多マッピングが削除されます。
オフライン・データベース表から外部キー制約が削除されます。
リレーションシップに関連する各外部キー・フィールドへの直接マッピングが追加されます。
この項では、ポーリング・ファイル順序付け計画という高度な使用例について説明します。 この使用例は次の場所にあります。
Oracle_Home
\bpel\samples\tutorials\122.DBAdapter\advanced/polling/PollingFileSequencingStrategy
このシナリオは、変更を伴わないポーリングを実行することを意図しています。 この例の順序付け計画で注意する必要があるのは、last read id
/sequence value
という1つの情報のみです。 この情報を同一データベースまたは異なるデータベースの表に格納するか、単にファイルに格納できます。
この項には、次の項目が含まれます。
次のディレクトリにあるsql
スクリプトsetup.sqlおよびreset.sqlを実行していることを確認します。
Oracle_Home
\bpel\samples\tutorials\122.DBAdapter\sql
次の手順に従って新規BPELプロジェクトを作成します。
Oracle JDeveloperを開きます。
「ファイル」メニューから「新規」を選択します。
「新規ギャラリ」ダイアログ・ボックスが表示されます。
「フィルタ方法」ボックスから「すべてのテクノロジ」を選択します。 使用可能なカテゴリのリストが表示されます。
「General」ノードを開いて「Projects」を選択します。
「項目」グループから「BPELプロジェクト」を選択します。
「OK」をクリックします。
「BPELプロジェクト作成」ダイアログ・ボックスが表示されます。
「OK」をクリックします。
新規BPELプロジェクトが作成されました。
Oracle JDeveloperでBPELプロジェクトを作成した後、データベース・アダプタの定義を開始できます。 データベース・アダプタを定義するには、次の手順を実行します。
「コンポーネント・パレット」からデザイナ・ウィンドウに「データベース・アダプタ」をドラッグ・アンド・ドロップします。
「アダプタ構成ウィザード - ようこそ」画面が表示されます。
「次へ」をクリックします。
「サービス名」ダイアログ・ボックスが表示されます。
図4-22のようにサービス名を入力します。 「説明」フィールドはオプションです。
「次へ」をクリックします。
「サービス接続」ダイアログ・ボックスが表示されます。
プロジェクトに定義済のデータベース接続を選択するか、新規接続を作成します。
「次へ」をクリックします。
「操作タイプ」ダイアログ・ボックスが表示されます。
図4-23のように、「表の新規レコードまたは更新されたレコードをポーリング」を選択します。
「次へ」をクリックします。
「表の選択」ダイアログ・ボックスが表示されます。
「表のインポート」をクリックします。
「表のインポート」ダイアログ・ボックスが表示されます。
図4-24のように、「MOVIES」表をダブルクリックして選択します。
「OK」をクリックします。
図4-25のように、MOVIES表が選択された状態で「表の選択」ダイアログ・ボックスが表示されます。
「次へ」をクリックします。
「リレーションシップ」ダイアログ・ボックスが表示されます。
「リレーションシップ」ダイアログ・ボックスで、ルート・データベースからアクセス可能なリレーションシップを定義できます。 ただし、この例ではリレーションシップを定義しません。「次へ」をクリックします。
表示される「オブジェクトのフィルタ」ダイアログ・ボックスで「次へ」をクリックします。
「読取り後」ダイアログ・ボックスが表示されます。
「順序ファイルの更新」を選択して「次へ」をクリックします。
「順序ファイル」ダイアログ・ボックスが表示されます。
次の情報を入力します。
順序ファイル: 順序ファイルの場所を指定します。 この例では、次のように指定します。
Oracle_Home
\bpel\samples\tutorials\122.DBAdapter\advanced\polling\PollingFileSequencingStrategy\lastReadId.txt
順序IDフィールド: 「LATST_UPDATED」を選択します。
図4-26に、値が移入された後の「順序ファイル」ダイアログ・ボックスを示します。
「次へ」をクリックします。
図4-27に示す「ポーリング・オプション」ダイアログ・ボックスが表示されます。
「ポーリング・オプション」ダイアログ・ボックスで、デフォルト値を保持して「次へ」をクリックします。
図4-28に示す「選択条件の定義」ダイアログ・ボックスが表示されます。
デフォルト値を保持して「次へ」をクリックします。
図4-29に示す「アダプタ構成ウィザード - 終了」画面が表示されます。
「終了」をクリックします。
すべてのフィールドが移入済の状態で、図4-30に示す「パートナ・リンクの作成」ダイアログ・ボックスが表示されます。
「OK」をクリックします。
画面は図4-31のようになります。
プロジェクトを右クリックして「デプロイ」を選択し、「ServerConnection1」をポイントして「Defaultドメインにデプロイ」をクリックします。
Oracle BPEL Controlは図4-32のようになります。
この使用例では、あるデータベースの表1セットのデータを別のデータベースの表にレプリケートする単純なシナリオを示します。 このシナリオでは、ソース表でのインバウンドのポーリング読取りと、宛先表へのアウトバウンドの書込みまたはマージを行います。
この使用例では、2組の部門表と従業員表があります。一方はインバウンド・データに使用されるSENDER_EMP
およびSENDER_DEPT
で、他方はアウトバウンド・データに使用されるRECEIVER_EMP
およびRECEIVER_DEPT
です。
各表セットに対する操作は個別のWSDLに定義されており、固有のデータベース・アダプタJNDI(接続)名を定義できることに注意してください。 つまり、各表セットを個別のデータベース・スキーマまたはインスタンスに置くことができます。
この項には、次のステップが含まれます。
アプリケーションを作成する前に、次の場所にあるストアド・プロシージャcreate_schemas.sql
を実行する必要があります。
OracleAS_1\bpel\samples\tutorials\122.DBAdapter\MasterDetail\sql\oracle
このストアド・プロシージャにより4つの表が作成されます。SENDER_EMP
およびSENDER_DEPT
はインバウンド・データベース・アダプタによりデータが読み取られる表で、RECEIVER_EMP
およびRECEIVER_DEPT
はアウトバウンド・データベース・アダプタによる新規データの格納元となる表です。
次の手順に従って新規ESBプロジェクトを作成します。
Oracle JDeveloperを開きます。
「ファイル」メニューから「新規」を選択します。
「新規ギャラリ」ダイアログ・ボックスが表示されます。
「フィルタ方法」ボックスから「すべてのテクノロジ」を選択します。 使用可能なカテゴリのリストが表示されます。
「General」ノードを開いて「Projects」を選択します。
図4-33のように、「項目」グループから「ESBプロジェクト」を選択します。
「OK」をクリックします。
「ESBプロジェクトの作成」ダイアログ・ボックスが表示されます。
「プロジェクト名」フィールドにわかりやすい名前を入力します。 たとえば、MasterDetails
と入力します。
「OK」をクリックします。
新規ESBプロジェクトMasterDetails
が作成されました。
次の手順に従ってインバウンド・データベース・アダプタを作成します。
「コンポーネント・パレット」から「アダプタ・サービス」を選択し、「データベース・アダプタ」をMasterDetails.esb
プロジェクトにドラッグ・アンド・ドロップします。
「データベース・アダプタ・サービスの作成」ダイアログ・ボックスが表示されます。
「データベース・アダプタ・サービスの作成」ダイアログ・ボックスで次の情報を指定します。
名前: サービスの名前を入力します。 この例では、InboundServices
と入力します。
システム/グループ: デフォルト値を保持します。
図4-34に、「名前」および「システム/グループ」フィールドに情報を入力した後の「データベース・アダプタ・サービスの作成」ダイアログ・ボックスを示します。
「アダプタ・サービスのWSDL」で「アダプタ・サービスのWSDLの構成」アイコンをクリックします。
「アダプタ構成ウィザード」の「ようこそ」ページが表示されます。
「次へ」をクリックします。
「サービス名」フィールドが入力済の状態で「サービス名」ダイアログ・ボックスが表示されます。
サービス名を保持して「次へ」をクリックします。
図4-35に示す「サービス接続」ダイアログ・ボックスが表示されます。
「新規」をクリックしてデータベース接続を定義します。
「データベース接続の作成」ウィザードの「ようこそ」ページが表示されます。
「次へ」をクリックします。
「タイプ」ダイアログ・ボックスが表示されます。
「タイプ」ダイアログ・ボックスに次の情報を入力します。
「接続名」フィールドで、データベース接続に使用する一意の名前を指定します。 この例では、masterdetailsと入力します。
「接続タイプ」ボックスから「Oracle (JDBC)」を選択します。
図4-36に「タイプ」ダイアログ・ボックスを示します。
「次へ」をクリックします。
「認証」ダイアログ・ボックスが表示されます。
次のフィールドに認証の資格証明を入力します。
「ユーザー名」フィールドで、データベース接続に使用する一意の名前を指定します。 この例では、scott
と入力します。
「パスワード」フィールドで、データベース接続に使用するパスワードを指定します。 この例では、tiger
と入力します。
「ロール」フィールドは空白にしておきます。
「パスワードを配布」を選択します。
図4-37に、各資格証明フィールドに値が移入された後の「認証」ダイアログ・ボックスを示します。
「次へ」をクリックします。
「接続」ダイアログ・ボックスが表示されます。
次のフィールドに情報を入力します。
「ドライバ」リストで、デフォルト値の「thin」を保持します。
「ホスト名」フィールドでデフォルト値の「localhost」を保持します。
「JDBCポート」フィールドで、データベース接続に使用するポート番号を指定します。 この例では、1521と入力します。
「SID」フィールドで、データベース接続に使用する一意のSID値を指定します。 この例では、ORCLと入力します。
図4-38に「接続」ダイアログ・ボックスを示します。
「次へ」をクリックします。
「テスト」ダイアログ・ボックスが表示されます。
「接続のテスト」をクリックし、指定した情報によりデータベースとの接続が確立されるかどうかを確認します。
「終了」をクリックして新規データベース接続の作成プロセスを完了します。
図4-39のように、「サービス接続」ダイアログ・ボックスが表示され、データベース接続のサマリーが示されます。
「次へ」をクリックします。
図4-40に示す「操作」ダイアログ・ボックスが表示されます。
「表の新規レコードまたは更新されたレコードをポーリング」を選択して「次へ」をクリックします。
「表の選択」ダイアログ・ボックスが表示されます。
「表のインポート」をクリックして表をインポートします。
図4-41に示す「表のインポート」ダイアログ・ボックスが表示されます。
「表のインポート」ダイアログ・ボックスで次の問合せパラメータを選択します。
スキーマ: 「SCOTT」を選択します。
名前フィルタ: 「問合せ」をクリックしてデータベースからオブジェクトを取得します。
使用可能な表のリストが表示されます。
「使用可能」列でRECEIVER_DEPT
およびRECEIVER_EMP
を選択し、「追加」ボタンをクリックして「選択」列に移動します。
図4-42に「追加」ボタンを示します。
図4-43のように、選択した表が「選択」列に表示されます。
「OK」をクリックします。
図4-44のように、インポートした表を含む「表の選択」ダイアログ・ボックスが表示されます。
ルート表を選択して「次へ」をクリックします。 この例では「SCOTT.RECEIVER_DEPT」
を選択します。
図4-45に示す「リレーションシップ」ダイアログ・ボックスが表示されます。
「次へ」をクリックします。
図4-46に示す「オブジェクトのフィルタ」ダイアログ・ボックスが表示されます。
「次へ」をクリックします。
「読取り後」ダイアログ・ボックスが表示されます。
「読取り後」ダイアログ・ボックスで、図4-47のように「読取り済の行の削除」を選択して「次へ」をクリックします。
図4-48に示す「ポーリング・オプション」ダイアログ・ボックスが表示されます。
「ポーリング・オプション」ダイアログ・ボックスで、デフォルト値を保持して「次へ」をクリックします。
図4-49に示す「選択条件の定義」ダイアログ・ボックスが表示されます。
デフォルトの問合せを保持して「次へ」をクリックします。 ただし、独自の式を定義するには「編集」をクリックします。
図4-50に示す「アダプタ構成ウィザード - 終了」画面が表示されます。
次の手順に従ってインバウンド・データベース・アダプタを作成します。
「コンポーネント・パレット」から「アダプタ・サービス」を選択し、「データベース・アダプタ」をMasterDetails.esb
プロジェクトにドラッグ・アンド・ドロップします。
「データベース・アダプタ・サービスの作成」ダイアログ・ボックスが表示されます。
「データベース・アダプタ・サービスの作成」ダイアログ・ボックスで次の情報を指定します。
名前: サービスの名前を入力します。 この例では、OutboundServices
と入力します。
システム/グループ: デフォルト値を保持します。
「アダプタ・サービスのWSDL」で「アダプタ・サービスのWSDLの構成」アイコンをクリックします。
「アダプタ構成ウィザード」の「ようこそ」ページが表示されます。
「次へ」をクリックします。
「サービス名」フィールドが入力済の状態で「サービス名」ダイアログ・ボックスが表示されます。
サービス名を保持して「次へ」をクリックします。
「サービス接続」ダイアログ・ボックスが表示されます。
作成済の接続を選択して「次へ」をクリックします。
図4-51に示す「操作」ダイアログ・ボックスが表示されます。
「表に対して操作を実行」を選択して「次へ」をクリックします。
「表の選択」ダイアログ・ボックスが表示されます。
「表のインポート」をクリックして表をインポートします。
「表のインポート」ダイアログ・ボックスが表示されます。
「表のインポート」ダイアログ・ボックスで次の問合せパラメータを選択します。
スキーマ: 「SCOTT」を選択します。
名前フィルタ: 「問合せ」をクリックしてデータベースからオブジェクトを取得します。
使用可能な表のリストが表示されます。
「使用可能」列でSENDER_DEPT
およびSENDER_EMP
を選択し、「追加」ボタンをクリックして「選択」列に移動します。
図4-52のように、選択した表が「選択」列に表示されます。
「OK」をクリックします。
図4-53のように、インポートした表を含む「表の選択」ダイアログ・ボックスが表示されます。
ルート表を選択して「次へ」をクリックします。 この例では「SCOTT.SENDER_DEPT」
を選択します。
図4-55に示す「リレーションシップ」ダイアログ・ボックスが表示されます。
「次へ」をクリックします。
図4-55に示す「オブジェクトのフィルタ」ダイアログ・ボックスが表示されます。
「次へ」をクリックします。
図4-56に示す「選択条件の定義」ダイアログ・ボックスが表示されます。
「次へ」をクリックします。
図4-57のように、アウトバウンド・サービスの作成を確認する「終了」画面が表示されます。
次の手順に従ってルーティング・サービスを構成します。
「InboundServices」
ルーティング・サービスをダブルクリックします。
図4-58のように、「アプリケーション」ウィンドウの中央ペインに「ルーティング・サービス」ウィンドウが表示されます。
「ルーティング・ルール」タブを選択し、「+」アイコンをクリックしてルールを追加します。
「ターゲット・サービス操作の参照」ダイアログ・ボックスが表示されます。
図4-59のように、「マージ」サービスを選択して「OK」をクリックします。
「OK」をクリックします。
「アプリケーション」ウィンドウの中央ペインは図4-60のようになります。
「トランスフォーメーション」アイコンをダブルクリックし、「新規マッパー・ファイルの作成」アイコンをクリックします。
図4-61に示す「リクエスト・トランスフォーメーション・マップ」ダイアログ・ボックスが表示されます。
「新規マッパー・ファイルの作成」オプションを選択します。
デフォルト値を受け入れて「OK」をクリックします。
図4-62に示す「トランスフォーメーション」ウィンドウが表示されます。
マッパーの左側で要素を選択し、右側の要素へドラッグしてマップ・プリファレンスを設定します。
「アプリケーション」ウィンドウの中央ペインは図4-63のようになります。
マッパーの設定を保存してタブを閉じます。
ルーティング・サービスの設定を保存してタブを閉じます。
MasterDetailsプロジェクトの中央ペインは図4-64のようになります。
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-66に示す「成功」ページが表示されます。
ESB Controlをチェックするには、ESB Consoleを開きます。 例: http://localhost:8888/esb/esb/EsbConsole.html
図4-67のようなサービス・ウィンドウが表示されます。
次の手順に従ってESB Controlで実行をチェックします。
ESB Consoleを開きます。
右上隅の「インスタンス」をクリックします。
「検索」の横にある緑の矢印をクリックします。
図4-68のようなインスタンスが表示されます。
BPELプロセスの一部としてデータベース・アダプタを使用するために必要なものは、すべてアダプタ構成ウィザードで生成されます。次の項では、パフォーマンスの問題とともに、ウィザードの使用時にバックグラウンドで行われることについて説明します。
この項には、次の項目が含まれます。
ウィザードは、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プロジェクトに影響のある変更(表のインポート、マッピングの作成または削除、式の指定など)を行うとすぐに適用されます。ウィザードを取り消しても元に戻りません。
ディスクリプタを削除すると、そのディスクリプタを共有している他のパートナ・リンクに影響を与える可能性があるため、ウィザード内でプロジェクトからTopLinkディスクリプタを削除することはできません。ディスクリプタを明示的に削除するには、次のようにします。
「アプリケーション - ナビゲータ」で、プロジェクトの下にある「アプリケーション・ソース」の下の「TopLinkマッピング」ノードをクリックします。
「TopLinkマッピング - 構造」ペインのツリーからディスクリプタを選択します。
右クリックして「削除」を選択します。
現在、アダプタ構成ウィザードには、表から特定のフィールドのみを返す部分オブジェクトの読取りに対するビルトイン・サポートがありません。結果セットに不要な属性を手動でアンマップすることで、この機能を取得できます。リレーションシップ・マッピングは、「リレーションシップ」ウィンドウでそれらを削除することでアンマップできますが、ダイレクト・マッピングはTopLinkディスクリプタで明示的にアンマップする必要があります。
属性をアンマップするには、次のようにします。
「アプリケーション - ナビゲータ」で、プロジェクトの下にある「アプリケーション・ソース」の下の「TopLinkマッピング」ノードをクリックします。
「TopLinkマッピング - 構造」ペインのツリーから、アンマップする属性を含むディスクリプタを選択します。
アンマップする属性を右クリックして、「マップ」→「アンマップ」を選択します。
属性を再マップするには、次のようにします。
「アプリケーション - ナビゲータ」で、プロジェクトの下にある「アプリケーション・ソース」の下の「TopLinkマッピング」ノードをクリックします。
「TopLinkマッピング - 構造」ペインのツリーから、再マップする属性を含むディスクリプタを選択します。
再マップする属性を右クリックして、「マップ」→「フィールドへ直接」を選択します。
JDeveloper BPEL DesignerのウィンドウにTopLink Mappings Editorが自動的に開かれます。
「データベース・フィールド」から、属性をマップする列を選択します。
対応するJavaソース・ファイルを開いて名前を変更します。「構造/マッピング」ペインに移動すると、新しい名前の属性が表示されます。その属性を右クリックし、「マップ」を選択して再マップします。その後、保存してBPEL成果物を再生成します。
「TopLinkマッピング - 構造」ウィンドウからアクセスできるビューには、プロジェクト・ビュー、表/ディスクリプタ・ビュー、個別属性/列ビューおよびJavaソース・ビューの4つがあります。Javaソース・ビューは正確にはTopLinkビューではありませんが、(マッピング名の変更時には)TopLinkビューとして扱うことも可能です。
オフライン・データベース表は、TopLink Workbenchプロジェクトの内部にあります。ウィザードを実行すると、TopLinkプロジェクトが作成されます。表をインポートすると、オフライン表定義として保存されます。
オフライン・データベース表は、データベースのデータ型からXML型への小規模なマッピングの制御に使用できます。サード・パーティのデータベースを使用している場合は、回避策としてこれらのオブジェクトを編集する必要があります。たとえば、サード・パーティのデータベースのserial
フィールドはInteger
としてマッピングする必要があります。これにより、ウィザードで認識されてxs:integer
にマッピングされます。 詳細は、「サード・パーティのデータベース表をインポートする際の問題」を参照してください。
一度ウィザードを実行します。これによって、JDeveloper BPEL Designerプロジェクトにdatabase/
schemaName/schemaName
.schema
を追加します。
プロジェクトに追加された後の表名をクリックし(図4-69を参照)、任意の列の型を変更します。 ウィザードを(編集モードで)再度実行して「終了」をクリックすると、新しいデータベースのデータ型に基づいてtoplink_mappings.xml
およびXSDファイルが再マップされます。
ConnectionManager
からアクセス可能な表ではなく、JDeveloper BPEL Designerプロジェクトでオフライン表を編集します(図4-70を参照)。前者の場合、オフライン形式ではなく表自体を編集しているため、列の型は編集できません。
データベース・アダプタは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
に別のプロパティを設定できます。
アダプタ構成ウィザードによって生成されたWSDLにより、アダプタ・サービスが定義されます。このWSDLでは、サービスによって公開される様々な操作が指定されます。表4-10に、ウィザードでの選択内容に基づいて生成される操作を指定します。
表4-10 アダプタ構成ウィザードによって生成されるWSDL操作
アダプタ構成ウィザードの選択内容 | 生成されるWSDL操作 |
---|---|
挿入/更新 |
|
削除 |
|
選択 |
|
表の新規レコードまたは更新されたレコードをポーリング |
|
前述の操作の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アクティブ化/相互作用の仕様 |
---|---|
|
|
|
|
|
|
次のコード・サンプルで、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パラメータ
パラメータ | 説明 | 更新メカニズム |
---|---|---|
|
書込み対象のルート・データベース表への間接参照 |
ウィザードにより自動的に更新されます。手動で変更しないでください。 |
|
操作のDML型( |
ウィザードにより自動的に更新されます。手動で変更しないでください。 |
|
リレーショナルからXMLへのマッピングを含むファイルへの参照( |
ウィザードにより自動的に更新されます。手動で変更しないでください。 |
次のコード例は、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パラメータ
パラメータ | 説明 | 更新メカニズム |
---|---|---|
|
問合せ対象のルート・データベース表への間接参照 |
ウィザードにより自動的に更新されます。手動で変更しないでください。 |
|
リレーショナルからXMLへのマッピングのファイル内の |
ウィザードにより自動的に更新されます。手動で変更しないでください。 |
|
この問合せが |
ウィザードにより自動的に更新されます。手動で変更しないでください。このパラメータは |
|
リレーショナルからXMLへのマッピングを含むファイルへの参照( |
ウィザードにより自動的に更新されます。手動で変更しないでください。 |
次のコード例で、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パラメータ
パラメータ | 説明 | 更新メカニズム |
---|---|---|
|
問合せ対象のルート・データベース表への間接参照 |
ウィザードにより自動的に更新されます。手動で変更しないでください。 |
|
リレーショナルからXMLへのマッピングのファイル内の |
ウィザードにより自動的に更新されます。手動で変更しないでください。 |
|
使用するポーリング計画を識別 |
ウィザードにより自動的に更新されます。手動で変更しないでください。 |
|
新規イベントでルート・データベース表をポーリングする頻度を指定(秒単位) |
ウィザードにより自動的に更新されます。手動で変更しないでください。 |
|
BPELエンジンに一度に渡すデータベース・レコードの最大数を指定 |
生成されたWSDLで手動で変更します。 |
|
1つのデータベース・トランザクションの一部として処理する行の最大数を指定 |
生成されたWSDLで手動で変更します。 |
|
リレーショナルから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パラメータ
パラメータ | 説明 | 更新メカニズム |
---|---|---|
|
行を読取りとマークする際に使用するデータベース列を指定。 |
ウィザードにより自動的に更新されます。手動で変更しないでください。 |
|
データベース列が行を読取りとマークするよう設定される値を指定。 |
ウィザードにより自動的に更新されます。手動で変更しないでください。 |
|
データベース列が行を予約済とマークするよう設定される値を指定。このパラメータはオプションです。複数のアダプタ・インスタンスで同じデータベース・アダプタ・サービスを提供している際に使用できます。 |
ウィザードにより自動的に更新されます。手動で変更しないでください。 |
|
データベース列が行を未読取りとマークするよう設定される値を指定。このパラメータはオプションです。データベース・アダプタで処理する必要のある特定の行を確認する際に使用します。 |
ウィザードにより自動的に更新されます。手動で変更しないでください。 |
次のコード例で、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パラメータ
パラメータ | 説明 | 更新メカニズム |
---|---|---|
|
一定量で増加するデータベース列を指定。 |
ウィザードにより自動的に更新されます。手動で変更しないでください。 |
|
一定量で増加するデータベース列の型を指定。このパラメータはオプションです。型が |
ウィザードにより自動的に更新されます。手動で変更しないでください。 |
|
このポーリング問合せのルート・データベース表を指定。 |
ウィザードにより自動的に更新されます。手動で変更しないでください。 |
|
ヘルパー表として機能しているデータベース表の名前。 |
ウィザードにより自動的に更新されます。手動で変更しないでください。 |
|
ルート・データベース表の名前の保存に使用されているヘルパー表のデータベース列を指定。 |
ウィザードにより自動的に更新されます。手動で変更しないでください。 |
|
ルート・データベース表の名前の最終処理行の順序番号の保存に使用されているヘルパー表のデータベース列を指定。 |
ウィザードにより自動的に更新されます。手動で変更しないでください。 |
WSDLのservice
セクションの詳細は、「デプロイ」を参照してください。
ウィザードにより、データベース・スキーマからオブジェクトの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ファイルを手動で変更してデータベース・アダプタを構成しないでください。 |
データベース・アダプタ・サービスの定義およびBPELプロセスの設計が完了したら、プロセスをコンパイルしてOracle BPEL Serverにデプロイします。JDeveloper BPEL Designerの「アプリケーション・ナビゲータ」で、BPELプロジェクトを右クリックして「デプロイ」を選択します。デプロイの詳細は、『Oracle BPEL Process Manager開発者ガイド』の第19章「BPELプロセスのデプロイおよびドメイン管理」を参照してください。
図4-71に、以降の各項で説明するように、WSDLファイル、oc4j-ra.xml
ファイルまたはdata-sources.xml
ファイルの3つの可能性のあるソースから、データベース・アダプタがどのようにして接続情報を取得するかを示します。
データベース・アダプタを使用してプロセスをデプロイする場合は、個別のデータベース・アダプタ・インスタンスがデプロイ済でアプリケーション・サーバー上で使用可能かどうかに応じて、デプロイの性質が異なります。 本番のデプロイの詳細は、「本番のデプロイ」を参照してください。
注意: デフォルトでのデプロイの場合は、例4-1に示すように、データベース・アダプタ・ウィザードを実行する際に、データベースから表をインポートするための接続情報が必要です。 便利な機能として、wsdl ファイルが書き込まれる際に、設計時に使用した接続情報が含まれます。 このように、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.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を含む) |
|
Oracle9+(オプション)
|
|
Oracle8 |
|
Oracle7 |
|
DB2 |
oracle.toplink.platform.database.DB2Platform |
AS400上のDB2 |
oracle.tip.adapter.db.toplinkext.DB2AS400Platform |
Informix |
|
Sybase |
|
SQLServer |
|
その他のデータベース |
|
この項では、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は起動しません。 起動するには、次の手順を実行します。
「スタート」→「ファイル名を指定して実行」をクリックします。
cmd
と入力して「OK」をクリックし、コマンド・プロンプトを起動します。
次のコマンドを入力してインストール・ディレクトリに移動します。
cd %SOAHOME%\opmn\bin
%SOAHOME%
を実際のパスで置き換えてください。次に例を示します。
cd c:\oracle\product\soabeta\opmn\bin
次のコマンドを入力します。
opmnctl startall
次のコマンドを入力して、サービスが正常に開始されたことを確認します。
opmnctl status
注意: すべてのサービスを停止するには、次のように入力します。opmnctl stopall |
次のURLを入力してOracle Enterprise Managerにログインします。
デフォルトのポートは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アダプタを作成します。
ページ上部で「OC4J: ホーム」ブレッドクラム・リンクを選択します。
「アプリケーション」リンクを選択します。
アプリケーション・ツリーで「デフォルト」リンクを選択します。
「モジュール」の下で「AppsAdapter」リンクを選択します。
「コネクション・ファクトリ」リンクを選択します。
「コネクション・ファクトリ」で「作成」をクリックします。
「共有接続プール」セクションの「作成」ボタンではなく、画面上部の「作成」ボタンを使用する必要があることに注意してください。
デフォルトをすべて受け入れて「続行」をクリックします。
「JNDIロケーション」にeis/Apps/appsSample
と入力します。
「構成プロパティ」の下で、「xADataSourceName」にjdbc/appsSampleDataSource
と入力します。
他のすべてのフィールドはデフォルト・エントリのままにします。
「終了」をクリックします。
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 |
|
データベース・アダプタは、多くのパフォーマンス最適化で事前構成されています。ただし、次の項で説明するように、変更を加えてデータベースへのラウンドトリップの回数を減らせます。
パフォーマンス・チューニングは、次に示すチュートリアルで説明されています。
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
次のパフォーマンス・ヒット・リストは、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に設定する必要もあります。
アダプタ構成ウィザードを使用して「挿入/更新」を選択した場合、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を監視します。
キャッシュはTopLinkの重要なパフォーマンス機能です。ただし、失効データの問題は管理が難しい場合があります。デフォルトでは、データベース・アダプタはWeakIdentityMap
を使用します。これは、キャッシュが循環参照の解決にのみ使用され、エントリはJava仮想マシンによって即座に再利用されることを意味します。循環がない場合は、NoIdentityMap
に切り替えられます(XMLには循環がないことが理想です)。TopLinkのデフォルトはSoftCacheWeakIdentityMap
です。これにより、データベースで最も頻繁に使用される行が、キャッシュに存在する可能性が高くなります。
キャッシュに関するより詳細な記事は、次のサイトを参照してください。
http://www.oracle.com/technology/tech/java/newsletter/november04.html
merge
のパフォーマンスを最適化する方法の1つは、データベースをチェックする存在チェックを行わないことです。行が新規の場合には、行全体ではなく主キーのみが返されるため、存在チェックの問題点もやや改善されます。ただし、merge
の性質上、存在チェックが終了すると、いずれにせよ行全体が読み込まれて変更箇所が算出されます。そのため、merge
操作中は、更新するすべての行でデータベースへのラウンドトリップが1つ追加されます。
AがマスターでBがプライベートに所有される子である場合、ルート・ディスクリプタ/表および任意の子表ではキャッシュのチェックを使用することをお薦めします。Aが存在しない場合、Bも存在しません。また、Aが存在する場合、Aの読取りの一部としてBもすべてロードされるため、キャッシュのチェックを使用できます。
このパラメータでは、BPELエンジンに一度に渡すXMLレコードの最大数を指定します。たとえば、maxRaiseSize = 10
と設定すると、一度に10のデータベース・レコードが渡されます。読取り(インバウンド)では、maxRaiseSize = 0
(バインドなし)と設定できます。これは、1000行読み取ると、要素が1000のXMLが1つ作成されることを意味し、そのXMLは単一のOracle BPEL Process Managerインスタンスを介して渡されます。アウトバウンド側のmerge
では、1000すべてが1つのグループに取り込まれ、バッチ書込みで一度に書き込まれます。
大きなペイロードの公開には、maxRaiseSize
パラメータを使用します。
ポーリング計画の選択も重要です。各行を個別に削除する必要があるため、削除ポーリング計画は使用しません。順序付けポーリング計画は、ヘルパー表への更新が1つある1000行を破損する可能性があります。
1対多および1対1リレーションシップのバッチ読取りは、デフォルトでオンになっています。1対1リレーションシップには、パフォーマンスが多少向上する結合読取りも使用できます。
アダプタのローカル接続プールまたはアプリケーション・サーバーのデータソースを使用している場合は、接続プールを構成できます。データベース接続の作成は負荷の高い操作です。負荷の高い状態でも、上限を超えるのはminConnections
のみが理想的です。一度にそれ以上の接続を常時使用している場合には、接続の設定と解除に時間がかかる可能性があります。データベース・アダプタにも読取り接続プールがあります。読取りでは1つの接続を同時に使用するユーザー数には制限がないため、読取り接続はより負荷が低く、ほとんどのJDBCドライバでサポートされている機能です。
データベース・アダプタは、データベース上の未処理の行数を計算するよう設計されています。デフォルトでは、1つまたは10,000のデータベース行を、データベースへの3回のラウンドトリップで読み取って処理できます。最も負荷の高い操作は定数に制限されています。また、データベース・アダプタを分散環境用に構成できます。
ロード・バランシング: MaxTransactionSizeおよびペシミスティック・ロック
図4-72に示すように、最初のポーリング問合せでロックを取得することで、データベース・アダプタが分散環境で安全に機能することを可能にする単純なオプションを設定できます。SQL用語で言い換えると、最初のSELECT
をSELECT...FOR UPDATE
に変更します。
すべてのポーリング計画の動作は次のとおりです。
あるインスタンスが手順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当たりのスループットに近い値に設定するのが最良です。これにより、ロード・バランシングは必要な場合にのみ機能します。
detectOmissions
機能detectOmission
機能の特長は、次のとおりです。
使用可能なリリース
リリース10.1.3以上
構成可能
◎
デフォルト値
設計時: true
(明示的にfalse
に設定しない場合)
使用例
ユーザーは、マージ、更新または挿入対象とする不完全または部分的なxmlを渡して、xmlで未指定の各列がデータベースでNULLに設定されていることを確認できます。
これにより、DBAdapter
のmerge、insertまたはupdateでは、xml文書内のnull
値と欠落値(省略)を区別できます。 xml内のどの情報が有効で、どの情報が無効であるかは、事例ごとに判別されます。 このようにして、xmlは完全な表現ではなくデータベース行の部分表現とみなされます。 次の表に、NULL値と省略可能な値の例を示します。
要素タイプ | 省略 | NULL |
---|---|---|
列 | <director></director>
|
<director xsi:nil="true" /> |
1-1 | <!-- dept> … </dept --> |
<dept xsi:nil="true" /> |
1-M | <!-- 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
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
が優先されます。
次の項では、サード・パーティのデータベースへの接続方法を説明します。BPELプロセスはデータベース・プラットフォームに依存しないため、設計時と実行時に別々のベンダーのデータベースを使用できます。
注意: Oracle Liteデータベース接続を作成するには、サード・パーティJDBCドライバの手順に従います(Oracle Liteデータベースの既存のウィザードおよびライブラリには追加の構成が必要なため)。 表4-19に、Oracle Liteデータベースに接続するための情報を示します。 |
詳細は、「サード・パーティのデータベース表をインポートする際の問題」を参照してください。
一般的に、次の手順は、サード・パーティJDBCドライバを使用してデータベース接続を作成する際に適用します。特定のサード・パーティのデータベースの場合は、次のトピックを参照してください。
サード・パーティJDBCドライバを使用している場合にデータベース接続を作成するには、次のようにします。
「表示」から「接続ナビゲータ」を選択します。
「データベース」を右クリックして「データベース接続の作成」を選択します。
「ようこそ」ウィンドウの「次へ」をクリックします。
接続名を入力します。
「接続タイプ」から「サード・パーティJDBCドライバ」を選択します。
ユーザー名、パスワードおよびロール情報を入力します。
「ドライバ・クラス」で「新規」をクリックします。
「ドライバ・クラス」にドライバ名(some
.jdbc.
Driver
など)を入力します。
「ライブラリ」で「新規」をクリックします。
「編集」をクリックして、ドライバの各JARファイルを「クラスパス」に追加します。
「OK」を2回クリックして「ライブラリの作成」ウィンドウを終了します。
「OK」をクリックして「JDBCドライバの登録」ウィンドウを終了します。
「URL」に接続文字列名を入力して、「次へ」をクリックします。
一般的に使用されるURLは、表4-19を参照してください。また、デプロイメント・ディスクリプタ・ファイル(oc4j-ra.xml
)にサンプルのエントリが表示されます。
「接続のテスト」をクリックします。
正常に接続したら、「終了」をクリックします。
Microsoft SQL Serverデータベースを使用している場合は、「設計時: コマンドライン・ユーティリティの使用方法」のデータベース接続の手順に従い、次の情報を使用します。
URL: jdbc:microsoft:sqlserver://localhost\
NAME:1433;SelectMethod=cursor;databasename=???
ドライバ・クラス: com.microsoft.jdbc.sqlserver.SQLServerDriver
ドライバJar: .\SQLServer2000\msbase.jar
、msutil.jar
、mssqlserver.jar
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ドライバも試用できます。
IBM DB2データベースを使用している場合は、「設計時: コマンドライン・ユーティリティの使用方法」のデータベース接続の手順に従い、次の情報を使用します。
Sybaseデータベースを使用している場合は、「設計時: コマンドライン・ユーティリティの使用方法」のデータベース接続の手順に従い、次の情報を使用します。
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
です。
MySQL 4データベースを使用している場合は、「設計時: コマンドライン・ユーティリティの使用方法」のデータベース接続の手順に従い、次の情報を使用します。
URL: jdbc:mysql://
hostname
:3306
/dbname
ドライバ・クラス: com.mysql.jdbc.Driver
ドライバJar: mysql-connector-java-3.1.10-bin.jar
表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
ここで、 例: 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 |
|
実行時、ドライバ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
この項では、データベース・アダプタで、Oracleデータベースのみに対するストアド・プロシージャおよびファンクションの使用がどのようにサポートされているかを説明します。Oracle以外のデータベースに対するストアド・プロシージャおよびファンクションは、現在はサポートされていません。
この項には、次の項目が含まれます。
「アダプタ構成ウィザード - ストアド・プロシージャ」は、アダプタ・サービスWSDLおよび必要なXSDの生成に使用されます。アダプタ・サービスWSDLは、基礎となるストアド・プロシージャまたはファンクションをWSIF JCAバインディングのあるWebサービスとしてカプセル化します。XSDには、すべてのパラメータおよびそのタイプを含む、プロシージャまたはファンクションが記述されています。このXSDには、実行時にデータベース・アダプタに発行されるインスタンスXMLの作成に使用される定義が指定されています。
この項には、次の項目が含まれます。
この項では、PL/SQLパッケージに定義されていないAPIを持つウィザードの使用方法を説明します。 「アダプタ構成ウィザード - ストアド・プロシージャ」を使用し、プロシージャまたはファンクションを選択してXSDを生成します。 ウィザードの起動方法の詳細は、「Oracle BPEL Process Managerでのデータベース・アダプタの使用例」を参照してください。
ウィザードでは、図4-73に示すように「データベース・アダプタ」を選択します。
サービス名(ProcedureProc
など)およびサービスのオプションの説明を入力後、図4-74に示すように、接続をサービスと関連付けます。リストから既存の接続を選択するか、新しい接続を作成できます。
図4-75に示すように、「操作タイプ」に「ストアド・プロシージャまたはファンクションの呼出し」を選択します。
図4-75 「アダプタ構成ウィザード」におけるストアド・プロシージャまたはファンクションの呼出し
次に、スキーマと、プロシージャまたはファンクションを選択します。リストからスキーマを選択するか、「<デフォルト・スキーマ>」を選択します。この場合、接続に関連付けられているスキーマが使用されます。プロシージャ名がわかっている場合は、「プロシージャ」フィールドに入力します。プロシージャがパッケージ内に定義されている場合は、EMPLOYEE.GET_NAME
のようにパッケージ名を含める必要があります。
スキーマおよびプロシージャ名がわからない場合は、「参照」をクリックして、図4-76に示す「ストアド・プロシージャ」ウィンドウにアクセスします。
リストからスキーマを選択するか、「<デフォルト・スキーマ>」を選択します。使用可能なプロシージャが左側のウィンドウに表示されます。APIの長いリストから特定のAPIを検索するには、「検索」フィールドに検索基準を入力します。たとえば、XX
で始まるすべてのAPIを検索するには、XX%
と入力し「検索」ボタンをクリックします。「すべて表示」ボタンをクリックすると、使用可能なすべてのAPIが表示されます。
図4-77に、PROCプロシージャを選択して、「引数」タブをクリックする方法を示します。「引数」タブには、プロシージャのパラメータが表示されます。表示されるパラメータは、名前、型、モード(IN
、IN/OUT
またはOUT
)およびプロシージャの定義におけるパラメータの数値位置です。
図4-78に、プロシージャを実装するコードが「ソース」タブでどのように表示されるかを示します。プロシージャ名に一致するテキストが強調表示されています。
プロシージャまたはファンクションを選択して「OK」をクリックすると、図4-79に示すように、APIの情報が表示されます。「戻る」または「参照」を使用してリビジョンを作成するか、「次へ」→「終了」をクリックして終了します。
アダプタ構成ウィザードの使用が終了すると、servicename
.wsdl
(ProcedureProc.wsdl
など)および生成されたXSDの2つのファイルが既存のプロジェクトに追加されます。生成されたXSDファイルの名前は、schema_package_procedurename
.xsd
です。この場合、生成されるXSDファイルの名前はSCOTT_PROC.xsd
です。
パッケージで定義されたAPIの使用は、スタンドアロンAPIの使用と似ています。 唯一の違いは、図4-80に示すように、パッケージ名を開いて、パッケージに定義されているすべてのAPIのリストを参照できることです。
同じ名前でパラメータが異なるAPIは、オーバーロードされたAPIと呼ばれます。 図4-80に示すように、PACKAGEというパッケージには、OVERLOADというオーバーロードされたプロシージャが2つあります。
図4-81に示すように、「ソース」タブを参照する際にはパッケージのどのAPIが選択されているかにかかわらず、PL/SQLパッケージ全体のコードが表示されます。プロシージャ名に一致するテキストが強調表示されています。
プロシージャまたはファンクションを選択して「OK」をクリックすると、図4-82に示すように、APIの情報が表示されます。スキーマ、プロシージャ名およびパラメータのリストが表示されます。プロシージャ名がパッケージ名でどのように修飾されているかに注意してください(PACKAGE.OVERLOAD)。「戻る」または「参照」を使用してリビジョンを作成するか、「次へ」→「終了」をクリックして終了します。
アダプタ構成ウィザードの使用が終了すると、Overload.wsdl
およびSCOTT_PACKAGE_OVERLOAD_2.xsd
の2つのファイルが既存のプロジェクトに追加されます。XSDファイル名ではプロシージャ名の後に_2
が追加され、オーバーロードされたAPIと区別されています。
コマンドライン・ユーティリティの起動には、プロパティ・ファイルと、必要なサービスWSDLの作成に使用されるテンプレートWSDLのファイル名を使用します。 この項には、次の項目が含まれます。
追加データベースは、それぞれコマンドライン・ユーティリティで提供される一部の共通機能を共有します。 すべてのサポート対象データベースで共有されるプロパティもいくつかあります。 サポート対象データベースで共有されるプロパティのリストを次に示します。
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>
はプロパティ・ファイル名です。 ユーティリティでは、データベース固有のプロパティなど、すべての必須プロパティが存在することも確認されます。
コマンドライン・ユーティリティでは、3つのファイル(選択したAPIのシグネチャを表すXSD、アダプタ・サービスWSDL、サービスWSDLでインポートされるプロジェクトWSDL)が生成されます。 生成されるWSDLの名前は、ServiceName
プロパティの値から導出されます。 XSDの名前は、ProcedureName
プロパティとデータベース固有の他のプロパティ値から導出されます。 たとえば、Oracleデータベースのスキーマ名とパッケージ名などです。
生成されるサービスWSDLの内容は、WSDLテンプレートと必須プロパティの値を使用して導出されます。 XSDの内容は、修飾プロシージャ名および使用するデータベース固有のタイプ・マッピング表から導出されます。 ストアド・プロシージャのパラメータを表す要素の属性の数とタイプは、アダプタ・ウィザードを使用して生成されるものと同じです。
コマンドライン・ユーティリティを使用すると、IBM DB2 v8.2、SQL Server 2000およびSQL Server 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スキーマ型 |
---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
前述の表に示したデータ型の他に、ストアド・プロシージャについては別名データ型もサポートされています。 別名データ型は、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では、構造化されたデータ型(ユーザー定義)が導入されています。ただし、コマンドライン・ユーティリティではサポートされていません。 したがって、構造化されたデータ型をストアド・プロシージャのパラメータの型として使用することはできません。
IBM DB2では、追加プロパティを使用してストアド・プロシージャをさらに修飾します。 サポートされるのがSQLストアド・プロシージャのみであることに注意してください。 外部プロシージャとユーザー定義ファンクションはサポートされません。
IBM DB2では、SchemaName
プロパティは必須です。 SchemaName
は、プロシージャが属しているスキーマの名前です。 コマンドライン・ユーティリティでは、プロシージャの存在を確認できるように、ストアド・プロシージャの修飾に使用されます。 表4-21に、DB2データベースで使用するストアド・プロシージャについてのみサポートされるデータ型を示します。
表4-21 IBM DB2データベースでストアド・プロシージャについてサポートされているデータ型
SQLデータ型 | XMLスキーマ型 |
---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
他のデータ型の名前も暗黙的にサポートされていることに注意してください。 たとえば、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では、ユーザー定義ファンクションもサポートしています。 ただし、アダプタではこれらがサポートされません。
「アダプタ構成ウィザード - ストアド・プロシージャ」では、ストアド・プロシージャまたはファンクションのシグネチャを説明するWSDLおよび有効なXSDを作成できます。次の項では、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
パラメータの値が保持されます。
多くのプリミティブ・データ型には、詳細に定義されたマッピングが用意されているため、設計時および実行時のコンポーネントのどちらでもサポートされています。また、VARRAY
、ネストされた表およびOBJECT
などのユーザー定義タイプを使用できます。 表4-22に、ストアド・プロシージャのデータベース・アダプタによってサポートされているプリミティブ・データ型をリスト表示します。
表4-22 ストアド・プロシージャのデータベース・アダプタによってサポートされているプリミティブ・データ型
SQLまたはPL/SQLタイプ | XMLスキーマ型 |
---|---|
|
double |
|
|
|
|
|
|
|
|
|
|
|
|
表4-23に、生成されたXSDで使用される属性をリスト表示します。接頭辞がdb:
の属性は、データベース・アダプタ固有です。
表4-23 生成されたXSD属性
属性 | 例 | 意味 |
---|---|---|
|
|
要素の名前 |
|
|
XMLスキーマ型 |
|
|
SQLまたはPL/SQLタイプ |
|
|
パラメータの位置 |
|
|
デフォルト句がある場合 |
|
|
最小発生数 |
|
|
最大発生数 |
|
|
NULL値の許可 |
db
ネームスペースは、実行中に使用される属性と標準のXMLスキーマ属性の区別に使用されます。db:type
属性は、データベース・タイプの特定に使用されるため、実行時に適切なJDBCタイプ・マッピングを取得できます。db:index
属性は、設計時および実行時のコンポーネントの両方で最適化として使用され、パラメータが適切な順序に配置されていることを確認できます。パラメータ索引は、プロシージャでは1
から、ファンクションでは0
から開始されます。ファンクションの戻り値は、name
がファンクションの名前で、db:index
が0
のOutputParameter
要素として表現されます。db:default
属性は、パラメータにデフォルト句があるかどうかを特定するために使用されます。
minOccurs
値は、XMLからのIN
パラメータの削除を可能にするために0
に設定されます。これは、パラメータにパラメータの値を定義するデフォルト句(X IN INTEGER DEFAULT 0
など)がある場合に便利です。実行時にXMLのパラメータに要素が指定されていない場合、そのパラメータはストアド・プロシージャの起動から除外されるため、デフォルト値の使用が可能になります。各パラメータを、ストアド・プロシージャまたはファンクションの起動に使用できるのは最大で一度です。そのため、デフォルト値が常に1
のmaxOccurs
は、パラメータを表す要素から常に除外されます。
nillable
属性は、インスタンスXMLの対応する要素にNULL値(<X/>
または<X></X>
など)を許可するために、常にtrue
に設定されています。ただし、NULL値のあるこのような要素では、スキーマ検証を成功させるために、(<X xsi:nil="true"/>
のように)明示的に宣言する必要がある場合があります。nillable
属性に使用されるネームスペースxsi
は、インスタンスXMLに(xmlns:xsi="http://www.w3.org/2001/XMLSchema
-instance"のように)明示的に宣言する必要があります。
ウィザードでも、コレクション(VARRAY
およびネストされた表)およびOBJECT
などのユーザー定義タイプに有効な定義を生成できます。XSDではcomplexType
定義として作成されます。
VARRAY
の場合、complexType
定義によりその順序内にname
_ITEM
という単一の要素が定義されます。ここでname
はVARRAY要素の名前です。XMLのすべての配列要素でそのように名前が付けられます。次のようなVARRAY
タイプ定義があるとします。
SQL> CREATE TYPE FOO AS VARRAY (5) OF VARCHAR2 (10);
タイプがFOO
のVARRAY
要素X
の場合、次のようなcomplexType
が生成されます。
<complexType name="FOO"> <sequence> <element name="X_ITEM" db:type="VARCHAR2" minOccurs="0" maxOccurs="5" nillable="true"/> <simpleType> <restriction base="string"> <maxLength value="10"/> </restriction> </simpleType> </sequence> </complexType>
空のコレクションを許可するため、minOccurs
値は0
です。maxOccurs
値は、コレクションで保持できる最大のアイテム数に設定されます。db:index
属性が使用されていないことに注意してください。nillable
をtrue
に設定すると、VARRAY
の個々のアイテムでNULL値を使用できます。
VARRAY
の要素FOO
で指定されている制限の使用に注意してください。これは、VARRAY
(またはネストされた表)の宣言で長さがわかる、CHAR
およびVARCHAR2
などのタイプに使用されます。要素のタイプや最大長が指定されます。指定された長さを超える要素値は、スキーマ検証中にインスタンスXMLが停止する原因になります。
タイプFOO
として宣言されたパラメータの属性値は、生成されたXSDでは次のようになります。
<element name="X" type="db:FOO" db:type="Array" db:index="1" minOccurs="0" nillable="true"/>
type
およびdb:type
の値は、パラメータがXSDでFOO
というcomplexType
によって定義済の配列として表現されていることを示します。db:index
の値は、ストアド・プロシージャにおけるそのパラメータの位置です。
ネストされた表は、VARRAY
とほぼ同じように処理されます。次にネストされた表のタイプ定義を示します。
SQL> CREATE TYPE FOO AS TABLE OF VARCHAR2 (10);
これは、その順序に単一の要素を含む、name
_ITEM
というcomplexType
としても生成されます。ネストされた表が任意のサイズであるためバインドされていないmaxOccurs
値を除き、その要素にはVARRAY
の例と同じ属性があります。
<complexType name="FOO"> <sequence> <element name="X_ITEM" … maxOccurs="unbounded" nillable="true"> … </element> </sequence> </complexType>
VARRAY
のX_ITEM
要素には同じ制限が生成されます。このタイプとして宣言されたX
パラメータの属性は、VARRAY
の例と同じです。
PL/SQLパッケージ仕様の内側で定義されたcollections
(Varray
およびネストした表)はサポートされないことに注意してください。次に例を示します。
SQL> create package pkg as > type vary is varray(10) of number; > type ntbl is table of varchar2(100; > procedure test(v in vary, n in ntbl); > end; > /
ユーザーがデータベース・アダプタ・ウィザードでストアド・プロシージャについてtestプロシージャを選択すると、そのタイプがサポートされていないことを示すエラーが発生します。 ただし、パッケージ外部のルート・レベルでvary
およびntbl
タイプ定義が定義されている場合は、testプロシージャを選択しても問題なく動作します。 次の例に、コレクション・タイプ(Varray
およびネストした表)についてサポートされている使用方法を示します。
SQL> create type vary as varray(10) of number; SQL> create type ntbl as table of varchar2(10); SQL> create package pkg as > procedure test(v in vary, n in ntbl); > end; /
OBJECT
定義もcomplexType
として生成されます。その順序には、OBJECT
の各属性に1つの要素が保持されています。
次にOBJECT
を示します。
SQL> CREATE TYPE FOO AS OBJECT (X VARCHAR2 (10), Y NUMBER);
これは、順序要素が2つあるFOO
というcomplexType
として表現されています。
<complexType name="FOO"> <sequence> <element name="X" db:type="VARCHAR2" minOccurs="0" nillable="true"/> <simpleType> <restriction base="string"> <maxLength value="10"/> </restriction> </simpleType> <element name="Y" type="decimal" db:type="NUMBER" minOccurs="0" nillable="true"/> </sequence> </complexType>
XMLからの要素の削除を許可するため、minOccurs
値は0
です。これにより、OBJECT
の対応する属性の値が実行時にNULLに設定されます。XMLに空の要素を許可するためnillable値はtrue
であり、要素の値がNULLであることを示すためにxsi:nil
属性で注釈が付けられています。ここでも、db:index
属性は使用されていません。
VARCHAR2
属性の制限の使用に注意してください。OBJECT
の属性の宣言から長さがわかります。
ユーザー定義タイプは、必要に応じて複雑に定義できます。OBJECT
には、前述の任意のユーザー定義タイプとして定義されているタイプの属性を含めることができます。これは、OBJECT
の属性のタイプが別のOBJECT
、VARRAY
またはネストされた表などになることを意味します。VARRAY
またはネストされた表のベース・タイプも、OBJECT
になる可能性があります。コレクションのベース・タイプが別のコレクションになることを許可することで、多次元のコレクションがサポートされます。
ウィザードでは、OBJECT
タイプの継承を使用してタイプが定義されているパラメータの有効なXSDを生成できます。次のようなタイプの階層があるとします。
SQL> CREATE TYPE A AS OBJECT (A1 NUMBER, A2 VARCHAR2 (10)) NOT FINAL; SQL> CREATE TYPE B UNDER A (B1 VARCHAR2 (10));
また、プロシージャにはタイプがB
のパラメータX
が含まれるとします。
SQL> CREATE PROCEDURE P (X IN B) AS BEGIN … END;
ウィザードでは、パラメータX
にInputParameters
要素が次のように生成されます。
<element name="X" type="db:B" db:index="1" db:type="Struct" minOccurs="0" nillable="true"/>
ここで、XSDのOBJECT
タイプB
の定義は、次に示すcomplexType
として生成されます。
<complexType name="B"> <sequence> <element name="A1" type="decimal" db:type="NUMBER" minOccurs="0" nillable="true"/> <element name="A2" db:type="VARCHAR2" minOccurs="0" nillable="true"> ... </element> <element name="B1" db:type="VARCHAR2" minOccurs="0" nillable="true"> ... </element> </sequence> </complexType>
属性A2
およびB1
の最大長の制限が適切に追加されています。OBJECT
タイプの階層が、階層全体のすべての属性に対応する要素の単一の順序にフラット化されていることに注意してください。
ウィザードでは、OBJECT
タイプへの参照(オブジェクト参照など)であるパラメータや、定義にオブジェクト参照が含まれるユーザー定義タイプのパラメータの有効なXSDも生成できます。次に例を示します。
SQL> CREATE TYPE FOO AS OBJECT (…); SQL> CREATE TYPE BAR AS OBJECT (F REF FOO, …); SQL> CREATE PROCEDURE PROC (X OUT BAR, Y OUT REF FOO) AS BEGIN … END;
ウィザードでは、FOO
およびBAR
のcomplexType
定義が前述したように生成されます。ただし、BAR
では、属性の要素F
は次のように生成されます。
<element name="F" type="db:FOO" db:type="Ref" minOccurs="0" nillable="true"/>
ここで、type
およびdb:type
属性値は、F
がOBJECT
タイプFOO
への参照であることを示します。
プロシージャPROC
では、XSDのOutputParameters
ルート要素に次の要素が生成されます。
<element name="X" type="db:BAR" db:index="1" db:type="Struct" minOccurs="0" nillable="true"/> <element name="Y" type="db:FOO" db:index="2" db:type="Ref" minOccurs="0" nillable="true"/>
Y
では、db:type
属性の値がRef
になっています。type
属性とともに、要素定義ではY
がFOO
への参照であることが示されています。
オブジェクト参照の使用には、パラメータ・モードがOUT
のみ限られる制限があることに注意してください。直接的なREF
のAPI、またはパラメータ・タイプがユーザー定義の場合はそのタイプの定義にREF
が含まれているAPIに、IN
またはIN/OUT
パラメータを渡すことはできません。
アクセスに必要な権限が付与されている場合には、別のスキーマに定義されているタイプを参照できます。たとえば、SCHEMA1
でタイプOBJ
が宣言されたとします。
SQL> CREATE TYPE OBJ AS OBJECT (…);
SCHEMA2
で宣言されているストアド・プロシージャのパラメータ・タイプを、SCHEMA1
のタイプOBJ
にすることも可能です。
CREATE PROCEDURE PROC (O IN SCHEMA1.OBJ) AS BEGIN … END;
これは、SCHEMA1
によりSCHEMA2
にタイプOBJ
にアクセスする権限が付与された場合にのみ可能です。
SQL> GRANT EXECUTE ON OBJ TO SCHEMA2;
必要な権限が付与されていない場合には、SCHEMA2
にプロシージャPROC
の作成を試行するとエラーが発生します。
PLS-00201: identifier "SCHEMA1.OBJ" must be declared
権限が付与されていないため、SCHEMA1
のタイプOBJ
はSCHEMA2
には表示されません。そのため、SCHEMA2
はパラメータO
の宣言でOBJ
を参照できません。
この項では、ストアド・プロシージャのサポートに関する重要事項と、ストアド・プロシージャまたはファンクションの起動前に発生する動作に関する重要事項の概要を説明します。
この項には、次の項目が含まれます。
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つの可能性があります。
"BEGIN PROC (); END;" - X = 0
(X
にはデフォルト句がある)
"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"/>
この項では、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
は相互作用が完了すると解放されます。
その他のデータ型の変換は簡単なため、追加情報は必要ありません。
プロシージャ(またはファンクション)を実行すると、任意のIN/OUT
およびOUT
パラメータの値が取得されます。これらは、生成されたXSDのOutputParameters
ルート要素の要素値に対応します。
この項には、次の項目が含まれます。
取得されたデータの変換は簡単です。 ただし、サード・パーティ・データベースでサポートされている類似のデータ型の変換と同様に、CLOB
(および他の文字データ)、RAW
、LONG
RAW
およびBLOB
の変換には特別な注意が必要です。
CLOB
が取得されると、そのCLOB
のコンテンツ全体が生成されたXMLの対応する要素に書き込まれます。標準のDOM APIを使用してXMLが構成されます。これは、CLOB
、CHAR
およびVARCHAR2
などのタイプに関しては、必要な置換えを行うために文字データが必要であると伝達されたため、値は有効で後続の処理でXMLに使用できることを意味します。そのため、たとえば、CLOB
で保存されたXMLドキュメントの<
および>
の置換えが行われ、関連するパラメータの生成されたXML内の要素に使用された値は有効になります。
RAW
およびLONG RAW
型などのRAWデータは、バイト配列として取得されます。BLOB
の場合、まずBLOB
が取得され、そのコンテンツはバイト配列として取得されます。バイト配列は、javax.mail.internet.MimeUtility
エンコードAPIを使用してbase64Binary
形式にエンコードされます。エンコードされた値は、すべて対応する要素のXMLに配置されます。この値をバイト配列にデコードするには、MimeUtility
デコードAPIを使用する必要があります。
その他のデータ型の変換は簡単なため、追加情報は必要ありません。
値がNULLの要素は、生成されたXMLでは空の要素として表示され、xsi:nil
属性で注釈が付けられます。つまり、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の場合にはこのように表示されます。
ファンクションの戻り値は、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>
と表示されます。
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
が常に先頭に表示されます。
この項では、データベース・アダプタで提供されているストアド・プロシージャ機能を使用して、直接にはサポートされていないタイプのシナリオを説明します。 次の項では、これらのデータ型を使用する必要がある場合に取り組む解決策を説明します。
設計時および実行時のいずれのコンポーネントでも、REF CURSOR
タイプは直接サポートされていません。解決策は、OBJECT
タイプのコレクションを使用することです。通常、REF CURSOR
によって返される行数は不明なため、コレクション・タイプとしてネストされた表を使用することをお薦めします。この解決策では、Javaストアド・プロシージャを使用して、ResultSet
を宣言されたコレクション・タイプのインスタンスに変換します。次のディレクトリに、これを説明したサンプルのチュートリアルが用意されています。
Oracle_Home
\bpel\samples\tutorials\122.DBAdapter\ResultSetConverter
この項には、次の項目が含まれます。
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として表示されます。
次のパッケージがあるとします。
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がバインドされます。
ウィザードには、これらのタイプが使用され、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に示すように、元のプロシージャ名は完全修飾され、PKG.PROC
となっています。パラメータ・タイプR
はRECORD
の名前です。タイプT
はTABLE
の名前です。タイプB
はBOOLEAN
です。生成されているラッパー・パッケージの名前は、サービス名bpel_
ServiceName
(bpel_UseJPub
など)から導出されます。これは、生成されたパッケージの名前で、ラッパー・プロシージャが含まれています。チェック・ボックスは、スキーマ・オブジェクトの作成時に、ウィザードで既存のパッケージの上書きを強制する際に使用できます。
図4-84に示すように、「次へ」をクリックすると、ウィザードの「終了」ページが表示されます。
このページのコンテンツでは、ウィザードで検出されたもの、「終了」ボタンがクリックされると実行される処理が説明されます。次に、このページのコンテンツをまとめます。
生成されたWSDLの名前はUseJPub.wsdl
です。
2つのSQLスクリプトが作成され、BPELプロセス・プロジェクトに追加されます。
BPEL_USEJPUB.sql
: スキーマ・オブジェクトが作成されます。
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が起動されると、生成されたラッパー・プロシージャは元のプロシージャのかわりに実行されます。
プロシージャにラッパーの生成が必要な特別なタイプが含まれる場合、パラメータのデフォルト句はラッパーには継承されません。たとえば、次のような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に要素がない場合、プロシージャ・コールから対応するパラメータを除外する必要があることを示すために実行時に使用されます。これらの要素のその他の属性は元のままです。
このチュートリアルでは、JDeveloper BPEL Designerを使用したOracle BPEL Process Managerへのストアド・プロシージャの統合方法を説明します。ストアド・プロシージャおよびファンクションを説明したその他のチュートリアルは、File2StoredProcedure
、JPublisherWrapper
およびResultSetConverter
です。次の場所に移動してください。
Oracle_Home
\bpel\samples\tutorials\122.DBAdapter
この項には、次の項目が含まれます。
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.
次の手順に従って新規BPELプロジェクトを作成します。
Oracle JDeveloperを開きます。
「ファイル」メニューから「新規」を選択します。
「新規ギャラリ」ダイアログ・ボックスが表示されます。
「フィルタ方法」ボックスから「すべてのテクノロジ」を選択します。 使用可能なカテゴリのリストが表示されます。
「General」ノードを開いて「Projects」を選択します。
図4-85のように、「項目」グループから「ESBプロジェクト」を選択します。
「OK」をクリックします。
「BPELプロジェクト作成ウィザード - プロジェクトの設定」ダイアログ・ボックスが表示されます。
名前: プロセス名を入力します。 この例では、Greetingと入力します。
ネームスペース: デフォルト値を保持します。
テンプレート: 「同期BPELプロセス」を選択します。
「次へ」をクリックします。
「BPELプロジェクト作成ウィザード - 入力/出力要素」ダイアログ・ボックスが表示されます。
デフォルト値を受け入れて「終了」をクリックします。
図4-86のように、BPELプロジェクトの作成が完了しました。
この項では、パートナ・リンクの作成方法を説明します。 次の手順に従ってパートナ・リンクを作成します。
「コンポーネント・パレット」から「Services」を選択します。
サービス・リストからBPELプロジェクト・ウィンドウへ「PartnerLink」をドラッグ・アンド・ドロップします。
「パートナ・リンクの作成」ダイアログ・ボックスが表示されます。
「名前」フィールドにHelloと入力し、「WSDL設定」で「アダプタ・サービスの定義」アイコン(3番目のアイコン)をクリックします。
「アダプタ構成ウィザード - ようこそ」画面が表示されます。
「次へ」をクリックします。
「アダプタ・タイプ」ダイアログ・ボックスが表示されます。
図4-87のように、「データベース・アダプタ」を選択して「次へ」をクリックします。
「サービス名」ウィンドウの「サービス名」フィールドにHelloと入力し、「次へ」をクリックします。これはパートナ・リンクのサービス名と同じ名前です。
「サービス接続」ダイアログ・ボックスが表示されます。
「新規」をクリックして新規接続を作成します。
「ようこそ」ダイアログ・ボックスが表示されます。
「次へ」をクリックします。
「タイプ」ダイアログ・ボックスが表示されます。
「タイプ」ダイアログ・ボックスの「接続名」フィールドに名前(myConnectionなど)を入力します。
「接続タイプ」リストからデータベースの接続タイプ(「Oracle (JDBC)」など)を選択して、「次へ」をクリックします。
「認証」ダイアログ・ボックスが表示されます。
「認証」ウィンドウの「ユーザー名」フィールドにscottと入力します。
「パスワード」フィールドにscottのパスワードを入力します(この例ではtiger)。
その他のフィールドはそのままにして、「次へ」をクリックします。
「接続」ダイアログ・ボックスが表示されます。
次の接続情報を入力します。この情報が不明な場合は、データベース管理者に連絡してください。
フィールド | 値の例 |
---|---|
ドライバ | thin |
ホスト名 | localhost |
JDBCポート | 1521 |
SID | ORCL |
「次へ」をクリックします。
「テスト」ダイアログ・ボックスが表示されます。
「テスト」ウィンドウの「接続のテスト」をクリックします。
正常に接続したら、次のメッセージが表示されます。
Success!
「終了」をクリックします。
すべてのフィールドが移入済の状態で、図4-88に示す「サービス接続」ダイアログ・ボックスが表示されます。
「次へ」をクリックします。
「操作タイプ」ダイアログ・ボックスが表示されます。
「操作タイプ」ウィンドウで、「ストアド・プロシージャまたはファンクションの呼出し」を選択して「次へ」をクリックします。
「ストアド・プロシージャの指定」ダイアログ・ボックスが表示されます。
「プロシージャ」フィールドの右にある「参照」をクリックします。
「ストアド・プロシージャ」ダイアログ・ボックスが表示されます。
「スキーマ」リストに「<デフォルト・スキーマ>」が選択されたままにします。これは、ストアド・プロシージャが定義されているscott
スキーマのデフォルトに設定されます。
「ストアド・プロシージャ」のナビゲーション・ツリーでHelloを選択します。
注意: 別の方法として、「検索」フィールドにHelloと入力して「検索」をクリックし、ストアド・プロシージャのナビゲーション・ツリーにこのストアド・プロシージャを表示して選択することもできます。 |
「引数」タブにストアド・プロシージャのパラメータが表示されます。
「ソース」タブをクリックして、Helloストアド・プロシージャのソース・コードを表示します。 これは、「ストアド・プロシージャの作成」でSQL*Plusを使用してストアド・プロシージャを作成した際に入力した構文です。
図4-89に、ストアド・プロシージャHelloのソース・コードを示します。
「OK」をクリックします。
「ストアド・プロシージャの指定」ウィンドウに選択内容が表示されます。 図4-90にその様子を示します。
「次へ」をクリックします。
「終了」画面が表示されます。
「終了」をクリックしてアダプタ構成を完了します。
「パートナ・リンクの作成」ウィンドウが自動的に完了します。
「適用」をクリックします。
「OK」をクリックします。
「ファイル」メイン・メニューから「すべて保存」を選択します。
「アプリケーション・ナビゲータ」の「インテグレーション・コンテンツ」→「Greeting」の下に次のファイルが表示されます。これらのファイルには、アダプタ構成ウィザードで指定したパラメータが含まれます。
Hello.wsdl
新しいストアド・プロシージャのパートナ・リンクに対応
SCOTT_HELLO.xsd
パラメータを含むストアド・プロシージャの定義を指定
invokeアクティビティを作成して、(Helloパートナ・リンクで特定された)サービスに対して起動する操作を指定します。
図に示すように、invokeアクティビティをreceiveInputアクティビティの下へドラッグ・アンド・ドロップします。
invokeアクティビティをダブルクリックして、「Invoke」ダイアログ・ボックスを表示します。
「Invoke」ダイアログ・ボックスで、次のアクションを実行するように指定します。
「名前」フィールドにGreetと入力します。
「パートナ・リンク」フィールドの右側にある「パートナ・リンクの参照」アイコンをクリックします。
「パートナ・リンクの選択」ダイアログ・ボックスが表示されます。
図4-92のように、「Hello」を選択して「OK」をクリックします。
「名前」、「パートナ・リンク」および「操作」の各フィールドが入力済の状態で「Invoke」ダイアログ・ボックスが表示されます。「操作」フィールドには、値Helloが自動的に設定されています。
「入力変数」フィールドの右側にある「入力変数の自動作成」アイコン(最初のアイコン)をクリックします。
「変数の作成」ダイアログ・ボックスが表示されます。Greet_Hello_InputVariableという名前の変数が、「名前」フィールドに自動的に表示されます。この変数により、ストアド・プロシージャのin
パラメータの値が指定されます。タイプはhttp://xmlns.oracle.com/pcbpel/adapter/db/Hello/}args_in_msgです。
「グローバル変数」が選択されていることを確認してください。
「変数の作成」ダイアログ・ボックスで「OK」をクリックします。
Greet_Hello_OutputVariableという名前の変数が、「名前」フィールドに自動的に表示されます。実行後、この変数にはプロシージャのout
パラメータの値が保持されます。タイプはhttp://xmlns.oracle.com/pcbpel/adapter/db/Hello/}args_out_msgです。
「グローバル変数」が選択されていることを確認してください。
「変数の作成」ダイアログ・ボックスで「OK」をクリックします。
図4-93のように「Invoke」ウィンドウの選択内容が表示されます。
「Invoke」ウィンドウで「OK」をクリックします。
「ファイル」メイン・メニューから「すべて保存」を選択します。
プロセスにより、GreetというinvokeアクティビティからHelloパートナ・リンクへのリンクが表示されます。
assignアクティビティを作成し、ストアド・プロシージャのin
パラメータに入力値を割り当てます。
Greetというinvokeアクティビティの上に、「コンポーネント・パレット」セクションからassignアクティビティをドラッグ・アンド・ドロップします。
assignアイコンをダブルクリックして、「Assign」ウィンドウを表示します。
「一般」タブをクリックします。
「名前」フィールドにInputと入力します。
「適用」をクリックします。
「コピー・ルール」タブをクリックします。
「作成」ドロップダウン・リストから「コピー操作」を選択します。
「コピー操作の作成」ダイアログ・ボックスが表示されます。
フィールド | 値 |
---|---|
From | |
|
変数 |
|
「変数」→inputVariable→payload→client:GreetingProcessRequest→client:inputを開いて選択します。 |
To | |
|
変数 |
|
「変数」→Greet_Hello_InputVariable→InputParameters→ns2:InputParameters→NAMEを開いて選択します。 |
「コピー操作の作成」ダイアログ・ボックスが次のように表示されます。
「OK」をクリックして「コピー・ルールの作成」ウィンドウを終了します。
「OK」をクリックして「Assign」ウィンドウを終了します。
「ファイル」メイン・メニューから「すべて保存」を選択します。
assignアクティビティを作成し、ストアド・プロシージャのout
パラメータの値を取得します。
Greetというinvokeアクティビティの下に、「コンポーネント・パレット」セクションからassignアクティビティをドラッグ・アンド・ドロップします。
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プロセスが次のように表示されます。
「ファイル」メイン・メニューから「すべて保存」を選択します。
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に割り当てられています。
プロセス・フローを表示するには、「フロー」タブをクリックします。
プロセス・ダイアグラムが表示されます。
BPELプロセスから渡されるXMLを表示するには任意のアクティビティをクリックします。たとえば、次のXMLを表示するには、Greetというinvokeアクティビティをクリックします。