4 コネクタの機能拡張

コネクタをデプロイしたら、ビジネス要件に合せて構成する必要があります。コネクタの機能を拡張するために実行できる手順は次のとおりです。

• 表1-2「リコンサイルされるターゲット・システム・フィールド」に、値がOracle Identity Managerにフェッチされるターゲット・システム・フィールドが示されています。このフィールドのセットが要件を満たすかどうかを確認します。この他のターゲット・システム・フィールドをこのセットに含める場合は、4.1項「リコンシリエーションの新規属性の追加」を参照してください。

• 1.5.4.1項「Lookup.EBS.HRMS.Recon参照定義」に、事前定義済属性のマッピングが示されています。これらの属性の名前を変更する場合は、4.2項「リコンシリエーションのためにマップされた事前定義済属性の名前の変更」を参照してください。

• 1.5.4.1項「Lookup.EBS.HRMS.Recon参照定義」に、事前定義済属性のマッピングが示されています。これらの属性マッピングの一部を削除することができます。この手順を実行する場合は、4.3項「リコンシリエーションのためにマップされた事前定義済属性の削除」を参照してください。

• OIMユーザー・フォームのフィールド長がターゲット・システムのフィールド長と一致しない場合は、4.4項「OIMユーザー・フォームのフィールド長の変更」を参照してください。

• 事前定義済リコンシリエーション問合せはOIM_HOME/xellerate/ScheduleTask/ebsERQuery.propertiesファイルに格納されています。このファイルをテキスト・エディタで開き、事前定義済問合せが要件を満たすかどうかを調べます。事前定義済問合せを変更する場合、または独自の問合せを作成する場合は、4.5項「リコンシリエーション問合せの構成」を参照してください。

• コネクタでは、特定のリコンシリエーション問合せについて、スケジュール済タスク属性の値としてWHERE句パラメータの値を指定できます。たとえば、ReconcileCurrentPersons問合せのWHERE句にパラメータを追加して、スケジュール済タスクに指定した姓を持つ個人のレコードが返されるようにできます。コネクタのこの機能を使用する場合は、3.2.5項「制限付きリコンシリエーションの構成」を参照してください。

• Oracle E-Business HRMSが、Oracle Identity Managerに対して構成する複数の信頼できるソースのうちの1つである場合は、4.7項「複数の信頼できるソースのリコンシリエーション用のコネクタの構成」を参照してください。

4.1 リコンシリエーションの新規属性の追加

注意: この項では、属性という用語はユーザー・データを格納するIDデータ・フィールドを指します。 この項では、オプションの手順を説明します。この手順は、リコンシリエーションに新しい属性を追加する場合にのみ実行します。

デフォルトでは、表1-2に示した属性が、リコンシリエーション用にOracle Identity Managerとターゲット・システム間でマップされます。必要に応じて、次の追加属性をリコンシリエーション用にマップできます。

注意: リコンシリエーションのために「Full Name」フィールドを追加するサンプル・シナリオを使用して、この手順を説明します。

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

2. 次のようにして、追加するフィールドのUDFを作成します。

   1. 「Administration」を開き、「User Defined Field Definition」をダブルクリックします。

   2. USR表を検索して開きます。

   3. 「Add」をクリックします。

   4. 「User Defined Fields」ダイアログ・ボックスに、次の値を入力します。

      • Label: フィールドのラベルを入力します。たとえば、Full Nameと入力します。

      • DataType: フィールドのデータ型を選択します。たとえば、Stringを選択します。

      • Field Size: フィールド長を入力します。たとえば、20と入力します。

      • Column Name: フィールドの列名を入力します。たとえば、FULL_NAMEと入力します。

        Oracle Identity Managerにより、指定した列名にUSR_UDF_が自動的に付けられます。このため、列名をFULL_NAMEと指定すると、実際の列名はUSR_UDF_FULL_NAMEに変更されます。

        次のスクリーンショットは「User Defined Fields」ダイアログ・ボックスです。

        
        

   5. 「Save」アイコンをクリックします。

