Oracle® Fusion Middleware Oracle Identity Managerのためのアプリケーションの開発とカスタマイズ 11gリリース2 (11.1.2.3.0) E61958-10 |
|
![]() 前 |
![]() 次 |
この章では、汎用テクノロジ・コネクタを使用および管理する方法について説明します。これらの項目が含まれます。
プロバイダは、汎用テクノロジ・コネクタを作成するための開始点となります。Oracle Identity Managerには、汎用テクノロジ・コネクタのビルディング・ブロックとして使用できるプロバイダの標準セットが用意されています。これらのプロバイダの詳細は、第12章「汎用テクノロジ・コネクタの事前定義済プロバイダ」を参照してください。
適切なプロバイダがない場合は、要件に合せてプロバイダを作成できます。
最後に、汎用テクノロジ・コネクタが統合要件を満たさない場合は、アダプタで利用可能なプログラム的なオプションを使用できます。詳細は、第3章「アダプタ・ファクトリの使用」を参照してください。
関連項目: 汎用テクノロジ・コネクタの作成および管理の詳細は、『Oracle Identity Managerの管理』の汎用コネクタの管理に関する項 |
カスタム・コネクタで、接続プーリングのニーズに対して汎用接続プール・フレームワーク(GCPとも呼ばれる)の使用を選択できます。
内部的に、汎用接続プール・フレームワークではOracleユニバーサル接続プール(UCP)をデフォルトの接続プーリング・メカニズムとして使用します。汎用接続プールをカスタム・コネクタで使用する基本的な手順は次のとおりです。
ResourceConnection
インタフェースの具体的な実装を指定します。
実装には、デフォルト・コンストラクタ(パラメータなし)も必要です。
ITResource定義で追加のフィールドを定義します。
汎用接続プールを呼び出し、プールから接続を取得およびリリースします。
このセクションの内容は次のとおりです。
接続プールでは、ResourceConnection
の具体的な実装を使用して、接続の作成とクローズ、およびターゲットへの接続の検証が行われます。そのため、この具体的な実装クラスがJavaTasks
フォルダの下でjarファイルとして使用できることを確認する必要があります。
表11-1に、ResourceConnection
の主要メソッドの説明を示します。
表11-1 ResourceConnectionのメソッド
メソッド | 説明 |
---|---|
Create Connection |
このメソッドは、(接続の初期数を作成するために)プールの初期化中、および必要に応じてプールのライフサイクル・イベントに対して呼び出されます。 このメソッドは、ターゲットへの実際の物理接続である |
Close Connection |
このメソッドは、プールのライフサイクル・イベントの過程で接続をクローズする必要がある場合にプールによって呼び出されます。 |
Heartbeat |
このメソッドは、ターゲットへの接続のTCPハートビート(またはTCPキープアライブ)を維持するために使用されます。このメソッドにより、接続がターゲット側からタイムアウトしないように、TCP接続が維持されます。 |
Validate |
このメソッドは、接続がまだ有効であるかどうかを示す このメソッドは、「流用時の接続の検証」が このメソッドが |
表11-2に、適切な値を指定する必要があるその他のITResource
パラメータを示します。
表11-2 ITResourceパラメータ
フィールド | 説明 | サンプル値および注意 |
---|---|---|
中止した接続のタイムアウト |
中止した接続の接続タイムアウト(秒)。タイムアウトの経過後、接続は再要求されます。 |
900 |
接続待機タイムアウト |
接続の確立を待機する時間(秒)。 |
60 |
非アクティブ接続タイムアウト |
プール内のアイドル状態の非アクティブ接続の接続タイムアウト(秒)。注意: これらは流用された接続ではありません。 |
300 |
初期プール・サイズ |
プール内の接続の初期数。 |
3 |
最大プール・サイズ |
プールで作成できる接続の最大数。 |
30 |
最小プール・サイズ |
プールで保持する必要がある接続の最小数。 |
2 |
貸出し時の接続の検証 |
接続を検証する必要があるかどうかを示します。詳細は、表11-1を参照してください。 |
trueまたはfalse |
タイムアウト・チェック間隔 |
タイムアウト・プロパティをチェックする頻度(秒)。 |
30 |
プール・プリファレンス |
優先されるプーリング・メカニズムを示します。デフォルトのプール実装はUCPです。 |
デフォルト(UCPの場合)。ネイティブ(ネイティブ実装の場合) |
接続プーリングをサポート |
プーリングがサポートされるかどうかを示します。プーリングがサポートされない場合、返される接続はプールされた接続ではありません。デフォルト(推奨)は |
trueまたはfalse |
ターゲットで1つの接続のみをサポート |
ターゲット・システムで一度に1つの接続のみがサポートされるかどうかを示します。trueに設定すると、他のプロパティに関係なく、次のプール・パラメータが使用されます。
デフォルト(推奨)は |
ターゲットで1つの接続のみが処理される場合は |
ResourceConnectionクラス定義 |
|
|
ネイティブ接続プール・クラス定義 |
GenericPoolを実装するネイティブ・プール・メカニズムのラッパー。「プール・プリファレンス」が |
|
プール除外フィールド |
接続の作成に不要なフィールドのカンマ区切りのリスト。指定したいずれかのフィールドが更新された場合には、GCPプールはリフレッシュされません。 注意: このリストのフィールドは、 |
|
次の点に注意してください。
Design ConsoleからITResource
パラメータを更新しても、プールはリフレッシュされません。Identity System AdministrationまたはAPIを介して値を更新します。
プールが使用されているときは値を更新しないでください。
汎用接続プールのコンシューマは、ConnectionServiceを呼び出して、ターゲットへのプールされた接続を取得し、プールに接続を戻すことができます。
このコード例は、ITResource名に基づいてプールから接続を取得し、戻します。
import com.oracle.oim.gcp.exceptions.ConnectionServiceException; import com.oracle.oim.gcp.pool.ConnectionService; import com.oracle.oim.gcp.resourceconnection.ResourceConnection; public class ConnectionPoolClient { public void testConnection(String itResName) { try{ //Request for connection from the connection pool ConnectionService service = new ConnectionService(); ResourceConnection myConnection = service.getConnection(itResName); //"myConnection" is the connection //use the connection... //Release connection back to the connection pool //Connections should always be returned this way. service.releaseConnection(myConnection); } catch(ConnectionServiceException e) { //handle } }
ITResourceキーを使用して、ターゲットへの接続をリクエストすることもできます。次に例を示します。
ConnectionService service = new ConnectionService(); ResourceConnection myConnection = service.getConnection(itResourceKey);
この項で前述したように、カスタム・コネクタにいずれかのサード・パーティ・プールを使用できます。ただし、前述の手順に加えて、サード・パーティ・プールのラッパーとしてGenericPoolインタフェースの具体的な実装を指定する必要があります。
注意: カスタム・コネクタでUCPプールを使用しない場合、カスタム・コネクタではネイティブ・オプションでGCPの使用を選択できますが、この選択に大きな利点はありません。ネイティブ・プール・プリファレンスでは、プールの維持と実装はカスタム・コネクタによって行われます。 |
表11-3に、GenericPoolインタフェースの呼び出されるメソッドを示します。
表11-3 GenericPoolインタフェースのメソッド
メソッド | 目的 |
---|---|
initializePool(PoolConfiguration poolConfig) |
プールを初期化します。PoolConfigurationデータ・オブジェクトには、すべてのプール関連のパラメータが含まれます。 |
borrowConnectionFromPool() |
接続をリクエストします。 |
returnConnectionToPool(ResourceConnection resConn) |
接続をプールへ返します。 |
refreshPool(PoolConfiguration newPoolConfig) |
更新された値でプールをリフレッシュします。 |
destroyPool() |
プールを削除します(ITResourceが削除された場合など)。 |
次の例は、ResourceConnection
インタフェースの実装を示しています。主要メソッドは強調表示されています。
例11-1 ResourceConnection実装の例
/** * Sample implementation for Socket Connections: */ import java.io.IOException; import java.net.InetSocketAddress; import java.net.Socket; import java.net.SocketException; import java.net.UnknownHostException; import com.oracle.oim.gcp.exceptions.ResourceConnectionCloseException; import com.oracle.oim.gcp.exceptions.ResourceConnectionCreateException; import com.oracle.oim.gcp.exceptions.ResourceConnectionValidationxception; import com.oracle.oim.gcp.resourceconnection.ResourceConnection; public class SocketResourceConnectionImpl extends Socket implements ResourceConnection { public SocketResourceConnectionImpl() { super(); } /** * Sample: Concrete implementation for closing a socket connection */ public void closeConnection() throws ResourceConnectionCloseException{ if(!this.isClosed()){ try { this.close(); } catch (IOException e) { throw new ResourceConnectionCloseException("[Client ResourceConnection implementation] Failed to close socket connection! "); } } } /** * Sample : Concrete implementation for creating a socket connection. * The return value is the actual physical socket connection * */ public ResourceConnection createConnection(HashMap itResInfoMap) throws ResourceConnectionCreateException { ResourceConnection r = null; SocketResourceConnectionImpl i = new SocketResourceConnectionImpl(); try { //HashMap has all ITResource related information that is needed //for connecting to target. String serverAddress= ((String) itResInfoMap.get ("Server Address")).trim(); //utility method getIntValue returns an int for a String int port = getIntValue(((String)itResInfoMap.get("Port")).trim()); System.out.println("Connecting to Socket with IP Address " + serverAddress+" at port "+ port); InetSocketAddress inet = new InetSocketAddress(serverAddress,port); i.connect(inet); if(!i.isConnected()){ throw new ResourceConnectionCreateException (" Failed to create socket: connection failure"); } r = (ResourceConnection)i; } catch (UnknownHostException e) { throw new ResourceConnectionCreateException(" [Client ResourceConnection implementation] Failed to create socket connection!", e); } catch (IOException e) { throw new ResourceConnectionCreateException(" [Client ResourceConnection implementation] Failed to create socket connection! ",e); } return r; } /** * Sample : Concrete implementation for heartbeat of a socket connection */ public void heartbeat() throws ResourceConnectionValidationxception { try { this.setKeepAlive(true); } catch (SocketException e) { throw new ResourceConnectionValidationxception ("[Client ResourceConnection implementation] Failed to set heartbeat "); } } /** * Sample: Concrete implementation for validating connection */ public boolean isValid() { if(this.isBound()){ return true; }else{ return false; } } }
この項は次のトピックで構成されています。
汎用テクノロジ・コネクタの名前を指定する場合は次のガイドラインを適用します。
サマリー:
名前にはASCII文字のみを使用するようにします。アンダースコア(_)文字は使用できますが、それ以外の非ASCII文字は名前に使用しないでください。
説明:
コネクタ作成プロセスの終了時に自動的に作成されるコネクタ・オブジェクトの大部分では、オブジェクト自体の名前の一部に汎用テクノロジ・コネクタの名前が使用されます。たとえば、汎用テクノロジ・コネクタの名前がWebConn
である場合、スケジュール済タスクの名前はWebConn_GTC
となります。
Oracle Identity Managerデータベースでは、非ASCII文字の名前が指定されたオブジェクトを格納するプロビジョニングは実行されません。そのため、汎用テクノロジ・コネクタの名前を指定するときに非ASCII文字を入力すると、エラー・メッセージが表示されます。
Oracle Identity Managerインストールで使用されているコネクタまたはコネクタ・オブジェクトの名前と同じ名前を指定しないでください。
ステージング・サーバー上で汎用テクノロジ・コネクタを作成して本番サーバーに移動する場合は、汎用テクノロジ・コネクタの名前が本番サーバー上の既存のコネクタまたはコネクタ・オブジェクトの名前と競合しないようにしてください。
ステージング・サーバー上に作成した汎用テクノロジ・コネクタを本番サーバーにインポートする前には、宛先のOracle Identity Managerデータベースのバックアップを作成して、コネクタ・オブジェクトが上書きされた場合に作業状態に戻れるようにしてください。
共有ドライブ・トランスポート・プロバイダを選択する場合は、CSVフォーマット・プロバイダを選択する必要があります。
SPMLプロビジョニング・フォーマット・プロバイダを選択する場合は、Webサービス・プロビジョニング・トランスポート・プロバイダを選択する必要があります。
共有ドライブ・リコンシリエーション・トランスポート・プロバイダを選択する場合は、リコンシリエーション用にターゲット・システムから提供される親データおよび子データのファイルにおいて、少なくとも最初の2行に所定のフォーマットのデータがあることを確認してください。データの所定のフォーマットの詳細は、第12.1項「共有ドライブ・リコンシリエーション・トランスポート・プロバイダ」で説明しています。
共有ドライブ・リコンシリエーション・トランスポート・プロバイダを選択する場合は、リコンシリエーションの開始前に、ステージング・ディレクトリおよびアーカイブ・ディレクトリに必要な権限が設定されていることを確認してください。必要な権限の詳細は、「ステージング・ディレクトリとアーカイブ・ディレクトリに設定する権限」で説明しています。
一度に複数の汎用テクノロジ・コネクタを作成しようとしないでください。同じOracle Identity ManagerインストールのIdentity System Administrationで、別のセッションから作成する場合も同様です。
ここでは、「ステップ2: パラメータ値の指定」ページで指定する入力に関する既知の問題について説明します。
サマリー:
共有ドライブ・リコンシリエーション・トランスポート・プロバイダを使用する場合、次の点に注意します。
ステージング・ディレクトリとアーカイブ・ディレクトリに同じパスを指定しないでください。両方のディレクトリに同じパスを指定すると、アーカイブ・ディレクトリの既存のファイルが削除されます。
ステージング・ディレクトリ内のファイルの名前が、アーカイブ・ディレクトリ内のファイルの名前と異なるようにしてください。ファイル名が同一になると、アーカイブ・ディレクトリ内の既存のファイルがリコンシリエーション実行の終了時に上書きされます。
説明:
共有ドライブ・リコンシリエーション・トランスポート・プロバイダを使用する場合、各リコンシリエーション実行の後にデータファイルがステージング・ディレクトリからアーカイブ・ディレクトリに移動します。アーカイブ・ディレクトリに移動したファイルにタイムスタンプまたはマークは付きません。そのため、共有ドライブ・トランスポート・プロバイダの使用時には、次のガイドラインに注意してください。
指定するアーカイブ・ディレクトリのパスおよび名前は、ステージング・ディレクトリのパスおよび名前と同じものにしないでください。同じパスおよび名前を指定すると、アーカイブ・ディレクトリ内の既存のファイルがリコンシリエーション実行の終了時に削除されます。
現行のリコンシリエーション実行時に、最後のリコンシリエーション実行で使用されたファイルと同じ名前のデータファイルがステージング・ディレクトリに配置されていると、アーカイブ・ディレクトリ内の既存のファイルが、ステージング・ディレクトリからの新しいファイルで上書きされます。次に、この例を示します。
最後のリコンシリエーションの実行終了時に、ステージング・ディレクトリからアーカイブ・ディレクトリに次の各ファイルが自動的に移動したとします。
usrdataParentData.csv usrdataRoleData.csv usrdataGroupMembershipData.txt
現行のリコンシリエーションの実行用に、ステージング・ディレクトリに次の各ファイルを配置します。
usrdataParentData.csv usrdataRoleData_04Feb07.csv usrdataGroupMembershipData_04Feb07.txt
これらのファイルは、現行のリコンシリエーションの実行終了時にアーカイブ・ディレクトリに移動します。その際、古いusrdataParentData.csv
ファイルが新しいファイルで上書きされます。
そのため、アーカイブ・ディレクトリ内のファイルがリコンシリエーション実行の終了時に上書きされないようにするには、ステージング・ディレクトリ内のファイルの名前がアーカイブ・ディレクトリ内のファイルの名前と同一にならないようにする必要があります。
サマリー:
「ステップ2: パラメータ値の指定」ページに戻っても、2回目にはメタデータの検出は行われません。そのため、必要に応じて「ステップ3: コネクタ構成の変更」ページに表示されるフィールドおよびフィールド・マッピングを手動で変更する必要があります。
説明:
「ステップ2: パラメータ値の指定」ページで指定した値を変更するとします。このページには、「ステップ4: コネクタ・フォーム名の検証」ページまたは「ステップ5: コネクタ情報の検証」ページから戻れます。ただし、プロバイダ・パラメータ値を変更した後に「続行」ボタンをクリックしても、2回目にはメタデータの検出は行われません。これは、「ステップ3: コネクタ構成の変更」ページで手動で行われた可能性のある変更の保護を目的とした機能です。
この機能が適用されるため、既存の汎用テクノロジ・コネクタを変更しても、メタデータの検出は行われません。
ここでは、次の領域に関するベスト・プラクティスについて説明します。
フィールドの追加時または編集時にフィールド名を指定する場合、次の検証が適用されることに注意してください。
同じデータセット(親または子)に属する2つのフィールドには同じ名前を指定できません。
同じ親データセットの2つの子データセットには同じ名前を指定できません。
親データセットのフィールドの名前には、その子データセットのいずれかと同じ名前は指定できません。
その2つの子データセットが同じ親データセットに属しているかどうかに関係なく、2つの異なる子データセットに同じ名前のフィールドをそれぞれ指定することは可能です。たとえば、UsrID
という名前のフィールドをGroupMembership
データセットとRole
データセットのそれぞれに指定できます。
2つの異なる親データセットに同じ名前のフィールドをそれぞれ指定することは可能です。同様に、これらのデータセットに同じ名前の子データセットをそれぞれ指定することも可能です。
子データセットの名前には、そのフィールドのいずれかと同じ名前を指定できます。
パスワードの安全性を確保するため、パスワード情報は汎用テクノロジ・コネクタでリコンサイルしないでください。つまり、「ソース」データセットおよび「リコンシリエーション・ステージング」データセットには「パスワード」フィールドが含まれないようにします。また、「リコンシリエーション・ステージング」データセットのフィールドを「OIM - ユーザー」データセットの「パスワード」フィールドにマップしないでください。
パスワード型フィールドは、「暗号化」属性および「パスワード・フィールド」属性を(「暗号化」チェック・ボックスおよび「パスワード・フィールド」チェック・ボックスを選択して)設定するフィールドです。「OIM - アカウント」データセットに追加するフィールドにこれらの2つの属性を設定すると、パスワード型フィールドを作成できます。
パスワード型フィールドの内容を保護するため、これらのフィールドの追加時または編集時には次のガイドラインに注意してください。
「パスワード・フィールド」チェック・ボックスおよび「暗号化」チェック・ボックスを使用すると、Oracle Identity Managerでのパスワード情報の表示および格納を保護できます。ただし、パスワード型フィールドを「プロビジョニング・ステージング」データセットのフィールドにマップする場合は、これらのフィールドに伝播されるデータを保護するため、必要なすべての予防措置をとってください。たとえば、このデータがプロビジョニング操作の終了時にターゲット・システムのプレーン・テキスト・ファイルに格納されないようにする必要があります。
「OIM - アカウント」データセットと「プロビジョニング・ステージング」データセットのパスワード・フィールド間には、1対1のマッピングのみ作成することをお薦めします。つまり、このパスワード・フィールドを、「プロビジョニング・ステージング」フィールドとの変換マッピングの入力フィールドとして使用しないようにしてください。「OIM - ユーザー」データセットの「パスワード」フィールドについても同様の予防措置をとる必要があります。
前述したとおり、「パスワード」フィールドは「OIM - ユーザー」データセットの事前定義済フィールドの1つです。このフィールドには「パスワード・フィールド」属性および「暗号化」属性が設定されます。Design Consoleを使用すると、作成するUDFに「パスワード・フィールド」属性および「暗号化」属性を設定できます。このように設定すると、新規作成されるUDFに既存の「パスワード」フィールドと同じプロパティが指定されます。ただし、汎用テクノロジ・コネクタ・フレームワークは、このフィールドを他のテキスト・フィールド(Stringデータ型を持つ)と同じように扱い、Identity Self Service、Identity System Administrationまたはデータベースでコンテンツはカプセル化されません。
「Oracle Identity Manager」データセットのフィールドを使用する場合は次のベスト・プラクティスに従います。
サマリー:
翻訳変換プロバイダを選択してマッピングを作成する場合、「参照コード名」リージョンに参照定義の名前を指定してください。データセット名およびフィールドを「参照コード名」リージョンに指定すると、実際のリコンシリエーションまたはプロビジョニングの操作時に変換に失敗します。
説明:
マッピングの作成時に翻訳変換プロバイダを選択すると、「ステップ2: マッピング」ページに、データセットからフィールドを選択してリテラルを指定するオプションが表示されます。翻訳変換プロバイダを使用しているため、「リテラル」オプションを選択して、変換用のコード・キーおよびデコードの値を含む参照定義の名前を入力する必要があります。「参照コード名」リージョンにデータセット名およびフィールドを選択しないでください。データセット名およびフィールドの選択を無効にする検証は行われませんが、実際のリコンシリエーションまたはプロビジョニングの操作時に変換操作に失敗します。
「OIM - アカウント」データセットのIDフィールドと、「リコンシリエーション・ステージング」データセットのレコードを一意に識別するフィールドとのマッピングを作成します。
IDフィールドに加えて、「OIM - アカウント」データセットの他のフィールドを「リコンシリエーション・ステージング」データセットの対応するフィールドに(一致のみで)マップして、リコンシリエーション一致のコンポジット・キー・フィールドを作成できます。
「プロビジョニング・ステージング」データセットのすべてのフィールドと、「Oracle Identity Manager」データセットの対応するフィールドとのマッピングを作成します。
リコンシリエーション・ルールを作成するには、リコンシリエーション・ステージング・データセットのフィールドと「OIM - ユーザー」データセットのフィールド間で一致のみのマッピングを作成します。子データセットがある場合は、一致のみのマッピングの入力フィールドとなる「リコンシリエーション・ステージング」データセットのフィールドの名前が「リコンシリエーション・ステージング」の子データセットで使用されていないことを確認してください。このガイドラインに従っていないと、リコンシリエーションは失敗します。
これについては、「「ステップ3: コネクタ構成の変更」ページ」にも記載されています。
変換マッピングの入力フィールドの1つとしてリテラル・フィールドを使用できます。「リテラル」オプションを選択した場合は、そのフィールドに値を入力する必要があります。このオプションの選択後は、リテラル・フィールドを空白にしないでください。
「Oracle Identity Manager」データセットのフィールドを使用する場合は次のベスト・プラクティスに従います。
信頼できるソースのリコンシリエーションでは、「OIM - ユーザー」データセットの次の各フィールドに常に値が保持されている必要があります。
ユーザーID
名
姓
組織名
Xellerateのタイプ
ロール
また、この他に選択できる「OIM - ユーザー」のフィールドにも、ユーザー・アカウントがリコンシリエーションを通じて作成された場合に入力が必要なものがあります。これらの各フィールドに対し、「リコンシリエーション・ステージング」データセットの対応するフィールドとのマッピングを作成する必要があります。リコンシリエーションの実行中は、これらのフィールドのソースとなるターゲット・システムのフィールドに、常に値が保持されているようにしてください。
プロビジョニングに選択できる「OIM - ユーザー」データセットまたは「OIM - アカウント」データセットのフィールドには、ターゲット・システムへの値の伝播が必要なものがあります。これらのフィールドは、特定した後に、「プロビジョニング・ステージング」データセットの対応するフィールドとのマッピングを作成してください。プロビジョニング操作中に、これらの各フィールドに値を入力する必要があります。
必要に応じて、事前定義済の「OIM - ユーザー」データセット・フィールドのリストにユーザー定義フィールド(UDF)を追加します。
既存の汎用テクノロジ・コネクタで、「OIM - アカウント」データセットのフィールドの属性を変更または削除しないでください。
サマリー
親レコードと子データ・レコードが作成され、ターゲット・システムおよびOracle Identity Managerの両方でリンクされる場合は、各リコンシリエーション実行の開始時に、親データと子データ両方のファイルがステージング・ディレクトリに格納されていることを確認してください。
説明
ターゲット・システムに、子データ・レコードに関連付けられた親データ・レコードがあるとします。これらのレコードをOracle Identity Managerにリコンサイルするには、これらのレコードを含む親データファイルおよび子データファイルをステージング・ディレクトリに配置します。リコンシリエーション実行中に、子データ・レコードがその対応する親データ・レコードにリンクされます。後続のリコンシリエーション実行を開始する前に、ステージング・ディレクトリから子データファイルを削除すると、このような形の子データ・レコードの削除に対してリコンシリエーション・イベントは作成されません。特定の親データ・レコードの子データ・レコードを削除する場合は、子データファイルから子データ・レコードを削除する必要があります。子データファイルに子データ・レコード(3行目以降)がない場合にも、各リコンシリエーション実行時には、子データファイルがステージング・ディレクトリに配置されていることを確認してください。
カスタム・プロバイダを使用する場合は次のガイドラインを適用します。
カスタム・プロビジョニング・トランスポート・プロバイダのコードを開発する場合、「ユーザーの作成」操作の終了時にプロバイダが一意のフィールドの値を戻すことを確認してください。この機能は、プロビジョニング・トランスポート・プロバイダのsendData
メソッドによって実装されます。詳細は、「プロビジョニング中のプロバイダの役割」を参照してください。
汎用テクノロジ・コネクタの作成時に自動的に作成されたコネクタ・オブジェクトを使用する場合は、次のガイドラインを適用します。
サマリー:
リコンシリエーションのみの汎用テクノロジ・コネクタ用に自動的に作成されたリソース・オブジェクトは、プロビジョニングに使用しようとしないでください。
説明:
汎用テクノロジ・コネクタの作成時に「リコンシリエーション」オプションのみを選択したとします。作成プロセスの終了時に、この汎用テクノロジ・コネクタ用に自動的に作成されるオブジェクトの1つとして、リソース・オブジェクトが作成されます。ただし、リコンシリエーションのみの汎用テクノロジ・コネクタには汎用アダプタが作成されないため、このリソース・オブジェクトはいずれのユーザーにもプロビジョニングできません。
サマリー:
汎用テクノロジ・コネクタのリソース・オブジェクトを、Oracle Identity Managerで定義されている組織にプロビジョニングしようとしないでください。
説明:
リソース・オブジェクトは、汎用テクノロジ・コネクタの作成中に自動的に作成されるコネクタ・オブジェクトの1つです。このリソース・オブジェクトは、Oracle Identity Managerユーザーにのみプロビジョニングできます。Oracle Identity Managerで定義されている組織にはプロビジョニングしようとしないでください。
これについては、「コネクタ・オブジェクト」にも記載されています。
Design Consoleを使用すると、汎用テクノロジ・コネクタの作成中に自動的に作成されるコネクタ・オブジェクトをカスタマイズできます。コネクタ・オブジェクトをカスタマイズした後に「汎用テクノロジ・コネクタの管理」操作を実行すると、そのコネクタ・オブジェクトに対して行ったすべてのカスタマイズが上書きされます。そのため、次のガイドラインのいずれかを適用することをお薦めします。
Design Consoleを使用して、汎用テクノロジ・コネクタ・オブジェクトを変更しないでください。
ITリソースについてはこのガイドラインは適用されません。ITリソースのパラメータは、Design Consoleを使用して変更できます。ただし、GenericConnector
カテゴリおよびGenericConnectorProviders
カテゴリのキャッシュを有効にしている場合は、ITリソースのパラメータを変更する前後のいずれかにキャッシュをパージする必要があります。
Design Consoleを使用して汎用テクノロジ・コネクタ・オブジェクトを変更する場合、汎用テクノロジ・コネクタの変更に「汎用テクノロジ・コネクタの管理」機能を使用しないでください。
これについては、第11.3.6項「コネクタ・オブジェクトの使用」にも記載されています。
事前移入アダプタは、汎用テクノロジ・コネクタの作成時に自動的に作成されるコネクタ・オブジェクトのセットの一部ではありません。ただし、汎用テクノロジ・コネクタの作成中に、プロビジョニングの入力をリテラル・フィールドおよびユーザー・データ・フィールドにマップすることはできます。この機能を使用してもユーザー定義フォームへの事前移入はできませんが、プロビジョニング・データ・パケットに事前移入することは可能です。
汎用テクノロジ・コネクタを変更する場合は次のベスト・プラクティスに従います。
一度に複数の汎用テクノロジ・コネクタを変更しようとしないでください。同じOracle Identity ManagerインストールのIdentity System Administrationで、別のセッションから作成する場合も同様です。