In enterprise architecture; there can be two or more EMS Servers being used for different application systems which may sometimes require some data communication between each other. To enable transfer of EMS messages between two or more EMS Servers; TIBCO EMS provides routing feature so that messages may be routed from one server to one or more other servers.
In this post; I will be explaining step by step how to achieve routing between two TIBCO EMS Servers.
Step 1: Enable Routing
Enabling the routing feature is the first step that needs to be done. By default; if you look into the configuration file—tibemds.conf; routing is disabled. To enable routing; just change routing value to enabled in this configuration file for both EMS Servers (For ease of understanding I will name the two servers in this post as ServerA and ServerB. In actual; name of the server can be found in the tibemsd.conf file with property name server.)
Make sure that you enable routing in both ServerA and ServerB.
Also note that any changes that you make directly in the configuration files; won’t affect immediately and you will have to restart EMS Servers after making all configuration changes.
Step 2: Create Route
Route from ServerA to ServerB can be created either by defining the route in the configuration file routes.conf on ServerA or by using the below command on EMS administration tool after connecting to EMS ServerA:
create route ROUTE_NAME url=SERVERBURL zone_name=ZONE_NAME zone_type=1hop|mhop properties
in the above command; change ROUTE_NAME to the name of SERVERB, url should be full url of the EMS Server for SERVERB (including protocol, host, port), zone_name can be any name that you want to give to this zone and zone_type should be single hop or multi-hop according to your needs. If routing at only one hop level is needed; use 1hop for this. Properties are optional properties which can be added to the route.
In the same way create route on SERVERB as well where url will be pointing to EMS SERVERA.
Step 3: Create Users on Both Servers for Routing
For routing to work; on both servers we need to create users (either by updating users.conf file or through EMS administration tool).
On SERVERA, create a new EMS User with the same name as the name of SERVERB. This user should have password based on Server Password on SERVERB (set on SERVERB using SET SERVER Password command).
In the same way create a new EMS User on SERVERB with the name matching the name of SERVERA and password same as the server password of SERVERA.
Please note that these user creations are required if authorization is enabled on the server. If the required users are not created or if the users don’t have sufficient rights; you may get error like below:
Unable to initialize route XYZ: route server returned: ‘invalid name or password’
However; If authorization is disabled; this is not needed then.
Step 4: Create Proxy Receiver/Routing Queue and Home Queue
For this example; I am using queues to show how routing works instead of topics. However, routing can be achieved for any types of destinations.
Let’s suppose that we want to route all the messages that are received on a queue tutorialspedia.queue on SERVERA to a queue with the same name on SERVERB.
For this purpose; create a Global queue on SERVERB using below command:
create queue tutorialspedia.queue global
The above command will create a queue tutorialspedia.queue with global property set.
Now, create a queue with the same name on SERVERA but use the suffix @SERVERB for this queue as this will be a routing queue only to route the messages towards the home queue on the SERVERB.
The proxy queue (routing queue) on SERVERA will be created using below command:
create queue tutorialspedia.queue@SERVERB
Step 5: Test EMS routing
After completing step 1 to 4; restart ems servers for both SERVERA and SERVERB so that changes become effective.
After this; just design a simple process in TIBCO BW which will be connecting to SERVERA and send JMS message towards the routing queue.
You should notice that same message is routed to the home queue on SERVERB from where consumers may pick the message and consume it.