In this blog post I shall focus on the first step in the EC-ECP Employee Master Data Replication process. Please refer Part I where I introduce a high-level process flow for this replication and Part II where I share pre-requisites and general tips. For your quick reference, following is the process flow diagram I shared in Part I:
Focus Area: Step 1: ECP Replication Program makes a call to Compound API in EC for employee data.
Please refer the sub-bullet 1 under Business Scenario in consideration section in Part I. While EC (which is system of record for HR master data) shall be going live for the entire employee population of the subject company as on a single date, ECP shall go live by payroll area which might fall on different dates as per their pay period alignments.
One of the critical configurations related to Step 1 is the Compound Employee API Query configuration.
Primary Table: T77SFEC_PTP_CONF
Secondary/Child Table: T77SFEC_PTP_SEGM
These two tables provide input to our replication program as to how to formulate the query for the EC Compound API call.
The first table (T77SFEC_PTP_CONF) has following fields:
Here's an example configuration entry for the pay area A1 of Company ABC LLC from our Business Scenario (refer Part I😞
The second table (T77SFEC_PTP_SEGM) lists out, for each Config ID in the primary table, the portlets whose data is to be fetched from EC. Example portlets that you may consider (and there could be more, especially if you happen to have custom or country-specific EC portlets to replicate):
Next, let's talk about the Last Run Table HRSFEC_PTP_LMOD. This, as expected, is a transactional table. You might want to create a parameter transaction on top of SM30 to maintain this table, unless your SAP security team lets you access SM30 directly. This table will have one entry per Config ID defined in T77SFEC_PTP_CONF and the timestamp in format YYYY-MM-DDTHH:MM:SSZ. When the replication program executes, it queries EC using the last run date in this table to specify since when it wants the data changes to be selected. You will have to reset entry in this table if at any time you want to do a full refresh.
Now, let's talk about selection screen inputs of the employee replication program RP_HRSFEC_PTP_EE_REPLICATION (transaction code: HRSFEC_PTP_EE_REPL).
This covers what all I had planned to share about Step 1. The knowledge matter is a bit intertwined (at least in my head), and I might touch upon some of the above items again in subsequent blog posts. Until then, shubhamastu.
PTP Process Flow Diagram
Focus Area: Step 1: ECP Replication Program makes a call to Compound API in EC for employee data.
Please refer the sub-bullet 1 under Business Scenario in consideration section in Part I. While EC (which is system of record for HR master data) shall be going live for the entire employee population of the subject company as on a single date, ECP shall go live by payroll area which might fall on different dates as per their pay period alignments.
Tip 1: Never ever plan to have EC go live by payroll area. Else, you shall end up breaking the org structure.
One of the critical configurations related to Step 1 is the Compound Employee API Query configuration.
Primary Table: T77SFEC_PTP_CONF
Secondary/Child Table: T77SFEC_PTP_SEGM
These two tables provide input to our replication program as to how to formulate the query for the EC Compound API call.
The first table (T77SFEC_PTP_CONF) has following fields:
- Config ID: I suggest you use following naming convention <Company Code>_<Payroll Area>. Thus, you shall have one config entry per pay area. This is because you will potentially have different go live for each pay area. Instead of Company Code as prefix (if there are multiple company codes for a company) you may come up with a unique code to identify each company in your landscape. Say, 1, 2, etc. or A, B, etc.
- Config. name: A descriptive name to identify this configuration.
- Company: List the applicable company codes for this configuration with comma as separator. In a multi-tenant environment, this will be critical entry.
- Country: E.g., USA for United States, CAN for Canada. These values are determined by EC picklist values for country. Avoid combining multiple countries in one configuration.
- Employee Class: I didn't have to use this field in my project implementation.
- Comp. Pay Group: This shall be the pay area, assuming EC uses the same codes.
- Target System: Not of use. Can be kept blank.
- Full Transmission Start Date: FTSD for short. This is when ECP is going live for the concerned pay area.
- Use as From Date: I had it unchecked in my project implementation; EC had fresh employee records starting as of ECP FTSD for the critical portlets such as, job information, compensation information, etc.
- Mult. Actions: I had it checked; thus accepting more than one action on a given date (which will go into Infotype 302).
- Ext. Cost Center: I had it checked.
Here's an example configuration entry for the pay area A1 of Company ABC LLC from our Business Scenario (refer Part I😞
Sample Config Entry
Tip 2: If you recollect in the earlier post, I had mentioned that you will need a custom program to directly update Full Transmission Start Date (FTSD) in the config table T77SFEC_PTP_CONF. The reason behind this is that, with multiple rounds of testing in lower environments (Dev and QA), where-in you might have different FTSDs which align with the most preferred pay periods for your testing, you will end up updating FTSD in config transports multiple times over until you have the FTSD for Production cutover in the final transport. To avoid having to do multiple transports, you can build a custom program which takes Config ID and FTSD as input, and directly updates the config table T77SFEC_PTP_CONF record's FTSD field value. You can then have this program execution to "fix" the FTSD as a task in your cutover plan prior to switching on the replications.
The second table (T77SFEC_PTP_SEGM) lists out, for each Config ID in the primary table, the portlets whose data is to be fetched from EC. Example portlets that you may consider (and there could be more, especially if you happen to have custom or country-specific EC portlets to replicate):
person
personal_information
address_information
phone_information
email_information
person_relation
employment_information
job_information
compensation_information
paycompensation_recurring
paycompensation_non_recurring
payment_information
accompanying_dependent
alternative_cost_distribution
job_relation
direct_deposit
national_id_card
deduction_recurring
deduction_non_recurring
global_assignment_information
ItDeclaration
dependent_information
personal_documents_information
associated_employee_information
emergency_contact_primary
Next, let's talk about the Last Run Table HRSFEC_PTP_LMOD. This, as expected, is a transactional table. You might want to create a parameter transaction on top of SM30 to maintain this table, unless your SAP security team lets you access SM30 directly. This table will have one entry per Config ID defined in T77SFEC_PTP_CONF and the timestamp in format YYYY-MM-DDTHH:MM:SSZ. When the replication program executes, it queries EC using the last run date in this table to specify since when it wants the data changes to be selected. You will have to reset entry in this table if at any time you want to do a full refresh.
Tip 3: When the replication program executes the first time, there will obviously be no entry in this table for the concerned config id. I've noticed that in such a situation, when the replication program doesn't query with a last run date, EC's Compound Employee API returns records since the last EC conversion data load. Now, if your EC team had performed multiple conversion data loads before EC-ECP Replications are turned ON, you might miss replicating some earlier loaded employee data. Thus, it would be advisable to enter an old date (such as 1 month before your EC go live date) in the Last Run Table HRSFEC_PTP_LMOD before turning ON the EC-ECP Replications.
Now, let's talk about selection screen inputs of the employee replication program RP_HRSFEC_PTP_EE_REPLICATION (transaction code: HRSFEC_PTP_EE_REPL).
- Configuration ID: It's the same Config ID that you entered in table T77SFEC_PTP_CONF. It's a mandatory input field. This means, you can replicate employee population corresponding to only one Config ID at a time.
- External Employee ID: This is an optional field. You shall enter a value only if you want to replicate ad hoc for a single employee due to some error corrections. The External Employee ID (aka "Person ID External") in most instances will be same as PERNR. However, it can be different when you have an individual who has multiple PERNRs (that is, someone who has worked for multiple companies in your multi-tenant landscape.) For such cases, the first PERNR the employee had in the system will be the External Employee ID and all remaining PERNRs will be linked to the same External Employee ID. In a way, this is SuccessFactors EC equivalent of Central Person Object in ECC. For more information on different IDs in SuccessFactors EC, refer SAP KBA 2493579.
Tip 4: When you search for employees in SuccessFactors EC Search Toolbar, you typically search using peoples' names. However, if you search by PERNR, do remember that it's not the PERNR but the External Employee ID or Person ID External that you are looking up. This is critical to know when you have employees with more than one PERNR. The same will happen in ECP, when you are browsing the SLG1 Application Log. More of that in a later blog post when I discuss about SLG1.
Tip 5: In production, you shall run this replication program as a background job with a set frequency (say, hourly, and at a time different from the OM replication job). Since the program validates that there are no simultaneous runs, it would be advisable to have all executions of this program (one for each Config ID) as individual steps in the same background job to avoid any overlap runs.
This covers what all I had planned to share about Step 1. The knowledge matter is a bit intertwined (at least in my head), and I might touch upon some of the above items again in subsequent blog posts. Until then, shubhamastu.
- SAP Managed Tags:
12 Comments
