In this blog, I will briefly explain the extensibility capabilities of EC Compound Employee API.

The Compound Employee API supports two forms of extensibility:

  • Extending Compound Employee API using standard or custom MDF objects
  • Extensibility using Employee Central custom fields
  • Extensibility using Employee Central custom fields

Custom fields and HRIS-based objects
If an HRIS object supports custom fields, the Compound Employee API will considers these custom fields as well. They are a part of the static fields list of Compound Employee API.

Custom fields are contained in the response, if the field is not blank or not nil (as for all other fields in the static fields list) and independent from data model or country specific data model.

Example

<customLong1>3</customLong1>


Custom Fields and MDF-based objects
 

Custom fields maintained in MDF objects will appear in the response as they are modeled in the MDF object definition. For the following objects custom fields are supported by Compound Employee API:

  • paymentinformationV3
  • alternative cost distribution
  • recurring deduction
  • one-time deduction
  • IT declaration

Custom fields are ignored by the Compound Employee API and excluded from the response if they are defined in the object model with the following data types:

  • Attachments
  • Data Sources
  • Character large objects (CLOB)
  • Extensibility using MDF objects

Custom Compositions

Custom compositions to custom objects that are defined in the following MDF objects are supported by the API:

  • paymentinformationV3 and child segments
  • recurring deductions
  • one-time deductions
  • alternative cost distribution
  • IT declaration

All fields that are defined in the object definition of the custom MDF object are returned by the API in its response.

 

MDF objects as additional select items

Compound Employee API can be extended by additional standard and/or custom-based MDF objects. To extend the Compound Employee API with further standard or custom MDF objects, these MDF objects have to be registered so that the Compound Employee API will extract them along with the HRIS and standard MDF objects. After the registration, meta data of Compound Employee API are adjusted accordingly. Now, to extract data from the registered object type, the registered MDF objects have to be included as an additional select item in the query request.

Object Types are considered by Compound Employee API, if they fulfill the following requirements:

  • The object is employment specific, meaning one of the following fields has to be of data type User:
    • externalCode
    • sfField1, sfField196, sfField197 … sfField200
    • For custom MDF objects only externalCode and sfField1 is supported.
  • API visibility is set to Read Only or Editable.
  • The object is not a composite object.
  • MDF Version History is set to Complete History.
To report this post you need to login first.

Be the first to leave a comment

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

Leave a Reply