ヘッダーをスキップ
Oracle Identity Manager Oracle E-Business Employee Reconciliation Connectorガイド
リリース9.1.0
B56037-01
  目次
目次
索引
索引

戻る
戻る
 
次へ
次へ
 

1 コネクタについて

Oracle Identity Managerでは、アクセス権の管理、セキュリティおよびITリソースのプロビジョニングが自動化されています。Oracle Identity Managerコネクタは、Oracle Identity Managerと外部のアイデンティティ対応アプリケーションの統合に使用されます。このマニュアルでは、Oracle Identity Managerのアイデンティティ・データの認可(信頼できる)ソースとしてOracle E-Business HRMSを使用するためのコネクタについて説明します。

コネクタのアイデンティティ・リコンシリエーション(信頼できるソース)構成において、個人レコードはOracle E-Business HRMSでのみ作成および変更され、それらのユーザーに関する情報がOracle Identity Managerにリコンサイルされます。


注意:

このマニュアルの一部では、Oracle E-Business HRMSをターゲット・システムと呼んでいます。

この章では、次の項目について説明します。

1.1 動作保証されているコンポーネント

表1-1に、このコネクタで動作保証されているコンポーネントを示します。

表1-1 動作保証されているコンポーネント

コンポーネント 要件

Oracle Identity Manager

Oracle Identity Managerリリース9.1.0.2以上

注意: このリリースのコネクタは、Oracle Identity Manager release 9.1.0.2で導入された機能(将来の日付のユーザー・ライフサイクル・イベントのリコンシリエーションなど)を利用しています。

ターゲット・システム

Oracle E-Business Suite 11.5.10、12.0.x、12.1.1

これらのアプリケーションは、単一データベースまたはRAC実装のいずれかとしてOracle Database 10gまたはOracle Database 11gで実行できます。

注意: Oracle Identity Managerとターゲット・システムの間の通信では、SSLモードまたは非SSLモードを使用できます。


1.2 動作保証されている言語

コネクタでは、次の言語がサポートされています。


関連項目:

サポートされる特殊文字の詳細は、『Oracle Identity Managerグローバリゼーション・ガイド』を参照してください。

1.3 コネクタのアーキテクチャ

図1-1に、コネクタのアーキテクチャを示します。

図1-1 コネクタのアーキテクチャ

図1-1の説明が続きます
「図1-1 コネクタのアーキテクチャ」の説明

コネクタを構成して、ターゲット・システムでのアイデンティティ(信頼できるソース)リコンシリエーションを実行するようにします。この種類のリコンシリエーションでは、アイデンティティ・データがOracle Identity Managerにフェッチされ、そのデータがOIMユーザーの作成や更新に使用されます。

信頼できるソース・リコンシリエーションで行われる手順の概要を次に示します。

  1. SQL問合せが使用され、リコンシリエーション時にターゲット・システムのレコードがフェッチされます。すべての事前定義済SQL問合せはプロパティ・ファイルに格納されています。ファイル内の各問合せは名前で識別されます。eBusiness HRMSの信頼できるリコンシリエーション・スケジュール済タスクを構成するときは、プロパティ・ファイルの名前と実行する問合せを指定します。

  2. 指定した時刻(間隔)にスケジュール済タスクが実行されます。このスケジュール済タスクには、実行するリコンシリエーションのモードの詳細が含まれます。

    3.2.6項「リコンシリエーションのスケジュール済タスクの構成」で、スケジュール済タスクについて説明しています。

  3. スケジュール済タスクによってターゲット・システムとの接続が確立されます。

  4. スケジュール済タスクは、タスク属性に設定された値を読み取り、タスク属性をリコンシリエーション問合せのパラメータにマップし、問合せのフォーマットを整え、ターゲット・システム・データベースで問合せを実行します。

  5. ターゲット・システム上で問合せの基準を満たすの個人レコードがOracle Identity Managerにフェッチされます。

  6. ターゲット・システムからフェッチされた各個人レコードが、既存のOIMユーザー・レコードと比較されます。この比較プロセスでリコンシリエーション・ルールが適用されます。リコンシリエーション・ルールの詳細は、1.5.3項「信頼できるソースのリコンシリエーションのリコンシリエーション・ルール」を参照してください。

  7. プロセスの次の手順は、比較の結果によって異なります。

    • ターゲット・システムの個人レコードとOIMユーザーが一致する場合、個人レコードに対して行われた変更内容でOIMユーザーが更新されます。

    • 一致しない場合、ターゲット・システムの個人レコードを使用してOIMユーザーが作成されます。

