リリース9.1.0
E05900-03
 目次 |
 索引 |
| Oracle Identity Manager 管理およびユーザー・コンソール・ガイド リリース9.1.0 E05900-03 |
|
事前定義プロバイダで対応できないプロバイダ要件に対して、カスタム・プロバイダを作成する必要があります。この章では、カスタム・プロバイダの作成手順について説明します。
この章の内容は、次のとおりです。
次の各項では、汎用テクノロジ・コネクタの作成中および使用中におけるプロバイダの役割を説明します。
汎用テクノロジ・コネクタは管理およびユーザー・コンソールで作成します。コネクタ作成手順のタスクの1つとして、データセットおよびデータセット間のデータ・フローが定義されます。このタスクは、メタデータの検出プロセスにより容易になります。
汎用テクノロジ・コネクタのコンテキストでは、メタデータという用語はユーザー・アカウント情報を構成する一連のアイデンティティ・フィールドを意味します。メタデータの検出という用語は、プロバイダによるターゲット・システムのメタデータ読込みおよび解析を指します。
メタデータの検出機能は、すべてのタイプのプロバイダでサポートされます。つまり、カスタム・プロバイダの作成時に、メタデータ読込み機能をプロバイダに組み込むことができます。
図21-1に、メタデータの検出プロセスを示します。
次の一連の手順で、メタデータの検出の実施方法について説明します。この一連の手順は、汎用テクノロジ・コネクタの作成時に「リコンシリエーション」オプションと「プロビジョニング」オプションの両方を選択するという想定に基づいています。「リコンシリエーション」オプションまたは「プロビジョニング」オプションのいずれかを選択しない場合、対応する手順は実施されません。
initializeメソッドが呼び出され、このプロバイダのインスタンスが作成されます。
initializeメソッドが呼び出され、このプロバイダのインスタンスが作成されます。
getMetadataメソッドが呼び出され、ターゲット・システムからメタデータがフェッチされます。このメソッドの出力はTargetSchema値オブジェクトであり、ここにターゲット・システムからフェッチしたメタデータが格納されています。
parseMetadataメソッドが呼び出され、ターゲット・システムからフェッチしたメタデータが解析されます。このメソッドの出力はOIMSchema値オブジェクトであり、ここにターゲット・システムからフェッチしたメタデータが格納されています。initializeメソッドが呼び出され、このプロバイダのインスタンスが作成されます。
initializeメソッドが呼び出され、このプロバイダのインスタンスが作成されます。
共有ドライブ・リコンシリエーション・トランスポート・プロバイダとCSVリコンシリエーション・フォーマット・プロバイダでは、ターゲット・システムからメタデータを検出できます。ただし、Webサービス・プロビジョニング・トランスポート・プロバイダおよびSPMLプロビジョニング・フォーマット・プロバイダでは、この機能はサポートされていません。
図21-2は、リコンシリエーション中のプロバイダの役割を示しています。
次の各手順で、リコンシリエーション中のプロバイダの役割について説明します。
initializeメソッドが呼び出され、このプロバイダのインスタンスが作成されます。
initializeメソッドが呼び出され、このプロバイダのインスタンスが作成されます。
Allです。バッチ・サイズを指定しなかった場合、リコンシリエーションのこの段階でリコンシリエーション・トランスポート・プロバイダのgetFirstPageメソッドが呼び出され、リコンシリエーション用に準備されているターゲット・システム・レコードの全体がフェッチされます。
バッチ・サイズを指定した場合、リコンシリエーション・トランスポート・プロバイダのgetFirstPageメソッドが呼び出され、リコンシリエーション用にターゲット・システム・レコードの最初のバッチがフェッチされます。リコンシリエーション用のターゲット・システム・レコードのバッチが複数ある場合は、同一プロバイダのgetNextPageメソッドが（必要に応じて複数回）呼び出されます。
parseRecordsメソッドが呼び出され、TargetRecord値オブジェクト配列の各レコードが処理されます。このメソッドの出力はOIMRecord値オブジェクトの配列です。
汎用テクノロジ・コネクタの作成時に検証プロバイダを選択しなかった場合、手順5は実施されず、OIMRecord値オブジェクトの配列の各要素は手順6に進みます。
汎用テクノロジ・コネクタの作成時に変換プロバイダを選択しなかった場合、手順6は実施されず、前の手順（手順4または手順5）で得られたOIMRecord値オブジェクト配列の各要素は手順7に進みます。
OIMRecord値オブジェクト配列は、「リコンシリエーション・モジュールのプロバイダおよびデータセット」で説明する「リコンシリエーション・ステージング」データセットに対応します。OIMRecord値オブジェクト配列の各要素がリコンシリエーション・エンジンに渡されます。
endメソッドが呼び出されます。このメソッドから、汎用テクノロジ・コネクタ・フレームワークでITリソースのTimestampパラメータに格納される文字列値が戻されます。このフレームワークでは、リコンシリエーションの実行が完了した段階がTimestampパラメータによりトラッキングされます。
図21-3は、プロビジョニング中のプロバイダの役割を示しています。
次の各手順で、プロビジョニング中のプロバイダの役割について説明します。
initializeメソッドが呼び出され、このプロバイダのインスタンスが作成されます。
initializeメソッドが呼び出され、このプロバイダのインスタンスが作成されます。
OIMRecord値オブジェクトの要素に変換されます。この段階では、OIMRecord値オブジェクトは「「OIM」データセット」で説明する「OIM」データセットに対応します。
transformDataメソッドにより、入力したOIMRecord値オブジェクトの指定の属性が処理され、これらのレコードが出力のOIMRecord値オブジェクトに変換されます。この段階では、OIMRecord値オブジェクトは「プロビジョニング・モジュールのプロバイダおよびデータセット」で説明する「プロビジョニング・ステージング」データセットに対応します。
formatDataメソッドが呼び出され、OIMRecord値オブジェクトが処理されます。このプロセスの出力は、TargetOperation値オブジェクトです。
sendDataメソッドが呼び出され、TargetOperation値オブジェクトがターゲット・システムに送信されます。
sendDataメソッドから戻されます。この値はその後、汎用テクノロジ・コネクタ・フレームワークに渡され、このフレームワークによってデータベースにポストされます。
プロビジョニング操作が更新または削除リクエストの場合、「ID」フィールドは名前/値ペアの1つです。このタイプのプロビジョニング・リクエストが送信された場合、結果は次のイベントのいずれかになります。
カスタム・プロバイダの作成は次の各手順に分類できます。
プロバイダ要件を判断するためのガイドラインは、次の各項に分けて説明します。
リコンシリエーション・プロバイダ要件の確認には、次のガイドラインが適用されます。
汎用テクノロジ・コネクタにリコンシリエーション・モジュールを含める場合、リコンシリエーション・トランスポート・プロバイダとリコンシリエーション・フォーマット・プロバイダの両方を（いずれかのプロバイダが不要な場合にも）含める必要があります。このガイドラインについては次の例で説明します。
リコンシリエーション・フォーマット・プロバイダの機能は、ターゲット・システムのデータをOracle Identity Managerでサポートされている形式に変換するものです。ターゲット・システムで、Oracle Identity Managerのサポートする形式でデータが生成される場合にも、汎用テクノロジ・コネクタの作成時にはリコンシリエーション・フォーマット・プロバイダを含める必要があります。
汎用テクノロジ・コネクタに含める必要のあるプロバイダのタイプは、ターゲット・システムでサポートされているデータ・フォーマットおよびデータ転送メカニズムによって異なります。データ・フォーマットとデータ転送メカニズムの組合せが、事前定義プロバイダの組合せで対応できるものであれば、カスタム・プロバイダを作成する必要はありません。
たとえば、ターゲット・システムでカンマ区切り形式のリコンシリエーション・データ・ファイルを生成できる場合は、共有ドライブ・リコンシリエーション・トランスポート・プロバイダとCSVリコンシリエーション・フォーマット・プロバイダを使用できます。カスタム・リコンシリエーション・プロバイダを作成する必要はありません。
プロビジョニング・モジュール用プロビジョニング・プロバイダの要件の確認には、次のガイドラインが適用されます。
汎用テクノロジ・コネクタにプロビジョニング・モジュールを含める場合、プロビジョニング・トランスポート・プロバイダとプロビジョニング・フォーマット・プロバイダの両方を（いずれかのプロバイダが不要な場合にも）含める必要があります。このガイドラインについては次の例で説明します。
プロビジョニング・フォーマット・プロバイダの機能は、Oracle Identity Managerのデータをターゲット・システムでサポートされている形式に変換するものです。ターゲット・システムでOracle Identity Managerの出力データ・フォーマットがサポートされている場合にも、汎用テクノロジ・コネクタの作成時にはプロビジョニング・フォーマット・プロバイダを含める必要があります。
汎用テクノロジ・コネクタに含める必要のあるプロバイダのタイプは、ターゲット・システムでサポートされているデータ・フォーマットおよびデータ転送メカニズムによって異なります。データ・フォーマットとデータ転送メカニズムの組合せが、事前定義プロバイダの組合せで対応できるものであれば、カスタム・プロバイダを作成する必要はありません。
たとえば、ターゲット・システムがWebサービスであり、SOAPメッセージにパッケージ化されたSPMLベースのプロビジョニング・リクエストの受入れや解析が可能な場合は、SPMLプロビジョニング・フォーマット・プロバイダとWebサービス・プロビジョニング・トランスポート・プロバイダを使用できます。カスタム・プロビジョニング・プロバイダを作成する必要はありません。
プロバイダ・パラメータとは、プロバイダが目的の機能を実行する必要のある値です。たとえば、プロビジョニング・リクエスト・ファイルをターゲット・システム・サーバーにコピーするプロビジョニング・トランスポート・プロバイダには、ターゲット・システムへの接続に接続パラメータが必要になります。
汎用テクノロジ・コネクタの作成時に、その汎用テクノロジ・コネクタ用に選択するプロバイダのパラメータ値を指定します。
カスタム・プロバイダを作成する場合、そのプロバイダが機能するために必要なパラメータをすべて識別する必要があります。また、このようなパラメータをランタイム・パラメータと設計パラメータに分類する必要もあります。
ランタイム・パラメータは、プロバイダの設計に制約されない値を示します。たとえば、リコンサイルするデータ・ファイルが格納されているディレクトリの場所がランタイム・パラメータ値となります。設計パラメータは、プロバイダ設計の一部として定義される1つまたは複数の値を表します。たとえば、リコンシリエーション・フォーマット・プロバイダで解析可能なキャラクタ・セット・エンコーディングのフォーマットなどは、そのプロバイダの設計パラメータに分類されます。
表21-1に示す値オブジェクトのJavaコード実装を開発します。この章で前述したように、このような値オブジェクトはプロバイダ操作の様々な段階で使用されます。
各プロバイダ・タイプのサンプル・コード・ファイルには、次の場所のそれぞれのプロバイダ・タイプのディレクトリで参照できます。
OIM_HOME/xellerate/GTC/Samples
たとえば、TargetOperation値オブジェクトの実装を作成する場合は、次のサンプル・コード・ファイルを参照してください。
OIM_HOME/xellerate/GTC/Samples/provisioningTransportProvider/MapProvInput.java
プロバイダ操作中に使用されるSPIメソッドのJavaコード実装を開発します。この章で前述したように、SPIメソッドはプロバイダ操作の様々な段階で呼び出されます。各プロバイダのSPIメソッドの情報へのリンクは、JavadocのPackage com.thortech.xl.gc.spiのページを参照してください。
各プロバイダ・タイプのサンプル・コード・ファイルには、次の場所のそれぞれのプロバイダ・タイプのディレクトリで参照できます。
OIM_HOME/xellerate/GTC/Samples
たとえば、プロビジョニング・フォーマット・プロバイダを作成する場合は、次のサンプル・コード・ファイルを参照してください。
OIM_HOME/xellerate/GTC/Samples/provisioningFormatProvider/PrepareDataHMap.java
値オブジェクトおよびSPIメソッドのJavaコード実装には、ロギング機能を組み込むことをお薦めします。これにより、プロバイダ使用時に発生する可能性のあるエラーのトラブルシューティング・プロセスを簡略化できます。
汎用テクノロジ・コネクタ・フレームワーク用のロギング・モジュールは、Oracle Identity Managerのロギング拡張機能です。表21-2に、サポートされている各プロバイダ・タイプ固有の各モジュールを示します。
これらのモジュールを使用してカスタム・プロバイダにロギング機能を組み込むには、参照としてサンプル・コード・ファイルを使用できます。
カスタム・プロバイダに例外処理を組み込む方法の詳細は、Javadocおよびサンプル・コード・ファイルを参照してください。
プロバイダXMLファイルには、汎用テクノロジ・コネクタ・フレームワークにプロバイダを登録するために必要なデータが含まれます。プロバイダXMLファイルは必ず作成してください。表21-3では、カスタム・プロバイダのプロバイダXMLファイルに含められる要素について説明します。
プロバイダXMLファイルは、次のファイルにあるスキーマ定義に従っている必要があります。
OIM_HOME/xellerate/GTC/Schema/Providers-def.xsd
各プロバイダ・タイプのサンプルXMLファイルの内容は、必要に応じて、次の場所のそれぞれのプロバイダ・タイプのディレクトリで参照できます。
OIM_HOME/xellerate/GTC/Samples
たとえば、プロビジョニング・フォーマット・プロバイダを作成する場合は、次のサンプルXMLファイルを参照してください。
OIM_HOME/xellerate/GTC/Samples/provisioningFormatProvider/PrepareDataHMapProvFormat.xml
リソース・バンドルとは、ロケール固有のテキスト文字列を含むファイルのことです。このようなテキスト文字列は、実行時にOracle Identity Managerで読み込まれ、管理およびユーザー・コンソールにGUI要素のラベルやメッセージとして表示されます。リソース・バンドルのファイル拡張子は.propertiesです。
サポートされる各言語のリソース・バンドルは、Oracle Identity Managerのインストール中にOracle Identity Managerサーバーにコピーされます。これには事前定義済プロバイダのリソース・バンドルも含まれます。
カスタム・プロバイダの場合、使用する各ロケールに応じたリソース・バンドル・エントリを作成する必要があります。リソース・バンドルの作成手順の概要を次に示します。
注意
Provider_Type、Parameter_NameおよびRESPONSE_CODEのそれぞれの値は、「プロバイダXMLファイルの作成」で説明する手順の実行時にプロバイダXMLファイルに指定する値と同じである必要があります。
プロバイダ名は次の形式で記述します。
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_requ ired_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.
プロバイダをデプロイするには、次の手順を実行します。
OIM_HOME/xellerate/GTC/ProviderDefinitions
i. 管理およびユーザー・コンソールにログインします。
ii.「汎用テクノロジ・コネクタ」を開き、「作成」をクリックします。プロバイダXMLファイルでエラーが発生した場合は、エラー・メッセージが表示されます。
エラー・メッセージが表示される場合、XMLファイル内で問題を修正し、Oracle Identity Managerを再起動して手順iと手順iiを繰り返します。
この手順は「作成」をクリックしてもエラー・メッセージが表示されなくなるまで繰り返します。
フォーマット・プロバイダとトランスポート・プロバイダはペアで機能します。リコンシリエーションの実行中、リコンシリエーション・トランスポート・プロバイダの出力がリコンシリエーション・フォーマット・プロバイダに渡されます。プロビジョニングの実行中には、プロビジョニング・フォーマット・プロバイダの出力がプロビジョニング・トランスポート・プロバイダに渡されます。つまり、トランスポート・プロバイダとフォーマット・プロバイダの実装は、この間で渡される値オブジェクトの実装を介してリンクしています。この依存性は、フォーマット・プロバイダおよびトランスポート・プロバイダの再利用に関するガイドラインの基礎となります。
一方、検証プロバイダや変換プロバイダには、他のプロバイダに対してこのような依存性はありません。そのため、検証プロバイダおよび変換プロバイダの再利用に関するガイドラインはありません。検証プロバイダと変換プロバイダは、事前定義されているものでも、カスタム・プロバイダとして作成したものでも再利用できます。これは、これらのプロバイダの動作が、ターゲット・システムのデータ・フォーマットやデータ転送メカニズムに限定されていないためです。
フォーマット・プロバイダおよびトランスポート・プロバイダの再利用に関するガイドラインは、次の各項に分けて説明します。
「リコンシリエーション中のプロバイダの役割」で説明するように、リコンシリエーション・トランスポート・プロバイダとリコンシリエーション・フォーマット・プロバイダの間のデータ交換には、TargetRecord値オブジェクトが使用されます。リコンシリエーション・トランスポート・プロバイダにより、リコンシリエーション実行中にフェッチされたターゲット・システム・レコードに対してTargetRecord値オブジェクトの配列が作成されます。その後、リコンシリエーション・フォーマット・プロバイダにより、値オブジェクト配列のデータが処理され、リコンシリエーション・エンジンに渡されます。
ユーザーの組織の操作環境に、TS1およびTS2という2つのターゲット・システムがあるとします。TS1では、リコンシリエーション中のデータ抽出にWebベースのインタフェースを利用できます。TS2では、そのアイデンティティ・ストアのデータを他のアプリケーションで読み取れるようにするAPIが用意されています。どちらのターゲット・システムでも同じデータ・フォーマットがサポートされています。両方のターゲット・システムのユーザー・データをリコンサイルする場合、各ターゲット・システムに対して汎用テクノロジ・コネクタを1つずつ作成する必要があります。それぞれの汎用テクノロジ・コネクタには、リコンシリエーション・トランスポート・プロバイダを作成する必要があります。ただし、リコンシリエーション・フォーマット・プロバイダは、それぞれの汎用テクノロジ・コネクタに対して作成するのではなく、1つのみ作成してそれを再利用できます。同様に、TS1およびTS2で（同じデータ・フォーマットをサポートしていない場合でも）同じデータ転送メカニズムがサポートされていれば、リコンシリエーション・トランスポート・プロバイダを再利用して別のリコンシリエーション・フォーマット・プロバイダを作成することが可能です。
リコンシリエーション・トランスポート・プロバイダを再利用する場合は、TargetRecord値オブジェクトの実装に、リコンシリエーション・フォーマット・プロバイダで実行される関数に固有のコードが含まれないようにしてください。リコンシリエーション・フォーマット・プロバイダを再利用する場合は、TargetRecord値オブジェクトの実装に、リコンシリエーション・トランスポート・プロバイダで実行される関数に固有のコードが含まれないようにしてください。
共有ドライブ・リコンシリエーション・トランスポート・プロバイダおよびCSVリコンシリエーション・フォーマット・プロバイダの実装は事前定義プロバイダであり、データ・フォーマットと単一のデータ転送メカニズムの固定の組合せ向けに作成されています。共有ドライブ・リコンシリエーション・トランスポート・プロバイダでは、フラット・ファイルからデータを読み取り、CSVリコンシリエーション・フォーマット・プロバイダにTargetRecord値オブジェクトの配列を渡します。共有ドライブ・リコンシリエーション・トランスポート・プロバイダの実装は、ページ・リコンシリエーションと複数値（子）データ・リコンシリエーションという2つの要素に基づいています。この2つの要素では、TargetRecord値オブジェクトの配列を作成する前に、プロバイダでのターゲット・システムのデータ解析を可能にする必要があります。つまり、共有ドライブ・リコンシリエーション・トランスポート・プロバイダではターゲット・システム・データの特定の型を解析でき、CSVリコンシリエーション・フォーマット・プロバイダには共有ドライブ・リコンシリエーション・トランスポート・プロバイダから提供される出力のみを使用できるため、相互依存の関係になっています。そのため、CSVリコンシリエーション・フォーマット・プロバイダのパラメータは、共有ドライブ・リコンシリエーション・トランスポート・プロバイダのパラメータとバンドルされています。
このような理由のため、共有ドライブ・リコンシリエーション・トランスポート・プロバイダとカスタム・リコンシリエーション・フォーマット・プロバイダは併用できず、またCSVフォーマット・プロバイダとカスタム・リコンシリエーション・トランスポート・プロバイダは併用できません。
「プロビジョニング中のプロバイダの役割」で説明するように、プロビジョニング・トランスポート・プロバイダとプロビジョニング・フォーマット・プロバイダの間のデータ交換には、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
このクラスの詳細は、Javadocを参照してください。
SPMLプロビジョニング・フォーマット・プロバイダを再利用する場合、このクラスのインスタンスを入力として受け入れ、関連するsetメソッドを呼び出すカスタム・トランスポート・プロバイダを作成する必要があります。同様に、Webサービス・プロビジョニング・トランスポート・プロバイダを再利用する場合、このクラスのインスタンスを作成し、関連するgetメソッドを呼び出すカスタム・プロビジョニング・フォーマット・プロバイダを作成する必要があります。
|
 Copyright © 2007, 2008 Oracle Corporation. All Rights Reserved. |
|