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 ensure the cloud infrastructure can forward your requests to the same server, called pinning. This pinning can be extremely helpful when reading large volumes of data across multiple requests. Reusing the session will ensure the requests reach the same server, which already has all the resources, such as the database resolved and available. Additionally, session reuse eliminates the need for authorizations in subsequent calls, improving the network turnaround time.
Suggested reading on session reuse: Cloud Integration – How to configure Session Handling in Integration Flow
Use Server Paging
When a large volume of data is pulled, OData services rely on pages to send the data across 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 defines 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 number of 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 snapshots 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 gives 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 a drop-down under the connections tab. For older versions, 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 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 is disabled. Together they optimize the data fetched into the integration.
Suggested reading: Handling Large Data with Content Enricher and OData v2 adapter
Disable Metadata Refresh
SuccessFactors OData adapter uses a cache to store the service metadata refreshed every hour. This can be over 8 MB and could increase turnaround time once every hour. In productive scenarios, the metadata seldom changes. Hence you can avoid the refresh by disabling metadata refresh.
Suggested reading: OData V2 Refresh Cache On Expiry
Hope you find all the above steps easy to implement. The links at the end of each topic cover the subject in greater detail and should help answer specific questions that may arise during the development of your integrations.
Thanks for sharing these nice tips Prasanth!