Microsoft Entra プロビジョニングと SAP SuccessFactors の統合方法

ユーザーの ID のライフ サイクルを管理するために、Microsoft Entra ユーザー プロビジョニング サービスと SAP SuccessFactors Employee Central を統合します。 Microsoft Entra ID では、次の 3 つの統合があらかじめ構築されています。

• オンプレミスの Active Directory のユーザー プロビジョニングに対する SuccessFactors
• SuccessFactors からの Microsoft Entra へのユーザー プロビジョニング
• SuccessFactors の書き戻し

この記事では、統合のしくみと、さまざまな HR シナリオでプロビジョニング動作をカスタマイズする方法について説明します。

Microsoft Entra では、SuccessFactors へのシングル サインオンもサポートされています。 詳細については、Microsoft Entra シングル サインオン (SSO) と SuccessFactors の統合に関する記事を参照してください。

接続の確立

Microsoft Entra プロビジョニング サービスでは、基本認証を使用して、Employee Central OData API エンドポイントへの接続が行われます。 SuccessFactors プロビジョニング アプリを設定するときに、 [管理者資格情報] セクションの [テナント URL] パラメーターを使用して、API データ センターの URL を構成します。

Microsoft Entra プロビジョニング サービスと SuccessFactors の間の接続をさらにセキュリティで保護するには、次のようにして、SuccessFactors の IP 許可リストに Microsoft Entra の IP 範囲を追加します。

1. Azure パブリック クラウドの最新の IP 範囲をダウンロードします。
2. そのファイルを開き、タグ AzureActiveDirectory を検索します。
3. addressPrefixes 要素内に列記されているすべての IP アドレス範囲をコピーし、その範囲を使用して IP アドレス制限リストを作成します。
4. CIDR の値を IP 範囲に変換します。
5. SuccessFactors 管理ポータルにログインして、IP 範囲を許可リストに追加します。 SAP サポート ノート 2253200 を参照してください。 このツールで IP 範囲を入力できるようになります。

サポートされているエンティティ

SuccessFactors のすべてのユーザーについて、Microsoft Entra プロビジョニング サービスにより次のエンティティが取得されます。 各エンティティは、"取得ルール" 列で説明されているように、OData API $expand クエリ パラメーターを使用して展開されます。 一部のエンティティは既定で展開されますが、一部のエンティティはマッピングに特定の属性が存在する場合にのみ展開されます。

完全同期のしくみ

属性マッピングに基づいて、完全同期の間に、Microsoft Entra プロビジョニング サービスによって、次の "GET" OData API クエリが送信されて、すべてのアクティブなワーカーと終了したワーカーの有効なデータがフェッチされます。

SuccessFactors のユーザーごとに、プロビジョニング サービスにより、マッピングで定義されている一致する属性を使用して、ターゲット (Microsoft Entra ID とオンプレミスの Active Directory) でアカウントが検索されます。 たとえば、personIdExternal が employeeId にマップされ、一致する属性として設定されている場合は、プロビジョニング サービスによって personIdExternal 値を使用して、employeeId フィルターでユーザーが検索されます。 ユーザーの一致が見つかった場合は、ターゲット属性が更新されます。 一致するものが見つからない場合は、ターゲットに新しいエントリが作成されます。

特定の personIdExternal に対して OData API エンドポイントによって返されたデータを検証するには、API クエリのSuccessFactorsAPIEndpointを自分の API データ センター サーバーの URL で更新し、cURLや Graph エクスプローラーなどのツールを使用してクエリを呼び出します。 「in」フィルターが機能しない場合は、「eq」フィルターを試してください。

https://[SuccessFactorsAPIEndpoint]/odata/v2/PerPerson?$format=json&
$filter=(personIdExternal in '[personIdExternalValue]')&
$expand=employmentNav/userNav,employmentNav/jobInfoNav,personalInfoNav,personEmpTerminationInfoNav,
phoneNav,phoneNav/phoneTypeNav,emailNav,employmentNav/jobInfoNav/businessUnitNav,employmentNav/jobInfoNav/companyNav,
employmentNav/jobInfoNav/companyNav/countryOfRegistrationNav,employmentNav/jobInfoNav/costCenterNav,
employmentNav/jobInfoNav/divisionNav,employmentNav/jobInfoNav/departmentNav,employmentNav/jobInfoNav/jobCodeNav,
employmentNav/jobInfoNav/locationNav,employmentNav/jobInfoNav/locationNav/addressNavDEFLT,employmentNav/jobInfoNav/payGradeNav,
employmentNav/empGlobalAssignmentNav,employmentNav/empGlobalAssignmentNav/assignmentTypeNav,employmentNav/jobInfoNav/emplStatusNav,
employmentNav/jobInfoNav/employmentTypeNav,employmentNav/jobInfoNav/employeeClassNav,employmentNav/jobInfoNav/eventReasonNav

増分同期のしくみ

