...
- Alerting Interface: alert clients can update the state of an alert.
- UCS Alerting Interface: client side interface to receive alert-related events from UCS server.
| Info | ||
|---|---|---|
| ||
The documentation is not clear on how the methods between the 2 interfaces are related. Alerting defines a single updateAlert() method but UCSAlerting defines 3: receiveAlertMessage(), updateAlertMessage() and cancelAlertMessage(). |
...
JH - the Alerting interface is provided by UCOM to allow alertable recipients to acknowledge the alert. The UCS Alerting interface must be provided by the alertable recipient to receive alerts (and updates/cancellations) - these are the methods UCOM will call in response to the sender issuing send/cancel/updateMessage requests (from 5.3) with an alert message type. |
According to the documentation, the following is a usual "Send Alert with ACK" scenario:
JH - the Alerting and UCS Alerting labels are wrong (note made to fix in spec)
The "send message" path is clear. A Sender uses Client.sendMessage() to send a new AlertMessage to UCS. UCS uses a specific adapter to send the message to one or more Receivers. (Note that our NiFi implementation will not have any adapter for the alerting part. All the messages will be kept inside UCS).
When the Receiver wants to ACK the message it uses UCSAlerting.updateAlertMessage() (Note: it is not clear what are the parameters the Receiver uses for the invocation JH - just the alert message itself) to modify the status of the AlertMessage in UCS. UCS then notifies the clients using, according to the documentation UCSClient.handleResponse() method. This is where I think the documentation is wrong. The method that UCS should use to notify a client about a modification in an AlertMessage should be UCSAlerting.updateAlertMessage() JH - no, this is not a method in 5.3, see above. This analysis document will use UCSAlerting.updateAlertMessage() and not UCSClient.handleResponse() to notify client about a modification in an AlertMessage.
...
| Info | ||
|---|---|---|
| ||
| Client interface also defines a method called updateMessage, but the intention of this method is to update a message that is being prepared BEFORE it is actually sent to UCS (JH - not strictly. We allow updates even after a message has been sent by UCOM, however for ti to be meaningful, it has to make sense in the modality used to transmit the message). In the current NiFi implementation, Client.updateMessage is not related in any way with UCSAlerting.updateAlertMessage. |
...
Send an Alert Message and cancel it
.png?version=1&modificationDate=1428952122338&cacheVersion=1&api=v2)
JH - Cancellation happens from the sender side (see state diagram below)
Design
Alerting Interface Design
...