PubSub+ - Configuring DMR using SEMPv2

Dynamic Message Routing (DMR) is a mechanism in Solace PubSub+ brokers to create a network or mesh of brokers within which events can flow freely between brokers. It is used in scenarios where events need to be distributed across sites such as in hybrid or multi-cloud or for horizontal scalability when single broker limits are exceeded.

You can find more information on DMR on the Solace documentation site.

In this article I'll describe how to set up or join DMR clusters and establish links between brokers via the PubSub+ broker's REST based SEMPv2 API.
Two postman collections illustrate how to create and tear down a DMR connection.

Full documentation of the SEMPv2 API is available online. We will need to use the Config API - whose Swagger API doc you can find here.

We will look at the scenario of connecting brokers across sites to facilitate data movement e.g. between on-premise and cloud. As a prerequisite you should have access to two PubSub+ brokers. You could use Solace Cloud services (with the exception of the "Free" plan), Standard Edition brokers deployed using Docker (configured for the 1000 connection scaling tier) or a combination of both.

Setting up DMR requires configuration on two resources:

• Message VPN
  • Ensure the VPN is enabled for DMR. This should be the case with new deployments, it may be disabled on upgrades from previous versions of the broker.
  • Add bridges between the local VPN and remote VPN that you want to connect.
• DMR Cluster
  • Create a DMR cluster or join an existing cluster
  • Create external or internal links to remote nodes
  • Attach the address of the cloud broker to the link on the local broker as the local broker will establish the connection.

DMR links establish the physical connection between nodes, DMR bridges connect the data channel and enable the flow of events between two Message VPNs.

Gather information about the brokers

First let's gather the information we need to connect to the SEMPv2 API and other data we need:

• Broker hostnames - in Solace Cloud you can find a service's host name on the Status tab of your service - look for "Host Name".
• Broker SEMPv2 base path - host name, HTTP or HTTPS admin port. For a locally deployed broker it may look like http://localhost:8080/SEMP/v2/. In cloud you can find the SEMPv2 base path on the Manage tab in the cloud console, look at the SEMP - REST API section.
• Names of the VPNs that you would like to connect
• Management username and password. Refer to your docker container setup or to your services' Management tab in the Cloud Console.
  • I'll admin/secret and admin/cloud
• Primary router name / virtual router name of both brokers. In Solace Cloud you can find this on the Status tab of your service - look for "Primary Router Name". For any broker you can use the following cUrl command, replacing http://localhost:8080 with your broker URL and changing the --user parameter to your admin username and password. I have added this call to the postman collection as well.

curl --location --request POST 'http://localhost:8080/SEMP' \
--header 'Content-Type: application/xml' \
--user admin:secret  \                                  
--data-raw '<rpc>
        <show>
        <router-name>      

        </router-name>
    </show>
</rpc>'

• If using Solace cloud you need the following information about the cluster that is pre-configured on the service. You can find this on the Status tab of your service
  • Cluster name
  • Cluster password

In the Postman collections I'll use the following parameters for the brokers. I set these up in an environment so you can easily import the collection, adjust the environment and test against your brokers.

Setting up the DMR cluster and connection

This Postman collection illustrates how to setup the DMR cluster and connection between local and cloud broker.
Executing all the request in the order they appear in the collection - manually or by using Postman's "Run" dialog - results in a functional external link between the brokers.

Removing the connection and the DMR cluster

This collection removes the connection created by the previous collection.
Executing all the request in the order they appear in the collection - manually or by using Postman's "Run" dialog - undos all configuration.