3.2 Thresholds, Limits, and Performance
To secure performance and stability for your integration, consider the thresholds and limits of the Compound
Employee API.
The Compound Employee API has similar thresholds and limitations as the other SAP SuccessFactors APIs:
● 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. Reach best
performance by setting the maxRows parameter to at least 400 or more.
In case you face issues because the amount of data to be returned is too high, you can reduce the number
of rows per query or queryMore call for your integration project. But remember that reducing this number
will lead to more queryMore operations, which in turn can slow down the transfer of data.
● A maximum SOAP message size (HTTP content size) cannot exceed 5 MB. This is the limit when uploading
binary attachments using SFAPI. In general, the total attachment storage size is controlled by the
attachment storage conguration of the company instance.
● Due to performance limitations, we recommend that you don't retrieve more than 20,000 employees per
integration process run. If the number of employees to be extracted is greater than 20,000, you can limit
the number of selected employees per run by using selection parameters such as company, country, pay
group, or employee class.
● The maximum number of objects that can be exposed by the API is limited to 50,000 instances of an
individual Generic Object (MDF Object) per call. In case this number is exceeded, the API aborts the call
and shows an error message containing the object type in question and the limit applied. If this happens,
we recommend that you reduce the number of objects to be returned by adjusting the lter conditions or
reducing the page size of the query.
● Ensure that you don't replicate employees many times although their data hasn't changed. Use the
last_modied_on parameter to transfer only employees that have changed since the last process run.
Please note that for last_modied_on queries, it is only possible to select data changes for up to a
maximum of three months into the past. Any date further in the past is not considered.
● If you want to select multiple employees, don't query them one by one. Avoid selecting single employees, in
particular with a high request frequency.
A common use case here is to query data of the employees' managers. Use the
associated_employee_information segment to get the managers along with the employees, instead of
querying this data separately.
● Avoid triggering a large number of queries in parallel. Too many parallel queries can have a negative impact
on performance and can put the stability of your integration at risk.
● Don't schedule API calls more frequently than every 15 minutes if they include the last_modied_on select
parameter or request the segment EmployeeDataReplicationElement. In case certain updates (such as the
termination of an employment) are needed earlier in the target system, consider consuming specic
events to detect such changes immediately. For more information, see
Setting Up Intelligent Services.
● API calls without a last_modied_on select parameter lead to a full extraction of employees, regardless of
whether data has changed since the last replication run. We recommend that you only use such calls in
initial load scenarios or when requesting the segment EmployeeDataReplicationElement in order to fetch
entries from the Employee Central Data Replication Monitor.
An initial load should be a one-time activity rather than scheduled to be run regularly. In case you still need
to schedule API calls without a last_modied_on parameter, make sure they don't run more often than
once a day.
● Don't carry out mass updates (for example, using imports) in parallel with a data extraction run performed
by the API. Or else employees might not be picked up due to deferred storage on the database. Meaning
Implementing the Employee Central Compound Employee API
Using the Compound Employee API
P U B L I C 17