目次


InfoSphere DataStage XMLおよび Web サービス・パックを使用したデータの変換と統合

Comments

概要

DataStage XML および Web サービス・パックの概要

Ascential DataStage は 2005 年に IBM によって買収され、現在は IBM InfoSphere DataStage として知られています。この製品は、異なる構造やフォーマットを持つ組織データの統合と、カスタマー・リレーションシップ・マネジメント (CRM) 分析、意思決定支援システム (DSS)、および e-business の効果的な支援を可能にする、使いやすい GUI ベースの抽出・変換・ロード (ETL) ツールです。

DataStage はクライアント/サーバー・インフラストラクチャーに基づいており、デザイナー、マネージャー、ディレクター、およびアドミニストレーターなどのコンポーネントを含み、充実した機能性を提供します。DataStage により開発から保守までのタスクを大幅に簡素化できます。

本資料では DataStage の XML パックおよび Web サービス・パックを中心に説明します。これら 2 つのパックにより、XML および Web サービスの DataStage ソリューションへの統合が容易に行えます。DataStage でこれら 2 つのパックを使用する利点は次のとおりです。

  1. 開発期間の短縮
  2. 迅速なユーザー応答
  3. 開発、マネジメント、および保守のためのユーザー・フレンドリーな GUI 環境

DataStage XML (DataStage の XML パック) は XML ダイジェスティング、XML パブリッシング、および変換機能から構成されています。本資料の XML のセクションでは、XML パックで提供される主要な変換機能の 1 つ、XML 文書と表データ間での変換について紹介します。

Web サービス・パックは、DataStage でリモート・サービスを呼び出し、それらのサービスを単純なデータ・ソース、データ・ターゲット、または対話式のデータ・インターフェースとして扱えるようにします。Web サービス・トランスフォーマーは、対話式のデータ・インターフェースを提供するものですが、これについては本資料の Web サービスの項で説明します。

本資料には DataStage (バージョン 7.5.1A、XML および Web サービス・パック導入済み) を使用したデータ・ソリューション開発の 4 つの例と併せて、それらの例に関する分析およびメモが含まれています。これらは次のような一般的なシナリオに従って記述されます。

  • 表データから XML 文書をパブリッシングする
  • XML 文書を構文解析して表データへ変換する
  • 入出力データを使用して Web サービスにアクセスする

前提条件

  • InfoSphere DataStage V7.5.1A、DB2® パック、XML パック、および Web サービス・パックが導入されている必要があります。
  • IBM DB2 for Linux®、UNIX®、および Windows® V8.2 (またはそれ以降) がインストールされている必要があります。
  • 読者は DataStage の基本的な知識と併せて、XML、Web サービス、および DB2 に関する多少の実践的経験を有することが前提になっています。

第 I 部. 表データから XML 文書をパブリッシングする

既存の表データに基づいた XML 文書のパブリッシングは一般的なシナリオです。関係表や順次ファイルは、XML 文書または XML チャンクなどの XML 階層構造への変換を要する場合があります。このような場合は、XML 出力ステージを使用して XML 出力を生成できます。入力表フィールドを出力文書の特定の位置にマップするために、XPath 式が使用されます。

例 1. XML 出力ステージを使用して、2 つの表に基づく XML ファイルを生成する

図1. XML パブリッシングのジョブ・ダイアグラム
図1. XML パブリッシングのジョブ・ダイアグラム
図1. XML パブリッシングのジョブ・ダイアグラム

例 1 の概要

例 1 では、図 1 のように顧客データおよび連絡先データが 2 つの対応する DB2 表からそれぞれ抽出されています。複雑な SQL の置き換えやデータの統合、また結合されたデータを DSLink6 を介して XML 出力ステージへフィードするためにトランスフォーマーが使用されます。次に XML 出力ステージでは XML の生成物が作成され、ファイル・システムに保存されます。図 1 はアプリケーション・デモ全体を簡単に説明しています。

一般的なデプロイメントのステップは次のとおりです。

  1. DB2 表の定義およびデプロイ
  2. XML 構造の準備
  3. DB2 表定義および XML 表定義のインポート
  4. 結合データを提供するための、トランスフォーマーによる DB2 ステージのセットアップ
  5. XML 文書生成のための XML 出力ステージのセットアップ
  6. コンパイルと実行

これらのステップを詳しく調べて見ましょう。

ステップ 1. DB2 表の定義およびデプロイ

リスト 1 に示されている DDL を使用してこれらの表をローカル DB2 サーバー上のサンプル・データベースにデプロイし、 図2.1 および 2.2 に従ってサンプル・データをロードします。

リスト 1. 顧客表および連絡先表の DDL
--customer table
CREATE TABLE S_CUST
(
    CUST_NUM  CHARACTER(10) PRIMARY KEY,
    CUST_NAME VARCHAR(100)  NOT NULL
);
--contact table
CREATE TABLE S_CONTACT
(
CNT_NUM  INTEGER
GENERATED  ALWAYS AS IDENTITY( START WITH 1, INCREMENT BY 1 )
PRIMARY KEY,
    CUST_NUM CHARACTER(10) NOT NULL,
    F_NAME  VARCHAR(50)   NOT NULL,
    L_NAME   VARCHAR(50)   NOT NULL,
    EMAIL    VARCHAR(100)  NOT NULL
);
図2-1. 顧客表のサンプル・データ
図2-1. 顧客表のサンプル・データ
図2-2. 連絡先表のサンプル・データ
図2-2. 連絡先表のサンプル・データ
図2-2. 連絡先表のサンプル・データ

ステップ 2. XML 構造の準備

XSD スキーマ・ファイルまたはサンプルの XML 文書のサンプルを使用して、ターゲット XML 構造を定義できます。リスト 2 は DataStage にインポートされるサンプルの XML 文書です。

リスト 2. target.xml - サンプル XML ファイル
<CustomerInfo xmlns="http://www.ibm.com/schemas/SimpleXMLDemo"
    xmlns:cnt="http://www.ibm.com/schemas/ContactDemo"
    xmlns:xsd="http://www.w3.org/2001/XMLSchema"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
	<CustomerID>0000000001</CustomerID>
	<CompanyName>MindLight Corp.</CompanyName>
	<Contacts>
		<cnt:Contact>
			<cnt:FirstName>Lee</cnt:FirstName>
			<cnt:LastName>Chen</cnt:LastName>
			<cnt:Email>LeeChen@gmail.com</cnt:Email>
		</cnt:Contact>L
	</Contacts>
</CustomerInfo>

