SAP Cloud Platform Integration with SF Compound

Employee API

Document History
Version No. Date Revision Description
0.1 18-Oct-2021 Draft
0.2 25-Oct-2021 Review
1.0 27-Oct-2021 Final version

Document Asset Team

Name Email
Hareesha Tanisetty hareesha.tanisetty@accenture.com
Vishwajeet Ahluwalia Vishwajeet.ahluwalia@accenture.com
Amit Kumar Jain amit.c.kumar.jain@accenture.com
Machindra Patade machindra.patade@accenture.com

Hareesha Tanisetty
Contents

1. Introduction ...................................................................................................................................... 2
2. Overview ........................................................................................................................................... 2
a. What is the need of Compound Employee API? ............................................................................... 2
b. When to use Compound Employee API? .......................................................................................... 2
c. Using the Compound Employee API: ................................................................................................ 3
d. List of SAP SuccessFactors API Servers for SAP SF data centers ..................................................... 9
3. Modes in Compound Employee API ................................................................................................. 9
4. Fetch data from SFEC using Compound Employee from SAP CPI ................................................... 11
5. Scenarios using Delta Mode ........................................................................................................... 14
6. Scenarios using Snapshot Mode ..................................................................................................... 20
7. Additional Scenarios ....................................................................................................................... 26
8. Negative Test Cases ........................................................................................................................ 29
9. Limitations....................................................................................................................................... 30
10. Conclusion ................................................................................................................................... 30
11. References .................................................................................................................................. 31

pg. 1 Copyright © Accenture 2018 All Rights Reserved

1. Introduction

The purpose of this document is to explain the usage of SFEC Compound Employee API.

Compound Employee Application Programming Interface (API) for SAP SuccessFactors Employee Central
is used to extract employee data out of Employee Central. Compound Employee API is based on the Simple
Object Access Protocol (SOAP). It replicates employee master data from Employee Central to SAP systems,
payroll systems, and benefits systems.

Currently SuccessFactors supports SFAPI (Compound Employee) and OData APIs for integration.
Compound Employee will be used when building Integrations around Employee Master data and for rest
of the scenarios, can leverage OData APIs.

2. Overview

Compound Employee API is commonly used to synchronize employee master data between Employee
Central and other on-demand or on-premises applications. It returns data about new employees and
about changes of employee data. Replication of employee master data by calling the Compound
Employee API happens synchronously, which means that the response is immediately returned.

a. What is the need of Compound Employee API?

Employee Central can be used as leading application for employee master data. Third-party
systems, such as payroll or benefits providers, require Employee Central employee data to trigger
their own services and follow-on processes.

Therefore, a regular replication of HR data to the third-party systems must be ensured. For this
purpose, replication processes call the Compound Employee API, a SOAP-based web service
inside Employee Central, to retrieve employee master data out of Employee Central.

b. When to use Compound Employee API?

• If one looking for delta changes and field level changes then it’s good to use compound employee
compared to calling multiple OData entities.
• Also, there are multiple parameters available to improve performance and good to go with
CompoundEmployee if want to get complete set of data.

pg. 2 Copyright © Accenture 2018 All Rights Reserved

 c. Using the Compound Employee API:
The Compound Employee API selects multiple entities related to an employee and returns all
data in a hierarchically structured response XML with the employee person data as the root
node. It works as:

• Query and QueryMore: A typical retrieval sequence consists of a login call, a CompoundEmployee API
call, and a number of subsequent queryMore API calls.
The API query call specifies the entities to be returned plus the selection criteria. This call returns a
limited number of employees. To retrieve the remaining records, you need to issue a series of
queryMore API calls until all employees are retrieved. In each call, queryMore you need to specify the
session ID provided by the first query response.

• QueryRequest: The CompoundEmployee API query request is made up of a SELECT clause, FROM
clause, and WHERE clause.
The query request of the API call has the following properties:
Property Definition
Param List of optional parameters (supported parameters are startingRow,
maxRow, and traceLevel)
queryString Select statement following an SQL-like syntax