完全同期の後、Microsoft Entra プロビジョニング サービスにより LastExecutionTimestamp が維持され、それを使用して増分変更を取得するためのデルタ クエリが作成されます。 各 SuccessFactors エンティティに含まれるタイムスタンプ属性 (lastModifiedDateTime、startDate、endDate、latestTerminationDate など) が評価され、変更が LastExecutionTimestamp と CurrentExecutionTime の間にあるかどうかが確認されます。 そうである場合、エントリの変更は有効であると見なされ、同期のために処理されます。

SuccessFactors に対して増分変更に関するクエリを実行するために Microsoft Entra ID で使用される OData API 要求テンプレートを次に示します。 要求テンプレートで変数 SuccessFactorsAPIEndpoint、LastExecutionTimestamp および CurrentExecutionTime を更新し、cURL や Graph エクスプローラーなどのツールを使用して、返されるデータを確認できます。 または、OData API 監査ログを有効にすることで、SuccessFactors から実際の要求ペイロードを取得することもできます。

https://[SuccessFactorsAPIEndpoint]/odata/v2/PerPerson/$count?$format=json&$filter=(personEmpTerminationInfoNav/activeEmploymentsCount ne null) and
((lastModifiedDateTime ge datetimeoffset'<LastExecutionTimestamp>' and lastModifiedDateTime le datetimeoffset'<CurrentExecutionTime>') or
(personalInfoNav/startDate ge datetimeoffset'<LastExecutionTimestamp>' and personalInfoNav/startDate le datetimeoffset'<CurrentExecutionTime>') or
((personalInfoNav/lastModifiedDateTime ge datetimeoffset'<LastExecutionTimestamp>' and personalInfoNav/lastModifiedDateTime le datetimeoffset'<CurrentExecutionTime>') and (personalInfoNav/startDate le datetimeoffset'<CurrentExecutionTime>' and (personalInfoNav/endDate ge datetimeoffset'<CurrentExecutionTime>' or  personalInfoNav/endDate eq null))) or
(employmentNav/startDate ge datetimeoffset'<LastExecutionTimestamp>' and employmentNav/startDate le datetimeoffset'<CurrentExecutionTime>') or
((employmentNav/lastModifiedDateTime ge datetimeoffset'<LastExecutionTimestamp>' and employmentNav/lastModifiedDateTime le datetimeoffset'<CurrentExecutionTime>') and (employmentNav/startDate le datetimeoffset'<CurrentExecutionTime>' and (employmentNav/endDate ge datetimeoffset'<CurrentExecutionTime>' or employmentNav/endDate eq null))) 
(employmentNav/jobInfoNav/startDate ge datetimeoffset'<LastExecutionTimestamp>' and employmentNav/jobInfoNav/startDate le datetimeoffset'<CurrentExecutionTime>') or
((employmentNav/jobInfoNav/lastModifiedDateTime ge datetimeoffset'<LastExecutionTimestamp>' and employmentNav/jobInfoNav/lastModifiedDateTime le datetimeoffset'<CurrentExecutionTime>') and (employmentNav/jobInfoNav/startDate le datetimeoffset'<CurrentExecutionTime>' and (employmentNav/jobInfoNav/endDate ge datetimeoffset'<CurrentExecutionTime>' or employmentNav/jobInfoNav/endDate eq null))) or
(phoneNav/lastModifiedDateTime ge datetimeoffset'<LastExecutionTimestamp>' and phoneNav/lastModifiedDateTime le datetimeoffset'<CurrentExecutionTime>') or
(emailNav/lastModifiedDateTime ge datetimeoffset'<LastExecutionTimestamp>' and emailNav/lastModifiedDateTime le datetimeoffset'<CurrentExecutionTime>') or
(personEmpTerminationInfoNav/latestTerminationDate ge datetimeoffset'<previousDayDateStartTime24hrs>' and personEmpTerminationInfoNav/latestTerminationDate le datetimeoffset'<previousDayDateTime24hrs>') or
(employmentNav/userNav/lastModifiedDateTime ge datetimeoffset'<LastExecutionTimestamp>' and employmentNav/userNav/lastModifiedDateTime le datetimeoffset'<CurrentExecutionTime>'))
&$expand=employmentNav/userNav,employmentNav/jobInfoNav,personalInfoNav,personEmpTerminationInfoNav,phoneNav,emailNav,employmentNav/userNav/manager/empInfo,employmentNav/jobInfoNav/companyNav,employmentNav/jobInfoNav/departmentNav,employmentNav/jobInfoNav/locationNav,employmentNav/jobInfoNav/locationNav/addressNavDEFLT,employmentNav/jobInfoNav/locationNav/addressNavDEFLT/stateNav&customPageSize=100

採用前処理のしくみ