3. 次のようにして、リソース・オブジェクトにリコンシリエーション・フィールドを追加します。

   1. 「Resource Management」を開き、「Resource Objects」をダブルクリックします。

   2. 「eBusiness Person」リソース・オブジェクトを検索して開きます。

   3. 「Object Reconciliation」タブの「Reconciliation Fields」サブタブで「Add」をクリックします。

   4. 「Add Reconciliation Field」ダイアログ・ボックスで次のようにします。

      • 「Field Name」フィールドで、リコンシリエーション・フィールドの名前を入力します。

      • 「Field Type」リストから、フィールドのデータ・タイプを選択します。

      • 「Save」アイコンをクリックしてダイアログ・ボックスを閉じます。

        次のスクリーンショットは「Add Reconciliation Field」ダイアログ・ボックスです。

        
        

   5. 「Save」アイコンをクリックします。

4. 次のようにして、プロセス定義にリコンシリエーション・フィールド・マッピングを作成します。

   1. 「Process Management」を開き、「Process Definition」をダブルクリックします。

   2. eBusiness HRMS Personプロセス定義を検索して開きます。

   3. 「Reconciliation Field Mappings」タブで、「Add Field Map」をクリックします。

   4. 「Add Reconciliation Field Mapping」ダイアログ・ボックスで次のようにします。

      • 「Field Name」リストから、「Full Name」を選択します。

      • 「User Attribute」リストから、「FULL_NAME」を選択します。

      • 「Save」アイコンをクリックしてダイアログ・ボックスを閉じます。

        次のスクリーンショットは「Add Reconciliation Field Mapping」ダイアログ・ボックスです。

        
        

   5. 「Save」アイコンをクリックします。

5. 次のようにして、リコンシリエーションの属性マッピングを保持する参照定義にエントリを追加します。

   1. 「Administration」を開き、「Lookup Definition」をダブルクリックします。

   2. Lookup.EBS.HRMS.Recon参照定義を検索して開きます。

   3. 「Add」をクリックします。

   4. 「Code Key」列にFull Name（例）と入力します。

   5. 「Decode」列にFULL_NAME（例）と入力します。

      このスクリーンショットは、Lookup.EBS.HRMS.Recon参照定義を示しています。

      
      

6. 次のようにして、プロパティ・ファイルから使用するリコンシリエーション問合せのSELECT句に列を追加します。

   1. テキスト・エディタでプロパティ・ファイルを開きます。このファイルは次のディレクトリにあります。

      OIM_HOME/xellerate/XLIntegration/EBSER/config

   2. プロパティ・ファイルの各問合せのSELECT句に列名を追加します。

      
      

      注意: これは、削除されたユーザーをリコンサイルするための問合せには適用されません。この問合せは変更しないでください。

      
      

   3. ファイルを保存して閉じます。

4.2 リコンシリエーションのためにマップされた事前定義済属性の名前の変更

注意: この項では、属性という用語はユーザー・データを格納するIDデータ・フィールドを指します。 この項では、オプションの手順を説明します。この手順は、リコンシリエーションのためにマップされた事前定義済属性の名前を変更する場合にのみ実行します。

リコンシリエーションのためにマップされた事前定義済のターゲット・システム属性の名前を変更できます。たとえば、FIRST_NAME属性をFNameに変更できます。事前定義済属性のマッピングの詳細は、1.5.4.1項「Lookup.EBS.HRMS.Recon参照定義」を参照してください。

リコンシリエーションのためにマップされた事前定義済属性の名前を変更するには、次のようにします。

1. 次のようにして、Lookup.EBS.HRMS.Recon参照定義の「Decode」列で属性の名前を変更します。

   1. 「Administration」を開き、「Lookup Definition」をダブルクリックします。

   2. Lookup.EBS.HRMS.Recon参照定義を検索して開きます。

   3. 「Decode」列で、属性のエントリを変更します。

      このスクリーンショットは、Lookup.EBS.HRMS.Recon参照定義を示しています。

      
      

   4. 「Save」アイコンをクリックします。