Oracle E-Business HRMSでは、一部の従業員ライフサイクル・イベントの有効日指定が可能です。たとえば、個人の入社日として将来の日付を設定することができます。この有効日付は、ターゲット・システムのデータベース表のEFFECTIVE_START_DATE列に格納されます。同様に、個人の退職日や組織での最終日などのイベントをあらかじめ設定することもできます。このような種類のイベントの日付はEFFECTIVE_END_DATE列に格納されます。将来の日付が設定された特定の変更について、現在の日付がEFFECTIVE_START_DATEまたはEFFECTIVE_END_DATE列に格納されている日付と一致したときに、ターゲット・システムの個人レコードで適切な変更が行われます。

コネクタは、このような有効日指定のライフサイクル・イベントを検出し、対応することができます。

事前定義済問合せを実行してすべての個人レコードをリコンサイルすると、現在の日付が設定された変更を含むレコードのみがOracle Identity Managerにフェッチされます。事前定義済問合せを実行して入社予定をリコンサイルすると、現在の日付の「開始日」値を含むレコードのみがOracle Identity Managerにフェッチされます。


注意:

Oracle Identity Managerリリース9.1.0.2では、将来の日付の入社イベントから作成されたリコンシリエーション・イベントはイベント遅延状態に設定されます。この状態のイベントを処理するためには、プロセス遅延リコンシリエーション・イベント・スケジュール済タスクが使用されます。イベント遅延状態の各イベントについて、このスケジュール済タスクがイベントのプロビジョニング開始日付とシステム日付を比較します。プロビジョニング開始日付がシステム日付と同じかそれよりも前である場合、そのイベントはOracle Identity Managerのリコンシリエーション・マネージャに転送されます。

図1-2に、Oracle Identity ManagerをOracle RACインストールに統合するコネクタのアーキテクチャを示します。

図1-2 Oracle RACインストールとの統合のアーキテクチャ

図1-2の説明が続きます
「図1-2 Oracle RACインストールとの統合のアーキテクチャ」の説明

この図に示すように、ロード・バランサが、スケジュール済タスクから送信されるリコンシリエーション問合せのインタフェースとして機能します。リコンシリエーションが実行されるたびに、問合せがいずれかのOracle RACノードに送信され、問合せ結果がロード・バランサを介してOracle Identity Managerに送信されます。

1.4 コネクタの機能

コネクタの機能は次のとおりです。

1.4.1 信頼できるソースのリコンシリエーションの専用サポート

コネクタを使用して、Oracle Identity Managerの信頼できるソースとしてOracle E-Business HRMSを統合することができます。つまり、ターゲット・システムがOracle Identity Managerのアイデンティティ・データの認可ソースになります。このアイデンティティ・データは、OIMユーザーの作成または更新に使用されます。また、組織のオペレーティング環境においてOracle E-Business HRMSが信頼できるソースの1つであるというシナリオで使用するように、コネクタを構成することもできます。

コネクタを使用してOracle E-Business HRMSをターゲット・リソースとして設定することはできません。つまり、コネクタでは、Oracle E-Business HRMSでのプロビジョニング操作とターゲット・リソースのリコンシリエーションはサポートされません。Oracle E-Business HRMSで管理される個人レコードは、ユーザーがシステムにログインして業務関連の作業を実行するときに使用するアカウントではないためです。

1.4.2 事前定義済リコンシリエーション問合せ

コネクタには事前定義済の問合せが含まれており、これらを使用して、ターゲット・システムにある次の種類のライフサイクル・イベントのデータをリコンサイルすることができます。

  • 個人のレコードの追加または変更。

  • 個人の部門の変更。

  • 個人のレコードの作成(入社日を将来の日付に設定)。これは有効日指定の入社予定です。

  • 個人の退職。

  • 個人のレコードの削除。

リコンシリエーションのスケジュール済タスクを構成するときに、ターゲット・システムで実行する問合せを指定できます。


