| Oracle® Fusion Middleware Oracle Identity Manager開発者ガイド 11g リリース1(11.1.1) B66705-01 |
|
 前 |
 次 |
事前定義済プロバイダで対応できないプロバイダ要件に対して、カスタム・プロバイダを作成する必要があります。この章では、カスタム・プロバイダの作成手順について説明します。
内容は次のとおりです。
次の各項では、汎用テクノロジ・コネクタの作成中および使用中におけるプロバイダの役割を説明します。
汎用テクノロジ・コネクタは管理およびユーザー・コンソールで作成します。コネクタ作成手順のタスクの1つとして、データセットおよびデータセット間のデータ・フローが定義されます。このタスクは、メタデータの検出プロセスにより容易になります。
汎用テクノロジ・コネクタのコンテキストでは、メタデータという用語はユーザー・アカウント情報を構成する一連のアイデンティティ・フィールドを意味します。メタデータの検出という用語は、プロバイダによるターゲット・システムのメタデータ読込みおよび解析を指します。
メタデータの検出機能は、すべてのタイプのプロバイダでサポートされます。つまり、カスタム・プロバイダの作成時に、メタデータ読込み機能をプロバイダに組み込むことができます。
|
注意: Javadocでは、メタデータの検出という用語のかわりにメタデータ定義という用語が使用されています。 |
図20-1に、メタデータの検出プロセスを示します。
次の一連の手順で、メタデータの検出プロセスについて説明します。この一連の手順は、汎用テクノロジ・コネクタの作成時に「リコンシリエーション」オプションと「プロビジョニング」オプションの両方を選択するという想定に基づいています。いずれのオプションも選択しない場合は、対応する手順が実行されません。
|
関連項目: 次の手順で示されているSPIメソッドおよび値オブジェクトの詳細は、Oracle Fusion Middleware Oracle Identity Manager Java APIリファレンスを参照してください。 Javadocでは、メタデータの検出という用語とメタデータ定義という用語が同義的に使用されています。 |
リコンシリエーション・トランスポート・プロバイダのinitializeメソッドが呼び出され、このプロバイダのインスタンスが作成されます。
リコンシリエーション・フォーマット・プロバイダのinitializeメソッドが呼び出され、このプロバイダのインスタンスが作成されます。
リコンシリエーション・トランスポート・プロバイダのgetMetadataメソッドが呼び出され、ターゲット・システムからメタデータがフェッチされます。このメソッドの出力はTargetSchema値オブジェクトであり、ここにターゲット・システムからフェッチしたメタデータが格納されています。
リコンシリエーション・フォーマット・プロバイダのparseMetadataメソッドが呼び出され、ターゲット・システムからフェッチしたメタデータが解析されます。このメソッドの出力はOIMSchema値オブジェクトであり、ここにターゲット・システムからフェッチしたメタデータが格納されています。
プロビジョニング・トランスポート・プロバイダのinitializeメソッドが呼び出され、このプロバイダのインスタンスが作成されます。
プロビジョニング・フォーマット・プロバイダのinitializeメソッドが呼び出され、このプロバイダのインスタンスが作成されます。
リコンシリエーション・トランスポート・プロバイダおよびリコンシリエーション・フォーマット・プロバイダでメタデータを検出できない場合、プロビジョニング・トランスポート・プロバイダおよびプロビジョニング・フォーマット・プロバイダについて手順1から4が繰り返されます。
|
注意: プロバイダは初期化した後、次のいずれかのイベントが発生するまでOracle Identity Managerのキャッシュに格納されています。
検証プロバイダおよびトランスフォーメーション・プロバイダは、必要な場合にのみインスタンス化されます。キャッシュには格納されません。 |
共有ドライブ・リコンシリエーション・トランスポート・プロバイダとCSVリコンシリエーション・フォーマット・プロバイダでは、ターゲット・システムからメタデータを検出できます。ただし、Webサービス・プロビジョニング・トランスポート・プロバイダおよびSPMLプロビジョニング・フォーマット・プロバイダでは、この機能はサポートされていません。
図20-2に、リコンシリエーション中のプロバイダの役割を示します。
次の各手順で、リコンシリエーション中のプロバイダの役割について説明します。
リコンシリエーション・トランスポート・プロバイダのインスタンスをキャッシュで使用できない場合、initializeメソッドが呼び出され、このプロバイダのインスタンスが作成されます。
リコンシリエーション・フォーマット・プロバイダのインスタンスをキャッシュで使用できない場合、initializeメソッドが呼び出され、このプロバイダのインスタンスが作成されます。
管理およびユーザー・コンソールで汎用テクノロジ・コネクタを作成している場合、リコンシリエーション実行のバッチ・サイズを指定できます。このパラメータを使用して、リコンシリエーション実行中にリコンシリエーション・エンジンがターゲット・システムからフェッチするレコードの総数をバッチに分割します。このパラメータのデフォルト値はAllです。
バッチ・サイズを指定しない場合、リコンシリエーションのこの段階でリコンシリエーション・トランスポート・プロバイダのgetFirstPageメソッドが呼び出され、リコンシリエーション用に準備されているターゲット・システム・レコードの全体がフェッチされます。
バッチ・サイズを指定すると、リコンシリエーション・トランスポート・プロバイダのgetFirstPageメソッドが呼び出され、リコンシリエーション用にターゲット・システム・レコードの最初のバッチがフェッチされます。リコンシリエーション用のターゲット・システム・レコードのバッチが複数ある場合は、同一プロバイダのgetNextPageメソッドが(必要に応じて複数回)呼び出されます。
リコンシリエーション・フォーマット・プロバイダのparseRecordsメソッドが呼び出され、TargetRecord値オブジェクト配列の各レコードが処理されます。このメソッドの出力はOIMRecord値オブジェクトの配列です。
汎用テクノロジ・コネクタの作成時に、「ソース」データセットから「リコンシリエーション・ステージング」データセットへのデータの移動中にデータを検証するため検証プロバイダを選択すると、次のように実行されます。
検証プロバイダのインスタンスが作成されます。
OIMRecord値オブジェクト配列の各レコードに指定された属性に対して、それぞれの検証プロバイダのvalidateメソッドが実行されます。
汎用テクノロジ・コネクタの作成時に検証プロバイダを選択しない場合、手順5は実施されず、OIMRecord値オブジェクト配列の各要素は手順6に進みます。
汎用テクノロジ・コネクタの作成時に、「ソース」データセットから「リコンシリエーション・ステージング」データセットへのデータの移動中のデータを変更するため変換プロバイダを選択してある場合、次のように実行されます。
変換プロバイダのインスタンスが作成されます。
変換プロバイダのtransformDataメソッドにより、次のいずれかの出力として生成されたOIMRecord値オブジェクト配列が処理されます。
各検証プロバイダのvalidateメソッド(検証プロバイダを選択した場合)
リコンシリエーション・フォーマット・プロバイダのparseRecordsメソッド(検証プロバイダを選択しなかった場合)
汎用テクノロジ・コネクタの作成時に変換プロバイダを選択しない場合、手順6は実施されず、前の手順(手順4または手順5)で得られたOIMRecord値オブジェクト配列の各要素は手順7に進みます。
この段階では、OIMRecord値オブジェクト配列は、第18.2.1項「リコンシリエーション・モジュールのプロバイダおよびデータセット」で説明する「リコンシリエーション・ステージング」データセットに対応します。OIMRecord値オブジェクト配列の各要素がリコンシリエーション・エンジンに渡されます。
リコンシリエーション手順の終了時には、リコンシリエーション・トランスポート・プロバイダのendメソッドが呼び出されます。このメソッドから、汎用テクノロジ・コネクタ・フレームワークでITリソースのTimestampパラメータに格納される文字列値が戻されます。このフレームワークでは、リコンシリエーションの実行が完了した段階がTimestampパラメータによりトラッキングされます。
図20-3は、プロビジョニング中のプロバイダの役割を示しています。
次の各手順で、プロビジョニング中のプロバイダの役割について説明します。
プロビジョニング・トランスポート・プロバイダのインスタンスをキャッシュで使用できない場合、initializeメソッドが呼び出され、このプロバイダのインスタンスが作成されます。
プロビジョニング・フォーマット・プロバイダのインスタンスをキャッシュで使用できない場合、initializeメソッドが呼び出され、このプロバイダのインスタンスが作成されます。
汎用テクノロジ・コネクタの作成時に作成されるコネクタ・オブジェクトの1つに、汎用テクノロジ・コネクタ・アダプタがあります。このアダプタにより、プロビジョニング・データ・レコードが名前/値ペアのハッシュマップに変換されます。このハッシュマップにはプロセス・インスタンスのデータが含まれています。各ハッシュマップは、OIMRecord値オブジェクトの要素に変換されます。この段階では、OIMRecord値オブジェクト配列は、第18.2.3項「Oracle Identity Managerデータセット」で説明する「Oracle Identity Manager」データセットに対応します。
汎用テクノロジ・コネクタの作成時に、「Oracle Identity Manager」データセットから「プロビジョニング・ステージング」データセットへのデータの移動中のデータを変更するため変換プロバイダを選択すると、次のように実行されます。
変換プロバイダのインスタンスが作成されます。
変換プロバイダのtransformDataメソッドにより、入力したOIMRecord値オブジェクトの指定の属性が処理され、これらのレコードが出力のOIMRecord値オブジェクトに変換されます。この段階では、OIMRecord値オブジェクトは、第18.2.2項「プロビジョニング・モジュールのプロバイダおよびデータセット」で説明する「プロビジョニング・ステージング」データセットに対応します。
プロビジョニング・フォーマット・プロバイダのformatDataメソッドが呼び出され、OIMRecord値オブジェクトが処理されます。このプロセスの出力は、TargetOperation値オブジェクトです。
プロビジョニング・トランスポート・プロバイダのsendDataメソッドが呼び出され、TargetOperation値オブジェクトがターゲット・システムに送信されます。
プロビジョニング操作が作成リクエストの場合、結果は次のイベントのいずれかになります。
ターゲット・システムで作成操作が正常に完了した時点で、新しく作成されたユーザー・アカウントに割り当てられる「ID」フィールド値が、sendDataメソッドから戻されます。この値はその後、汎用テクノロジ・コネクタ・フレームワークに渡され、このフレームワークによってデータベースにポストされます。
「ID」フィールド値が返されない場合は、作成操作が失敗したとみなされます。管理およびユーザー・コンソールにエラー・メッセージが表示されます。
名前/値ペアの作成後のいずれかの段階で操作が失敗すると、管理およびユーザー・コンソールにエラー・メッセージが表示されます。
プロビジョニング操作が更新または削除リクエストの場合、「ID」フィールドは名前/値ペアの1つです。このタイプのプロビジョニング・リクエストが送信された場合、結果は次のイベントのいずれかになります。
名前/値ペアの作成後のいずれかの段階で操作が失敗すると、管理およびユーザー・コンソールにエラー・メッセージが表示されます。
「ID」フィールドの値は、更新操作または削除操作が正常に完了した時点で、プロビジョニング・トランスポート・プロバイダの実装に応じて返される場合と返されない場合があります。
どちらの場合も、汎用テクノロジ・コネクタ・フレームワークでは「ID」フィールド値は必要ありません。
カスタム・プロバイダの作成は次の各手順で構成されます。
プロバイダ要件を判断するためのガイドラインは、次のとおりです。
リコンシリエーション・プロバイダ要件の確認には、次のガイドラインが適用されます。
ターゲット・システムをOracle Identity Managerのユーザー・アカウント情報のソースとしてのみ使用する場合、リコンシリエーション・トランスポート・プロバイダとリコンシリエーション・フォーマット・プロバイダのみが必要です。プロビジョニング・トランスポート・プロバイダとプロビジョニング・フォーマット・プロバイダは必要ありません。
汎用テクノロジ・コネクタにリコンシリエーション・モジュールを含める場合、リコンシリエーション・トランスポート・プロバイダとリコンシリエーション・フォーマット・プロバイダの両方を(いずれかのプロバイダが不要な場合にも)含める必要があります。
リコンシリエーション・フォーマット・プロバイダの機能は、ターゲット・システムのデータをOracle Identity Managerでサポートされている形式に変換するものです。ターゲット・システムで、Oracle Identity Managerのサポートする形式でデータが生成される場合にも、汎用テクノロジ・コネクタの作成時にはリコンシリエーション・フォーマット・プロバイダを含める必要があります。
事前定義済プロバイダで対応できないプロバイダ要件に対してのみ、カスタム・プロバイダの作成が必要になります。
汎用テクノロジ・コネクタに含める必要のあるプロバイダのタイプは、ターゲット・システムでサポートされているデータ・フォーマットおよびデータ転送メカニズムによって異なります。データ・フォーマットとデータ転送メカニズムの組合せが、事前定義済プロバイダの組合せで対応できるものであれば、カスタム・プロバイダを作成する必要はありません。
たとえば、ターゲット・システムでカンマ区切り形式のリコンシリエーション・データファイルを生成できる場合は、共有ドライブ・リコンシリエーション・トランスポート・プロバイダとCSVリコンシリエーション・フォーマット・プロバイダを使用できます。カスタム・リコンシリエーション・プロバイダを作成する必要はありません。
プロビジョニング・モジュール用プロビジョニング・プロバイダの要件の確認には、次のガイドラインが適用されます。
ターゲット・システムをOracle Identity Managerで開始されるプロビジョニング操作のターゲットとしてのみ使用する場合、プロビジョニング・トランスポート・プロバイダとプロビジョニング・フォーマット・プロバイダのみが必要です。リコンシリエーション・トランスポート・プロバイダとリコンシリエーション・フォーマット・プロバイダは必要ありません。
汎用テクノロジ・コネクタにプロビジョニング・モジュールを含める場合、プロビジョニング・トランスポート・プロバイダとプロビジョニング・フォーマット・プロバイダの両方を(いずれかのプロバイダが不要な場合にも)含める必要があります。このガイドラインについては次の例で説明します。
プロビジョニング・フォーマット・プロバイダの機能は、Oracle Identity Managerのデータをターゲット・システムでサポートされている形式に変換するものです。ターゲット・システムでOracle Identity Managerの出力データ・フォーマットがサポートされている場合にも、汎用テクノロジ・コネクタの作成時にはプロビジョニング・フォーマット・プロバイダを含める必要があります。
事前定義済プロバイダで対応できないプロバイダ要件に対してのみ、カスタム・プロバイダの作成が必要になります。
汎用テクノロジ・コネクタに含める必要のあるプロバイダのタイプは、ターゲット・システムでサポートされているデータ・フォーマットおよびデータ転送メカニズムによって異なります。データ・フォーマットとデータ転送メカニズムの組合せが、事前定義済プロバイダの組合せで対応できるものであれば、カスタム・プロバイダを作成する必要はありません。
たとえば、ターゲット・システムがWebサービスであり、SOAPメッセージにパッケージ化されたSPMLベースのプロビジョニング・リクエストの受入れや解析が可能な場合は、SPMLプロビジョニング・フォーマット・プロバイダとWebサービス・プロビジョニング・トランスポート・プロバイダを使用できます。カスタム・プロビジョニング・プロバイダを作成する必要はありません。
プロバイダ・パラメータとは、プロバイダが目的の機能を実行するために必要な値です。たとえば、プロビジョニング・リクエスト・ファイルをターゲット・システム・サーバーにコピーするプロビジョニング・トランスポート・プロバイダには、ターゲット・システムへの接続に接続パラメータが必要になります。
汎用テクノロジ・コネクタの作成時に、その汎用テクノロジ・コネクタ用に選択するプロバイダのパラメータ値を指定します。
カスタム・プロバイダを作成する場合、そのプロバイダが機能するために必要なパラメータをすべて識別する必要があります。また、このようなパラメータをランタイム・パラメータと設計パラメータに分類する必要もあります。
ランタイム・パラメータは、プロバイダの設計に制約されない値を示します。たとえば、リコンサイルするデータファイルが格納されているディレクトリの場所がランタイム・パラメータ値となります。設計パラメータは、プロバイダ設計の一部として定義される1つまたは複数の値を表します。たとえば、リコンシリエーション・フォーマット・プロバイダで解析可能なキャラクタ・セット・エンコーディングのフォーマットなどは、そのプロバイダの設計パラメータに分類されます。
表20-1に示す値オブジェクトのJavaコード実装を開発します。前述したように、このような値オブジェクトはプロバイダ操作の様々な段階で使用されます。
|
注意: 汎用テクノロジ・コネクタに含めない値オブジェクトのJavaコード実装については、開発する必要はありません。 |
表20-1 プロバイダ操作中に使用される値オブジェクト
| 使用領域 | 値オブジェクト | Javadocパッケージ |
|---|---|---|
|
メタデータの検出 |
|
|
|
|
|
|
|
プロビジョニング |
|
|
|
リコンシリエーション |
|
|
|
|
|
プロバイダ操作中に使用されるSPIメソッドのJavaコード実装を開発します。前述したように、SPIメソッドはプロバイダ操作の様々な段階で呼び出されます。各プロバイダのSPIメソッドの情報へのリンクは、JavadocのPackage com.thortech.xl.gc.spiのページを参照してください。
|
注意: 汎用テクノロジ・コネクタに含めないプロバイダのSPIメソッドのJavaコード実装については、開発する必要はありません。 |
値オブジェクトおよびSPIメソッドのJavaコード実装には、ロギング機能を組み込むことをお薦めします。これにより、プロバイダ使用時に発生する可能性のあるエラーのトラブルシューティングを簡略化できます。
汎用テクノロジ・コネクタ・フレームワーク用のロギング・モジュールは、Oracle Identity Managerのロギング拡張機能です。表20-2に、サポートされている各プロバイダ・タイプ固有のモジュールを示します。
表20-2 サポートされる各プロバイダ・タイプに固有のロギング・モジュール
| ロギング・モジュール | 汎用テクノロジ・コネクタ・フレームワークの機能モジュール |
|---|---|
|
|
プロビジョニング・フォーマット・プロバイダ |
|
|
プロビジョニング・トランスポート・プロバイダ |
|
|
リコンシリエーション・トランスポート・プロバイダ |
|
|
リコンシリエーション・フォーマット・プロバイダ |
|
|
変換プロバイダ |
|
|
検証プロバイダ |
カスタム・プロバイダの組込み例外処理の詳細は、Oracle Fusion Middleware Oracle Identity Manager Java APIリファレンスを参照してください。
プロバイダXMLファイルには、汎用テクノロジ・コネクタ・フレームワークにプロバイダを登録するために必要なデータが含まれます。プロバイダXMLファイルは必ず作成してください。表20-3に、カスタム・プロバイダのプロバイダXMLファイルに含める要素を示します。
|
注意: 1つのプロバイダXMLファイルを使用して複数のプロバイダを定義できます。また、作成する各プロバイダについて、それぞれプロバイダXMLファイルを作成することもできます。 |
プロバイダXMLファイルは、MDSにあるスキーマ定義に従っている必要があります。スキーマおよびプロバイダ定義XMLファイルは、次の場所にあります。
PROVIDER_DEF_XSD_LOCATION = "/db/GTC/Schema";
PROVIDER_DEF_XML_LOCATION = "/db/GTC/ProviderDefinitions";
表20-3 プロバイダXMLファイルの要素
| 要素 | 説明 |
|---|---|
|
|
プロバイダXMLファイルのルート要素 |
|
|
リコンシリエーション・プロバイダの記述に使用する構成要素の親要素 |
|
|
プロビジョニング・プロバイダの記述に使用する構成要素の親要素 |
|
|
変換プロバイダの記述に使用する構成要素の親要素 |
|
|
検証プロバイダの記述に使用する構成要素の親要素 |
|
|
リコンシリエーション・トランスポート・プロバイダの記述に使用する構成要素の親要素 この要素には次の属性があります。
|
|
|
リコンシリエーション・フォーマット・プロバイダの記述に使用する構成要素の親要素 この要素には次の属性があります。
|
|
|
プロビジョニング・フォーマット・プロバイダの記述に使用する構成要素の親要素 この要素には次の属性があります。
|
|
|
プロビジョニング・トランスポート・プロバイダの記述に使用する構成要素の親要素 この要素には次の属性があります。
|
|
|
変換プロバイダの記述に使用する構成要素の親要素 この要素には次の属性があります。
|
|
|
検証プロバイダの記述に使用する構成要素の親要素 この要素には次の属性があります。
|
|
|
あらゆるタイプのプロバイダの構成要素の親要素 |
|
|
プロバイダのパラメータに関する情報を提供する要素
|
|
|
この要素は、
プロビジョニング・リクエストに含めるデータ属性の一部は、プロビジョニング操作を正常に完了するために不可欠なものです。プロビジョニング・フォーマット・プロバイダでは最終的なプロビジョニング入力データ・フォーマットが生成されるため、このプロバイダの定義にはこのような必須データ属性を含める必要があります。したがって、このような属性がターゲット・システムで必要な場合は、プロビジョニング・フォーマット・プロバイダXMLファイルで |
|
|
この要素は
注意: プロビジョニング・フォーマット・プロバイダやプロビジョニング・トランスポート・プロバイダでは、 |
|
関連項目:
|
リソース・バンドルとは、ロケール固有のテキスト文字列を含むファイルのことです。このようなテキスト文字列は、実行時にOracle Identity Managerで読み込まれ、管理およびユーザー・コンソールにGUI要素のラベルやメッセージとして表示されます。リソース・バンドルのファイル拡張子は.propertiesです。
サポートされる各言語のリソース・バンドルは、Oracle Identity Managerのインストール中にOracle Identity Managerサーバーにコピーされます。これには事前定義済プロバイダのリソース・バンドルも含まれます。
カスタム・プロバイダの場合、使用する各ロケールに応じたリソース・バンドル・エントリを作成する必要があります。リソース・バンドルの作成手順の概要を次に示します。
テキスト・エディタで新規ファイルを開きます。
このファイルに、次のテキスト文字列のエントリを作成します。
|
注意:
|
プロバイダ名
プロバイダ名は次の形式で記述します。
gc.provider.Provider_Type.Provider_Name=Label_string_in_the_required_language
プロビジョニング・フォーマット・プロバイダのプロバイダ名エントリは、英語では次のようになります。
gc.provider.ProvFormatProvider.SPML=SPML
プロバイダ・パラメータのラベルおよび説明
プロバイダのパラメータのラベルおよびその説明は、次の形式で記述します。
gc.Provider_Type.Provider_Name.Parameter_Name.label=Parameter_label_in_the_required_language gc.Provider_Type.Provider_Name.Parameter_Name.description=Parameter_description_in_the_required_language
プロビジョニング・フォーマット・プロバイダのプロバイダ・パラメータのラベルおよびその説明エントリは、英語では次のようになります。
gc.ProvFormatProvider.SPML.targetID.label=Target ID gc.ProvFormatProvider.SPML.targetID.description=Target ID of the provisioning target
レスポンス・コードおよび説明
レスポンス・コードおよび説明は、次の形式で記述します。
GC.GCPROV.PROVIDER_TYPE.PROVIDER_NAME.RESPONSE_CODE=Response_code_in_the_required_language GC.GCPROV.PROVIDER_TYPE.PROVIDER_NAME.RESPONSE_CODE.description=Description_in_the_required_language
プロビジョニング・フォーマット・プロバイダのレスポンス・コードおよび説明のエントリは、英語では次のようになります。
GC.GCPROV.ProvFormatProvider.SPML.SPML_VELOCITY_PROPERTIES_NOT_READ=SPML Velocity Properties Not Read GC.GCPROV.ProvFormatProvider.SPML.SPML_VELOCITY_PROPERTIES_NOT_READ.description=Necessary SPML template properties could not be read.
メタデータの検出のエラー・メッセージ
メタデータの検出のエラー・メッセージは、次の形式で記述します。
gc.error.Provider_Type.Provider_Name.ERROR_CODE=Error_Description
ここで、ERROR_CODEは例外クラスのコンストラクタに引数として渡されるerrorCode文字列の値と同じである必要があります。たとえば、ReconciliationTransportExceptionクラスのコンストラクタの1つを次に示します。
ReconciliationTransportException(java.lang.String errorCode, java.lang.String isMessage)
リソース・バンドルでは、errorCode文字列に考えられるすべての値のための行を追加する必要があります。
リコンシリエーション・トランスポート・プロバイダのメタデータの検出エラー・メッセージは、英語では次のようになります。
gc.error.ReconTransportProvider.SharedDrive.NO_READ_FILE=There are no readable files to detect metadata.
リソース・バンドルを保存して閉じます。
プロバイダをデプロイするには、次の手順を実行します。
JARファイルを次のようにデプロイします。
Javaコード・ファイルをすべてコンパイルし、JARファイルにパッケージ化します。
JARファイルを次のディレクトリにコピーします。
OIM_HOME/JavaTasks
また、JARファイルをOracle Identity Managerデータベースにアップロードします。詳細は、「カスタム・プロバイダのデプロイ」を参照してください。
|
注意: クラスタ化されている環境では、作成するそれぞれのファイルをクラスタの各ノードの対応ディレクトリにコピーする必要があります。 |
プロバイダXMLファイルを次のようにデプロイします。
プロバイダXMLファイルを次の場所のMDSにアップロードします。
PROVIDER_DEF_XML_LOCATION = "/db/GTC/ProviderDefinitions":
Oracle Identity Managerを再起動します。
次のようにプロバイダXMLファイルが正しく登録されているかどうかを確認します。
i.管理およびユーザー・コンソールにログインします。
ii.「汎用テクノロジ・コネクタ」を開き、「作成」をクリックします。プロバイダXMLファイルでエラーが発生した場合は、エラー・メッセージが表示されます。
エラー・メッセージが表示される場合、XMLファイル内で問題を修正し、Oracle Identity Managerを再起動して手順iと手順iiを繰り返します。
この手順は「作成」をクリックしてもエラー・メッセージが表示されなくなるまで繰り返します。
プロバイダのリソース・バンドルを次のようにデプロイします。
OIM_HOME/bin/ディレクトリにあるUploadResourceBundles.shユーティリティを使用して、リソース・バンドルをMDSにアップロードします。ユーティリティの実行の詳細は、「リソース・バンドルのアップロード・ユーティリティ」を参照してください。
新しいリソース・バンドル・エントリを有効にするには、PurgeCacheスクリプトを実行するか、アプリケーション・サーバーを再起動します。PurgeCacheユーティリティの実行の詳細は、Oracle Fusion Middleware Oracle Identity Manager管理者ガイドのキャッシュのパージに関する説明を参照してください。
フォーマット・プロバイダとトランスポート・プロバイダはペアで機能します。リコンシリエーション中、リコンシリエーション・トランスポート・プロバイダの出力がリコンシリエーション・フォーマット・プロバイダに渡されます。プロビジョニングの実行中には、プロビジョニング・フォーマット・プロバイダの出力がプロビジョニング・トランスポート・プロバイダに渡されます。つまり、トランスポート・プロバイダとフォーマット・プロバイダの実装は、この間で渡される値オブジェクトの実装を介してリンクしています。この依存性は、フォーマット・プロバイダおよびトランスポート・プロバイダの再利用に関するガイドラインの基礎となります。
一方、検証プロバイダまたは変換プロバイダには、このような他のプロバイダへの依存性はありません。このため、検証プロバイダおよび変換プロバイダの再利用に関するガイドラインはありません。事前定義済およびカスタムの変換プロバイダと検証プロバイダのアクションはターゲット・システムのデータ・フォーマットやデータ転送メカニズムに固有のものではないため、これらのプロバイダの両方を再利用できます。
フォーマット・プロバイダおよびトランスポート・プロバイダの再利用に関するガイドラインは、次の各項に分けて説明します。
第20.1.2項「リコンシリエーション中のプロバイダの役割」で説明するように、リコンシリエーション・トランスポート・プロバイダとリコンシリエーション・フォーマット・プロバイダの間のデータ交換には、TargetRecord値オブジェクトが使用されます。リコンシリエーション・トランスポート・プロバイダにより、リコンシリエーション中にフェッチされたターゲット・システム・レコードに対してTargetRecord値オブジェクトの配列が作成されます。その後、リコンシリエーション・フォーマット・プロバイダにより、値オブジェクト配列のデータが処理され、リコンシリエーション・エンジンに渡されます。
ユーザーの組織の操作環境に、TS1およびTS2という2つのターゲット・システムがあるとします。TS1では、リコンシリエーション中のデータ抽出にWebベースのインタフェースを利用できます。TS2では、そのアイデンティティ・ストアのデータを他のアプリケーションで読み取れるようにするAPIが用意されています。どちらのターゲット・システムでも同じデータ・フォーマットがサポートされています。両方のターゲット・システムのユーザー・データをリコンサイルする場合、各ターゲット・システムに対して汎用テクノロジ・コネクタを1つずつ作成する必要があります。それぞれの汎用テクノロジ・コネクタには、リコンシリエーション・トランスポート・プロバイダを作成する必要があります。ただし、リコンシリエーション・フォーマット・プロバイダは、それぞれの汎用テクノロジ・コネクタに対して作成するのではなく、1つのみ作成してそれを再利用できます。同様に、TS1およびTS2で(同じデータ・フォーマットをサポートしていない場合でも)同じデータ転送メカニズムがサポートされていれば、リコンシリエーション・トランスポート・プロバイダを再利用して別のリコンシリエーション・フォーマット・プロバイダを作成することが可能です。
リコンシリエーション・トランスポート・プロバイダを再利用する場合は、TargetRecord値オブジェクトの実装に、リコンシリエーション・フォーマット・プロバイダで実行される関数に固有のコードが含まれないようにしてください。リコンシリエーション・フォーマット・プロバイダを再利用する場合は、TargetRecord値オブジェクトの実装に、リコンシリエーション・トランスポート・プロバイダで実行される関数に固有のコードが含まれないようにしてください。
事前定義リコンシリエーション・プロバイダの再利用
共有ドライブ・リコンシリエーション・トランスポート・プロバイダおよびCSVリコンシリエーション・フォーマット・プロバイダの実装は事前定義済プロバイダであり、データ・フォーマットと単一のデータ転送メカニズムの固定の組合せ向けに作成されています。共有ドライブ・リコンシリエーション・トランスポート・プロバイダでは、フラット・ファイルからデータを読み取り、CSVリコンシリエーション・フォーマット・プロバイダにTargetRecord値オブジェクトの配列を渡します。
共有ドライブ・リコンシリエーション・トランスポート・プロバイダの実装は、ページ化リコンシリエーションと複数値(子)データ・リコンシリエーションという2つの要素に基づきます。この2つの要素では、TargetRecord値オブジェクトの配列を作成する前に、プロバイダでのターゲット・システムのデータ解析を可能にする必要があります。つまり、共有ドライブ・リコンシリエーション・トランスポート・プロバイダではターゲット・システム・データの特定の型を解析でき、CSVリコンシリエーション・フォーマット・プロバイダには共有ドライブ・リコンシリエーション・トランスポート・プロバイダから提供される出力のみを使用できるため、相互依存の関係になっています。そのため、CSVリコンシリエーション・フォーマット・プロバイダのパラメータは、共有ドライブ・リコンシリエーション・トランスポート・プロバイダのパラメータとバンドルされています。
このような理由のため、共有ドライブ・リコンシリエーション・トランスポート・プロバイダとカスタム・リコンシリエーション・フォーマット・プロバイダは併用できず、またCSVフォーマット・プロバイダとカスタム・リコンシリエーション・トランスポート・プロバイダは併用できません。
第20.1.3項「プロビジョニング中のプロバイダの役割」で説明するように、プロビジョニング・トランスポート・プロバイダとプロビジョニング・フォーマット・プロバイダの間のデータ交換には、TargetOperation値オブジェクトが使用されます。プロビジョニング・フォーマット・プロバイダで、ターゲット・システムへの送信用にプロビジョニング・データからTargetOperation値オブジェクトが作成されます。次にプロビジョニング・トランスポート・プロバイダで、この値オブジェクトがターゲット・システムに渡されます。
ユーザーの組織の操作環境に、TS1およびTS2という2つのターゲット・システムがあるとします。TS1では、プロビジョニング・リクエスト・データの受信にWebベースのインタフェースを利用できます。TS2では、そのアイデンティティ・ストアにプロビジョニング・データを書き込めるようにするAPIが用意されています。どちらのターゲット・システムでも同じデータ・フォーマットがサポートされています。両方のターゲット・システムでプロビジョニング操作を実行する場合、各ターゲット・システムに対して汎用テクノロジ・コネクタを1つずつ作成する必要があります。それぞれの汎用テクノロジ・コネクタには、プロビジョニング・トランスポート・プロバイダを作成する必要があります。ただし、プロビジョニング・フォーマット・プロバイダは、各汎用テクノロジ・コネクタに対して作成するのではなく、1つのみ作成してそれを再利用できます。
TS1およびTS2でサポートされているデータ転送メカニズムが同じであり、データ・フォーマットがそれぞれ異なる場合、プロビジョニング・トランスポート・プロバイダを再利用して別のプロビジョニング・フォーマット・プロバイダを作成できます。
プロビジョニング・トランスポート・プロバイダを再利用する場合は、TargetOperation値オブジェクトの実装に、プロビジョニング・フォーマット・プロバイダで実行される関数に固有のコードが含まれないようにしてください。プロビジョニング・フォーマット・プロバイダを再利用する場合は、TargetOperation値オブジェクトの実装に、プロビジョニング・トランスポート・プロバイダで実行される関数に固有のコードが含まれないようにしてください。
事前定義プロビジョニング・プロバイダの再利用
ターゲット・システムがWebサービスである場合は、作成したカスタム・プロビジョニング・フォーマット・プロバイダとWebサービス・プロビジョニング・トランスポート・プロバイダを使用できます。次に、この例を示します。
このマニュアルで前述したように、SPMLプロビジョニング・フォーマット・プロバイダではSPML仕様に従って記述されているプロビジョニング操作のサブセットのみがサポートされます。あらゆるSPMLプロビジョニング操作をサポートする、カスタム・プロビジョニング・フォーマット・プロバイダを開発できます。ターゲット・システムがWebサービスの場合、Webサービス・プロビジョニング・トランスポート・プロバイダを使用して、カスタム・プロビジョニング・フォーマット・プロバイダからターゲット・システムにSPMLリクエストを送信できます。
同様に、SPMLプロビジョニング・フォーマット・プロバイダとカスタム・プロビジョニング・トランスポート・プロバイダを併用して、SPMLリクエストをSPMLベースのターゲット・システムに送信することもできます。
SPMLプロビジョニング・フォーマット・プロバイダで作成され、Webサービス・プロビジョニング・トランスポート・プロバイダの入力として使用されるTargetOperation値オブジェクトの実装について、次に示します。
com.thortech.xl.gc.impl.prov.WSTransportTargetOperation
このクラスの詳細は、Oracle Fusion Middleware Oracle Identity Manager Java APIリファレンスを参照してください。
SPMLプロビジョニング・フォーマット・プロバイダを再利用する場合、このクラスのインスタンスを入力として受け入れ、関連するsetメソッドを呼び出すカスタム・トランスポート・プロバイダを作成する必要があります。同様に、Webサービス・プロビジョニング・トランスポート・プロバイダを再利用する場合、このクラスのインスタンスを作成し、関連するgetメソッドを呼び出すカスタム・プロビジョニング・フォーマット・プロバイダを作成する必要があります。
カスタム・プロバイダをデプロイするには、次の手順を実行します。
プロバイダ定義XMLファイルをMDSの場所/db/GTC/ProviderDefinitionsにアップロードします。Oracle Identity Managerでは、MDSリポジトリとの間でデータをエクスポート/インポートするためのユーティリティが提供されます。
MDSユーティリティの詳細は、第33章「MDSユーティリティとユーザーが修正可能なメタデータ・ファイル」を参照してください。
プロバイダ・リソース・バンドルおよびJARファイルをOracle Identity Managerデータベースにアップロードする必要があります。リソース・バンドルおよびJARファイルをOracle Identity Managerデータベースにアップロードするユーティリティは、OIM_HOME/bin/ディレクトリにあります。
リソース・バンドルおよびJARのアップロード・ユーティリティの詳細は、第35章「JARおよびリソース・バンドルのアップロード・ユーティリティ」を参照してください。
