Overview :
This blog will focus on the error handling mechanism when there is connectivity error with Salesforce while trying to update/upsert data in Salesforce. We chose to opt for JMS queue.
Kindly go through previous blog to understand SAP Salesforce Adapter configuration for different operations – https://community.sap.com/t5/technology-blog-posts-by-members/exploring-salesforce-adapter-for-sap-integration-suite/ba-p/14206977
Retry Mechanism
1. JMS Queues
– Stores failed messages in queues for retries.
– Setup: Enable JMS (Enterprise Edition). Use JMS receiver to store messages. Set max 5 retries, exponential backoff. Move to dead-letter queue or notify after max retries.
– Use Case: Update failure in Salesforce Custom Object
– Pros: Reliable, visible in Queue Monitor.
– Cons: 10 GB limit, polling may pause.
– Example: Failed message retried 5 times, then mail to Application Maintenance (AM/Support) Team.
Execution Design Steps :
1. Design consists of three iFlow – Parent (Trigger) iFlow -> Child iFlow -> JMS Retry PD iFlow
2.Parent iFlow gets triggered whenever data is placed into Salesforce push topic
3.Child iFlow, set the /TargetFlowAddress which would be reference for the JMS Retry PD iFlow
4.In the Exception Subprocess, add router condition for specific frequent error occurring during update operation in Salesforce
5.On router condition match, call the JMS Retry PD iflow with the input push topic payload
6. In JMS Retry PD iFlow – after max retry attempt trigger mail to the AM team.
Implementation Steps : Below are configuration snippets
CHILD FLOW :
1. set target address of the iflow to be retriggered by JMS Retry PD iflow ; in child flow in content modifier as
2. Exception occurred in Child flow –
Exception subprocess in Child flow captures the error using the script
JMS Retry PD Flow
3. JMS Retry PD Flow is triggered for the initial store with custom header set message as shown below
Setting queue name
4.In LIP for JMS Reprocess assign the queue name and set the retry mode for iteration check
5. Using the target address call the child flow where error occurred for retry attempts – as shown below –
6. In case the reprocessing fails, then exception subprocess calls the LIP_ReprocessFailedMessage
7. After Max retry attempts, mail gets triggered from JMS Retry PD iflow.
PARENT FLOW :
8.Flow execution goes back to parents in the exception subprocess of parent flow.
9. Set the iflow name in content modifier for mail body.
10. Router condition checks on the specific error and routes accordingly. In case of ‘UNABLE_TO_LOCK_ROW’ , ends it since JMS Retry PD already sent the error notification mail. In case of other error, sends the error notification mail.
Monitoring Log :
Below would be reflected
First Initial Store in JMS is set as custom execution header message in JMS Retry PD iflow then attempts in child flow then sends the mail after max attempt and set the error as the custom execution header message.
For groovy for execution summary mail body, you can refer to the previous blog –
#abap