注意:

Oracle E-Business HRMSを使用すると、昇進イベントに際して個人レコードに適用する必要がある変更内容を構成(カスタマイズ)できます。このため、コネクタではこのライフサイクル・イベントの事前定義済問合せは提供されません。必要であれば、リコンシリエーション問合せを作成して、昇進イベントをOracle Identity Managerにフェッチすることができます。カスタム・リコンシリエーション問合せの作成手順は後で説明します。

詳細は、1.5.1項「リコンシリエーション問合せ」を参照してください。

1.4.3 カスタム・リコンシリエーション問合せ

任意の事前定義済問合せを変更して使用できます。また、独自のリコンシリエーション問合せを作成することもできます。

詳細は、次の各項を参照してください。

1.4.4 有効日指定イベントのリコンシリエーション

ターゲット・システムでは、特定のライフサイクル・イベントについて将来の日付すなわち有効日付を設定できます。コネクタは、このようなイベントを検出して対応することができます。たとえば、組織でのJohnの雇用が現在の日付から2か月後に開始するようにスケジュールします。入社予定をリコンサイルするようにスケジュール済タスクを構成すると、Johnの入社日は将来の日付に設定されているため、問合せによってJohnのレコードがフェッチされます。ただし、新たに追加または変更されたレコードをリコンサイルするようにスケジュール済タスクを構成した場合、新たに作成されたJohnのレコードは有効日指定のため無視されます。

詳細は、1.3項「コネクタのアーキテクチャ」を参照してください。

1.4.5 複数の個人タイプのサポート

組織はOracle E-Business HRMSを使用して様々な種類の個人レコードを格納できます。個人タイプの例には、従業員、パートタイム、非従業員および契約社員があります。コネクタは、個人タイプが異なるレコードを区別できます。また、サポートされる個人タイプの事前定義済セットの追加や変更が可能です。

詳細は、次の各項を参照してください。

1.4.6 完全リコンシリエーションおよび増分リコンシリエーション

完全リコンシリエーションでは、すべての個人レコードがターゲット・システムからOracle Identity Managerにフェッチされます。増分リコンシリエーションでは、前回のリコンシリエーションの実行後に新たに追加または変更された個人レコードのみが、Oracle Identity Managerにフェッチされます。

最終実行時間および「バッチ・サイズ」の各スケジュール済タスク属性を使用して、完全リコンシリエーションおよび増分リコンシリエーションを実装します。最終実行時間属性が0に設定され、「バッチ・サイズ」属性が0以外の値に設定されている場合は、完全リコンシリエーションが実行されます。最終実行時間属性が0以外の値を含む場合は、増分リコンシリエーションが実行されます。

詳細は、3.1項「初回(完全)リコンシリエーションの実行」を参照してください。

1.4.7 制限付き(フィルタ)リコンシリエーション

リコンシリエーションの実行時にOracle Identity Managerにフェッチされるレコードを制限すなわちフィルタ処理するために、実行するリコンシリエーション問合せのWHERE句に条件を追加することができます。

詳細は、3.2.5項「制限付きリコンシリエーションの構成」を参照してください。

1.4.8 バッチ・リコンシリエーション

リコンシリエーションの実行をバッチに分割することができます。これには、各バッチに含める必要があるレコード数を指定します。

詳細は、3.2.1項「バッチ・リコンシリエーション」を参照してください。

1.4.9 接続プーリング

接続プールは、ターゲット・システムへの物理的な接続を表すオブジェクトのキャッシュです。Oracle Identity Managerコネクタは、これらの接続を使用してターゲット・システムと通信できます。実行時には、アプリケーションがプールに接続をリクエストします。接続が使用可能であれば、コネクタがその接続を使用してからプールに戻します。プールに戻された接続は、コネクタが別の操作のために再びリクエストして使用することができます。接続プールは、接続の再利用を可能にし、ネットワーク待機時間、メモリー割当ておよび認証といった接続作成のオーバーヘッドを減らすことに役立っています。

接続プールの構成プロパティは、ITリソース定義に含まれます。接続プールの詳細は、2.3.3項「接続プーリングの設定」を参照してください。

1.4.10 ターゲット・システムおよびOracle Identity Manager間のSSL通信のサポート

