A flow defines a list of queues or topics that the one side of the pipe will listen or subscribe to (known as the sources), the queue / topic the messages from the sources will be sent to (known as the target), transformations that will be applied to any messages along this flow and other message properties such as the quality of service (QoS) at which the messages from the sources to the target will be sent. Within flows, QoS is defined according to the MQTT scheme as an integer in the range 0 to 2 where:
- QoS 0 means messages will be delivered at most once and not persisted
- QoS 1 means messages will be delivered at least once and are persisted but may be duplicated
- QoS 2 means messages will be delivered once only and are persisted
As with MQTT, the subscribing QoS for publish and subscribe governs the QoS at which the bridge will receive the message. If a flow is consuming messages using a QoS 0 subscription, even if the publisher published the message at QoS 2, the bridge would see the message as QoS 0.
The only required property on a flow is to set at least one source queue or topic. If a target is not set, it will default to the same as the source.
Flows are added to pipes as either inbound or outbound flows. On an outbound flow the sources are on the local micro broker and the target is another message system (messages are going out from the local micro broker). On an inbound flow the sources are on another messaging system and the target is the local micro broker (messages are coming into the local micro broker).
As an example two flows are created, Flow A has source topics “stock/IBM” and “stock/XYZ” and a target topic of “stock/myStocks”, Flow B has a source topic of “temp/#”, no target but a transformation that prepends “house/” to all incoming topics. Flow A is an incoming flow and Flow B an outgoing flow. When the pipe is running messages published to “stock/IBM” and “stock/XYZ” on the remote messaging system are sent over to the local micro broker however a client connected to the local micro broker would need to subscribe to topic “stock/myStocks” to receive the messages. A client publishing messages into the local micro broker on topics that match “temp/#” will be sent to the remote messaging system. A client connected to the remote messaging system would need to subscribe to “house/temp/#” in order to receive the messages.
Any transformations that change the topic will take precedence over the target property. So if Flow B had specified a target it would not have been used.
Certain flow properties will only be valid the flow is used along with an appropriate connection. For example, some JMS properties can be set on a flow, like a JMS message selector, these are not valid when the flow is used in a pipe with an MQTT connection.
If two flows are added to the same pipe in the same direction (for example, two inbound flows on a pipe) care must be taken to ensure they do not contain exactly the same source queue / topic. If this occurs only one message will be received and it will be sent according to the properties of the flow that was processed last. So if Flow A was added to a pipe then Flow B was added later and Flow A sent messages at QoS 0 and Flow B at QoS 2 the messages would be sent using QoS 2 because Flow B was added later and it would overwrite the subscription Flow A made. As for overlapping subscriptions these are handled in the same way as the micro broker handles all subscriptions, with the message matching the most specific topic first. E.g. If Flow A had “stock/#” as a source and Flow B had “stock/IBM/#” as its source, messages arriving on topic “stock/IBM/closingprice” would match Flow B.
Parent topic: Components of the bridge: XPD622