How best recover after a long interruption in Service Bridge syncing?

[VanGoghJoe1]

Hi,

We're an MSP and act as a Provider for a number of clients, primarily using it to integrate Incidents.

From time to time, something may happen to interrupt syncing with one or more of them and after it's restored, all the transactions queued up in RPS will go flooding out all at once.   That in turn sometimes has unwanted consequences such as an incident that had been resolved getting re-opened. 

Anyone have any recommendations on best way to handle that?   The hope would to preserve the remote task connections if possible to preserve history and avoid duplicates, while minimizing out of order updates.

One idea is to delete all the queued transactions before service is restored, but don't know what kind of consequences that would have.  

[Vikram Reddy]

Hello @VanGoghJoe1,

Don't purge the backlog, that just means the other side permanently misses whatever happened during the outage, which is worse than a late update. The reopen behavior is more likely coming from how Service Bridge processes updates on the transform: it runs twice per record, once applying the new value and once comparing the previous input.value against the current one, and that second pass is exactly where a flood of queued transactions replaying back to back can misfire a condition that shouldn't have triggered.

• Audit any custom transform scripts on the incident Remote Task Definition for conditions that key off input.value without an isFirstPass or scratchpad check
• Let the outbound queue drain on its own rather than deleting records out of cdc_queue_ih
• Exclude state from bidirectional sync on that field mapping if reopen risk outweighs the value of two way status updates

Thank you,
Vikram Karety
Octigo Solutions INC

[VanGoghJoe1]

Thank you very much, that was very helpful.  I think you're right, avoiding the 2nd pass should go a long way to reducing the issues.