Skip to Content

In this blog, I will briefly explain EC Compound Employee API and how it can be used to synchronize employee master data with on-demand or on-premise applications.

Compound Employee API Overview

Compound Employee API, a SOAP-based web service inside EC, is commonly used to synchronize employee master data between Employee Central and other on-demand or on-premise applications. Replication of employee master data by calling Compound Employee API happens synchronously, which means that the response is immediately returned. The Compound Employee API response is structured very similar to the data structures in Employee Central. It returns data about new employees and about changes of employee data.

How to define the consumer structure interface file gives an overview about the options for the generation of a consumer interface structure file.

Compound Employee API supports full transmission and delta transmission. In full transmission the API replicates the complete employee data including future and historic data, independently if the data was changed since the last replication or not. Contrarily, in delta transmission (effective-dated or period-based delta transmission; see also Delta transmission of Compound Employee API) the API only returns elements, which have been created, changed or deleted since the last replication.

The Compound Employee API supports two forms of extensibility, an overview about these is given in  Compound Employee API: Extensibility.

Employee master data synchronization

To setup the data synchronization and to initially load the employee master data from Employee Central into the consuming system, first a full-transmission query of Compound Employee API without any selection parameter can be triggered. With this first synchronization, all employee data including historical data are then sent to consuming systems.

Afterwards only changed employees shall be sent to the consumers to update the employee master data on consuming side accordingly. This can be achieved by replicating changes for employees that happened since the last synchronization by using the Compound Employee API in

  • full transmission mode using select parameter ‘last_modified_on’ to identify changed employees. However, the response of the full transmission contains the complete historical data of the employees and the consumer has to figure out, which data of the employees has changed.
  • delta transmission to identify changed data for changed employees using select parameter ‘last_modified_on’ and /or a given period for not effective-dated delta transmission. In the Compound Employee API response for each segment it is indicated via an action code how the data change needs to be processed on consumer side.

You can find further info under in http://help.sap.com/hr_api/ or about Compound Employee API: http://service.sap.com/~sapidb/002007974700000283532014E and http://service.sap.com/~sapidb/012002523100008807102016E

To report this post you need to login first.

4 Comments

You must be Logged on to comment or reply to a post.

  1. Manu Bhutani

    Hi Mario ,

     

    In middleware (HCI) we have FTSD (Full Transmission start date), when this is set, HCI will pull only those records from EC which are valid on or after this date.

    1. Can you please suggest how FTSD is related to the parameter ‘last_modfified_on’.
    2. Where to define the ‘last_modfified_on’.

     

    Regards,

    Manu

    (0) 
  2. Siddharth Rajora

    FTSD is set on HCI side and also available in ERP side

    Last modified data also in on HCI side! its available in the guide. Please refer it, FTSD is the date from which records would be replicated before it would be cut off even though last modified goes prior to FTSD

     

    (0) 

Leave a Reply