HCMでのユーザーおよびロールのプロビジョニングのベスト・プラクティス

次のベスト・プラクティスとガイドラインでは、HCMでユーザーおよびロールをプロビジョニングするためのプロセスについて説明します。ここで提示するプロセスを使用することが重要である理由を、様々な例とシナリオをとおして説明します。

これらのプロセスの適切な実行について理解することで、安定性を確保し、責任を持ってリソースを管理できるようになります。

ユーザーおよびロールのプロビジョニング・プロセス

ユーザーとロールのプロビジョニングには4つのプロセスがあります。これらのプロセスは一度に1つだけ実行してください。これらのプロセスは重複しないようにしてください。プロセスが完了するまでの時間を十分に確保したうえで、別のプロセスをスケジュールするようにしてください。

ユーザーとロールのプロビジョニングには次の4つのプロセスがあります。

プロセス	目的	頻度	使用方法	ベスト・プラクティス
待ち状態のLDAP要求の送信	ユーザー・アカウントのプロビジョニングに関する要求とユーザー・ロールの追加および削除の要求をLDAPディレクトリに送信します。通常はこれを使用して、一括プロセスによって作成されたプロビジョニング要求を処理し、現在アクティブである先日付の要求も処理します。	日次必要に応じて	このジョブは、次の要求を処理します。ユーザー・アカウントの作成、一時停止、再アクティブ化ロールのプロビジョニングおよびプロビジョニング解除勤務先Eメールを含む個々のユーザーの個人属性の更新 Oracle HCM Cloudで発信されたHCMデータ・ロールに関する情報の送信パラメータの使用方法: `User Type` すべて - すべてのユーザー・タイプに対する要求を処理します。推奨。パーティ - CRMパーティの要求のみを処理します。個人 - HCM個人の要求のみを処理します。 `バッチ・サイズ` - 待ち状態の要求を処理するバッチの数 A - バッチ・サイズ10を使用します。推奨。 AF - バッチ・サイズ10を使用しますが、各実行では前回の実行で失敗した要求も処理されます。 20 - 非常に多くの要求を処理する場合にのみ使用されます。詳細は、「待ち状態のLDAP要求の送信」プロセスを実行する理由のトピックを参照してください。	すべきことバッチ・サイズをAにして、少なくとも1日に1回スケジュールします。必要に応じて、要件に基づいて1日に2回以上実行するようにスケジュールします。次の実行が、前の実行の完了後少なくとも30分後に開始することを確認します。 HCMデータ・ローダーを使用して就業者またはユーザーを一括ロードした後に、ジョブを実行します。詳細は、HCMデータ・ローダー・ガイドのデータのロード後に実行するプロセスのトピックを参照してください。禁止事項 30分未満の間隔で実行するようにスケジュールしないでください。ジョブを頻繁に実行すると、アプリケーションの不要な処理オーバーヘッドが発生し、パフォーマンスの問題が発生する可能性があります。バッチ・サイズをAFとして実行するようにスケジュールしないでください。バッチ・サイズAFは、問題の解決後に失敗した要求を再処理するためにジョブを手動で実行する場合にのみ使用する必要があります。バッチ・サイズAFで実行するようにスケジュールされている場合、ジョブが実行されるたびに、失敗した要求に対して新しいLDAP要求が作成され、再処理されます。障害の根本的な問題が解決されない場合、新しいLDAP要求の作成が何度も繰り返されます。 20を超えるバッチ・サイズで実行するようにスケジュールしないでください。デフォルトのバッチ・サイズは10 (A)で、推奨される最大バッチ・サイズは20です。
すべてのユーザーのロールの自動プロビジョニング	非アクティブなユーザーを含むすべてのユーザーのロール・メンバーシップを、ロール・プロビジョニング・ルールに対して評価します。	必要に応じてまれ	このプロセスでは、現在のすべてのユーザー・アサイメントが現在のすべてのロール・マッピングと比較され、ユーザーに対してロールを追加または削除するために必要な要求が作成されます。パラメータの使用方法 `生成されたロール要求の処理` - 生成されたLDAP要求をジョブで処理するかどうかを示しますはい - 生成されるロール要求の数が少ないことが予想される場合は、パラメータを「はい」に設定して、生成された要求もこのジョブで処理されるようにします。いいえ - 何千ものロール要求が生成されることが予想される場合は、パラメータを「いいえ」に設定して、処理を「待ち状態のLDAP要求の送信」ジョブの次回の実行に延期します。 `就業者アサイメント・ステータス` - ジョブによって自動プロビジョニング・ルールを実行する必要がある就業者のアサイメント・ステータスアクティブアクティブ、休止非アクティブ休止多数の要求の処理中にパフォーマンスを向上させるには、このジョブに対して一括モードを有効にします。	すべきこと次のシナリオでは、オンデマンドでジョブを1回実行します。ロール・マッピングの作成後の既存のユーザーの初期ロール割当新しいロール・マッピング・ルールが追加された場合、または既存のルールが変更された場合詳細は、「自動プロビジョニング」のトピックを参照してください。禁止事項このジョブは、すべてのロール・マッピング・ルールを評価し、対象ユーザー全体に対して検証するため(これは負荷のかかる操作です)、定期的に実行するようにスケジュールしないでください。最初のロール割当が完了すると、就業者の作成、更新、退職のたびにロール・マッピング・ルールが増分的に実行されます。ロール・マッピング・ルールの数とユーザー数が多いほど、このジョブによって行われる処理が長くなり、負荷も大きくなります。ジョブを頻繁に実行すると、アプリケーションの不要な処理オーバーヘッドが発生し、パフォーマンスの問題が発生する可能性があります。
LDAPへの複数ユーザーの個人データの送信	Oracle HCM Cloudにおける個人情報の変更をLDAPディレクトリと調整。	必要に応じてまれ	HCM個人レコードの一括更新の場合、このプロセスでは、LDAPの個人データがOracle HCM Cloudのデータと一致するように更新されます。このプロセスでは、「名」、「姓」、「Eメール」および「マネージャ」属性が更新されます。このプロセスは、HCM個人ユーザーのみに適用され、パーティ・ユーザーには適用されません。パラメータの使用方法 `User Population` すべてのユーザー変更されたユーザーのみ詳細は、個人データをアイデンティティ・ストアに送信する理由のトピックを参照してください。	すべきこと初期実装時に、すべてのユーザー・レコードをLDAPに1回のみ同期するために、パラメータ`「すべてのユーザー」`を使用してオンデマンドで1回実行します。就業者の個人データを一括で変更した後、パラメータ`変更されたユーザーのみ`を使用してオンデマンドで1回実行します。このジョブは、変更されたユーザーの個人データのみをLDAPに同期します。詳細は、データのロード後に実行するプロセスのトピックを参照してください。禁止事項パラメータ`「すべてのユーザー」`を使用して定期的に実行するようにスケジュールしないでください。ジョブが実行されるたびに、個人情報が変更されたかどうかに関係なく、ユーザーごとにLDAP要求が作成されます。ジョブがスケジュールされると、次の2つの問題が発生します。アプリケーション内のすべてのユーザーに対して不要なLDAP要求が作成されるため、LDAP要求表のサイズが大きくなります。「待ち状態のLDAP要求の送信」ジョブで不要な処理オーバーヘッドが発生し、パフォーマンスの問題が発生する可能性があります。
最新のLDAP変更の取得	Oracle HCM Cloudの個人レコードをLDAPディレクトリから受信したデータで更新します。	非常にまれ	このプロセスでは、LDAPディレクトリのすべてのユーザーおよびロールがOracle HCM Cloudに同期されます。セキュリティ・コンソールでユーザーにプロビジョニングされたロールと「ユーザー・アカウントの管理」ページのロールに違いが見られる場合は、このプロセスを実行することをお薦めします。このジョブにはパラメータはありません。詳細は、最新のLDAP変更の取得のトピックを参照してください。	すべきこと次のシナリオにおいてオンデマンドで1回実行します。リリース更新後 Oracle HCM Cloudのユーザー/ロール・レコードがLDAPと同期されておらず、ジョブを実行することがOracleサポートによって確認された場合禁止事項これは不要な処理であり、機能的な目的を果たさないため、定期的に実行するようにスケジュールしないでください。すべてのユーザー・データは、最初にOracle HCM Cloudで作成され、LDAPと同期されます。ユーザー・レコードがLDAPで直接変更されることは想定されていないため、LDAPからOracle HCM Cloudに変更を定期的に取得する必要はありません。