リスト 2 に示されるように、XML ファイルには次のような 5 つの主要なフィールドがあります。CustomerID、CompanyName、FirstName、LastName、および Email です。それぞれ、データベース表に対応する列があります。

ステップ 3. DB2 表定義および XML 表定義のインポート

データ・ソースの情報を入力するには、表定義を手動で入力するか、DataStage でソース・データから直接定義をインポートする必要があります。DataStage 表定義には、さまざまな種類のデータ・ソースのメタデータが表形式で含まれており (図 3 参照)、データを保持している表またはファイルの名前や場所、またそれらの中に含まれる列の定義が含まれています。情報は DataStage リポジトリーの表定義に保存されます。

この例では、DB2 から 2 つのデータベース表がインポートされ、XML 構造がサンプル・ファイルから抽出されています。

注: これらの機能を有効にするには、DB2 および XML のプラグイン・モジュールがインストールされている必要があります。

図3. 表定義の構造
図3. 表定義の構造
図3. 表定義の構造

DB2 表定義のインポート

DB2 表をインポートするには、「プラグインのメタデータ定義 (Plug-in Meta Data Definitions)」 (図 4 で示された赤い円内) を選択します。

図4. プラグインのメタデータ定義
図4. プラグインのメタデータ定義
図4. プラグインのメタデータ定義

ポップアップ・ウィンドウで「DB2 プラグイン (DB2 plug-in)」を選択し、「OK」をクリックします。「DSDB2 メタデータのインポート (Import DSDB2 Meta Data)」ウィンドウの最初のページ (図 5 参照) で、適切なユーザー名およびパスワードを使用し、メタデータをインポートするソースとして「サンプル (SAMPLE)」データベースを選択します。「テーブル (Tables)」および「完全修飾表名 (Fully Qualified Table Names)」チェック・ボックスが選択されていることを確認し、次のウィンドウで表名がスキーマ名と共に表示されるようにします。「次へ (Next)」ボタンをクリックします。

図5. DSDB2 メタデータのインポート 1
図5. DSDB2 メタデータのインポート 1
図5. DSDB2 メタデータのインポート 1

DB2 表定義は、図 6 に示されるように「PlugIn\sample」という「カテゴリー (To category)」に保存できます。

図6. DSDB2 メタデータのインポート 2
図6. DSDB2 メタデータのインポート 2
図6. DSDB2 メタデータのインポート 2

XML 表定義のインポート

表定義 (Table definitions)」リポジトリー・ビューで右クリックし、「インポート (Import)」 > 「XML 表定義 (XML Table Definition)」を選択します (図 4 で示されたアクションに類似)。これを行った後に、XML メタデータ・インポーターが起動されます (図 7 参照)。

図7. XML メタデータ・インポーター
図7. XML メタデータ・インポーター
図7. XML メタデータ・インポーター

XML メタデータ・インポーターは XML サンプルまたは XSD ファイルから XML 構造をインポートできます。XML メタデータ・インポーターで target.xml(US) ファイルを開きます。XML ファイルは一度開かれると表構造にマップされます。図 7 で示されているように、XML エレメントのテキスト・コンテンツを抽出するために、表定義の列として 5 つのデータ・エレメントの「テキスト (TEXT)」フィールド (赤い円で囲まれた部分) を選択します。「説明 (Description)」フィールド (図 7 の赤い枠で囲まれた部分) には XPath が含まれていますが、これは XML 文書内における列の対応する位置を示しています。この例では、各連絡先レコードには「キー (Key)」列として使用されるユニークな E メール・アドレスがあると仮定しています。表定義を「target_xml」という名前で「PlugIn\sample」カテゴリーに保存します。

これまでに、3 つの表定義 (図 8 の赤い円の部分) がカテゴリーに正常にインポートされました。

図8. インポートされた表定義
図8. インポートされた表定義

ステップ 4. 結合データを提供するための、トランスフォーマーによる DB2 ステージのセットアップ

表定義がリポジトリーに準備できたら、次に XML 出力のデータ・ソースの設定を行います。データの抽出には次の 2 つのオプションがあります。

  1. リスト 3 に示されるように、1 つの DB2 ステージで SQL を使用する
  2. トランスフォーマーを使用して、複数のステージのデータを結合する

この例では 2 番目のオプションを使用します。

リスト 3. データ抽出のための照会
SELECT cnt.CUST_NUM,c.CUST_NAME,cnt.F_NAME,cnt.L_NAME,cnt.EMAIL
FROM S_CONTACT cnt
JOIN  S_CUST c ON cnt.CUST_NUM=c.CUST_NUM ;
図9. リスト 3 の照会の結果
図9. リスト 3 の照会の結果
図9. リスト 3 の照会の結果

DataStage で図 9 に示されたものと同じ出力を得るためには、2 つの DB2/UDB API ステージ (パレットのデータベース・カテゴリー内) および 1 つの Transformer ステージ (パレットのプロセッシング・カテゴリー内) が採用されます。これらのステージが新しいジョブ・ダイアグラムに追加され、次のように名前が付けられます。

  • 2 つの DB2 ステージ:「CONTACT」および「CUST」
  • Transformer ステージ:「JOIN_CUST_CNT」

DSLink3 および DSLink4 をそれぞれ使用して、「CONTACT」および「CUST」を「JOIN_CUST_CNT」に接続します。(図 10 参照。)

図10. ジョブ・ダイアグラム
図10. ジョブ・ダイアグラム
図10. ジョブ・ダイアグラム

データベース開発者としては、顧客表を連絡先表に結合し、顧客表を主たる表として扱うのが一般的です。しかしこの例では、DSLink3 の実線矢印が示すように、連絡先表が主たる表です。トランスフォーマーは非 1 次表において 1 次表のレコードのルックアップ・アクションを実行します。1 次表の単一レコードに対して、非 1 次表からはレコードが 1 つだけ取り出されます。

注: ODBC ステージおよび UniVerse ステージのみが複数行のルックアップをサポートしています。

「CONTACT」ステージの構成

「CONTACT」ステージをダブルクリックして、そのプロパティーを構成します。「ステージ (Stage)」ページで、次の DB2 の接続情報を入力します。データベース名、ユーザー名、およびパスワードです。「出力 (Output)」ページに切り替え、「列 (columns)」タブをクリックします。列情報には、「列名 (Column name)」、「出力仕様 (Derivation)」、「タイプ (Type)」などが含まれます。列は直接編集するか、既存の表定義からロードすることができます。ここでは、インポートした CHENLI.S_CONTACT 表定義を使用してこのステージに列をロードします。「ロード (Load)」ボタンをクリックし、表定義ポップアップ・ウィンドウで「CHENLI.S_CONTACT」を選択して「OK」を押し、次に連続した列選択ウィンドウで表定義のすべての列を選択します。列がロードされると、結果は図 11 のように見えます。

