In Part I blog post, I introduced the overall employee data replication process flow. The flow diagram has been re-shared below for easy reference. In Part II and Part III I covered the pre-requisites and first step in the flow respectively. In this post, I shall share more insights on second, third and fourth steps.
Focus Area: Step 2: EC then responds, in XML format, with first employee data package as per the query request. ECP Replication Program keeps polling EC for subsequent employee data packages until all are received.
Before I elaborate Step 2, let’s come back to Step 1. I had mentioned that ECP queries EC as per the configuration maintained in tables T77SFEC_PTP_CONF and T77SFEC_PTP_SEGM. The Compound Employee API query string for our sample config id 1000_A1 would look like following:
SELECT <all segments you have configured in table T77SFEC_PTP_SEGM with comma separator> FROM CompoundEmployee WHERE replicationContentType = 'EMPLOYEE_MASTER_DATA' AND replicationTargetSystem = 'P01CLNT100' <-- your ECP system id and client AND compensation_pay_group IN ('A1') <-- payroll area(s) from T77SFEC_PTP_CONF AND employment_information_country IN ('USA') <-- country from T77SFEC_PTP_CONF AND employment_information_company IN ('1000') <-- company code(s) from T77SFEC_PTP_CONF AND effective_end_date >= to_date('2020-06-10') <-- FTSD from T77SFEC_PTP_CONF AND last_modified_on >= to_datetime('<last run timestamp>') <-- Last Run timestamp from HRSFEC_PTP_LMOD
The different elements of the SELECT query string are built inside class: CL_HRSFEC_PTP_EE_REPLICATION, method: PROCESS.
NOTE: If you had run the program for a specific Employee ID, then the WHERE clause will have a filter on person_id_external without the last_modified_on addition.
Once you run the replication program, if you go to SLG1 and search for Object ID: HRSFEC, SubObject ID: EMPLOYEE_PTP and External ID: REPLICATION, you shall find this query string in the message list.
The query response has data for a max. of 200 employees in a package. Replication program keeps polling until all data packages are received.
Focus Area: Step 3: For each employee in the data package, ECP Replication Program spawns off a new processing thread so that all replication activities for the concerned employee are contained within that thread, thus reducing data mix-up between employees and limiting impact of any short dumps to the specific employee being processed, while also improving the overall performance.
As each data package is received from EC, ECP replication program initiates processing for each employee in the package, by calling Service Provider EmployeeMasterDataBundleReplicationRequest_In (search for it in SE80 under SAP Package PAOC_PAD_SE_SFEC) where-in it makes RFC call to itself (ECP), spawning a fresh thread for replicating that employee. The RFC Function Module is PROCESS_EE_MDR_INBOUND_RFC, which eventually makes call to Class: CL_HRSFEC_EE_MDR_MAIN, Method: PROCESS_EMPLOYEE.
Tip 1: If you want to debug replication for an employee, you will have to apply external breakpoint in Class: CL_HRSFEC_EE_MDR_MAIN, Method: PROCESS_EMPLOYEE, or a relevant BADI implementation under HRSFEC_CE_MASTER_DATA_REPL.
I shall provide additional insights on the processing logic and BADI implementations in a future blog post.
Tip 2: As each employee of every batch is processed via a Service Provider call and initiation of fresh processing threads, the main replication program doesn’t wait for completion of the call and instead moves onto the next employee to be processed. Thus, we have a true multi-processing architecture, which would only mean that even if the replication job has finished execution, not all employees would have been processed by then. So, before going to SLG1 to get the statistics from your execution run, go to SM50 and confirm there is no processing thread still in execution.
Focus Area: Step 4: ECP Replication Program as a final step, (without waiting for all the threads to complete processing) sends out a confirmation message to EC.
As a final step, the replication program reports a confirmation message to EC. in SLG1 you can review the log under Object ID: HRSFEC, SubObject ID: EMPLOYEE_PTP and External ID: CONFIRMATION.
If everything goes well, you wouldn’t have to monitor SLG1 log entries for REPLICATION and CONFIRMATION messages. What you will truly be working off would be the SLG1 log entries under Object ID: HRSFEC, SubObject ID: EMPLOYEE and External ID: <External Employee ID>. These are message logs generated by the individual threads processing the employee data which we covered in Step 3.
I shall now end this blog post. We shall have more interesting matter such as the custom developments and mappings to discuss in the subsequent blog posts. Until next time, Lokāḥ Samastāḥ Sukhino Bhavantu [a musical rendition on youtube].