このセクションでは、SAP SuccessFactors コネクタで事前採用レコード (採用日/将来の開始日が設定されている従業員) がどのように処理されるかについて説明します。 たとえば、2023 年 6 月 1 日の開始日が設定された employeeId "1234" を持つ事前採用者が SuccessFactors Employee Central に存在するとします。 さらに、この事前採用レコードが Employee Central または Onboarding モジュールのいずれかで 2023 年 5 月 15 日に最初に作成されたとします。 プロビジョニング サービスが (完全同期または増分同期の一部として) 2023 年 5 月 15 日にこのレコードを最初に観察したとき、このレコードは引き続き事前採用の状態です。 このため、SuccessFactors では、そのユーザーに関連付けられているすべての属性 (例: userNav/username) をプロビジョニング サービスに送信しません。 companyName、personIdExternal、firstname、lastname、startDate などのユーザーに関する最小限のデータのみが使用できます。 事前採用者を正常に処理するには、次の前提条件を満たす必要があります。

1. personIdExternal 属性はプライマリ照合識別子 (結合プロパティ) として設定する必要があります。 別の属性 (例: userName) を結合プロパティとして構成した場合、プロビジョニング サービスでは事前採用者の情報を取得できません。
2. startDate 属性を使用でき、その JSONPath を $.employmentNav.results[0].startDate または $.employmentNav.results[-1:].startDate に設定する必要があります。
3. 事前採用レコードは、Employee Central で 'active' (t)、'inactive' (f)、または 'active_external_suite' (e) のいずれかの状態である必要があります。 これらの状態の詳細については、SAP サポート ノート 2736579 を参照してください。

完全/増分同期またはオンデマンド プロビジョニング中に、プロビジョニング サービスで事前採用レコードが検出されると、"asOfDate" フィルターがユーザーの startDate (例: asOfDate=2023-06-01) に設定された次の OData クエリが SuccessFactors に送信されます。

https://[SuccessFactorsAPIEndpoint]/odata/v2/PerPerson?$format=json&$
filter=(personIdExternal in '1234' and employmentNav/userNav/status in 't','f','e')&asOfDate=2023-06-01&$
expand=employmentNav/userNav,employmentNav/jobInfoNav,personalInfoNav,personEmpTerminationInfoNav,phoneNav,emailNav,employmentNav/userNav/manager/empInfo,employmentNav/jobInfoNav/companyNav,employmentNav/jobInfoNav/costCenterNav,employmentNav/jobInfoNav/divisionNav,employmentNav/jobInfoNav/departmentNav,employmentNav/

事前採用者の処理に関する問題が発生している場合は、上の OData 要求形式を使用して、API エンドポイントを置き換える SuccessFactors インスタンスに対してクエリを実行します。personIdExternal と asOfDate をテスト シナリオに対応する値でフィルター処理します。

属性データの読み取り

Microsoft Entra プロビジョニング サービスにより SuccessFactors のクエリが行われ、JSON の結果セットが取得されます。 JSON の結果セットには、Employee Central に格納されている多くの属性が含まれています。 既定では、プロビジョニング スキーマは、これらの属性のサブセットのみを取得するように構成されています。

さらに属性を取得するには、次の手順に従います。

1. [エンタープライズ アプリケーション] ->[SuccessFactors アプリ] ->[プロビジョニング] ->[Edit Provisioning](プロビジョニングの編集) ->属性マッピング ページを参照します。

2. 下にスクロールし、 [詳細オプションの表示] をクリックします。

3. [SuccessFactors の属性リストを編集します] をクリックします。

   Note

   [SuccessFactors の属性リストを編集します] オプションが Microsoft Entra に表示されない場合は、URL https://portal.azure.com/?Microsoft_AAD_IAM_forceSchemaEditorEnabled=true を使用してページにアクセスします。

4. このビューの [API 式] 列には、コネクタによって使用される JSONPath 式が表示されます。

   

5. 既存の JSONPath 値を編集するか、有効な JSONPath 式を使用して新しい属性をスキーマに追加することができます。

次のセクションでは、JSONPath 値の編集に関する一般的なシナリオの一覧を示します。

さまざまな HR シナリオの処理

JSONPath は、XML 用の XPath に似た JSON 用のクエリ言語です。 XPath と同様に、JSONPath を使用すると、JSON ペイロードのデータの抽出とフィルター処理を行うことができます。

JSONPath 変換を使用すると、Microsoft Entra プロビジョニング アプリの動作をカスタマイズして、カスタム属性を取得し、再雇用、作業者変換、グローバル割り当てなどのシナリオを処理することができます。

このセクションでは、次の HR シナリオ用にプロビジョニング アプリをカスタマイズする方法について説明します。

• 追加属性の取得
• カスタム属性の取得
• 雇用状態をアカウントの状態にマッピング
• 作業者の転換と再雇用のシナリオの処理
• 現在のアクティブな雇用レコードの取得
• グローバル割り当てシナリオの処理
• 同時実行ジョブのシナリオの処理
• 位置の詳細の取得
• Onboarding モジュールでのユーザーのプロビジョニング
• SuccessFactors での OData API 監査ログの有効化

追加属性の取得

既定の Microsoft Entra SuccessFactors プロビジョニング アプリ スキーマには、90 以上の定義済み属性が付属しています。 プロビジョニング スキーマに SuccessFactors 属性をさらに追加するには、次の手順を使用します。

