第 5 章データエクスポータ

この章では、データエクスポータの機能について説明し、それを配備するために必要な情報を提供します。

データエクスポータとは

Identity Manager では、広範囲のシステムおよびアプリケーションでユーザーアカウント情報が処理され、変更が企業ポリシーに準拠した内容となるための、制御され、監査された環境を提供します。Identity Manager は、「データライト」アーキテクチャーです。管理対象のシステムおよびアプリションに最小限のアカウント情報がローカルに格納され、必要に応じて、実際のシステムまたはアプリケーションからデータがフェッチされます。

このアーキテクチャーは、プロビジョニング処理中にデータの重複を減らしたり、無効なデータが転送される危険性を最小限にしたりするのに役立ちますが、ローカルに格納されたアカウントデータを持つことが望ましい場合もあります。たとえば、基本システムやアプリケーションにアクセスしないでアカウント情報のクエリーを実行できると、特定の属性値を持つすべてのアカウントを識別するなどの一部の処理で、大幅にパフォーマンスが改善されることがあります。一般に、システムまたはアプリケーションのアカウントデータの使用は、プロビジョニング処理よりもレポート処理に関連しますが、そのデータが組織にとって価値がある場合もあります。

Identity Manager では、「データライト」アーキテクチャーに加えて、「現在のデータのみ」のデータモデルが使用されます。つまり、履歴レコード (監査ログとシステムログ以外) は保持されません。このモデルの利点は、オペレーショナルリポジトリのサイズが管理対象のアカウント、システム、およびアプリケーションの数に比例する傾向があることです。その結果、プロビジョニングシステム自体で必要なメンテナンスが少なくなります。ただし、Identity Manager で処理されるデータは、履歴処理で役立つ場合があります。

データエクスポータを使用すると、上記のような質問に回答するために必要なアカウントおよびワークフローデータなどの Identity Manager で処理される数多くの情報を選択的に取得できます。Identity Manager では、商用データベースの変換、レポート、および分析ツールを使用してクエリーおよび変換の基盤として追加処理または使用するために、このデータはデータウェアハウスに転送できる形式で生成されます。

Identity Manager からデータをエクスポートする必要はありません。このタイプの履歴データを追跡する必要がない場合は、このデータを保持する必要はありません。このデータが必要な場合は、Identity Manager に影響を与えることなく、独自のデータ有効期限および保持期間のポリシーを自由に確立できます。

エクスポート可能なデータ型

データエクスポータは、持続的なデータと一時的なデータの両方をエクスポートできます。持続的なデータとは、Identity Manager によってリポジトリに格納されたデータを指します。一時的なデータとは、デフォルトで Identity Manager リポジトリに格納されないデータ、または変更済みのレコードの定期的なフェッチを除外するライフサイクルを持つデータのいずれかです。一部のデータ型は、一時的と持続的の両方の場合があります (タスクインスタンスや作業項目など)。これらのデータ型は、外部から予測不可能な時点で Identity Manager によって削除されるため、一時的であると考えられます。

Identity Manager では、次のデータ型がエクスポートされます。

表 5-1 サポートされるデータ型
データ型	永続	説明
Account	持続的	User と ResourceAccount 間のリンケージを含むレコード
Entitlement	持続的	特定ユーザーのアテステーションのリストを含むレコード
LogRecord	持続的	単一の監査レコードを含むレコード
ObjectGroup	持続的	組織として設計されたセキュリティーコンテナ
Resource	持続的	アカウントがプロビジョニングされるシステムまたはアプリケーション
ResourceAccount	一時的	特定リソース上にアカウントを構成する属性セット
Role	持続的	アクセス用の論理コンテナ
Rule	持続的	Identity Manager で実行可能なロジックのブロック
TaskInstance	一時的および持続的	実行中または完了済みのプロセスを示すレコード
User	持続的	0 (ゼロ) 個以上のアカウントを含む論理ユーザー
WorkflowActivity	一時的	Identity Manager ワークフローの単一アクティビティー
WorkItem	一時的および持続的	Identity Manager ワークフローからの手動アクション