図11. ロードされた列
図11. ロードされた列
図11. ロードされた列

「CONTACT」ステージの SQL を設定し、DB2 からデータを抽出します。「SQL (SQL)」タブを選択し、「SQL ビルダー (SQL Builder)」をクリックします。SQL ビルダーは GUI ツールで、デフォルトで起動され、SQL 照会の組み立てを支援します (図 12 参照)。

図12. SQL ビルダー
図12. SQL ビルダー
図12. SQL ビルダー

SQL の準備ができたら「OK」をクリックします。「SQL (SQL)」タブは図 13 のように見えるはずです。これで「データの表示 (View Data)」ボタンを選択して「CONTACT」表の内容を見ることができます。

図13. 「SQL (SQL)」タブ
図13. 「SQL (SQL)」タブ
図13. 「SQL (SQL)」タブ

これで「CONTACT」ステージの構成は完了しました。同様のステップで「CUST」ステージのセットアップも行えます。その後、2 つの表のアイコンが両方のリンクに表示されます。

「JOIN_CUST_CNT」ステージの構成

今度はトランスフォーマーの「JOIN_CUST_CNT」を構成して、2 つの DB2 入力ステージをアグリゲートして合わせ、結合データを作成することができます。図 14 に示されているように、DSLink3 の CUST_NUM を DSLink4 の CUST_NUM にドラッグします。

図14. Transformer ステージ
図14. Transformer ステージ
図14. Transformer ステージ

ステップ 5. XML 文書生成のための XML 出力ステージのセットアップ

図 15 に示されているように「Gen_Cust_XML」という名前の「パレット (Palette)」の「リアル・タイム (Real Time)」カテゴリーから XML 出力ステージをダイアグラムに追加し、Transformer ステージの「JOIN_CUST_CNT」からそこにリンクを追加します。

図15. XML 出力のジョブ・ダイアグラムへの追加
図15. XML 出力のジョブ・ダイアグラムへの追加
図15. XML 出力のジョブ・ダイアグラムへの追加

Gen_Cust_XML」ステージをダブルクリックして、そのプロパティーを設定します。「ステージ (Stage)」ページでは、現在のソリューションに対する「文書設定 (Document Settings)」タブの「名前空間の宣言 (Namespace Declarations)」 (図 16 参照) および「オプション (Options)」タブの出力 XML ファイルのファイル・パス (図 17 参照) のみ設定が必要です。 名前空間の宣言のロードは、表定義から列をロードするのに似ており、XML 表定義から名前空間をロードします。

図16. 名前空間の宣言のロード
図16. 名前空間の宣言のロード
図16. 名前空間の宣言のロード
図17. 出力ファイル・パスの設定
図17. 出力ファイル・パスの設定
図17. 出力ファイル・パスの設定

「入力 (Input)」ページでは、列タブを入力する必要があります。このプロセスは DB2 ステージに出力列をロードするのに似ています。XML 表定義「target_xml」をロードすると、XML 出力ステージは図 18 のように見えます。

図18. XML 表定義からの列のロード
図18. XML 表定義からの列のロード
図18. XML 表定義からの列のロード

注: 各顧客にはターゲット XML 構造内に複数の連絡先を持たせることができるため、冗長性を削減するために、顧客ごとに連絡先情報をアグリゲートする必要があります。このためには、図 19 に示すように「変換設定 (Transformation Settings)」を設定します。

図19. 変換設定 (Transformation Settings)
図19. 変換設定 (Transformation Settings)
図19. 変換設定 (Transformation Settings)

トリガー列の「CustomerID」を使用すると、「CustomerID」フィールドが新しい値に変更された場合にのみ、出力が単一の XML 文書を含む新しいレコードを生成します。図 9のデータが単一の XML 文書にアグリゲートされます。

「JOIN_CUST_CNT」ステージに戻り、入力の左端の列フィールドを右端の出力にドラッグしてリンクさせます。(図 20 参照。)

図20. Transformer ステージの再表示
図20. Transformer ステージの再表示
図20. Transformer ステージの再表示

OK (OK)」をクリックします。ここまでで XML パブリッシング・ソリューションが完了しました。

ステップ 6. コンパイルと実行

このジョブをデザイナーでコンパイルして実行します。エラーがなければ、ルーチン・タスクとしてジョブ・スケジュールに追加できます。デザイナーでジョブを実行する場合、エラーが検出されなければ関連する統計情報のリンクが緑色に変わります (図 21 参照)。エラーが発生すると、リンクは赤くなります。ログを調べてデバッグを行う必要があります。図 21 では、このジョブは次のターゲット XML ファイルを正常に生成しました。SampleOutput1.xml(US)

図21. 例 1 のジョブの実行
図21. 例 1 のジョブの実行
図21. 例 1 のジョブの実行

第 II 部.XML 文書を構文解析して表データへ変換する

このシナリオは XML データのパブリッシングとは逆のプロセスとなり、XML データが入力され、それを解析して表レコードに入れた後、そのレコードをデータベース表に挿入します。XML 文書を解析して表データに入れる方法を示すために、2 つの例を示します。例 2 は前出の XML パブリッシングの例の逆のプロセスで、XML 文書を顧客表および連絡先表にロードするものです。例 3 は DB2 出力と併せてより複雑な XML 入力を含んでいます (3 つの表)。これらの 2 つのケースでは、異なるデプロイメント方法が使用されます。

例 2. XML 入力ステージを使用して、XML 文書から顧客および連絡先情報を抽出する

例 2 の概要

例 2 では、例 1 の表定義を使用し (図 8 参照)、新しい企業および 2 つの連絡先を持つ XML ファイルを使用して入力データを準備します (input_cust_cnt.xml(US) 参照)。このケースでは、Folder ステージを使用して XML ファイルを読み取り、コンテンツを XML 入力ステージに渡して解析し、表レコードに出力した後、トランスフォーマーを使用して列を個別の表に分散します。このジョブ・ダイアグラムは図 22 に示されています。

図22. 例 2 のジョブ・ダイアグラム
図22. 例 2 のジョブ・ダイアグラム
図22. 例 2 のジョブ・ダイアグラム

「XML_CUST_CNT」ステージからの出力は 図 9 に示される行に似たものになると予想されます。

注: 「CUST_NUM」列および「CUST_NAME」列には重複した情報が存在し、これらが顧客表に渡されて主キーの競合が生じます。この問題に対処するために、アグリゲーターを使用して当該の重複レコードを顧客ごとに 1 つのレコードにまとめることができます。