1. OData クエリを使用して、Employee Central から有効なテスト ユーザーのデータを取得します。

    https://[SuccessFactorsAPIEndpoint]/odata/v2/PerPerson?$format=json&
    $filter=(personIdExternal in '[personIdExternalValue]')&
    $expand=employmentNav/userNav,employmentNav/jobInfoNav,personalInfoNav,personEmpTerminationInfoNav,
    phoneNav,phoneNav/phoneTypeNav,emailNav,employmentNav/jobInfoNav/businessUnitNav,employmentNav/jobInfoNav/companyNav,
    employmentNav/jobInfoNav/companyNav/countryOfRegistrationNav,employmentNav/jobInfoNav/costCenterNav,
    employmentNav/jobInfoNav/divisionNav,employmentNav/jobInfoNav/departmentNav,employmentNav/jobInfoNav/jobCodeNav,
    employmentNav/jobInfoNav/locationNav,employmentNav/jobInfoNav/locationNav/addressNavDEFLT,employmentNav/jobInfoNav/payGradeNav,
    employmentNav/empGlobalAssignmentNav,employmentNav/empGlobalAssignmentNav/assignmentTypeNav,employmentNav/jobInfoNav/emplStatusNav,
    employmentNav/jobInfoNav/employmentTypeNav,employmentNav/jobInfoNav/employeeClassNav,employmentNav/jobInfoNav/eventReasonNav
   

2. 属性に関連付けられている Employee Central エンティティを確認します

   • 属性が EmpEmployment エンティティの一部である場合は、employmentNav ノードの下で属性を探します。
   • 属性が User エンティティの一部である場合は、employmentNav/userNav ノードの下で属性を探します。
   • 属性が EmpJob エンティティの一部である場合は、employmentNav/jobInfoNav ノードの下で属性を探します。

3. 属性に関連付けられた JSON パスを作成し、この新しい属性を SuccessFactors 属性のリストに追加します。

   • 例 1: employmentNav エンティティの一部である okToRehire 属性を追加し、JSONPath $.employmentNav.results[0].okToRehire を使用するとします
   • 例 2:userNav エンティティの一部である timeZone 属性を追加し、JSONPath $.employmentNav.results[0].userNav.timeZone を使用するとします
   • 例 3: jobInfoNav エンティティの一部である flsaStatus 属性を追加し、JSONPath $.employmentNav.results[0].jobInfoNav.results[0].flsaStatus を使用するとします

4. スキーマを保存します。

5. プロビジョニングを再開します。

カスタム属性の取得

Microsoft Entra SuccessFactors プロビジョニング アプリでは、次のカスタム属性が既定で事前に定義されています。

• User (userNav) エンティティからの custom01 - custom15
• empNavCustomString1 - empNavCustomString15 と呼ばれる、EmpEmployment (employmentNav) エンティティからの customString1 - customString15
• empJobNavCustomString1 - empNavJobCustomString15 と呼ばれる、EmpJobInfo (jobInfoNav) エンティティからの customString1 - customString15

たとえば、Employee Central のインスタンスで、EmpJobInfo の customString35 属性に、場所の説明が格納されているとします。 この値を Active Directory の physicalDeliveryOfficeName 属性にフローさせるものとします。 このシナリオの属性マッピングを構成するには、次の手順を使用します。

1. SuccessFactors の属性リストを編集して、empJobNavCustomString35 という名前の新しい属性を追加します。
2. この属性の JSONPath API 式を次のように設定します: $.employmentNav.results[0].jobInfoNav.results[0].customString35
3. Microsoft Entra 管理センターでマッピングの変更を保存して再読み込みします。
4. 属性マッピング ブレードで、empJobNavCustomString35 を physicalDeliveryOfficeName にマップします。
5. マッピングを保存します。

このシナリオの拡張:

• custom35 属性を User エンティティからマップする場合は、JSONPath $.employmentNav.results[0].userNav.custom35 を使用します
• customString35 属性を EmpEmployment エンティティからマップする場合は、JSONPath $.employmentNav.results[0].customString35 を使用します

雇用状態をアカウントの状態にマッピング

既定で、Microsoft Entra SuccessFactors コネクタは、PersonEmpTerminationInfo オブジェクトの activeEmploymentsCount フィールドを使用してアカウントの状態を設定します。 この属性では、次のいずれかの問題が発生する可能性があります。

1. コネクタにより、雇用契約が終了する勤務最終日の 1 日前に、その従業員のアカウントが無効になることがあるという既知の問題があります。
2. PersonEmpTerminationInfo オブジェクトが null に設定されている場合、personEmpTerminationInfoNav オブジェクトが null に設定されたレコードはプロビジョニング エンジンによって除外されるため、終了時の AD アカウントの無効化は機能しません。

これらの問題のいずれかが発生している場合、または雇用状態をアカウントの状態にマッピングしたい場合は、emplStatus フィールドを展開し、emplStatus.externalCode フィールドにある雇用状態コードを使用するようにマッピングを更新できます。 SAP サポート ノート 2505526 に基づき、プロビジョニング アプリで取得できる雇用状態コードの一覧を次に示します。

