7 Oracle E-Business Suite HRMSコネクタの機能の拡張

特定のビジネス要件に対応するようにコネクタの機能を拡張できます。

この章の構成は、次のとおりです。

7.1 コネクタ・スキーマの拡張について

デフォルトでは、コネクタで、Oracle Identity Governanceとターゲット・システム間のリコンシリエーションおよびプロビジョニング操作に使用される属性マッピングのセットが提供されます。ビジネス要件に応じて、リコンシリエーションおよびプロビジョニング操作用の属性を追加し、追加属性をマップできます。新規属性をOIM_EMPLOYEE_WRAPPER.pckラッパー・パッケージのget_schema()ストアド・プロシージャに追加することにより、コネクタ・スキーマを拡張できます。

コネクタ・スキーマを拡張する場合、次の概念を理解する必要があります。

  • 属性の初期化

    次の初期化文には、コネクタ・スキーマの属性定義が含まれる内部配列が保持されています。

    attr.extend(NUM);

    ここで、NUMは、初期化する配列のサイズを定義します。配列のサイズは、常に定義される属性の数以上にする必要があります。たとえば、初期化文attr.extend(20);では、初期化時に20個の属性の内部配列が保持されます。

  • 属性の定義

    初期化後、次の形式の文を追加することにより、属性ごとの情報を定義します。

    attr (ORD_NO) := attributeinfo(ATTR_NAME,ATTR_TYPE,CREATE_FLAG,UPDATE_FLAG,REQUIRED_FLAG,READ_FLAG);

    この形式の詳細は次のとおりです。

    • ORD_NOは配列内での属性の順序です。これは必須です。

    • ATTR_NAMEは子属性または単一値属性の名前です。

    • ATTR_TYPEは子属性または単一値属性のSQLデータ型です。

    • CREATE_FLAGは、作成プロビジョニング操作時に属性が必要かどうかを示すフラグです。

    • UPDATE_FLAGは属性が更新可能かどうかを示すフラグです。

    • REQUIRED_FLAGは属性が必須かどうかを示すフラグです。

    • READ_FLAGは属性が読取り可能かどうかを示すフラグです。

    各フラグの値1または0は、それぞれTrueまたはFalseを示します。たとえば、フラグの値1, 0, 1, 0は、属性が必須属性で、作成プロビジョニング操作時に想定する必要があることを意味しています。

  • 属性の配列の拡張

    次の文を指定することにより、初期化後に配列のサイズを増やすことができます。

    attr.extend;

    この文を指定するたびに、配列のサイズが1ずつ増加します。

7.2 認可アプリケーションへの新しい属性の追加

デフォルトでは、アプリケーションの作成時に「スキーマ」ページにリストされている属性が、Oracle Identity Governanceとターゲット・システム間のリコンシリエーション用にマップされます。必要に応じて、信頼できるソースのリコンシリエーション用に追加属性を認可アプリケーションにマップできます。

次の項で、新規属性を追加するために実行する手順について説明します。

7.2.1 認可アプリケーションの「スキーマ」ページへの新しい属性の追加

認可アプリケーションの作成中、「スキーマ」ページにOracle Identity Governanceの属性とターゲット・システムの列間のデフォルトの属性マッピングを表示できます。必要に応じて、新しい属性を追加できます。

これを行うには、『Oracle Identity Governanceでのセルフ・サービス・タスクの実行』認可アプリケーションのスキーマ情報の指定に関する項を参照してください。

7.2.2 DBラッパー・パッケージの更新

次のように、DBラッパー・パッケージを更新することによりコネクタ・スキーマを拡張して、アプリケーションの新規属性を含める必要があります。

  1. 任意のSQLクライアントを開きます。たとえば、SQL Developerなどです。

  2. OIM_EMPLOYEE_WRAPPER.pckラッパー・パッケージの本体を開きます。

  3. get_schema()ストアド・プロシージャを選択します。ストアド・プロシージャで定義されている属性のリストが表示されます。

  4. 定義済属性の数が初期化済属性の数を超えた場合、次のようにします。

    1. 次の属性の初期化文を追加します。

      attr.extend;

    2. 次の形式で追加する新規属性の定義を入力します。

      attr (ORD_NO) := attributeinfo(ATTR_NAME,ATTR_TYPE,CREATE_FLAG,UPDATE_FLAG,REQUIRED_FLAG,READ_FLAG);

      たとえば、ユーザー・アカウントの血液型を含む新規属性を追加する場合、次の文を指定します。

      attr.extend;
      attr (28) := attributeinfo('BLOOD_TYPE','varchar2',1,1,0,1);
      

      この例では、フラグの値1,1,0,1は、作成プロビジョニング操作時にBLOOD_TYPE属性が必須で、更新および読取り可能であるという意味です。

      関連項目:

      新規属性定義を追加する必要のある形式の詳細は、「コネクタ・スキーマの拡張の理解」を参照してください

  5. 定義済属性の数が初期化済属性の数を超えていない場合、新規属性の定義のみを追加します。たとえば、attr (28) := attributeinfo('BLOOD_TYPE','varchar2',1,1,0,1);です。

  6. ラッパー・パッケージを再コンパイルします。

