...
According to the documentation, the following is a usual "Send Alert with ACK" scenario:
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) 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(). This analysis document will use UCSAlerting.updateAlertMessage() and not UCSClient.handleResponse() to notify client about a modification in an AlertMessage.
...
This section explains when each the methods of UCSAlerting are invoked by UCS.
receiveAlertMessage
...
This method is invoked whenever an AlertMessage is updated in UCS. An AlertMessage is modified using UCSAlerting.updateAlertMessage().
| 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. In the current NiFi implementation, Client.updateMessage is not related in any way with UCSAlerting.updateAlertMessage. |
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 change its status
.png?version=1&modificationDate=1428952109684&cacheVersion=1&api=v2)
Send an Alert Message and cancel it
.png?version=1&modificationDate=1428952122338&cacheVersion=1&api=v2)
Design
Alerting Interface Design
...
In order to allow clients to register UCSAlerting callback interfaces into UCS, a new processor must be implemented and added into Client Interface workflow: UCSRegisterAlertingCallback.
The previous image shows how Client Interface workflow will look after the modifications for the Alerting Interface are implemented.
...
In this approach, the two previously mentioned processors - UCSUpdateAlertMessage and UCSRegisterAlertingCallback - are implemented into a specific workflow called "Alerting Interface". The structure of this workflow is similar to the Client Interface.
As you can see in the previous image, the new workflow has a similar structure to Client Interface: a message is received via HTTP, parsed and processed according to its content. The 2 available "commands" in this workflow are: registerUCSAlertingInterface (or registerUCSAlertingCallback) and updateAlertMessage.
...
This workflow is in charge of notifying any previously registered UCSAlerting interface about alert-related events happening inside UCS. The supported events are: a new Alert Message is present in UCS, an Alert Message was modified inside UCS and an Alert Message was canceled inside UCS. Each of this events is represented in the new workflow as an input port.
Just like UCS Client Interface workflow, this new workflow notifies any previously registered UCSAlerting callback about an alert-related event that happened inside UCS.
New Processors
...
UCSUpdateAlertMessage
This processor is the most important processor in the entire Alerting Interface implementation. This processor receives an AlertMessage as its input, and generates a FlowFile containing 2 AlertMessages.
The incoming AlertMessage MUST have a MessageId that is known inside UCS. The original Alert Message is then retrieved and a diff is performed between the old and the new version of the message.
...
- if the message contains a statusByReciever entry for each of its recipients and the status of each of them is Acknowledged -> the alertStatus property of the message is updated to Acknowledged.
- if the message contains a statusByReciever entry for each of its recipients but the status of each of them are not the same -> the alertStatus property of the message is not updated.
- if the message does not contain a statusByReciever entry for each of its recipients -> the alertStatus property of the message is not updated.
If there is no error during the execution of this processor, the output of this processor is a flowfile containing a serialized version of both, the original and the updated message.
UCSRegisterUCSAlertingCallback
...