このソリューション例を開発する一般的なステップには以下が含まれます。

  1. Folder ステージのセットアップによる、1 つまたは複数の XML ファイルの読み取り
  2. XML 入力ステージのセットアップ
  3. データを受け取るための DB2 ステージのセットアップ
  4. アグリゲーターの構成
  5. データを配布するための Transformer ステージのセットアップ
  6. コンパイルと実行

これらのステップを詳しく調べて見ましょう。

この例では、図 22 に示されているように、新しいジョブに対して先にすべてのステージおよびリンクを追加してから、各ステージの設定をステップ・バイ・ステップで行うことができます。

ステップ 1. Folder ステージのセットアップによる、1 つまたは複数の XML ファイルの読み取り

XML_FOLDER」ステージをダブルクリックします。「ステージ (Stage)」ページでフォルダーの pathname のプロパティーを設定します。「出力 (Output)」ページでワイルドカード・プロパティー (ファイル名のワイルド・カード*.txt など。このケースでは *.xml を使用) を入力します。

次に「XML_FOLDER」ステージに列をロードし、図 23 に示されているように組み込みの表定義である「Folder」を適用します。「Folder」定義には次の 2 つのフィールドが含まれています。「FileName」および「Record」です。「Record」列にはソース・フォルダーからの入力ファイルのコンテンツが入力されます。

図23. 「Folder」表定義からの列のロード
図23. 「Folder」表定義からの列のロード
図23. 「Folder」表定義からの列のロード

ステップ 2. XML 入力ステージのセットアップ

XML_CUST_CNT」をダブルクリックして、プロパティー・ウィンドウを開きます。「XML ソース列 (XML source column)」として「Record」を指定し、そこから入力 XML 文書を取得します。次に「列のコンテンツ (Column content)」を「XML 文書 (XML document)」に設定します。

図24. XML ソースのセットアップ
図24. XML ソースのセットアップ
図24. XML ソースのセットアップ

図 25 で示されている「出力 (Output)」ページで「トランスフォーマーの設定 (Transformation Settings)」タブおよび「列 (Columns)」タブに入力して「XML_CUST_CNT」ステージを有効にし、入力 XML 文書を構文解析して出力レコードを生成します。最初に「反復エレメントが必要 (Repetition element required)」を選択しますが、これは入力文書に複数の連絡先エレメントが含まれているためです。次に、XML 表定義から名前空間をロードします (図 16 に類似)。

注: 入力文書に複数の名前空間およびプレフィックスが含まれている場合は、名前空間の宣言は必須事項です。

図25. 「XML_CUST_CNT」ステージの変換設定
図25. 「XML_CUST_CNT」ステージの変換設定
図25. 「XML_CUST_CNT」ステージの変換設定

一般的には、名前空間のロードが XML 表定義の列を「列 (Columns)」タブに同時にロードするトリガーとなるため、XML 入力ステージの列定義を手動でロードする必要はありません (図 26 参照)。

注: 名前空間および列を別々にロードする必要のある XML 出力ステージとは異なり、XML 入力ステージではそれらは同時にロードされます。

図26. 「XML_CUST_CNT」ステージの出力列
図26. 「XML_CUST_CNT」ステージの出力列
図26. 「XML_CUST_CNT」ステージの出力列

それぞれの列定義では「説明 (Description)」フィールドに XPath 式があり、XML 文書内の特定のエレメントを対応する出力データ列にマップします。これらの XPath は XML 解析の最も重要な設定です。また、「キー (Key)」フィールドでは反復エレメントを指定します。ここでは、連絡先ごとにユニークであるため、E メール・エレメントがキーとして選択されています。

これで「XML_CUST_CNT」ステージのセットアップは完了しました。

ステップ 3. データを受け取るための DB2 ステージのセットアップ

最初に、2 つの DB2 ステージである「CONTACT」および「CUST」のサーバー情報を構成します。

しかし前出の DB2 ステージの例とは異なり、出力リンクの代わりに入力リンクを使用するため、今度は DB2 ステージの「入力 (Input)」ページで作業を行います。ターゲット表を選択し (図 27 参照)、それぞれの DB2 ステージに列をロードします。

注: 自動生成された列は含めないでください。

図27. ターゲット表の選択
図27. ターゲット表の選択
図27. ターゲット表の選択

連絡先表で、「CNT_NUM」列は自動的に増分された ID 列であり、その値は新規レコードが挿入される際に自動的に生成されるため、この列は選択されません。一方、顧客表のすべての列は XML 文書から取られたものであるため、これらの列は選択されます。

ステップ 4. アグリゲーターの構成

XML 入力ステージは同一の顧客に対して複数の行を生成するため、「CUST」ステージのために顧客の冗長情報をまとめるために Aggregator ステージが必要です。

アグリゲーターによって受け取られる入力データは出力リンクと同一の構造を持っていますが、これは「CUST」ステージで定義されるものです。(基本的には、DB2 表の「CHENLI.S_CUST」で定義されます。) そこで、このアグリゲーターの入力として、表定義の「CHENLI.S_CUST」をロードします。

アグリゲーターの「出力 (Outputs)」ページで、出力列は「CUST_NUM」および「CUST_NAME」です。図 28 に示されるように、レコードの重複を避けるために 2 つの出力列の「出力仕様 (Derivation)」を定義する必要があります。

図28. Aggregator ステージ
図28. Aggregator ステージ
図28. Aggregator ステージ

図 28 の「出力仕様 (Derivation)」列の下のハイライト表示されたセルをダブルクリックします。「出力仕様 (Derivation)」を設定するためのダイアログ・ボックスが表示されます。図 29 は、アグリゲート機能の「grouped」を指定した出力仕様の詳細な設定を表しています。

図29. 「出力仕様 (Derivation)」ダイアログ・ボックス
図29. 「出力仕様 (Derivation)」ダイアログ・ボックス
図29. 「出力仕様 (Derivation)」ダイアログ・ボックス

「grouped」の他に、多のケースに対して「アグリゲート機能 (Aggregate function)」選択ボックスで「Max」、「Min」、「Count」、「Average」、「Sum」などの機能を選択できます。

ステップ 5. データを配布するための Transformer ステージのセットアップ

トランスフォーマーのプロパティー・ウィンドウでソースをターゲットにリンクします (図 30 参照)。

図30. トランスフォーマーでのデータの配布
図30. トランスフォーマーでのデータの配布
図30. トランスフォーマーでのデータの配布

終了したら「OK」を押します。例 2 の実行準備が整いました。

ステップ 6. コンパイルと実行