• A = Active (勤務中)
• D = Dormant (休職中)
• U = Unpaid Leave (無給休暇)
• P = Paid Leave (有給休暇)
• S = Suspended (出勤停止)
• F = Furlough (一時解雇)
• O = Discarded (解雇)
• R = Retired (定年退職)
• T = Terminated (雇用終了)

次の手順を使用して、これらのコードを取得するようにマッピングを更新します。

1. SuccessFactors プロビジョニング アプリの属性マッピング ブレードを開きます。

2. [Show advanced options](詳細オプションの表示) で、[Edit SuccessFactors attribute list](SuccessFactors 属性リストの編集) をクリックします。

3. 属性 emplStatus を見つけ、JSONPath を $.employmentNav.results[0].jobInfoNav.results[0].emplStatusNav.externalCode に更新します。 この更新により、コネクタはテーブル内の雇用状態コードを取得できます。

4. 変更を保存します。

5. 属性マッピング ブレードで、アカウントの状態フラグの式マッピングを更新します。

   プロビジョニング ジョブ	アカウントの状態の属性	マッピング式
   Active Directory ユーザー プロビジョニングに対する SuccessFactors	accountDisabled	Switch([emplStatus], "True", "A", "False", "U", "False", "P", "False")
   SuccessFactors から Microsoft Entra へのユーザー プロビジョニング	accountEnabled	Switch([emplStatus], "False", "A", "True", "U", "True", "P", "True")

6. 変更を保存します。

7. オンデマンド プロビジョニングを使用して構成をテストします。

8. 同期が期待どおりに動作することを確認したら、プロビジョニング ジョブを再起動します。

作業者の転換と再雇用のシナリオの処理

作業者の転換シナリオについて: 作業者の転換とは、既存の常勤従業員を契約社員に、または契約社員を常勤従業員に転換するプロセスです。 このシナリオでは、Employee Central により新しい EmpEmployment エンティティが、同じ Person エンティティに対する新しい User エンティティと共に追加されます。 前の EmpEmployment エンティティの下に入れ子にされていた User エンティティは、null に設定されます。

再雇用シナリオについて: SuccessFactors には、従業員の再雇用を処理するための 2 つのオプションがあります。

• オプション 1: Employee Central で新しい個人プロファイルを作成する
• オプション 2:Employee Central で既存の個人プロファイルを再利用する

HR プロセスでオプション 1 を使用する場合は、プロビジョニング スキーマを変更する必要はありません。 HR プロセスでオプション 2 を使用する場合は、Employee Central により新しい EmpEmployment エンティティが、同じ Person エンティティに対する新しい User エンティティと共に追加されます。

転換または再雇用が発生したときに新しい雇用データが表示されるように、両方のシナリオを処理することができます。 以下のステップを使用してプロビジョニング アプリのスキーマを一括更新します。

1. SuccessFactors プロビジョニング アプリの属性マッピング ブレードを開きます。

2. 下にスクロールし、 [詳細オプションの表示] をクリックします。

3. [Review your schema here](ここでスキーマを確認する) リンクをクリックして、スキーマ エディターを開きます。

   

4. [ダウンロード] リンクをクリックして、編集前にスキーマのコピーを保存します。

   

5. スキーマ エディターで Ctrl + H キーを押して、検索して置換コントロールを開きます。

6. 検索テキスト ボックスに値 $.employmentNav.results[0] をコピーして貼り付けます

7. 置換テキスト ボックスに値 $.employmentNav.results[-1:] をコピーして貼り付けます。 この JSONPath 式では、最新の EmpEmployment レコードが返されます。

   

8. [すべて置換] をクリックしてスキーマを更新します。

9. スキーマを保存します。

10. 上のプロセスでは、すべての JSONPath 式が次のように更新されます。

    • 古い JSONPath: $.employmentNav.results[0].jobInfoNav.results[0].departmentNav.name_localized
    • 新しい JSONPath: $.employmentNav.results[-1:].jobInfoNav.results[0].departmentNav.name_localized

11. オンデマンド プロビジョニングを使用して構成をテストします。

12. 同期が期待どおりに動作することを確認したら、プロビジョニング ジョブを再起動します。

現在のアクティブな雇用レコードの取得

$.employmentNav.results[0] または $.employmentNav.results[-1:] の JSONPath ルートを使用した雇用レコードのフェッチは、ほとんどのシナリオで機能し、構成をシンプルに保ちます。 ただし、SuccessFactors インスタンスの構成方法によっては、コネクタで常に最新のアクティブな雇用レコードがフェッチされるように、この構成を更新する必要がある場合があります。

このセクションでは、ユーザーの現在アクティブな雇用レコードを確実に取得するように JSONPath 設定を更新する方法について説明します。 また、従業員の転換と再雇用のシナリオについても扱います。

1. SuccessFactors プロビジョニング アプリの属性マッピング ブレードを開きます。