データエクスポータを使用すると、ウェアハウスの正確な要求に応じて、各データ型のエクスポート方針を定義できます。たとえば、一部のデータ型ではオブジェクトへのすべての変更をエクスポートする必要がある一方で、ほかのデータ型では一定の間隔でエクスポートすることで十分であり、データへの中間の変更がスキップされる可能性があります。

エクスポートする型を選択できます。型を選択すると、その型の新規および変更済みインスタンスがすべてエクスポートされます。削除済みのオブジェクトをエクスポートするように、持続的なデータ型を設定することもできます。

データエクスポータアーキテクチャー

データエクスポータを有効にすると、Identity Manager では、リポジトリ内のテーブルにレコードとして指定されたオブジェクト (データ型) への検出済みの各変更が格納されます。データ型ごとに設定可能な間隔で、エクスポートするレコードを選択するための 2 つのクエリーが実行されます。

1 番目のクエリーでは、最後のエクスポート以降に変更された、特定の型の持続的なオブジェクトがリポジトリ内で検索されます。ウェアハウスタスクでは、これらのレコードがエクスポートされ、最近変更されたレコードのタイムスタンプが特定され、次回クエリーを実行する開始点としてこの値が使用されます。

2 番目のクエリーでは、キューテーブルが検索されます。特定のデータ型のすべてのレコードが検出され、それらのレコードがエクスポートされたあとに、キューから削除されます。クエリーの完了後に追加されたレコードは、次のサイクルでエクスポートされます。

エクスポートされたレコードは順序付けられません。ただし、エクスポート済みのデータには、ウェアハウスの後続クエリーで時系列順にデータを配置できるフィールドがあります。

一般的な配備では、データエクスポータによってデータがステージングテーブルのセットに書き込まれます。Identity Manager では、サポートされるデータベースタイプごとに、これらのテーブルを定義する SQL スクリプトが用意されています。Identity Manager の配備にエクスポートが必要な拡張属性が含まれていない限り、これらのテーブルを変更する必要がありません。ただし、エクスポートする拡張属性がある場合は、エクスポートスキーマをカスタマイズし、これらの属性を処理するための独自のファクトリクラスをコンパイルする必要があります。詳細については、「データエクスポータをカスタマイズする」を参照してください。

ステージングテーブルにデータをエクスポートすると、データウェアハウスおよび最終的にデータマートへの格納用にデータを処理できるように、独自の ETL (Extract, Transform, and Load) インフラストラクチャーを作成できます。タイムスタンプ処理は、一般に実装される変換です。システムでは、YYYY-MM-DD hh:mm:ss の形式の java.sql.Timestamp が使用されます。タイムスタンプには曜日が明示的に指定されていませんが、変換を使用すると曜日を抽出できます。

ウェアハウスおよびデータマートに情報を転送する必要がない場合は、そのステージングテーブルが最終宛先であると見なすことができます。この場合、読み取り処理と書き込み処理で同一の接続情報を必ず使用してください。データエクスポータの設定の詳細については、『Identity Manager 管理ガイド』を参照してください。

フォレンジッククエリーを使用すると、Identity Manager で、データウェアハウス (または単一環境のステージングテーブル) に格納されたデータを読み取ることができます。ユーザー、ロール、または関連するデータ型の現在値または履歴値に基づいて、ユーザーまたはロールを特定できます。フォレンジッククエリーは「ユーザーの検索」または「ロールの検索」レポートと似ていますが、履歴データと比較してマッチング条件を評価できる点と、クエリー対象のユーザーまたはロール以外のデータ型の属性を検索できる点で異なります。フォレンジッククエリーの定義の詳細については、『Identity Manager 管理ガイド』を参照してください。

次の図は、データエクスポータを有効にしたときのデータフローを示します。

データエクスポータを計画する

データエクスポータを配備する前に、次の点について計画する必要があります。

エクスポートするデータ量はどのくらいですか。エクスポートされたデータ型の数によって、必要となるデータベーステーブルの数が決まります。データ型へのすべての変更をキューに入れたり、削除したオブジェクトまでエクスポートしたりすることを選択するとデータベース要件が大きくなります。詳細については、「データベースの検討事項」を参照してください。

