Event notifications
This topic provides an overview of WebHooks notifications and describes how they work.
Every time a work order is changed, your application receives a notification about this if the WebHook is configured to be used. This is a very useful functionality that helps to keep your data up-to-date.
For details how to configure WebHook notifications, see Configuration topic.
Notification types
Notifications can be initiated by a customer application or by CorrigoPro Desktop. WebHook notifications are sent for actions initiated by CorrigoPro Direct.
To understand what application initiated a notification, review the MessageHeader.Sender.Type value of an event notification body.
The following table describes notifications types and the application that can initiate them:
| Notification | Initiated by customer application | Initiated by CorrigoPro Desktop |
|---|---|---|
| Attachment removed | Yes | No |
| Attachment added | Yes | Yes |
| Message received | Yes | Yes |
| NTE changed | Yes | No |
| Quote changed | Yes | Yes |
| SLA changed | Yes | No |
| Checklist updated * | No | Yes |
| Work order received | Yes | No |
| Work order accepted | Yes** | Yes |
| Work order rejected | No | Yes |
| Work order put on hold | Yes | No |
| Work order recalled | Yes | No |
| Work verified | Yes | No |
| Technician checked in | Yes | Yes |
| Technician checked out | Yes | Yes |
| Technician paused | Yes | Yes |
*See Warning Below.
** Depends on version of the customer's application
For more details on notifications structure, see Receiving Updates.
Important
Check lists are becoming Procedures for most Enterprise clients on March 22, 2018, and we discourage their usage.
Notification mechanism
Each time one of events described in the previous table happens, a notification request is created and sent to your WebHook endpoint if your notification service is enabled.
There might be a delay, usually not more than 4 seconds, between an exact date and time of an event and the date and time of the request to your WebHook endpoint.
Notification failure
If due to some reason a notification failed to be sent, CorrigoPro Direct attempts to send this notification in 5 minutes. Every unsuccessful attempt will increase the attempt interval to: 5, 10, 20, 40, and 60 minutes. When the delay reaches the longest time interval (60 minutes), it stops to increase. After 200 attempts it will stop sending the failed notifications. Such notifications are considered dead, but you can reprocess undelivered notifications by using the Queue management tool.
See Communication Logs for troubleshooting the communication errors.
To guarantee the proper sequence of updates, a notification queue is created per work order. Every new notification event of a work order is added to the notification queue if a previous notification failed to be sent. When the first undelivered notification is successfully delivered, the rest of notifications in the queue are processed one by one.
Updated almost 5 years ago