2. 下にスクロールし、 [詳細オプションの表示] をクリックします。

3. [Review your schema here](ここでスキーマを確認する) リンクをクリックして、スキーマ エディターを開きます。

4. [ダウンロード] リンクをクリックして、編集前にスキーマのコピーを保存します。

5. スキーマ エディターで Ctrl + H キーを押して、検索して置換コントロールを開きます。

6. 次の検索置換操作を実行します。 検索置換操作を実行するときは、先頭または末尾にスペースがないことを確認します。 [0] ではなく [-1:] インデックスを使用している場合は、それに応じて "検索する文字列" フィールドを更新します。

   検索する文字列	置換に使用する文字列	目的
   $.employmentNav.results[0].jobInfoNav.results[0].emplStatus	$.employmentNav..jobInfoNav..results[?(@.emplStatusNav.externalCode == 'A' || @.emplStatusNav.externalCode == 'U' || @.emplStatusNav.externalCode == 'P' )].emplStatusNav.externalCode	この検索置換では、emplStatusNav OData オブジェクトを展開する機能を追加しています。
   $.employmentNav.results[0].jobInfoNav.results[0]	$.employmentNav..jobInfoNav..results[?(@.emplStatusNav.externalCode == 'A' || @.emplStatusNav.externalCode == 'U' || @.emplStatusNav.externalCode == 'P')]	この検索置換では、アクティブな SuccessFactors EmpJobInfo レコードに関連付けられている属性を常に取得するようにコネクタに指示します。 SuccessFactors で、終了または非アクティブなレコードに関連付けられている属性は無視されます。
   $.employmentNav.results[0]	$.employmentNav..results[?(@.jobInfoNav..results[?(@.emplStatusNav.externalCode == 'A' || @.emplStatusNav.externalCode == 'U' || @.emplStatusNav.externalCode == 'P')])]	この検索置換では、アクティブな SuccessFactors Employment レコードに関連付けられている属性を常に取得するようにコネクタに指示します。 SuccessFactors で、終了または非アクティブなレコードに関連付けられている属性は無視されます。

7. スキーマを保存します。

8. 上のプロセスでは、すべての JSONPath 式が更新されます。

9. 事前採用者処理を機能させるには、startDate 属性に関連付けられている JSONPath で [0] または [-1:] インデックスのいずれかを使用する必要があります。 [Show advanced options](詳細オプションの表示) で、[Edit SuccessFactors attribute list](SuccessFactors 属性リストの編集) をクリックします。 属性 startDate を見つけて値 $.employmentNav.results[-1:].startDate に設定します。

10. スキーマを保存します。

11. 終了が期待どおりに処理されるようにするには、属性マッピング セクションで次のいずれかの設定を使用できます。

    プロビジョニング ジョブ	アカウントの状態の属性	アカウントの状態が "activeEmploymentsCount" に基づいている場合に使用する式	アカウントの状態が "emplStatus" 値に基づいている場合に使用する式
    Active Directory ユーザー プロビジョニングに対する SuccessFactors	accountDisabled	Switch([activeEmploymentsCount], "False", "0", "True")	Switch([emplStatus], "True", "A", "False", "U", "False", "P", "False")
    SuccessFactors から Microsoft Entra へのユーザー プロビジョニング	accountEnabled	Switch([activeEmploymentsCount], "True", "0", "False")	Switch([emplStatus], "False", "A", "True", "U", "True", "P", "True")

12. 変更を保存します。 1.

13. オンデマンド プロビジョニングを使用して構成をテストします。

14. 同期が期待どおりに動作することを確認したら、プロビジョニング ジョブを再起動します。

グローバル割り当てシナリオの処理

Employee Central のユーザーがグローバル割り当てに対して処理されると、SuccessFactors により、新しい EmpEmployment エンティティが追加されて、assignmentClass が "GA" に設定されます。 また、新しい User エンティティも作成されます。 したがって、ユーザーは次のようになります。

• assignmentClass が "ST" に設定されたホーム割り当てに対応する 1 つの EmpEmployment + User エンティティ
• assignmentClass が "GA" に設定されたグローバル割り当てに対応する別の EmpEmployment + User エンティティ

標準割り当てとグローバル割り当てのユーザー プロファイルに属する属性を取得するには、次の手順を使用します。

1. SuccessFactors プロビジョニング アプリの属性マッピング ブレードを開きます。

2. 下にスクロールし、 [詳細オプションの表示] をクリックします。

3. [Review your schema here](ここでスキーマを確認する) リンクをクリックして、スキーマ エディターを開きます。

4. [ダウンロード] リンクをクリックして、編集前にスキーマのコピーを保存します。

5. スキーマ エディターで Ctrl + H キーを押して、検索して置換コントロールを開きます。

6. 検索テキスト ボックスに値 $.employmentNav.results[0] をコピーして貼り付けます

7. 置換テキスト ボックスに値 $.employmentNav.results[?(@.assignmentClass == 'ST')] をコピーして貼り付けます。 演算子を囲む空白に注意してください。これは、JSONPath 式を正常に処理するために重要です。