すべての準備が整うと、ロードの完了時に図 31 のようなビューがデザイナーに表示されます。

図31. XML 文書が正常にロードされた場合
図31. XML 文書が正常にロードされた場合
図31. XML 文書が正常にロードされた場合

リスト 4 の SQL を使用して DB2 の表を検証すると、図 32 のような結果が表示されます。

リスト 4. DB2 での表の検証
SELECT * FROM S_CUST cust WHERE cust.CUST_NUM='0000000002';
SELECT * FROM S_CONTACT cnt WHERE cnt.CUST_NUM='0000000002';
図32. リスト 4 の SQL の結果
図32. リスト 4 の SQL の結果
図32. リスト 4 の SQL の結果

例 3. XML 入力ステージ群を使用して、XML 文書から抽出したデータを 3 つの表に入れる

例 3 の概要

例 2 の XML 文書 (input_cust_cnt.xml(US)) は、一方が他方を参照する 2 つの表のみに対してデータが配布されるという、一般的なシナリオを示しています。今度はもう少し複雑なケースです。XML 文書には多数の反復エレメント群 (リスト 5 参照) またはネストされた反復エレメント (リスト 6 参照) が存在し、これらによりデータが 3 つ以上の表に配布されます。対応する関係モデルは次のように説明されます。

  1. 3 つ以上の表が 1 つのヘッダー・テーブルに関連している
  2. 3 つ以上の表がツリー構造にネストされる
  3. 1 と 2 の混合

このような種類の文書を単一の XML 入力によって処理することは困難ですが、さまざまな関連データを同時に単一の文書にカプセル化することが可能なため、これらは最も一般的なケースです。

リスト 5. XML 文書に複数の反復エレメント群がある場合
<A>
	<A_DATA/>
	<B>
		<B_DATA/>
		<B_DATA/>
		<B_DATA/>
	</B>
	<C>
		<C_DATA/>
		<C_DATA/>
	</C>
</A>
リスト 6. XML 文書に複数のネストされた反復エレメント群がある場合
<A>
	<B>
		<B_DATA/>
		<C/>
		<C/>
		<C/>
	</B>
	<B>
		<B_DATA/>
		<C/>
		<C/>
		<C/>
	</B>
</A>

リスト 5 および 6 のような XML 文書を処理するには、Transformer ステージによってリンクされる XML 入力ステージ群を使用して異なるブランチの文書を個別に受け取って処理する方法がシンプルなソリューションとなります。例 3 では、新しい文書 input_cust_cnt.ord.xml(US) (下のリスト 7 も参照) を作成するために例 2 の XML 構造 (input_cust_cnt_xml(US) 参照) に「Orders」が追加されています。リスト 5 の構造に対応して、新しい表の「S_ORDER」 (リスト 8 参照) が作成されます。

リスト 7. Input_cust_cnt_ord.xml
<?xml version="1.0" encoding="UTF-8"?>
<CustomerInfo xmlns:cnt="http://www.ibm.com/schemas/ContactDemo" 
    xmlns="http://www.ibm.com/schemas/SimpleXMLDemo" 
    xmlns:xsd="http://www.w3.org/2001/XMLSchema" 
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
	<CustomerID>0000000003</CustomerID>
	<CompanyName>Eastway software Inc.</CompanyName>
	<Orders>
		<OrderItem>
			<OrderNum>00001</OrderNum>
			<OrderQty>1.00</OrderQty>
			<PartId>A01</PartId>
		</OrderItem>
		<OrderItem>
			<OrderNum>00002</OrderNum>
			<OrderQty>2.00</OrderQty>
			<PartId>A02</PartId>
		</OrderItem>
		<OrderItem>
			<OrderNum>00003</OrderNum>
			<OrderQty>4.00</OrderQty>
			<PartId>A03</PartId>
		</OrderItem>
	</Orders>
	<Contacts>
		<cnt:Contact>
			<cnt:FirstName>Andy</cnt:FirstName>
			<cnt:LastName>Lin</cnt:LastName>
			<cnt:Email>AndyLin@eastway.com</cnt:Email>
		</cnt:Contact>
		<cnt:Contact>
			<cnt:FirstName>Tom</cnt:FirstName>
			<cnt:LastName>Zheng</cnt:LastName>
			<cnt:Email>TomZ@eastway.com</cnt:Email>
		</cnt:Contact>
	</Contacts>
</CustomerInfo>
リスト 8. 「オーダー (order)」表の DDL
CREATE TABLE S_ORDER
(
    ORDER_NUM CHARACTER(5)  PRIMARY KEY,
    CUST_NUM  CHARACTER(10) NOT NULL,
    PART_ID   CHARACTER(3)  NOT NULL,
    QTY       DECIMAL(10,3)
);

このソリューションでは、2 つのフェーズで XML 文書をプロセスするために 2 レイヤーの XML 入力ステージが使用されています。最初のフェーズでは、顧客情報を解析して連絡先およびオーダーの XML チャンクを取得するために XML 入力ステージが使用されています。次にこの 2 つのチャンクを、次のフェーズの 2 つの別々の XML 入力ステージに渡して、「S_CONTACT」表および「S_ORDER」表にデータを抽出します。このジョブ・ダイアグラムは図 33 に示されています。

図33. 例 3 のジョブ・ダイアグラム
図33. 例 3 のジョブ・ダイアグラム
図33. 例 3 のジョブ・ダイアグラム

このソリューション例を開発する一般的なステップには以下が含まれます。

  1. Folder ステージのセットアップ
  2. 3 つの XML 入力ステージの構成
  3. 関連するステージをリンクするためのトランスフォーマーのセットアップ
  4. DB2 出力ステージのセットアップ
  5. コンパイルと実行

これらのステップを詳しく調べて見ましょう。

各ステージの設定方法は前出のセクションで既に説明されています。そこで、このセクションではこれらの詳細を省き、注意を必要とする部分のみに注目します。それはこれらの XML 入力ステージの「列 (Columns)」の設定です。まず、XML メタデータ・インポーター (図 7 参照) を通して XML 表定義をインポートします。次に、それらの適用時に列のリストおよび定義の XPath を変更します。

最初の XML 入力ステージは「XML_Cust」と名付けられています。図 34 に示されているように、「S_CUST」表と、<Orders/> および <Contacta/> の XML チャンクに対して「CustomerID」および「ComapanyName」の各フィールドを抽出するために、その出力リンク列をセットアップします。

図34. 「XML_Cust」の「出力 (Output)」の「列 (Columns)」タブ
図34. 「XML_Cust」の「出力 (Output)」の「列 (Columns)」タブ
図34. 「XML_Cust」の「出力 (Output)」の「列 (Columns)」タブ

