c copyright ibm corp 2011 2016 fileibm tririga application platform バージョン 3 リリース...

IBM TRIRIGA Application Platformバージョン 3 リリース 5.2

IBM TRIRIGA ApplicationPlatform のアプリケーション構築:パフォーマンス・フレームワーク

IBM

注記

本書および本書で紹介する製品をご使用になる前に、 83 ページの『特記事項』に記載されている情報をお読みください。

本書は、IBM TRIRIGA Application Platform バージョン 3 リリース 5 モディフィケーション 2 および新しい版で明記されていない限り、以降のすべてのリリースおよびモディフィケーションに適用されます。

お客様の環境によっては、資料中の円記号がバックスラッシュと表示されたり、バックスラッシュが円記号と表示されたりする場合があります。

原典： IBM TRIRIGA Application PlatformVersion 3 Release 5.2Application Building for theIBM TRIRIGA Application Platform:Performance Framework

発行：日本アイ・ビー・エム株式会社

担当：トランスレーション・サービス・センター

© Copyright IBM Corporation 2011, 2016.

目次

第 1 章パフォーマンス・フレームワーク 1

第 2 章データ構造 . . . . . . . . . . 3アーキテクチャーの概要 . . . . . . . . . . 3ファクト・テーブル . . . . . . . . . . . . 4

ファクト・テーブルおよび関連するディメンションの例 . . . . . . . . . . . . . . . . 7

メトリックの構造 . . . . . . . . . . . . . 8ETL 統合 . . . . . . . . . . . . . . . 10

ETL 統合アーキテクチャー . . . . . . . . 10ETL 統合のプロセス . . . . . . . . . . 12ETL 統合のための前提条件のセットアップ . . . 15ETL 変換の定義および保守 . . . . . . . . 16

Pentaho Spoon での ETL の使用 . . . . . 16IBM Tivoli Directory Integrator 構成エディターでの ETL の使用 . . . . . . . . . . 35

ETL 変換の実行 . . . . . . . . . . . . 60ETL ジョブ項目、ジョブ・グループ、およびジョブ・スケジューラー . . . . . . . . 60ETL ジョブ項目の作成または変更 . . . . . 60ジョブ・グループの追加または変更 . . . . 63ジョブ・スケジューラーの作成または変更 . . 63

変換オブジェクトのカスタマイズ . . . . . . 65変換ビジネス・オブジェクト、フォーム、およびワークフローの定義 . . . . . . . . . 66Content Manager への変換 XML の保存 . . 66ワークフロー・ランタイムの構成 . . . . . 66ETL カスタム・ワークフロー・タスク仕様の実行 . . . . . . . . . . . . . . . 67

第 3 章メトリック . . . . . . . . . 69測定基準レポート . . . . . . . . . . . . 69キー・メトリック . . . . . . . . . . . . 70フォーム・メトリック . . . . . . . . . . . 70

データのフィルタリング . . . . . . . . . 71サブレポート . . . . . . . . . . . . . 72

第 4 章階層フラット化ツール . . . . . 73フラット階層 . . . . . . . . . . . . . . 73

フラット階層の例 . . . . . . . . . . . 74階層構造マネージャー . . . . . . . . . . . 76

階層構造へのアクセス . . . . . . . . . . 76データ階層の作成 . . . . . . . . . . . 76フォーム階層の作成 . . . . . . . . . . 76

第 5 章ファクト・テーブル . . . . . . 79サポートされるファクト・テーブルおよびメトリックのリスト . . . . . . . . . . . . . . 79特殊なステージング・テーブルおよび ETL を必要とするファクト . . . . . . . . . . . . . 79従属 ETL . . . . . . . . . . . . . . . 80

特記事項 . . . . . . . . . . . . . . 83商標 . . . . . . . . . . . . . . . . . 85製品資料に関するご使用条件 . . . . . . . . 85IBM オンラインでのプライバシー・ステートメント 86

© Copyright IBM Corp. 2011, 2016 iii

iv © Copyright IBM Corp. 2011, 2016

第 1 章パフォーマンス・フレームワーク

IBM® TRIRIGA® ワークプレース・パフォーマンス管理および IBM TRIRIGA 不動産環境維持は、施設および不動産に関連するプロセスを企業が戦略的に計画、管理、評価、改善する上で役立つ、実行可能なソリューションを提供します。

IBM TRIRIGA パフォーマンス・フレームワークは、TRIRIGA ワークプレース・パフォーマンス管理および TRIRIGA 不動産環境維持内で管理されます。これらには以下のコンポーネントが含まれています。

v データ変換サービスおよびファクト・テーブル・ロード・サービス

v データ・モデラーを使用するメトリック・ビルダー

v メトリック照会エンジン

v 測定基準レポートを作成するための拡張レポート・マネージャー

v メトリック・スコアカードをレンダリングする拡張ポータル機能

v 事前に作成されている一連のメトリック、レポート、およびアラート。これらにより、TRIRIGA 内でサポートされている多くの役割の生産性が大幅に向上します

© Copyright IBM Corp. 2011, 2016 1

2 © Copyright IBM Corp. 2011, 2016

第 2 章データ構造

TRIRIGA は、ビジネス・オブジェクト・テーブルからファクト・テーブルにデータを移動するためのメカニズムとして抽出、変換、およびロード (ETL) 開発環境を使用します。メトリック、レポート、スコアカードなどのパフォーマンス基準を示すには、報告ツールが処理できるファクト・テーブルやフラット階層テーブルの形にデータを変換する必要があります。

アーキテクチャーの概要TRIRIGA ワークプレース・パフォーマンス管理のソース・データは、TRIRIGA アプリケーション・データベース、外部の財務システムからインポートされた財務サマリー・データ、および外部の建物管理システムからインポートされた建物メーターのデータから取り込まれます。

ETL テクノロジーを使用して、ソース・データがファクト・テーブルにロードされます。ファクト・テーブルとディメンション・テーブルは、TRIRIGA アプリケーションと同じデータベース・リポジトリーに格納されています。ファクト・テーブルには、ファクトと呼ばれる数値データが格納されます。この数値データは、TRIRIGA ワークプレース・パフォーマンス管理のメトリック値の計算に使用されます。ファクト・テーブルの各行は、1 つ以上の関連ビジネス・オブジェクト、分類、またはファクトをグループ化およびフィルタリングするリストを参照します。これらの行はディメンションと呼ばれます。

メトリック照会エンジンがファクト・テーブルとディメンション・テーブルに対する照会を実行します。ユーザーが階層ディメンション内を上下に移動すると、メトリック照会によってメトリック値が迅速に再計算されます。

以下の図に、このアーキテクチャーを構成する個々のレイヤー、およびレイヤー間のデータ・フローを示します。


ファクト・テーブルファクト・テーブルは、測定基準レポート内のメトリックを計算するために使用されるデータを保管します。ファクト・テーブルへのデータの取り込みは、ETL 変換によってのみ行われる。ビジネス・オブジェクトをファクト・テーブルとして指定するには、データ・モデラーから、ファクト・テーブル・ビジネス・オブジェクト定義で「外部管理」フラグを設定します。

IBM TRIRIGA Application Platform では、各ファクト・テーブルは、以下のエレメントの一部またはすべてを含む特殊なビジネス・オブジェクトとして実装されます。


表 1. ファクト・テーブル

ファクト・テーブルのエレメント説明

階層ディメンション各階層ディメンションは、階層モジュール(建物、サービス・コスト・コード、市区町村など) に属するビジネス・オブジェクトのロケーター・フィールドです。階層ディメンションごとに、対応する階層構造によって測定基準レポートがサポートされています。階層ディメンションは、モジュール内の一部またはすべてのビジネス・オブジェクトを参照できます。できる限り具体的に入力してください。特定のビジネス・オブジェクトをターゲットとすることで、レポートの細分度が向上します。各階層ディメンションで、対応する階層構造が定義されている必要があります。階層構造は、測定基準レポートのドリル・パスに使用されます。

非階層ディメンション各非階層ディメンションは、非階層モジュール (タスク、人など) に属するビジネス・オブジェクトのリスト・フィールドまたはロケーター・フィールドのいずれかです。

数値ファクト・フィールド数値ファクト・フィールドは、標準数値フィールドです (単位 (UOM) プロパティーを含む場合と含まない場合があります)。数値ファクト・フィールドは、以下のいずれかのタイプの特性を備えています。

v 加法: すべてのディメンションにわたって合計可能です。

v 準加法: 一部のディメンションのみで合計可能です。例えば、毎月収集される特定の建物の総人数を、四半期ごとに合計することはできません。これは、四半期ごとに合計しても四半期の総人数が算出されないためです。ただし地域別に合計することは可能です。したがって、このファクトは時間的には非加法です。

v 非加法: どのディメンションにおいても合計できません。例えば、比率は合計できないため、非加法ファクトです。また、複数のグレーンからの値を含むフィールドも非加法です。

単位フィールド単位 (UOM) フィールドは、入力されたそれぞれのローカル単位で収集されます (ただしエリア・フィールドを除きます)。

エリア・フィールドエリア・フィールドは、ヤード・ポンド法(平方フィートなど) およびメートル法 (平方メートルなど) の両方の値で収集されます。

第 2 章データ構造 5

表 1. ファクト・テーブル (続き)

ファクト・テーブルのエレメント説明

通貨フィールド通貨フィールドは、基本通貨を使用して収集されます。通貨換算は行われません。

現行期間期間ディメンションは、1 つのファクト・レコードを適用できる日付/期間を特定するために使用される特殊なディメンションです。これはほとんどの場合、データの収集期間です。期間ディメンションがドリル・パスまたはフィルターとして使用されない場合は、収集期間を示すために使用されるディメンションを示すために、triCapturePeriodTX フィールドにデータを取り込む必要があります。このフィールドが存在する場合、そのディメンションに対応するビジネス・オブジェクトに、 triCurrentBL という名前のフィールドが含まれている必要があります。このフィールドは、現行期間を反映するディメンション・レコードにフラグを設定するために使用されます。これらのレコードは測定基準レポートの結果セットのフィルタリングに使用されます。

会計期間会計期間分類は、ETL プロセスがファクト・レコードの収集期間を定義するために使用します。これは測定基準レポートの主要期間ディメンションです。階層内の各レベルに対して 1 つのレコードを持ち、異なる収集頻度に基づいたデータが含まれている複数の異なるファクト・テーブルを持つことが可能であるため、各レベルに現行期間のフラグを設定することができます。例えば年/四半期/月の階層が会計期間分類で作成される場合、現在の年、現在の四半期、または現在の月を特定できます。特殊なETL ジョブ・タイプによって、このデータの同期を保持するためのワークフローが提供されます。原則として、1 つのファクト・テーブルのデータはすべて、同一の期間グレーン/レベル(年、四半期、月) で収集する必要があります。特定のファクト・テーブルのデータの収集後に期間グレーン/レベルを変更した場合、そのファクト・テーブルのすべてのデータを正しいグレーン/レベルに修正するか、または切り捨て/削除する必要があります。

ファクト・テーブル・ビジネス・オブジェクト

ビジネス・オブジェクトを、対応するファクト・テーブルを持つオブジェクトとして特定するには、ビジネス・オブジェクトの作成時にビジネス・オブジェクトのプロパティーで「外部管理」ラジオ・ボタンを選択します。


ヒント: 標準 TRIRIGA ソフトウェアに付属のファクト・ビジネス・オブジェクト、ファクト・テーブル、および ETL スクリプトは削除も変更もしないでください。代わりに、既存のファクト・ビジネス・オブジェクト、ファクト・テーブル、またはスクリプトを変更するには、コピーを作成してそのコピーの名前を変更し、必要に応じてコピーを調整してください。

ファクト・テーブルおよび関連するディメンションの例ファクト・テーブルおよびディメンション・テーブルは、データウェアハウス設計のスター・スキーマ方式を使用して作成されます。これらのテーブルは TRIRIGAアプリケーションと同じデータベース・リポジトリーに格納されます。

次の図に、TRIRIGA ワークプレース・パフォーマンス管理の事前構成ファクト・テーブルの 1 つの例を示します。

この図には、5 つのファクト (スペース・キャパシティー、合計人数、残存キャパシティー、スペース面積、および割り振られた面積) からなるスペース・ファクトが示されています。スペース・ファクトは、7 つのディメンション (スペース、建物、ロケーション、地域、スペース・クラス、建物クラス、および建物保有権) も参照します。ファクト・テーブルのディメンションによって、ファクトが対応するディメンション・テーブルにリンクされます。ディメンションには、階層ディメンション (ロケーション、地域など) と非階層ディメンション (スペース、建物など)があります。


フラット階層テーブルは、選択されているビジネス・オブジェクトの子を特定するために使用されます。フラット階層テーブルにより、メトリック照会エンジンが階層モジュール、ビジネス・オブジェクト、および分類を参照できるようになります。

以下の表に、地域に基づくフラット階層の例を示します。

表 2. 地域フラット階層の例

SPEC_ID レベルの番号レベル 1SPEC_ID

レベル 2SPEC_ID

レベル 3SPEC_ID

レベル 4SPEC_ID

グローバル 1 グローバル N/A N/A N/A

北アメリカ 2 グローバル北アメリカ N/A N/A

EMEA 2 グローバル EMEA N/A N/A

APAC 2 グローバル APAC N/A N/A

米国 3 グローバル北アメリカ米国 N/A

カナダ 3 グローバル北アメリカカナダ N/A

ネバダ 4 グローバル北アメリカ米国ネバダ

テキサス 4 グローバル北アメリカ米国テキサス

この例では、「北アメリカ：の子である地域をすべて特定するには、最初に、地域フラット階層の例の表で、1 番目の列 (SPEC_ID) で「北アメリカ」を見つけます。「北アメリカ」のレベル番号 (2) を使用して、フィルター列を決定できます。SPEC_ID とレベル番号を使用することで、「北アメリカ」より下に位置する子、孫、およびすべてのレベルの地域を特定できます。

メトリックの構造TRIRIGA ワークプレース・パフォーマンス管理の機能は、メトリック・ファクトを収集することと、基準レポートを作成できるようにすることに重点を置いています。

TRIRIGA のメトリックの大部分は多次元です。つまり、同じメトリックが、全体的なサマリー表示 (組織およびポートフォリオ全体の面積当たりの運用コスト合計など) に加えて、さまざまなディメンションまたはフィルターをドリルダウンすることで、役割固有の表示 (北米事業部が管理している施設の北米事業部の面積当たりの運用コスト合計など) も示します。

メトリックは、処理のパフォーマンスを測定するもので、アクション可能な結果を特定することができます。通常、その基準は、比率、パーセンテージ、またはスコアです。メトリックには、目標、しきい値、アクションの条件、アカウンタビリティー、およびアクション・タスク機能があります。

TRIRIGA ワークプレース・パフォーマンス管理には、以下のタイプのメトリックがあります。これらは、「キー・メトリック」ポータル・セクションの「スコア・カード・カテゴリー」になっています。

顧客メトリック顧客満足度を測定します


ファイナンシャル・メトリック財務パフォーマンスを測定します

ポートフォリオ・メトリック運用による使用状況と資産のライフサイクルの正常性を測定します

処理メトリック処理の効率と有効性を測定します

報告および分析メトリック特定のパフォーマンス・メトリックを分析します

さらに、TRIRIGA 不動産環境維持には以下のタイプのメトリックもあります。

環境環境イニシアチブのパフォーマンスを測定します

建物メーターメーターおよびセンサーによって報告される建物の特性を測定します

以下の全体的なプロセス・ダイアグラムは、メトリックがどのようにして定義、収集され、ユーザーに表示されるのかを示したものです。

TRIRIGA データベースが、ファクト・テーブルにロードする運用データを収集するための主なデータ・ソースです。オプションで、他のソースからデータを抽出して、ファクト・テーブルにロードすることもできます。

各ファクト・テーブルには、各メトリック・カテゴリーの最下位レベルの集合データ (「建物」レベルなど) が保管されます。ファクト・テーブルは、効率化のために、複数の TRIRIGA テーブルのデータ・エレメントを含む非正規化 (フラット化)されたテーブルになっています。

ディメンション・テーブルには、各メトリックのディメンションが保管されます。ディメンションは、効率化のために、別のテーブルに保管されています。ファクト・テーブルには、各ディメンションのキー (仕様 ID) が保管されています。ディメンション・テーブルは、フラットな階層テーブルである場合と、TRIRIGA のビジネス・オブジェクト・テーブルである場合があります。


メトリック処理エンジン (分析/報告ツール) は、ファクト・テーブルに保管されたデータと、メトリックのセットアップ・データおよびディメンション・データを使用して、メトリックを生成します。

メトリック・データは、通知、アクション、およびアラートとともに、メトリックのセットアップ・テーブルで定義されたさまざまな形式 (レポート、照会、グラフなど) の役割ベースのポータルで、ユーザーに表示されます。ユーザーは、特定のオブジェクトやドリル・パスをドリルダウンすることで、表示されたメトリック・データをさらに詳細に分析できます。

測定基準レポートは、メトリックのファクト・テーブルを基準として作成されます。これらのファクト・テーブルは、データ・モデラーを使用して実装されますが、それがメトリック・オブジェクトであることを示す固有のオブジェクト・タイプによって識別されます。メトリック・オブジェクトへのデータの設定は、ETL 開発環境を使用して行います。この点は、メタデータ・レイヤーを通じて更新される他のすべてのオブジェクト・タイプと異なります。ETL 処理のスケジューリングは、TRIRIGA システム内からジョブ・スケジューラーを使用して制御します。

ETL 統合TRIRIGA は、Tivoli® Directory Integrator の ETL 開発環境の構成エディター、または Pentaho の ETL 開発環境の Spoon を使用して、変換 XML ファイルを生成します。これらの変換を API 経由で実行すると、データがソース・テーブルから宛先テーブルに移されます。

ETL 統合アーキテクチャーTRIRIGA では、ファクト・テーブルにデータを取り込む ETL スクリプトを作成するために、2 つの ETL 環境が使用されます。この 2 つの ETL 開発環境は、TivoliDirectory Integrator 構成エディターと Pentaho データ統合ツール Spoon です。ETL 開発環境では、TRIRIGA ビジネス・オブジェクト・テーブルからデータを読み取り、結果をファクト・テーブルのファクト列とディメンション列にマップおよび変換する SQL 照会を作成できます。

ソース・データ・レイヤー、ETL 開発環境レイヤー、および TRIRIGA ワークプレース・パフォーマンス管理データ・モデル・レイヤー間でのデータ・フローを以下の図に示します。


ETL ジョブ項目は、ファクト・テーブルへのデータの取り込みに使用される ETLスクリプトを参照するビジネス・オブジェクトです。

TRIRIGA ワークプレース・パフォーマンス管理は標準 TRIRIGA ApplicationPlatform ツールを使用します。

アプリケーション・プラットフォーム・ツールを以下の図に示します。


ETL 統合のプロセスソース・テーブルから宛先テーブルにデータを移動するには、Tivoli DirectoryIntegrator 構成エディターまたは Pentaho Spoon のいずれかで開発した ETL 変換ファイルを API 経由で実行します。

変換は、ファクト・テーブルごとに必要です。ファクト・テーブルへのデータの設定は、TRIRIGA アプリケーションではなく、ETL 変換を通じてのみ実行されます。

TRIRIGA Application Platform には、スケジュールに従ってファクト・テーブルをロードするワークフローが用意されています。このワークフローは、プラットフォームのカスタム・ワークフロー・タスクを呼び出します。このタスクは、ContentManager から最新の変換 XML を取得し、Tivoli Directory Integrator またはKettle API を使用して変換を実行します。


スケジュール済み ETL プロセスは、以下のライセンスにより使用可能になります。

v 任意の IBM TRIRIGA ワークプレース・パフォーマンス管理ライセンス

v IBM TRIRIGA 不動産環境維持マネージャー・ライセンス

v IBM TRIRIGA 不動産環境維持影響マネージャー・ライセンス

v IBM TRIRIGA ワークプレース予約マネージャー・ライセンス

v 小規模インストール用の IBM TRIRIGA ワークプレース予約マネージャー・ライセンス

以下の 3 つのメイン・プロセスがあります。

v 設定。変換ビジネス・オブジェクト/フォーム/ナビゲーション項目とワークフロー自体の作成を行います。

v ETL 開発環境を使用した変換 XML の作成/保守。

v ランタイム。これはスケジュールされたワークフローで、カスタム・ワークフロー・タスクを実行して変換を定期的に調べることで、ファクト・テーブルを更新します。

制約事項: セットアップやメンテナンスのプロセスには、追加のライセンスが必要になる場合があります (triJobItem モジュール用のライセンスなど)。ETL を作成または編集するために必要となるライセンスは、ランタイム・プロセス用に必要なライセンスとは異なります。

Pentaho Spoon による ETL 変換の場合のこれらのプロセスの概要を以下の図に示します。


Tivoli Directory Integrator 構成エディターによる ETL 変換の場合のこれらのプロセスの概要を以下の図に示します。


データは、ETL スクリプトによって「財務サマリー」ビジネス・オブジェクトなどのビジネス・オブジェクトから抽出されます。「財務サマリー」ビジネス・オブジェクトには、スプレッドシートや、お客様が設計した財務システムとのインターフェースから財務サマリー・レコードがインポートされます。

ETL 統合のための前提条件のセットアップTRIRIGA Application Platform では、ビジネス・オブジェクトとフォームによって変換が管理されます。変換を作成するには、ソース・テーブルと宛先ファクト・テーブルが定義されており、マッピングが認識されている必要があります。


ファクト・テーブルごとに、変換を通じてロードされるレコードがあります。変換ビジネス・オブジェクトの 2 進数フィールドによって、変換 XML ファイルがContent Manager に抽出されます。フォームは、変換 XML を簡単に保守できるように、XML ファイルをアップロード/ダウンロードするための方法を提供します。TRIRIGA では、このビジネス・オブジェクトまたはフォームの実装として、ETLジョブ項目があらかじめ構成されています。

TRIRIGA Application Platform では、ワークフローがスケジュールに従って実行され、このワークフローによって、ロードまたは更新が必要なファクト・テーブルごとに、カスタム・ワークフロー・タスクが呼び出されます。ジョブ・スケジューラーは、ETL ジョブ項目のカスタム・ワークフロー・タスクを自動的に呼び出すメカニズムを提供します。

TRIRIGA には、初期状態の TRIRIGA ワークプレース・パフォーマンス管理および TRIRIGA 不動産環境維持の各製品をサポートするために必要なすべてのビジネス・オブジェクト、フォーム、およびワークフローが用意されています。