専用のエクスポートサーバーが必要ですか。複雑なワークフローを実行するサーバー上でデータをエクスポートすると、パフォーマンスが低下する可能性があります。詳細については、「エクスポートサーバーの検討事項」を参照してください。

エクスポートする必要があるカスタム拡張属性がありますか。該当する場合は、エクスポートスキーマを更新し、Warehouse Interface Code (WIC) を再コンパイルしたあとに、エクスポートスキーマを更新する必要があります。詳細については、「データエクスポータをカスタマイズする」を参照してください。

データベースの検討事項

データエクスポータは、Identity Manager リポジトリとしてサポートされている任意のデータベースにエクスポートできます。さらに、データエクスポータは、Hibernate 3.2 でサポートされている任意の RDBMS で処理するようにしてください。

Hibernate のサポート

データエクスポータでは、Identity Manager Java オブジェクトと RDBMS テーブル間の双方向のマッピングで Hibernate 3.2 が使用されます。Identity Manager では、ウェアハウス Beans と RDBMS テーブル間のマッピングを制御するファイルセット (データ型ごとに 1 つ) が用意されています。これらのファイルは、$WSHOME/exporter/hbm ディレクトリに配置されています。

Hibernate では、接続プールとして C3P0 が使用されます。C3P0 ではログエントリが JRE ログシステムに送信されます。デフォルトでは、INFO レベルのログが有効化されています。ログの対象を制限するには、$JRE/lib/logging.properties ファイルの最終行に次の行を追加します。

com.mchange.v2.c3p0.impl.level=SEVERE
com.mchange.v2.c3p0.level=SEVERE
com.mchange.v2.log.level=SEVERE

オブジェクト関係マッピング

Identity Manager では作業の実行に (Java) オブジェクトが使用されますが、これらのオブジェクトをリレーショナルデータベーステーブルのセットにエクスポートする場合は、オブジェクト関係マッピングと一般に呼ばれている変換をオブジェクトで実行する必要があります。この変換が必要であるのは、RDBMS 関係で表現できるデータ型と任意の Java オブジェクトで表現できるデータ型には相違点があるためです。たとえば、次の Java クラスを検討します。

_subWidgets フィールドは入れ子構造であるため、関係用語で表現されると、このクラスで問題が発生します。subWidgets が共有された Widget オブジェクトの 2 つの階層を RDBMS テーブルのセットに分解し、階層の 1 つを削除しようとすると、参照関連の問題が発生します。

表現上の相違点に対処するために、Identity Manager では、エクスポートできるデータ型にいくつかの制約が置かれます。特に、この制限を使用すると、最上位の Java オブジェクトにスカラー属性、スカラー属性のリスト、およびスカラー属性のマップを含めることができます。場合によっては、Identity Manager により柔軟な表現方法が必要になることがあります。このような問題を解決するために、Identity Manager には PseudoModel が導入されています。概念上は、PseudoModel はスカラー属性のみを含むデータ構造です。最上位の Java オブジェクトには、PseudoModel または PseudoModel のリストである属性を含めることができます。PseudoModel は、拡張不可能な Identity Manager 構造です。PseudoModel の例は次のとおりです。

class TopLevelModel

{

private String _name;

private List<PseudoModelPoint> _points;

}

class PseudoModelPoint

{

private String _name;

private String _color;

private int _x;

private int _y;

private int _z;

}

PseudoModelPoint にはスカラー属性のみが含まれるため、Identity Manager では、TopLevelModel のオブジェクト関係変換を適切に実行できます。クエリーの注釈では、PseudoModel の色属性は次のようにアドレス可能です。

Identity Manager データエクスポートスキーマを調査すると、PseudoModel 型がいくつか見つかります。これらの型では、最上位のエクスポートモデルのより複雑なデータの一部が表現されます。PseudoModel は直接エクスポートされないため、PseudoModel のクエリーを直接実行できません。PseudoModel は単に、最上位モデルの属性で保持される構造化データです。

データベーステーブル

