Integration Server 10.15 | Publish-Subscribe Developer’s Guide | Synchronizing Data Between Multiple Resources | For N-Way Synchronizations Add Echo Suppression to Services | Adding Echo Suppression to Notification Services | Incorporating Echo Suppression Logic into a Notification Service
 
Incorporating Echo Suppression Logic into a Notification Service
The following shows the sample notification service with echo suppression logic added to it. The sample notification service was presented in Setting Up Key Cross-Referencing in the Source Integration Server along with a description of its flow steps, which are unnumbered in the sample below. The numbered flow steps in the sample below are the flow steps added for echo suppression. For more information about the numbered flow steps, see the table after the diagram.
Step
Description
1
Determine whether the latch is open or closed for the changed object. Invoke the pub.synchronization.latch:isLatchClosed service to locate a row in the cross‑reference table for the object that has changed and for which you want to send notification. Pass the isLatchClosed service the following inputs that identify the object:
In this input variable...
Specify...
appId
The identification of the application (e.g., Billing system).
objectId
The object type (e.g., Account).
canonicalKey
The canonical ID.
The isLatchClosed service uses the isLatchClosed field from the matching row to determine whether the latch is open or closed. If the isLatchClosed field is ‘false’, the latch is open, and the isLatchClosed service returns ‘false’ in the isLatchClosed output variable. If the isLatchClosed field is ‘true’, the latch is closed, and the service returns ‘true’. For more information about the isLatchClosed service, see pub.synchronization.latch:isLatchClosed.
2
Split logic based on whether the latch is open or closed. Use a BRANCH flow step to split the logic. Set the Switch property of the BRANCH to isLatchClosed, to indicate that you want to split logic based on the value of the isLatchClosed pipeline variable.
3
Build a sequence of steps to execute when the latch is open. Because the Label property for the SEQUENCE flow step is set to false, this sequence of operations is executed when the isLatchClosed variable is false, meaning the latch is open. When the latch is open, the target resources have not yet been notified of the data change. This sequence of steps builds and publishes the canonical document.
4
Close the latch. When the latch is open, the first step is to close the latch. By closing the latch before publishing the canonical document, you remove any chance that Integration Server will receive and act on the published canonical document.
To close the latch, invoke the pub.synchronization.latch:closeLatch service. Pass the closeLatch service the same input variables that were passed to the pub.sychronization.latch:isLatchClosed service in step 1 above. For more information about the closeLatch service, see pub.synchronization.latch:closeLatch.
5
Build a sequence of steps to execute when the latch is closed. Because the Label property for the SEQUENCE flow operation is set to true, this sequence of steps is executed when the isLatchClosed variable is true, meaning the latch is closed. When the latch is closed, notification of the data change has already been published. As a result, the notification service does not need to build or publish the canonical document. This sequence of steps simply re-opens the latch.
6
Re-open the latch. Re-open the latch to reset the latch for future data changes. To re-open the latch, invoke the pub.synchronization.latch:openLatch service. Pass the openLatch service the same input variables that were passed to the pub.sychronization.latch:isLatchClosed service in step 1 above. For more information about the openLatch service, see the pub.synchronization.latch:openLatch..
Important:
If multiple resources will make changes to the same object simultaneously or near simultaneously, echo suppression cannot guarantee successful updating. If you expect simultaneous or near simultaneous updates, you must take additional steps:
1. When defining the structure of a canonical document, include a tracking field that identifies the source of the change to the canonical document structure.
2. In the notification service include a filter or BRANCH to test on the source field to determine whether to send the notification.