...
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 (EA- Then how is a client notified about the ACK? UCSClient.handleResponse()?? -> UCSClient.updateAlertMessage()). 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. EA - (From 5.3: "[Client.updateMessage()]This operation is used to modify a message. Unsent messages are considered fully mutable except for the message ID and creation information. Once a message is sent, the message is immutable."). |
cancelAlertMessage
Is is not clear in the documentation what is the action in UCS that triggers this method. Client interface defines a method called cancelMessage but this method is used to cancel a message that was being prepared BEFORE it was actually sent to UCS.
A way this method could be triggered is when a client uses Alerting.updateAlertMessage() specifying a status of Retracted. We need to investigate further.
...
Send and receive an Alert Message
Send an Alert Message and
...
ACK
...
.png?version=1&modificationDate=1428952109684&cacheVersion=1&api=v2)
Send an Alert Message and update it
...
| Warning | ||
|---|---|---|
| ||
This operation is vaguely described in the specification. The implications of the modifications of a message are too complex to be included in this implementation. We are not going to support this operation. |
Send an Alert Message and cancel
...
it
.png?version=1&modificationDate=1430223407219&cacheVersion=1&api=v2)
Design
Alerting Interface Design
...