Skip to Content
Technical Articles

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: Self (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,

/
8 Comments
You must be Logged on to comment or reply to a post.
  • Nice blog Girish.. there is a bit of ‘staging’ for the PA replication too.. the Org Assignment requests that have to be processed.. I wish it was combined into one step.

  • Hi Girish Bangalore

    this is very useful! I was looking at the numbering scheme (the pale-blue rectangles that are showing consecutive numbering). Is the numbering relative or absolute? It looks like that the numbering is absolute. But, I can see that both number 1 and 2 are used twice. How can I get that together? Kindly asking you to provide guidance.

     

    Thanks

    Max

    • Hi Max,

      Glad it helped.There’re two things going on here.

      1. The regular scheduled pull from SAP: The report ECPAO*EE* runs in a scheduled mode to pull deltas that have accumulated in SF vis-a-vis the previous run.
      2. Then there’s the push notification.
        1. Push follows the pub-sub architecture. No different from notifications on your iphone.  SAP raises events for key lifecycle changes on EC like Hire/Term and such. Honestly only hire and term exist as of now. SAP will hopefully expose more events in the future. Coming back, this event containing the personid_ext is “notified” to SAP HCM via CPI (Intelligent service and integration center play a role here). There’s a process on CPI for this ( searchL SuccessFactors*PUSH*).
        2. On the other end of CPI notification is the SAP proxy. This in turn invokes the regular pull job in a single employee mode.
      3. Pull and push work in tandem. 

      I believe the diagram doesn’t do a good job explaining this – my bad. Will fix it when I get the time.

  • Hi Girish Bangalore

    First up – a very well written, and well articulated blog. And brownie points for taking time to “paint your own picture”.

    This is not a criticism at all but just a mere observation – does this blog explain anything new that is not already covered in SAP’s replication guides – OM, and Employee and Org Assignment?

    Perhaps you could add these links (for both ERP and S/4HANA) to your blog so that others can find the artifacts for reference?

    Cheers

    Arijit Das