Unlocking the Power of Job_Event_Information in Compound Employee API of SAP Successfactors

[shayanmajumder]

SAP SuccessFactors is providing cloud-based software for human capital management using the Software as a service model. Among its array of APIs, the Compound Employee API plays a pivotal role in extracting detailed employee information specially for delta integrations. In this blog, we’ll delve into the power of the job_event_information entity within the Compound Employee API, unlocking valuable insights into using this in mainstream integrations specially when incorporating frequent changes in job information becomes necessary.

To comprehend the significance of job_event_information, we will leverage SAP SuccessFactors for test case generation and SAP CPI (Cloud Platform Integration) for data querying.

Handling Multiple Record since Last Run

Suppose an employee underwent multiple changes in job information since the last run. It is crucial to ensure that we only transmit cases where the employee is a new hire with the event reason HIRNEW. While the typical approach involves a consultant searching the topmost stack in job_information, this method may not always capture the required event. Another commonly used method is to iterate through all the job_information records, but this approach makes sending the latest information challenging and necessitates complex code.
A more effective approach is to initially iterate through all the job_event_information records. If the event reason HIRNEW is present, then the employee data can be cached for further processing. This method streamlines the process and ensures that only relevant data is considered for transmission.

EC portlet for job information Job event information in compound employee

Multiple Event Records Entered On The Same Day

It has been observed that more than often a client may add multiple events job information on the same day. Suppose an employer entered a termination and a data change event on the same day. However if a consultant goes through the traditional route of going through job information records he will only find one record with the event reason.

EC portlet for job information

Job Event Information 

Job Information only shows event Data Change However in job_event_information as seen above both events are captured.

Multiple Event Triggers

Continuing with the above example suppose a client wants a requirement of capturing a change which involves multiple events. In the below example suppose an implementation is sending only delta changes to another system. It is often for a consultant to come across a situation in which you send employees who are on leave(LOALOA) or have returned from leave(RETLEAVE) during a run period. The most trusted tool to check and process this information would be using job event information and to check the associated job events and hence send data accordingly. There may be cases in a run period if an employee has returned from leave(RETLEAVE) and has again gone for a leave(LOALOA) on a run period. The only way to determine what to send would be to check the event dates in job event information and compare accordingly.

EC portlet for job information

Job Event Information in Compound Employee

Job information changes vs New Job Event  

There may be cases where no new event is entered but there has been a change in the existing event. Job information will return a record with change for both cases be it a new event creation or a changed event. There it becomes difficult to handle scenarios which depends only on new events. Henceforth a consultant should always refer job_event_information to know exactly if a new event has been entered or a existing event has been changed.

Only change has been made in the existing event 

No insert action can be seen.

Changes in Job Information Event Reason

There may be cases where the event or the event reason has changed, job_event_information captures that as well. Where the previous job_event_information record is returned with action DELETE and a new job_event_information is returned with action INSERT.

Job event information in case of change in job information event reason change.

Deleting a past dated event

Some business scenarios may require a consultant to capture scenarios where a past job information record has been deleted. Job event information can be used for that as well. Suppose during last integration run an employee had gone for a leave however during the next run the leave is cancelled. Thus this information needs to be coordinated with the other system as well, since now the employee is active and the system should’nt wait for a returned from leave(RETLEAVE). Hence we capture the delete event as well from job_event_information to update the current status of the employee.

The marked record is being deleted

Delete action in job event information

In conclusion, leveraging the job_event_information entity in SAP SuccessFactors’ Compound Employee API is important for extracting detailed employee information in integrations. The blog highlights its power in handling multi-record scenarios, capturing simultaneous events on the same day, triggering multi-event conditions, tracking historic events, and differentiating between changes and new events. It also emphasizes the entity’s capability to handle deleted past job information records. By utilizing job_event_information, consultants can ensure efficient ,accurate data synchronization and most importantly ease of implementation especially in scenarios requiring handling of job-related events.