ウェアハウス DDL で定義された RDBMS テーブルの数は、エクスポートされるモデルの種類の数、および各モデルでエクスポートする属性の種類によって異なります。一般に、各モデルには 3 ～ 5 つのテーブルが必要です。それぞれのテーブルには、リスト/マップ値の属性が格納されます。デフォルト DDL には、約 50 個のテーブルが含まれています。エクスポートスキーマについて調べてから、一部の属性テーブルが除外されるように Hibernate マッピングファイルを変更することもできます。

領域の要件

エクスポータウェアハウスで必要な領域の量は、次の条件によって異なります。

通常、WorkflowActivity および ResourceAccount はもっともボリュームが大きいエクスポートモデルです。たとえば、単一のワークフローに複数のアクティビティーが含まれる場合があり、各ワークフローが実行されると、Identity Manager によって、ウェアハウスに書き込まれる数多くの新規レコードが作成される場合があります。ユーザーオブジェクトを編集すると、アカウントごとに 1 つの ResourceAccount レコードがユーザーにリンクされる場合があります。TaskInstance、WorkItem、および LogRecord も、ボリュームの大きいモデルです。単一の Identity Manager サーバーでは、1 時間で 50,000 個以上のオブジェクト変更が発生し、エクスポートされる可能性があります。

エクスポートサーバーの検討事項

特に大量のデータをエクスポートする予定の場合、専用サーバーでエクスポートタスクを実行することを検討するようにしてください。エクスポートタスクは、Identity Manager からウェアハウスに効率的にデータを転送し、エクスポート処理中に CPU を最大限消費します。専用サーバーを使用しない場合は、大量データのエクスポート中にレスポンス時間が大幅に低下するため、対話型トラフィックのサーバー処理を制限するようにしてください。

エクスポートタスクでは、主に Identity Manager リポジトリとステージングテーブルとの入出力処理が実行されます。キューに入れられたレコード数が増加するにつれてメモリーを増設する必要がありますが、エクスポートタスクのメモリー要件は控えめです。一般に、エクスポートタスクは入出力の速度によって制約され、スループットを向上させるために複数の同時実行スレッドが使用されます。

適切なサーバーを選択するには、検証が必要となります。入力 (Identity Manager リポジトリ) または出力 (ステージングテーブル) の転送速度が遅い場合、エクスポートタスクで最新の CPU は飽和状態になりません。エクスポート処理ではエクスポートサイクルの開始時にのみクエリーが発行されるため、入力パスのクエリー速度は問題になりません。大部分の時間は、レコードの読み書きに費やされます。

Identity Manager には、入出力データ速度を決定する JMX MBeans が用意されています。これらの MBeans の詳細については、『Identity Manager 管理ガイド』を参照してください。

デフォルト DDL を読み込む

このセクションでは、データベースの作成およびデフォルト DDL (Data Definition Language) の読み込みに必要なコマンドを列挙します。エクスポート DDL は、現在のエクスポートスキーマに一致するように、Identity Manager で提供されたツールによって生成されます。

create_warehouse スクリプトは、$WSHOME/exporter ディレクトリに配置されています。Identity Manager では、対応する drop_warehouse スクリプトも同じディレクトリに含まれています。

DB2

システム DBA として次のようなスクリプトを実行します。スクリプトを実行する前に、必ず idm_warehouse データベースおよび idm_warehouse/idm_warehouse user を作成してください。

CONNECT TO idm_warehouse USER idm_warehouse using 'idm_warehouse'
CREATE SCHEMA idm_warehouse AUTHORIZATION idm_warehouse
GRANT CONNECT ON DATABASE TO USER idm_warehouse

DDL を読み込むには、%WSHOME%¥exporter¥create_warehouse.db2 ファイルに次の行を追加します。

次に、次のコマンドを実行します (Windows DB2 サーバーを想定)。

MySQL

CREATE DATABASE IF NOT EXISTS idm_warehouse CHARACTER SET utf8 COLLATE utf8_bin;

GRANT ALL PRIVILEGES on idm_warehouse.* TO idm_warehouse IDENTIFIED BY 'idm_warehouse';

GRANT ALL PRIVILEGES on idm_warehouse.* TO idm_warehouse@'%' IDENTIFIED BY 'idm_warehouse';