2. プロパティ・ファイルのすべてのリコンシリエーション問合せで、この属性の列名を変更します。

   
   

   注意: 列名は、Lookup.EBS.HRMS.Recon参照定義の「Decode」列の属性名と同じにする必要があります。

   
   

   1. テキスト・エディタでプロパティ・ファイルを開きます。

   2. プロパティ・ファイルの各問合せのSELECT句で列の名前を変更します。

   3. ファイルを保存して閉じます。

4.3 リコンシリエーションのためにマップされた事前定義済属性の削除

注意: この項では、属性という用語はユーザー・データを格納するIDデータ・フィールドを指します。 この項では、オプションの手順を説明します。この手順は、事前定義済属性マッピングのいずれかを削除する場合にのみ実行します。

1.5.4.1項「Lookup.EBS.HRMS.Recon参照定義」に、リコンシリエーションのための事前定義済属性のマッピングが示されています。この表の属性のうち、削除できるのは次の属性です。

• PERSON_ID1

• EMPLOYEE_NUMBER

• BUSINESS_GROUP_ID

• SUPERVISOR_ID

• SUPERVISOR_NAME

• JOB

• GRADE

これらの属性いずれかに対するマッピングを削除するには、次のようにします。

1. 次のようにして、プロパティ・ファイルのすべてのリコンシリエーション問合せで、SELECT句から列を削除します。

   1. テキスト・エディタでプロパティ・ファイルを開きます。

   2. プロパティ・ファイルの各問合せのSELECT句から列名を削除します。

      
      

      注意: これは、削除されたユーザーをリコンサイルするための問合せには適用されません。この問合せは変更しないでください。

      
      

   3. ファイルを保存して閉じます。

2. Design Consoleにログインします。

3. 次のようにして、リコンシリエーションの属性マッピングを保持する参照定義から属性のエントリを削除します。

   1. 「Administration」を開き、「Lookup Definition」をダブルクリックします。

   2. Lookup.EBS.HRMS.Recon参照定義を検索して開きます。

   3. 削除するエントリに対応する行を選択します。

      このスクリーンショットは、Lookup.EBS.HRMS.Recon参照定義を示しています。

      
      

   4. 「Delete」をクリックし、「Save」アイコンをクリックします。

4. 次のようにして、OIMユーザー・フォームから属性を削除します。

   1. 「Administration」を開き、「User Defined Field Definition」をダブルクリックします。

   2. Usersフォームを検索して開きます。

      次のスクリーンショットには「Users」フォームが表示されています。

      
      

   3. 削除する属性に対応する行を削除します。

   4. 「Save」アイコンをクリックします。

5. 次のようにして、「eBusiness Person」リソース・オブジェクトからフィールドを削除します。

   1. 「Resource Management」を開き、「Resource Objects」をダブルクリックします。

   2. 「eBusiness Person」リソース・オブジェクトを検索して開きます。

   3. 「Object Reconciliation」タブの「Reconciliation Fields」サブタブで、削除するフィールドを選択し、「Delete」をクリックします。

      次のスクリーンショットは、リコンシリエーション・フィールドを示しています。

      
      

   4. 「Save」アイコンをクリックします。

6. 次のようにして、「eBusiness HRMS Person」プロセス定義からリコンシリエーション・フィールド・マッピングを削除します。

   1. 「Process Management」を展開します。

   2. 「Process Definition」をダブルクリックします。

   3. eBusiness HRMS Personプロセス定義を検索して開きます。

   4. 「Reconciliation Field Mappings」タブで、削除するフィールドのエントリをクリックしてから、「Remove Field Map」をクリックします。

      次のスクリーンショットは、リコンシリエーション・フィールド・マッピングを示しています。

      
      

   5. 「Save」アイコンをクリックします。

4.4 OIMユーザー・フォームのフィールド長の変更

注意: この項では、オプションの手順を説明します。この手順は、OIMユーザー・フォームのフィールド長を変更する場合にのみ実行してください。

場合によっては、OIMユーザー・フォームのフィールド（属性）の長さを変更する必要があります。たとえば、Japaneseロケールを使用する場合は、ターゲット・システムのマルチバイト・データを格納するためにOIMユーザー・フォームのフィールド長を増やす場合があります。

OIMユーザー・フォームのフィールド長を変更する場合は、次のようにします。

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