7.2.3 認可アプリケーション用のsearch.propertiesファイルの更新

search.propertiesを更新して、新しく追加された属性を対応するSQL問合せに含める必要があります。

  1. org.identityconnectors.ebs-12.3.0.jarファイルの内容(コネクタ・インストール・パッケージの/bundleディレクトリにあります)を任意のディレクトリに抽出します。
  2. テキスト・エディタで、構成ディレクトリにあるsearch.propertiesを開きます。
  3. 新規作成した属性に対応する列名を含む必要があるSQL問合せを検索します。たとえば、HRMS_CURRENT_EMPLOYEE_RECON_QUERY問合せを検索します。
  4. 新規追加した属性に対応する列名がすでにSQL問合せに含まれている場合、この項で説明する残りのステップをスキップできます。
  5. 新規追加した列名に関する情報がSQL問合せに含まれていない場合、この情報を含むように変更します。たとえば、HRMS_CURRENT_EMPLOYEE_RECON_QUERY問合せ(検索オプション)を変更してPAPF.BLOOD_TYPE AS blood_typeを含めます。Blood Type属性はPER_ALL_PEOPLE_F表内にあり、PAPFは表の別名です。
  6. HRMS_CURRENT_FUTURE_EMPLOYEE_RECON_QUERY (検索オプションと同期オプションの両方)やHRMS_CURRENT_EMPLOYEE_RECON_QUERY (同期オプション)などの他のSQL問合せが該当する場合は、ステップ3から5を繰り返してそれらを更新します。たとえば、HRMS_CURRENT_EMPLOYEE_RECON_QUERYおよびHRMS_CURRENT_FUTURE_EMPLOYEE_RECON_QUERYの問合せを、「EBS ERコネクタのサンプルのSQL問合せ」にリストされているSQL問合せで更新します。
  7. 変更を保存して、ファイルを閉じます。
  8. 更新した問合せを確認します。

7.2.4 コネクタ・バンドルの更新

コネクタ・バンドル(org.identityconnectors.ebs-12.3.0.jar)を更新して、「スキーマ」ページ、DBラッパー・パッケージおよびプロパティ・ファイルに対して行われたすべての更新を含める必要があります。

  1. 次のコマンドを実行して、コネクタ・バンドル(org.identityconnectors.ebs-12.3.0.jar)を更新します。

    jar -cvfm org.identityconnectors.ebs-12.3.0.jar META-INF/MANIFEST.MF *

  2. Oracle Identity GovernanceのJAR更新ユーティリティを実行して、既存のコネクタ・バンドルをOracle Identity Governanceデータベース内の更新済のコネクタ・バンドルに置き換えます。このユーティリティは、Oracle Identity Governanceのインストール時に次の場所にコピーされます。

    ノート:

    このユーティリティを使用する前に、Oracle WebLogic ServerをインストールしたディレクトリにWL_HOME環境変数が設定されていることを確認してください。

    Microsoft Windowsの場合:

    OIM_HOME/server/bin/UpdateJars.bat

    UNIXの場合:

    OIM_HOME/server/bin/UpdateJars.sh

    このユーティリティを実行すると、Oracle Identity Governance管理者のログイン資格証明、Oracle Identity Governanceホスト・コンピュータのURL、コンテキスト・ファクトリ値、アップロードするJARファイルのタイプ、およびアップロードするJARファイルが含まれる場所を入力するように要求されます。JARタイプの値として4を指定します。

  3. コネクタ・バンドルJARが正常に更新されたらOracle Identity Governanceを再起動します。

