Listen Operations
Overview
Listen operations provide an alternative form of change detection to Changes Operations. Whereas check operations poll for changes on a particular schedule, listen operations listen for changes and are notified by the target systems of changes. In other words, the direction of change notification is opposite to check operations. Similarly to check operations, when a change is found the internals of the operation list is executed.
Unlike check operations, listen operations do not usually require commit operations, as the change notifications are uni-directional and atomic. Care must also be taken in the configuration of groups, schedules and queue on blocked, as they should usually be configured in a way that would allow the operation list to retry should it be unable to at the time the listen operation is triggered.
Usage
Listen operations are typically used to improve the timeliness of change notification. However, there are some unique challenges resulting from the fact that notifications only come through once: namely if the operation list fails, changes can be missed. Because of this it is recommended to maintain a corresponding check operation, even if an operation list has a listen operation, with a less frequent polling schedule.
Shared Standard Configuration
The following configuration settings are common to all standard listen operations:
| Name | Description |
|---|---|
| Recycle Timeout | The timeout after which the listen operation should be recycled. Listen operations are recycled to workaround timeout issues that can be encountered by some systems. The timeout should be reduced if timeouts are being encountered before the listen operation is recycled. |
Standard Operations
The following listen operations are available:
Customer support service by UserEcho
