Geeks With Blogs
Paul's Petrov Whiteboard [BizTalk, Enterprise Application Integration, Business Process Automation, SOA, .NET]

Although current BizTalk release does not support .NET generics it does support concept of genericity at the message level. It is possible, of course, through "untyped" messages or messages that don't have specific type attached to their context. Such messages are represented as System.Xml.XmlDocument type in orchestrations. To read more on message typing aspect of BizTalk please refer to this excellent post by Charles Young. I'd like show practical examples of applying generic programming to typical BizTalk tasks. These examples will help to make your BizTalk solutions leaner, more flexible, and easier to maintain.

Let's start with very common pattern where BizTalk is used as merely message dispatcher - Message Broker. The goal of our generic message broker will be to dispatch any type of message to its destination decided at runtime. So, by avoiding type dependency and early routing binding (basically, hardcoding) we would get single very flexible orchestration which can easily handle requirement changes - one of the top goals of good application design.

Some things to consider before creating BizTalk orchestration. First, we need to figure out how and where to store input to output destination map. Since, it's just key-value pairs, application configuration file will work fine. In my work, I prefer to keep collections of homogenous setting like this in separate xml config files and read them in custom XmlSerializable map (objects like NameValueCollection or Dictionary being non XmlSerializable won't work in orchestration unless placed inside atomic transaction scope). I'll place them in application configuration file now to keep it simple. Next thing, is to decide what to use as a key. Since messages all of the same type to orchestration, we should select something that uniquely maps message to destination. Let's assume that per our requirements it's a input file name, although it can be anything inside message content. The destination will be expressed as complete URL, i.e. [protocol]://[path]/[fileName], for example ftp://myserver/files/dest.dat. So, the map entry can look like this: <add key="emp.dat" value=file://myserver/incoming/employees.dat />. I use .dat extension here just to emphasize it's applicable to any files and not only XML.

Once questions have been answered, the orchestration comes together fairly quickly. On the global level it has one input port, expression to read routing configuration, Decide shape to branch on routing availability condition, and dynamic send port. Receive shape receives input message of XmlDocument type. Output message of the same type is sent through dynamic send port after routing address and all properties have been set:

DispatchMessage orchestration high level view

Inside Decide_IfRoutingAvailable shape there are two branches of execution. If routing address is found then it will read destination URL from the configuration and select transport protocol. Otherwise, destination will be set to the backup location from configuration file in order for the message to be preserved:

Once protocol is identified, we can create output message and set its properties and destination address. In case if protocol is not supported, we route message to the backup location using the same dynamic send port. That's how it looks inside Choose Protocole decide shape:

DispatchMessage - select protocol

Let's dive into ConstructFtpMessage shape, to see how properties set:

msgOutput = msgInput;
msgOutput(FTP.UserName) = System.Configuration.ConfigurationManager.AppSettings["FTPUserName"];
msgOutput(FTP.Password) = System.Configuration.ConfigurationManager.AppSettings["FTPPassword"];
msgOutput(FTP.PassiveMode) = System.Convert.ToBoolean(System.Configuration.ConfigurationManager.AppSettings["FTPMode"]);
msgOutput(FTP.RepresentationType) = System.Configuration.ConfigurationManager.AppSettings["FTPRepresentationType"];
msgOutput(FTP.BeforePut) = System.Configuration.ConfigurationManager.AppSettings["FTPBeforePut_" + receivedFileName.ToUpper()];
msgOutput(FTP.CommandLogFileName) = System.Configuration.ConfigurationManager.AppSettings["FTPCommandLog"];

First line simply copies our generic input message content to the output message. Susequent lines set FTP properties from configuration file. Then, all that left is to set destination URL on dynamic port and send output message through it:

DestinationSendPort(Microsoft.XLANGs.BaseTypes.Address) = destUrl.ToString();

As the result, we have a single orchestration that can handle hundreds of different message schemas and multiple protocols. Another positive outcome is that deployment greatly simplified. The application has one orchestration, two ports, but only one of them is bound at deployment time. Also, note no schemas, no maps at this time, we will add them later when we augment application with content transformation functionality.

Posted on Tuesday, January 15, 2008 12:13 AM BizTalk , EAI | Back to top

Comments on this post: Generic BizTalk Patterns: Message Broker

# re: Generic BizTalk Patterns: Message Broker
Requesting Gravatar...
i must say ... this is very cool indeed! a very simple concept but often the best things in life are the simplest!
Left by Ryan CrawCour on Jan 17, 2008 1:53 PM

# re: Generic BizTalk Patterns: Message Broker
Requesting Gravatar...
Excellent, simplistic and realistic......

Thanks a lot
Left by Bugs on Nov 11, 2008 6:54 AM

# re: Generic BizTalk Patterns: Message Broker
Requesting Gravatar...
Very good example!!!. It would be great if you share code for this article.
Left by sudhakar reddy on Apr 18, 2009 1:10 PM

# re: Generic BizTalk Patterns: Message Broker
Requesting Gravatar...
The source code is in the next article:
Left by Paul on Apr 26, 2009 11:12 AM

Your comment:
 (will show your gravatar)

Copyright © Paul Petrov | Powered by: