...
Created Montag 13 April 2015
Analysis
UCS documentation specifies 2 interfaces related to Alerting:
- 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(). |
According to the documentation, the following is a usual "Send Alert with ACK" scenario:
...
UCSClient.receiveMessage vs UCSAlerting.receiveAlertMessage
The documentation doesn't specify what is the specific sequence of actions when a new AlertMessage is introduced in UCS via Client.sendMessage(). The singularity of this situation is that there are 2 "UCS" interfaces that has to be invoked here: UCSClient.receiveMessage() and UCSAlerting.receiveAlertMessage(). Given that the documentation is not specific, our NiFi implementation will notify both interfaces whenever a new AlertMessage is introduced in UCS.
AlertStatus vs AlertStatusByReceiver.
Another gray area in the documentation is what is the correct usage of alertStatus and statusByReciever properties of AlertMessageHeader class. Apparently, an AlertMessage has 2 levels of statuses: a global status and a specific status for each of the recipients. It is not clear how/if the global status is related in any way with each of the individual statuses of each of the recipients. Both levels are defined by the same enum: AlertStatus.
public enum AlertStatus {
Acknowledged,
New,
Expired,
Retracted,
Pending
}...
Our NiFi implementation will use these 2 levels of statuses in the following way:
- alertStatus: it will only allow the following values: New, Pending, Acknowledged and Retracted. Any incoming message will start with a 'New' status. When a Receiver acknowledges the message, its status will be modified to Pending (if there are more Recipients that haven't yet acknowledged the message) or Retracted (If the recipient is the only recipient of the message or if all the recipients of the message already aknowledged it). When an AlertMessage is canceled, its status is changed to Retracted.
- statusByReciever: it will only allow the following values: Pending and Acknowledged. When a new AlertMessage arrives to UCS, it must contain one entry in this Map with a status of Pending for each of the message's recipients. When a recipient acknowledges an AlertMessage, it changes his own status to Acknowledged. UCS will analyze and update the global status whenever a statusByReceiver is modified.
...
UCSAlerting methods
This section explains when each the methods of UCSAlerting are invoked by UCS.
receiveAlertMessage
This methodis method is invoked whenever a new AlertMessage arrives to UCS. Usually, an AlertMessage is introduced into UCS using Client.sendMessage().
...
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.
Sequence Diagrams
Send and receive an Alert Message
...
Send an Alert Message and cancel it
Design
...
Alerting Interface Design
...