Page Comparison

...

Send an Alert Message and cancel it

Alerts timeout and escalation

Even if there is no technical limitation, Alert Messages are not designed to support responses. The purpose of an alert is to notify a set of recipients and, most of the times, to expect an ACK from the recipients. In the context of an Alert, then, what determines the timeout/escalation is not the absence of a response, but the alertStatus of the Alert Message.

If, when the timeout period is reached, the status of the Alert Message is not "Acknowledged", the escalation mechanism should be triggered. 

Design

Alerting Interface Design

...

This processor implements the expected behavior of Client.cancelMessage() operation. This processor retrieves the messageId from the incoming FlowFile, retrieves the related message from UCSControllerService and performs the following operations:
1.- If there is no message in UCSControllerService with the specified id, the processor will route the incoming FlowFile to a REL_UNKNOWN_MESSAGE relationship.
2.- If the message in UCSControllerService with the specified id is not an AlertMessage, the processor will route the incoming FlowFile to a BAD_MESSAGE relationship. 
3.- If the alertStatus property of the message in UCSControllerService with the specified id is already "Retracted", the FlowFile will be directed to a REL_NO_UPDATE relationship. 
4.- If the alertStatus property of the message in UCSControllerService with the specified id is "Pending", the alertStatus value is changed to "Retracted" and a FlowFile with the serialized message will be directed to a REL_CANCELLED relationship.  
5.- If the alertStatus property of the message in UCSControllerService with the specified id is other than "Pending" or "Retracted", the FlowFile will be directed to a REL_INVALID_STATE relationship. 

Alerts timeout and escalation

Given that the current implementation ACKs an Alert Message as soon as the first recipient ACKs it, there is only one escalation possibility: onNoResponseAll.

When an Alert Message is persisted - UCSPersistMessage processor - a new cron job needs to be scheduled if the message fulfils the following requirements:

1.- The Message is an AlertMessage instance
2.- The respondBy  property of the message's header is > 0
3.- The receiptNotification  property of the message's header is true

The cron job that gets scheduled implements the following logic:

1.- If the alertStatus property of message if "Acknowledged", "Retracted" or "Expired", the cron job ends silently.
2.- If the alertStatus property of the message is "Pending", any Message present in onNoResponseAll list is notified to UCSControllerService.notifyAboutMessageWithResponseTimeout(). The timeOutReason of the generated TimedOutMessage is NO_RESPONSES.