ETL 変換の定義および保守データを移動するための変換を作成するには、ETL 開発環境を使用します。変換中には、計算を実行したり、TRIRIGA Application Platform やシステムからの変数を使用したりすることができます。

Pentaho Spoon での ETL の使用Pentaho Spoon を ETL 開発環境として使用できます。

Pentaho Spoon の使用の概要:

最初にソース・テーブルおよび宛先テーブルを作成し、対応するマッピングを設定する必要があります。次に、変換に渡す必要がある変数を明確化し、それらの変数を変換ビジネス・オブジェクトまたはフォームに追加する必要があります。これにより、Pentaho Spoon と以下の手順を使用して、変換の定義と保守を行うことができるようになります。

ヒント: 下記の手順は、必ずしもすべて行う必要はありません。必要な手順は、変換を定義するか保守するかによって異なります。

v Spoon を開いて、spoon.bat ファイルまたは kettle.exe ファイルを実行します。リポジトリーを使用する必要はないため、「リポジトリーなし (NoRepository)」を選択します。

v 「変換フォーム」を使用して、ファイル・システムにダウンロードされている既存の XML ファイルを開くか、「ファイル (File)」 > 「新規作成 (New)」 >「変換 (Transformation)」を使用して新規変換を作成します。

v ローカル・データベースの JNDI 設定を定義します。接続名として TRIRIGA を使用します。ツールで、「ビュー (View)」 > 「データベース接続 (DatabaseConnections)」 > 「新規作成 (New)」を使用して、データベース接続を設定します。ワークフローによって変換が実行されると、接続がアプリケーション・サーバーの接続情報に上書きされます。

v 「設計 (Design)」メニューを使用して、以下のように変換の内容を指定します。


– 「設計 (Design)」 > 「入力 (Input)」 > 「テーブル入力 (Table Input)」を使用して、テーブルから行を抽出します。

– 「設計」 > 「変換 (Transform)」 > 「値マッパー (Value Mapper)」を使用して、計算に使用するときにすべての行のフィールドに値が設定されているようにします。

– 「設計 (Design)」 > 「変換 (Transform)」 > 「計算 (Calculator)」を使用して、計算を実行します。

– 「設計 (Design)」 > 「ルックアップ (Lookup)」 > 「DB プロシージャー呼び出し (Call DB procedure)」で、NEXTVAL に保管されたデータベース・プロシージャーを使用して、宛先行の順序付けを指定します。

– 「スクリプト機能 (Scripting)」 > 「変更後の JavaScript の値 (ModifiedJavaScript Value)」などのステップを使用して、必要に応じてデータを変換します。

– 「設計 (Design)」 > 「出力 (Output)」 > 「テーブル出力 (TableOutput)」で、行の出力先となるテーブルを特定します。

– 「ターゲット・ステップに対するマッピングを生成する (GeneratedMappings against Target Step)」でフィールドをマップします。

v 「ビュー (View)」 > 「ホップ (Hops)」を使用してステップをリンクし、変換の内容を段階的に指定します。

v 「実行」などの使用可能なユーティリティーを使用して入念にテストします。テストにより、プロセスが正確であること、および意図した行が返され、適切に変換されることを確認します。

v 「ファイル (File)」 > 「保存 (Save)」を使用して変換を保存します。リポジトリーには保存しないでください。代わりに、ファイル・タイプを XML に設定し、.ktr ファイル拡張子を使用して保存します。ファイル・タイプを設定しない場合は、デフォルトで Kettle 変換になります。その場合、XML ファイルが.ktr ファイル拡張子で保存されます。

Pentaho Spoon のインストール:

ETL 開発環境として Pentaho Spoon をインストールできます。TRIRIGA との統合が可能なバージョンであるバージョン 3.1 を使用してください。

手順

1. http://sourceforge.net/projects/pentaho/files/Data%20Integration/3.1.0-stable/pdi-open-3.1.0-826.zip で Pentaho Spoon バージョン 3.1 を見つけます。

2. .zip ファイルから各ファイルを解凍し、ディレクトリー構造をそのまま維持します。

3. http://kettle.pentaho.org/ にある最新バージョンの Pentaho Spoon、および付随する詳細な資料を確認します。

ローカル JNDI のセットアップ:

データベースのローカル JNDI 設定を定義する必要があります。このためには、プロパティー・ファイルを更新します。


http://sourceforge.net/projects/pentaho/files/Data%20Integration/3.1.0-stable/pdi-open-3.1.0-826.zip

http://sourceforge.net/projects/pentaho/files/Data%20Integration/3.1.0-stable/pdi-open-3.1.0-826.zip

http://kettle.pentaho.org/

手順

1. pdi-open-3.1.0-826/simple-jndi ディレクトリーから、jdbc.properties ファイルを編集して、以下のプロパティーを追加します。

v LocalJNDI/type=javax.sql.DataSource

v LocalJNDI/driver=oracle.jdbc.driver.OracleDriver

v LocalJNDI/url=jdbc:oracle:thin:@localhost:1521:orcl

v LocalJNDI/user=tridata2

v LocalJNDI/password=tridata2

2. DB2 または SQL Server を使用している場合は、ドライバーを含め、必要に応じて情報を更新します。

3. ファイルを保存して閉じます。

変換とデータベース接続の作成:

Pentaho Spoon と TRIRIGA の間で使用する変換とデータベース接続を作成できます

手順

1. Spoon ツールを開き、pdi-open-3.1.0-826 ディレクトリーにある spoon.batファイルを実行します。リポジトリーなしでの実行を選択します。

2. 新規の変換を作成するには、「変換 (Transformations)」を右クリックして「新規」を選択します。

3. 「ビュー (View)」モードで、データベース接続を作成します。「変換(Transformations)」内でデータベース接続を右クリックし、「新規作成(New)」を選択します。

4. カスタム・ワークフロー・タスクにより、TRIRIGA 接続がアプリケーション・サーバー JNDI 設定に置き換えられます。以下のように、データベース接続を構成します。

v 接続名: TRIRIGA

v 接続タイプ: Oracle

v アクセス: JNDI

v 設定: JNDI 名: ローカル JNDI

5. 「テスト (Test)」を選択し、接続が正しくセットアップされていることを確認します。

6. データベース接続の詳細を保存します。

7. 変換を XML ファイルとしてリポジトリー以外の場所に保存してください。Kettle 変換の拡張子は .ktr です。 Kettle 変換のデフォルトでは、ファイルは.ktr として保存されます。

Pentaho Spoon からの変換の実行:

完成している変換または作成中の変換を実行できます。


手順

1. 変換を保存して「実行 (Run)」を選択します。

2. 必要に応じて変数を設定します。

3. 「プレビュー (Preview)」を選択して、各ステップの実行時の入力ストリームの変更内容を表示します。

Spoon ステップの選択:

さまざまな Spoon ステップ・タイプを選択して変換に追加するには、「設計モード(Design Mode)」を使用できます。

手順

1. 変換にステップを追加するには、「ステップ・タイプ (Step type)」を選択し、左側のナビゲーションからステップをパレットにドラッグします。

2. 2 つのステップをリンクするために、左側のナビゲーションで「ビュー(View)」を選択し、「ホップ (Hops)」をダブルクリックします。

3. 「ソース (From)」ステップと「ターゲット (To)」ステップを入力し、「OK」を選択します。

4. あるいは、2 つのステップで Ctrl キーを押しながらクリックし、いずれか 1つのステップを右クリックし、「新規ホップ (New hop)」を選択します。

5. 変換にメモを追加するには、パレットを右クリックして「メモの新規作成 (NewNote)」を選択します。

Spoon 変換の例:

既存の ETL ジョブ項目に含まれる既存の .ktr スクリプトのうちいずれかのコピーをダウンロードして、ステップの説明と照らし合わせることができます。Spoon 変換の例を以下に示します。

ほとんどの初期状態の ETL は、ここに示す例と同じフローをたどります。ただし、データを抽出する元となるデータベース表や、データの変換方法などの仕様は異なります。

変換の例には、以下の項目が含まれます。

v T_TRIORGANIZATIONALLOCATION 組織と T_TRISPACE スペースから、org.TRILOCATIONLOOKUPTXOBJID = space.SPEC_ID の入力行およびフィールドを抽出します。

v IBS_SPEC.UPDATED_DATE を使用して、選択する行を制限します。このとき、変換ビジネス・オブジェクトから渡された日付範囲を使用します。

v 「値マッパー (Value Mapper)」を使用して、すべての行で、space.TRIHEADCOUNTNU、space.TRIHEADCOUNTOTHERNU、およびorg.TRIALLOCPERCENTNU に、値が設定されるようにします (0 に設定しない場合)。

v 「計算 (Calculator)」を使用して、TRIFACTTOTALWORKERSASS を(space.TRIHEADCOUNTNU + space.TRIHEADCOUNTOTHERNU) *org.TRIALLOCPERCENTNU に設定します。


v 変換ビジネス・オブジェクトから変数の取得 (Get Variables) ステップを通じて渡された TRICREATEDBYTX および TRIRUNDA を取得します。

v 「定数の追加 (Add Constant)」を使用して、シーケンス名と増分を設定し、順序付けステップの入力ストリームで使用できるようにします。

v DB プロシージャー NEXTVAL を使用して SPEC_ID を設定し、パフォーマンスを改善するために 5 つのスレッドを使用するようにこのステップを設定します。

v Java スクリプト (JavaScript) ステップを使用して、プロジェクトが時間どおりかどうかを判断し、プロジェクトの期間を計算します。パフォーマンスを改善するために 3 つのステップを使用するように、このステップを設定します。

v フィールドを T_TRISPACEALLOCFACTOID にマップします。

変換の作成時に考慮する必要がある重要事項は以下のとおりです。

v 変換が目的どおりに動作するかどうかを確認するために、ステップを追加するたびにテストを行ってください。

v 変換の開発は慎重に行う必要があります。例えば、特定のフィールドに基づく計算を作成する場合は、すべての行でこれらのフィールドに値が設定されており、空のフィールドがない状態にする必要があります。そうしないと、変換が異常終了します。「値マッパー (Value Mapper)」を使用して、計算に使用するすべてのフィールドに値が設定されているようにしてください。

v TRIRIGA がサポートするデータベースは日付フィールドに日付と時刻を保持するため、日付の処理は容易ではありません。日付の解決では、SQL で日付範囲を処理する方法を示しています。

v ソリューションで複数のデータベース・プラットフォーム (DB2、Oracle、および Microsoft SQL Server) を実行する必要がある場合は特に、必ず JNDI 設定を使用し、変換データベースに依存関係がないようにしてください。

v 変換ビジネス・オブジェクト上のすべての属性は、変数として変換に送信されます。ただし、いくつかの例外があります。タイプが Time または SystemVariable の属性は無視されます。SQL 内で変数を使用する場合や、変数を入力ストリームに抽出する場合は、${VariableName} (VariableName は属性名) という構文を使用して「変数の取得 (Get Variables)」を使用します。

v 「テーブル入力 (Table Input)」で変数を使用する前に、変換のテストとセットアップが完了していることを確認してください。JavaScript、テーブル入力のプレビュー、およびテーブル・マッピングをテストするのは困難です。変換内の変数を設定するには、「編集 (Edit)」 > 「環境変数の設定 (Set EnvironmentVariables)」を使用するか、「実行 (Execute)」ページの「変数 (Variable)」セクションを使用します。変数を使用することで、Spoon 内のより多くのテスト機能を使用できるようになります。

v JNDI を使用する前、検索を実行する前、または Spoon 変換を実行する前に、接続をテストしてください。Spoon でパフォーマンスの潜在的な問題が発生しないようにするために、JNDI 接続をテストする必要があります。

v 索引の追加を検討してください。ETL が T 表からデータを取得する方法は通常のアプリケーションと異なるため、この点がパフォーマンスの鍵になります。

上記の項目は、使用する Spoon ステップを構成する場合の変換の詳細を示したものです。これらの項目では、TRIRIGA に用意されている変換で使用する主要ステップ


だけが取り上げられています。Spoon には、データの操作に使用できる、その他のステップ・タイプが用意されています。変換の必要に応じて、これらのステップを使用してください。

Spoon 入力ステップの構成:

入力ステップを使用して、変換にデータを入力できます。

このタスクについて

テーブル入力 (Table Input) は、ほとんどのデータのソースです。指定されたデータベース接続を使用して、テーブルからデータを抽出する SQL をセットアップできます。

手順

1. テーブル入力 (Table Input) ステップをダブルクリックし、ステップの情報を表示します。

2. TRIRIGA またはソース・データベースへの接続を設定します。

3. SQL を SQL テーブルに入力します。

4. 「OK」を選択して、テーブル入力を保存します。

5. 「プレビュー (Preview)」を選択して、テーブル入力のデータをプレビューします。 SQL で変数を使用する場合、「プレビュー (Preview)」が機能するためには、これらの変数が設定されている必要があります。テスト中に変数値をハードコーディングするか、または「編集 (Edit)」 > 「環境変数の設定 (SetEnvironment Variables)」を選択して変数値を設定する必要があります。SQLの変数は $(triActiveStartDA_MinDATE} と ${triActiveEndDA_MaxDATE} です。

タスクの結果

示されている SQL は、T_TRIORGANIZATIONALLOCATION 組織とT_TRISPACE スペースから、org.TRILOCATIONLOOKUPTXOBJID =space.SPEC_ID の入力行を抽出します。変換ビジネス・オブジェクトの日付を使用して、含まれるデータが制限されます。

Spoon 変換ステップの構成:

変換ステップを使用して、入力データを変更したり、入力ストリームに情報を追加したりすることができます。


Spoon の変換例では、「計算器」、「定数の追加 (Add Constants)」、および「値マッパー (Value Mapper)」の各ステップを使用します。Spoon 経由でシーケンスを追加できますが、その方法はデータベースに依存し、SQL Server では機能しません。代わりに、用意されている DB プロシージャーを使用することができます。

手順

1. 「値マッパー (Value Mapper)」ステップは、フィールドに値を確実に設定したり、フィールドに別の値を設定したりするために使用します。ソース・フィール


ドの値に基づいて値をターゲット・フィールドに設定することができます。ターゲット・フィールドを指定しなければ、ターゲット・フィールドの代わりにソース・フィールドが設定されます。計算に使用するすべてのフィールドに値が設定されていなければなりません。計算中にヌル値が検出されると、変換が失敗します。

2. 「値マッパー (Value Mapper)」をダブルクリックすると、必要な情報を入力するためのダイアログが開きます。Spoon の変換例では、フィールドに値が設定されていない場合に 0 を設定するために使用しています。

3. 「定数の追加 (Add Constants)」ステップは、定数を入力ストリームに追加したり、NEXTVAL DB プロシージャーに必要な値を設定したりするために使用します。

4. NEXTVAL DB プロシージャーを使用するすべての変換でこのステップを使用する必要があります。SEQ_NAME を SEQ_FACTSOID に設定し、INCR を 1 に設定します。

5. 「計算器」ステップは、フィールドを取り込んで計算 (一部に限定) を実行します。フィールド値に対して使用する一連の関数が用意されています。「計算器」ステップは、JavaScript スクリプト・ステップを使用するよりも効率よく実行されます。

6. 組み込みの計算は限定されています。「計算」列を選択すると、使用可能な関数のリストが表示されます。

Spoon ルックアップ・ステップの構成:

ルックアップ・ステップを使用して、データベースからデータ・ストリームに追加データを抽出できます。


「DB プロシージャー呼び出し (Call DB procedure)」により、変換がデータベース・プロシージャーを呼び出すことができます。情報はこのプロシージャーを通って変換に戻ります。ファクト・テーブル項目のシーケンスを作成できます。

手順

1. NEXTVAL を使用し、SEQ_NAME と INCR を送信し、CURR_VALUE を使用して出力するように DB プロシージャー呼び出しをセットアップします。

2. 実行するこのルックアップ・ステップのインスタンスの数を決定します。変換をテストする場合は、このステップを 5 つのインスタンスで実行すると、パフォーマンスが大幅に向上します。例えば 30,000 件のレコードの場合、パフォーマンス時間が 90 秒から 30 秒に減少します。

3. 1 つのステップを実行するスレッドの数を変更するために、ステップを右クリックして「コピーの数の変更 (Change number of copies to start)」を選択します。

4. DB プロシージャー (DB Procedure) ステップを実行するスレッドの数を調整します。


Spoon ジョブ・ステップの構成:

Kettle の変数とフィールドを入力ストリームに取り込むために必要なジョブは作成しませんが、出力フィールドに変数を設定できることを確認する必要があります。


Spoon の変換例では、triCreatedByTX 変数と triRunDA 変数が入力ストリームに取り込まれます。また、ONTIME 変数と DURATION 変数で抽出する変数を取得し、JavaScript スクリプト・ステップの中でこれらの変数を設定できるようにします。

手順

変換中に障害が発生する状況に備えて、変換実行時のタイム・スタンプを取得しておくことが重要です。この例では、この目的で triRunDA 変数を使用します。これにより、プロセスにロールバックのための明示的な手順がない場合でも、ロールバックを実行するための手段が確保されます。変換でフィールドに値を設定するときは、それらのタイプが同一でなければなりません。そうでないと、変換が失敗します。

Spoon スクリプト・ステップの構成:

スクリプト・ステップを使用して JavaScript 機能を実装することができます。


「計算 (Calculator)」では処理できない入力ストリームに対する特定のデータ操作に使用できます。期間を計算、またはストリームに値を設定することができます。これは、if/then/else 節で指定されるその他の値に基づきます。定数の値または変数の値を変換ストリームに設定できます。

手順

1. 値を設定するためのロジックが必要な場合は、JavaScript スクリプト機能を使用します。

2. Spoon の変換の例では、2 つの日付を相互に減算して期間が計算されます。この期間から、計画が予定どおり進行したかどうかが判別されます。

3. JavaScript スクリプト機能を使用するとき、「テーブル入力 (Table Input)」の行から情報を取得する場合には、必要なフィールドを探し出すために繰り返し処理を行う必要があります。テーブル入力 (Table Input) ステップでフィールドに別名を割り当てていない場合は、フィールドに直接アクセスできません。

例

JavaScript スクリプト機能の例で、変数を取得および設定する方法を詳しく示します。

var actualEnd;var actualStart;var plannedEnd;var plannedStart;var duration;var valueDuration;


var valueOnTime;

// loop through the input stream row and get the fields// we want to play withfor (var i=0;i<row.size();i++) {

var value=row.getValue(i);

// get the value of the field as a numberif (value.getName().equals("TRIACTUALENDDA")) {actualEnd = value.getNumber();

}if (value.getName().equals("TRIACTUALSTARTDA")) {actualStart = value.getNumber();

}if (value.getName().equals("TRIPLANNEDENDDA")) {plannedEnd = value.getNumber();

}if (value.getName().equals("TRIPLANNEDSTARTDA")) {plannedStart = value.getNumber();

}

// these are the 'variables' in the stream that we want// to update with the duration and ontime setting// so we want the actual Value class not the value// of the variableif (value.getName().equals("DURATION")) {valueDuration = value;

}if (value.getName().equals("ONTIME")) {valueOnTime = value;

}}

// calculate the duration in daysduration = Math.round((actualEnd - actualStart) / (60*60*24*1000));// calculate the duration in hours// duration = (actualEnd - actualStart) / (60*60*1000);

// set the duration into the 'variable' in the rowvalueDuration.setValue(duration);

// determine ontime and set the value into the// 'variable' in the row streamif ((actualEnd == null) || (plannedEnd == null))

valueOnTime.setValue("");else if (actualEnd > plannedEnd)

valueOnTime.setValue("no");else

valueOnTime.setValue("yes");

「スクリプトのテスト (Test Script)」を選択して、JavaScript がコンパイルされることを確認します。テーブル入力 (Table Input) の「スクリプトのテスト (TestScript)」ステップと「プレビュー (Preview)」ステップは、設定されていない変数を処理できません。「編集 (Edit)」 > 「環境変数の設定 (Set EnvironmentVariables)」を使用して、変換の変数を設定できます。これにより、Pentaho Spoon内でテスト機能をより活用できます。

例えば「編集 (Edit)」 > 「環境変数の設定 (Set Environment Variables)」を使用して、triActiveStartDA_MinDATE に to_date('20061201', 'YYYYmmdd') を設定できます。

照会を定義するときに列別名を使用する場合は、getName で列を検索するときと同じ別名を使用する必要があります。


次の例に、テーブル入力ステップ (Table Input) での選択オプションを示します。

SELECT mainProject.triProjectCalcEndDA ActualEndDate,mainProject.triProjectActualStartDA ActualStartDate

ActualEndDate の値を検索する場合は、次に示すように、データベースの列名ではなく別名を使用します。

if (value.getName().equals("ActualEndDate")) {actualEnd = value.getNumber();

}

Spoon 出力ステップの構成:

出力ステップを使用して、データベースにデータを書き込むことができます。


テーブル出力 (Table Output) およびテーブル出力マッピング (Table OutputMapping) により、データベースに情報が格納されます。この情報はファクト・テーブルで使用されます。変換を保存するための情報がすべて揃っている場合は、出力ステップを変換の終わりに追加し、最終ステップに接続できます。

手順

1. ダブルクリックし、出力テーブルとして使用するファクト・テーブルと接続情報を追加します。

2. それがセットアップされ、ステップが接続されたら、テーブル出力 (TableOutput) ステップを右クリックします。

3. 「このターゲット・ステップに対するマッピングを生成する (Generatemapping against this target step)」をクリックします。

4. ソース・フィールドをターゲット・データベースのターゲット・フィールドにマップし、「OK」を選択します。ソース・フィールドには、入力ストリームに追加される追加フィールドも含まれます。テーブル入力 (Table Input) ステップで変数を使用する前に、必ずテーブル・マッピングを設定してください。

5. 変換を完了するために、最後の 2 つのステップの間にマッピング (Mapping)ステップをドラッグします。

6. 必要に応じて、マッピング (Mapping) ステップでフィールドを変更するか、またはフィールドを追加することができます。

変換のテスト:

変換のテストは、各 Spoon ステップを追加した後、またはすべての Spoon ステップが完了した最後の時点で実行できます。各ステップの後でテストを行うと、デバッグが容易になります。変換をテストするには、まず、その変換を保存する必要があります。


変数セクションには、変換で使用される変数の詳細が記載されています。 Spoon を使用して変換をテストするときに、これらの変数に値を設定できます。変換がTRIRIGA 内から実行される際、変数は変換ビジネス・オブジェクトの一部を形成します。カスタム・ワークフロー・タスクが呼び出される前に、使用する値を設定


