Employee Central’s Compound Employee API offers two different kinds of delta transmission:
- Effective-dated delta transmission
- Period-based delta transmission
Effective-dated delta transmission is designed for consumers that work in an effective-dated manner. This means, it is assumed that consumers store the time frame (start and end date) when a data record is effective. Deltas are communicated with regard to the time frames that have been transmitted in the last replication.
In contrast to this, period-based delta transmission is intended for consumers that are not able to deal with effective-dated objects. Deltas contain retro-active changes and effective-dated objects that are relevant for the given period.
"Image/data in this KBA is from SAP internal systems, sample data, or demo systems. Any resemblance to real data is purely coincidental."
SAP Successfactors CompoundEmployee API
Let's understand this difference with the help of below example:
An employee was hired and created in the system in September. In mid-October, the job data of the employee was changed usingMake correction. Today (end of October), the salary was changed effective mid-October and the address was changed effective in November. The last synchronization of the consumer took place before the change of the job data.
In effective-dated delta transmission, the Compound Employee API returns all changes that happened since the last synchronization, such as the change of the job, the change of the salary, and the future address change.
For a consumer using period-based delta transmission and providing October 1st to October 31st as the synchronization period, only the change of the job and the change of the salary will be replicated, since these changes affect the given period and the data, which has already been replicated to the consumer in the past.
However the change of the address remains unconsidered and will be transmitted in the next period of November, when it becomes effective.
Let's take other sample:
Employee has two Job Info records returned by Compound Employee API.
- Record having action as "NO CHANGE".
- This record has start date as 2020-08-14 and last modified on as 2020-08-17T12:46:41.000Z.
- It has used new event reason as "RETFUR".
- As you can see from the last modified on date and time, it’s definitely changed otherwise why its showing last modified on as 2020-08-17T12:46:41.000Z.
- This record has start date as 2020-08-10 and last modified on as 2020-08-17T12:45:56.000Z.
- It has used event reason as "LOFRED".
As you can see for the above two entries, there are two records uploaded in SF EC Job Info portlet (both have start date in past) in a difference of just 1 minute.
Why one record is returned with action as "CHANGE" while other has been returned as action "NO CHANGE"
In period delta only the relevant changes since the last run (last_modified_on) are sent to the target system. If both the new job_info records were added so close we expect that was in between two runs.
If you having issues to understand why the SFAPI CompoundEmployee returned "NO CHANGE" or "CHANGE", we will share one sample.
For example, if the old snapshot had a job_info record with 2020-06-16 until 9999-12-31 in the response.
Now the timeframe from 2020-06-16 until 9999-12-31 is interrupted by a new record with a different status (2020-06-16 until 2020-08-11).
So the target system needs to be notified about this change for the timeframe from 2020-06-16 until 2020-08-11 -> CHANGE. The timeframe from 2020-08-11 until 9999-12-31 is unchanged since the last replication and therefore it is rendered as NO CHANGE.
This logic above of period Delta is also described in the Use cases, chapters 18.104.22.168 in the CE Delta handbook.
Link for the SAP Help page where you can find the SFAPI CE handbooks.
compound employee, effective-dated, period based delta, delta transmission, CHANGE, NO CHANGE, period-delta, CompoundEmployee, SFAPI CE , KBA , LOD-SF-INT-CE , Compound Employee API , LOD-SF-INT , Integrations , How To