Oracle Identity Managerとターゲット・システムの間の通信を保護するためにSSLを構成できます。

詳細は、2.3.4項「ターゲット・システムおよびOracle Identity Manager間のセキュアな通信の構成」を参照してください。

1.5 リコンシリエーション時に使用されるコネクタ・オブジェクト

この項では、次の項目について説明します。

1.5.1 リコンシリエーション問合せ

この章の前半で説明したように、リコンシリエーション時にターゲット・システムのレコードをフェッチするためにSQL問合せを使用します。すべての事前定義済SQL問合せはebsERQuery.propertiesファイルに格納されています。


注意:

要件に応じて、既存の問合せを変更するか、ebsERQuery.propertiesまたは別のプロパティ・ファイルに独自の問合せを追加することができます。詳細は、4.5項「リコンシリエーション問合せの構成」を参照してください。

各事前定義済問合せのSELECT句の列は、ターゲット・システムのPER_ALL_PEOPLE_F表のものです。SELECT句の列の別名は、Lookup.EBS.HRMS.Recon参照定義によってOracle Identity Managerのプロセス・フォーム・フィールドにマップされます。

事前定義済問合せのほとんどは、最終実行時間スケジュール済タスク属性と組み合せて使用されます。この属性には、前回のリコンシリエーション実行が開始したときのタイムスタンプが格納されます。削除されたユーザー・レコードをリコンサイルする問合せを除き、事前定義済問合せは次のような基準を適用して、ターゲット・システムからリコンシリエーションのためにレコードを抽出します。


注意:

最終実行時間属性には値を指定できます。詳細は、3.2.3項「リコンシリエーションのタイムスタンプ」を参照してください。

  • PER_ALL_PEOPLE_F表のLAST_UPDATE_DATE列の日付が、最終実行時間スケジュール済タスク属性に格納されているタイムスタンプの日付部分よりも後の日付であること。

  • CURRENT_EMPLOYEE_FLAG列がyに設定されていること。

  • ターゲット・システム・データベースが実行しているホスト・コンピュータの日付が、EFFECTIVE_START_DATE列とEFFECTIVE_START_DATE列に格納されているそれぞれの日付の間であること。

事前定義済プロパティ・ファイル内の問合せでは、次のリコンシリエーション・モードがサポートされます。

1.5.1.1 新規個人レコードおよび変更された個人レコードのリコンシリエーション

ReconcileCurrentPersons問合せを使用して、最終実行時間属性に格納されているタイムスタンプの後で追加または変更されたすべての個人レコードをリコンサイルします。

次のサンプル・シナリオではReconcileCurrentPersons問合せを使用できます。

Drew、MariaおよびRichardが3月21日に入社しました。この人たちの個人レコードは同じ日にOracle E-Business HRMSに作成されました。また、同じ日にTheresaの姓が更新されました。これらの新たに追された個人レコードと変更された個人レコードは、ReconcileCurrentPersons問合せを次に実行するときにOracle Identity Managerにフェッチされます。

ReconcileCurrentPersons問合せでは、次のターゲット・システム表に格納されているデータが使用されます。

PER_ALL_PEOPLE_F

PER_PERSON_TYPES

PER_PERSON_TYPE_USAGES_F

PER_ALL_ASSIGNMENTS_F

PER_ALL_PEOPLE_F

PER_JOBS

PER_GRADES

HR_ALL_ORGANIZATION_UNITS

1.5.1.2 部門が変更された個人のリコンシリエーション

ChangedDepartments問合せを使用して、問合せに指定する日付範囲内に部門が変更された個人のレコードをリコンサイルします。前に示した3つの基準に加えて、この問合せでは部門変更の日付範囲も使用します。指定された日付範囲内に部門が変更されたユーザーのみがリコンサイルされます。

次のサンプル・シナリオではChangedDepartments問合せを使用できます。

西海岸販売チームとサポート・チームが統合された後、両方のチームの数人のメンバーが別のチームに割り当てられました。このようなチームの変更は3週間かけて行われました。ChangedDepartments問合せを実行するときは、開始日付と終了日付を指定して、新しいチームに転属した個人の変更レコードをリコンサイルできます。

ChangedDepartments問合せでは、次のターゲット・システム表に格納されているデータが使用されます。