8. [すべて置換] をクリックしてスキーマを更新します。

9. スキーマを保存します。

10. 上のプロセスでは、すべての JSONPath 式が次のように更新されます。

    • 古い JSONPath: $.employmentNav.results[0].jobInfoNav.results[0].departmentNav.name_localized
    • 新しい JSONPath: $.employmentNav.results[?(@.assignmentClass == 'ST')].jobInfoNav.results[0].departmentNav.name_localized

11. アプリの属性マッピング ブレードを再度読み込みます。

12. 下にスクロールし、 [詳細オプションの表示] をクリックします。

13. [SuccessFactors の属性リストを編集します] をクリックします。

14. 新しい属性を追加して、グローバル割り当てデータをフェッチします。 たとえば、グローバル割り当てプロファイルに関連付けられている部署名を取得する場合は、JSONPath 式を $.employmentNav.results[?(@.assignmentClass == 'GA')].jobInfoNav.results[0].departmentNav.name_localized に設定して属性 globalAssignmentDepartment を追加します。

15. 両方の部署の値を Active Directory 属性にフローさせるか、または式マッピングを使用して値を選択的にフローさせることができます。 例: この式では、AD の department 属性の値が、globalAssignmentDepartment が存在する場合はそれに設定され、存在しない場合は標準割り当てに関連付けられている department に設定されます。

    • IIF(IsPresent([globalAssignmentDepartment]),[globalAssignmentDepartment],[department])

16. マッピングを保存します。

17. オンデマンド プロビジョニングを使用して構成をテストします。

18. 同期が期待どおりに動作することを確認したら、プロビジョニング ジョブを再起動します。

同時実行ジョブのシナリオの処理

Employee Central のユーザーに複数の同時実行ジョブがある場合は、2 つの EmpEmployment エンティティと User エンティティで assignmentClass が "ST" に設定されています。 両方のジョブに属している属性をフェッチするには、次の手順を使用します。

1. SuccessFactors プロビジョニング アプリの属性マッピング ブレードを開きます。
2. 下にスクロールし、 [詳細オプションの表示] をクリックします。
3. [SuccessFactors の属性リストを編集します] をクリックします。
4. たとえば、ジョブ 1 とジョブ 2 に関連付けられている部署を取得するとします。 定義済みの属性 department では、最初のジョブの部署の値が既にフェッチされています。 secondJobDepartment という名前の新しい属性を定義し、JSONPath 式を $.employmentNav.results[1].jobInfoNav.results[0].departmentNav.name_localized に設定します
5. 両方の部署の値を Active Directory 属性にフローさせるか、または式マッピングを使用して値を選択的にフローさせることができます。
6. マッピングを保存します。
7. オンデマンド プロビジョニングを使用して構成をテストします。
8. 同期が期待どおりに動作することを確認したら、プロビジョニング ジョブを再起動します。

位置の詳細の取得

SuccessFactors コネクタでは、位置オブジェクトの展開がサポートされています。 位置オブジェクトのジョブ レベルや位置名などの属性を特定の言語で展開または取得するには、下に示す JSONPath 式を使用します。

Onboarding モジュールでのユーザーのプロビジョニング

SAP SuccessFactors からオンプレミスの Active Directory および Microsoft Entra ID へのインバウンド ユーザー プロビジョニングで、SAP SuccessFactors Onboarding 2.0 モジュールに存在する事前採用者の事前プロビジョニングがサポートされるようになりました。 Microsoft Entra プロビジョニング サービスは、開始日が将来の日付である新しい採用プロファイルを検出すると、SAP SuccessFactors に対してクエリを実行し、状態コードが active、inactive、active_external_suite のいずれかである新規採用者を取得します。 状態コード active_external_suite は、SAP SuccessFactors Onboarding 2.0 モジュールに存在する事前採用者に対応しています。 これらの状態コードの説明については、SAP サポートノート 2736579 を参照してください。

プロビジョニング サービスの既定の動作では、Onboarding モジュールで事前採用者を処理します。

Onboarding モジュールでの事前採用者の処理を除外する場合、プロビジョニング ジョブの構成を次のように更新します。

1. SuccessFactors プロビジョニング アプリの属性マッピング ブレードを開きます。
2. [詳細オプションの表示] で、SuccessFactors の属性リストを編集して、userStatus という名前の新しい属性を追加します。
3. この属性の JSONPath API 式を次のように設定します: $.employmentNav.results[0].userNav.status
4. スキーマを保存して、属性マッピング ブレードに戻ります。
5. [ソース オブジェクト] スコープを編集して、スコープ フィルター userStatus NOT EQUALS を適用します。
6. マッピングを保存し、オンデマンドのプロビジョニングを使用してスコープ フィルターが機能することを検証します。

SuccessFactors での OData API 監査ログの有効化

