...
| Note | ||
|---|---|---|
| ||
| This implementation will only diff the alertStatus and statusByReciever properties property of the messages. |
The way the statuses status of an Alert Message are is processed is this:
1.- If the alertStatus property of the new original alert message in UCS is different than the alertStatus property of the original message, the property in the original message is updatedother than Pending, the processor will fail.
2.- (Only executed if the previous step was not)The statusByReciever entries If the alertStatus property of the new message are analyzed and updated in the original message. If, after the property is updated, the following scenarios must be evaluated:
...
alert message is other than Acknowledged, the processor will fail.
3.- If the alertStatus property of the new message is different than the alertStatus property of the original message, the property in the original message is updated
...
.
4.- If the alertStatus property of the new message is
...
equals to the alertStatus property of the
...
original message, the flowfile will be directed to a REL_NO_UPDATE relationship.
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.
...
Similar to UCSGetUCSClientCallbacks, this processor retrieves any previously registered UCSAlerting callback URL from UCSControllerService and generates a flowfile for each of them.
UCSCancelMessage
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.