In this article, I want to highlight the features you get if you are already a SwiftMQ user and want to use Flow Director with it.

The 2 Ways of connecting a SwiftMQ Router Network

Flow Director uses SwiftMQ as its runtime platform internally. An installation, either Docker-based or the Unix and Windows distributions, consist of the Flow Director server with an embedded SwiftMQ router.

There are 2 ways to connect to an external SwiftMQ Router Network.

Use a Bridge Flow Component

In this mode, you run Flow Director in addition to your existing SwiftMQ deployment and connect both via a bridge flow component as shown here:

Do anything with the data, .i.e., consume it from a queue or topic of a remote router, process, analyze and visualize it, and maybe send it back to another queue/topic of the remote router. Because you can integrate any other messaging system like Kafka in the same way, you can combine them all, i.e., receive from IBM MQ and send it to SwiftMQ. The possibilities are endless.

The significant advantage of this mode is that you don't touch your existing messaging system (no matter which you use). You don't need to run a particular SwiftMQ release to use Flow Director, nor do you need to use SwiftMQ at all! It also works with ActiveMQ, RabbitMQ, Kafka ... you name it. You just run it side-by-side. For this reason, we see this as the default deployment method. It's just easy to set up and works.

Connect via Routing Connection

Here you connect Flow Director to your existing SwiftMQ network. The flows are deployed and executed on your SwiftMQ routers.

There are multiple ways to establish a routing connection:

Use Explorer App

Create the routing connector through the Explorer app and you are done. I would use this way if the connector should be live longer, i.e., you permanently use Flow Director to manage a particular SwiftMQ Router Network.

Use CLI from a Flow

Create a flow that executes a CLI flow component to create a routing connector to a remote router on flow start and delete the connector on flow stop. If you are clever, what I assume, you make this flow a template flow and define the routername as a flow parameter. This way, you only need to copy it and set the routername accordingly and are able to connect to another router.

This method can also be used to connect standalone routers and create a temporary network, manage it, deploy and run some flows and then disconnect.

Use the internal Routing Listener

The router embedded in Flow Director already has a routing listener defined on port 4100. So you only need to let your remoted routers connect to this listener. This is way is recommended if you want to scale Flow Director by adding more routers. You only need to configure the remote router to connect but there is no configuration required at Flow Director.

Advantages

With this method, you get the same features as with the side-by-side deployment. The advantage is here, you don't need to go through a network to access a queue or topic. You can access it directly by running a flow on that router where the destination is defined. You can also integrate any other messaging system but then from within your routers.

But the real advantage of integrated over side-car is that you get new management and monitoring capabilities which are:

• A modern web-based Explorer App to manage a SwiftMQ Router Network, which is much more scalable and feature-rich than the Swing-based SwiftMQ Explorer.
• A modern web-based Router Monitoring App with current states, timelines, histories, and alerting.
• Integration of SwiftMQ metrics with Prometheus and Grafana.

This allows you to do everything through the Flow Director web interface without the need to use any other tools.

Keep in mind: You need SwiftMQ release 12.1.0 or higher for this mode.

Summary

You can use Flow Director side-by-side to your existing messaging system, or you can run it integrated and connect it to your existing SwiftMQ Router Network. Both have the same features but the side-by-side deployment runs independently from your existing messaging infrastructure while the integrated deployment avoids network access and includes management, monitoring, and integrates nicely with Prometheus/Grafana. It allows you to do everything through Flow Director's web interface without the need to use any other tools. You decide!