2. 「Administration」を開き、「User Defined Field Definition」をダブルクリックします。

3. Usersフォームを検索して開きます。

4. 必要なフィールドの長さを変更します。

   次のスクリーンショットには「Users」が表示されています。

   
   

5. 「Save」アイコンをクリックします。

4.5 リコンシリエーション問合せの構成

注意: この項では、オプションの手順を説明します。この手順は、事前定義済リコンシリエーション問合せのいずれかを変更する場合または独自の問合せを作成する場合にのみ実行します。

プロパティ・ファイルの既存の問合せを変更できます。また、独自の問合せをファイルに追加することもできます。「問合せの名前」スケジュール済タスク属性の値として名前を指定した問合せが、リコンシリエーション時に適用されます。

既存の問合せを変更する、またはプロパティ・ファイルに問合せを追加するには、次のようにします。

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

1. テキスト・エディタでプロパティ・ファイルを開きます。独自のプロパティ・ファイルを作成する場合は、拡張子を.propertiesにしてください。このプロパティ・ファイルは、ターゲット・システム・ホスト・コンピュータの任意のディレクトリに格納できます。

2. 問合せを変更または追加する際には、次のガイドラインが適用されます。

   
   

   注意: プロパティ・ファイルの問合せを変更または追加する前に、その問合せを標準データベース・クライアントを使用して実行し、ターゲット・システム・データベースで実行したときに必要な結果が生成されることを確認する必要があります。

   
   

   • 問合せの名前

     問合せ名にはスペースを含めないでください。

     問合せ名がプロパティ・ファイルのその他の問合せの名前と同じにならないように確認します。

   • SELECT句

     SELECT句に列を追加するかSELECT句の列を変更します。SELECT句で行う変更を、Lookup.EBS.HRMS.Recon参照定義およびプロセス・フォーム（必要な場合）で行う必要があります。詳細は、4.1項「リコンシリエーションの新規属性の追加」を参照してください。

     OimUserGrants.sqlファイルにリストされている表以外の表から列を追加する場合は、必要なエントリをOimUserGrants.sqlファイルとOimUserSynonyms.sqlファイルに追加します。これらのファイルの既存の権限の詳細は、2.1.2.1項「コネクタ操作用のターゲット・システム・ユーザー・アカウントの作成」を参照してください。

     OimUserGrants.sqlスクリプトにエントリを追加する場合は、次の書式を適用します。

     PROMPT GRANT SELECT ON SCHEMA_NAME.TABLE_NAME TO &USERNAME;
     GRANT SELECT ON SCHEMA_NAME.TABLE_NAME TO &USERNAME;
     

     OimUserSynonyms.sqlスクリプトにエントリを追加する場合は、次の書式を適用します。

     PROMPT CREATE SYNONYM TABLE_NAME FOR SCHEMA_NAME.TABLE_NAME;
     CREATE SYNONYM TABLE_NAME FOR SCHEMA_NAME.TABLE_NAME;
     

   • WHERE句

     次の条件が問合せのWHERE句に含まれていることを確認します。

     
     

     注意: すべての事前定義済問合せにおいてWHERE句のその他の条件はオプションです。リコンシリエーション時に適用する場合のみ、それらの条件を含めてください。

     
     

     • PPT.USER_PERSON_TYPE_IN('Employee','Contractor','Contingent Employee')

       この条件に指定する個人タイプは、Lookup.EBS.HRMS.PersonTypes参照定義に指定するものと同じであることが必要です。この参照定義の詳細は、1.5.4.2項「Lookup.EBS.HRMS.PersonTypes参照定義」を参照してください。

     • (ROUND((PAPF.LAST_UPDATE_DATE – TO_DATE('01011970','DDMMYYYY')) *1440 *60 *1000) > :lastExecutionTime)

       この条件は、最終実行時間スケジュール済タスク属性に格納されているタイムスタンプの後にターゲット・システム・レコードが追加または更新されたかどうかを判別するために使用されます。

     • OimUserGrants.sqlファイルにリストされている表以外の表から列を追加するとき、その表にタイムスタンプ情報を格納する列がある場合は、次の条件を追加します。

       (ROUND((TABLE_ALIAS.TIME_STAMP_COLUMN_NAME – TO_DATE('01011970','DDMMYYYY')) *1440 *60 *1000) > :lastExecutionTime)

     次に、WHERE句の拡張サンプルを示します。

     AND HAOU.NAME IN ('Sales', 'Operations') \
     

     このサンプルの条件を使用すると、フェッチされるユーザー・レコードが、Sales部門またはOperations部門に所属するユーザーに制限されます。HAOUはHR_ALL_ORGANIZATION_UNITS表の別名です。

   • コメント

     プロパティ・ファイルではシャープ記号を使用して各コメント行を指定します。

     コメントを付けて、既存の問合せに加える変更を説明したり、追加する新しい問合せを説明したりします。

     例としてはファイルの既存のコメントを参照してください。

   • 改行

     （読みやすくするために）問合せを改行する場合は、各行の最後に円記号（\）を追加します。

   • SQLキーワード

     データベースのデータを変更する（または変更のために使用される可能性がある）句またはキーワードが問合せに含まれないことを確認する必要があります。次のキーワードが検出されるとエラー・メッセージがログ・ファイルに書き込まれます。

     • ALTER

     • CREATE

     • DELETE

     • DROP

     • EXECUTE

     • INSERT

     • UPDATE