# Give permissions to the "idm_warehouse" user when it logs in from the localhost.

GRANT ALL PRIVILEGES on idm_warehouse.* TO idm_warehouse@localhost IDENTIFIED BY 'idm_warehouse';

# mysql -uidm_warehouse -pidm_warehouse -Didm_warehouse < create_warehouse.mysql

Oracle

CREATE TABLESPACE idm_warehouse_ts
   DATAFILE 'D:/Oracle/warehouse/idm_warehouse.dbf' SIZE 10M
   AUTOEXTEND ON NEXT 10M
   DEFAULT STORAGE (INITIAL 10M NEXT 10M);

CREATE USER idm_warehouse IDENTIFIED BY idm_warehouse
DEFAULT TABLESPACE idm_warehouse_ts
QUOTA UNLIMITED ON idm_warehouse_ts;

SQL Server

システム DBA として次のようなスクリプトを実行します。必要に応じて、行のコメントを解除します。

--For SQL Server authentication:
-- sp_addlogin user, password, defaultdb
--For Windows authentication:
-- sp_grantlogin <domain¥user>

--For SQL Server 2005:
--CREATE LOGIN idm_warehouse WITH PASSWORD = 'idm_warehouse', DEFAULT_DATABASE = idm_warehouse sp_addlogin 'idm_warehouse', 'idm_warehouse', 'idm_warehouse'

--For SQL Server 2005 SP2 create a schema - not needed in other versions:
--CREATE SCHEMA idm_warehouse
--GO

--For SQL Server 2005 SP2 use CREATE user instead of sp_grantdbaccess
--CREATE USER idm_warehouse FOR LOGIN idm_warehouse with DEFAULT_SCHEMA = idm_warehouse

osql -d idm_warehouse -U idm_warehouse -P idm_warehouse < create_warehouse.sqlserver

データエクスポータをカスタマイズする

データエクスポートには、事実上、内部 (ObjectClass) スキーマと外部 (Export) スキーマの 2 レベルのスキーマがあります。これらのスキーマでは、Identity Manager の複数のリリースに準拠したデータ「インタフェース」が提供されます。準拠とは、属性名、データ型、およびデータの意味が変更されないことを意味します。属性は削除できますが、別の意味を表すためにその属性名を再使用することはできません。属性はいつでも追加できます。準拠するスキーマを使用すると、スキーマのバージョンに関係なくレポートを書き込むことができ、今後のバージョンでも変更なしで実行できます。

ObjectClass スキーマではデータの外観について Identity Manager サーバーのプログラムに通知します。一方、外部スキーマではデータの外観についてウェアハウスに通知します。内部スキーマはリリースごとに異なりますが、外部スキーマではリリース間で準拠が保持されます。

Identity Manager ObjectClass スキーマ

User および Role 型の ObjectClass スキーマは拡張できますが、その他のスキーマは変更できません。ObjectClass スキーマは、データオブジェクト自体にアクセスするために、Identity Manager サーバーで実行されるプログラムで使用されます。このスキーマは Identity Manager 内にコンパイルされ、Identity Manager 内で格納および処理されるデータを表現します。

このスキーマは Identity Manager の複数のバージョン間で変更される場合がありますが、エクスポートスキーマが原因で、データウェアハウスにとっては抽象的です。ObjectClass スキーマでは、Identity Manager の持続的なオブジェクトレイヤーの最上部にスキーマが抽象的に表示されます。これは、Identity Manager リポジトリに格納されるデータオブジェクトです。

カスタムユーザーおよびロール属性 (拡張属性とも呼ばれる) は、IDMSchemaConfiguration オブジェクトで定義されます。ObjectClass スキーマへの拡張属性の追加の詳細については、「設定オブジェクトを編集する」を参照してください。

エクスポートスキーマ

エクスポートスキーマには、ウェアハウスに書き込むことができるデータが定義されます。2 つのスキーマ間の相違点は非常に少ないですが、デフォルトでは ObjectClass スキーマのサブセットに制限されています。ObjectClass スキーマは Java オブジェクトで表現されますが、エクスポートスキーマには Java オブジェクトと RDBMS テーブル間の双方向のマッピングが必要です。

