UCOM and Nifi Overview

General principles we should follow:

• Keep Nifi processors as simple as possible – have them just do one thing well. This allows us to reuse them and moves the complexity to the workflow rather than have it live within a monolithic piece of processor code. The ability to componentize the workflow is the reason we’re using Nifi after all. Remember we can always create higher order processor functionality through composition into Nifi Processor Subgroups.

• Only place information that you need into metadata (the Nifi FlowFile Attributes). In other words, keep the data contained in the FlowFile Content there as long as possible and resist the urge to break it down into Attributes too soon.

• Make your processor as general purpose as possible through the use of workflow configuration. For example, rather than build a publishing processor for a particular topic, you could create a general purpose publishing processor that takes the topic it publishes to as either a configuration parameter when the processor is instanced in the workflow, or even have it be passed the topic as a FlowFile attribute. Similarly for a subscribing processor, it would be configured when it’s instanced in the workflow to listen to a particular topic and not have the topic hard coded into it.

Here's a high level view of how I see the Nifi processors and UCOM service functional interfaces working together. The magic subgroup is currently just that, magic. Ultimately it will contain the workflow to handle re-routing, escalation and user physical delivery endpoint identification as well as contain the infrastructure needed to handle conversations. The diagram isn't a comprehensive list of all the data ingress/egress processors we'll need (e.g. XMPP isn't shown) but is intended to show how such pieces would fit together.