This blog gives you an overview and explains the frequently asked questions on the replication of Employee master data from an external system to SAP Hybris Cloud for Customer. The external system may be SAP ERP, SAP CRM or SAP SuccessFactors Employee Central (EC). Also, the replication is unidirectional from the external system into SAP Hybris Cloud for Customer (Cloud). Employee replication is mediated from SAP CRM/SAP ERP to Cloud through SAP HCI/PI system, whereas the EC integration is a point-to-point integration.
Once you scope and configure for Employee replication in SAP Hybris Cloud for Customer, a background job is scheduled by default to run every day. This job reads the employee replication requests received in the staging area and creates employees in SAP Hybris Cloud for Customer.
It is important that a SAP Hybris Cloud for Customer administrator looks into the failed requests in Employee Staging, and either corrects the issue or marks the request as irrelevant.
To avoid any errors, follow these best practices:
- Replicate organization center data from SAP ERP/CRM and only then replicate employees. Otherwise, employee replication will fail due to missing organizations.
- Use employee replication interface to replicate employees, instead of business partner replication interface.
- To minimize replication errors, employees from Employee Central should be sent to SAP Hybris Cloud for Customer through an initial load. This creates an organization center hierarchy in SAP Hybris Cloud for Customer, minimizing replication errors.
Frequently Asked Questions
Is it possible to replicate business partners with employee role, if the BP has already been replicated with some other role?
If a Business Partner (BP) is replicated as contact/customer to SAP Hybris Cloud for Customer, it is not possible again to replicate the same BP as employee.
Error: A FATAL EXCEPTION is raised for instance sharing scenario.
What is the significance of Employee Type in replication? Give an example use case where employee replication is affected due to Employee Type Validity?
Employee Type data contains information on the duration of employee’s validity in the system. Say an employee is terminated in CRM/ERP, and Employee Type Validity end date will have termination date of an employee. If employee is sent to Cloud for Customer, whose validity date extends beyond the termination date, then the employee is set to inactive and his user is locked in Cloud for Customer.
Most common use case where employee replication fails is because organization assignment validity is extended beyond employee type validity.
Error Text: “Assigned employee <EMP_NAME> is not valid from <DATE> to <DATE>”.
Can we use business partner service interface to replicate employees from CRM to Cloud for Customer?
BP service interface should not be used to replicate employees. Instead, use Employee replication service to replicate employees from ERP/CRM.
How to manage employee replication background job?
Background job is scheduled only when employee replication is scoped. By default, it is scheduled to run once a day, but a key user can re-schedule the job as required. It is recommended not to configure it to run on “Single Run” or “Start Immediately” option. By doing so, the background job schedule instance moves to “Completed” status and re-run will not be possible. In such a case, an incident is required to create Background job schedule from backend.
What are the steps to migrate employees using migration template?
Follow these steps to replicate employees using a migration template:
- Navigate to Data Integration Complete Employee Master Data Replication work center view.
- To launch Migration workbench, click Actions Upload Complete Data.
- Download migration template from the launched view.
- Follow these guidelines while filling the template:
- On the Grouping tab, make an entry in key column “File Creation Date Time” in the format “YYYY-MM-DD hh:mm:ss”.
- On the other tabs, maintain the same value for “File Creation Date Time”.
- In the “Person ID Type” column, enter the value “1” for ERP remote employee ID, or “2” for CRM business partner remote ID.
- Upload the filled template using migration workbench.
- After the data is successfully uploaded, navigate to Data Integration Complete Employee Master Data Replication work center view.
- Verify the data is loaded into staging.
Can we replicate private address of an employee to C4C?
Employee view in Cloud for Customer shows work place address and not private address. Hence, private address is not replicated.
How is ID mapping used in employee replication?
On replication, Cloud for Customer maintains a mapping between employee IDs in the external system and the Cloud for Customer system.
When an employee is replicated, the replication service checks the existence of external ID in this ID mapping. If external ID is not found,
it creates a new employee in Cloud for Customer, else if it finds the mapping, it updates existing employee data.
Is it possible to send an employee without organization assignments? What are the common failure use cases around org-assignments to employee?
Yes, it is possible to replicate an employee without org-assignment.
Most common issues around org-assignments to employee are that the replication fails if:
- An employee assigned to an organizational unit is not replicated to Cloud for Customer.
Error Text: “Remote org unit <REMOTE_ORG_ID> with definition Functional Unit from <REMOTE_SYSTEM> not yet replicated”.
- An org-assignment validity extends beyond employee validity.
Error Text: “Assigned employee <EMP_NAME> is not valid from <DATE> to <DATE>”.
What is complete transmission date in the context of employee replication? And what are unchanged indicator and how do they influence employee replication?
Complete Transmission Start Date (CTSD) is the date from which complete data of an employee is transmitted.
For example, if CTSD is 01.01.2013, then all data of an employee from this date, say Personal Details, Org-assignment, and Workplace Address are transmitted to Cloud for Customer.
Unchanged indicator is provided to restrict modification of data in Cloud for Customer. It is always set to false during initial replication of an employee. Following unchanged indicators can be set on the employee replication request:
- PersonalDetailsUnchangedIndicator: If true, update to Personal details data of employees is restricted.
- WorkplaceAddressUnchangedIndicator: If true, update to Workplace details data of employees is restricted.
- OrganisationalAssignmentUnchangedIndicator: If true, update to Organizational assignment data of employees is restricted.
- EmployeeTypeUnchangedIndicator: If true, update to Employee Type data of employees is restricted.
- IdentityUnchangedIndicator: If true, update to Identity data of employees is restricted.
Which attributes are mandatory for employee replication?
Following attributes are mandatory to successfully replicate employees to Cloud for Customer.
- Business System ID
Error Text: “Remote system instance ID missing”
- Remote Employee ID/Business Partner Remote ID
Error Text: “Remote employee ID or Remote business partner ID missing”.
- Last Name of an Employee
Error Text: “Last Name mandatory. Enter last name”.
- Employee Type data
Error Text: “Employee type missing for remote employee <REMOTE_ID> from <REMOTE_SYSTEM>”.
What are the effects of changing business system after the initial load of employees to Cloud for Customer?
When employees are replicated from an external system, ID mappings (Remote ID – Local ID) are maintained in Cloud for Customer, with respect to a business system from where an employee is replicated. If the business system changes after the initial load, all employees are again created in Cloud for Customer.
In case if such a situation arises where a business system has to be changed after initial load, then first update the business system in ID mapping for all the employees. This could be done either by Data Workbench or ID mapping download/upload utility.
Once the existing ID mappings are updated with new business system, employee will not get duplicated in the Cloud for Customer system.
How are the employees from staging processed? Is it in sequential or parallel processing mode?
Employees from the staging are processed via background job in parallel processing mode. Employees from external system are sent in packets to Cloud for Customer employee staging. The processing of employee replication request also happens in packets, and in a packet if one replication fails the entire packet will fail to replicate in parallel processing mode. Packet with failed replication request will be processed in sequential mode.
Can an IDOC have multiple instances of the same employee?
An IDOC will not have multiple instances of the same employee.
How to configure Cloud for Customer to integrate with Employee Central.
Please refer the following document on SAP Service Marketplace: INTEGRATION: EC Service Center + Cloud for Customer
• INTEGRATION with Employee Central – Mappings at Field Level
Which attributes of Employee Central are mapped to attributes in Cloud for Customer?
Please refer the following document on SAP Service Marketplace: INTEGRATION with Employee Central – Mappings at Field Level
Is it possible to assign same user ID to different employees in Cloud for Customer?
For every employee replicated, business user is created with a unique user ID. Same user ID cannot be shared or multiple employees cannot have same user ID. It is possible to update the user ID in Cloud for Customer but again it should not be assigned to some other user.
Error Text: “An identity with the same ID <USER_ID> (<Employee Name>) already exists”.
Can we use attribute “ScheduleProcessingDirectlyIndicator” to process employee replication request immediately?
Please do not use this attribute as it is not supported. Instead the workaround is to schedule the employee replication background job to run at shorter intervals of time like every hour or two.
How to ensure that employee replication is working fine?
Key user or administrator needs to regularly monitor the employee replication job and employee staging for the failed jobs or failed replication requests. For every failed request, look at the error and take the necessary action either by correcting the data in the staging or by marking it as irrelevant, if the data is outdated.
Why is Employee staging view failing to load the data?
This issue usually occurs if there is any inconsistency in FSI. By FSI reload it should get resolved.
If your issue is still not resolved, then please raise an incident for SAP Support. Also, please send the following information in the incident:
• Problem description
• Steps to reproduce
• Cloud for Customer Message ID
• IDoc number from ERP/CRM.