注: 特にこのケースの場合、XML チャンクを抽出するためには、例えば「/ns1:CustomerInfo/ns1:Orders」のように、XPath 式の末尾に /text() を付加しないでください。そうすれば、列はそのエレメントの全 XML 構造を返し、他のステージでの次段階のプロセスが容易になります。

XML チャンクを受け取って、顧客表を参照しながらレコードを生成するには、図 35 のように入力列に CUST_NUM フィールドおよび XML チャンク・フィールドを取得するために他の 2 つの XML 入力ステージを手動で設定する必要があります。

図35. 「XML_Contact」の「入力 (Input)」の「列 (Columns)」タブ
図35. 「XML_Contact」の「入力 (Input)」の「列 (Columns)」タブ
図35. 「XML_Contact」の「入力 (Input)」の「列 (Columns)」タブ

「XML_Contact」ステージおよび「XML_Order」ステージの入力列の準備が整ったら、トランスフォーマーの「Div_branches」を使用してそれらを接続します。

図36. 「Div_branches」ステージでのデータの配布
図36. 「Div_branches」ステージでのデータの配布
図36. 「Div_branches」ステージでのデータの配布

次に「XML_Contact」ステージおよび「XML_Order」ステージの出力列がそれぞれ設定されます。

注: XML 入力ステージと DB2 ステージの間には、出力フィールドを DB2 列にマップするためのトランスフォーマーは存在しません。そこで XML 入力ステージの出力列名 (「XML_Contact」および「XML_Order」) がデータベース表の名前と正確に一致することを確認する必要があります。一度すべてを設定すると、DB2 ステージの入力列が自動的にロードされます。表定義を再ロードして DB2 ステージの入力列を「上書きしない」でください。上書きすると、前述の XML 入力ステージの XPath が失われることになります。

図37. 「XML_Contact」ステージの「出力 (Output)」の「列 (Columns)」
図37. 「XML_Contact」ステージの「出力 (Output)」の「列 (Columns)」
図37. 「XML_Contact」ステージの「出力 (Output)」の「列 (Columns)」
図38. 「XML_Order」ステージの「出力 (Output)」の「列 (Columns)」
図38. 「XML_Order」ステージの「出力 (Output)」の「列 (Columns)」
図38. 「XML_Order」ステージの「出力 (Output)」の「列 (Columns)」

注: 「CUST_NUM」フィールドは 2 つの XML 入力ステージの入力列および出力列の両方に存在します。このフィールドは、入力リンクから出力リンクへ直接渡される「パススルー」フィールドです。

すべてのステージのセットアップ後にジョブを実行すると、図 39 のようなビューが正常に表示されるはずです。

図39. XML ファイルが 3 つの表に正常にロードされた場合
図39. XML ファイルが 3 つの表に正常にロードされた場合
図39. XML ファイルが 3 つの表に正常にロードされた場合

DB2 のデータを検証します。

リスト 9. 表データを検証する SQL
SELECT * FROM S_CUST    cust WHERE cust.CUST_NUM='0000000003';
SELECT * FROM S_CONTACT cnt  WHERE cnt.CUST_NUM='0000000003';
SELECT * FROM S_ORDER   ord  WHERE ord.CUST_NUM='0000000003';
図40. リスト 9 の SQL の結果
図40. リスト 9 の SQL の結果
図40. リスト 9 の SQL の結果

第 III 部.入出力データを使用して Web サービスにアクセスする

Web サービス・パックを使用すると、DataStage は DataStage サーバーのジョブ内で Web サービスの操作を容易に行うことができます。Web サービス・パックにより DataStage に 2 つのリアルタイム・ステージが追加されます。Web サービス・クライアント・ステージおよび Web サービス・トランスフォーマー・ステージです。Web サービスをデータ・ソースまたはデータ・ターゲットのいずれかとして動作させる場合、Web サービス・クライアント・ステージが使用されます。この場合、単一の Web サービス操作では入力リンクまたは出力リンクのどちらか 1 つのみが必要となります。しかし、Web サービスのトランスフォーマー・ステージには入力リンクおよび出力リンクの両方が含まれており、データ・トランザクションの観点においてリモート・サービスとの対話が可能です。Web サービス・パックにより、DataStage で Web サービスのルーチンもサポートできるようになりますが、これらは Transformer ステージにおいてトランスフォーマー機能として使用されます。Web サービス・トランスフォーマーは DataStage においてより一般的で柔軟な Web サービスの適用方法であるため、本資料の第 III 部では例として Web サービス・トランスフォーマーのみを使用し、説明します。Web サービス・クライアント・ステージおよび Web サービス・ルーチンはたいへんシンプルで、「Web services Pack Designer Guide」 (資料参照) に詳しく記述されています。

Web サービス・トランスフォーマーをソリューションに統合するには、WSDL Web サービス記述ファイルのインポート、Web サービス・トランスフォーマーのソリューションへの追加、および Web トランスフォーマーにおけるターゲット・サービスの選択を行う必要があります。次にデータをフィードし、データを抽出してファイルやデータベースに保存するなど、出力を適切な方法で処理します。次の例で、実際のケースにおいてこの機能を説明しましょう。

例 4. データベース表のキーワードで Google 照会を行い、応答を別の表に保存する

例 4 の概要

典型的で一般的なシナリオであるため、GoogleSearchをターゲット・サービスとして選択しています。すなわち、照会をサブミットすると、レコードが返されます。その上、Web サービスは既に使用可能で自由に使用できるようになっています。

GoogleSearch サービスは Google SOAP Search API プロジェクト (資料 参照) にあり、次の 3 つの操作を含みます。doGoogleSearch、doGetCachedPage、および doSpellingSuggestion です。この例では、doGoogleSearch の操作を使用します。サービスにアクセスする前に、リクエスターを識別するために要求メッセージに含めて送信されるライセンス・キーを取得するために、無料のアカウント (Web ページ・アドレス) に登録する必要があります。doGoogleSearch 操作のトランザクションでは、ライセンス・キー付きの照会が Google に送信され、ヒット項目がいくつか含まれた反復構造の応答メッセージが返されます。

注:DataStage 7.5.1A の Web サービス・トランスフォーマーでは、応答内の反復エレメントを解析して複数行のレコードに挿入することができないという制約があります。各入力行は、1 行分の出力データの生成のみが可能です。幸い、Web サービス・トランスフォーマーは XPath を使用して応答文書からのデータの抽出およびXML チャンク出力のサポートが行えます。そのため、元のメッセージから反復構造を含む XML チャンクを抽出し、それらを次の 1 つまたは複数の XML 入力ステージに渡すことができます。このような方法で、制約を回避し、より複雑な構造もプロセスできます。