し、スマート・オブジェクトに保存してください。

手順

1. triRunDA 変数を、ワークフロー実行の日時に設定します。変換ビジネス・オブジェクトの属性である必要はありません。これは、実行日時の数表現です。triRunDA は、カスタム・ワークフロー・タスクによって動的に生成されるため、6 種類の日付形式を持ちません。triRunDA は、ファクト行の作成日を設定するために必要になります。

2. triCreatedByTX は、変換ビジネス・オブジェクトの属性です。

3. triActiveStartDA_MinDATE と triActiveEndDA_MaxDATE はそれぞれ、triActiveStartDA と triActiveEndDA のラップされた表現です。 Spoon によるテスト中に、Oracle または DB2 でテストしている場合は to_date('the dateyou want', 'the format') を使用してラップする必要があります。

4. 「起動 (Launch)」をクリックして変換を実行します。ステップにエラーがある場合は、そのステップが赤色で示され、エラーがログ・ファイルに保存されます。ログ・ファイルにはログ・ページからアクセスできます。

日付ソリューション:

Pentaho Spoon で使用するときに、いくつかの日付変数では計算と比較が必要になります。日付の解決により、これらの計算および比較が提供されます。

日付の解決が必要になるのは以下の 3 つの場合です。

1. 2 つの日付を比較する。この比較は、プロジェクトが予定どおりに進んでいるかどうかを判別するために使用されます。

2. 2 つの日付の間の期間を日数で計算する。場合によっては、その期間が何時間であるかを計算するためにこの計算が使用されます。

3. 日付 (変更日や処理日など) を日付の範囲 (月の初日から月の末日など) と比較する。

最初と 2 番目の事例は、JavaScript スクリプト・ステップを使用して解決します。

3 番目の事例は、テーブル入力で日付範囲を使用して解決します。

日付には 2 種類あります。データベースの中に日付として格納される日付と、データベースの中に数値として格納される日付です。

ヒント: TRIRIGA のすべてのオブジェクトは、「日付」フィールドと「日時」フィールドを数値としてデータベースに保管します。ビジネス・オブジェクト・テーブルを操作するには、フィールドが数値になるように選択します。日付として定義されたシステム・プラットフォーム・テーブルのフィールドを操作するには、フィールドが日付になるように選択します。

日付としてのフィールドの選択:

フィールドを日付として選択することで、日付と定義されたシステム・プラットフォーム・テーブルのフィールドを操作することができます。

以下のコード例では、IBS_SPEC.UPDATED_DATE を日付フィールドとして使用して、行が必要かどうかを判別します。triActiveStartDA と triActiveEndDA が日付の範


囲です。これらのデータは、変換ビジネス・オブジェクトの triActiveStartDA フィールドおよび triActiveEndDA フィールドから取得されます。

IBS_SPEC テーブルは TRIRIGA オブジェクトではありません。これはシステム・プラットフォーム・テーブルであり、TRIRIGA でオブジェクトを追跡するために使用されます。そこには、TRIRIGA 内のオブジェクトが更新されるたびに変更されるフィールドが含まれます。このフィールドは UPDATED_DATE フィールドであり、データベース内では数値フィールドではなく日付フィールドです。

以下のコード例では ${triActiveStartDA_MinDATE} と ${triActiveEndDA_MaxDATE}を使用しています。これらのラップされた日付フィールドによって、開始日の午前12 時から終了日の午後 11 時 59 分までのすべてのレコードが取り出されます。

SELECT org.SPEC_ID ORG_SPEC_ID, org.TRIORGANIZATIONLOOKUOBJID,space.CLASSIFIEDBYSPACESYSKEY, org.TRIALLOCPERCENTNU, org.TRIALLOCAREANU,space.TRIHEADCOUNTNU, space.TRIHEADCOUNTOTHERNU, spec.UPDATED_DATEFROM T_TRIORGANIZATIONALLOCATION org, T_TRISPACE space, IBS_SPEC specWHERE org.TRILOCATIONLOOKUPTXOBJID = space.SPEC_IDand space.SPEC_ID = spec.SPEC_IDand spec.UPDATED_DATE >= ${triActiveStartDA_MinDATE}and spec.UPDATED_DATE <= ${triActiveEndDA_MaxDATE} order by UPDATED_DATE

Oracle または DB2 では、${triActiveStartDA_MinDATE} が to_date ('2007070100:00:00', 'YYYYmmdd hh24:mi:ss') のように、${triActiveEndDA_MaxDATE} がto_date ('20070731 23:59:59', 'YYYYmmdd hh24:mi:ss') のように表示されます。

SQL Server では、データベース仕様のためにこれらの日付の形式が少し異なりますが、2 つの日付の間にあるすべての行を収集するようにセットアップされます。

数値としてのフィールドの選択:

フィールドを数値として選択することで、ビジネス・オブジェクト・テーブルを操作することができます。

TRIRIGA 日付の日付判別フィールドとして IBS_SPEC.UPDATED_DATE を使用する代わりに、この方法では、判別フィールドを直接 triActiveStartDA およびtriActiveEndDA と比較します。これは、これらのフィールドがいずれもデータベース内で数値であるためです。

以下のコード例で、triCaptureDA は T_TRISPACE のフィールドです。

SELECT org.SPEC_ID ORG_SPEC_ID, org.TRIORGANIZATIONLOOKUOBJID,space.CLASSIFIEDBYSPACESYSKEY, org.TRIALLOCPERCENTNU, org.TRIALLOCAREANU,space.TRIHEADCOUNTNU, space.TRIHEADCOUNTOTHERNU, space.TRICAPTUREDAFROM T_TRIORGANIZATIONALLOCATION org, T_TRISPACE space, IBS_SPEC specWHERE org.TRILOCATIONLOOKUPTXOBJID = space.SPEC_IDand space.TRICAPTUREDA >= ${triActiveStartDA_Min}and space.TRICAPTUREDA <= ${triActiveEndDA_Max} order by space.TRICAPTUREDA

日付フィールドと同様に、Min 変数と Max 変数を使用して、開始が 00:00:00、終了が 23:59:59 になるようにします。例えば、これらの変数を使用して、12 月 31日の午後 1 時 54 分のレコードを検索で抽出します。

日付変数:

ファクト変換ビジネス・オブジェクトの日付属性または日時属性ごとに、6 つのKettle 変数がシステムによって作成されます。


これらの Kettle 変数の概要を以下の表に示します。

表 3. Kettle 変数

Kettle 変数説明

${triActiveStartDA} サフィックスなし = 2014 年 1 月 1 日以降のミリ秒数の値。時刻は変更されません。この変数は数値として表現されるフィールドに使用されます。

${triActiveStartDA_Min} Min = 2014 年 1 月 1 日以降のミリ秒数の値であり、時刻の値は、指定された日付の00:00:00 に設定されます。この変数は数値として表現されるフィールドに使用されます。

${triActiveStartDA_Max} Max = 2014 年 1 月 1 日以降のミリ秒数の値であり、時刻の値は、指定された日付の23:59:59 に設定されます。この変数は数値として表現されるフィールドに使用されます。

${triActiveStartDA_DATE} DATE = 日付形式のラップされた値。時刻は変更されません。この変数は、データベース内で日付として表現されるフィールドに使用されます。Oracle または DB2 ではラップされ、to_date ('20070615 22:45:10','YYYYmmddh24:mi:ss') のように表現されます。SQL Server では '20070615 22:45:10' のように表現されます。

${triActiveStartDA_MinDATE} MinDATE = 日付形式のラップされた値。時刻の値は 00:00:00 に設定されます。この変数は、データベース内で日付として表現されるフィールドに使用されます。

${triActiveStartDA_MaxDATE} MaxDATE = 日付形式のラップされた値。時刻の値は 23:59:59 に設定されます。この変数は、データベース内で日付として表現されるフィールドに使用されます。

${triActiveStartDA_Min} 変数と ${triActiveStartDA_Max} 変数を指定して 2 つの日付の間の期間を調べる場合は、その期間内のすべての行を収集する必要があります。午前 0 時に始めて午前 0 時 1 秒前に停止する必要があります。日付の値しか使用しないと、変数の時刻によっては、必要な行をすべて取得できない場合があります。TRIRIGA のデータベースは、両方も日時フィールドまたは数値フィールドに日付を保管するため、分と秒を指定する必要があります。

${triActiveStartDA_MinDATE} 変数および ${triActiveStartDA_MaxDATE} 変数は日付の比較にも役立ちます。

例えば、値が 20070615 22:45:10 である triActiveStartDA の場合は、以下のようになります。


triActiveStartDA_MinDATE =(Oracle) to_date('20070615 00:00:00','YYYYmmdd h24:mi:ss')(SQL Server) '20070615 00:00:00'triActiveStartDA_MaxDATE =(Oracle) to_date('20070615 23:59:59','YYYYmmdd h24:mi:ss')(SQL Server) '20070615 23:59:59'

ETL スクリプトの TRIRIGA への移動:

変換が完成し、テストが終了したら、その変換を TRIRIGA ETL ジョブ項目にアップロードする必要があります。

要確認: 変換を保存するときは、ファイル・タイプを XML とし、拡張子を .ktrとします。

ETL 環境と TRIRIGA の間のフローについて以下の図で説明します。

Kettle に渡される変数:

Kettle に渡される変数のタイプはすべてストリングです。数値変数は、カスタム・ワークフロー・タスクによってタイプがストリングに変換されます。Kettle でサポートされている TRIRIGA のフィールド・タイプは、テキスト、ブール値、日付、日時、ロケーター、および数値です。

表 4. ETL ジョブ項目のフィールドの例を以下に示します。

フィールド名フィールド・ラベルフィールド・タイプ

triActiveEndDA アクティブな終了日日付

triActiveStartDA アクティブな開始日日付

triBONamesTX ビジネス・オブジェクト名テキスト

triControlNumberCN 制御番号制御番号

triCreatedByTX 作成者テキスト

triLocator triLocator テキスト

triModuleNamesTX モジュール名テキスト


表 4. ETL ジョブ項目のフィールドの例を以下に示します。 (続き)


triNameTX 名前テキスト

triTransformBI ファイルの変換バイナリー

表 5. Kettle に渡される変数を以下に示します。

Kettle に渡される変数説明

triNameTX (テキスト)

triActiveStartDA (数値) 2014 年 1 月 1 日以降のミリ秒数で表した日付

triActiveStartDA_DATE (日付) Oracle または DB2 の場合はラップされます。時刻は属性に設定されている時刻です

triActiveStartDA_MinDATE (日付) Oracle または DB2 の場合はラップされます。時刻は 00:00:00 です

triActiveStartDA_MaxDATE (日付) Oracle または DB2 の場合はラップされます。時刻は 23:59:59 です

triActiveStartDA_Min (数値) 2014 年 1 月 1 日以降のミリ秒数で表した日付。時刻は 00:00:00 です

triActiveStartDA_Max (数値) 2014 年 1 月 1 日以降のミリ秒数で表した日付。時刻は 23:59:59 です

triActiveEndDA (数値) 2014 年 1 月 1 日以降のミリ秒数で表した日付

triActiveEndDA_DATE (日付) Oracle または DB2 の場合はラップされます。時刻は属性に設定されている時刻です

triActiveEndDA_MinDATE (日付) Oracle または DB2 の場合はラップされます。時刻は 00:00:00 です

triActiveEndDA_MaxDATE (日付) Oracle または DB2 の場合はラップされます。時刻は 23:59:59 です

triActiveEndDA_Min (数値) 2014 年 1 月 1 日以降のミリ秒数で表した日付。時刻は 00:00:00 です

triActiveEndDA_Max (数値) 2014 年 1 月 1 日以降のミリ秒数で表した日付。時刻は 23:59:59 です


triCreatedByTX (テキスト)

triRunDATE (数値) カスタム・ワークフロー・タスクによって設定された実行日

triLocator (テキスト – ロケーター) 別のビジネス・オブジェクトへの参照を含むロケーター・フィールド。この変数には、そのレコードのフィールドのテキスト値が含まれています。


表 5. Kettle に渡される変数を以下に示します。 (続き)

Kettle に渡される変数説明

triLocator_IBS_SPEC (テキスト - ロケーター) triLocator フィールド内のレコードの spec_id が含まれています。この spec_id を使用して、他のデータベース表を通じてそのレコードの関連情報を検索できます。

triControlNumberCN および triTransformBI は Kettle には渡されません。

重要: 変数についての注意事項:

v タイプが日付 (および日時) のフィールドには、それぞれ 6 つの変数があります。TRIRIGA は値をラップし、6 種類の形式で Kettle に渡します。

v Kettle 内の変数はすべてストリングです。スクリプトで変数を数値にする必要がある場合は、変換を使用する必要があります。triRunDATE などの変数でTRICREATEDDA などの数値フィールドを設定することができます。Kettle はいくつかの場合に暗黙の変換を行いますが、変数を使用して計算を行う場合は、その変数をあらかじめ数値に変換しておく必要があります。

v 日付には、必ず正しい表現を使用してください。例えば、選択にspec.UPDATED_DATE >= ${triCreatedDA} を含めることはできません。spec.UPDATED_DATE は日付ですが、triCreatedDA は数値です。そのため、不正確な結果になるか、SQL が失敗します。

v Kettle に渡すことができる属性タイプは、テキスト、ブール値、日付、日時、ロケーター、および数値に制限されています。TRIRIGA のその他すべてのデータ型はスキップされます (ロケーターを除く)。

v ロケーター・フィールドに対しては、2 つの変数が作成されます。1 つはロケーターのテキストに、もう 1 つはリンクされたレコードの SPEC_ID に使用されます。この SPEC_ID を使用して、他のデータベース表を通じてそのレコードの関連情報を検索できます。

アプリケーションでの ETL スクリプトのデバッグ:

アプリケーションで ETL スクリプトをデバッグするには、最初にロギングをセットアップしてから、RunETL カスタム・ワークフロー・タスクをトリガーしてログ情報を表示する必要があります。

ロギングのセットアップ:

TRIRIGA には、TRIRIGA アプリケーションでの ETL スクリプトの実行時に使用できるデバッグ機能が備えられています。

手順

1. 管理者コンソールで、プラットフォーム・ロギング管理対象オブジェクトを選択します。次に、ETL ロギングを使用可能にするオプションを選択します。

2. 「カテゴリー ETL (Category ETL)」 > 「変換 (Transforms)」 > 「変換の実行 (Run Transform)」を選択して、ETL ジョブ項目を処理する TRIRIGA プラットフォーム・コードでのデバッグ・ロギングをオンにします。ログ・メッセージが server.log に出力されます。


3. 「カテゴリー ETL (Category ETL)」 > 「変換 (Transforms)」 > 「Kettle」を選択して、Kettle 変換でのデバッグ・ロギングをオンにします。ログ・メッセージが server.log に出力されます。

4. 変更を適用します。これで、ETL スクリプトの実行時に、ETL 関連情報がサーバー・ログに記録されます。

重要: ログに大量の情報が表示される可能性があるため、ETL ジョブ項目の 1回の実行についてのみデバッグするように Pentaho Spoon ロギングを設定してください。

ETL ジョブを使用したデバッグ:

ロギングのセットアップが完了したら、ログに記録されている情報を確認するために RunETL カスタム・ワークフローをトリガーする手段が必要になります。


ETL ジョブ項目を使用している場合は、フォームの「プロセスの実行」アクションをクリックします。

手順

フォームのフィールドには必ず、ETL スクリプトで受け入れられる値を入力してください。「プロセスの実行」アクションは、デバッグ目的でのみ使用してください。実稼働環境では、代わりにジョブ・スケジューラーを使用してください。「プロセスの実行」ではデータベースのテーブルが更新されるため、実稼働環境ではこのアクションを使用しないでください。

例

以下は、ログ出力のサンプルです。

2011-01-21 14:01:27,125 DEBUG [com.tririga.platform.workflow.runtime.taskhandler.ETL.RunETL](WFA:11325389 - 3070255 triProcessManual:38447392 IE=38447392) Kettlevariable set - ${triCalendarPeriodTX_SPEC_ID} = 3103902

2011-01-21 14:01:27,125 DEBUG [com.tririga.platform.workflow.runtime.taskhandler.ETL.RunETL](WFA:11325389 - 3070255 triProcessManual:38447392 IE=38447392) Kettlevariable set - ${triCalendarPeriodTX} = ¥Classifications¥Calendar Period¥2010¥Q4 - 2010¥October - 2010

2011-01-21 14:01:27,125 DEBUG [com.tririga.platform.workflow.runtime.taskhandler.ETL.RunETL](WFA:11325389 - 3070255 triProcessManual:38447392 IE=38447392) *** objectfield found = BoFieldImpl[name=triEndDA,id=1044,Section=BoSectionImpl[name=General,id=BoSectionId[categoryId=1,subCategoryId=1],Business Object=BoImpl[name=triETLJobItem,id=10011948,module=ModuleImpl[name=triJobItem,id=22322]]]]

2011-01-21 14:01:27,125 DEBUG [com.tririga.platform.workflow.runtime.taskhandler.ETL.RunETL](WFA:11325389 - 3070255 triProcessManual:38447392 IE=38447392) Kettlevariable set - ${triEndDA_MinDATE} = to_date('20101031 00:00:00','YYYYmmdd hh24:mi:ss')

2011-01-21 14:01:27,125 DEBUG [com.tririga.platform.workflow.runtime.taskhandler.ETL.RunETL](WFA:11325389 - 3070255 triProcessManual:38447392 IE=38447392) Kettlevariable set - ${triEndDA_MaxDATE} = to_date('20101031 23:59:59','YYYYmmdd hh24:mi:ss')

2011-01-21 14:01:27,125 DEBUG [com.tririga.platform.workflow.runtime.taskhandler.


ETL.RunETL](WFA:11325389 - 3070255 triProcessManual:38447392 IE=38447392) Kettlevariable set - ${triEndDA_DATE} = to_date('20101031 00:00:00','YYYYmmdd h24:mi:ss')

2011-01-21 14:01:27,125 DEBUG [com.tririga.platform.workflow.runtime.taskhandler.ETL.RunETL](WFA:11325389 - 3070255 triProcessManual:38447392 IE=38447392) Kettlevariable set - ${triEndDA} = 1288508400000

2011-01-21 14:01:27,125 DEBUG [com.tririga.platform.workflow.runtime.taskhandler.ETL.RunETL](WFA:11325389 - 3070255 triProcessManual:38447392 IE=38447392) Kettlevariable set - ${triEndDA_Min} = 1288508400000

2011-01-21 14:01:27,125 DEBUG [com.tririga.platform.workflow.runtime.taskhandler.ETL.RunETL](WFA:11325389 - 3070255 triProcessManual:38447392 IE=38447392) Kettlevariable set - ${triEndDA_Max} = 1288594799000

2011-01-21 14:02:10,595 INFO [SpaceFact](WFA:11325389 - 3070255 triProcessManual:38447392 IE=38447392) SpaceFact - Process Remove Nulls (LEGALINTEREST_SPEC_ID)'.0ended successfully, processed 3282 lines. ( 76 lines/s)

2011-01-21 14:02:10,595 INFO [SpaceFact](WFA:11325389 - 3070255 triProcessManual:38447392 IE=38447392) SpaceFact - Process Remove Nulls ( REALPROPERTYUSE_SPEC_ID)'.0 ended successfully, processed 3282 lines. ( 76 lines/s)

2011-01-21 14:02:10,595 INFO [SpaceFact](WFA:11325389 - 3070255 triProcessManual:38447392 IE=38447392) SpaceFact - Process Remove Nulls ( REALPROPERTYTYPE_SPEC_ID)'.0 ended successfully, processed 3282 lines. ( 76 lines/s)

2011-01-21 14:02:10,595 INFO [SpaceFact](WFA:11325389 - 3070255 triProcessManual:38447392 IE=38447392) SpaceFact - Process Filter rows'.0 ended successfully,processed 3307 lines. ( 76 lines/s)

2011-01-21 14:02:10,595 INFO [SpaceFact](WFA:11325389 - 3070255 triProcessManual:38447392 IE=38447392) SpaceFact - Process Dummy (do nothing)'.0 ended successfully,processed 25 lines. ( 0 lines/s)

2011-01-21 14:02:10,595 INFO [SpaceFact](WFA:11325389 - 3070255 triProcessManual:38447392 IE=38447392) SpaceFact - Process Query for Space'.0 ended successfully,processed 0 lines. ( 0 lines/s)

パフォーマンスの調整のヒント:

Spoon での ETL のパフォーマンスを向上させるには、以下のヒントを参照してください。

サマリー

1. ETL で目的の処理を行う準備ができたら、ベースライン・パフォーマンス測定を実施します。

2. Spoon を使用して、ファクト・テーブルに数千行を追加したデータベースに対して ETL を実行します。

3. ネットワーク待ち時間が発生しないようにするため、必ず JNDI 接続を使用し、データベースが稼働しているネットワークで Spoon を実行してください。VPN 経由では実行しないでください。

4. 実行の完了リストを入手します。例えば、triSpacePeopleFact ETL の実行のリストなどです。

分析

1. JavaScript ステップおよび DB プロシージャー (Get Next Spec ID) ステップには複数のコピーがあります。ステップを右クリックし、開始するコピーの数を変更します。


v 前記の例の実行に示した triSpacePeopleFact ETL の場合、JavaScript ステップおよび DB プロシージャー (Get Next Spec ID) ステップのコピー数を、以下のようにそれぞれ 3 に変更します。

v 未変更: 12.9、12.7、12.5、12.6

v 各ステップの 3 つのコピー: 11.4、11.6、12.3、12.2

2. デフォルトの行セット・サイズを 1000 から 10000 に変更します。新しい変換は自動的にこのように設定されます。ETL を右クリックし、変換のプロパティーを開きます。

3. 実行を分析します。ボトルネックがありますか? 他のステップよりも時間がかかるステップがありますか? 他のステップでは、スループットを向上するために複数コピーが作成されていることがあります。

4. データ入力 (Data Input) ステップがボトルネックになっていますか? 索引によってデータベースの動作が改善されますか? 該当する場合は、索引を追加して再実行してください。パフォーマンスは向上しましたか? データベースを使用して結果セットをフィルタリングして絞り込む代わりに、フィルター・ステップを使用することもできます。

5. 分析は反復プロセスです。JavaScript ステップおよび DB プロシージャー (GetNext Spec ID) ステップの複数コピーが常に存在します。

