5. Bug Fixed
Preserve the request reference for asynchronous Salesforce processing
An iFlow could supply a request reference called correlationId, but the adapter did not forward it to Salesforce during the Apex call. Salesforce therefore could not use that supplied reference to identify the related request. The adapter now forwards correlationId from the iFlow’s exchange property or message header to Salesforce. Background processing also uses the adapter’s existing asynchronous executor. Salesforce receives the reference supplied by the iFlow and can use it to associate the asynchronous processing with the corresponding request. For example, if an iFlow supplies REQ-1001, the adapter now sends REQ-1001 to Salesforce with the call. The iFlow must supply the reference.
Fix Package Size not applied to V2 data processing with V4/integrate
When users selected the following receiver settings, the adapter sent all records together without applying the target SKYVVA interface’s package-size setting:
| Field | Selection |
|---|---|
| Tab | Processing |
| Processing Type | Skyvva |
| Operation | Integrate |
| Skyvva API Version | V2 |
| Skyvva API | V4/integrate |
For example, a request containing 100 records was sent in one call, even when Package Size was set to 20. Large requests could exceed Salesforce processing limits and fail.
The adapter now reads the target interface’s package-size configuration and divides the XML or JSON data into smaller groups. It sends each group one after another and combines any returned results into one response for the iFlow. This correction also applies to V4/integrateSynchronous and V4/integrateBatch.
With Package Size = 20, a request containing 100 records is now sent in five groups of 20. Customers can continue sending one request from the iFlow. The adapter automatically divides the records, reducing the risk of failures caused by sending too many records in a single call.