Making SAP SuccessFactors and SAP Cloud Integration more reliable and performant
In this blog post, you will learn about the many finer configurations in SAP Cloud Integration that can help you design an integrated flow connecting to SAP SuccessFactors. The topic can be complicated and hence I have tried to group all the known options under different topics with links for further reading on each topic.
Always use SAP SuccessFactors adapter variants instead of Generic SOAP and OData
SAP Cloud Integration gives both OData and SAP SuccessFactors adapter variants. Though both provide same functionalities at the protocol level, there are additional application-specific headers and functionalities in SAP SuccessFactors variant that can help you and SAP Support better troubleshoot problems. For instance, the Message-ID in SAP Cloud Integration is forwarded via headers to SAP Successfactors. The message ID can help you correlate a failing HTTP request in SAP SuccessFactors Audit Logs to SAP Cloud Integration Messages.
Check out help documentation to know about all the functionalities: Configure the SuccessFactors OData V2 Receiver Adapter
Enable session reuse
Cloud solutions create an abstraction between the service and the server. However, all the requests eventually have to reach a server in the cloud to be processed. Session reuse is a great way to ensuring the cloud infrastructure can forward your requests to the same server, called pinning. This pinning can be extremely helpful when we are reading large volumes of data across multiple requests. Reusing session will ensure the requests are reaching the same server which already has all the resources such as database resolved and available. Additionally, session reuse eliminates the need for authorizations in subsequent calls further improving the network turnaround time.
Suggested reading on session reuse: Cloud Integration – How to configure Session Handling in Integration Flow
Use Server Paging
When there is a large volume of data to be pulled, OData services rely on pages to send the data across the multiple requests. A page has a finite number of records, defined as the page size. Typically developers use $top to control the page size. This mechanism via $top is called Client Paging where the client is defining the page size. If the $top is not used, the server will use the default page size and is called server paging. It is ideal for integrations to use server paging. You can achieve this in SAP Cloud Integration by keeping the page size empty in the adapter. This ensures the maximum available records are fetched in each network call.
Paging also gives more control on data load management. Suggested reading:Handling Large Data With SAP Cloud Platform Integration OData V2 Adapter
Snapshot refers to a record of the contents of a storage location or data file at a given time. Using snapshot for queries can help SAP SuccessFactors precompute the results. Apart from eliminating the possibility of data-loss/data-duplication, snapshots will ensure the subsequent queries take a shorter time.
Suggested reading server based paging: How to avoid missing/duplicated data enabling server based pagination in Boomi, CPI / HCI and Integration Center – SuccessFactors
Use gzip encoding
HTTP Compression has a great advantage when fetching large data volumes. Using gzip for most cases give a compression ratio of around 90%, i.e. a 100 MB payload effectively becomes 10MB on the network making the call much faster.
For adapter version 1.18 and higher, the accept-encoding option is available as drop-down under connections tab. For older version, suggested reading for enabling gzip: Increase the performance using Compress Data in CPI SuccessFactors OData connector – Content-Encoding=gzip
Fine tune the Enrichers
SAP SuccessFactors integrations heavily rely on Enrichers. Most integrations often have multiple enrich calls in quick succession. Though it appears simple, most integrations do not perform their best due to poorly configured Enrichers. Having all the above stated optimizations with filters to each of the enrich call can ensure only necessary data is fetched and greatly impact your overall integration performance. Ideally, you will have the request-reply and enrichers in the same local process. Server paging shall work on the request-reply, filters on the enrichers where the process in pages are disabled. Together they optimize the data fetched into the integration.
Suggested reading: Handling Large Data with Content Enricher and OData v2 adapter
Hope you find all the above steps easy to implement. The links at the end of each topic covers the subject in greater detail and should help answer an specific questions that may arise in the course of the development of your integrations.