When the tag query parameter is used in the Inbound Messages API, the message FlowFile is attributed with the value provided. This allows flow designers to use the RouteOnAttribute processor to route each incoming message to the appropriate downstream flow within their canvas.
RouteOnAttribute is one of the many options by which routing can be accomplished
within Dataflow Studio.
To configure the RouteOnAttribute processor for tags, a dynamic relationship must be added for each tag that requires routing. These dynamic relationships are defined as custom properties within the RouteOnAttribute processor, including the tag relationship and an evaluation statement.
To configure tag relationships using RouteOnAttribute:
-
Go to the Properties configuration for the RouteOnAttribute processor.
-
Add a new property ('+' button).
-
Define the property name for the tag relationship, e.g., "tagName_relationship".
-
Set the property value to an Expression Language statement that evaluates to true (or false) for the tag expected, e.g., "${im.tag:equals(‘tagName’)}"
"im.tag" is the name of the attribute added to the FlowFile. The tagName entered
in the statement must match what is sent through the API query parameter. Other expressions
may be used, outside of true or false statements.
Once all dynamic relationships are defined and applied to the processor, they can be used for downstream processor connections.
Example:
Tag "po" and "asset" are sent through Inbound Messages API, indicate the BOD message coming to the system. In Dataflow Studio, each tag needs to be routed to a different BODToEAM processor for the appropriate BOD Type selection to ensure processing once it reaches EAM.
In the RouteOnAttribute processor, a dynamic relationship property must be added and defined for each tag:
Once entered and saved, these newly defined relationships are shown in the Create Connection dialog and in the processor Relationship tab.
These dynamic relationships allow each tag ("po" and "asset") to be connected and routed to the appropriate BODToEAM processor, for its corresponding each BOD type into EAM.
Using this as our example, the flow from Inbound Message queue to EAM may look something like the below.
-
The InboundMessagesProcessor resides in the tenant root level, connected to RouteOnAttribute.
-
Relationships are defined for each specific message, connecting to specific Process Groups for each message type and tag being received.
-
Each subsequent Process Group would contain a dedicated flow to transform and transport that specific message.
The InboundMessagesProcessor is placed at the root level and is connected to the RouteOnAttribute processor. Within RouteOnAttribute, relationships are defined for each specific message type and tag being used. Based on the tag-relationship, RouteOnAttribute is connected to subsequent Process Groups, where a dedicated flow exists for the necessary transformation and transit of the data.