6. 300 行/秒から 800 行/秒の速度で実行される ETL はパフォーマンスが良好であり、明らかにパフォーマンスの許容範囲内にあります。

triSpacePeopleFact ETL の場合、初期開発後にステップ 1 と 2 を行うだけで、大幅な向上が実現しました。

一方、triSpaceFact ETL で大幅な向上を実現するには、ステップ 1、2、および 4を実行しました。

ステップ 1 と 2 を行った場合の triSpacePeopleFact ETL の実行結果を以下に示します。

Query for Space People: Time = 11.6 sec; Speed (r/s) = 743.6

ステップ 1 と 2 を行った場合の triSpaceFact ETL の実行結果を以下に示します。

Query for Space: Time = 313.9 sec; Speed (r/s) = 24.0

「Query for Space」ステップ (データ入力 (Data Input) ステップ) は 24 行/秒であり、明らかにボトルネックになっています。

「Query for Space People」は、「Query for Space」ステップのようにボトルネックにはなっていないことに注意してください。triSpaceFact ETL は、ステップ 1 と2 以外の変更を行わない状態で適切に実行され、700 行/秒を超える速度が得られます。

triSpaceFact ETL でのステップ 4 については、「Query for Space」タスクの SQLを参照してください。SQL に SUM があることに注意してください。特に SUMが 2 つ存在し、どのフィールドにも索引が作成されないため、コストがかかります。

索引を T_TRIORGANIZATIONALLOCATION.TRILOCATIONLOOKUPTXOBJIDに追加してください。 SELECT SUM WHERE に TRISTATUSCL が含まれていま


すが、TRILOCATIONLOOKUPTXOBJID に索引を追加する必要があるだけです。TRISTATUSCL は 1000 文字のフィールドであり、このため索引作成に時間がかかり、SQL サーバーでも実行が困難です。

CREATE INDEX IDX01_TRIORGALLOC ON T_TRIORGANIZATIONALLOCATION(TRILOCATIONLOOKUPTXOBJID) NOPARALLEL;

ETL を再実行してください。

ステップ 1、2、および 4 を行った場合の triSpaceFact ETL の実行結果を以下に示します。

Query for Space: Time = 3.2 sec; Speed (r/s) = 2378.3

データ入力 (Data Input) ステップの 1 秒当たりの行数 (2378.3) が変化していることと、ETL の実行にかかる時間 (7544 行で 3.2 秒) に注意してください。

重要: ETL の開発中に留意すべき点:

v 複雑な SQL や集約関数 (COUNT、MIN、MAX、SUM など) は使用しないようにしてください。これらの関数を使用する必要がある場合は、索引によってデータ入力 (Data Input) ステップが改善されるかどうかを検討してください。ラージ VARCHAR 型フィールドには索引を作成しないでください。SQL Serverで処理できる索引のサイズは 900 バイト未満です。

v OR、NOT、およびビュー (TRIRIGA データベースの M_TableName) は、可能な限り使用しないでください。

v 可能な場合は、JavaScript ステップの代わりに計算 (Calculator) ステップを使用してください。 JavaScript ステップはコストがかかります。

v JavaScript ステップは 1 つのみにしてください。

IBM Tivoli Directory Integrator 構成エディターでの ETL の使用Tivoli Directory Integrator 構成エディターは、Tivoli Directory Integrator に組み込まれている ETL 開発環境です。構成エディターにより、ETL 変換 (TivoliDirectory Integrator では構成ファイルと呼びます) の作成、保守、テスト、およびデバッグを行えます。構成エディターは Eclipse プラットフォームをベースに構築されており、包括的かつ拡張可能な開発環境を提供します。

始める前に

構成エディターを使用した変換の定義または保守を担当するシステム開発者は、TRIRIGA データベースにアクセスできることと、このデータベースを使用して作業した経験を持っていることが必要です。

Tivoli Directory Integrator 構成エディターを使用して ETL 変換の定義および保守を行うには、以下の作業を行う必要があります。

v ソース・テーブルおよび宛先テーブルの作成

v 対応するマッピングの設定

v 変換に渡す必要がある変数の明確化

v 変換ビジネス・オブジェクトまたはフォームへの変数の追加


Tivoli Directory Integrator 構成エディターのインストール:

Tivoli Directory Integrator ランタイム・サーバーは、TRIRIGA と共に自動的にインストールされますが、Tivoli Directory Integrator AssemblyLine を作成または変更するには、ETL の開発に使用するワークステーションに構成エディターをインストールする必要があります。

手順

1. 該当する Tivoli Directory Integrator インストール・パッケージをパスポート・アドバンテージ (http://www.ibm.com/software/howtobuy/passportadvantage/pao_customers.htm) からダウンロードしてインストールします。

オプション説明

TDI711_TAP340_Install_Wind.zip Windows Multilingual 上の IBM TRIRIGAApplication Platform V3.4.0 用の IBMTivoli Directory Integrator V7.1.1 インストーラー

TDI711_TAP340_Install_Linux.tar Linux Multilingual 上の IBM TRIRIGAApplication Platform V3.4.0 用の IBMTivoli Directory Integrator V7.1.1 インストーラー

TDI711_TAP340_Install_SOLIntl.tar Solaris Intel Multilingual 上の IBMTRIRIGA Application Platform V3.4.0 用のIBM Tivoli Directory Integrator V7.1.1 インストーラー

TDI711_TAP340_Install_SOLSprc.tar Solaris Sparc Multilingual 上の IBMTRIRIGA Application Platform V3.4.0 用のIBM Tivoli Directory Integrator V7.1.1 インストーラー

TDI711_TAP340_Install_AIX.tar AIX Multilingual 上の IBM TRIRIGAApplication Platform V3.4.0 用の IBMTivoli Directory Integrator V7.1.1 インストーラー

2. IBM Tivoli Directory Integrator V7.1.1 Fixpack 3 に更新します。このFixPack は、http://www.ibm.com/support/docview.wss?uid=swg27010509から入手できます。

3. 7.1.1-TIV-TDI-LA0014 を適用します。これは、IBM サポートに連絡することにより入手できます。

4. TRIRIGA インストール・ディレクトリーから、AssemblyLine の接続先のデータベース・タイプに対応する JDBC ドライバーを、Tivoli Directory Integratorディレクトリー TDI Install Directory/jars にコピーします。

v SQL サーバーの場合は、jtds-1.2.8.jar をコピーします

v Oracle の場合は、ojdbc6.jar をコピーします

v DB2 の場合は、db2jcc4.jar をコピーします


http://www.ibm.com/software/howtobuy/passportadvantage/pao_customers.htm

http://www.ibm.com/software/howtobuy/passportadvantage/pao_customers.htm

http://www.ibm.com/support/docview.wss?uid=swg27010509

Tivoli Directory Integrator が使用するポートの変更:

Tivoli Directory Integrator が使用するポートは、TRIRIGA のインストール中に指定します。まれに、これらのポート設定を変更することが必要な場合があります。


TRIRIGA が ETL 変換を Tivoli Directory Integrator に送信して実行させるポートを変更するには、TRIRIGAWEB.properties の TDI_HTTP_SERVER_PORT を変更します。

v

Tivoli Directory Integrator エージェントが Tivoli Directory Integrator サーバーの管理に使用するポートを変更するには、以下の作業を行います。

v TRIRIGAWEB.properties の TDI_SERVER_PORT を変更する

v TRIRIGA_Install_Directory/TDI_IE/TDISolDir/solution.properties のapi.remote.naming.port を変更する

Tivoli Directory Integrator 構成エディター入門:

構成エディターで ETL の定義および保守を行えるようにするには、まず基本的な作業 (構成エディターのオープン、ビューの把握、プロジェクト、AssemblyLine、フック、スクリプト、またはコネクターの作成、構成ファイルのインポートなど)を理解する必要があります。

構成エディターを開始するには、ibmditk ラッパー・スクリプトを使用します。このスクリプトは Tivoli Directory Integrator のインストール・ディレクトリーにあります。プロジェクトとファイルを保管するためのワークスペース・フォルダーを選択してください。

構成エディターのワークスペース・ウィンドウに表示されるビューは以下のとおりです。

v ナビゲーター (左上) には、サーバー構成および Tivoli Directory Integrator ソリューション用のすべてのプロジェクトとソース・ファイルが表示されます。ナビゲーターには、テキスト・ファイルなどのその他のファイルやプロジェクトが表示されることもあります。構成エディターは、Tivoli Directory Integrator プロジェクトを特別に取り扱うため、他のファイルやプロジェクトは構成エディターの影響を受けません。

v サーバー・ビュー (左下) には、「TDI サーバー」プロジェクトで定義されている各サーバーの状況が表示されます。定義できるサーバーの数に制限はありません。このサーバー・ビューには、サーバー上で操作するさまざまな機能とその構成が表示されます。「更新」ボタンを押すと、ビュー内のすべてのサーバーの状況が更新されます。

v エディター領域 (右上) では、AssemblyLine 構成などの文書を開いて編集します。このエリアは上下に分かれており、その他の関連情報を提供する各種のビューが含まれています。その中で最も重要なのが、「問題」ビュー (TivoliDirectory Integrator コンポーネントでの潜在的な問題が表示されます)、「エラー・ログ」(ソリューションの開発中に発生したエラーが表示されます)、および


「コンソール」ビュー (Tivoli Directory Integrator サーバー (構成エディターによって始動されたものなど) を実行するためのコンソール・ログが表示されます)の各ビューです。

一般的なアクティビティーには、以下の基本タスクが含まれます。

v プロジェクトを作成するには、右クリックして「ファイル」 > 「新規」 > 「プロジェクト」を選択します。

v AssemblyLine を作成するには、ナビゲーターからプロジェクトを選択し、右クリックして「ファイル」 > 「新規」 > 「AssemblyLine」を選択します。AssemblyLine は、データを移動および変換するために組み合わされた一連のコンポーネントです。AssemblyLine は、データを渡す経路を記述します。この経路で処理されるデータは項目オブジェクトとして表現されます。AssemblyLineは、AssemblyLine の各サイクルで一度に 1 つの項目を処理します。これはTivoli Directory Integrator における作業単位であり、一般に 1 つ以上のデータ・ソースから 1 つ以上のターゲットへの情報のフローを表します。このAssemblyLine を TRIRIGA から実行する ETL ジョブ項目を作成するときは、新規 AssemblyLine に付けた名前を入力する必要があります。

v AssemblyLine のフックを追加するには、エディター領域で「オプション」 >「AssemblyLine のフック (AssemblyLine Hooks)」をクリックします。いずれかのフックの横にあるチェック・ボックスを有効にして、「閉じる」をクリックします。フックが追加されると、そのフックを選択して JavaScript コードを追加することができます。

v スクリプトを追加するには、エディター領域で Feed フォルダーまたは DataFlow フォルダーのいずれかを選択します。そのフォルダーを右クリックして、「コンポーネントの追加 (Add Component)」を選択します。スクリプトのフィルターを選択してから、コンポーネントを選択して「完了 (Finish)」をクリックします。AssemblyLine に追加されたスクリプトを選択し、ユーザー定義のJavaScript コード・ブロックを追加します。

v コネクターを追加するには、エディター領域で Feed フォルダーまたは DataFlow フォルダーのいずれかを選択します。そのフォルダーを右クリックして、「コンポーネントの追加 (Add Component)」を選択します。コネクターのフィルターを選択して、コンポーネントを選択し、「完了」をクリックします。AssemblyLine に追加されたコネクターを選択し、必要な構成データを指定します。

v 構成ファイルをインポートするには、「ファイル」 > 「インポート」をクリックした後、「IBM Tivoli Directory Integrator」および「構成」を選択します。「次へ」をクリックし、構成ファイルを指定してから「完了 (Finish)」をクリックします。プロジェクト名を要求するプロンプトが表示されたら、名前を入力して「完了 (Finish)」をクリックします。

Tivoli Directory Integrator の使用について詳しくは、IBM Tivoli DirectoryIntegrator バージョン 7.1.1 のインフォメーション・センター(http://publib.boulder.ibm.com/infocenter/tivihelp/v2r1/topic/com.ibm.IBMDI.doc_7.1.1/welcome.htm) を参照してください。


http://publib.boulder.ibm.com/infocenter/tivihelp/v2r1/topic/com.ibm.IBMDI.doc_7.1.1/welcome.htm

http://publib.boulder.ibm.com/infocenter/tivihelp/v2r1/topic/com.ibm.IBMDI.doc_7.1.1/welcome.htm

Tivoli Directory Integrator エージェント:

Tivoli Directory Integrator エージェントは、TRIRIGA 内から Tivoli DirectoryIntegrator ランタイム・サーバーを始動および停止するためのインターフェースを提供します。

スケジュール済み ETL プロセスは、以下のライセンスにより使用可能になります。

v 任意の IBM TRIRIGA ワークプレース・パフォーマンス管理ライセンス

v IBM TRIRIGA 不動産環境維持マネージャー・ライセンス

v IBM TRIRIGA 不動産環境維持影響マネージャー・ライセンス

v IBM TRIRIGA ワークプレース予約マネージャー・ライセンス

v 小規模インストール用の IBM TRIRIGA ワークプレース予約マネージャー・ライセンス

Tivoli Directory Integrator タイプの ETL ジョブ項目を正常に実行するには、Tivoli Directory Integrator サーバーが稼働している必要があります。TivoliDirectory Integrator サーバーが稼働していない場合は、ETL ジョブ項目が失敗し、エラーが TRIRIGA サーバー・ログに記録されます。

Tivoli Directory Integrator サーバーを始動または停止するには、管理者コンソールのエージェント・マネージャー・パネルに移動して Tivoli Directory Integrator エージェントを開始または停止します。開始すると、このエージェントがスケジュールに従って実行され、Tivoli Directory Integrator サーバーをモニターします。Tivoli Directory Integrator サーバーが稼働していないことを検出した場合は、再始動を試行します。

エージェント・マネージャー・パネルについて詳しくは、「IBM TRIRIGAApplication Platform 3 管理者コンソール・ユーザー・ガイド」を参照してください。

Tivoli Directory Integrator エージェントの構成:

Tivoli Directory Integrator サーバーが稼働しているかどうかを検査するためのプロパティーを構成することができます。

Tivoli Directory Integrator エージェントを実行するアプリケーション・サーバーのTDI_AGENT_SLEEPTIME プロパティーは、Tivoli Directory Integrator サーバーが稼動しているかどうかをエージェントが検査し、再始動を試行する頻度を制御します。

Tivoli Directory Integrator エージェントを実行するアプリケーション・サーバーのTDI_SERVER_TIMEOUT プロパティーは、Tivoli Directory Integrator サーバーの始動コマンドまたは停止コマンドが完了するまで待機する時間を制御します。この時間が過ぎると、障害と報告されます。

これらのプロパティーは TRIRIGAWEB.properties ファイルで定義されています。

Tivoli Directory Integrator エージェントのロギング:

Tivoli Directory Integrator エージェントに関する問題は server.log に記録されます。追加情報を入手するには、エージェントを実行しているサーバーの管理コンソ


ールでプラットフォームのロギング設定を変更することにより、Tivoli DirectoryIntegrator エージェントでデバッグ・ロギングをオンにします。

追加のロギング構成を行うには、エージェントを実行しているサーバーで log4j の設定を変更します。

例えば、標準の log4j 規約に従って Tivoli Directory Integrator サーバーに関する問題をモニターすることができます。Tivoli Directory Integrator エージェントは、Tivoli Directory Integrator サーバーを始動できない場合に log4j カテゴリー「com.tririga.platform.tdi.agent.TDIAgent.TDISTARTFAILED」にエラーを書き込みます。デフォルトでは、このカテゴリーに書き込まれたエラーは TRIRIGA サーバー・ログに記録されます。メール通知を送信するなど、別の動作を構成するには、そのカテゴリーを別の log4j アペンダーに書き込むように構成します。

Tivoli Directory Integrator 構成エディターからの変換の実行:

開発中の変換または完了した変換を実行するには、その変換を保存して、ツールバーから「実行」をクリックします。


エディター領域に、AssemblyLine と同じ名前の新しいウィンドウまたはタブが開きます。このウィンドウには、AssemblyLine の実行結果が表示されます。「デバッガー (Debugger)」ボタンを使用して、各ステップの実行時の入力ストリームの変更内容を表示することもできます。

Tivoli Directory Integrator 構成エディター変換の例:

以下では、Tivoli Directory Integrator 変換に必要ないくつかのステップの例について説明します。

既存の ETL ジョブ項目に含まれる「メーター項目ステージング・テーブルのロード」の .xml 構成ファイルのコピーをダウンロードして、ステップの説明と照らし合わせることができます。多くの初期状態の ETL は、同じフローをたどります。ただし、データを抽出する元となるデータベース表や、データの変換方法などの仕様が異なります。

この変換例では以下の処理を行います。

v この AssemblyLine で使用するロギング・パラメーター (ロガー・タイプ、ファイル・パス、添付、日付パターン、レイアウト・パターン、ログ・レベル、ログ有効化など) を指定します。

v DB-TRIRIGA 用に構成されている AssemblyLine 接続のパラメーターを使用して、データベース接続を確立します。

v 「アプリケーションの設定」テーブルから「エネルギー・ログ遅延時間」パラメーターを取得します。

v JDBC コネクターを使用して、「資産の毎時ファクト」テーブルからレコードを取得します。

v 入力属性マップを使用して、データベース列を内部の Tivoli DirectoryIntegrator 作業項目の属性にマップします


v Tivoli Directory Integrator フックおよびスクリプトを使用してデータ変換を実行します。

v JDBC コネクターを使用して、「環境メーター項目 (Environmental MeterItem)」ステージング・テーブルに対するレコードの挿入または更新を行います。

v 出力属性マップを使用して、JDBC 出力コネクターで構成されたテーブルのデータベース列に内部作業変数をマップします。

v 「成功時」フックを使用して以下の処理を実行します。

– 実行の処理統計をログに記録する

– errCount および errMsg を設定する

v Tivoli Directory Integrator の「失敗時」フックを使用して以下の処理を実行します。

– エラー・メッセージをログに記録する

– errCount および errMsg を設定する

以降のセクションでは、Tivoli Directory Integrator 変換の主要コンポーネントに関する詳細について説明します。ここでは、TRIRIGA に用意されている変換で使用する主要なコンポーネントに絞って説明します。Tivoli Directory Integrator には、変換の必要に応じてデータの操作に使用できる多くのコンポーネントが用意されています。

変換を作成するときには、以下のヒントを念頭に置いてください。

v AssemblyLine の作成時に使用可能なテスト機能を使用して、意図したとおりに変換が動作することを確認してください。

v 変換の開発は慎重に行う必要があります。例えば、特定のフィールドを使用して計算を行う場合は、すべての行でこれらのフィールドに値が設定されており、空のフィールドがない状態にする必要があります。そうしないと、変換が異常終了します。検証ロジックを追加して、計算で使用するすべてのフィールドに値が設定されていることを確認してください。

v AssemblyLine を正常に実行するためにヌルまたは未定義の変数が必要な場合は、ヌルまたは未定義の変数と戻りエラーの有無を確認してください。例えば、AssemblyLine で外部データベースに接続するために DB-OTHER 変数(jdbcOthUrl や jdbcOthDriver など) を使用する場合は、それらの変数が定義されていることを確認し、エラーの場合に適切に処理する必要があります。

v TRIRIGA がサポートするデータベースはいずれも日付フィールドに日付と時刻を保持するため、日付の処理は容易ではありません。

v ソリューションで複数のデータベース・プラットフォーム (DB2、Oracle、および Microsoft SQL Server) を実行する必要がある場合は特に、必ずAssemblyLine 接続を使用し、変換データベースに依存関係がないようにしてください。

v Tivoli Directory Integrator 変換を実行する前に AssemblyLine 接続をテストしてください。さもなければ、データベース接続エラーが発生して変換が終了することがあります。


ロガーの構成:

AssemblyLine ロガーを構成し、このアセンブリーで使用するロギング・パラメーター (ロガー・タイプ、ファイル・パス、添付、日付パターン、レイアウト・パターン、ログ・レベル、ログ有効化など) を指定します。


注: 変換を TRIRIGA から実行したときに TRIRIGA が ETL ロギングを正しく処理するように、以下のログ設定の規約に従ってください。

v ファイル・パスを設定するときには、相対パス ../../log/TDI/log name を指定してください。ここで、log name は AssemblyLine の名前です。例えば、ファイル・パスを ../../log/TDI/triLoadMeterData.log とします。これにより、triLoadMeterData.log を他の TRIRIGA ログとともに TRIRIGA 管理コンソールから表示できるようになります。

v DailyRollingFileAppender のロガー・タイプを他の TRIRIGA ログと整合させてください。

これらのログ設定は、変換を構成エディターから実行するときに作成されるログに適用されます。一部の値は、TRIRIGA ETL ジョブ項目から変換を呼び出すときにオーバーライドされます。Tivoli Directory Integrator ログを TRIRIGA ログと整合させ、TRIRIGA ログと同じ方法で構成できるようにするために、ログ・レベル、日付パターン、およびレイアウト・パターンは、TRIRIGA の log4j 用 .xml ファイルで指定された値でオーバーライドされます。

手順

エディター領域で「オプション」 > 「ログ設定 (Log Settings)」をクリックしてAssemblyLine ロガーを構成し、このアセンブリーで使用するロギング・パラメーターを指定します。

例

例の中では、ファイル・パスを ../../log/TDI/triLoadMeterData.log に設定したDailyRollingFileAppender ログを構成しています。AssemblyLine フックは、以下のようなコマンドを起動することでこのログにデータを書き込むことができます。

var methodName = "triLoadMeterData - LookupMeterItemDTO ";task.logmsg("DEBUG", methodName + "Entry");

AssemblyLine の初期化:

AssemblyLine の初期化時に、スクリプト・エンジンが開始され、AssemblyLine のProlog フックが起動されます。

手順

1. エディター領域で、「オプション」 > 「AssemblyLine フック(AssemblyLine Hooks)」をクリックして AssemblyLine フックを作成し、「Prolog – Before Init」チェック・ボックスを有効にします。

2. 以下の JavaScript コードをスクリプトに追加し、データベース接続を確立して、「アプリケーションの設定」パラメーターを取得します。


catch (err){task.logmsg("INFO", methodName + "Setting Default Values for

Application Settings");energyLogLagTime=5}

task.logmsg("INFO", methodName + "energyLogLagTime:" + energyLogLagTime);result = rs1.next();

}rs1.close();selectStmt1.close();

3. AssemblyLine フックを保存します。

例

ここに示す例では、「Prolog - Before Init」フックで以下のタスクが実行されます。

v AssemblyLine に渡される Tivoli Directory Integrator 変換変数を取得します。このタスクは、AssemblyLine が ETL ジョブ項目から実行される場合にのみ行われます。AssemblyLine が構成エディターから起動されるときに、Prolog でJDBC 接続パラメーターを構成する必要があります。

v データベース接続を確立します。

v 「アプリケーションの設定」レコードから AssemblyLine に固有の設定を取得します。

データの取得:

データは、コネクターやなんらかの入力モードを使用して接続先システムからAssemblyLine に入力されます。

ここに示す例では、JDBC コネクターおよび属性マップを使用してデータをAssemblyLine に提供します。

コネクター

テーブル入力 (Table Input) は、ほとんどのデータのソースです。ここで、初期化中に AssemblyLine に渡したデータベース接続パラメーターを使用してテーブルからデータを抽出するためのコネクターをセットアップします。

ここに示す例では、JDBCConnectorToHourlyFact というコネクターが毎時ファクト・テーブルから入力行を取得します。このコンポーネントは、AssemblyLine のフィード・セクションに追加されています。

「接続」タブにより、JDBC 接続パラメーターを構成することができます。例の中では、「拡張」(Javascript) を使用して初期化中に AssemblyLine に渡された接続パラメーターを取得しています。さらに、「SQL Select (SQL Select)」フィールドの「拡張」セクションで以下の SQL 照会を指定し、データベース表から取得するデータの範囲を絞り込みます。

select * from T_TRIASSETENERGYUSEHFACT where TRIMAINMETERBL in ('TRUE') andTRI-MAINMETERPROCESSEDN = 0 order by TRIWRITETIMETX.


ヒント: コネクターに対する SQL ステートメントのロギングを有効にするには、コネクターの「接続」タブにある「詳細ログ (Detailed Log)」チェック・ボックスを有効にします。

属性マップ

特定の複数のフィールドに確実に値を設定したり 1 つのフィールドに別の値を設定したりするには、コネクター属性マップを使用します。属性マップでは、ソース・フィールドの値に基づいて値をターゲット・フィールドに設定できます。ターゲット・フィールドを指定しなければ、フィールドを、ターゲット・フィールドではなくデフォルト値に設定できます。

JDBCConnectorToHourlyFact コネクターをクリックしてから「入力マップ (InputMap)」タブをクリックすると、属性マップが表示されます。例の中では、マップを使用していくつかのフィールドにデフォルト値を設定しています。

1 番目のコネクターの処理が完了すると、情報のバケツ (「作業エントリー」つまり「処理」) が AssemblyLine に沿って次のコンポーネントに渡されます。

スクリプト:

スクリプトを追加して、ユーザー定義の JavaScript コード・ブロックを実装することができます。

ここに示す例では、スクリプト機能を使用して AssemblyLine にカスタム処理を追加します。以下のセクションでは、スクリプト機能の使用方法をいくつか説明します。

検証

付属の例の中では、下記のスクリプトに示すように入力データのフィールドを検証します。

var methodName = "triLoadMeterData - JDBCConnectorToHourlyFact -GetNext Successful ";

task.logmsg("DEBUG", methodName + "Entry");

rowsProcessed = parseInt(rowsProcessed) + 1;

var SPEC_ID = work.SPEC_ID.getValue();task.logmsg("DEBUG", methodName + "SPEC_ID: " + SPEC_ID);

// Verify Required Fields and do not process record is anyvalues are missingvalidData = true;if (work.TRICAPTUREDDT.getValue() == null){task.logmsg("ERROR", methodName + "TRICOSTNU is null.");validData=false;}if (work.TRICOSTNU.getValue() == null){task.logmsg("ERROR", methodName + "TRICOSTNU is null.");validData=false;}if (work.TRICOSTNU_UOM.getValue() == null){task.logmsg("ERROR", methodName + "TRICOSTNU_UOM is null.");


validData=false;}if (work.TRIDIMASSETTX.getValue() == null){task.logmsg("ERROR", methodName + "TRIDIMASSETTX is null.");validData=false;}if (work.TRIENERGYTYPECL.getValue() == null){task.logmsg("ERROR", methodName + "TRIENERGYTYPECL is null.");validData=false;}if (work.TRIENERGYTYPECLOBJID.getValue() == null){task.logmsg("ERROR", methodName + "TRIENERGYTYPECLOBJID is null.");validData=false;}if (work.TRIMETERIDTX.getValue() == null){task.logmsg("ERROR", methodName + "TRIMETERIDTX is null.");validData=false;}if (work.TRIRATENU.getValue() == null){task.logmsg("ERROR", methodName + "TRIRATENU is null.");validData=false;}if (work.TRIRATENU_UOM.getValue() == null){task.logmsg("ERROR", methodName + "TRIRATENU_UOM is null.");validData=false;}if (work.TRIWRITETIMETX.getValue() == null){task.logmsg("ERROR", methodName + "TRIWRITETIMETX is null.");validData=false;}

if (!validData){rowsNotValid = rowsNotValid + 1;task.logmsg("ERROR", methodName + "Record will NOT be processed.");var selectStmt1 = conn1.createStatement();

var query = "update " + tableName + " set TRIMAINMETERPROCESSEDN =3 where SPEC_ID = ¥'" + SPEC_ID + "¥'";

task.logmsg("DEBUG", methodName + "query:" + query);var count = selectStmt1.executeUpdate(query);task.logmsg("DEBUG", methodName + "Update count:" + count);selectStmt1.close();system.exitBranch();

}

データのフィルタリング

付属の例の中には、レコードを処理する必要があるかどうかを判別するスクリプトがあります。下記のスクリプトには条件ステートメントが存在し、2 つの日付フィールドを比較しています。条件が true の場合は system.exitBrankch() メソッドを呼び出し、現行レコードをスキップします。

// Should we process this record?if (capturedDT < earliestDateUTC){

task.logmsg("DEBUG", methodName + "Skip!");rowsSkipped = rowsSkipped + 1;

// Set triMainMeterProcessedNU=2 flag in T_TRIASSETENERYUSEHFACT table


// indicating that we will not process this recordvar selectStmt1 = conn1.createStatement();var query = "update " + tableName + " set TRIMAINMETERPROCESSEDN =

2 where SPEC_ID = ¥'" + SPEC_ID + "¥'";task.logmsg("DEBUG", methodName + "query:" + query);var count = selectStmt1.executeUpdate(query);task.logmsg("DEBUG", methodName + "Update count:" + count);selectStmt1.close();system.exitBranch();

}

DB プロシージャーの呼び出し

JavaScript からストアード・プロシージャーを呼び出すことができます。情報はこのプロシージャーを通って、変換に戻ることができます。

付属の例の中ではストアード・プロシージャー呼び出しを実装していませんが、以下に例を示します。これは、ファクト・テーブル・エントリーのシーケンスを作成する方法の例です。ここでは、DB2、SQL Server、または Oracle のいずれかでNEXTVAL という DB プロシージャーを呼び出します。NEXTVAL ストアード・プロシージャーの例を以下に示します。

// Stored procedure calltask.logmsg("DEBUG", methodName + "Call Stored Procedure")var command = "{call NEXTVAL(?,?,?)}";try{

cstmt = conn2.prepareCall(command);cstmt.setString(1, "SEQ_FACTSOID");cstmt.setInt(2, 1);cstmt.registerOutParameter(3, java.sql.Types.INTEGER);cstmt.execute();result = cstmt.getInt(3);task.logmsg("DEBUG", methodName + "Result:" + result);work.setAttribute("SPECID", result)cstmt.close();

}catch (e){

task.logmsg("DEBUG", "Stored Procedure call failed with exception:" + e);}