7.3 ターゲット・アプリケーションへの新しい属性の追加

デフォルトでは、アプリケーションの作成時に「スキーマ」ページにリストされている属性が、Oracle Identity Governanceとターゲット・システム間のリコンシリエーション用にマップされます。必要に応じて、ターゲット・リソースのリコンシリエーションおよびプロビジョニング操作用に追加属性をターゲット・アプリケーションにマップできます。

次の項で、新規属性を追加するために実行する手順について説明します。

7.3.1 ターゲット・アプリケーションの「スキーマ」ページへの新しい属性の追加

ターゲット・アプリケーションの作成中、「スキーマ」ページにOracle Identity Governanceの属性とターゲット・システムの列間のデフォルトの属性マッピングを表示できます。必要に応じて、新しい属性を追加できます。

これを行うには、『Oracle Identity Governanceでのセルフ・サービス・タスクの実行』ターゲット・アプリケーションのスキーマ情報の指定に関する項を参照してください。

7.3.2 DBラッパー・パッケージの更新

次のように、DBラッパー・パッケージを更新することによりコネクタ・スキーマを拡張して、アプリケーションの新規属性を含める必要があります。

  1. 任意のSQLクライアントを開きます。たとえば、SQL Developerなどです。

  2. OIM_EMPLOYEE_WRAPPER.pckラッパー・パッケージの本体を開きます。

  3. get_schema()ストアド・プロシージャを選択します。ストアド・プロシージャで定義されている属性のリストが表示されます。

  4. 定義済属性の数が初期化済属性の数を超えた場合、次のようにします。

    1. 次の属性の初期化文を追加します。

      attr.extend;

    2. 次の形式で追加する新規属性の定義を入力します。

      attr (ORD_NO) := attributeinfo(ATTR_NAME,ATTR_TYPE,CREATE_FLAG,UPDATE_FLAG,REQUIRED_FLAG,READ_FLAG);

      たとえば、ユーザー・アカウントの血液型を含む新規属性を追加する場合、次の文を指定します。

      attr.extend;
      attr (28) := attributeinfo('BLOOD_TYPE','varchar2',1,1,0,1);
      

      この例では、フラグの値1,1,0,1は、作成プロビジョニング操作時にBLOOD_TYPE属性が必須で、更新および読取り可能であるという意味です。

      関連項目:

      新規属性定義を追加する必要のある形式の詳細は、「コネクタ・スキーマの拡張の理解」を参照してください

  5. 定義済属性の数が初期化済属性の数を超えていない場合、新規属性の定義のみを追加します。たとえば、attr (28) := attributeinfo('BLOOD_TYPE','varchar2',1,1,0,1);です。

  6. ラッパー・パッケージを再コンパイルします。

7.3.3 search.propertiesファイルの更新

search.propertiesファイルを更新して、新しく追加された属性を対応するSQL問合せに含める必要があります。

  1. org.identityconnectors.ebs-12.3.0.jarファイルの内容(コネクタ・インストール・パッケージの/bundleディレクトリにあります)を任意のディレクトリに抽出します。
  2. テキスト・エディタで、構成ディレクトリにあるsearch.propertiesを開きます。
  3. 新規作成した属性に対応する列名を含む必要があるSQL問合せを検索します。たとえば、TARGET_HRMS_CURRENT_EMPLOYEE_RECON_QUERY問合せを検索します。
  4. 新規追加した属性に対応する列名がすでにSQL問合せに含まれている場合、この項で説明する残りのステップをスキップできます。
  5. 新規追加した列名に関する情報がSQL問合せに含まれていない場合、この情報を含むように変更します。たとえば、TARGET_HRMS_CURRENT_EMPLOYEE_RECON_QUERY問合せ(検索オプション)を変更してPAPF.BLOOD_TYPE AS blood_typeを含めます。Blood Type属性はPER_ALL_PEOPLE_F表内にあり、PAPFは表の別名です。

    TARGET_HRMS_CURRENT_EMPLOYEE_RECON_QUERY問合せにBlood Type列を含むサンプルの問合せについては「EBS HRMSコネクタのサンプルのSQL問合せ」を参照してください。

  6. TARGET_HRMS_CURRENT_EMPLOYEE_RECON_QUERY (検索オプション)やHRMS_TERMINATED_EMPLOYEE_RECON_QUERYなどの他のSQL問合せが該当する場合は、ステップ3から5を繰り返してそれらの問合せを更新します。たとえば、TARGET_HRMS_CURRENT_EMPLOYEE_RECON_QUERY SQL問合せを変更してPAPF.BLOOD_TYPE AS blood_typeおよびperson.BLOOD_TYPEを選択問合せに含めます。
  7. 変更を保存して、ファイルを閉じます。
  8. 更新した問合せを確認します。

