バルク・データ処理は、参加アプリケーション間の離散レコードのバッチ処理です。Oracle AIAでは、Oracle Fusion Middleware SOA SuiteのコンポーネントであるOracle Data Integrator (ODI)を使用して、バルク・データ統合が実行されます。この章では、AIA ODIアーキテクチャの設計パターンの概要を示し、Xref表ありの大規模トランザクションの処理、ODIプロジェクトの作成、XREFナレッジ・モジュール、ODIの使用、ドメイン値マップの使用、エラー処理の使用、ODIのRef関数の使用の各方法、さらにパッケージおよびデータ・モデルをWebサービスとして公開する方法について説明します。
この章の内容は次のとおりです。
Oracle Data Integratorの使用方法の詳細は、『Oracle Data Integratorでの統合プロジェクトの開発』を参照してください。
Oracle Data Integratorのデータ転送は常にポイントツーポイントであるため、ソース・システムとターゲット・システムは、データのバッチ・ロードを処理できる必要があります。統合プロジェクトでは、ソース側またはターゲット側のいずれかのアプリケーションで処理できる行数に制限がある場合は、Oracle Data Integratorをソリューションとして採用しないでください。
この項では、AIAアーキテクチャでOracle Data Integratorを使用するためのAIA承認済の設計パターンについて説明します。AIAで承認されている設計パターンは、次のとおりです。
図15-1に示したこの設計パターンでは、特定オブジェクトのデータの初期セットが、ソース・データベースからターゲット・データベースにロードされます(たとえば、既存のソース・アプリケーション・データベースから新しいアプリケーション・データベースへの顧客アカウント情報のロードや請求書情報のロード)。プロセスでは、統合要件に応じて、Xrefデータが設定される場合と設定されない場合があります。
特定の統合用に開発されたOracle Data Integratorパッケージは、別の参加アプリケーションにデータをロードするために再使用することはできません。
図15-1 初期データ・ロード
Oracle Data Integratorのデータ・ロードを実行する手順は、次のとおりです。
注意:
次のサンプルのステップでは、図15-1に示すように、ERP Application 1からERP Application 2への初期データ・ロードを実行する方法について説明します。
Oracle Data Integratorの詳細は、『Oracle SOA SuiteでのSOAアプリケーションの開発』を参照してください。
大規模なデータ転送が必要な場合は、アプリケーション間のデータ転送にOracle Data Integratorソリューションを使用することをお薦めします。この方法を使用すると、Oracle Data Integratorパッケージによって、ソース・システムからターゲット・システムにデータが定期的に転送されます。
データのロード方法の詳細は、「Oracle Data Integratorのデータ・ロードの実行方法」を参照してください。
ソース側のインタフェース表に、処理した行を示すためのメカニズムを設定することをお薦めします。
バッチ・ロードが通常のオンライン・トランザクションと共存する必要がある場合は、図15-2に示した方法をお薦めします。
図15-2 断続的な大規模トランザクション
このシナリオでは、2つの異なるフローによって、ソース・アプリケーションからターゲット・アプリケーションにデータが送信され、一方ではAIA Oracle Data Integratorアプローチを使用し、もう一方では標準のAIAアプローチを使用します。データ整合性は、参加アプリケーション側で確保する必要があります。AIA Oracle Data Integratorアーキテクチャ・アプローチを使用してロードするのは、新しいレコードのみにすることをお薦めします。
AIA-Oracle Data Integratorアーキテクチャを使用してソースからターゲットにデータを送信する方法の詳細は、「Oracle Data Integratorのデータ・ロードの実行方法」を参照してください。
作成操作がAIA Oracle Data Integratorアプローチを使用して実行する必要があるのに対して、その他のすべての操作は、AIAを使用して実行する必要があります。
この設計パターンで、Oracle Fusion Middlewareが使用できない場合にデータを送信する代替ルートとして、AIA Oracle Data Integratorアプローチを使用しないでください。かわりに、メッセージは、JMSQなどの適切なメッセージ・キューイング・テクノロジを使用してキューに入れ、AIAで推奨されている保証付きメッセージ・テクノロジを使用して処理する必要があります。
保証付きメッセージの詳細は、「保証付きメッセージ配信」を参照してください。
大規模トランザクション用のXrefデータの格納が有効ではない場合は、図15-3に示すように、Oracle Data Integratorを使用したポイントツーポイント統合を使用することをお薦めします。
図15-3 大規模トランザクション
たとえば、小売ストア・チェーンの本社で、毎日営業終了時に個々の小売ストアからデータを受信するとします。このシナリオでは、個々の各ローカル・ストアとHQの間では、これらのデータ・セットに対するDML操作がないため、Xrefデータを格納する必要はありません。
データのロード方法の詳細は、「Oracle Data Integratorのデータ・ロードの実行方法」を参照してください。
このアーキテクチャにはAIAコンポーネントはありません。ローカルERPアプリケーションによって、そのインタフェース表がロードされ、データをHQインタフェース表に送信するためのOracle Data Integratorパッケージが呼び出されます。データが処理された後で、Oracle Data Integratorによって、ローカルERPアプリケーションのインタフェース表の各行がTransferredまたはProcessedで更新されます。
Oracle Data Integratorを使用するAIAに対するバルク・データ処理戦略は、ポイントツーポイント・ソリューションの作成、Xrefにデータを設定する必要性の考慮、DVMの使用、および処理されたデータが実行時にAIAサービスに参加できることの保証などです。
Oracle Data Integratorで、XREFデータの作成は2ステップのプロセスです。各ステップがインタフェースです。全体的なプロセスは図15-4に示されています。
最初のインタフェースでは、ユーザーのソース表がOracle Data Integratorのソースであり、ユーザーのターゲット表がOracle Data Integratorのターゲットです。
ソース表からターゲット表へのデータの送信時に、ソース行および共通行に対するXREFデータを作成します。このプロセスでは、ターゲットの任意の列に共通識別子を入力する場合は、これもOracle Data Integratorのナレッジ・モジュールで処理されます。
注意:
ターゲット・インタフェース表に共通データ用のプレースホルダが含まれていない場合は、ソース識別子を入力するか、またはアプリケーションでソース行ごとに共通値用のプレースホルダが識別されるようにする必要があります。
最後のステップでは、データがインタフェース表からベース表に転記された後で、前述のインタフェース処理中に送信した、ターゲット識別子と共通(またはソース)識別子間のマッピングが使用可能であるデータ・ストアを、ターゲット・アプリケーションで識別する必要があります。
2番目のインタフェースは、このデータ・ストアがOracle Data Integratorのソースであり、XREF表がターゲットである場合に実行する必要があります。この結果、XREF表に適切なターゲット列が作成されます。
図15-4 XREFナレッジ・モジュールの使用
相互参照は、メディエータ・コンポーネントを介して使用できるOracle Fusion Middlewareの機能で、通常は、サービス指向アーキテクチャ(SOA)の規則に基づいて作成される疎結合の統合で利用されます。統合の様々な参加アプリケーション間のランタイム相関を管理するために使用されます。
ソース表からターゲット表へのデータのロード時に、トリクル・フィード・アーキテクチャで実行する場合と同様に、SOAデータベースに相互参照データを設定する必要があります。SOA Suiteでは相互参照表のデータ入力に標準APIを使用できますが、これらのAPIは、セットベース処理ではなく行単位の処理になる場合があるため、Oracle Data Integratorでは使用できません。
以降の各項では、ソース表のデータをターゲット表にロードすると同時に、相互参照にデータを入力する方法について説明します。
相互参照の詳細は、「DVMおよび相互参照の使用」を参照してください。
Oracle Data Integratorを使用する前に、これらの前提条件を完了してください。
マスター・リポジトリと作業リポジトリを定義します。
すべてのトポロジ・パラメータを定義します。
物理アーキテクチャ(ソース、ターゲットおよびXREF_DATA用)
論理アーキテクチャ
コンテキスト
データ・モデルを定義します。
プロジェクトを作成します。
次のナレッジ・モジュールをプロジェクトにインポートします。
KM_LKM SQL to SQL (メディエータXREF)またはKM_LKM SQL to Oracle (メディエータXREF)
CKM Oracle (提供済)
KM_IKM SQL Control Append (メディエータXREF)
ODIの設定方法の詳細は、『Oracle Data Integratorでの統合プロジェクトの開発』を参照してください。
XREF列名はハードコードできないため、ソース列名とターゲット列名を保持するために2つの変数を定義する必要があります。通常、これらの列名はAIAConfigurationファイルから導出されます。この項では、それをXMLから取得する方法を説明するのではなく、SQLのSELECT文からリフレッシュする方法について説明します。
変数の詳細は、『Oracle Data Integratorでの統合プロジェクトの開発』の、変数の取り扱いに関する項を参照してください。
ソース列名とターゲット列名を定義する手順は、次のとおりです。
変数GetSourceColumnName
を作成します。
この変数は、XREF_DATA
表の列名を判断するために使用されます。図15-5に示すように、「リフレッシュ中」タブには、実装に応じて、値をソースから取得するための適切なSQLが表示されます。
図15-5 「変数: GetSourceColumnName」ページ
変数GetTargetColumnName
を作成します。
この変数は、XREF_DATA
表の列名を判断するために使用されます。「リフレッシュ中」タブには、実装に応じて、値をソースから取得するための適切なSQLが表示されます。
最初のインタフェースを作成する手順は、次のとおりです。
インタフェースを作成します。
データ・モデルのソース表を「ソース」にドロップする必要があります(この例ではIM_FINANCIALS_STAGE)。
ターゲット表(この例ではPS_VCHR_HDR_STG)がターゲット・データ・ストアに表示されます。
図15-6に示すように、各フィールドのマッピングを指定します。
図15-6 インタフェース・ダイアグラム・ページ
「フロー」タブに移動します。
カスタマイズしたKM_LKM SQL to SQL (ESB XREF)として「LKM
」を選択します。
これには、SOURCE_PK_EXPRESSION
というオプションがあります。このオプションで、XREF表のソース・キー値を表す式を渡します。ソース表にキーとして定義されている列が1列のみの場合は、このオプションにその列名(この例ではSEQ_NO
)を単純に記述します。ソース・キーに複数の列が含まれる場合は、キー値を導出するための式を使用します。
たとえば、表に2つのキー列があり、これらの列を連結した値をソース値としてXREF表に格納する場合は、オプション値にSEQ_NO
|DOC_DATE
という式を入力します。このオプションは必須です。
XREFに加えて更新/削除を使用している場合は、LKMの他のオプションを更新します。更新/削除を使用していない場合は、オプションSRC_UPDATE_DELETE_ACTION
に「NONE」を設定します。
IKMで、カスタマイズしたナレッジ・モジュール「IKM SQL to SQL (ESB Xref)」を選択します。
このモジュールで、表15-1にリストしたオプションを定義する必要があります。
表15-1 カスタマイズしたナレッジ・モジュールIKM SQL to SQLの必須オプション
項目 | 説明 |
---|---|
XREF_TABLE_NAME |
XREF表の名前。 |
XREF_COLUMN_NAME |
XREF表のソース列の名前。このオプションに、以前に定義した変数名(#GetSourceColumnName)を入力します。 |
XREF_SYS_GUID_EXPRESSION |
共通識別子にGUIDを使用するか、順序を使用するかを選択します。GUIDの場合は、SYS_GUIDを使用します。順序の場合、この値に順序名を使用します。 |
XREF_ROWNUMBER_EXPRESSION |
XREF_DATA表のROWNUMBER列に挿入される値。順序が必要ない場合は、デフォルト値のGUIDを使用します。 |
ナレッジ・モジュールを選択した場合は、「制御」タブで「CKM Oracle」を選択します。
共通値をターゲット表に送信する必要がない場合は、このステップは無視してください。
ターゲット表に共通識別子のプレースホルダがなく、ターゲット表の列の1つにソース識別子を指定する場合は、Oracle Data Integratorの標準マッピング・ルールを使用して、どのソース識別子をどの列に入力するかを示す必要があります。その場合、この統合ナレッジ・モジュールでは何も処理は実行されません。
共通識別子を保持するターゲット列がターゲット表の一意キーである場合は、その列にダミー・マッピングを挿入します。これは、Oracle Data Integratorの制限のためであり、これを実行しない場合は、次回インタフェースを開いたときにキーが表示されません。実行時、このダミー・マッピングは、統合ナレッジ・モジュールで生成された共通識別子で上書きされます。列値を挿入するターゲット列を示すために、UD1列にマークを付けます。
インタフェースを検証して保存します。
最初のインタフェースに対するパッケージを作成する手順は、次のとおりです。
図15-7に示すように、インタフェースを実行するパッケージを作成します。
図15-7 インタフェースを実行するパッケージ
これには、少なくとも2つのステップが必要です。
ソース列名を保持する変数をリフレッシュします。
インタフェースを実行します。
注意:
それぞれの実装で、その独自のエラー処理ステップをパッケージに追加します。
パッケージを検証して保存します。
パッケージを実行します。
ほとんどの場合、このパッケージは、ソース表にデータが到着するとすぐに実行されます。これを実現するには、Oracle Data Integratorのチェンジ・データ・キャプチャを使用します。
ソース表にデータが到着したときにパッケージを実行する方法は、以降の項で説明します。
例15-1 XREFデータベースでのXREFビューの作成
CREATE OR REPLACE FORCE VIEW "ORAESB"."INVOICE_XREF_VW" ("ROW_NUMBER", "XREF_TABLE_NAME", "RETL_01", "COMMON", "PSFT_01") AS select row_number, XREF_TABLE_NAME, max(decode(XREF_COLUMN_NAME, 'RETL_01', VALUE,null)) RETL_01, max(decode(XREF_COLUMN_NAME, 'COMMON', VALUE,null)) COMMON, max(decode(XREF_COLUMN_NAME, 'PSFT_01', VALUE,null)) PSFT_01 from XREF_DATA GROUP BY row_number, XREF_TABLE_NAME;
データがターゲット・ベース表に移動し、ターゲット識別子が作成された後、ループを完了するために、そのデータをソース識別子に対応するXREFデータベースに戻す必要があります。前述のステップで、共通(またはソース)識別子がターゲット・システムに渡されました。ここでは、ターゲット・システムで、その共通(またはソース)識別子とターゲット・ベース識別子間のマップを提供する必要があります。これは、同じインタフェース表に挿入される場合と、別々の表に挿入される場合があります。このマッピング・データ・ストアは、このインタフェースのソースで使用されます。このインタフェースはパッケージ化され、最終的にターゲット・システムとは別のプロセスでそのパッケージが実行されます。
2番目のインタフェースを作成する手順は、次のとおりです。
データ・トランスポート用のインタフェースを作成します。
ソース・セクションに、XREF_VWビューおよびマッピング・データ・ストアをドロップします(この例では、PeopleSoft PS_VCHR_HDR_STGの同じインタフェース表)。ターゲット・データ・セクションで、XREF_DATA表を選択します。
図15-8に示すように、表名のみからデータをフィルタするように、WHERE句を使用してXREF_VWにフィルタを適用します。たとえば、INVOICEに対してこれを使用している場合は、XREF_VW.XREF_TABLE_NAME='INVOICE'
です。
図15-8 表名のみからデータをフィルタするためのWHERE句を使用したXREF_VWに対するフィルタ
図15-9に示すように、マッピング・データ・ストアとXREF_VWを、共通(またはソース)識別子を格納する列と結合します。
この例では、共通データを格納するPeopleSoftインタフェース表の列はVOUCHER_ID_RELATED
です。
図15-9 共通IDを格納する列と結合されるマッピング・データ・ストアとXREF_VW
XREF_TABLE_NAMEのマップは、実装のXREF_TABLE名である必要があります。
XREF_COLUMN_NAMEのマップは(以前に作成した変数を指す)#GetTargetColumnName
である必要があります。
ROW_NUMBERをXREF_VWのROW_NUMBERにマップします。
VALUEフィールドに対するマップは、マッピング・データ・ストアのターゲット識別子を格納する列です(この例では、PS_VCHR_HDR_STGのINVOICE_ID列)。
IS_DELETEDに対するマップはN
に設定されます。
LAST_MODIFIEDおよびLAST_ACCESSEDに対するマップは、実装ごとに異なります。
図15-10に示すように、XREF_TABLE_NAME、XREF_COLUMN_NAMEおよびVALUEにKey
とマーク付けします。
図15-10 Keyとマーク付けされるXREF_TABLE_NAME、XREF_COLUMN_NAMEおよびVALUE
「フロー」タブで、ロード・ナレッジ・モジュールLKM SQL to Oracle
を使用します。
統合ナレッジ・モジュールIKM Oracle incremental update
を使用します。
「制御」
タブで、チェック・ナレッジ・モジュールCKM Oracle
を使用します。
インタフェースを検証して保存します。
2番目のインタフェースに対するパッケージを作成する手順は、次のとおりです。
図15-11に示すように、インタフェースを実行するパッケージを作成します。
図15-11 インタフェースを実行するために作成されたパッケージ
これには、少なくとも2つのステップが必要です。
ターゲット列名を保持する変数をリフレッシュします。
最初のインタフェースを実行します。
注意:
それぞれの実装で、その独自のエラー処理ステップをパッケージに追加します。
パッケージを検証して保存します。
パッケージを実行します。
ほとんどの場合、このパッケージは、ターゲットのマッピング・データ・ストアにデータが到着するとすぐに実行されます。これを実現するには、Oracle Data Integratorのチェンジ・データ・キャプチャを使用します。
ドメイン値マップ(DVM)はXMLファイルとして使用でき、提供時に使用できます。
DVMを使用する手順は、次のとおりです。
注意:
各DVM中心の列に対してすべての結合を繰り返す必要があります。
Oracle Data Integratorフローに対してエラー処理を使用する手順は、次のとおりです。
図15-21に示すパッケージは、エラーで終了した場合にAIAAsyncErrorHandlingBPELProcessを呼び出すサンプル・インタフェースです。
図15-21 エラーで終了した場合にAIAAsyncErrorHandlingBPELProcessを呼び出すサンプル・インタフェース
このプロセスに対するXMLリクエストの入力は、例15-2で提供されています。
例15-2 AIAAsyncErrorHandlingBPELProcess用のXMLリクエストの入力
<initiateRequest> <Fault> <EBMReference> <EBMID/> <EBMName/> <EBOName/> <VerbCode/> <BusinessScopeReference> <ID/> <InstanceID>[End to End Process Name, Hard code, every developer must know this process name]</InstanceID> <EnterpriseServiceName/> <EnterpriseServiceOperationName/> </BusinessScopeReference> <SenderReference> <ID>[Sender Reference ID - Hard code the system id of the source system]</ID> <SenderMessageID/> <TransactionCode/> <ObjectCrossReference> <SenderObjectIdentification> <BusinessComponentID/> <ID/> <ContextID/> <ApplicationObjectKey> <ID/> <ContextID/> </ApplicationObjectKey> <AlternateObjectKey> <ID/> <ContextID/> </AlternateObjectKey> </SenderObjectIdentification> <EBOID/> </ObjectCrossReference> <Application> <ID/> <Version/> </Application> </SenderReference> </EBMReference> <FaultNotification> <ReportingDateTime><%=odiRef.getPrevStepLog("BEGIN")%></ReportingDateTime> <CorrectiveAction>[ODI does not have it, leave this element null]</ CorrectiveAction > <FaultMessage> <Code>[ODI Error return code to be passed here. Must find the ODI system variable to get the return code]</Code> <Text><%=odiRef.getPrevStepLog("CONTEXT_NAME" )%>/<%=odiRef.getSession( "SESS_ NAME" )%>/<%=odiRef.getPrevStepLog("STEP_ NAME")%>:<![CDATA[<%=odiRef.getPrevStepLog("MESSAGE")%>]]></Text> <Severity>[ODI does not have it, hard code it to 1]</Severity> <Stack/> </FaultMessage> <FaultingService> <ID>[Hard code a meaningful name of the Process, For example, CustomerInitialLoad (this could be same as package name)] </ID> <ImplementationCode>ODI</ImplementationCode> <InstanceID><%=odiRef.getPrevStepLog("SESS_NO")%></InstanceID> </FaultingService> </FaultNotification> </Fault> </initiateRequest>
表15-2に、Oracle Data IntegratorのRef関数とそれぞれの説明を示します。
表15-2 Oracle Data IntegratorのRef関数
Ref関数 | 説明 |
---|---|
|
エラーで終了したステップが開始したときの日時 |
|
前のステップによって返されたエラー・メッセージ(ある場合)。エラーが発生しなかった場合は空白文字列です。 |
|
セッションの番号 |
|
手順が実行されたコンテキストの名前。 |
|
セッションの名前。 |
|
ステップの名前。 |
パッケージおよびデータ・モデルをWebサービスとして公開する手順は、次のとおりです。
スタンドアロン・サーバーとしてAxis2をインストールします。
環境変数JAVA_HOMEに、JDKリリースをインストールしたディレクトリのパス名を設定します。
Apache Axis2バージョン1.2 (http://axis.apache.org/axis2/java/core/download.cgi
)をダウンロードし、Axis2標準バイナリ・ディストリビューションを適切な場所に解凍して、ディストリビューションがその固有のディレクトリに存在するようにします。環境変数AXIS2_HOMEに、Axis2の抽出したディレクトリのパス名を設定します(例: /opt/axis2-1.2)。
コマンド$AXIS2_HOME\bin\axis2server.bat
(Windows)を実行して、スタンドアロンAxis2サーバーを起動します。
起動後に、http://localhost:8080/axis2/services/にアクセスすると、Axis2に組み込まれているデフォルトのWebサービスを使用できます。
axis2.war
をhttp://axis.apache.org/axis2/java/core/download.cgi
からダウンロードします。
axis2.war
をOC4Jアプリケーション・サーバーにデプロイします。
axis2.war
をOC4Jアプリケーション・サーバー(http://www.oracle.com/technetwork/middleware/ias/downloads/utilsoft-090603.html
)にデプロイするか、またはSOA SuiteのOC4Jサーバーも使用できます。http://<Host:port>
に移動し、アプリケーション・サーバーを起動するとOC4Jホームが表示されます。「アプリケーション」タブをクリックし、次に「デプロイ」タブをクリックします。ファイルの場所を指定するよう要求されます。参照してAxis2.war
ファイルを指定し、デプロイします。
WARが正常にデプロイされた後、Webブラウザでhttp://<host:port>/axis2
にアクセスしてテストします。この結果、「Axis2 Web Application Home Page」が開きます。
手順が正常に終了したことを確認するために、「Validate」をクリックします。
Oracle Data Integrator Public Web ServicesをAxis2にインストールします。
Axis2で、「Administration」ページに移動します。
「Upload Service」リンクを選択します。
Oracle Data Integrator Web Servicesの.aarファイルを参照します。
これは、Oracle Data Integratorインストール・ディレクトリの/tools/web_services/
サブディレクトリにあります。
「アップロード」ボタンをクリックします。
Axis2によって、Oracle Data Integrator Web Servicesがアップロードされます。Data Integrator Public Web ServicesがAxis2のサービス・リストに表示されるようになります。
正常にインストールされたサービスのサービスと操作は使用可能なサービスのページ(http://<Host>:<HTTP port>/axis2/services/listServices
)に表示され、ここにOdiInvokeが表示されます。
データ・サービス用の環境設定
データベース・ドライバ(http://www.oracle.com/technetwork/database/enterprise-edition/jdbc9201-092698.html
)を適切なディレクトリにインストールする必要があります。OC4Jの場合はORACLE_HOME/j2ee/home/applibです。
データ・サーバーを指すJDBCデータソースを作成します。
OC4J管理インタフェースに接続します。
「管理」タブで、「サービス」|「JDBCリソース」を選択し、「タスクに移動」をクリックします。
「接続プール」セクションで「作成」ボタンをクリックします。
Axis2アプリケーションを選択し、「新規接続プール」を選択した後、「続行」を選択します。
JDBCデータソースのフィールドを入力して、「終了」をクリックします。
「データソース」セクションで「作成」ボタンをクリックします。
Axis2アプリケーションを選択し、「管理データソース」を選択した後、「続行」を選択します。
META-INF/context.xmlおよびWEB-INF/web.xmlがiAxisディレクトリで更新されます。
例15-3に示すように、特定のフォルダORACLE_HOME\j2ee\home\applications\axis2\META-INFのapplication.xmlを更新します。
環境変数ODI_JAVA_HOMEに、JDKリリースをインストールしたディレクトリのパス名を設定します。
図15-22に示すように、トポロジを構成します。
トポロジ・マネージャの物理アーキテクチャ・ビューで、Axis2テクノロジを選択します。右クリックして、データサーバーの挿入を選択します。別のWebサービス・コンテナを使用している場合は、適切なテクノロジをかわりに選択します。
「定義」タブで次の各フィールドを入力します。
名前: Oracle Data Integratorに表示されるとおりのデータサーバーの名前。
公開されたサービスのベースURL: http://<Host>:<HTTP port>/axis2/services
。
選択したデプロイメント方法に対応するオプションを選択します。
Webサービスのアップロード: Axis2アプリケーションのルートURL(通常はhttp://<Host>:<HTTP port>/axis2/axis2-admin/
)、およびAxis2管理者のユーザー名(admin
)とパスワード(axis2
)を指定します。
「OK」をクリックします。物理スキーマを作成できるウィンドウが開きます。
「コンテキスト」タブに移動し、データ・サービスをデプロイするコンテキストごとに論理スキーマを1つずつ定義します。
「OK」をクリックします。
図15-22 トポロジ構成
Webサービスを使用して表のデータにアクセスするようにデータ・モデルを設定します。
モデルを開き、図15-23に示すように「サービス」タブに移動します。
「アプリケーション・サーバー」リストから、以前に設定したWebサービス・コンテナを選択します。
生成したWSDLで使用するネームスペースを入力します。
Webサービスが含まれる、生成したJavaパッケージに名前を付けるために使用するパッケージ名を指定します。通常、この名前の形式はcom.<company name>.<project name>
です。
「データソースの名前」フィールドで、データソースの設定時にサーバーに対して定義したデータソースの名前をコピーして貼り付けます。(データソースのJNDIロケーションを指定します。)
データ・サービス名を定義します。
リストからサービス・ナレッジ・モジュール(SKM Oracle)を選択し、そのオプションを設定します。
「デプロイ済データストア」タブに移動します。
Webサービスとして公開するために必要なすべてのデータ・ストアを選択します。それぞれに対して、データ・サービス名および公開されたエンティティの名前を指定します。
「OK」をクリックして、変更を保存します。
「生成およびデプロイ」タブをクリックして、OC4Jサーバーにデプロイします。
デプロイしたデータ・ストアは、使用可能なすべての操作とともに、http://<Host>:<HTTP port>/axis2/services/listServices
で表示できます。
生成したデータ・サービスは、パッケージで提供されているOdiInvokeWebServiceツールを使用してテストできます。
図15-23 「サービス - データ・サービス」ページ
Webサービスを使用してシナリオを実行します。
OdiInvoke Webサービスは、Webサービスを使用してシナリオを実行するために使用されます。WSDLはhttp://<Host>:<HTTP port>/axis2/services/OdiInvoke?wsdl
です。使用するポートは、invokeScenario
というポートです。
このWebサービスは、エージェントに対して、特定の作業リポジトリに接続し、特定のシナリオを起動するように指示します。パラメータは、OSコマンドからのシナリオの実行時に使用するパラメータと同じです。例15-4は、このWebサービスに対するサンプルのSOAPリクエストです。
図15-5に示すように、シナリオの実行によってSOAPレスポンスが返されます。
例15-3 ORACLE_HOME\j2ee\home\applications\axis2\META-INFのapplication.xmlの更新
<Context > <Resource name="jdbc/TestDS
" type="javax.sql.DataSource
" driverClassName="oracle.jdbc.OracleDriver
" url="jdbc:oracle:thin:@abijayku-idc:1522:orcl1
" username="master
" password="master
" maxIdle="2
" maxWait="-1
" maxActive="4
"/> </Context> (Resource name will be reused in the web.xml file and in the Model in Designer.) (driverClassName, url, username and password will explicitly point to the data source.) Update the web.xml file with the resource name of the context.xml file (here res-ref-name) in the given folder ORACLE_ HOME\j2ee\home\applications\axis2\axis2\WEB-INF as follows: <resource-ref> <description>Data Integrator Data Services on Oracle_SRV1</description> <res-ref-name>jdbc/TestDS
</res-ref-name> <res-type>javax.sql.DataSource</res-type> <res-auth>Container</res-auth> </resource-ref>
図15-4 OdiInvoke Webサービスに対するサンプルSOAPリクエスト
<invokeScenarioRequest> <invokeScenarioRequest> <RepositoryConnection> <JdbcDriver>oracle.jdbc.driver.OracleDriver</JdbcDriver> <JdbcUrl>jdbc:oracle:thin:@sbijayku-idc:1522:orcl1</JdbcUrl> <JdbcUser>MASTER_FINPROJ</JdbcUser> <JdbcPassword>master</JdbcPassword> <OdiUser>SUPERVISOR</OdiUser> <OdiPassword>SUNOPSIS</OdiPassword> <WorkRepository>WORK</WorkRepository> </RepositoryConnection> <Command> <ScenName>ABC</ScenName> <ScenVersion>001</ScenVersion> <Context>RETL_TO_PSFT</Context> <LogLevel>5</LogLevel> <SyncMode>1</SyncMode> </Command> <Agent> <Host>sbijayku-idc</Host> <Port>20910</Port> </Agent> </invokeScenarioRequest> </invokeScenarioRequest>
図15-5 シナリオの実行によって返されるSOAPレスポンス
<odi:invokeScenarioResponse xmlns:odi="xmlns.oracle.com/odi/OdiInvoke"> <odi:CommandResultType> <odi:Ok>true</odi:Ok> <odi:SessionNumber>1148001</odi:SessionNumber> </odi:CommandResultType> </odi:invokeScenarioResponse>