検索コネクターの使用による各種データ・ソースからのデータの結合:

各種データ・ソースからのデータを結合できる検索を実行することが可能です。このアクションは、カスタム・スクリプトを使用するか検索コネクターを使用して実装することができます。


ここに示す例では、スクリプトを使用してデータベース検索を実行し、追加のデータを抽出してデータ・ストリームに転送します。

手順

1. エディター領域で「データ・フロー (Data Flow)」をクリックし、スクリプトを作成します。

2. 「コンポーネントの追加 (Add Component)」をクリックし、「空のスクリプト (Empty Script)」コンポーネントを選択して「完了 (Finish)」をクリックします。


3. メーター項目 DTO テーブルのレコードを検索するための以下の JavaScript コードをスクリプトに追加します。

var methodName = "triLoadMeterData - LookupMeterItemDTO ";

task.logmsg("DEBUG", methodName + "Entry");

// Lookup Meter Item DTO recordvar recordFound = false;var selectStmt1 = conn1.createStatement();var rs1 = selectStmt1.executeQuery("select DC_SEQUENCE_ID,TRICOSTPERUNITNU, TRIQUANTITYNU from S_TRIENVMETERITEMDTO1where TRIMETERIDTX = ¥'" + work.TRIMETERIDTX.getValue() + "¥'and TRITODATEDA = " + TRITODATEDA );var result = rs1.next();while (result){...}rs1.close();selectStmt1.close();

データ・ソースへのエントリーの出力:

出力中には、変換されたデータが AssemblyLine に沿ってなんらかの出力モードの別の JDBC コネクターに渡され、さらに接続先システムに出力されます。接続先システムはレコード単位であるため、作業の各種の属性は、出力属性マップを使用してレコードの列にマップされます。

コネクター

テーブル出力 (Table output) は、大部分のデータのターゲットです。ここで、初期化中にアセンブリー・ラインに渡したデータベース接続パラメーターを使用してテーブルに対するデータの挿入または更新を行うための JDBC コネクターをセットアップします。

ここに示す例では、JDBCConnectoToMeterItemDTO というコネクターを使用して情報を TRIRIGA 環境メーター・ログ・ステージング・テーブルに格納します。保存する情報がすべて生成されたら、このコンポーネントを AssemblyLine の終端に追加します。

コネクターの「リンク基準 (Link Criteria)」タブは、出力テーブル更新用の SQLステートメントの生成に使用する以下の基準を指定するために使用します。ここに示す例では、基準に以下のエントリーが含まれています。

v TRIMETERIDTX equals $TRIMETERIDTX

v TRITODATEDA equals $TRITODATEDA

ヒント: $ を使用して、その後に続く変数名を内部の作業エントリーの値で置き換えるように指示しています。

属性マップ

コネクターは出力属性マップを持っており、内部の作業変数と出力テーブルの列名の間のマッピングを指定するために使用します。


「JDBCConnectorToMeterItemDTO」コンポーネントを選択してから「出力マップ(Output Map)」タブをクリックします。「出力マップ (Output Map)」ページが開きます。このページを使用して、ソース・フィールドをターゲット・データベースのターゲット・フィールドにマップします。ソース・フィールドには、入力ストリームに追加される追加フィールドも含まれている点に注意してください。

ETL ジョブ項目への状況の伝搬:

ETL ジョブ項目から変換が実行されたときに状況を TRIRIGA に報告するためのerrCount および errMsg 作業属性にデータを取り込む「成功時」および「失敗時」の両方のフックが、すべてのスクリプトに含まれている必要があります。


errCount 作業属性は、AssemblyLine ファイルの実行時に検出されたエラーの数です。errMsg 作業属性は、TRIRIGA ログに書き込まれるエラー・メッセージです。

手順

1. AssemblyLine フックを追加するには、エディター領域で、「オプション」 >「AssemblyLine フック (AssemblyLine Hooks)」をクリックします。

2. 「成功時」および「失敗時」フックの横にある各チェック・ボックスを選択し、「閉じる」をクリックします。

3. 以下のコードを使用して、「成功時」フックを変更し、errCount およびerrMsg 作業属性を設定します。

// Set errCount and errMessage for ALif (task.getResult() == null) {

var result = system.newEntry();result.errCount = errCount;result.errMsg='Assembly line completed successfully.';task.setWork(result);

}else{

work.errCount = errCount;work.errMsg='Assembly line completed successfully.';

}

4. 以下のコードを使用して、「失敗時」フックを変更し、errCount およびerrMsg 作業属性を設定します。

// Set errCount and errMessage for triDispatcher ALif (task.getResult() == null) {

var result = system.newEntry();result.errCount = 1;result.errMsg='Assembly line failed.';task.setWork(result);

}else{

work.errCount = 1;work.errMsg='Assembly line failed.';

}

Tivoli Directory Integrator での変換のテスト:

各ステップの後でテストを行うと、デバッグが容易になります。


変換を実行する前に、変換を保存しておく必要があります。そうしないと、前回保存した後に加えた変更が反映されないまま Tivoli Directory Integrator がAssemblyLine を起動してしまいます。

AssemblyLine を開発しながらテストすることができます。方法として、AssemblyLine を最後まで実行する方法と、コンポーネントを 1 つずつステップ実行する方法があります。AssemblyLine を実行するための 2 つのボタンが用意されています。「コンソールで実行 (Run in Console)」アクションは、AssemblyLineを開始して出力を「コンソール」ビューに表示します。「デバッガー (Debugger)」アクションは、デバッガーで AssemblyLine を実行します。

AssemblyLine の開始処理は以下のステップで実行されます。

1. AssemblyLine にエラーがある場合 (出力マップがないなど)、AssemblyLine の実行を確認するプロンプトが出され、メッセージ「この AssemblyLine には 1つ以上のエラーが含まれています。実行を続行しますか?」が表示されます。

2. 次の検査は、Tivoli Directory Integrator サーバーが使用可能かどうかです。サーバーにアクセスできない場合は、メッセージ「サーバー Default.tdiserverへの接続を取得できません。」が表示されます。

3. 最後に、構成エディターがランタイム構成をサーバーに転送し、AssemblyLineが開始されるのを待機します。この段階では、ウィンドウの右上部分に進行状況表示バーが表示されます。AssemblyLine がまだ開始していないため、停止するためのツールバー・ボタンもぼかし表示になっています。AssemblyLine が実行中になると、進行状況表示バーが回転し、ログ・ウィンドウにメッセージが表示されるようになります。この状態で AssemblyLine を停止するには、ツールバーの「停止」アクションをクリックします。

Tivoli Directory Integrator から TRIRIGA への ETL スクリプトの移動:

変換が完成し、テストが終了したら、その変換を TRIRIGA ETL ジョブ項目にアップロードする必要があります。

ETL 環境と TRIRIGA の間のフローについて以下の図で説明します。


TRIRIGA データベース AssemblyLine 接続のセットアップ:

ランタイム構成ファイルを TRIRIGA ETL ジョブ項目レコードにアップロードする前に、初期化時に Tivoli Directory Integrator アセンブリーに渡されるパラメーターを使用して、TRIRIGA データベース AssemblyLine 接続を構成する必要があります。

手順

1. 「システム管理」 > 「システム・セットアップ」 > 「一般」 > 「アプリケーションの設定」をクリックします。

2. 「環境設定」タブの「AssemblyLine 設定 (AssemblyLine Settings)」セクションで、データベース AssemblyLine 接続を構成します。

a. 必須: TRIRIGA データベースへの接続として DB-TRIRIGA を構成します。この接続を構成しないと、Tivoli Directory Integrator ETL ジョブ項目が実行されません。

b. オプション: Tivoli Directory Integrator AssemblyLine が外部データベースに接続する必要がある場合は、DB-OTHER を構成します。 DB-OTHERはオプションであるため、TRIRIGA は DB-OTHER が設定されていることを検証しません。そのため、AssemblyLine は、この接続を使用する前に接続が設定されていることを検査する必要があります。

3. 「テスト DB 接続」をクリックして、データ接続が正常であることを確認します。

AssemblyLine パラメーターの取得:

TRIRIGA データベース AssemblyLine 接続の構成が完了したら、AssemblyLineを変更してパラメーターを取得します。

手順

1. AssemblyLine を初期化する Prolog スクリプトを開きます。


2. 以下のステートメントを追加して、TRIRIGA-DB 接続パラメーターを取得します。

var op = task.getOpEntry();var jdbcTriURL = op.getString("jdbcTriURL");var jdbcTriDriver = op.getString("jdbcTriDriver");var jdbcTriUser = op.getString("jdbcTriUser");var jdbcTriPassword = op.getString("jdbcTriPassword");

3. 以下のステートメントを追加して、OTHER-DB 接続パラメーターを取得します。

var op = task.getOpEntry();var jdbcOthURL = op.getString("jdbcOthURL");var jdbcOthDriver = op.getString("jdbcOthDriver");var jdbcOthUser = op.getString("jdbcOthUser");var jdbcOthPassword = op.getString("jdbcOthPassword");

4. 変更を保存します。

ETL スクリプトの TRIRIGA への移動:

Tivoli Directory Integrator 構成エディターで ETL スクリプトを作成したら、そのスクリプトを TRIRIGA に移動する必要があります。


Tivoli Directory Integrator 構成エディターは、ランタイム構成ファイルをWorkspace/ProjectName/Runtime-ProjectName/ProjectName.xml に自動的に保管します。

手順

1. 「ジョブ項目タイプ」フィールドを「Tivoli Directory Integrator 変換」に設定して、ETL ジョブ項目レコードを作成します。

2. 「アセンブリー・ライン名」フィールドを、構成ファイルをロードした後に開始する AssemblyLine の名前に設定します。

3. 構成エディターで作成したランタイム構成ファイルをアップロードすることにより、「ファイルの変換」フィールドを設定します。

4. オプション: ETL 変換でファイルが入力として必要になる場合は、そのファイルを ETL ジョブ項目にリソース・ファイルとして関連付けます。例えば、ETL 変換がスプレッドシート・ファイルからのデータを処理する必要がある場合、そのファイルをリソース・ファイルとして関連付ける必要があります。

a. 「リソース・ファイル」セクションで、「追加」をクリックします。

b. 「リソース名」を、リソース・ファイルの識別に使用される名前に設定します。この名前は、TRIRIGA が ETL 変換に送信する一時リソース・ファイル名の一部になります。このことは、複数のリソース・ファイルを ETL ジョブ項目に関連付ける場合に役立ちます。送信される複数のファイルをETL 変換が名前で識別できるようになるためです。

c. 「リソース・ファイル」フィールドを設定するには、そのフィールドの横にある「リソース・ファイルのアップロード (Upload Resource File)」アイコンをクリックしてファイルの場所を指定し、「OK」をクリックして、当該ファイルを「リソース・ファイル」フィールドにアップロードします。


Tivoli Directory Integrator に渡される変数:

TRIRIGA は、いくつかの入力変数を Tivoli Directory Integrator ETL に渡します。

AssemblyLine でこれらの変数を使用するには、Tivoli Directory IntegratorgetOpEntry() インターフェースからアクセスします。例えば、var op =task.getOpEntry(); var jdbcTriURL = op.getString("jdbcTriURL"); とします。

TRIRIGA は、ETL ジョブ項目レコードからフィールド値を抽出して入力パラメーターとして渡します。サポートされるフィールド・タイプはテキスト、ブール値、日付、日時、ロケーター、および数値です。このタイプの ETL ジョブ項目フィールドは、すべて変数として渡されます。

ETL ジョブ項目に以下のフィールドがある場合は、2 番目の表の変数が TivoliDirectory Integrator に渡されます。

表 6. ETL ジョブ項目のフィールド


triActiveEndDA アクティブな終了日日付

triActiveStartDA アクティブな開始日日付

triControlNumberCN 制御番号制御番号

triCreatedByTX 作成者テキスト

triLocator triLocator テキスト

triNameTX 名前テキスト

triTransformBI ファイルの変換バイナリー

Tivoli Directory Integrator に渡される変数は以下のとおりです。

表 7. Tivoli Directory Integrator に渡される変数

Tivoli Directory Integrator に渡される変数説明

triNameTX (テキスト)

triActiveStartDA (数値) 1970 年 1 月 1 日以降のミリ秒数で表した日付

triActiveStartDA_DATE (日付) Oracle または DB2 の場合はラップされます。時刻は属性に設定されている時刻です

triActiveStartDA_MinDATE (日付) Oracle または DB2 の場合はラップされます。時刻は 00:00:00 です

triActiveStartDA_MaxDATE (日付) Oracle または DB2 の場合はラップされます。時刻は 23:59:59 です

triActiveStartDA_Min (数値) 1970 年 1 月 1 日以降のミリ秒数で表した日付。時刻は 00:00:00 です

triActiveStartDA_Max (数値) 1970 年 1 月 1 日以降のミリ秒数で表した日付。時刻は 23:59:59 です



表 7. Tivoli Directory Integrator に渡される変数 (続き)


triActiveEndDA_DATE (日付) Oracle または DB2 の場合はラップされます。時刻は属性に設定されている時刻です

triActiveEndDA_MinDATE (日付) Oracle または DB2 の場合はラップされます。時刻は 00:00:00 です

triActiveEndDA_MaxDATE (日付) Oracle または DB2 の場合はラップされます。時刻は 23:59:59 です

triActiveEndDA_Min (数値) 1970 年 1 月 1 日以降のミリ秒数で表した日付。時刻は 00:00:00 です

triActiveEndDA_Max (数値) 1970 年 1 月 1 日以降のミリ秒数で表した日付。時刻は 23:59:59 です

triCreatedByTX (テキスト)

triRunDATE (数値) カスタム・ワークフロー・タスクによって設定された実行日

triLocator (テキスト – ロケーター) 別のビジネス・オブジェクトへの参照を含むロケーター・フィールド。この変数には、そのレコードのフィールドのテキスト値が含まれています。

triLocator_IBS_SPEC (テキスト - ロケーター) triLocator フィールド内のレコードの spec_id が含まれています。この spec_id を使用して、他のデータベース表を通じてそのレコードの関連情報を検索できます。

triAssemblyLineNameTX 実行する ETL 変換のメイン AssemblyLineの名前

TRIRIGA はリソース・ファイル変数も渡します。リソース・ファイルは、ETL 変換時に入力として必要なファイルです。例えば、ETL 変換でコンマ区切り値 (.csv)ファイルからのデータを処理する必要がある場合は、実行時にそのファイルを参照するための場所と方法に関する情報が必要です。

ETL ジョブ項目に 2 つのリソース・ファイル・レコードが関連している場合は、それぞれに以下のフィールドが含まれます。

表 8. リソース・ファイル・レコードに関連したフィールド


triResourceNameTX リソース・ファイルの識別に使用される名前

テキスト

triResourceFileBI リソース・ファイルの内容バイナリー

これらのリソース・ファイル・レコードの場合に Tivoli Directory Integrator に渡される変数は以下のとおりです。


表 9. Tivoli Directory Integrator に渡される変数