拡張属性を IDMSchemaConfiguration オブジェクトに追加したあとに、エクスポートスキーマでも同じ属性を定義する必要があります。この属性は、$WSHOME/model-export.xml ファイルで定義します。このファイルで Role または User モデルを検索し、属性を定義する field 要素を追加します。field 要素には、次のパラメータを含めることができます。

表 5-2 エクスポート属性パラメータ
パラメータ	説明
name	属性の名前。この値は、IDMSchemaConfiguration オブジェクトに割り当てられた名前と一致する必要があります。
type	属性のデータ型。完全 Java クラス名 (java.lang.String や java.util.List など) を指定する必要があります。
introduced	オプション。属性がスキーマに追加されたリリースを指定します。
friendlyName	データエクスポータの設定ページに表示されるラベル。
elementType	type パラメータが java.util.List である場合は、このパラメータにはリスト内の項目のデータ型が指定されます。共通の値には、java.lang.String と com.sun.idm.object.ReferenceBean が含まれます。
referenceType	elementType パラメータが com.sun.idm.object.ReferenceBeanである場合は、このパラメータは別の Identity Manager オブジェクトまたは擬似オブジェクトを参照します。
forensic	関係の決定に属性が使用されることを示します。指定可能な値は、User および Role です。
exported	false に設定すると、属性はエクスポートされません。データエクスポータのデータ型設定ページで、デフォルト属性を非表示にする場合は、属性定義に exported=false を追加します。エクスポートが無効にされたデフォルトスキーマに属性をエクスポートできるようにするには、カスタム WIC ライブラリを作成する必要があります。
クエリー可能	false に設定すると、このフィールドをフォレンジッククエリーで使用できません。
max-length	値の最大長。

次の例では、User モデルの一部としてエクスポートスキーマに telno という拡張属性を追加します。

<field name='telno'
   type='java.lang.String'
   introduced='8.0'
   max-length='20'
   friendlyName='Telephone Number'>
   <description>The phone number assigned to the user.</description>
</field>

ウェアハウスインタフェースコードを変更する

Identity Manager では、ウェアハウスインタフェースコード (WIC) はバイナリおよびソースの形式で提供されます。多くの配備ではバイナリ形式 (変更なし) で WIC コードを使用できますが、一部の配備ではその他の変更を行う場合もあります。WIC コードでは、エクスポートで使用される 2 つのインタフェース、およびフォレンジッククエリーインタフェースで使用される 3 番目のインタフェースを実装する必要があります。

デフォルトの WIC 実装では、RDBMS テーブルのセットに書き込まれます。多くのアプリケーションではこれで十分ですが、JMS キューまたはその他の一部のコンシューマに日付を書き込むために、カスタム WIC コードを作成することもできます。

com.sun.idm.exporter.Factory および com.sun.idm.exporter.Exporter クラスは、データのエクスポートに使用されます。エクスポートコードは、格納に適した形式へのモデル (Java データオブジェクト) の変換に関与します。一般に、これはリレーショナルデータベースへの書き込みを意味します。その結果、WIC コードはオブジェクトから関係への変換に関与します。

デフォルトの WIC 実装では、オブジェクト関係マッピングを提供するために Hibernate が使用されます。このマッピングは、Hibernate の .hbm.xml マッピングファイルで制御されます。同様にこのファイルは、エクスポートスキーマに基づいて生成されます。Hibernate では、その作業に Java bean スタイルのデータオブジェクトの使用が優先されます。これを実現するために、さまざまな get および set メソッドがあります。WIC コードでは、エクスポートスキーマと一致する Bean および Hibernate ファイルが生成されます。Hibernate で必要なマッピング機能が提供される場合は、任意の WIC コードを手動で変更する必要がなくなる場合もあります。

WIC ファイルは、InstallationDirectory/REF/exporter ディレクトリに配置されています。

新規ファクトリクラスを生成する

Identity Manager を使用すると、カスタム User および Role 属性を ObjectClass スキーマに追加できます。これらの属性 (拡張属性と呼ばれる) は、エクスポートスキーマに追加し、ウェアハウスインタフェースコード (WIC) を再生成し、コードを配備しない限り、エクスポートできません。

