In part 1 I defined what the bitwise operator is and how you can use it in your .net code. Now, let us see how we can use the same functionality in BizTalk to route messages.

How to use  the bitwise operator in BizTalk

One of the great things about my job is that I get to move around a lot. Different customers has different uses for BizTalk and this leads to new ways to use it. This scenario is not unique, but was new to me anyway.

BizTalk receives a message and needs to route it to different receivers. The receivers will be assigned using some form of “lookup” based on the message type. Message type A must be sent to system 1, 2 and 4. Message type B must be sent to system 3 and 4, and so on.

As usual, the preferred solution makes no use of an orchestration, should be reconfigured without redeployment and adding a new receiver should be very easy and should only impact the current deployment in a minor way.

This is a good time to use the bitwise operator!

Setup in BizTalk

This is just a simple proof of concept and, as such not complete. Keep that in mind and please provide feedback if anything is missing.

The schema: The bitwise operator will solve the task. To use that, and also avoid using an orchestration, BizTalk has to be able to route messages based on a value in the file. In order to do that, a promoted property is used. In this case a field called “ReceiverField”.

It is important to remember that in this particular case, the promoted property must be an unsignedInt. This makes sense since you cannot use bitwise on a combination of positive and negative numbers. If you use Int, the operator will not show up in the administration console.

Receive port: Now set up the ports. First we need receive to pick up the incoming data. In this a simple file receive location is used, but there is nothing stopping you form using other protocols. The bitwise handling will still work. The important thing to remember is to use the xmlreceive pipeline (as opposed to the passthru).

Sendport for different systems: Now for the magic part. Add a sendport for each of the systems you need to send the information to. Make sure to configure filters to reflect the particular number you have assigned to that system.

In the picture above, the filter is configured to send files received on the previously configured receive port and then the bitwise operator is used to look for the number two in the receiver field in the previously created schema.

Add another port for another system:

The important thing to notice here is that there really is not any major difference. The only important difference is the number for the receiver field, which is not set to a 4.

Start all the ports create a testfile to be dropped in the receive folder. Set the value of the receiver field to “2”. Drop it in the receive folder. The only the send port marked with a “2” will pick it up.

Try again and change the value to “4”, only the second port will pick it up. Lastly set the value to “6”, now both ports will pick it up!

The upsides

The most important gain is of course the routing but there are some other benefits as well. Firstly, you can put different format mapping for different systems in their respective ports. This is also true for pipelines, so if one of the systems is using custom formatting, that is not a problem.

Next, adding another system is simple as all you have to do is add another send port, and configure it to look for the next number (double the last).

The downsides

This logic cannot be used in orchestrations. You cannot use the bitwise operator as a part of an activation filter in the orchestration, sadly.

Another thing that might be a problem is the code, or handling, by which you assign the number in the “RecievierField”. If BizTalk is responsible for assigning this value, you have to make sure that adding another system is just as simple as adding another send port. Maybe you have a database that matches message types and assign the number. BizTalk can then simply use a database functiod in a map to look it up.

Blog Post by: Mikael Sand