RESOURCE_1 リソース・ファイルの完全修飾ファイル名。ファイル名には triResourceNameTX フィールドからの値が含まれ、ETL 変換時の識別に使用されます

RESOURCE_2 その他のリソース・ファイルの完全修飾ファイル名。ファイル名にはtriResourceNameTX フィールドからの値が含まれ、ETL 変換時の識別に使用されます

表 10. TRIRIGA は、「アプリケーションの設定」で定義されている JDBC 入力変数も渡します。


jdbcTriURL TRIRIGA データベース・ドライバーの URL

jdbcTriDriver TRIRIGA データベース・ドライバーの名前

jdbcTriUser TRIRIGA データベース・ユーザー名

jdbcTriPassword TRIRIGA データベース・パスワード

jdbcOthURL その他のデータベース・ドライバーの URL

jdbcOthDriver その他のデータベース・ドライバー名

jdbcOthUser その他のデータベース・ユーザー名

jdbcOthPassword その他のデータ

アプリケーションでの ETL スクリプトのデバッグ:

アプリケーションで ETL スクリプトをデバッグするには、最初にロギングをセットアップしてから、RunETL カスタム・ワークフロー・タスクをトリガーしてログ情報を表示する必要があります。

ロギングのセットアップ:

TRIRIGA には、TRIRIGA アプリケーションでの ETL スクリプトの実行時に使用できるデバッグ機能が備えられています。

手順

1. 管理者コンソールで、プラットフォーム・ロギング管理対象オブジェクトを選択します。次に、ETL ロギングを使用可能にするオプションを選択します。

2. 「カテゴリー ETL (Category ETL)」 > 「変換 (Transforms)」 > 「変換の実行 (Run Transform)」を選択して、ETL ジョブ項目を処理する TRIRIGA プラットフォーム・コードでのデバッグ・ロギングをオンにします。ログ・メッセージが server.log に出力されます。

3. 「カテゴリー ETL (Category ETL)」 > 「変換 (Transforms)」 > 「TivoliDirectory Integrator」を選択して、Tivoli Directory Integrator AssemblyLineでのデバッグ・ロギングをオンにします。ログ・メッセージが AssemblyLineログに出力されます。各 AssemblyLine には専用のログ・ファイルがあります。


4. 変更を適用します。これで、ETL スクリプトの実行時に、ETL 関連情報がサーバー・ログまたは AssemblyLine ログに記録されます。

重要: ログに大量の情報が表示される可能性があるため、ETL ジョブ項目の 1回の実行についてのみデバッグするように Tivoli Directory Integrator ロギングを設定してください。

ETL ジョブを使用したデバッグ:

ロギングのセットアップが完了したら、ログに記録されている情報を確認するために RunETL カスタム・ワークフロー・タスクをトリガーする必要があります。

手順

ETL ジョブ項目を使用している場合は、当該フォームの「プロセスの実行」をクリックするだけです。フォームのフィールドには必ず、ETL スクリプトで受け入れられる値を入力してください。

注: 「プロセスの実行」アクションは、デバッグ目的でのみ使用してください。実稼働環境では、代わりにジョブ・スケジューラーを使用してください。「プロセスの実行」ではデータベースのテーブルが更新されるため、実稼働環境ではこのアクションを使用しないでください。

例

以下は、サーバー・ログ出力のサンプルです。

2014-03-27 13:18:10,427 DEBUG [com.tririga.platform.workflow.runtime.taskhandler.ETL.RunETL](WFA:221931 - 15290804 triProcessManual:305676189 IE=305676189)Entry: getETLVarsFromFields...2014-03-27 13:18:10,431 DEBUG [com.tririga.platform.workflow.runtime.taskhandler.ETL.RunETL](WFA:221931 - 15290804 triProcessManual:305676189 IE=305676189)Exit: getETLVarsFromFields2014-03-27 13:18:10,431 DEBUG [com.tririga.platform.workflow.runtime.taskhandler.ETL.RunETL](WFA:221931 - 15290804 triProcessManual:305676189 IE=305676189)Entry: getETLVarsFromResourceFiles2014-03-27 13:18:10,432 DEBUG [com.tririga.platform.workflow.runtime.taskhandler.ETL.RunETL](WFA:221931 - 15290804 triProcessManual:305676189 IE=305676189)Exit: getETLVarsFromResourceFiles2014-03-27 13:18:10,432 DEBUG [com.tririga.platform.workflow.runtime.taskhandler.ETL.RunETL](WFA:221931 - 15290804 triProcessManual:305676189 IE=305676189)Processing Job Item with Type = Tivoli Directory Integrator Transformation2014-03-27 13:18:10,432 DEBUG [com.tririga.platform.workflow.runtime.taskhandler.ETL.RunETL](WFA:221931 - 15290804 triProcessManual:305676189 IE=305676189)Entry: transformRecordTDI2014-03-27 13:18:10,474 DEBUG [com.tririga.platform.workflow.runtime.taskhandler.ETL.TDIRequest](WFA:221931 - 15290804 triProcessManual:305676189 IE=305676189)Entry: init2014-03-27 13:18:10,474 DEBUG [com.tririga.platform.workflow.runtime.taskhandler.ETL.TDIRequest](WFA:221931 - 15290804 triProcessManual:305676189 IE=305676189)Exit: init2014-03-27 13:18:10,483 DEBUG [com.tririga.platform.workflow.runtime.


taskhandler.ETL.RunETL](WFA:221931 - 15290804 triProcessManual:305676189 IE=305676189) ***ETL Variable = triIdTX : triLoadMeterData2014-03-27 13:18:10,483 DEBUG [com.tririga.platform.workflow.runtime.taskhandler.ETL.RunETL](WFA:221931 - 15290804 triProcessManual:305676189 IE=305676189) ***ETL Variable = triAssemblyLineNameTX : triLoadMeterData...2014-03-27 13:18:10,483 DEBUG [com.tririga.platform.workflow.runtime.taskhandler.ETL.RunETL](WFA:221931 - 15290804 triProcessManual:305676189 IE=305676189)*** ETL Variable = triNameTX :メーター項目ステージング・テーブルのロード2014-03-27 13:18:10,488 DEBUG [com.tririga.platform.workflow.runtime.taskhandler.ETL.DataSourceConnectionInfoImpl] (WFA:221931 - 15290804triProcessManual:305676189 IE=305676189)Entry: init2014-03-27 13:18:10,495 DEBUG [com.tririga.platform.workflow.runtime.taskhandler.ETL.DataSourceConnectionInfoImpl](WFA:221931 - 15290804 triProcessManual:305676189 IE=305676189)Exit: init2014-03-27 13:18:10,495 DEBUG [com.tririga.platform.workflow.runtime.taskhandler.ETL.DataSourceConnectionInfoImpl](WFA:221931 - 15290804 triProcessManual:305676189 IE=305676189)Entry: init2014-03-27 13:18:10,496 DEBUG [com.tririga.platform.workflow.runtime.taskhandler.ETL.DataSourceConnectionInfoImpl](WFA:221931 - 15290804 triProcessManual:305676189 IE=305676189)Exit: init2014-03-27 13:18:10,497 INFO [com.tririga.platform.workflow.runtime.taskhandler.ETL.RunETL](WFA:221931 - 15290804 triProcessManual:305676189 IE=305676189)Setting TDI log level to Debug.2014-03-27 13:18:10,503 DEBUG [com.tririga.platform.workflow.runtime.taskhandler.ETL.LogSettingsServiceImpl](WFA:221931 - 15290804 triProcessManual:305676189 IE=305676189)Entry: getLogSettings2014-03-27 13:18:10,503 DEBUG [com.tririga.platform.workflow.runtime.taskhandler.ETL.LogSettingsServiceImpl](WFA:221931 - 15290804 triProcessManual:305676189 IE=305676189)Found DailyRollingFileAppender.2014-03-27 13:18:10,503 DEBUG [com.tririga.platform.workflow.runtime.taskhandler.ETL.LogSettingsServiceImpl](WFA:221931 - 15290804 triProcessManual:305676189 IE=305676189)Exit: getLogSettings2014-03-27 13:18:10,503 DEBUG [com.tririga.platform.workflow.runtime.taskhandler.ETL.TDIRequest](WFA:221931 - 15290804 triProcessManual:305676189 IE=305676189)Entry: send2014-03-27 13:18:14,396 DEBUG [com.tririga.platform.workflow.runtime.taskhandler.ETL.TDIRequest](WFA:221931 - 15290804 triProcessManual:305676189 IE=305676189)Exit: send2014-03-27 13:18:14,396 INFO [com.tririga.platform.workflow.runtime.taskhandler.ETL.RunETL](WFA:221931 - 15290804 triProcessManual:305676189 IE=305676189)RunETL request returned fromTDI server version: 7.1.1.3 - 2013-12-06 running on host: i3650x3cr22014-03-27 13:18:14,396 INFO [com.tririga.platform.workflow.runtime.taskhandler.ETL.RunETL]


(WFA:221931 - 15290804 triProcessManual:305676189 IE=305676189)RunETL: Prepare=2014/03/2713:18:10.475 Start=2014/03/27 13:18:10.503 Stop=2014/03/27 13:18:14.3962014-03-27 13:18:14,396 INFO [com.tririga.platform.workflow.runtime.taskhandler.ETL.RunETL](WFA:221931 - 15290804 triProcessManual:305676189 IE=305676189)RunETL: Processing endedafter 3 seconds.2014-03-27 13:18:14,396 DEBUG [com.tririga.platform.workflow.runtime.taskhandler.ETL.RunETL](WFA:221931 - 15290804 triProcessManual:305676189 IE=305676189)Exit: transformRecordTDI

以下は、AssemblyLine ログのサンプルです。

2014-03-27 13:18:11,062 INFO [org.apache.log4j.DailyRollingFileAppender.a9e2d096-4cdc-4f87-a57b-5e31323093d9]CTGDIS967I AssemblyLine started by triLoadMeterData_1395951491025.2014-03-27 13:18:11,063 INFO [org.apache.log4j.DailyRollingFileAppender.a9e2d096-4cdc-4f87-a57b-5e31323093d9]CTGDIS255I AssemblyLine AssemblyLines/triLoadMeterData is started.2014-03-27 13:18:11,073 DEBUG [org.apache.log4j.DailyRollingFileAppender.a9e2d096-4cdc-4f87-a57b-5e31323093d9]CTGDIS089I Current statistics: Interval=0, Maximum Errors=0, Maximum Read=02014-03-27 13:18:11,073 DEBUG [org.apache.log4j.DailyRollingFileAppender.a9e2d096-4cdc-4f87-a57b-5e31323093d9]CTGDIS069I Loading Connectors....2014-03-27 13:18:14,384 DEBUG [org.apache.log4j.DailyRollingFileAppender.a9e2d096-4cdc-4f87-a57b-5e31323093d9]triLoadMeterData - On Success Entry2014-03-27 13:18:14,384 INFO [org.apache.log4j.DailyRollingFileAppender.a9e2d096-4cdc-4f87-a57b-5e31323093d9]triLoadMeterData - On Success Processing Success2014-03-27 13:18:14,384 INFO [org.apache.log4j.DailyRollingFileAppender.a9e2d096-4cdc-4f87-a57b-5e31323093d9]triLoadMeterData - On Success -----------------------------------------------------------------------------

2014-03-27 13:18:14,384 INFO [org.apache.log4j.DailyRollingFileAppender.a9e2d096-4cdc-4f87-a57b-5e31323093d9]triLoadMeterData - On Success Processing Summary2014-03-27 13:18:14,384 INFO [org.apache.log4j.DailyRollingFileAppender.a9e2d096-4cdc-4f87-a57b-5e31323093d9]triLoadMeterData - On Success rowsProcessed = 3602014-03-27 13:18:14,384 INFO [org.apache.log4j.DailyRollingFileAppender.a9e2d096-4cdc-4f87-a57b-5e31323093d9]triLoadMeterData - On Success stagingTableWriteRowSuccess = 3602014-03-27 13:18:14,384 INFO [org.apache.log4j.DailyRollingFileAppender.a9e2d096-4cdc-4f87-a57b-5e31323093d9]triLoadMeterData - On Success stagingTableWriteRowFail = 02014-03-27 13:18:14,384 INFO [org.apache.log4j.DailyRollingFileAppender.a9e2d096-4cdc-4f87-a57b-5e31323093d9]triLoadMeterData - On Success rowsSkipped = 02014-03-27 13:18:14,384 INFO [org.apache.log4j.DailyRollingFileAppender.a9e2d096-4cdc-4f87-a57b-5e31323093d9]triLoadMeterData - On Success rowsNotValid = 02014-03-27 13:18:14,384 INFO [org.apache.log4j.DailyRollingFileAppender.a9e2d096-4cdc-4f87-a57b-5e31323093d9]triLoadMeterData - On Success dcJobsToReadyState = 02014-03-27 13:18:14,384 INFO [org.apache.log4j.DailyRollingFileAppender.a9e2d096-4cdc-4f87-a57b-5e31323093d9]triLoadMeterData - On Success createdDT = 13959514910882014-03-27 13:18:14,384 INFO [org.apache.log4j.DailyRollingFileAppender.a9e2d096-4cdc-4f87-a57b-5e31323093d9]triLoadMeterData - On Success finishedDT = 13959514943842014-03-27 13:18:14,384 INFO [org.apache.log4j.DailyRollingFileAppender.


a9e2d096-4cdc-4f87-a57b-5e31323093d9]triLoadMeterData - On Success seconds = 32014-03-27 13:18:14,384 INFO [org.apache.log4j.DailyRollingFileAppender.a9e2d096-4cdc-4f87-a57b-5e31323093d9]triLoadMeterData - On Success secondsPerRecord = 0.012014-03-27 13:18:14,384 INFO [org.apache.log4j.DailyRollingFileAppender.a9e2d096-4cdc-4f87-a57b-5e31323093d9]triLoadMeterData - On Success -----------------------------------------------------------------------------2014-03-27 13:18:14,386 DEBUG [org.apache.log4j.DailyRollingFileAppender.a9e2d096-4cdc-4f87-a57b-5e31323093d9]triLoadMeterData - On Success Exit2014-03-27 13:18:14,386 INFO [org.apache.log4j.DailyRollingFileAppender.a9e2d096-4cdc-4f87-a57b-5e31323093d9]CTGDIS116I Scripting hook of type onsuccess finished.2014-03-27 13:18:14,386 INFO [org.apache.log4j.DailyRollingFileAppender.a9e2d096-4cdc-4f87-a57b-5e31323093d9]CTGDIS080I Terminated successfully (0 errors).

パフォーマンスの調整のヒント:

パフォーマンスを向上させるには、以下の説明を参照してください。

ETL での目的の処理が完了したら、ベースライン・パフォーマンス測定を実施します。

1. Tivoli Directory Integrator 構成エディターを使用して、ファクト・テーブルに数千行を追加する予定のデータベースに対して ETL を実行します。

2. ネットワーク待ち時間が発生しないようにするため、必ずデータベース接続を使用し、データベースが稼働しているネットワークで Tivoli Directory Integrator変換を実行してください。VPN 経由では実行しないでください。

3. 実行に対して記録された情報を検討します。例えば、triLoadMeterData ETL の実行から得られた triLoadMeterData.log ファイルを検討します。

実行の分析:

1. 実行を分析します。他のステップよりも時間がかかるステップがありますか?

2. データ入力 (Data input) ステップで時間がかかっていますか? 索引をデータベースに追加する必要がありますか? 該当する場合は、索引を追加して再実行してください。パフォーマンスは向上しましたか? 場合によっては、データベースを使用して結果セットをフィルタリングして絞り込む代わりに、フィルター・ステップを使用する必要があります。

ETL 開発のためのヒント:

v 複雑な SQL や集約関数 (COUNT、MIN、MAX、SUM など) は使用しないようにしてください。これらを使用する必要がある場合は、索引を作成することでデータ入力 (Data Input) ステップが改善されるかどうかを確認してください。ラージ VARCHAR 型フィールドには索引を作成しないでください。SQL Serverで処理できる索引のサイズは 900 バイト未満です。

v OR、NOT、およびビュー (IBM TRIRIGA データベースの M_TableName)は、可能な限り使用しないでください。


ETL 変換の実行TRIRIGA ジョブ・スケジューラーを使用して、TRIRIGA ファクト・テーブルまたはフラット化された階層テーブルにデータを移動するために使用する ETL ジョブ項目およびジョブ・グループを実行します。

ETL ジョブ項目、ジョブ・グループ、およびジョブ・スケジューラーETL ジョブ項目は、TRIRIGA データベースから情報を収集して変換し、ファクト・テーブルにロードするために使用する ETL 変換スクリプトまたは階層の再構築プロセスを定義します。ETL ジョブ・グループは、ETL ジョブ項目の単なる集合です。ジョブ・スケジューラーは、ETL ジョブ項目およびジョブ・グループをいつ実行するかを定義します。ジョブ・スケジュールに関連付けられたジョブを実行するには、そのジョブ・スケジュールをアクティブ化する必要があります。

TRIRIGA ワークプレース・パフォーマンス管理の分析/報告ツールは、フラット階層テーブル内のデータを基準にグループ化されたファクト・テーブルへの照会を使用して、レポートやグラフの生成に使用されるメトリックを計算します。ジョブ・スケジューラーは、ETL ジョブ項目を使用して、ソース・テーブル (TRIRIGA ビジネス・オブジェクト・テーブルなど) からデータを抽出してファクト・テーブルにロードするワークフローを起動します。ETL ジョブ項目を使用して、フラット階層を更新することもできます。

TRIRIGA ワークプレース・パフォーマンス管理には、以下の 3 つのタイプのETL ジョブ項目があります。

Kettle 変換TRIRIGA ビジネス・オブジェクト・テーブルからデータを抽出し、そのデータを TRIRIGA ワークプレース・パフォーマンス管理のファクト・テーブルにロードします。

Tivoli Directory Integrator 変換TRIRIGA ビジネス・オブジェクト・テーブルまたは外部ソースによるテーブルからデータを抽出し、そのデータを TRIRIGA ワークプレース・パフォーマンス管理のファクト・テーブルにロードします。

階層の再構築TRIRIGA ビジネス・オブジェクト・テーブルからデータを抽出し、そのデータを TRIRIGA ワークプレース・パフォーマンス管理のフラット化された階層テーブルにロードします。

ETL ジョブ項目の作成または変更ETL ジョブ項目は、TRIRIGA データベースから情報を収集して変換し、ファクト・テーブルまたはフラット化された階層テーブルにロードするスクリプトを定義します。

手順

1. 「システム管理」 > 「システム・セットアップ」 > 「ジョブ・スケジュール」 > 「ETL ジョブ項目」をクリックします。

2. 既存のジョブ項目を選択するか「追加」をクリックします。


3. 「一般」セクションに、ETL ジョブ項目の ID を入力します。「ID」フィールドにはファクト・テーブルの名前を含めてください。状況は、ETL ジョブ項目の作成時に TRIRIGA システムにより指定されます。

4. ETL ジョブ項目の名前と説明を入力します。「詳細」セクションの「ジョブ項目クラス」フィールドは、TRIRIGA システムにより「ETL」に設定されています。

5. 「ジョブ項目タイプ」を選択します。

6. ジョブ項目タイプが「階層の再構築」の場合は、以下の手順を実行します。

a. 階層モジュール名を入力してください。指定する場合は、TRIRIGA で階層が定義されているモジュールでなければなりません (ロケーションなど)。このETL ジョブ項目が実行されると、このモジュールのすべてのフラット階層が再構築されます。

b. 階層名を入力してください。この ETL ジョブ項目が実行されると、このビジネス・オブジェクトのフラット階層が再構築されます。階層名が指定されている場合、階層名は階層モジュール名よりも優先されます。

c. TRIRIGA システムは、「詳細」セクションのカレンダー期間、会計期間、およびその他の日付に入力された情報を無視します。

d. 特定モジュールのフラット階層をすべて再構築するには、階層モジュール名を指定し、階層名はブランクのままにします。

e. 1 つのフラット階層を再構築するには、階層モジュール名と階層名の両方を指定します。

f. 階層モジュール名と階層名の両方がブランクであるか、いずれかに「すべて」が指定されている場合は、すべてのフラット階層が再構築されます。

7. ジョブ項目タイプが「Kettle 変換」または「TDI 変換 (TDITransformation)」の場合は、以下の手順を実行します。

a. 変換ファイルを参照して選択することによって指定します。 TRIRIGA システムでは、Kettle 変換ファイルは .ktl 形式または .xml 形式でなければならず、Tivoli Directory Integrator 変換ファイルは .xml 形式でなければなりません。

b. オプション: 変換ファイルをアップロードすると、「コンテンツの表示」をクリックして表示できるようになります。

8. ジョブ項目タイプが「TDI 変換 (TDI Transformation)」の場合は、アセンブリー・ライン名を入力します。

9. ジョブ項目タイプが「Kettle 変換」の場合は、

a. モジュール名を入力してください。複数の名前を指定する場合は、必ずコンマで区切ってください。

v 各モジュール名は、変換ファイルの変数に変換されます。この変数の形式は ${Module.<moduleName>.ViewName} であり、<moduleName> はモジュール名です。

v ETL に渡される各変数の値は、そのモジュールのビューの名前です。この変数の値は、ETL で特定のモジュールのビューの名前を知る必要がある場合に使用できます。

b. ビジネス・オブジェクト名を入力します。複数のビジネス・オブジェクト名を指定する場合は、必ず名前をコンマで区切ってください。


v 各ビジネス・オブジェクト名は、変換ファイルの変数に変換されます。この変数は ${BO.<boName>.TableName} という形式で、<boName> はビジネス・オブジェクト名です。

v ビジネス・オブジェクト名にモジュール名が含まれていない場合、ビジネス・オブジェクトがデータベースで固有であることは保証されません。名前が固有ではないビジネス・オブジェクトを使用する場合は、コンマ区切りリストにモジュール名を含めてください。構文<moduleName>::<boName> を使用してください。ここで <moduleName>はモジュール名、<boName> はビジネス・オブジェクト名です。

v 変換ファイルに ${BO.<moduleName>::<boName>.TableName} という形式の変数が指定されます。各変数の値は、ビジネス・オブジェクトの表の名前です。この変数の値は、ETL で特定のビジネス・オブジェクトの表の名前を知る必要がある場合に使用できます。

10. ジョブ項目タイプが「Kettle 変換」または「TDI 変換 (TDITransformation)」の場合は、以下の手順を実行します。

a. 一般に、ETL ジョブ項目は 1 つ以上のジョブ・スケジュールの制御下で実行されます。

