In this post I will discuss a problem encountered a while ago when I was responsible for developing a Microsoft .NET Class Library (DLL) that was going to be used by .NET applications handling messages between BizTalk and old Legacy systems. The .NET applications retrieves information from and store information into the Legacy system and communicates with BizTalk via MSMQ queues. Picture 1 shows the conceptual solution where messages are sent between BizTalk and an old Legacy system.
Picture 1. Messages sent between BizTalk and Legacy system via MSMQ queues.
At first it was straight forward programming using standard .NET Message Queuing classes from_ System.Messaging_ namespace. The code block below demonstrates the classes used.
using System.Messaging; … MessageQueue queue = new MessageQueue(); Message message = new Message(“This is a message!”); queue.Send(message, ”Message Label”); …
Problem encountered When it was time for Integration Tests a problem was encountered. The BizTalk MSMQ Adapters were not able to interpret the messages sent by .NET applications and vice versa.
When sending or receiving messages using the MessageQueue class something called a Message Formatter is used. A Message Formatter is a class implementing the IMessageFormatter interface and it determines how the messages are serialized/deserialized into the body of the message when they are sent/received. The System.Messaging namespace contains the following Message Formatters:
If no Message Formatter is explicitly used when calling Send/Receive on MessageQueue the XmlMessageFormatter will be chosen by default.
Why is this a problem?
The XmlMessageFormatter wraps information around the actual data being sent and expects certain information wrapped around received data. The ActiveXMessageFormatter and BinaryMessageFormatter serialize the data into binary representation.
Since there is no way to configure BizTalk MSMQ Adapter to use a Message Formatter it is not possible to configure the BizTalk MSMQ Adapter to be compatible with the .NET Applications. The problem had to be solved in the .NET Class Library since it was desired to solve it in one place and it should work for both directions. A possible solution might have been to solve it with a Custom Pipeline Component. However, since there was a clean and elegant solution to the problem that could be implemented in the .NET Class Library we naturally chose that solution.
Solution The solution to the problem was to write a Custom Message Formatter which serializes/deserializes the data to/from a byte stream with UTF-8 encoding witout adding any additional information to the message body.
For more information on MSDN about creating Custom Message Formatter, see this article http://support.microsoft.com/kb/310683