7.3.4 コネクタ・バンドルの更新

コネクタ・バンドル(org.identityconnectors.ebs-12.3.0.jar)を更新して、「スキーマ」ページ、DBラッパー・パッケージおよびプロパティ・ファイルに対して行われたすべての更新を含める必要があります。

  1. 次のコマンドを実行して、コネクタ・バンドル(org.identityconnectors.ebs-12.3.0.jar)を更新します。

    jar -cvfm org.identityconnectors.ebs-12.3.0.jar META-INF/MANIFEST.MF *

  2. Oracle Identity GovernanceのJAR更新ユーティリティを実行して、既存のコネクタ・バンドルをOracle Identity Governanceデータベース内の更新済のコネクタ・バンドルに置き換えます。このユーティリティは、Oracle Identity Governanceのインストール時に次の場所にコピーされます。

    ノート:

    このユーティリティを使用する前に、Oracle WebLogic ServerをインストールしたディレクトリにWL_HOME環境変数が設定されていることを確認してください。

    Microsoft Windowsの場合:

    OIM_HOME/server/bin/UpdateJars.bat

    UNIXの場合:

    OIM_HOME/server/bin/UpdateJars.sh

    このユーティリティを実行すると、Oracle Identity Governance管理者のログイン資格証明、Oracle Identity Governanceホスト・コンピュータのURL、コンテキスト・ファクトリ値、アップロードするJARファイルのタイプ、およびアップロードするJARファイルが含まれる場所を入力するように要求されます。JARタイプの値として4を指定します。

  3. コネクタ・バンドルJARが正常に更新されたらOracle Identity Governanceを再起動します。

7.3.5 ターゲット・アプリケーション用のProcedures.propertiesファイルの更新

作成および更新プロビジョニング操作時に新規追加した列属性をサポートするには、Procedures.propertiesファイルで起動されるストアド・プロシージャを更新する必要があります。

  1. テキスト・エディタで、編集のためにProcedures.propertiesファイルを開きます。

  2. 個人の作成および個人の更新のプロビジョニング操作を起動するために使用されるラッパー・パッケージおよびストアド・プロシージャの名前を検索して決定します。たとえば、OIM_EMPLOYEE_WRAPPER.CREATE_PERSON_APIおよびOIM_EMPLOYEE_WRAPPER.UPDATE_PERSON_APIは、ユーザー作成およびユーザー更新プロビジョニング操作に使用されるラッパー・パッケージおよびストアド・プロシージャです。

  3. 次のように、前述のステップで決定したストアド・プロシージャを更新します。

    1. 任意のSQLクライアントを開きます。たとえば、SQL Developerなどです。

    2. ラッパー・パッケージを開いて、新規追加した属性(例: Blood Type)をユーザー作成およびユーザー更新ストアド・プロシージャに追加します。たとえば、OIM_EMPLOYEE_WRAPPERパッケージを開いて、新規追加した属性をCREATE_PERSON_APIおよびUPDATE_PERSON_APIストアド・プロシージャに追加します。

      図7-1では、新規追加した属性を含めるためにOIM_EMPLOYEE_WRAPPERパッケージで更新する必要があるストアド・プロシージャを強調表示しています。

      図7-1 OIM_EMPLOYEE_WRAPPERパッケージで更新されるストアド・プロシージャ

      図7-1の説明が続きます
      「図7-1 OIM_EMPLOYEE_WRAPPERパッケージで更新されるストアド・プロシージャ」の説明
    3. CREATE_PERSON_APIストアド・プロシージャを選択して、新規追加した属性を含めるように入力パラメータを更新します。

      図7-2では、CREATE_PERSON_APIおよびUPDATE_PERSON_APIの両方のストアド・プロシージャで新規追加された属性を強調表示しています。

      図7-2 新規追加された属性を含むストアド・プロシージャ

      図7-2の説明が続きます
      「図7-2 新規追加された属性を含むストアド・プロシージャ」の説明
    4. OIM_EMPLOYEE_WRAPPER Bodyを開いて、CREATE_PERSON_APIストアド・プロシージャを選択します。

    5. 新規追加した属性を含むプロシージャでHR_EMPLOYEE_API.create_employee APIのコールを更新します。

      図7-3は、更新済のHR_EMPLOYEE_API.create_employee APIを示しています。

      図7-3 新規追加した属性を含むHR_EMPLOYEE_API.create_employee API

      図7-3の説明が続きます
      「図7-3 新規追加した属性を含むHR_EMPLOYEE_API.create_employee API」の説明
    6. 新規追加した属性を含むプロシージャでHR_CONTINGENT_WORKER_API.create_cwk APIのコールを更新します。

      図7-4は、更新済のHR_CONTINGENT_WORKER_API.create_cwk APIを示しています。

      図7-4 新規追加した属性を含むHR_CONTINGENT_WORKER_API.create_cwk API

      図7-4の説明が続きます
      「図7-4 新規追加した属性を含むHR_CONTINGENT_WORKER_API.create_cwk API」の説明
    7. ステップ3.cから3.fを繰り返して、新規追加した属性を含めるようにUPDATE_PERSON_APIストアド・プロシージャを更新します。

    8. ラッパー・パッケージを再コンパイルします。