Below is the example of what the query request can look like:

QueryRequest.xml

o SELECT Clause - The SELECT clause of the CompoundEmployee API contains a list of all entities to
be returned as part of the hierarchical query result XML. The following substructures are
supported in the SELECT clause:
▪ person
▪ personal_information
▪ address_information
▪ phone_information
▪ email_information
▪ person_relation
▪ employment_information
▪ job_information
▪ compensation_information
▪ paycompensation_recurring
▪ paycompensation_non_recurring

pg. 3 Copyright © Accenture 2018 All Rights Reserved

 ▪ payment_information
▪ accompanying_dependent
▪ alternative_cost_distribution
▪ job_relation
▪ direct_deposit
▪ BenefitsIntegrationOneTimeInfo
▪ BenefitsIntegrationRecurringInfo
▪ EmpCostAssignment
▪ national_id_card
▪ deduction_recurring
▪ deduction_non_recurring
▪ global_assignment_information
▪ ItDeclaration
▪ dependent_information
▪ personal_documents_information
▪ EmployeeDataReplicationElement
▪ associated_employee_information
▪ emergency_contact_primary

Example : SELECT person, address_information, email_information, employment_information,

compensation_information, paycompensation_recurring, job_information, job_relation,
paycompensation_non_recurring, payment_information, national_id_card,
personal_information, phone_information, global_assignment_information FROM
CompoundEmployee WHERE last_modified_on >
to_datetime('${property.lastSuccessfullRun}T00:00:00Z') and fromDate =
to_date('${property.lastSuccessfullRun}','yyyy-MM-dd') and toDate =
to_date('${property.Current_Date}','yyyy-MM-dd') and person_id_external IN ('123')

o WHERE Clause - The WHERE clause in the CompoundEmployee API query request specifies the
conditions that employees need to fulfill in order to be included in the query result. The WHERE
clause consists of subexpressions, which can be combined by the logical operator AND. A
subexpression is made up of field, operator, and value or values.
The WHERE clause of the CompoundEmployee API supports a list of selects parameters.

Field Description Valid

Operators
LAST_MODIFIED_ON Returns all employees, for which any =, >, >=, <, <=
employee data has changed since this date
and time. The modification date applies on all
effective dated records.
The date can only go back as far as 3 months.
User information isn’t considered for queries
by last_modified_on.

pg. 4 Copyright © Accenture 2018 All Rights Reserved

 Deletion of records is considered in queries
for last modified employees. These deleted
records aren’t returned by the API.
For example:
WHERE last_modified_on >
to_datetime('2012-11-06T23:30:00Z')
WHERE last_modified_on >
to_date('01/07/10', 'DD/MM/YY')
START_DATE Returns all employees for which any >=
employee data is effective from this date on.
COMPANY_TERRITORY_CODE Returns all employees that have a job at a =, IN
company located in the provided
country/region at any point in time. The
companies are determined via table
FO_LEGAL_ENTITY_T.
PERSON_ID Returns all employees with the respective =, IN, NOT IN
PERSON_ID.
PER_PERSON_UUID Returns all employees with the respective =, IN, NOT IN
PER_PERSON_UUID.
PERSON_ID_EXTERNAL Returns all employees with the respective =, IN, NOT IN
PERSON_ID_EXTERNAL.
USER_ID Returns all employees with the respective =, IN, NOT IN
USER_ID.
COMPANY Returns all employees that have a job at the =, IN
selected company. The select is based on the
external code of the company.
EMPLOYEE_CLASS Returns all employees that have a job in the =, IN
respective employee class. The selection is
based on the external code of the employee
class.
DEPARTMENT Returns all employees that have a job in the =, IN
provided department. The select is based on
the external code of the department.
DIVISION Returns all employees that have a job in the =, IN
provided division. The select is based on the
external code of the division.
BUSINESS_UNIT Returns all employees that have a job in the =, IN
provided business unit. The select is based on
the external code of the business unit-
LOCATION Returns all employees that have a job in the =, IN
provided location. The select is based on the
external code of the location.
JOB_CODE Returns all employees that have a job with =, IN
the provided job code. The select is based on
the external code of the job code.

