Working on SAP Projects to replicate Employee Master Data and Organizational Assignments from Employee Central to S/4HANA On-Premise/ERP/S/4HANA Cloud can at times be quite interesting. Typically, they fall under the umbrella of standard integration processes with straightforward SAP guidelines/documentation; the nature of challenges that emerge can be resolved with minimal effort. At least, that was the impression I had from my previous experience (replicating Employee Master Data to S/4Hana On Premise) until recently.
Replication of Employee Master data from Employee Central to S/4HANA Cloud was the goal of the project this time. It was right up my alley and to back my hunch - the Discover page in Cloud Integration tenant brought up the standard package the scope item JB1. Simple and uncomplicated.
But then every project brings along its own set of challenges and that’s what makes them interesting.
The challenges and complexities on this project helped us realize the importance of the pre-requisites for an EC/S4HC implementation, especially when setting up an external number range for employees because it is a critical decision that needs to be made early in the project. The key here is timing. It must be made prior to any work being done, so the integration can be configured first and then the employees can be replicated over.
High-level overview of the processes. Please note I am not covering anything about Employee Availability and Photo replication in this blog.
Business Requirement:
Establish the standard integration between SuccessFactors and SAP S/4HANA Cloud to integrate the employee record to SAP S/4HANA Cloud.
Systems involved:
- Employee Central: Configure settings following the JB1 guideline.
- Cloud Integration: Copy the standard package and set the required parameters based on the business requirements.
- S/4HANA Cloud: Activate the API using the Communication Arrangement following the JB1 guideline.
Issue Description:
The required configurations and connections are set up among the three systems and the API was activated. But while activating the API (SAP_COM_001) on S/4HANA Cloud, there was an error.
Scenario Description:
There was a twist in the requirements - We needed to set up the number range as external so that we can accept PERNRs coming from Employee Central. While this is a parameter for setting up the integration, it can be easily overlooked since this setting can be changed anytime during the configuration.
During employee data integration from Employee Central to S/4HANA Cloud, this data is being replicated with an internal number range (like 5**). However, we wanted to set up the number range as external so that we can accept PERNRs coming from Employee Central. When we attempted to set up the number range as external (In the Communication Arrangement SAP_COM_0001), we received the following error message (External number range cannot be enabled).
S/4HANA Cloud Employee Replication API
Reason and Analysis:
This parameter could be enabled only for greenfield customers. However, this caused confusion because our system was a greenfield customer, so it must have been possible. But the kicker was that some users were created a few months before in S/4HANA Cloud using the Maintain Employee App.
When the implementation project started to integrate Employee data between Employee Central and S/4HANA Cloud, we could not activate this API in S/4HANA Cloud in the QA System. This stalled the project and we could not move forward. We had multiple discussions and working sessions with SAP. We discovered an inconsistency in the system as entries existed in old persistency as well as new persistency tables.
While a workaround was implemented from the backend with SAP’s help to fix this, there were still some challenges. For example: If we replicate the same user again that existed in old persistency there would be two PERNRs that could never be reused again.
The workaround was strictly not applicable to the Production System. Luckily, our Production System was a brand-new system and we had not used the Import App. Only the initial user exists at that time.
But there remained two unanswered questions: what if my user didn’t exist in the Production System (which is generally done using the Import App). How would I configure JB1 in the system to start the replication from Employee Central? Since the Import app couldn’t be used, the standard process was to be followed (JB1) or we would have the same situation.
We had quite a few internal discussions with the SAP Security expert on exploring options to at least get my user configured in JB1. But without the Import app, it was impossible to achieve. Finally, after a lot of brainstorming– a ray of light appeared at the end of the tunnel. Or maybe two little rays of light emerged in the form of the following options:
- The person with the Initial user had to configure the JB1
- Create a Business user with appropriate roles
The resolution was to proceed with the creation of a Business User and assign the Administrator Role by the Security admin, set up done on the Identity Authentication service (IAS) side to configure the Communication Arrangements to activate API and follow the steps listed in JB1.
I would love to hear from our SAP Community here on the similar experiences with this Standard Integration. Please share your feedback/thought here in the comment. Did you have similar challenges with the external number range and if so, did you used an alternate approach.
I plan to post another blog on my experience with the Availability flow, so please follow my profile for future blog posts.
Thanks for reading and happy blogging!!
- SAP Managed Tags:
6 Comments