Microsoft Entra SuccessFactors コネクタは、SuccessFactors OData API を使用して変更を取得し、ユーザーをプロビジョニングします。 プロビジョニング サービスに関する問題が発生し、SuccessFactors から取得されたデータを確認したい場合は、SuccessFactors で OData API 監査ログを有効にできます。 監査ログから Microsoft Entra ID によって送信された要求ペイロードを取得します。 トラブルシューティングを行うには、cURL や Graph エクスプローラーなどのツールでこの要求ペイロードをコピーし、コネクタで使用されているのと同じ API ユーザーを使用するように設定し、SuccessFactors から必要な変更が返されるかどうかを確認します。

書き戻しのシナリオ

このセクションでは、さまざまな書き戻しのシナリオについて説明します。 SuccessFactors でのメールと電話番号の設定方法に基づいて構成方法を推奨します。

電話とメールの書き戻しに対してサポートされるシナリオ

• 書き戻し属性マッピングに電話番号のマッピングがない場合は、メールのみが書き戻しに含まれます。
• Employee Central での新規雇用オンボードの間に、勤務先のメールと電話番号を使用できない場合があります。 オンボードの間に勤務先メールと勤務先電話をプライマリとして設定する必要がある場合は、新規雇用の作成の間に勤務先の電話とメールにダミーの値を設定できます。 しばらくすると、書き戻しアプリによって値が更新されます。

UserID での書き戻しの有効化

SuccessFactors 書き戻しアプリでユーザー オブジェクトの属性を更新するには、次のロジックを使用します。

• 最初のステップとして、変更セットで userId 属性が検索されます。 存在する場合は、SuccessFactors API の呼び出しを行うために "UserId" が使用されます。
• userId が見つからない場合は、personIdExternal 属性の値が既定で使用されます。

通常、SuccessFactors の personIdExternal 属性の値は、userId 属性の値と一致します。 ただし、再雇用や作業者転換などのシナリオでは、SuccessFactors 内の従業員がアクティブと非アクティブの 2 つの雇用記録を持つ場合があります。 そのようなシナリオで、書き戻しによってアクティブなユーザー プロファイルが更新されるようにするには、SuccessFactors プロビジョニング アプリの構成を説明のように更新します。 このように構成すると、コネクタによって認識される変更セットに userId が常に存在し、SuccessFactors API の呼び出しで使用されるようになります。

1. Microsoft Entra ユーザー プロビジョニング アプリに対する SuccessFactors、またはオンプレミス AD ユーザープ ロビジョニング アプリに対する SuccessFactors を開きます。
2. Microsoft Entra ID の extensionAttribute[1-15] に、すべての作業者のアクティブな雇用記録の userId が常に保存されるようにします。 レコードは、SuccessFactors userId 属性を Microsoft Entra ID の extensionAttribute[1-15] にマップします。

   

3. JSONPath の設定に関するガイダンスについては、「作業者の転換と再雇用のシナリオの処理」セクションを参照して、アクティブな雇用レコードの userId 値が Microsoft Entra ID に流れることをご確認ください。
4. マッピングを保存します。
5. プロビジョニング ジョブを実行して、userId の値が Microsoft Entra ID に流れるようにします。

   Note

   オンプレミスの Active Directory ユーザーのプロビジョニングに SuccessFactors を使用している場合は、userId 属性の値がオンプレミスの Active Directory から Microsoft Entra ID に同期されるように Microsoft Entra Connect を構成します。

6. Azure portal で SuccessFactors 書き戻しアプリを開きます。
7. userId の値が含まれる適切な extensionAttribute を、SuccessFactors の userId 属性にマップします。

   

8. マッピングを保存します。
9. [属性マッピング] -> [詳細設定] -> [Review Schema](スキーマの確認) に移動して、JSON スキーマ エディターを開きます。
10. バックアップとしてスキーマのコピーをダウンロードします。
11. スキーマ エディターで Ctrl + F キーを押して、userId のマッピングが含まれる JSON ノードを検索します。ここでは、ソース Microsoft Entra 属性にマップされます。
12. 次に示すように、flowBehavior 属性を "FlowWhenChanged" から "FlowAlways" に更新します。

    

13. マッピングを保存し、オンデマンド プロビジョニングで書き戻しのシナリオをテストします。

電話とメールの書き戻しに対してサポートされないシナリオ

• Employee Central では、オンボードの間に、個人のメールと電話がプライマリとして設定されます。 書き戻しアプリでは、この設定を切り替えることができず、勤務先メールと勤務先電話をプライマリとして設定することはできません。
• Employee Central では、勤務先電話がプライマリとして設定されます。 書き戻しアプリではこれを変更できず、携帯電話をプライマリとして設定することはできません。
• 書き戻しアプリでは、現在のプライマリ フラグの設定を読み取ることはできず、書き込み操作に同じ値を使用することはできません。 属性マッピングで構成されているフラグの値が常に使用されます。

次のステップ

• SuccessFactors から Active Directory へのプロビジョニングを構成する方法を確認する
• SuccessFactors への書き戻しを構成する方法を確認する
• 受信プロビジョニングのサポートされている SuccessFactors 属性に関する詳細情報