PER_ALL_PEOPLE_F PAPF

PER_ALL_ASSIGNMENTS_F N_PAAF

PER_ALL_ASSIGNMENTS_F O_PAAF

PER_PERSON_TYPES PPT

PER_PERSON_TYPE_USAGES_F PPU

PER_ALL_PEOPLE_F SUP

PER_JOBS

PER_GRADES

1.5.1.3 入社予定のリコンシリエーション

FutureHires問合せを使用して、入社予定のレコードをリコンサイルします。このような個人レコードでは、DATE_START列の日付が現在の日付よりも先になっています。この問合せを実行すると、前に説明した最初の2つの基準と一緒に次の基準が適用されます。

ターゲット・システム・データベースが実行しているホスト・コンピュータの日付が、EFFECTIVE_START_DATE列に格納されている日付よりも前であること。

次のサンプル・シナリオではFutureHires問合せを使用できます。

Ansonは、6月に開始する予定のプロジェクトのために雇用されました。Ansonの採用通知には5月25日に入社する必要があることが記載されています。これは現在の日付から10週先です。Ansonのために作成される個人レコードでは、DATE_START列に25-Mayと設定されます。AnsonのレコードをReconcileCurrentPersons問合せでフェッチすることはできません。レコードが有効日指定(将来の日付)であるためです。FutureHires問合せを実行すると、Ansonのレコードは問合せ基準を満たし、レコードがOracle Identity Managerにフェッチされます。


注意:

FutureHires問合せは、最終実行時間スケジュール済タスク属性と組み合せて使用されます。

FutureHires問合せでは、次のターゲット・システム表に格納されているデータが使用されます。

PER_ALL_PEOPLE_FPAPF

PER_PERIODS_OF_SERVICE PPS

PER_PERSON_TYPES PPT

PER_PERSON_TYPE_USAGES_F

PER_ALL_ASSIGNMENTS_F

PER_ALL_PEOPLE_F

PER_JOBS

PER_GRADES

HR_ALL_ORGANIZATION_UNITS

1.5.1.4 退職した個人のリコンシリエーション

退職した個人では、「終了日」列の日付は現在の日付と同じかそれよりも前になります。

TerminatedPersons問合せを使用して、退職した個人のレコードをリコンサイルします。これらの個人レコードでは、DATE_END列の値は現在の日付と同じかそれよりも前です。退職した個人のレコードをリコンサイルすると、対応するOIMユーザーの状態はDisabledに設定されます。

次のサンプル・シナリオではTerminatedPersons問合せを使用できます。

Patrickは退職しました。在籍した最後の日付は8月25日です。TerminatedPersons問合せを8月31日に実行すると、PatrickのOIMユーザー・アイデンティティがDisabled状態に設定されます。


注意:

TerminatedPersons問合せは、最終実行時間スケジュール済タスク属性と組み合せて使用されます。

TerminatedPersons問合せでは、次のターゲット・システム表に格納されているデータが使用されます。

PER_ALL_PEOPLE_F

PER_PERIODS_OF_SERVICE

PER_PERSON_TYPES

PER_PERSON_TYPE_USAGES_F

PER_ALL_ASSIGNMENTS_F

PER_JOBS

PER_GRADES

1.5.1.5 削除された個人レコードのリコンシリエーション

DeletedPersons問合せを使用して、個人レコードの削除をリコンサイルします。このリコンシリエーション・モードでは、すべてのターゲット・システム・レコードの「個人ID」の値がフェッチされ、既存のOIMユーザー・レコードの「個人ID」値と比較されます。特定のOIMユーザーについて一致する値がない場合、そのOIMユーザーの状態はDeletedに設定されます。


注意:

この問合せは変更しないでください。この問合せにWHERE句を追加すると、個人IDの実際のセットのうちサブセットのみが比較のためにOracle Identity Managerにフェッチされます。ユーザーIDがこれらの個人IDと一致しないOIMユーザーは、Oracle Identity Managerから削除されます。

次のサンプル・シナリオではDeletedPersons問合せを使用できます。