ユーザーおよびロール・プロビジョニング・プロセスの一般的なシナリオ

ユーザーおよびロールのプロビジョニング・プロセスについての理解を深めるため、いくつかのシナリオを見てみましょう。一部のプロセスは環境の速度低下を招く恐れがあるため、シナリオの内容を理解して影響を把握したうえで、プロセスをスケジュールするようにしてください。

シナリオ1: HCMデータ・ローダーを使用した新規採用のインポート

HCM Enterprise情報の管理ページの「ユーザー・アカウント作成」オプションが「個人およびパーティ・ユーザーの両方」に設定されています。この設定では、各就業者のインポート時にユーザー・アカウントが自動的に生成されます。
HCMデータ・ローダーを使用してWorker.datファイルをインポートする方法で、新規採用をロードします。
インポートされた各個人について、ユーザー・アカウント要求が自動的に作成されます。

次に実行すべき作業:

HCMデータ・ローダーを使用して新規採用をインポートしたら、「待ち状態のLDAP要求の送信」プロセスを実行します。このジョブでは、保留中のすべてのユーザー・アカウント作成要求がHCM CloudからLDAPディレクトリに送信されます。

禁止事項:

すべてのユーザーのロールの自動プロビジョニング
最新のLDAP変更の取得
すべてのユーザーの個人データのLDAPへのコピー

