Employee Replication

former_member188995 · ‎08-05-2016

Overview

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 Cloud for Customer. The external system may be SAP ERP, SAP CRM, S/4 Hana or SAP SuccessFactors Employee Central (EC). The replication is unidirectional from the external system into SAP Cloud for Customer.

Employee replication is mediated from an external system to cloud through SAP CPI/PI system.

New service for Employee Replication from an External system (eg: ERP, S4Hana or CRM) to SAP Cloud for Customer.

Replicate Employee from SAP Business Suite

A new replication service is now available for Employees coming in from SAP ERP, S4Hana, CRM system. This new service will directly create/update Employee in SAP Cloud for Customer rather than creating a Replication requests and processing them via background job.

New service for Employee Replication from SuccessFactors Employee Central to SAP Cloud for Customer via CPI as middleware.

Replicate Employee from SAP SuccessFactors Employee Central

How Employee Replication from SAP Business Suite is better than Employee Replication using Intermediate Staging Area from SAP Business Suite.

Direct replication makes it independent of a C4C replication background job so users need not have to wait for the job to replicate their user. This even reduces maintenance tasks and C4C administrators need not have to monitor employee replication jobs.

Does that mean existing process of Employee Replication is deprecated?

No, customers can either use this new service for integration or existing replication request service but not both at same time as this might cause data inconsistencies.

How to configure this new service?

From Business configuration perspective, nothing changes, you still need to scope for Employee replication.

Once this scoping is done, you will find new Communication Scenario.

Also, create Communication Arrangement for the same.

Note: New PI mapping CRM_COD_SimplifiedEmployee_Replication_Bulk, ERP_COD_SimplifiedEmployeeReplication, S4_C4C_SimplifiedEmployeeReplication and EC_C4C_SimplifiedEmployeeReplication is delivered for this new service for CRM, ERP, S4Hana and SuccessFactors Employee Central Integration respectively.

Best Practices

To avoid any errors, follow these best practices:

Replicate organization center data from SAP ERP/S4Hana/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

What is the default locking behavior of an employee/user created in C4C?

If an Employee is created via replication service Employee Replication from SAP Business Suite, it will create a locked user by default. The old staging area service Employee Replication using Intermediate Staging Area from SAP Business Suite still creates an unlocked user in C4C. All the future enhancements will be done for the new service only.

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.

Note

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.

What is the difference between Initial load and delta load in SAP CRM Integration?

Initial load	delta load
When	Once First time load of a record from SAP CRM to SAP Hybris Cloud for Customer	Every business day (best practice)
Identifier	ID mapping for Remote Business Partner ID gets created in SAP Hybris Cloud for Customer. If initial load is re-executed on existing Business Partner ID, from SAP Hybris Cloud for Customer point of view, it is a delta load of data (update) for that Employee	ID Mapping for Remote Business Partner already exists
KEY_DATE	Cut-off date for older data to reduce amount of historical data in SAP Hybris Cloud for Customer. Transmission date is Key date – 3 months	Same behavior
Input	Any employee entered as parameter	Only those employees where unprocessed change pointers exist in BDCP2 table
data set	Full record is being transmitted	Full record is being transmitted

execution	We expect customer to provide Business Partner IDs and we fetch data for those BPs and transmit data to SAP Hybris Cloud for Customer	We rely on BDCP2 entries for employee message type. We fetch only those employees for whom the change pointers exist and then transmit data to SAP Hybris Cloud for Customer

Is multiple organization assignment supported as part of ERP integration?

No, currently we support multiple organization assignment for integration between CRM – C4C only.

Background job for processing employee replication request failing continuously.

Usually this type of issue/dumps happen when the system has more load than it can handle. At first please check how many replication requests exist in the system which are in “Not started” state. This can be directly checked from the UI (Administrator Work center).

Additionally, check if there exist duplicate replications in bulk for all employees. If yes, please check your replication strategy from the external system (ERP/CRM/EC).

Replication requests for some of the employees are not getting processed.

This type of issue happens when we try to process a replication request which is in “Past” with respect to the “Last successful” replication request.

This can be checked and verified (from the UI) with the timestamp of the replication request which you are trying to process with that of a replication request which has Current indicator as true (last successful replication). If the new replication request has a timestamp before that of last successful replication, then the new replication request must be marked as irrelevant as it is Outdated.

Background job is getting cancelled.

This can happen in multiple scenarios.

When multiple background jobs are scheduled for employee replication. Here we need to cancel duplicate jobs and let only one job to run.

When there is a manual triggering of background job from UI (Replicate All) which overlaps with the scheduled run.

When the replication request is coming from middleware with “ScheduleProcessDirectlyIndicator” as true which schedules and trigger the job as soon as the Cloud for Customer receives a request. This indicator should always be false.

Business partner exist without any role.

This happens when we try to process an employee for which the business partner exists without any role. It happens when an employee is terminated without even getting replicated to C4C once.

To process such employees please apply the note 2511977 and replicate those terminated employees using a new report ‘crmpcd_terminated_empl_extract’ provided as part of the mentioned note.

Point to Point replication in Employee Central is deprecated.

Starting from 1611, we have introduced HCI mediated service which will periodically query Employee Central system and send asynchronous inbound messages to C4C.

For more information regarding HCI medicated solution please follow this blog.

What all fields gets replicated from SuccessFactors Employee Central to C4C?

We don’t replicate any Job Information or Organization Assignment from Employee Central to C4C as it’s already deprecated so even if it’s available in the payload received at C4C it will not be considered for replication.

We replicate Address, Phone, Mobile and Email Information from Employee Central to C4C only if it’s of type ‘Business’/’business’, ‘B’, ‘CELL’ and ‘B’ respectively.

Mapping Workplace Address node in C4C directly to respective fields in EC will not replicate Address information to C4C as we calculate Workplace Address node based on what data is coming in Address Information, Phone Information and Email Information nodes from EC.

Extension fields are not getting replicated from SuccessFactors Employee Central to C4C?

This hold true if you are extending Employee Replication from SAP SuccessFactors Employee Central web service.

Unlike other extension handling, we need to add that field against two services:

Employee Central Employee Replication - Common Data

Employee Replication - Common Data