This document will cover the basic steps for BIB config and Enhancements available in a   Hybrid Employee central to SAP on premise integration scenario.

We will explore customization of below replication data.

• Organization Integration.
• Employee Integration
• Cost center Replication

There will few Tips and Tricks at the end of session.

This document will be useful for those who has never worked in BIB replication. They can read this document to get an overall idea about BIB replication process.

Overall Architecture

In most of the projects, EC data needs to replicated to SAP system from Employee central.

Employee data and Org data can be sent both way between SFEC and SAP via CPI. But generally, data replicated from SFEC to SAP. So that it can be used in payroll processing in SAP system.

Success factor Employee central should be system where Master data changes must be done and then data needs to be replicated to ECC.

In few cases, some org data and employee org related data needs to be sent from SAP to Success factor Employee central. But these are rare cases.

Cost center replication is unidirectional. Data sent from SAP ECC to SFEC via CPI.

SPRO

This is the place in SPRO where all BIB Configs are done.

SPRO

Below are few basic steps needs to be done in the BIB Config.

• We need to create two instance for Employee and org replication.
• Import the metadata from EC to SAP.
• Config the EC entities in SPRO. We can create custom EC entities as per requirement.
• The EC entities are mapped to different portlet in Employee central. For e.g. we have EC entities for personal data, Bank information, Employment information etc.
• We need to config the Value mapping entities. Here we need to map the EC value to its respective SAP value.
• Maintain constant value for replication.

Org Replication

• We need to config the User specific org setting. Basically , we need to configure few T77S0 entries for org replication.
• We can suppress the creation of relation in Emp org assignment replication.
• We need to define the object types for Organization data. Like Org unit, Position, job etc.
• We can modify the EC entities according to user requirement.
• The main step is to create the Transform template group for the org instance. Here we create different template and do the Field mapping. For e.g. for Position we create a template under the template group. Then we map respective fields and info types. Like we need to create IT1001 for object description, 1001 for relationship and etc.

Employee Replication

• We can define additional EC entities as per user requirement.
• We need to similarly create a template group and under that different templates for respective portlets. For e.g. if we need to map the address data , then we need to create a template and assign the EC entitles which brings the Address data.
• We can map the field and the info types in primary mapping. There is also secondary mapping and country specific mapping available. For e.g. if we want different field to be mapped for different country, then it can be done via country specific mapping or secondary mapping.
• We can filter the info type data. If we want to exclude info type for any specific country or subtype, then we can configure in filtering  info type .
• In the Define parameter, we need to map the template group, SAP system and other configuration for replication. This is one of the critical configuration for replication to work.

Org Replication Transactions

Run Transaction SFIOM_QRY_ORG_OBJ. Then provide the template group and object type needs to replicated.

Org replication is two step process to update the database.

Run Transaction code SFIOM_VIEW_ORG_REQS

It will display the object run mentioned in previous slide.

If it is in open status, then click on Process selected request to update the database.

If there is an error, then status will be failed or pending.

Employee Replication Transactions

Run Transaction ECPAO_EE_ORG_QUERY

Then provide the template group and Employee id to be replicated.

• If we provide the change date in the selection screen, then it select the data from ECC after the change date. Other wise it will select the data to be compared with EC data from Cut off date.
• IF we checked the payload and verbose logging, then we will get detail data in SLG1. For daily replication, ideally the verbose logging is not checked. It is only used in case of any critical issue analysis.
• Test mode will not update anything in the database.

Employee Org Relationship replication

Employee position and relationships won’t be updated after org replication and employee replication.

We need to run the Transaction SFIOM_VIEW_REQUESTS and process the employee record, so that position gets updated in Info type 0001 and Relationship A008 is created in org side.

Cost Center Replication

• Activate Change pointers for Message Type – ODTF_CCTR (Transaction Code BD50)
• Whenever there is change in Cost center, then IDOC will be created.
• Program ODTF_REPL_CC sends the Cost center data from ECC to EC.
• For delta scenario – Variant need to be sent for original program with delta replication and RBDMIDOC sends the delta changes to EC.

Data Migration and Jobs

• We need to determine the cutoff date of a project and send all valid data on cut off date to EC.
• Historical data is not sent from SAP to EC. Generally, the latest data is sent to EC.
• There is a migration team for each integration project. We have DCM Tool which sends the data from SAP to EC based on client requirement.
• Then we need to schedule the Employee, org replication jobs which I mentioned in earlier slides.
• We do not give any specific objects for daily run.
• It runs in delta mode. IF there is any change in EC, then data come to SAP. Then SAP compares the data from cut off date. If it founds any change, then it updates the database.

 BADI

There are many custom enhancements generally done in BIB replication.

Below are the BADI used for various purposes .

The Change info type BADI is the place where majority of customizations are done.

This BADI will be called for each info type. It will bring the Info type data retrieved from EC after filtering through all the custom setting. Here we can modify the data and write our own logic.

PNNN_PRIMARY_TAB contains the Info type data, and it needs to be changes.

Below BADI is used to map employee number and central Person ID field from EC to SAP

Here we can write specific logic for special cases of Rehire, Transfers etc.

Below BADI prevents overwriting of Additional Action

Below BADI is triggered during Employee org assignment.

We can do customization like changing the end date for contractor, create specific relationship during Employee org relationship replication

Below BADI used to customize Cost Center replication

BADI ODTF_CO_REPL_IDOC_COST_CENTERS

Troubleshooting

We use Transaction SLG1, SRT_UTIL, SRT_MONI for analysis of any issue.

Employee – Object ECAPAO_IN

Org – PAOC_SFI_OM

All SOA Manager and web service-related issues can be monitored in SRT_MONI Error log.

In SLG1 verbose log contains information like What are the info types updated for the employee, What is data we get from EC payload, What is the data after Transformation. These data is very helpful in Analysis.

Whenever we get any error, ABAP team put break point on custom BADI and debug the issue.

If there is any code issue, it needs to resolved by ABAP team. If it is a standard issue, then there would be in the BIB config or EC config.

Most issues are related to data. Ask Functional team to check the data before handing over for debugging.