シナリオ2: 組織におけるロール・プロビジョニング・ルールの管理に対する変更

新しいロール・プロビジョニング・ルールの追加や、既存のロール・プロビジョニング・ルールの更新など、「ロール・プロビジョニング・ルールの管理」に変更を加えます。これらの変更はロールを新規または既存のユーザーに割り当てる方法に影響を与える可能性があります。

次に実行すべき作業:

自動プロビジョニング・マッピングの更新が完了した後に、次を実行します。

「すべてのユーザーの自動プロビジョニング・ロール」プロセスをデフォルトのパラメータで1回実行します。

このジョブは、アクティブなユーザーと非アクティブ・ユーザーを含むすべてのユーザーを評価し、更新されたロール自動プロビジョニング・ルールに従ってロール・メンバーシップを更新します。本番環境では、このような状況においてのみ、このプロセスを実行します。

シナリオ3: 就業者のインポート後に、「ロール・プロビジョニング・ルールの管理」で自動プロビジョニング・マッピングを作成

就業者をインポートして、それらの就業者のユーザー・アカウントを作成した後に、「ロール・プロビジョニング・ルールの管理」タスクでロール・プロビジョニング・ルールを作成します。既存のユーザー・アカウントは新しいロール・プロビジョニング・ルールに照らして評価されていません。

次に実行すべき作業:

このような状況は回避しけなければいけません。就業者を一括ロードする前に、すべてのロール・プロビジョニング・ルールを作成する必要があります。少なくとも「従業員」ロール・ルールは作成しておく必要があります。

ロール・プロビジョニング・ルールが作成されたら、次を実行します。

「すべてのユーザーの自動プロビジョニング・ロール」プロセスをデフォルトのパラメータで1回実行します。このジョブは、アクティブなユーザーと非アクティブ・ユーザーを含むすべてのユーザーを評価し、更新されたロール自動プロビジョニング・ルールに従ってロール・メンバーシップを更新します。

シナリオ4: 従業員のマネージャ、名、姓またはEメールの手動更新

短い従業員リストに含まれる次のフィールドのいずれかを、アプリケーションを使用して更新します。

名
姓
Eメール
マネージャ

次に実行すべき作業:

なし。このHRトランザクションにはユーザー・プロビジョニング関連アクティビティは必要ありません。

禁止事項:

このHRトランザクションの完了後、ユーザーおよびロールのプロビジョニング・プロセスを実行またはスケジュールしないでください。

シナリオ5: 従業員のマネージャ、名、姓またはEメールの一括更新

HCMデータ・ローダーを使用して、次の従業員(就業者)フィールドを一括で更新します。

名
姓
Eメール
マネージャ

また、この変更を行うことで、ユーザー関連のアクティビティがさらに必要になるかどうかを把握できていません。

次に実行すべき作業:

HCMデータ・ローダーを使用して更新された就業者情報をインポートした後に、次を実行します。

「LDAPへの複数ユーザーの個人データの送信」プロセスを1回実行します。

このジョブは、HCMデータ・ローダー・インポートによる個人プロファイル変更を使用してLDAPレコードを更新します。このジョブは「すべてのユーザー」モードではなく「変更済」モードで実行してください。
Eメールが更新された場合のみ、「待ち状態のLDAP要求の送信」プロセスを実行します。これによりLDAPディレクトリが同期し続けます。

シナリオ6: 従業員のアサイメント事業所の手動更新

