3. Bug Fixed

Fix for V2 Synchronous and Batch Processing

Previously, users could select Skyvva API Version \= V2 and choose V4/integrateSynchronous or V4/integrateBatch, but processing could fail with a “Not Found” error.

This happened because the adapter used the selected option as the Salesforce service address. It sent requests to V4/integrateSynchronous or V4/integrateBatch, but those separate service addresses did not exist in Salesforce. Both options needed to use the existing V4/integrate service.

Salesforce therefore returned “404 Not Found”, and the request failed before processing could begin. Users did not receive the expected processing result or see a new batch basket in Salesforce.

Version 1.2.4 corrects the address automatically while keeping the processing option selected by the user:

• V4/integrateSynchronous: Process the records immediately and return the result.
  
• V4/integrateBatch: Place the data in a batch basket for later processing.

Users can continue selecting the same options in the receiver settings. The adapter sends the request through V4/integrate and tells Salesforce which processing action to perform.

The request should proceed without the previous “Not Found” error. For synchronous processing, users receive the processing result and can verify the Salesforce records. For batch processing, users can see the created basket in Salesforce, ready for the configured batch process.

Clearer Error Information When Sending Data to Salesforce

When sending data to Salesforce, a request could fail because of a connection problem, an expired login session, or a temporary service problem.

While trying to read the failure response, the adapter could encounter another error. Users then saw a technical message such as “NullPointerException”, while the original reason for the failure was hidden. This made it difficult for users and support teams to understand what happened and decide how to resolve it.

Version 1.2.4 improves how the adapter handles failed Salesforce requests:

• It checks whether the request failed before reading the response as a successful result.
  
• It retains more information about the failure, helping support teams investigate.
  
• For supported expired-session errors, it can renew the Salesforce session and retry the request.

For example, when a service returns “503 Service Unavailable”, the updated handling can preserve that information so support can recognize a temporary service problem.

For the error cases covered by this change, users and support teams receive more useful information about why processing failed. This helps them decide whether to retry the request or investigate the connection or Salesforce service.