Employee Central to SAP HCM Integration – Under the hood

Introduction

When SAP HCM customers move to SuccessFactors Employee Central (EC) for global HR purposes, they break their core HR process of Hire to Pay into two systems. The process now becomes “Hire in EC” and “Pay in SAP HCM”. An employee hired in EC makes her way into HCM via an integration that SAP calls the Core Hybrid integration – the core HR process of Hire to Pay is delivered with a hybrid of EC and SAP HCM. This blog follows the journey of an employee from SuccessFactors to SAP HCM.

Employee data flows form EC to HCM

Employee data flowing from EC to HCM is made possible by the following architecture.

Image Copyright: INTEGRTR GmbH

1. On a scheduled time of the day, a job on SAP wakes up to trigger off a series API calls to replicate changes on Employee Central (employee and OM objects) into SAP.
2. The job, represented by an SAP report, calls an async API on SAP Cloud Platform Integration (CPI). Whilst doing so, it presents CPI with all the necessary parameters in terms of the information to fetch, the where clause, the last run date etc., to make a call to SF.
3. SAP Cloud Platform Integration (CPI) is the cloud middleware from SAP that orchestrates the whole integration between the cloud and the on premise worlds. The API call made in the previous call is served by CPI. The API front ends an IFlow* that batches and issues API calls to SuccessFactors.
   * There’re different iFlows for Employee and OM.On SuccessFactors, the venerable Compound Employee API – the source API of all employee data and changes. On the OM side, it’s supplanted by OData APIs.A sample call made against Compound Employee API to fetch all German employees from SF starting Jan 1st 2020.
   SELECT
address_information,
alternative_cost_distribution,
compensation_information,
dependent_information,
employment_information,
job_information,
national_id_card,
paycompensation_non_recurring,
paycompensation_recurring,
payment_information,
person,
personal_information
FROM
CompoundEmployee
WHERE
replicationTargetSystem = 'ERPCLNT200' AND replicationContentType = 'EMPLOYEE_MASTER_DATA' AND company_territory_code IN ('DEU') AND
selectFromDate = to_date('2020-01-01','yyyy-MM-dd') AND isContingentWorker IN ('0') AND
effective_end_date >= to_date('2020-01-01') ​
   Fun fact: Compound Employee API is the only SOAP API in the SuccessFactors API arsenal. The rest of them are well, ReSTful in nature.
4. The response from these APIs are transformed, only a wee bit infact*, and is then relay across to SAP HCM via an on premise agent called the SAP Cloud Connector.* The response from SF is almost entirely sent across to SAP. Only a few header parameters are added for audit and security reasons.SAP Cloud Connector is a reverse proxy tunnel. Sitting in the DMZ of the customer, it allows secure connections to the SAP HCM system without having to open up any ports or additions to the allow list on the firewall.
5. On the SAP side, the receiving end of this call, is a SOAP web service. The proxy of the SOAP service is the beating heart of the whole integration. In case of employee replication, the proxy spins off a background RFC and queues it up into the bgRFC queue for processing. When the bgRFC gets processed the entire machinery of Business Integration Builder (BIB, part of SAP’s PA_SE_IN add-on) comes to bear and, when all goes as planned, settles the call into infotypes and subtypes.
6. In case of OM, the call ends up a staging area. A subsequent report flushes the same into PD infotypes of HRP1000 and HRP1001. The design deviation for OM is because of the way OM is structured – objects and relationships. If one of the objects is missing, the DB update to relationships can go wrong. Hence, all the objects are collated into a staging table to begin with and then are flushed into DB in a go.

Design take-aways

1. The integration architecture espouses the asynchronous design as a norm with the SF API calls being the only exception.
   1. SAP calls CPI and sleeps
   2. CPI batches and calls SF API in a sync mode and forwards the response to SAP HCM and moves on with the next batch.
   3. The web services receiving this information on SAP is also async in nature. In case of employee it spins off a thread with the bgRFC call and in case of OM, the OM object is persisted into a database table with very few or no business logic checks.
2. The async nature of the architecture builds resilience into the whole infrastructure. A common characteristic of a hybrid landscape is the diverse nature of the APIs and infrastructure involved. The API on the SAP HCM landscape is limited in terms of resources it can marshal on the go; on premise components, be it the cloud connector or the SAP HCM system, can never compete with the infinite scaling micro service infrastructures of CPI or SuccessFactors. The SAP HCM systems runs in its own pace and its cloud counterparts in their own. The async architecture allows for this luxury.
3. Usage of SAP Cloud Connector (CC), a custom-tailored reverse proxy tunnel. Called the “reverse invoke proxy” by SAP, it safely connects on premise assets to SAP Cloud Platform. On premise assets as a phrase is important as the CC can be used not just to connect SAP ERP/S4HANA systems but also to connect to on prem. LDAP, other http and off recently even SQL databases over JDBC connection. There’re other ways to securely connect SAP CP to the on premise world – but none that’s so easy to setup and scale.
4. Usage of CPI as a pass through: CPI is great middleware. It can do many things. Process orchestration, data transformation, integration what not.But, the EC to HCM architecture cleverly uses CPI mainly as a secure data pass-through pipe that behaves like a message broker – queuing and batching calls. All the transformation is done on the ABAP side using the Business Integration Builder (BIB) infrastructure. For an ABAP heavy HCM consulting landscape, this is a welcome departure from the earlier middleware heavy integration (< PA_SE_IN SP18).Furthermore, since the CPI process is offered in a “customizing only” mode and all customizing is now moved to the ABAP side, SAP can now push quarterly updates to customers without worrying about breaking a working integration.
5. Usage of CPI in a pub-sub mode: When a new employee is hired on EC, the new hire event is passed on to the subscriber in CPI. This is the the “push” notification to bring new hires and other similar life cycle events almost near instantaneously to SAP HCM.
6. Sticking to SOAP on SAP HCM side: The lowest ECC release that the add-on PA_SE_IN supports is the ECC 6.0 (+SPxx). ECC6.0 is atleast 12 years old. ECC6.0’s BASIS/NW release doesn’t support the newer API capabilities like ODATA and the ReSTFul programming model. SOAP has been around as an inherent part of the core Netweaver release and it requires no additional software components. If you choose to look through the obvious warts, it provides robust service connectivity once setup. Digital transformation should not come at the cost of upgrading existing on premise infrastructure – especially when cloud is the way ahead.
7. Customers often ask: if EC to EC Payroll can be done point to point, why not EC to SAP ERP HCM? Much of the argument from the previous point holds good here too. EC and EC Payroll are both hosted on SAP data centers and SAP ensures that they’re at the latest and greatest of the technology components thus accommodating newer integration models and architectures. This is not the case for all SAP HCM customers. It’s true that a lot of customers are on the latest and the greatest of the stacks dished out by SAP, but there’re always customers who are still on that particular older release of SAP HCM. For the vendor in SAP that’s trying to build a one-size-fits-all solution, the PA_SE_IN add-on architecture is a design trade-off.

To conclude, there’s a lot going on in the EC to HCM integrations. Owning to its design trade-offs, it has its fair share of caveats. But on a whole it brings a diverse set of systems together to deliver on the promised Hire to Pay scenario. It wouldn’t be wrong to call the design an engineering masterpiece,