この会社では、退職した個人のレコードを2年間保存しておくポリシーがあります。Martinのレコードは退社2年後に削除されました。DeletedPersons問合せの次の実行時に、リコンシリエーション・モジュールによって、MartinのOIMユーザー・アイデンティティ(この時点でDisabled状態)に対応する個人レコードがターゲット・システムにないことが検出されます。その後、MartinのOIMユーザー・アイデンティティはDeletedに設定されます。

DeletedPersons問合せでは、PER_ALL_PEOPLE_Fターゲット・システム表に格納されているデータが使用されます。

1.5.1.6 すべての個人レコードのリコンシリエーション

ReconcileAllPersons問合せを使用して、次に示すすべての個人レコードをリコンサイルします。これらは、他の各問合せで個別にリコンサイルされます。


注意:

削除された個人レコードがOracle Identity Managerに送られるのは、DeletedPersons問合せを実行するときのみです。

  • 新しい個人レコードおよび変更された個人レコード

  • 部門が変更された個人のレコード

  • 入社予定のために作成されたレコード

  • 退職した個人のレコード

1.5.2 リコンシリエーションで使用されるターゲット・システム・フィールド

信頼できるソース・リコンシリエーションでは、表1-2に示すターゲット・システム・フィールドの値がOracle Identity Managerにフェッチされます。これらのフィールドは、PER_ALL_PEOPLE_F表の列です。

表1-2 リコンサイルされるターゲット・システム・フィールド

Oracle E-Business HRMSの属性 OIMユーザー・フォームのフィールド 説明

PERSON_ID

ユーザーID

PER_ALL_PEOPLE_F表の個人レコードの一意のID

PERSON_ID

個人ID

個人レコードの一意のID

FIRST_NAME

名前

LAST_NAME

EFFECTIVE_START_DATE

開始日

ターゲット・システムのアカウントの開始日

EFFECTIVE_END_DATE

終了日

ターゲット・システムのアカウントの終了日

EMAIL_ADDRESS

電子メール

電子メール・アドレス

EMPLOYEE_NUMBER

従業員番号

従業員番号

BUSINESS_GROUP_ID

ビジネス・グループID

組織の業務部門の一意のID

SUPERVISOR_ID

スーパーバイザID

個人のスーパーバイザの一意のID

SUPERVISOR_NAME

スーパーバイザ名

個人のスーパーバイザの名前

JOB

ジョブ

個人のジョブ・コード

GRADE

グレード

個人のグレード


1.5.3 信頼できるソースのリコンシリエーションのリコンシリエーション・ルール


関連項目:

リコンシリエーション一致ルールおよびアクション・ルールに関する一般的な情報は、『Oracle Identity Manager Connector概要』を参照してください。

次に、プロセス一致ルールを示します。

ルール名: eBusiness Employee Recon Rule

ルール要素: Person ID Equals Person ID

このルールでは、次のようになります。

  • 「Equals」の左の「個人ID」フィールドは、OIMユーザー・フォームのフィールドです。

  • 「Equals」の右の「個人ID」フィールドは、ターゲット・システム・フィールドです。

コネクタのデプロイ後に次の手順を実行すると、信頼できるソースのリコンシリエーションのリコンシリエーション・ルールを表示できます。


注意:

次の手順は、コネクタのデプロイ後にのみ実行してください。

  1. Oracle Identity Manager Design Consoleにログインします。

  2. 「Development Tools」を展開します。

  3. 「Reconciliation Rules」をダブルクリックします。

  4. eBusiness Employee Recon Ruleを検索します。図1-3に、信頼できるソースのリコンシリエーションのリコンシリエーション・ルールを示します。

    図1-3 リコンシリエーション・ルール

    図1-3の説明が続きます
    「図1-3 リコンシリエーション・ルール」の説明

1.5.4 リコンシリエーション時に使用される参照定義

コネクタをデプロイすると次の参照定義がOracle Identity Managerに作成されます。

1.5.4.1 Lookup.EBS.HRMS.Recon参照定義

Lookup.EBS.HRMS.Recon参照定義には、プロセス・フォーム・フィールドとターゲット・システムのマッピングに関する情報が保持されます。この参照定義の「Code Key」列には、OIMユーザーのフォーム・フィールド名が含まれます。「Decode」列には、リコンシリエーション問合せのSELECT句に指定されたターゲット・システム・データベース列の別名が含まれます。リコンシリエーション問合せの詳細は、4.5項「リコンシリエーション問合せの構成」を参照してください。

