...
| Note | ||
|---|---|---|
| ||
| This implementation will only diff the alertStatus property of the messages. |
UPDATE: NiFi UCSAlertingUpdateAlertMessage processor will only take as input parameters the id and new status of the message to be updated. Receiving an entire message as input made things complicated - and error prone - to the mechanism we currently have in place to process commands. This implementation also makes more clear what the intention of the processor is. The impedance between what UCS specification stands for Alerting.updateMessage() and the way NiFi implements it will be hidden behind the concrete implementation of ucs-nifi-api.
The way the status of an Alert Message is processed is this:
1.- If the alertStatus property of the original alert message in UCS is other than "Pending" or "Acknowledged", the processor will fail. The incoming flowfile is redirected to REL_STATUS_MISSMATCH (using UCSCreateException.routeFlowFileToException())
2.- If the alertStatus property of the new alert message is other than "Acknowledged", the processor will fail. The incoming flowfile is redirected to REL_STATUS_MISSMATCH (using UCSCreateException.routeFlowFileToException())
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. Use REL_SUCCESS. The message is updated in UCSControllerService by invoking updateMessage().
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.
...