Understanding Route Actions in Service Bus EAI and EDI Labs

Route actions are a very important feature within Service Bus EAI and EDI Labs. That’s the piece that actually lets you do protocol bridging over Azure. With this blog, I try to explain how route action bridges protocol mismatch.

Consider a scenario where App A talks to App B. App A sends messages only using REST/POX protocol while App B can receive messages only over SOAP protocol. To make this happen, you can use an XML bridge as a mediator. The bridge will accept messages over REST/POX but will send them out over SOAP. A bridge helps in appropriately connecting two applications which are over different protocols. When a message is sent out on a SOAP protocol, the bridge, just before it sends the message out stamps the message headers as required by the SOAP protocol.


The term “Route Action” suggests the message processing that needs to be done after the route condition is evaluated and the destination entity is determined, but before the message is actually sent out over the wire. So, how does an XML bridge makes this happen. There are two ways to set the route action – one through properties that you must have already defined in the bridge, and two through constant ‘expressions’ that can be assigned to a message header.

Let us look at how you can set the route action using both these approaches

Using Properties Already Defined in the Bridge

Step 1: Define properties as part of the Enrich stage in a bridge configuration. For example, say you are using XPATH to get a value from the XML message and you assign it to a property.


So, if we go by this screenshot, you create a property P1 and use an XPATH query (defined in Identifier) to extract a value. The extracted value is assigned to property P1.

Step 2: Now while defining a route action, we use the value of property P1 and assign it to a header in the outgoing SOAP message. On the Bridge Configuration surface, right-click the routing arrow between two entities and from the Properties grid, click the ellipsis against Route Action


In the Route Action dialog box, you select the property as P1 from the drop-down, set the Type to SOAP, and specify the header name. This denotes that the value of property P1 will be applied to the To header of the outgoing SOAP message.


Thus, you could successfully use the Route Action to construct a valid outgoing SOAP message from an incoming REST message, thereby bridging the protocol mismatch between the message source and destination.

Using Constant Values for Message Headers

You use the option of specifying a constant value to a message header when you know the value already and you don’t want to use the properties already promoted in the bridge. One such example is while sending a message to an LOB relay endpoint on the bridge. When you want to send a message to an LOB relay endpoint, you must specify the SOAP action header on the outgoing message. This header is not set on the message that comes out of the bridge. The SOAP action to be specified is already available as part of the LOB relay configuration, as shown in the figure below and the value in the red box is the value that must be set for the Action SOAP header


This is how you go about doing this:

Step 2: On the Bridge Configuration surface, right-click the routing arrow between two entities and from the Properties grid, click the ellipsis against Route Action.


In the Route Action dialog box, you specify the values as shown in the screenshot below:


When the message leaves the bridge, it has Action header set on it with the value specified for the Expression text box.