拡張属性が追加されると、エクスポートスキーマ制御ファイルを編集し、属性を追加する必要があります。属性をエクスポータから除外する場合は、単にスキーマフィールドに exported='false' を指定し、WIC コードを再生成します。

WIC コードを変更するには、次のものをシステムにインストールする必要があります。

拡張属性のエクスポートに必要なステップは次のとおりです。

WIC ソースコードを REF キットから入手します。

WSHOME 環境変数を Identity Manager のインストールディレクトリに設定します。

エクスポートスキーマ制御ファイル $WSHOME/model-export.xml をバックアップしてから、編集します。

WIC ソースの最上位ディレクトリに移動します。このディレクトリには、build.xml、BeanGenerator.java、および HbmGenerator.java というファイルが含まれているはずです。

アプリケーションサーバーを停止します。

環境から CLASSPATH を削除します。



注	次のステップで ant rebuild を実行する前に、環境から CLASSPATH を削除する必要があります。

ant rebuild コマンドを使用して、WIC コードを再ビルドします。

ant deploy コマンドを使用して、変更済みの WIC コードをアプリケーションサーバーに配備します。

アプリケーションサーバーを再起動します。



注	model-export.xml を変更し、前述のステップで示したように WIC を再ビルドすると、新規ウェアハウス DDL が生成されます。古いテーブルを削除し、新規 DDL をロードする必要があります。これにより、テーブル上にあるデータがすべて削除されます。

トラブルシューティング

エクスポータから転送されるデータの量と種類が増えると、データエクスポート中に問題が発生する可能性が高くなります。

Beans およびその他のツール

データエクスポータのパフォーマンスとスループットは、Identity Manager で提供される JMX 管理 Bean から監視できます。エクスポートデータのパフォーマンス影響を最小限にするために、Identity Manager では、揮発性のメモリーベースのキューが一部使用されています。予期せずにサーバーが終了した場合は、これらのキューのデータは失われます。これらのキューのサイズを一定期間監視することにより、このような危険にさらされているかどうかを判断できます。

Model Serialization の制限

適切な時間にエクスポートできることを保証するには、データエクスポータではいくつかのオブジェクトをキューに入れる必要があります。これらのオブジェクトは、Java 直列化によってキューに入れられます。ただし、直列化できないエクスポート済みオブジェクトにデータが含まれる可能性があります。この場合、エクスポータコードでは直列化不可能なデータが検出され、問題を示すトークンで置換されます。これにより、残りのオブジェクトをエクスポートできるようになります。

レジストリポーリングの設定

各タイプには、独立したエクスポートサイクルを指定できます。管理者インタフェースでは、ほどんどの用途に十分に対応できる単純なサイクルを定義するための簡単な方法が提供されます。ただし、エクスポートサイクルは、さらに優れた柔軟性をサポートするネイティブ cron のスタイルで指定することもできます。

トレースとログ

デフォルト WIC コードでは、エクスポート済みデータオブジェクトのオブジェクト/RDBMS マッピングを提供するために Hibernate が使用されます。ただし、Hibernate ライブラリを使用することは、トレースおよびログが完全には統合されないことを意味します。com.sun.idm.warehouse.* package を使用すると、実際の WIC コードのトレースを実行できます。ただし、Hibernate のログを有効化するには別の技術が必要です。

Hibernate セッションを開始するコードに Hibernate プロパティーを渡すには、DatabaseConnection 設定オブジェクトに属性を追加します。属性名に「X」という接頭辞を付ける必要があります。たとえば、ネイティブプロパティー名が hibernate.show_sql である場合は、設定オブジェクトに Xhibernate.show_sql と定義する必要があります。次の例では、Hibernate によって生成済みの SQL がアプリケーションサーバーの標準出力に表示されます。

デフォルトでは、接続プールに C3P0 が Hibernate で使用されます。C3P0 でログを取得するには、java.logging 機能が使用されます。この機能は、$JRE/lib/logging.properties ファイルで制御されます。

前へ目次索引次へ
Sun™ Identity Manager 8.0 配備に関する技術概要