b. ETL ジョブ項目の単体テストを行うには、「詳細」セクションで日付パラメーターを設定します。

c. 以下の日付パラメーターの扱いは ETL によって異なり、情報が使用されることもされないこともあります。この日付パラメーターは、ETL ジョブ項目がジョブ・スケジューラーによって実行されるときに上書きされます。

v 「カレンダー期間」を選択すると、ジョブのカレンダー期間を含む変数が渡されます。

v 「会計期間」を選択すると、ジョブの会計期間を含む変数が渡されます。会計期間は、TRIRIGA ワークプレース・パフォーマンス管理のファクト・テーブルの「収集期間」フィールドによって使用されます。

v 「日付」を選択すると、ジョブの日付レコードを含む変数が渡されます。日付レコードは、TRIRIGA ワークプレース・パフォーマンス管理のファクト・テーブルの「日付ディメンション (Date Dimension)」フィールドをスタンプするために使用されます。

v 「日付」を選択すると、ジョブの日付を含む変数が渡されます。日付を入力するか、「カレンダー」アイコンをクリックして日付を選択します。

v 最初のデータ収集の日付を指定し、ジョブの開始日を含む変数を渡すには、「開始日」を選択します。日付を入力するか、「カレンダー」アイコンをクリックして日付を選択します。

v 最後のデータ収集の日付を指定し、ジョブの終了日を含む変数を渡すには、「終了日」を選択します。日付を入力するか、「カレンダー」アイコンをクリックして日付を選択します。

11. 「メトリック」セクションに、この ETL ジョブ項目のロギング・データの要約が表示されます。「平均期間」は、「合計期間」と「実行回数」に基づいて計算されます (「合計期間」/「実行回数」)。


12. 「ログ」セクションには、この ETL ジョブ項目が実行されるごとに、それぞれの時刻と状況が表示されます。このデータは、「メトリック」セクションに合計して表示されます。

13. 「ドラフトの作成」をクリックします。

14. 「アクティブ化」をクリックします。

タスクの結果

ETL ジョブ項目レコードが作成され、ジョブ・グループ、ジョブ・スケジュール、またはそれら両方に含められるようになります。

次のタスク

単体テストを実行するには、「プロセスの実行」をクリックし、ETL ジョブ項目に指定されている Kettle 変換、Tivoli Directory Integrator 変換、または階層の再構築プロセスをトリガーします。

ジョブ・グループの追加または変更ジョブのスケジューリングを単純化するには、ジョブ・グループを使用して、同じスケジュールで実行する ETL ジョブ項目の集合を作成します。

手順

1. 「システム管理」 > 「システム・セットアップ」 > 「ジョブ・スケジュール」 > 「ジョブ・グループ」をクリックします。

2. 既存のジョブ・グループを選択するか「追加」をクリックします。

3. 「ジョブ・グループ」フォームにジョブ・グループの名前と説明を入力します。

4. 「ジョブ項目」セクションのジョブ・グループに対して ETL ジョブ項目の追加や削除を行うには、「検索」アクションや「削除」アクションを使用します。

5. オプション: ジョブ項目の順序を調整します。

6. 「作成」をクリックします。

タスクの結果

ジョブ・グループ・レコードをジョブ・スケジュールに含められるようになりました。

ジョブ・スケジューラーの作成または変更TRIRIGA がいつ ETL ジョブ項目およびジョブ・グループを実行するかをスケジュールするには、ジョブ・スケジューラーを使用します。ジョブは、毎時、日次、毎週、または月次で実行するようにスケジュールすることができます。

始める前に

TRIRIGA にはジョブ・スケジューラーが事前定義されていますが、事前定義のジョブ・スケジューラーを変更するか、開始日と終了日を指定して新しいジョブ・スケジューラーを作成し、「アクティブ化」をクリックするまでジョブはスケジュールされません。


手順

1. 「システム管理」 > 「システム・セットアップ」 > 「ジョブ・スケジュール」 > 「ジョブ・スケジューラー」をクリックします。

2. 既存のジョブ・スケジューラーを選択するか「追加」をクリックします。

3. ジョブ・スケジューラーの名前と説明を入力します。

4. 「スケジュール」セクションに表示されるリストから、「スケジュール・タイプ」の頻度を選択します。

v 「日次」のスケジュール・タイプを選択すると、「毎時ですか?」フィールドと「毎」フィールドが表示されます。「毎時ですか?」チェック・ボックスをクリックしてジョブが 1 時間ごとに実行されるようにスケジュールした後、「毎」フィールドをクリックして、スケジュール対象の各ジョブの間隔(時間単位) を指定します。

v スケジュール・タイプとして「拡張」を選択すると、「スケジュール」セクションに「繰り返しパターン」フィールドが表示されます。「繰り返しパターン」をクリックすると「ジョブ・イベント」フォームが開き、柔軟なオプションを使用してジョブをスケジュールすることができます。

5. オプション: このジョブ・スケジュールのアクティビティーの結果から計算されるメトリックに履歴データを含めることを指定するため、「スケジュール」セクションで「履歴取得を実行しますか?」チェック・ボックスを選択します。このジョブ・スケジュールがアクティブ化されている場合、このオプションによりジョブ・スケジューラーに対し、スケジュール日が本日よりも前であるジョブを生成して実行するように指示されます。時間枠または期間のパラメーター (開始日、終了日、会計期間など) が各ジョブ項目に渡され、履歴収集がシミュレートされます。ただし、プロセスは今すぐ実行されるため、正常に完了するかどうかは、ETL スクリプトでこれらのパラメーターがどのように使用されるかに全面的に依存します。履歴収集の実行は拡張オプションであり、このオプションを使用するには各スクリプトの処理を完全に理解している必要があります。

6. 最初の収集の開始日、最後の収集の終了日、および取得ラグ (各取得の最終日から) を選択します。取得ラグは、システムがジョブを処理するワークフローの開始を待機する時間です。各データ収集期間は、開始日とスケジュール・タイプを使用して計算されます。各収集期間の終了日から収集ラグの期間が経過した直後に、ETL ジョブ項目を実行するワークフローがトリガーされます。例えば開始日が 2014 年 1 月 1 日、スケジュール・タイプが月次、取得ラグが 1 日の場合は以下のイベントがスケジュールされます。

表 11. 月初からスケジュールされたジョブ実行

ジョブ実行 - この日の深夜 0時収集されるデータの開始日収集されるデータの終了日

02/01/2014 01/01/2014 01/31/2014

03/01/2014 02/01/2014 02/28/2014

04/01/2014 03/01/2014 03/31/2014

終了日によって、収集用の最後のイベントが決定されます。前述の例では、2014 年 3 月 15 日が最終日の場合、最終イベントは以下のようにスケジュールされます。


表 12. 月の半ばからスケジュールされたジョブ実行

ジョブ実行 - この日の深夜 0時収集されるデータの開始日収集されるデータの終了日

03/16/2014 03/01/2014 03/15/2014

v 「収集期間をリセットしますか?」チェック・ボックスが選択されている場合、システムにより、ジョブを実行するたびに収集期間が常に最新の期間に設定されます。

v 例えばアクティブ化されたジョブ・スケジューラーがスケジュール・タイプ「月次」で構成されている場合、システムは毎月ウェイクアップし、レコードのジョブ項目を実行します。ジョブ・スケジューラーで「収集期間のリセット」が選択されている場合、ウェイクアップ中に、システムにより、収集期間がウェイクアップ日に基づいて正しく設定されます。

v ジョブ項目とジョブ・グループのいずれかまたは両方を指定し、このジョブ・スケジュール・レコードをアクティブ化している場合、このジョブ・スケジュールのスケジュールされたイベントのリストが、「スケジュールされたジョブ」セクションに表示されます。

7. 「ジョブ項目」セクションで、「検索」アクションまたは「削除」アクションを使用して、スケジュールに含める ETL ジョブ項目およびジョブ・グループを選択し、「OK」をクリックします。ジョブ項目は、「シーケンス」列で指定された順序で実行されます。

v このジョブ・スケジュールがアクティブ化されている場合、「メトリック」セクションにこのジョブ・スケジュールのロギング・データの要約が表示されます。

v 平均期間は、合計期間と実行回数に基づいて計算されます (合計期間/実行回数)。

v このジョブ・スケジュールがアクティブ化されている場合、「ログ」セクションに、このジョブ・スケジュールの実行ごとの時刻と状況が表示されます。

8. オプション: ジョブ項目の順序を調整します。

9. 「ドラフトの作成」をクリックしてから、「アクティブ化」をクリックします。

タスクの結果

TRIRIGA システムにより、スケジュール・タイプ、開始日、および終了日に基づく一連のスケジュールされたジョブが作成されます。スケジュールされたジョブは、ジョブ・スケジュールの「スケジュールされたジョブ」セクションで確認できます。

変換オブジェクトのカスタマイズTRIRIGA には ETL ジョブ項目と変換オブジェクトが用意されています。新しい変換オブジェクトを定義せずに、既存の ETL ジョブ項目の変換オブジェクトをカスタマイズすることができます。既存の変換オブジェクトを使用する場合は、変換を定義するか保守する必要があります。ただし、ビジネス・オブジェクト、フォーム、またはワークフロー・タスクは既に定義されているため、定義および保守する必要はありません。


変換ビジネス・オブジェクト、フォーム、およびワークフローの定義新規の変換オブジェクトを定義する際に、既存の TRIRIGA ETL ジョブ項目を例として使用することができます。独自の新規変換オブジェクトを定義する場合、ビジネス・オブジェクト、フォーム、およびワークフローの定義および保守も必要になります。

始める前に

ソース・テーブルと宛先テーブル (ビジネス・オブジェクト) を作成し、対応するマッピングを設定します。

手順

1. 変換ビジネス・オブジェクトを作成します。

a. 変換に渡す変数を識別し、それらの変数を変換ビジネス・オブジェクトに追加します。例えば、期間などです。

b. 変換 XML 用の 2 進数フィールドがあることを確認します。

2. 変換フォームを作成し、ナビゲーション項目または他の方法を提供して、変換フォームを表示します。

3. ETL 変換カスタム・ワークフロー・タスクを呼び出すワークフローを作成します。

a. スケジュールに従って実行するようにワークフローを設定します。

b. 実行する必要がある変換ビジネス・オブジェクト・レコードごとにカスタム・ワークフロー・タスクを呼び出して、すべてのレコードについて繰り返し処理を行います。

Content Manager への変換 XML の保存変換 XML を定義した後に、その XML をファイル・システムに保存して、TRIRIGA Content Manager にアップロードできます。その後、ETL 開発環境を使用して、変換 XML をテストすることができます。

手順

1. 変換ビジネス・オブジェクトのナビゲーション項目を開きます。既存の変換ビジネス・オブジェクトを編集するか、新規の変換ビジネス・オブジェクトを追加します。

2. 2 進数フィールドを使用して、変換 XML を TRIRIGA Content Manager にアップロードします。

3. 必要に応じて、他のフィールドを更新します。

4. 変換レコードを保存します。

ワークフロー・ランタイムの構成変換 XML を TRIRIGA Content Manager にアップロードすると、ワークフローがスケジュールに従って実行されるようにセットアップすることができます。ワークフローは、すべての変換ビジネス・オブジェクト・レコードにわたって、各レコードのカスタム・ワークフロー・タスクの呼び出しを繰り返します。

手順

1. ワークフローが、変換ビジネス・オブジェクトのレコードを取得します。


2. ワークフローが、カスタム・ワークフロー・タスクに送信するレコードを判別します。

3. ワークフローが、各レコードについてカスタム・ワークフロー・タスクを呼び出す処理を繰り返します。クラス名はcom.tririga.platform.workflow.runtime.taskhandler.ETL.RunETL でなければなりません。

4. カスタム・ワークフロー・タスクが以下の処理を実行します。

a. 変換 XML を Content Manager から一時ファイルにロードします。

b. ビジネス・オブジェクトのすべてのフィールドを収集し、ETL ツールに渡す変数を作成します。日付や日時の形式については特別な処理が必要です。

c. ETL 環境を作成します。

d. ローカル・アプリケーション・サーバー JNDI への TRIRIGA 接続を設定します。

e. ETL API を使用して変換を実行します。

f. 処理中にエラーが発生した場合はワークフローに false を返し、それ以外の場合は true を返します。

ETL カスタム・ワークフロー・タスク仕様の実行ワークフローは、すべての変換ビジネス・オブジェクト・レコードにわたって、各レコードのカスタム・ワークフロー・タスクの呼び出しを繰り返します。カスタム・ワークフロー・タスクには定義済みの仕様が含まれます。

各変換ビジネス・オブジェクトに対してカスタム・ワークフロー・タスクが呼び出されると、そのフィールドが以下のように処理されます。

1. triTransformBI フィールドは必須であり、実行する変換 XML ファイルに対する参照を保持します。

2. triBONamesTX フィールドが存在する場合は、ビジネス・オブジェクト名のコンマ区切りリストとして解析されます。カスタム・ワークフロー・タスクは、${BO.<boName>.TableName} という形式の変数を作成します。例えば、フィールドに triBuilding が含まれる場合は、ETL スクリプトで${BO.triBuilding.TableName} 変数を使用できます。この変数には、triBuilding レコードを格納する実際のデータベース表名が入ります。ビジネス・オブジェクト名は固有でない可能性があるため、<moduleName>::<boName> という形式を使用してモジュールを指定して ${BO.<moduleName>::<boName>.TableName} 変数に対応させることができます。例えば、Location::triBuilding は ETL スクリプトで変数 ${BO.Location::triBuilding.TableName} として使用できます。

3. triModuleNamesTX フィールドが存在する場合は、モジュール名のコンマ区切りリストとして解析されます。カスタム・ワークフロー・タスクは、${Module.<moduleName>.ViewName} という形式の変数を作成します。


第 3 章メトリック

メトリックとは、測定対象となる操作目標です。すべての TRIRIGA メトリックは、同じメトリック・テクノロジーおよびデータを使用しますが、目的に応じて異なるメトリックが使用されます。

メトリックは、目的により以下の 2 つに分けられます。

パフォーマンス・メトリック処理のパフォーマンスを測定し、改善のために実行可能なアクションを識別するメトリック。通常、その基準は、比率、パーセンテージ、またはスコアです。パフォーマンス・メトリックには、目標、しきい値、アクションの条件、アカウンタビリティー、およびアクション・タスク機能があります。

分析およびレポート・メトリック一般的なレポート、または関連するパフォーマンス・メトリックの詳細な分析のための情報となるメトリック。この情報は、次元分析およびナビゲーションに役立ち、パフォーマンス管理アプリケーションのメトリック機能を使用します。分析およびレポート・メトリックには、目標、しきい値、アクションの条件、アカウンタビリティー、およびアクション・タスクはありません。「結果」、「目標」、および「状況」フィールドのキー・メトリック値は、このメトリック・タイプではブランクです。

詳しくは、「IBM TRIRIGA 10 Workplace Performance Management User Guide」を参照してください。

測定基準レポート測定基準レポートは、ファクト・テーブルに定義されているディメンションおよびファクト・フィールドを使用して、特定のメトリックの計算を表します。測定基準レポートは、単一メトリックの集約された値を表示します。

ユーザーの役割ごとの測定基準レポートの集合が、ポータル・ホーム・ページおよびパフォーマンス・マネージャーに表示されます。

TRIRIGA ソフトウェアを企業の環境に合わせてカスタマイズする際、初期状態の測定基準レポートを編集したり変更したりしないでください。代わりに、既存の測定基準レポートをコピーして名前変更し、編集するか、全く新しい測定基準レポートを作成して、派生測定基準レポートを作成します。「モジュール」フィルターを「triMetricFact」に、「表示タイプ」フィルターを「メトリック」に、「名前」フィルターを「メトリック」に設定して、「My レポート」 > 「システム・レポート」で測定基準レポートを表示します。メトリック・グラフィック・レポートに関連するメトリック表形式レポートを表示するには、「名前」フィルターを「関連レポート」に設定します。

各測定基準レポートは以下の要素から構成されています。


ドリル・パス階層ディメンションを利用し、レポート・ユーザーが階層を上下に移動できるようにする特殊なレポート機能。

フィルターレポートに表示されるデータを変更したりフィルタリングしたりする機能をレポート・ユーザーに提供します。

メトリック計算レポートの主な焦点となるメトリック。

関連レポート測定基準レポートに関する追加のデータ (メトリックでない場合もある) を表示します。

詳しくは、「IBM TRIRIGA Application Platform 3 Reporting User Guide」を参照してください。

キー・メトリックスコア・カード・ポータルには、複数のメトリックを単一ビューに集約する「キー・メトリック」セクションが含まれています。

TRIRIGA を組織向けにカスタマイズする際、初期状態のキー・メトリックを編集したり変更したりしないでください。代わりに、初期状態のキー・メトリックをコピーして名前変更し、編集することにより、派生キー・メトリックを作成します。また、全く新しいキー・メトリック・ポータル・セクションを作成することもできます。

スコア・カード・ビルダー、ポータル・ビルダー、およびナビゲーション・ビルダーを使用してポータルをセットアップするプロセスについては、「IBM TRIRIGAApplication Platform 3 ユーザー・エクスペリエンス・ユーザー・ガイド」で説明しています。

ヒント:

v スコア・カード・フォームの「照会」タブに、この「キー・メトリック」ポータル・セクションの「選択済み照会」セクションに表示されるすべての照会を含めます。

v ナビゲーション項目にスコア・カードを配置するときに、デフォルト・レポートを指定します。

v ユーザーがホーム・ポータルおよびパフォーマンス・マネージャー内を移動するときにかかる応答時間は、状況によって異なる可能性があります。応答時間は、スコア・カードに含まれているメトリック数、および各メトリックのデータ量に直接関連しています。フィルターの精度が高いほど、パフォーマンスは向上します。

フォーム・メトリックメトリックの表示に代わる方法は、フォーム・ビューを使用する方法です。


フォームへのメトリックの表示は、フォームに照会セクションを定義することにより実行できます。この場合、参照される照会はメトリック照会です。メトリック照会が選択するデータを、フォームが表示される親レコードに基づいてフィルタリングして表示することができます。関連するレポートの切り替えにより、ユーザー・アクションに基づく照会の交換が可能になります。

設計時に、$$RECORDID$$ および $$PARENT::[Section]:: [Field]$$ フィルターを使用してメトリック照会を定義します。実行時に、フォームが表示される親レコードによって、メトリック照会エンジンが表示対象として選択したデータが暗黙的にフィルタリングされます。

他のメトリック照会を関連レポートとして定義できます。実行時に、メトリック照会がフォーム関連レポート内に表示される際、ユーザーはコントロールを切り替えることにより、表示される照会を交換できます。

データのフィルタリングメトリックがフォームに表示される前に、データがフィルタリングされます。

実行時に照会が実行される前に、以下の処理が行われます。

v $$RECORDID$$ フィルターが、フォームが表示されている親レコードのレコードID に置き換えられます。

v $$PARENT::[Section]::[Field]$$ フィルターが、定義された親レコード・フィールドの値に解決されます。

v メトリック照会が親レコードの外部で表示される場合、$$RECORDID$$ および$$PARENT::[Section]::[Field]$$ などの親依存フィルターはすべて無視されます。

ファクト・テーブル内のドリル・パスとして定義されているフィールドに対して$$RECORDID$$ および $$PARENT::[Section]::[Field]$$ フィルターを定義します。プログラムまたは分類を対象にフィルタリングされ、前述のフィルターを使用するメトリックは、ドリル・パス・リストからの選択と同様に機能します。また、このメトリックは、指定されたレコードをフィルタリングして取得し、そのレコードのすべての子を含んでいます。

$$PARENT::[Section]::[Field]$$ フィルター値が階層フィルターに指定されている場合、ヌルの親フィールドは、ドリル・パスのルート・ノードを選択することに相当します。また、ルート値に一致するすべてのレコードも含んでいます。非階層フィルターは、ビジネス・オブジェクト照会フィルターと同様に動作し、親フィールド値がヌルの場合に、ヌル値を持つレコードをフィルタリングして取得します。

$$RECORDID$$ および $$PARENT::[Section]::[Field]$$ フィルターは、その値が親レコードから渡される点を除き、ランタイム・フィルターと同様に動作します。

メトリック照会に、同じフィールドに対して定義されている $$RUNTIME$$ および$$PARENT::[Section]::[Field]$$ フィルターがある場合、フォーム内に照会が表示されるときに、$$RUNTIME$$ フィルター制御は使用されません。代わりに、$$PARENT::[Section]::[Field]$$ の値が、フィルター値として使用されます。

第 3 章メトリック 71

サブレポートフォーム・メトリックには、表形式とグラフィック形式の両方のサブレポートを含めることができます。

表形式のサブレポートは、パフォーマンス・マネージャーの関連レポートを定義します。表形式以外のサブレポートは、フォーム内で切り替えることができるメトリック・グラフを表します。

表形式とグラフィック形式の両方のレポートを、メトリック照会の「サブレポート」セクションに追加できます。実行時にパフォーマンス・マネージャーは、関連レポートとして表形式レポートのみを表示します。また、フォーム照会セクション内のメトリックには、「サブレポート」セクションのスワップ・コントロールのオプションとしてグラフィカル・レポートのみがあります。

サブレポートのタイプ (例えば、メトリック、照会、レポートなど) が、レポート・ビルダーの「サブレポート」セクションに表示されます。メトリック照会では、「表形式出力」フラグが使用可能です。

メトリック照会は、サブレポートとして他のメトリック照会を表示できます。


第 4 章階層フラット化ツール

TRIRIGA Application Platform での階層の定義により、データ階層をさまざまに配列することができ (例えば組織に対応するように)、実装に柔軟性がもたらされます。ただし、レポート・ツールでは、レポート作成を単純化し、パフォーマンスを最大化するために、より構造化されたデータ・サマリーが適しています。

階層フラット化ツールの目的は、管理者が TRIRIGA 測定基準レポート・エンジンで使用する一連の名前付き構造を定義し、システム内の階層データを迅速に処理できるようにすることです。結果として生成される構造は、フラット階層と呼ばれ、測定基準レポートで使用されます。

管理者は、ジョブ・スケジューラーを使用し、ETL ジョブ項目を利用して、階層フラット化ツール・プロセスを実行します。システム開発者は、カスタム・ワークフロー・タスクを使用してプロセスをトリガーします。この場合、階層フラット化ツール・プロセスを実行するために使用されるクラス名は次のとおりです。

com.tririga.platform.workflow.runtime.taskhandler.flathierarchy.RebuildFlatHierarchies