pg. 5 Copyright © Accenture 2018 All Rights Reserved

 PAY_GROUP Returns all employees that have a job with =, IN
the provided pay group. The select is based
on the external code of the pay group.
COMPENSATION_PAY_GROUP Returns all employees that have a =, IN
compensation with the provided pay group.
The select is based on the external code of
the pay group.
SNAPSHOT_DATE Returns the employee data for a certain point =
in time.
The date can only go back as far as 3 months.
SourceOfRecord Returns all employees that have an =, IN
employment with the provided source of
record information. The select is based on
the external code of the source of record
information.
Returns all employees that have an =, IN
isContingentWorker employment with the given value in field
IsContingentWorker. The absence of the
isContingentWorker condition is treated as
isContingentWorker=false to preserve
compatibility with older integration
processes that expect real employees only.
In order to select all persons that are
contingent workers, use the condition
isContingentWorker=true. If you want to
request only regular employees, use the
condition isContingentWorker=false. If you
want both employment types, use
condition isContingentWorker IN (true,
false)
fromDate...toDate Selects employees that have changes that =
become effective in the given time period.
Additionally, the time period is applied as
a filter to all effective dated segments so
that only time slices are returned that
intersect with the given time period.
selectFromDate Returns all employees that satisfy all job =
and/or compensation conditions where the
effective end date of the respective time
slices is greater than or equal to the value of
selectFromDate. The value must be a fixed
date format, for example to_date('2016-01-
01','yyyy-MM-dd').
selectToDate Returns all employees that satisfy all job =
and/or compensation conditions where the
effective start date of the respective time

pg. 6 Copyright © Accenture 2018 All Rights Reserved

 slice is lower than or equal to the value
selectToDate. The value must be a fixed date
format, for example to_date('2016-01-
01','yyyy-MM-dd').
hiringNotCompleted Evaluates the indicator property =
hiringNotCompleted in the
EmpEmployment entity in Employee
Central, which was introduced for
Onboarding (2.0). The property allows for
differentiat-ing data records of candidates
(that is, new hires that didn't yet complete
the Manage Pending Hire process). If
hiringNotCompleted is false, the
CompoundEmployee API returns only data
of hired employees.
assignment_class Filters employments by the =, IN
ASSIGNMENT_TYPE field from the
employment in Employee Central

Example: WHERE company = 'SAP' AND employee_class IN ('C','P')

o Effective Period Selection - Using the select parameters selectFromDate and selectToDate can
further restrict the set of selected employees either by specifying an open period, by using only
one of the parameters or by using both parameters to determine a fixed time range.

Example: SELECT person, employment_information, job_information FROM CompoundEmployee

WHERE last_modified_on > to_datetime('2021-10-13T00:00:00Z') and fromDate = to_date('2021-
10-13','yyyy-MM-dd') and toDate = to_date('2021-10-27','yyyy-MM-dd') and person_id_external
IN ('962')

o Effective End Date Filter - The EFFECTIVE_END_DATE parameter in the WHERE clause of the
CompoundEmployee API plays a special role, since it isn't directly applied when selecting the data
but is used to filter the result.
Field Description Valid Operators
EFFECTIVE_END_DATE The condition is applied as a filter to all =, >=
segments of the employee that are effective-
dated. Depending on the operator, the
following results are returned:
=: The query returns the entry of an effective-
dated segment, which is valid on the given date
(EFFECTIVE_START_DATE <= given date <=
EFFECTIVE_END_DATE).>=: The query returns
all occurrences of an effective-dated segment
that are valid on the given date or any later
date (given date <= EFFECTIVE_END_DATE).

pg. 7 Copyright © Accenture 2018 All Rights Reserved

 o Sorting by Start Date - The CompoundEmployee API supports ascending and descending sorting
by start date for effective-dated entities.Time slices of effective-dated objects in the response are
by default sorted in descending order by start date. This means the newest time slice is always
the first in the response. Semantic keys and sequence numbers are also considered in sorting.
Syntax of ORDER BY Expression Sorting Order
ORDER BY start_date DESC descending
ORDER BY start_date ASC ascending
ORDER BY start_date ascending

Example: SELECT person, personal_information, address_information, employment_information,

job_information FROM CompoundEmployee ORDER BY start_date ASC / DESC

• QueryResponse: The CompoundEmployee API query response has a defined list of elements and
follows the current Employee Central data model to build a hierarchically-structured XML.
Elements of the Query Response:

Element Definition
hasMore Indicator if more results are available
numResults Number of top-level results
querySessionId Query session ID for paging
sfobject List of employees with subentities, returned as hierarchical XML

Below is the example of what the query response can look like:

QueryResponse.xml

pg. 8 Copyright © Accenture 2018 All Rights Reserved

• API Metadata Access: The CompoundEmployee API also provides operations that return its
metadata.

• How the CompoundEmployee API Reacts to Data Purge: Can provides some optional data purge
checks, which can be enabled by the consumers.

• Error Handling in the CompoundEmployee API:

The API handles errors depending on the situation in which they occurred:
o Errors aborting the overall API processing
o Errors leading to incomplete data in the response

d. List of SAP SuccessFactors API Servers for SAP SF data centers

Protocol URL Pattern Endpoint Example

OData v2 /odata/v2/ https://api17.sapsf.com/odata/v2/

OData v4 /odatav4/ https://api17.sapsff.com/odatav4/

SFAPI /sfapi/v1/soap https://api17.sapsf.com/sfapi/v1/soap

WSDL /sfapi/v1/soap?wsdl https://api17.sapsf.com/sfapi/v1/soap?wsdl

3. Modes in Compound Employee API

Compound Employee API supports two types of modes:

a. Snapshot Transmission Mode

b. Delta Transmission Mode

a. Snapshot Transmission Mode: In this mode, the API returns the data as it was on the snapshot date,
considering all changes, corrections, and deletions.

Limitations of snapshot mode

• Segments Not Supported in Snapshot Mode:

o payment_information, because this segment doesn't provide audit information in Employee
Central.
o accompanying_dependent, because this segment doesn't have an HRIS element model.
• Changes Not Considered in Snapshot Mode:
o Changes to external codes of picklists, foundation objects, or generic objects. The current
value of the external code is returned.

pg. 9 Copyright © Accenture 2018 All Rights Reserved

 o Changes to foundation objects that are triggered using Make Correction. The current value of
the determined time slice of the foundation object is returned.
o Changes to attributes of the objects USERS_SYS_INFO and USER_ACCOUNT. The current
value is returned for the following attributes:

▪ logon_user_id, logon_user_name,and logon_user_is_active in the person segment.

▪ direct_reports in the employment_information segment.

b. Delta Transmission Mode: In this mode, the API only returns employee data that was created,
changed, or deleted since the last replication.

Note: The CompoundEmployee API returns employees (persons with employment) only. Persons without
employment are excluded from extraction and not returned. This means that technical users and
employee dependents aren’t returned as sfobject by the API. But dependents are considered as a sub
element of employees.

Action Codes: It supports some action codes.

Action Code Description

INSERT INSERT is communicated if a new record is created. For example, when an employee is
hired, all segments are returned with action code INSERT.
CHANGE CHANGE is sent if an existing record has been modified. For example, the amount of a
bonus has been adjusted.
DELETE DELETE means that a record has been deleted completely. For example,
paycompensation_non_recurring information has been removed.
NO_CHANGE NO_CHANGE indicates that there were no relevant changes on the exposed attributes of
the segment since the last replication. In case a segment is effective dated, several
instances of this segment might be in the response and each can have a different action
code. In cases where one instance has the action code NO_CHANGE, this means that in
the time frame of this instance no differences exist compared to the data status at the
last replication.

Previous Fields: In case a field has been changed since the last modified date, a subelement
called previous is added to the field by the CompoundEmployee API. While the field itself contains the
current value of the field, the previous element shows which content the field had before the change.

Event Information: Job information and compensation information require special treatment because
they contain the information about the business events.

Typical business events in Employee Central include:

• Hire
• Promotion
• Leave
• Job change

pg. 10 Copyright © Accenture 2018 All Rights Reserved

 • Termination
• Rehire

Effective-Dated and Period-Based Delta Transmission:

The CompoundEmployee API offers two different kinds of delta transmission:

a. Effective-Dated Delta Transmission: Effective-dated delta transmission is designed for consumers

that work in an effective-dated manner. This means, it’s 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.
b. Period-Based Delta Transmission: Period-based delta transmission is intended for consumers that
aren’t able to deal with effective-dated objects. Deltas contain retroactive changes and effective-
dated objects that are relevant for the given period.
Non-effective-dated objects are returned in both kinds of delta transmissions if they’re changed
after the last replication.

4. Fetch data from SFEC using Compound Employee from SAP CPI

A Request Reply is used to connect to receiver SFEC system to fetch the data from SFEC. Compound
Employee API is based on SuccessFactors SOAP receiver adapter to connect a tenant SAP Cloud
Integration to SOAP-based Web services of a SuccessFactors Employee Central system (synchronous or
asynchronous communication).

Follow the below steps to configure the SF Soap adapter for compound employee in SAP CPI:

• In Web UI, Create the new integration flow.

• Access into the palette choose request reply then connect it to a receiver system and select
the adapter type as SuccessFactors and message protocol as SOAP.
• Navigate to general tab, connection tab and processing tab and provide the values for the
parameters.

General:

Parameter Description
Name Enter the name of the channel

pg. 11 Copyright © Accenture 2018 All Rights Reserved

Connection:

Parameter Description
Address URL of the SuccessFactors data center that want to connect to. Can
browse to and select the SuccessFactors data center URL by using
the Select option.
Address Suffix The system automatically populates this field with /sfapi/v1/soap as
selected the SOAP message protocol.
Authentication Select one of the following authentication methods:
• Basic
• OAuth2 SAML Bearer Assertion
Credential Name Credential name for the credentials that has been deployed on the
tenant.
Proxy Type Type of proxy used to connect to the SuccessFactors system – Internet
or Manual.
• Choose Manual, to enter values for the fields Proxy Host and
Proxy Port.
• Proxy Host is the name of the proxy host which will be using.
• Proxy Port is the port number that will be using.

Processing:

Parameter Description
Call Type Default value is Synchronous Query.

pg. 12 Copyright © Accenture 2018 All Rights Reserved

 To execute an ad hoc operation, select Asynchronous/Adhoc
Query from the dropdown list.
Operation Operation that wants to perform on the entity that accessing on the
SuccessFactors system. Supported operations are:
• Query
• Delete
• Insert
• Update
• Upsert
Entity Entity wants to access in the SuccessFactors system. For
example, CompoundEmployee
Query Query that wants to construct.
Parameters Enter the parameters
Page Size Maximum number of records to be fetched in one page of response
Timeout Maximum time the system waits for a response
Retry on Connection Failure Select this, if want to retry on connection failure
Process in Pages Select Process in Pages to enable the adapter to process messages in
batches

Query Parameters for Compound Employee Entity

Query Parameters consists of queryMode and resultOptions. Below is a list of all the Query Parameters
supported by the Compound Employee API.

querymode – This parameter must be used to switch on and to use snap/delta transmissions.

• snapshot – Parameter value to enable snapshot transmission

• delta – Parameter value to enable delta transmission
• periodDelta – Parameter value to enable period-based delta transmission
• maxRows – The maximum number of rows to be returned by the query call
• startingRow – The number of the first row to be returned by the call. For example, if startingRow
is 3, the first two rows are skipped

resultOptions - This parameter is used to switch between different options on how much data shall be
returned in the response.

• “allJobChangesPerDay” - If specified the API returns all job information slices that result from
multiple job changes per day. Normally, in case there are several job slices with the same start
date, the API does not return all job slices. It only returns the job slice with the highest sequence
number because it contains the valid business data. If the parameter value is specified, the
consumer gets all job slices and consequently knows about the historic changes and the events
that triggered each of the changes. The parameter value is not supported in case the queryMode
parameter is set to “Delta”.

pg. 13 Copyright © Accenture 2018 All Rights Reserved

 • “allCompensationChangesPerDay” - If specified the API returns all compensation information
slices that result from multiple compensation changes per day. As a result the consumer
consequently knows about the historic changes and the events that triggered each of the changes.
The parameter is only supported if the performance improved render mode is switched on. The
parameter value is not supported in case the queryMode parameter is set to “Delta” or when
using the old render mode.
• “changedSegmentsOnly” - If specified, the API returns only changed segments with an action
code not equal to ‘No Change’ in delta transmission. The parameter value is only supported in
case the queryMode parameter is set to “delta”.
• “changedFieldsOnly” - If specified, the API returns only changed fields of a changed segment. The
parameter value is only supported together with “changedSegmentsOnly” and in case the
queryMode parameter is set to “delta”.
• “isNotFirstQuery” The parameter value is only supported in case the queryMode parameter is set
to “delta” in combination with “fromDate” and “toDate” select parameter. For further
information be referred to the separate delta transmission handbook.
• “extendedConsistencyChecks” - If specified, the API conducts in delta transmission additional
validations for dates of time slices and errors out for effected employees in cases of overlapping
time slices or gaps in between time slices where no gaps are allowed. For the affected employees
a log entry gets returned containing the severity ‘ERROR’.
• “xsd” If specified, the API generates the XSD for the response message. The XSD can be used in
the middleware to generate the profile for the interface.
• “renderPreviousTags” - If specified, the way that previous values are exposed in the response
message is changed. The API returns previous values in a separate tag and no longer in mixed data
types.

5. Scenarios using Delta Mode

Below scenarios covers the high-level explanation of CompoundEmployee API using Delta mode
transmission. When the interface runs in delta mode, the CompoundEmployee API returns the employee
data that was created, changed, or deleted since the last replication.

Two different kind of delta transmission are supported by Compound Employee API, these are:

• Effective dated delta transmission

• Period-based delta transmission

Let’s consider one real time example:

In the example below, an employee was hired and created in the system in June. In August the
compensation data of the employee was created. In November the compensation data was changed
becoming effective from Nov 1st and again the salary was changed becoming effective from November
5th. The last synchronization of the consumer took place before the change of the compensation data.

pg. 14 Copyright © Accenture 2018 All Rights Reserved

In effective dated delta transmission Compound Employee API returns all changes that happened since
the last synchronization, i.e., the insertion of the compensation, the change of the salary and the future
salary change.

In period-based delta transmission and providing Jun 15th to Nov 1st as synchronization period, only
the insertion of the compensation, 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 employee in the past. However,
the second change of the salary which will be effective from Nov 5th remains unconsidered and will first
be transmitted in the next period of November, if it becomes effective.

SFEC Screenshot:

pg. 15 Copyright © Accenture 2018 All Rights Reserved

Now let's run one query in the SFAPI CompoundEmployee with the parameters delta and perioddelta
mode using SAP CPI.

Integrated Configuration flow in SAP CPI:

pg. 16 Copyright © Accenture 2018 All Rights Reserved

Iflow is designed with a timer to trigger the interface upon deployment and an empty Content Modifier is
added. A Request-Reply is used to fetch the data from SFEC using SuccessFactors SOAP API adapter and
the received data is sent to the receiver using SFTP adapter. Below are the configurations of
CompoundEmployee API using Snapshot mode transmission.

Effective dated delta transmission:

pg. 17 Copyright © Accenture 2018 All Rights Reserved

In this example, delta mode is enabled by setting the query parameter queryMode to delta and in the
query includes the last_modified_on > to_datetime('2021-06-15T00:00:00Z') in the WHERE condition.
Here compensation data of an employee is changed and the last modified date in the query is after the
last synchronization date of the change, hence the API returns the employee with all the changes, since
the last synchronization i.e., '2021-06-15T00:00:00Z'

SFEC Response:

delta.xml

Based on the last modified date this query returns all the 3 compensation records of an employee i.e., all
changes that happened since the last synchronization.

Period-based delta transmission:

pg. 18 Copyright © Accenture 2018 All Rights Reserved

In this example, delta mode is enabled by setting the query parameter queryMode to perioddelta and in
the query includes the last_modified_on > to_datetime('2021-06-15T00:00:00Z') and fromDate =
to_date('2021-06-15','yyyy-MM-dd') and toDate = to_date('2021-11-01','yyyy-MM-dd') in the WHERE
condition. Here compensation data of an employee is changed and the last modified date in the query is
after the last synchronization date of the change and providing Jun 15th to Nov 1st as synchronization
period, hence the API returns the employee only the compensation data and the change of the salary will
be replicated, since these changes affect the given period.

SFEC Response:

period delta.xml

Based on the toDate and fromDate this query returns only 2 compensation records of an employee i.e.,
only the changes affect the given period.

pg. 19 Copyright © Accenture 2018 All Rights Reserved

6. Scenarios using Snapshot Mode

Below scenarios covers the high-level explanation of CompoundEmployee API using Snapshot mode
transmission. When the interface runs in snapshot mode, the CompoundEmployee API returns the data
considering all the changes, corrections, and deletions as it was on snapshot date.

Let’s consider one real time example:

SFEC Screenshot

pg. 20 Copyright © Accenture 2018 All Rights Reserved

In the example above, Last modified date was on July 08, 2021 2:23:31 AM EDT. This employee contains
5 records in Personal Information as there are changes in the personal data.

Now let's run one query in the SFAPI CompoundEmployee with the parameters snapshot mode using SAP
CPI.

Integrated Configuration flow in SAP CPI:

Iflow is designed with a timer to trigger the interface upon deployment and an empty Content Modifier is
added. A Request-Reply is used to fetch the data from SFEC using SuccessFactors SOAP API adapter and

pg. 21 Copyright © Accenture 2018 All Rights Reserved

the received data is sent to the receiver using SFTP adapter. Below are the configurations of
CompoundEmployee API using Snapshot mode transmission.

Query1:

In this example, snapshot mode is enabled by setting the query parameter queryMode to snapshot and
in the query includes the snapshot_date = ‘2021-07-02T00:00:00Z’ in the WHERE condition. Here personal
data of an employee is changed and the snapshot date in the query is before the last modified date of the
change, hence the API returns the employee with old records whose last modified date is before ‘2021-
07-02T00:00:00Z’.

SFEC Response:

snapshot_response1.
xml

pg. 22 Copyright © Accenture 2018 All Rights Reserved

Based on the last modified date this query returns only 3 personal information records of an employee
whose snapshot date is before the last modified date.

Query2:

pg. 23 Copyright © Accenture 2018 All Rights Reserved

In this example, snapshot mode is enabled by setting the query parameter queryMode to snapshot and
in the query includes the snapshot_date = ‘2021-07-10T00:00:00Z’ in the WHERE condition. Here personal
data of an employee is changed and the snapshot date in the query is after the last modified date of the
change, hence the API returns the employee with all personal records. Hence the API returns the
employee with all personal records whose last modified date is before ‘2021-07-10T00:00:00Z’.

SFEC Response:

snapshot_response2.
xml

Based on the last modified date this query returns all the 5 personal information records of an employee
whose snapshot date is after the last modified date.

pg. 24 Copyright © Accenture 2018 All Rights Reserved

Note: Operator ">" is not supported for "snapshot_date". For example, if the query containing
snapshot_date > to_datetime('2021-07-10T00:00:00Z') is executed then the below error is generated.

pg. 25 Copyright © Accenture 2018 All Rights Reserved

7. Additional Scenarios

a. Effective End Date – To extract the latest record of job information use the below query in
CompoundEmployee API in the full transmission query mode (which is a default query mode – so
no need to explicitly use this parameter in the query). Also note, job information is just an example
– the API will fetch current data from all the portlets.
SELECT person, employment_information, job_information FROM CompoundEmployee WHERE
start_date >= to_date('2021-07-01','YYYY-MM-DD') and effective_end_date = to_date('2021-10-
31','yyyy-mm-dd') and person_id_external IN ('962')

effective_end_date.x
ml

b. renderPreviousTags - When the data of a field is changed and would like to retrieve the changed
data as well as the previous data via Compound Employee API then renderPreviousTags is used
as a parameter.

SFEC Response:

previoustags.xml

c. changedFieldsOnly and changedSegmentsOnly – This return changed fields of a changed

segment with an action code not equal to ‘No Change’ in delta transmission.

pg. 26 Copyright © Accenture 2018 All Rights Reserved

SFEC Response:

Changed
segments.xml

d. allCompensationChangesPerDay - If multiple records exist for the same time slice, it returns all
the compensation information records with same effective start.

pg. 27 Copyright © Accenture 2018 All Rights Reserved

SFEC Response:

allCompensationData
.xml

e. allJobChangesPerDay - If multiple records exist for the same time slice, it returns all the job
information records with same effective start date.

pg. 28 Copyright © Accenture 2018 All Rights Reserved

SFEC Response:

alljobchanges.xml

8. Negative Test Cases

a. Perioddelta

If queryMode=perioddelta and the query is SELECT person, employment_information, job_information

FROM CompoundEmployee WHERE last_modified_on > to_datetime('2021-10-30T00:00:00Z') and
person_id_external IN ('962')

b. Effective_End_Date

SELECT person, address_information, employment_information, compensation_information,

paycompensation_recurring,job_information, job_relation, paycompensation_non_recurring, ,

pg. 29 Copyright © Accenture 2018 All Rights Reserved

personal_information FROM CompoundEmployee WHERE effective_end_date >= to_date('2020-02-
01','yyyy-mm-dd') and last_modified_on > to_datetime('2019-01-07T06:28:29Z')

c. allCompensationChangesPerDay or allJobChangesPerDay

9. Limitations

a. A maximum SOAP message size (HTTP content size) can’t exceed 5 MB. This is the limit when
uploading binary attachments using SFAPI.
b. By default, a maximum of 200 rows is returned in a single query or queryMore method. This
number can be set to a value from 1 to 800 by specifying the maxRows parameter in the query
method.
c. Due to performance limitations, its recommended that don't retrieve more than 20,000
employees per integration process run.

10. Conclusion
The document provides an overview of CompoundEmployee API and its functionality in SAP CPI with detail
explanation.

pg. 30 Copyright © Accenture 2018 All Rights Reserved

11. References
• https://help.sap.com/viewer/368c481cd6954bdfa5d0435479fd4eaf/Cloud/en-
US/360ef42b1d4e4b86a6867b6f0adce4ce.html
• https://help.sap.com/doc/60753cd8689244d18a6960f790b08661/2111/en-
US/SF_EC_Comp_Emp_API.pdf
• https://userapps.support.sap.com/sap/support/knowledge/en/2318047
• https://userapps.support.sap.com/sap/support/knowledge/en/2659455
• https://userapps.support.sap.com/sap/support/knowledge/en/2649816

pg. 31 Copyright © Accenture 2018 All Rights Reserved