表1-3で、Lookup.EBS.HRMS.Recon参照定義のエントリを説明します。


注意:

必要であれば、この参照定義にエントリを追加することができます。詳細は、4.1項「リコンシリエーションの新規属性の追加」を参照してください。

表1-3 Lookup.EBS.HRMS.Recon参照定義のエントリ

コード・キー デコード

Person ID

PERSON_ID1

User ID

PERSON_ID2

First Name

FIRST_NAME

Last Name

LAST_NAME

Email Address

EMAIL_ADDRESS

Effective Start Date

EFFECTIVE_START_DATE

Employee Number

EMPLOYEE_NUMBER

Effective End Date

EFFECTIVE_END_DATE

Employee Type

USER_PERSON_TYPE

Business Group ID

BUSINESS_GROUP_ID

Supervisor ID

SUPERVISOR_ID

Supervisor Name

SUPERVISOR_NAME

Job

JOB

Grade

GRADE


1.5.4.2 Lookup.EBS.HRMS.PersonTypes参照定義

Lookup.EBS.HRMS.PersonTypes参照定義は、ターゲット・システムとOracle Identity Managerで定義されたユーザー(個人)タイプをマップします。「Code Key」列にはターゲット・システムのUSER_PERSON_TYPE値が含まれ、「Decode」列にはOracle Identity ManagerのUSR_EMP_TYPE値が含まれます。

必要であれば、この参照定義にエントリを追加することができます。たとえば、オペレーティング環境で個人タイプの1つに「大学生」があるときに、Oracle Identity Managerに「インターン」ユーザー・タイプを追加した場合は、エントリを追加して「大学生」を「インターン」にマップすることができます。


注意:

この参照定義にエントリを追加した場合、またはエントリを変更した場合は、リコンシリエーション問合せでも同じ変更を行う必要があります。詳細は、4.5項「リコンシリエーション問合せの構成」を参照してください。

表1-4に、この参照定義のデフォルト・エントリを示します。

表1-4 Lookup.EBS.HRMS.PersonTypes参照定義のエントリ

コード・キー デコード

Employee

Full-Time

Contingent Employee

Part-Time

Contractor

Consultant


1.5.4.3 Lookup.EBS.HRMS.DeleteRecon参照定義

Lookup.EBS.HRMS.DeleteRecon参照定義は、OIMユーザー・フォームの「個人ID」フィールドとターゲット・システムのPERSON_IDフィールドをマップします。この参照定義は、削除された個人レコードのリコンシリエーション時に使用されます。


注意:

この参照定義は変更しないでください。この参照定義を変更すると、削除された従業員レコードのリコンシリエーションが機能しなくなります。


関連項目:

削除された個人レコードのリコンシリエーションの詳細は、次の各項を参照してください。

1.5.4.4 Lookup.EBS.HRMS.QueryFilters参照定義

Lookup.EBS.HRMS.QueryFilters参照定義には、ユーザーが指定するリコンシリエーション・フィルタ・パラメータが含まれます。これらのフィルタ・パラメータは、リコンシリエーションのために選択した問合せのWHERE句に自動的に追加されます。

この参照定義の事前定義済エントリの詳細は、3.2.4項「リコンシリエーションのビジネス・グループIDと日付範囲の設定」を参照してください。

複数のフィルタ・パラメータをこの参照定義に追加することができます。手順は、3.2.5項「制限付きリコンシリエーションの構成」を参照してください。

1.5.4.5 Lookup.EBS.ER.Configurations参照定義

この参照定義を使用して、Oracle Identity Managerリリース9.1.0.2で導入された接続プーリング機能を使用するかどうかを指定します。

Lookup.EBS.ER.Configurations参照定義には次のエントリが含まれます。

コード・キー: USE_CONNECTION_POOLING

デコード: YesまたはNoを指定できます。

この参照定義は、接続プーリング情報を含むITリソースのパラメータと組み合せて使用されます。

詳細は、2.3.3項「接続プーリングの設定」を参照してください。

1.6 コネクタのデプロイおよび使用のロードマップ

次に、このマニュアルの次の章以降の構成を示します。