例 4 のターゲット・ソリューションは、DB2 表から照会キーワードを抽出し、それらを Web サービス・トランスフォーマーにフィードします。Web サービス・トランスフォーマーは Web サービスを起動し、後続の XML 入力ステージに直接応答メッセージを出力します。最後に、結果を別の DB2 表に挿入します。このジョブ・ダイアグラムは図 41 に示されています。

図41. 例 4 のジョブ・ダイアグラム予想図
図41. 例 4 のジョブ・ダイアグラム予想図
図41. 例 4 のジョブ・ダイアグラム予想図

この例では、ジョブのセットアップのために以下を含むいくつかのステップが行われます。

  1. WSDL ファイルからのターゲット・サービスのインポート
  2. Web サービス・トランスフォーマーのセットアップ
  3. XML 入力ステージのセットアップ
  4. DB2 表の作成と、入出力のためのデータベース・ステージのセットアップ
  5. コンパイルと実行

これらのステップを詳しく調べて見ましょう。

ステップ 1. WSDL ファイルからのターゲット・サービスのインポート

リポジトリー・ビューの「テーブル定義 (Table Definition)」を右クリックし、「インポート (Import)」 > 「Web サービス WSDL 定義 (Web Services WSDL Definitions)」 (図 4 参照) の順に選択します。Web サービス・メタデータ・インポーターが有効になります (図 42 参照)。これを使用して WSDL ファイルをロードします。ターゲットの操作を選択したら、「インポート (Import)」ボタンをクリックして定義を保存します。

図42. Web サービス・メタデータ・インポーター
図42. Web サービス・メタデータ・インポーター
図42. Web サービス・メタデータ・インポーター

インポートされた操作に対して複数の表定義が生成されます。doGoogleSearch も例外ではありません。以下の表定義が自動的に作成されるはずです。

  • Info_WS:URI、ポート名などの Web サービス・メタデータ
  • doGoogleSearch_IN:入力パラメーター
  • doGoogleSearch_MSGIN:入力メッセージのメタデータ
  • doGoogleSearch_MSGOUT:出力メッセージのメタデータ
  • doGoogleSearch_OP:操作メタデータ
  • doGoogleSearch_OUT:出力パラメーター

ステップ 2. Web サービス・トランスフォーマーのセットアップ

Web サービス・トランスフォーマーは、入出力データのデータ構造が完全に依存しているため、ソリューションの中心となるコンポーネントです。そのため、Web サービス・トランスフォーマーは高い優先順位に置かれます。Web サービス・トランスフォーマーの「ステージ (Stage)」ページでは、Web サービスの操作のみを構成すれば GoogleSearch のようなオープンな公開サービスに基本的な機能でアクセスできるため、この例ではこの点について説明します。

注: さらに、「ステージ (Stage)」ページでは、より高度なアプリケーションのためのプロキシー、HTTP AUTH、HTTPs、Web サービス・パラメーター他の設定など、さらに多くのオプションが提供されます。

Web サービス・トランスフォーマーに対するターゲット操作を構成するには、「ステージ (Stage)」ページの「Web サービス操作の選択 (Select Web Service Operation)」をクリックし、図 43 のように Web サービスのブラウザーのターゲット操作をダブルクリックします。

図43. Web サービス操作の選択
図43. Web サービス操作の選択
図43. Web サービス操作の選択

「入力 (Input)」ページの「入力メッセージ (Input Message)」タブに切り替えます (図 44 参照)。

図44. 入力メッセージ・メタデータのロード
図44. 入力メッセージ・メタデータのロード
図44. 入力メッセージ・メタデータのロード

選択した Web サービス操作で自動的にメタデータ、名前空間、および列をロードするには、「メッセージ情報のロード (Load Message Information)」をクリックします。

図45. メタデータがロードされると入力列もロードされる
図45. メタデータがロードされると入力列もロードされる
図45. メタデータがロードされると入力列もロードされる

図 45 に示された列は、ライセンス・キー (key)、照会キーワード (q)、およびその他多くの構成パラメーターなど、doGoogleSearch 操作で Google にフィードされるべき実パラメーターです。

出力リンクの設定は入力リンクに似ており、「出力 (Output)」ページの「出力メッセージ (Output Message)」タブにメタデータをロードします。例 4 のステップ 1 で説明したように、応答内で反復エレメントを処理するには XML 入力ステージが使用されます。この Web サービス・トランスフォーマーの出力リンクは、応答の SOAP 文書全体を出力するためにカスタマイズする必要があります。図 46 では、「RS_XML」列に有効な XML 文書形式で応答が含まれています。

図46. 「GoogleWST」ステージのカスタマイズされた出力列
図46. 「GoogleWST」ステージのカスタマイズされた出力列
図46. 「GoogleWST」ステージのカスタマイズされた出力列

ステップ 3. XML 入力ステージのセットアップ

XML 入力ステージの構成は前の例で既に説明されています (例 2 のステップ 2 参照)。ここで唯一異なる点は出力リンクの表定義ですが、これはインポートされた XML 表定義からではなく、「doGoogleSearch_OUT」と名付けられた Web サービスの出力表定義からのものです。この表定義には多くの列が含まれており、応答メッセージ内で定義されたすべてのデータ・エレメントを表しています。この例では次にあげる一部のデータ・エレメントのみを使用します: URL、snippet、title、cached size、related information present、host name、およびテスト目的のための照会キーワードそのもの。

図47. 「RS_parsing」 XML 入力ステージの「出力 (Output)」列
図47. 「RS_parsing」 XML 入力ステージの「出力 (Output)」列
図47. 「RS_parsing」 XML 入力ステージの「出力 (Output)」列

注: URL 列が「Key」列に設定されているのは、返された各検索ヒットを区別することができるためです。

ステップ 4. DB2 表の作成と、入出力のためのデータベース・ステージのセットアップ

ID フィールドおよびキーワード・フィールドのみを含む簡単な照会表である「S_GOOGLE_Q」と、以前に選択したすべての応答列を網羅する「S_GOOGLE_RS」という名前の結果表を作成します。

リスト 10. 照会表および応答表用の DDL
CREATE TABLE S_GOOGLE_Q
(
Q_ID                        INTEGER
GENERATED  ALWAYS AS IDENTITY( START WITH 1, INCREMENT BY 1)
                            PRIMARY KEY,
KEYWORD VARCHAR(255)
);