3. プロパティ・ファイルを保存して閉じます。

4.6 ターゲット・システムの複数のインストールに対するコネクタの構成

ターゲット・システムの複数のインストールに対してコネクタを構成する場合があります。次の例でこの要件について説明します。

Example Multinational Inc.の東京、ロンドンおよびニューヨークの事業所には、独自にターゲット・システムがインストールされています。最近、この会社では、Oracle Identity Managerをインストールし、これを構成してインストールされたすべてのターゲット・システムをリンクしようとしています。

このような例で示される要件に対応するには、ターゲット・システムの各インストールに対してコネクタのコピーを作成する必要があります。

このような例で示される要件に対応するには、ターゲット・システムの各インストールに対するコネクタを構成する必要があります。そのためには、次のコネクタ・オブジェクトのコピーを作成します。

関連項目: この手順の各ステップ実行の詳細は、『Oracle Identity Managerデザイン・コンソール・ガイド』を参照してください。

• リソース・オブジェクト

• ITリソース

• 参照定義:

  • Lookup.EBS.ER.Configurations

  • Lookup.EBS.HRMS.DeleteRecon

  • Lookup.EBS.HRMS.PersonTypes

  • Lookup.EBS.HRMS.QueryFilters

  • Lookup.EBS.HRMS.Recon

• スケジュール済タスク

  • eBusiness HRMSの信頼できるリコンシリエーション

  • eBusiness HRMSの削除リコンシリエーション

4.7 複数の信頼できるソースのリコンシリエーション用のコネクタの構成

注意: このコネクタでは、複数の信頼できるソースのリコンシリエーションがサポートされます。 この項では、オプションの手順を説明します。この手順は、複数の信頼できるソースのリコンシリエーションのためにコネクタを構成する場合にのみ実行します。

次に、組織の個人データに対して複数の信頼できるソースが存在する場合の例を示します。

• ターゲット・システムの1つは、個人に関するデータの信頼できるソースです。2つ目のターゲット・システムは、契約者に関するデータの信頼できるソースです。3つ目のターゲット・システムは、インターンに関するデータの信頼できるソースです。

• 1つのターゲット・システムは、OIMユーザーを構成する一部のアイデンティティ・フィールドのデータを保持します。他の2つのシステムは、残りのアイデンティティ・フィールドのデータを保持します。つまり、OIMユーザーを作成するには、3つのシステム全部からデータをリコンサイルする必要があります。

組織のオペレーティング環境がこれらのシナリオのいずれかで説明されている環境に類似する場合、このコネクタを使用すると、組織の個人データの信頼できるソースの1つとしてターゲット・システムを使用できるようになります。

複数の信頼できるソースのリコンシリエーションの詳細は、『Oracle Identity Managerデザイン・コンソール・ガイド』を参照してください。