カスタム・ワークフロー・タスクを使用したプロセスのトリガーについては、「Application Building for the IBM TRIRIGA Application Platform 3」で説明しています。

重要: TRIRIGA 内の階層が変更されると必ず、階層ツリーが直ちに更新されます。例えば、新規の triBuilding を追加した場合、ロケーション階層が更新されます。ただし、triBuilding に対応するフラット階層は、「階層の再構築」ジョブ項目を使用して再構築するまでは更新されません。そのため、ファクト・テーブルを介したTRIRIGA ワークプレース・パフォーマンス管理データの収集を計画するときに、同時に「階層の再構築」ジョブ項目をスケジュールすることが重要です。「階層の再構築」ジョブ項目により、情報が確実に最新の状態に保持されます。

フラット階層階層構造定義は、何に基づいてフラット化を行うかによって異なります。フラット階層は、指定されたモジュールの階層の標準親子関係に基づいて構築することができます。また、モジュールの階層内の特定の各レベル、およびそれぞれのレベルのビジネス・オブジェクトに基づくフラット階層を作成することもできます。

各階層構造定義には、階層名、モジュール、および階層タイプを識別する単一のヘッダー・レコードが含まれています。階層名は階層を説明する名前で、モジュールは階層が表すモジュールです。階層タイプは、データをフラット化する方法を把握するためにフラット化プロセスで使用されます。階層タイプには「データ」および「フォーム」の 2 つのタイプがあります。

データ階層は、指定されたモジュールの階層の標準親子関係に基づいてデータのパスをフラット化するために使用されます。この階層タイプには、名前のあるレベルはありません。これは、TRIRIGA Application Platform アプリケーションでは、異


なるタイプのデータをモジュールの階層内の同じ物理レベルで表すことができるためです。例えば、ロケーション階層に、「物件、建物、およびフロア」と「建物およびフロア」の両方のデータが含まれているとします。階層の第 1 レベルには物件と建物が混在して含まれ、第 2 レベルには建物とフロアが混在して含まれています。

フォーム階層は、指定されたモジュールの階層の親子関係、およびレベルを表すビジネス・オブジェクトに基づいてデータのパスをフラット化するために使用されます。各レベルは 1 つのビジネス・オブジェクトによってのみ表されます。

各フォーム階層は、レベル番号、そのレベルが表すビジネス・オブジェクト、およびタイプを含む明示的なレベルを指定する必要があります。タイプは、当該レベルのデータを検出する方法を把握するためにフラット化プロセスで使用されます。タイプには、「検索」、「無視」、および「再帰 (Recurse)」の 3 つのオプションがあります。

v タイプの値が「検索」の場合、システムは、指定されたフォームのレコードが見つかるまで、インスタンス・データのサブレベルで特定のスレッドを検索します。レコードが見つからない場合、階層定義の残りのレベルは無視され、そのスレッドのフラット・データはこれ以上作成されなくなります。レコードが見つかった場合、システムはそのノードのフラット・データ・レコードを作成し、定義内の次のレベルに進みます。このモードには、実際のビジネス・データに応じてツリーを省略する機能が備えられています。

v タイプの値が「無視」の場合、システムは最後の親の 1 つ下のレベルの指定されたフォームを検索します。レコードが見つからない場合、システムはこのレベルのギャップを作成し、定義内の次のレベルに進みます。レコードが見つかった場合、システムはそのノードのフラット・データ・レコードを作成し、定義内の次のレベルに進みます。このモードには、実際のビジネス・データに応じてツリーを展開する機能が備えられています。レポート処理を容易にするために、ギャップに名前またはラベルを指定する必要があります。これを行うには、階層構造マネージャーで「ギャップ・ラベル (Gap Label)」の値を使用します。

v タイプの値が「再帰 (Recurse)」の場合、システムは、指定されたフォームのレコードが見つかるまで、インスタンス・データのサブレベルで特定のスレッドを検索します。レコードが見つからない場合、階層定義の残りのレベルは無視され、そのスレッドのフラット・データはこれ以上作成されなくなります。見つかったレコードごとに、システムはそのノードのフラット・データ・レコードを作成してから、定義内の次のレベルに進みます。

フラット階層の例フラット階層の例を参照することにより、フラット階層定義の構造について理解を深めることができます。


フラット階層ヘッダー・レコードの例

以下の表に、階層内のモジュールに基づくフラット階層の例を示します。

表 13. ヘッダー・レコードの例

階層名モジュール階層タイプ

スペース階層 (SpaceHierarchy)

ロケーション GUI

土地階層 (Land Hierarchy) ロケーション GUI

市区町村階層 (CityHierarchy)

地域 GUI

完全ロケーション階層 (FullLocation Hierarchy)

ロケーションデータ

完全組織階層 (FullOrganization Hierarchy)

組織データ

内部組織階層 (InternalOrganization Hierarchy)

組織 GUI

外部組織階層 (ExternalOrganization Hierarchy)

組織 GUI

フラット階層レベル・レコードの例

以下の表に、階層内のレベルに基づくフラット階層の例を示します。

表 14. フラット階層レベル・レコードの例

階層名レベルの番号フォームモジュール検索


1 プロパティー無視


2 建物検索


3 フロア検索


4 スペース管理再帰 (Recurse)

内部組織階層(InternalOrganizationHierarchy)

1 企業検索


2 事業部無視


3 部門再帰 (Recurse)

第 4 章階層フラット化ツール 75

階層構造マネージャー階層構造マネージャーを使用して、階層およびレベル情報を定義できます。階層構造マネージャーは、フラット階層を作成、更新、および削除するための単一インターフェースを提供します。

階層構造へのアクセス階層を追加、変更、または削除するには、階層構造機能にアクセスします。

手順1. 「システム管理」 > 「ビルダー・ツール」 > 「データ・モデラー」をクリッ

クします。

2. 「ユーティリティー」をクリックします。

3. 「階層構造」をクリックします。

データ階層の作成データ階層は、指定されたモジュールの階層の標準親子関係に基づいてデータのパスをフラット化するために使用されます。データ階層を作成するときに、名前付きのレベルは必要ありません。これは、異なるタイプのデータをモジュールの階層内の同じ物理レベルで表すことができるためです。

手順1. 「階層の作成」をクリックします。

2. 「名前」フィールドに、階層が表す内容を説明する名前を入力します。

3. 「モジュール」リストから、データ階層に関連のあるモジュールを選択します。

4. 「階層タイプ」リストから、「データ」を選択します。

5. 「作成」をクリックします。

6. 「保存」をクリックし、「閉じる」をクリックします。

フォーム階層の作成フォーム階層は、指定されたモジュールの階層の親子関係、およびレベルを表すビジネス・オブジェクトに基づいてデータのパスをフラット化するために使用されます。フォーム階層を作成するときに、各レベルは 1 つのビジネス・オブジェクトによってのみ表されます。

手順1. 「階層の作成」をクリックします。

2. 「名前」フィールドに、階層が表す内容を説明する名前を入力します。

3. 「モジュール」リストから、フォーム階層に関連のあるモジュールを選択します。

4. 「階層タイプ」リストから、「フォーム」を選択します。

5. 「作成」をクリックします。「レベル (Levels)」セクションが表示されます。レベル 1 フォームの情報を入力します。

6. 「ビジネス・オブジェクト」リストから、関連するビジネス・オブジェクトを選択します。


7. 「フォーム」リストから、関連するフォームを選択します。

8. 「タイプ」リストから、「検索」を選択します。「ギャップ・ラベル (GapLabel)」は、「タイプ」リストから「無視」が選択され、レコードが見つからないときに指定されるラベルです。

9. 「保存」をクリックします。

10. すべてのレベルが定義されるまで、情報の入力および保存を続行します。

11. 「保存」をクリックし、「閉じる」をクリックします。

第 4 章階層フラット化ツール 77

第 5 章ファクト・テーブル

ファクト・テーブルは、ビジネス・プロセスの測定、メトリック、またはファクトで構成されています。ファクト・テーブルは、測定基準レポート内のメトリックを計算するために使用されるデータを保管します。

ファクト・テーブル情報は、初期状態の TRIRIGA ワークプレース・パフォーマンス管理製品および TRIRIGA 不動産環境維持製品に基づいています。企業ごとに実装が異なる可能性があります。

各ファクト・テーブルには、データをロードするための ETL とデータをクリアするための ETL があります。データをクリアする ETL の名前の末尾は「– クリア」になります。例えば、「建物コスト・ファクト – クリア」などです。ETL を表示するには、「システム管理」 > 「システム・セットアップ」 > 「ETL ジョブ項目」をクリックします。

サポートされるファクト・テーブルおよびメトリックのリスト各企業における TRIRIGA の実装でサポートされるファクト・テーブルおよびメトリックのリストを参照できます。

ファクト・テーブルへのアクセス

「システム管理」 > 「ビルダー・ツール」 > 「データ・モデラー」をクリックします。

triMetricFact を見つけて選択し、ファクト・テーブル・ビジネス・オブジェクトのリストを表示します。

メトリックへのアクセス

「システム管理」 > 「ビルダー・ツール」 > 「レポート・マネージャー」 >「システム・レポート」をクリックします。

「ビジネス・オブジェクト」と「モジュール」でフィルタリングし、メトリック情報をソートして、関連するレポート・リストを取得します。

ヒント: #FM# は、メトリックがシステム内のフォーム・メトリックでもあることを意味します。

特殊なステージング・テーブルおよび ETL を必要とするファクトほとんどのファクト・テーブルでは、メトリックを計算するための保管データのロード・プロセスは単純です。ただし、一部のファクト・テーブルでは、ロード・プロセスを支援する特殊なステージング・テーブルおよび ETL が必要になります。

以下の表に、特殊なステージング・テーブルおよび ETL を必要とするファクトを示します。


表 15. 特殊なステージング・テーブルおよび ETL を必要とするファクト

ファクト・テーブル名ファクト・テーブル・ビジネス・オブジェクト

財務サマリー triFinancialSummary

標準時間 triStandardHours

標準時間の詳細 triStandardHoursDetails

資産分析 (毎時) ファクト triAssetAnalyticHFact

資産エネルギー利用 (日次) ファクト triAssetEnergyUseDFact

資産エネルギー利用 (毎時) ファクト triAssetEnergyUseHFact

資産エネルギー利用 (月次) ファクト triAssetEnergyUseMFact

従属 ETL一部の ETL は、ロード・プロセスを支援する他の ETL に依存します。

以下の表に、他の ETL に依存する ETL を示します。

表 16. 従属 ETL


建物コスト・ファクト・ロード ETL この ETL は、財務サマリー・テーブルのデータの可用性に依存します。財務サマリー・テーブルは、財務システムとのバックエンド統合を行うか、オフライン財務サマリーExcel プロセスを使用することによりロードできます。オフライン財務サマリー Excel プロセスを容易に実行するために、Excel/オフライン・プロセスから財務サマリー・テーブルにデータをプッシュする特殊な ETL があります。初期状態の TRIRIGA ワークプレース・パフォーマンス管理では、これらの特殊ETL に「オフライン・ステージングからの財務サマリーのロード」および「オフライン・ステージングからの財務サマリーのクリア」という名前が付けられています。オフライン財務サマリー Excel プロセスにより財務サマリー・データをインポートする場合は、最初に「オフライン・ステージングからの財務サマリーのロード」ETL を実行する必要があります。次に、「建物コスト・ファクト・ロード」ETL を実行する必要があります。


表 16. 従属 ETL (続き)


建物ファクト・ロード ETL この ETL は、財務サマリー・テーブルのデータの可用性に依存します。財務サマリー・テーブルは、財務システムとのバックエンド統合を行うか、オフライン財務サマリーExcel プロセスを使用することによりロードできます。オフライン財務サマリー Excel プロセスを容易に実行するために、Excel/オフライン・プロセスから財務サマリー・テーブルにデータをプッシュする特殊な ETL があります。初期状態の TRIRIGA ワークプレース・パフォーマンス管理では、これらの特殊ETL に「オフライン・ステージングからの財務サマリーのロード」および「オフライン・ステージングからの財務サマリーのクリア」という名前が付けられています。オフライン財務サマリー Excel プロセスにより財務サマリー・データをインポートする場合は、最初に「オフライン・ステージングからの財務サマリーのロード」ETL を実行する必要があります。次に、「建物ファクト・ロード」ETLを実行する必要があります。

リソース・ファクト・ロード ETL 標準時間ロード ETL に依存します。

標準時間ロード ETL 標準時間の詳細ロード ETL に依存します。

資産の日次ファクト ETL

資産の毎時ファクト ETL

資産の月次ファクト ETL

これらの ETL は、ステージング・テーブルのデータの可用性に依存します。ステージング・テーブルのタイプは汎用でなければなりません。ステージング・テーブルには、特定のフィールドが含まれている必要があります。ステージング・テーブルは、建物管理システムとのバックエンド統合によりロードできます。ステージング・テーブルは、ETL を使用して外部データベースからデータを取り込むことにより、ロードすることもできます。ステージング・テーブルおよび ETL のサンプルなどの詳細については、「IntegratedService Management Library」を参照してください。

第 5 章ファクト・テーブル 81

特記事項

本書は米国 IBM が提供する製品およびサービスについて作成したものです。この資料の他の言語版を IBM から入手できる場合があります。ただし、これを入手するには、本製品または当該言語版製品を所有している必要がある場合があります。

本書に記載の製品、サービス、または機能が日本においては提供されていない場合があります。日本で利用可能な製品、サービス、および機能については、日本 IBMの営業担当員にお尋ねください。本書で IBM 製品、プログラム、またはサービスに言及していても、その IBM 製品、プログラム、またはサービスのみが使用可能であることを意味するものではありません。これらに代えて、IBM の知的所有権を侵害することのない、機能的に同等の製品、プログラム、またはサービスを使用することができます。ただし、IBM 以外の製品とプログラムの操作またはサービスの評価および検証は、お客様の責任で行っていただきます。

IBM は、本書に記載されている内容に関して特許権 (特許出願中のものを含む) を保有している場合があります。本書の提供は、お客様にこれらの特許権について実施権を許諾することを意味するものではありません。実施権についてのお問い合わせは、書面にて下記宛先にお送りください。

〒103-8510東京都中央区日本橋箱崎町19番21号日本アイ・ビー・エム株式会社法務・知的財産知的財産権ライセンス渉外

IBM およびその直接または間接の子会社は、本書を特定物として現存するままの状態で提供し、商品性の保証、特定目的適合性の保証および法律上の瑕疵担保責任を含むすべての明示もしくは黙示の保証責任を負わないものとします。国または地域によっては、法律の強行規定により、保証責任の制限が禁じられる場合、強行規定の制限を受けるものとします。

この情報には、技術的に不適切な記述や誤植を含む場合があります。本書は定期的に見直され、必要な変更は本書の次版に組み込まれます。IBM は予告なしに、随時、この文書に記載されている製品またはプログラムに対して、改良または変更を行うことがあります。

本書において IBM 以外の Web サイトに言及している場合がありますが、便宜のため記載しただけであり、決してそれらの Web サイトを推奨するものではありません。それらの Web サイトにある資料は、この IBM 製品の資料の一部ではありません。それらの Web サイトは、お客様の責任でご使用ください。

IBM は、お客様が提供するいかなる情報も、お客様に対してなんら義務も負うことのない、自ら適切と信ずる方法で、使用もしくは配布することができるものとします。


本プログラムのライセンス保持者で、(i) 独自に作成したプログラムとその他のプログラム (本プログラムを含む) との間での情報交換、および (ii) 交換された情報の相互利用を可能にすることを目的として、本プログラムに関する情報を必要とする方は、下記に連絡してください。

IBM Director of LicensingIBM CorporationNorth Castle Drive, MD-NC119Armonk, NY 10504-1785US

本プログラムに関する上記の情報は、適切な使用条件の下で使用することができますが、有償の場合もあります。

本書で説明されているライセンス・プログラムまたはその他のライセンス資料は、IBM 所定のプログラム契約の契約条項、IBM プログラムのご使用条件、またはそれと同等の条項に基づいて、IBM より提供されます。

記載されている性能データとお客様事例は、例として示す目的でのみ提供されています。実際の結果は特定の構成や稼働条件によって異なります。

IBM 以外の製品に関する情報は、その製品の供給者、出版物、もしくはその他の公に利用可能なソースから入手したものです。IBM は、それらの製品のテストは行っておりません。したがって、他社製品に関する実行性、互換性、またはその他の要求については確証できません。IBM 以外の製品の性能に関する質問は、それらの製品の供給者にお願いします。

IBM の将来の方向または意向に関する記述については、予告なしに変更または撤回される場合があり、単に目標を示しているものです。

本書には、日常の業務処理で用いられるデータや報告書の例が含まれています。より具体性を与えるために、それらの例には、個人、企業、ブランド、あるいは製品などの名前が含まれている場合があります。これらの名称はすべて架空のものであり、名称や住所が類似する企業が実在しているとしても、それは偶然にすぎません。

著作権使用許諾:

本書には、様々なオペレーティング・プラットフォームでのプログラミング手法を例示するサンプル・アプリケーション・プログラムがソース言語で掲載されています。お客様は、サンプル・プログラムが書かれているオペレーティング・プラットフォームのアプリケーション・プログラミング・インターフェースに準拠したアプリケーション・プログラムの開発、使用、販売、配布を目的として、いかなる形式においても、IBM に対価を支払うことなくこれを複製し、改変し、配布することができます。このサンプル・プログラムは、あらゆる条件下における完全なテストを経ていません。従って IBM は、これらのサンプル・プログラムについて信頼性、利便性もしくは機能性があることをほのめかしたり、保証することはできません。これらのサンプル・プログラムは特定物として現存するままの状態で提供されるものであり、いかなる保証も提供されません。 IBM は、お客様の当該サンプル・プログラムの使用から生ずるいかなる損害に対しても一切の責任を負いません。


それぞれの複製物、サンプル・プログラムのいかなる部分、またはすべての派生した創作物には、次のように、著作権表示を入れていただく必要があります。© (お客様の会社名) (西暦年).このコードの一部は、IBM Corp. のサンプル・プログラムから取られています。© Copyright IBM Corp. _年を入れる_.

商標IBM、IBM ロゴおよび ibm.com は、世界の多くの国で登録された InternationalBusiness Machines Corporation の商標です。他の製品名およびサービス名等は、それぞれ IBM または各社の商標である場合があります。現時点での IBM の商標リストについては、http://www.ibm.com/legal/copytrade.shtml をご覧ください。

Java™ およびすべての Java 関連の商標およびロゴは Oracle やその関連会社の米国およびその他の国における商標または登録商標です。

Linux は、Linus Torvalds の米国およびその他の国における登録商標です。

Microsoft、Windows、Windows NT および Windows ロゴは、MicrosoftCorporation の米国およびその他の国における商標です。

UNIX は The Open Group の米国およびその他の国における登録商標です。

製品資料に関するご使用条件これらの資料は、以下の条件に同意していただける場合に限りご使用いただけます。

適用条件

IBM Web サイトの「ご利用条件」に加えて、以下のご使用条件が適用されます。

個人使用

これらの資料は、すべての著作権表示その他の所有権表示をしていただくことを条件に、非商業的な個人による使用目的に限り複製することができます。ただし、IBM の明示的な承諾をえずに、これらの資料またはその一部について、二次的著作物を作成したり、配布 (頒布、送信を含む) または表示 (上映を含む) することはできません。

商業的利用

これらの資料は、すべての著作権表示その他の所有権表示をしていただくことを条件に、お客様の企業内に限り、複製、配布、および表示することができます。ただし、IBM の明示的な承諾をえずにこれらの資料の二次的著作物を作成したり、お客様の企業外で資料またはその一部を複製、配布、または表示することはできません。

特記事項 85

http://www.ibm.com/legal/us/en/copytrade.shtml

権利

ここで明示的に許可されているもの以外に、資料や資料内に含まれる情報、データ、ソフトウェア、またはその他の知的所有権に対するいかなる許可、ライセンス、または権利を明示的にも黙示的にも付与するものではありません。

資料の使用が IBM の利益を損なうと判断された場合や、上記の条件が適切に守られていないと判断された場合、IBM はいつでも自らの判断により、ここで与えた許可を撤回できるものとさせていただきます。

お客様がこの情報をダウンロード、輸出、または再輸出する際には、米国のすべての輸出入関連法規を含む、すべての関連法規を遵守するものとします。

IBM は、これらの資料の内容についていかなる保証もしません。これらの資料は、特定物として現存するままの状態で提供され、商品性の保証、特定目的適合性の保証および法律上の瑕疵担保責任を含むすべての明示もしくは黙示の保証責任なしで提供されます。

IBM オンラインでのプライバシー・ステートメントサービス・ソリューションとしてのソフトウェアも含めた IBM ソフトウェア製品(「ソフトウェア・オファリング」) では、製品の使用に関する情報の収集、エンド・ユーザーの使用感の向上、エンド・ユーザーとの対話またはその他の目的のために、Cookie はじめさまざまなテクノロジーを使用することがあります。多くの場合、これらの「ソフトウェア・オファリング」により個人情報が収集されることはありません。一部の「ソフトウェア・オファリング」では、個人情報を収集することができます。ご使用の「ソフトウェア・オファリング」が、これらの Cookie およびそれに類するテクノロジーを通じてお客様による個人情報の収集を可能にする場合、以下の具体的事項をご確認ください。

このソフトウェア・オファリングは個人情報を収集するための Cookie またはその他の技術を使用していません。

この「ソフトウェア・オファリング」用にデプロイされた構成が Cookie およびさまざまなテクノロジーを使用してエンド・ユーザーから個人情報を収集する機能を提供する場合、お客様は、個人情報を収集するにあたって適用される法律、ガイドライン等を遵守する必要があります。これには、エンド・ユーザーへの通知や同意取得の要求も含まれますがそれらには限られません。

このような目的での Cookie を含む様々なテクノロジーの使用の詳細については、IBM の『IBM オンラインでのプライバシー・ステートメント』(http://www.ibm.com/privacy/details/jp/ja/) の『クッキー、ウェブ・ビーコン、その他のテクノロジー』および『IBM Software Products andSoftware-as-a-Service Privacy Statement』(http://www.ibm.com/software/info/product-privacy) を参照してください。


http://www.ibm.com/privacy/details/jp/ja/

http://www.ibm.com/software/info/product-privacy

http://www.ibm.com/software/info/product-privacy

特記事項 87

IBM®

Printed in Japan

c copyright ibm corp 2011 2016 fileibm tririga application platform バージョン 3 リリース...

Documents