CREATE TABLE S_GOOGLE_RS
(
R_ID                        INTEGER
GENERATED  ALWAYS AS IDENTITY( START WITH 1, INCREMENT BY 1)
                            PRIMARY KEY,
URL                         VARCHAR(255) NOT NULL,
CACHEDSIZE                  VARCHAR(255) NOT NULL,
HOSTNAME                    VARCHAR(255) NOT NULL,
RELATEDINFORMATIONPRESENT   VARCHAR(255) NOT NULL,
SNIPPET                     VARCHAR(255) NOT NULL,
TITLE                       VARCHAR(255) NOT NULL,
SEARCHQUERY                 VARCHAR(255) NOT NULL
);

2 つの DB2 表のために、「REQUESTS」および「RESULTS」という 2 つの DB2 ステージをセットアップします。

「REQUESTS」 DB2 ステージでは、doGoogleSearch の操作に必要なすべてのフィールドが列に含まれていなければなりません。Web サービスの表定義「doGoogleSearch_IN」から表定義もロードされます。

注: 図 45 に示されるように「SQL タイプ (SQL type)」列が「unknown」の場合、それらに対して「VarChar」のような通常のタイプを割り当てる必要があります。

図48. 「REQUEST」 DB2 ステージの出力列
図48. 「REQUEST」 DB2 ステージの出力列
図48. 「REQUEST」 DB2 ステージの出力列

SQL (SQL) 」タブ内の「カスタム SQL ステートメントを入力 (Enter custom SQL statement)」を選択し、Web サービスの操作に関する他の入力パラメーターの定数列を含め、「S_GOOGLE_Q」表からキーワードを抽出する照会を入力します (図 49 参照)。

図49. データの準備のためにカスタム SQL ステートメントを使用する
図49. データの準備のためにカスタム SQL ステートメントを使用する
図49. データの準備のためにカスタム SQL ステートメントを使用する

「REQUEST」ステージを「GoogleWST」ステージに接続するためにはトランスフォーマーを使用する必要があります。使用しない場合、2 つのステージで列名が正確に一致してもジョブは開始されません。これは Web サービスの表定義における「Unknown」 のSQL タイプが原因である可能性があります。

図50. 「COL_mapping」トランスフォーマーの設定
図50. 「COL_mapping」トランスフォーマーの設定
図50. 「COL_mapping」トランスフォーマーの設定

今度は「RESULTS」 DB2 ステージを構成します。サーバー情報を構成し、ターゲット表の選択のみで行えます。XML 入力ステージ「RS_parsing」 (図 41 参照) の表定義内の列名は、データベース表内の名前と正確に一致しています。insert ステートメントの作成に入力列名を使用しているため、DB2 ステージではこれらの列を DB2 表に自動的に挿入できます。

ステップ 5. コンパイルと実行

上述の設定が完了すれば、ジョブはコンパイルして実行できます。ただし、オンライン・サービスにアクセスする前に、照会表にキーワードをいくつか準備する必要があります。たとえ「Beijing」、「space shuttle」、および「iguana」という 3 つのキーワードが使用されるとします。(図 51 参照。)

図51. Google 検索が正常に実行された場合
図51. Google 検索が正常に実行された場合
図51. Google 検索が正常に実行された場合

図 51 では、結果表にはキーワードごとに 10 個ずつ、30 個のレコードが挿入されたことが分かります。「S_GOOGLE_RS」表を調べてデータを検証します。

リスト 11. Google から返された結果を調べる SQL
SELECT searchquery, url, hostname FROM S_GOOGLE_RS;
図52. リスト 11 の SQL の結果
図52. リスト 11 の SQL の結果
図52. リスト 11 の SQL の結果

追記:ユーザー定義のメッセージを使用して Web サービスを起動する

時として、入力メッセージがたいへん複雑な場合、またはメッセージの本体が既に使用可能な場合があります。そのような場合、入力として表データを使用することが最適なソリューションとはならないことがあります。

Web サービス・トランスフォーマーはユーザー定義のメッセージをサポートし、XML 文書をメッセージ本体として受け入れます。この機能によりさらなる柔軟性が提供されます。手動によるメッセージ文書の入力や、データベースから複雑な XML 文書を作成するためのサード・パーティーのプログラムの使用など、要求メッセージの準備に適した方法を選択できます。

ユーザー定義によるメッセージの使用方法を示すために、例 4 のジョブに少し変更を加え、Folder ステージを使用して XML ファイル (googleReq.xml(US)) を Web サービス・トランスフォーマーにフィードしてみましょう。この新しいジョブは図 53 に示されています。

図53. ユーザー定義のメッセージを使用した Web サービス
図53. ユーザー定義のメッセージを使用した Web サービス
図53. ユーザー定義のメッセージを使用した Web サービス
図54. Web サービス・トランスフォーマー・ステージのためのユーザー定義のメッセージ設定
図54. Web サービス・トランスフォーマー・ステージのためのユーザー定義のメッセージ設定
図54. Web サービス・トランスフォーマー・ステージのためのユーザー定義のメッセージ設定

おわりに

XML および Web サービス・パックは機能性の高い便利なツールキットです。本資料では、DB2 表からの XML 文書のパブリッシングの方法、XML 文書からのデータの抽出方法、また主要な手順と分析を含めた、サンプルを使用しての Web サービスへのアクセス方法について説明しました。

DataStage では他にも多くの便利なコンポーネントや、それらを直感的に組み合わせて柔軟性の高い統合ソリューションを構築する方法を提供します。

実践においては、DataStage の XML および Web サービスの機能、さらに他の DataStage コンポーネントについて、より興味深いアプリケーションを必ず見つけられるでしょう。

※本資料は Transform and integrate data using WebSphere DataStage XML and Web services packs (2007年3月29日)(US)を翻訳したものです。


ダウンロード可能なリソース


関連トピック

  • developerWorks InfoSphere resource page (US):資料およびチュートリアルを読み、IBM Information Server のスキルを高めるために他の資料にアクセスできます。
  • Google Soap Search API(US)」 プロジェクト:Google Search Web サービスについての詳細を学びます。
  • developerWorks Information Management zone:Information Management についての詳細を学びます。技術資料、使用方法に関する資料、教育資料、ダウンロード、製品情報などを検索できます。
  • 次期開発プロジェクトの構築には IBM trial software(US) をご利用ください。developerWorks から直接ダウンロードしてご利用いただけます。

コメント

コメントを登録するにはサインインあるいは登録してください。

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Information Management, XML, SOA and web services, WebSphere
ArticleID=456992
ArticleTitle=InfoSphere DataStage XMLおよび Web サービス・パックを使用したデータの変換と統合
publish-date=12182009