BizTalk for beginners

It's been some time since my last post, for no other reason than I've gone from SharePoint development to BizTalk related activities in recent months.  In any case, let's get to it.

For this first BizTalk related post, I just want to create a beginner's level guide to developing BizTalk projects.  So what are the terms floating around BizTalk; Orchestrations, Itineraries, Maps, Schemas, Send/Receive Ports, Messages, etc.  Now, I can go over the terms for everyone, but it's not necessary to review what's been published hundreds of times already. My focus is to help developers adjust their current mindset to become open to the idea of project compartmentalization.  I have found that it is easiest to consider every aspect of a BizTalk project as an object.  And as a rule of thumb, work from the ground up, meaning that the development effort should begin with the most basic/independent "objects" first.

From a developers standpoint, it's important to become familiar with Schemas first and foremost.  Why? For no other reason than it is how your message content will be defined for specific operations and they are the absolutely most basic aspect of the BizTalk project.  Schemas are defined in Xml format.  Generally, the top elements define the message operations, such as select or delete operations, and their children define the data processed by these operations.  So it is possible to have a field defined several times within one schema.

A big problem I first ran into during development was that I had no idea how to structure my incoming message for unit testing.  Luckily, (and I found this out after many trials) Visual Studio has the ability to generate an instance of a message based on a supporting schema (Just right-click the schema and select Generate Instance).  This comes in handy when running tests againsts maps....

So how do we transfer information from one Message/Schema to another? Maps (There are other methods, but this is just a beginner's guide).  When you create a new mapping file, you are asked for a source and destination schema.  This is where the Schemas you generated come in handy.  Define a source and destination and leverage the mapper as much as possible to map fields from one schema to the other.  There may be fields that require some massaging before transmitting to their respective destination schema fields, and this is where it becomes important to familiarize yourself with functoids.

Functoids are the tools leveraged within a map to translate data.  They come in many forms; String functoids, Mathematical functoids, Date/Time functiods, etc.  Drop these on your map and define their input/output fields, as well as any other information required of them (such as actual C# code for instance).

In review, create your schemas first, then create your Maps.  Leverage Visual Studio to generate an instance of your source message/schema so you can test your maps more precisely.  Don't forget the functoids to translate your data for the destination system.

Ok. Ports.  You have send and receive ports.  As you may have guessed, ports define what data is transmitted into or out of the BizTalk environment.  But it's not enough to discuss ports alone, because ports have several working parts; Port Types, Operations, Communication Patterns, Message Types, Message Directions, Binding.   Where do we start? Start with Port Types.

To discuss Port Types we should first discuss Communication Patterns.  Communication Patterns define the direction in which the data is to be transmitted by the port.  There are two options; One way or Request-Response.  A one way communication pattern is best defined as a pattern that does not require a formal handshake, whereas a Request-Response pattern does.  To best illustrate this, think of the task of running a select query against a database.  The handshake in this instance occurs when the database receives the select query and returns a resultset back.  Conversely, the one way pattern is illustrated as a push event.

Operations are simply actions that define what activity can occur over a port.  So let's say you have a port that connects a SQL database to BizTalk, the operations can be select, insert, and update operations.

Message Directions define the how the message content is used. It can be either as a request or a response, much like you have requests and responses over http.

Message Types are simply the operations defined within the schemas.  As mentioned earlier, schemas are defined in Xml format.  Their top level elements are generally used to define specific operations and their children define the data processed by these operations.

So Ports need a Port Type assigned to them.  Once a port type is selected for a port, the communication direction is automatically selected for it.  For one way ports, this is fine, but on Request-Response ports, you must be cautious that the comm direction is the one you intended, otherwise you may have to manually select the comm direction.  To help you decide, you must determine whether the port will send data and expect to receive data in return, or vice-versa. Bindings on the other hand can be defined either through Visual Studio or the BizTalk Administration console.  In either case, the bindings are basically the system defined connection protocol.

With all of these defined, the Ports then only allow messages that match the message type defined within their Port type. Not much left to be said about that, so on to the next item...

Messages are simple as well. Consider them the data packages defined by an operation instance within a schema.  Thus, a Message Type must be selected for each message.  Again, not much left to say about messages.

Next up are orchestrations.  With Schemas, Maps, Messages and Ports defined, the orchestration binds these objects all together.  Now within the Orchestrations, you setup your Messages, Ports, Port Types, etc. Basically, everything can be setup from within an orchestration file, but you're better off creating your Maps and Schemas first and adding references to them from within the orchestration file.  All other objects are fair game to create within the Orchestration.

Now, tips.  I've found that it is best to have two separate orchestrations.  One to act as a container for your Port Types, and the other to handle the rest.  Why, because you may have several orchestrations within a project file, so it becomes easier to maintain your port types from one source file and reference those types from the other orchestration files.  Also, I've found that my orchestrations generally leverage similar port types when contained within a project.

Well,  that's it for now.  Hopefully, I'll pick up a few more tips before Microsoft buries BizTalk, in which case, I may have to turn to AppFabric.