ジョブ事業所を変更した従業員がいます。アプリケーション・インタフェースを使用してアサイメント事業所を更新します。従業員の事業所を変更すると、ロール・アサイメントに影響する場合があります。

次に実行すべき作業:

なし。このHRトランザクションでは、ロール自動プロビジョニング・ルールに対してこの従業員が自動的に評価されます。この従業員のロール・メンバーシップに変更が必要な場合、HRトランザクションを保存したときに自動的に変更されます。

禁止事項:

このHRトランザクションの完了後、ユーザーおよびロールのプロビジョニング・プロセスを実行またはスケジュールしないでください。

シナリオ7: 個人に対するジョブ・ロールの手動追加

選択された従業員にジョブ・ロールを手動で追加しましたが、LDAPディレクトリに対して他に何か実行する必要があるかどうかを把握できていません。

次に実行すべき作業:

なし。このHRトランザクションは、選択された従業員に対する保留中のLDAP要求を自動的に処理します。

禁止事項:

このHRトランザクションの完了後、ユーザーおよびロールのプロビジョニング・プロセスを実行またはスケジュールしないでください。

シナリオ8: HCMデータ・ローダーを使用して、ユーザー・アカウント作成を抑制した状態で就業者をロード

ユーザー・アカウントの作成を抑制した状態(Counter-intelligences = N)で就業者をロードしましたが、LDAPディレクトリに対して他に何か実行する必要があるかどうかを把握できていません。

次に実行すべき作業:

なし。インポートされた就業者にはユーザー・アカウントがないため、LDAP関連プロセスを追加で実行する必要はありません。

禁止事項:

このHRトランザクションの完了後、ユーザーおよびロールのプロビジョニング・プロセスを実行またはスケジュールしないでください。

シナリオ9: HCMデータ・ローダーを使用して、既存の個人レコードに対してユーザー・アカウントを作成

ユーザー・アカウントを作成せずに就業者をロードしました。 HCMデータ・ローダーを使用して、適切に準備されたUser.datファイルをインポートし、既存の就業者のユーザー・アカウントを一括で作成します。また、これと同じ方法を使用して、いくつかの手動ロールを新規ユーザー・アカウントに割り当てます。

ロールの自動プロビジョニングについて懸念があり、LDAPディレクトリに対して他に何か実行する必要があるかどうかを把握できていません。

次に実行すべき作業:

HCMデータ・ローダーを使用してUser.datファイルをインポートしたら、「待ち状態のLDAP要求の送信」プロセスを1回実行します。

このジョブは保留中のすべてのユーザー・アカウントおよびロール・アサイメント要求をHCMからLDAPディレクトリに送信します。すべての新規ユーザー・アカウントは、作成プロセス中に自動プロビジョニング・ルールに照らして評価されます。

禁止事項:

HCMデータ・ローダーでユーザー・アカウント要求をロードした後に、次のプロセスをスケジュールしないでください。

すべてのユーザーのロールの自動プロビジョニング
最新のLDAP変更の取得
すべてのユーザーの個人データのLDAPへのコピー

シナリオ10: 「すべてのユーザーの自動プロビジョニング・ロール」プロセスを実行し、大量のユーザー・アカウントを用意する必要がある場合

他のアサイメント・ステータスの前にアクティブなアサイメントがある従業員について、最初にプロセスを実行する必要があります。「すべてのユーザーの自動プロビジョニング・ロール」プロセスでは、実行のたびにすべてのユーザー・アカウントが選択されます。これは、大量のユーザー・アカウントがある場合に実行時間が長くなることがあります。これは、オプションのフィルタリング・パラメータ、従業員のアサイメント・ステータスを使用して克服できます。

従業員のアサイメント・ステータスパラメータを使用すると、アサイメントが選択したステータスの就業者にリンクされているユーザー・アカウントのみを処理できます。次のいずれかの値を指定できます。

[空白] - デフォルト
アクティブ
アクティブ、休止
非アクティブ
休止

次に実行すべき作業:

特定のアサイメント・ステータスの自動プロビジョニングの更新が完了したら、デフォルトのパラメータを使用して「すべてのユーザーの自動プロビジョニング・ロール」プロセスを1回実行します。このジョブは、アクティブなユーザーと非アクティブ・ユーザーを含むすべてのユーザーを評価し、更新されたロール自動プロビジョニング・ルールに従ってロール・メンバーシップを更新します。本番環境では、このような状況においてのみ、このプロセスを実行します。