7.4 ターゲット・アプリケーションへの新規の複数値属性の追加

ターゲット・リソースのリコンシリエーションおよびプロビジョニング用に、Oracle Identity Governanceとターゲット・システム間で新規の複数値属性をマップできます。

デフォルトでは、「EBS HRMSコネクタの属性マッピング」にリストされている属性が、Oracle Identity Governanceとターゲット・システム間のリコンシリエーションおよびプロビジョニング用にマップされます。必要に応じて、ターゲット・リソースのリコンシリエーションおよびプロビジョニング用に追加の複数値属性をターゲット・アプリケーションにマップできます。『Oracle Identity Governance Oracle E-Business Suite User Managementアプリケーションの構成』リコンシリエーションおよびプロビジョニング用の新規複数値属性の追加に関する項を参照してください。

7.5 データの変換および検証の構成

アプリケーションの作成時にGroovyスクリプトのロジックを作成して、ユーザー・アカウント・データの変換および検証を構成します。

要件に応じてリコンサイルされた単一値ユーザー・データの変換を構成できます。たとえば、First NameおよびLast Name値を使用して、Oracle Identity Governanceの「氏名」フィールドの値を作成できます。

同様に、要件に応じて、リコンサイルおよびプロビジョニングされた単一値データの検証を構成できます。たとえば、「名」属性からフェッチしたデータを検証して、そのデータに番号記号(#)が含まれていないことを確認します。また、プロセス・フォームの「名」フィールドに入力したデータを検証して、プロビジョニング操作中にターゲット・システムに番号記号(#)が送信されないようにします。

ユーザー・アカウント・データの変換または検証を構成するには、アプリケーションの作成時にGroovyスクリプトを作成する必要があります。Groovyスクリプトベースの検証と変換のロジックを作成する方法の詳細は、『Oracle Fusion Middleware Oracle Identity Governanceでのセルフ・サービス・タスクの実行』プロビジョニング属性とリコンシリエーション属性の検証と変換に関する項を参照してください。

7.6 アクション・スクリプトの構成

アクション・スクリプトを構成するには、アプリケーションの作成時に独自のGroovyスクリプトを作成します。

これらのスクリプトは、アカウントの作成、更新または削除のプロビジョニング操作の前または後に実行されるように構成できます。たとえば、あるスクリプトを、個々のユーザー作成操作前に実行するように構成できます。

アクション・スクリプトの追加または編集の詳細は、『Oracle Fusion Middleware Oracle Identity Governanceでのセルフ・サービス・タスクの実行』プロビジョニング構成の更新に関する項を参照してください。

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

ターゲット・システムの複数のインストールに対してベース・アプリケーションを構成するには、その構成のコピーを作成する必要があります。

次の例でこの要件について説明します。

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

このようなシナリオによって提起される要件を満たすには、アプリケーションをクローニングして、ベース・アプリケーションの構成をすべてクローニングされたアプリケーションにコピーする必要があります。アプリケーションのクローニングの詳細は、『Oracle Fusion Middleware Oracle Identity Governanceでのセルフ・サービス・タスクの実行』アプリケーションのクローニングに関する項を参照してください。