How to throttle an outbound message in Jitterbit
Over the past year, I have been working on a number of integrations using Jitterbit, focused on moving HR data to various systems.
We initially went for a transactional approach, where operations would be triggered by outbound messages. That turned out to not work well with the Netsuite API, without purchasing a rather expensive user license that would allow concurrent API sessions. However, at the time we needed to “throttle” SFDC outbound messages, which can contain up to 200 records at a time, so that they processed one record at a time. I’m recording how we did this here, as I’m sure I will need to reference it later.
Its quite easy to do, once you have created an web service operation to consume the outbound message (will post on that later).
The outbound message operation in Jitterbit has 3 components
- Web service method
- Transformation
- Response
In order to throttle the outbound message, edit the transformation, and call your next operation from within the transformation, after declaring any global variables used in the operation.
Declaring global variables and running child operation from within transformation:
<trans>
$SFDCWorkerId = root$transaction$body$notifications$Notification.sObject$Id$;
$SFDCOrganizationId = root$transaction$body$notifications$Notification.sObject$SFDC_Organization_Id__c$;
RunOperation("<TAG>Operations/Jitterbit Connect™/Salesforce Queries/Copy of Query Workers</TAG>",true);
</trans>
One note - Salesforce is waiting for a response while your operations are processing, and will sense a failure and will resend the outbound message if the acknowledgement is not received in time. This can quickly escalate into a traffic jam.
I’m not sure what the exact OM response timeout is for SFDC. The time between retries increases exponentially, up to a max of 2 hours between retries.
There might be a way to send the ack response from jitterbit to salesforce prior to the throttling operation, still need to explore that.
This stackexchange post suggests building in the ability to keep track of successfully processed message ids. Thats for another date.