…that can be seen here looks exactly like the SQL Server logo and is very similar to the System Center logo. I wonder why and which server product is next?
Category: BizTalk
Interviewing for BizTalk employment
More then a few times I have seen interview questions that people post on their blogs for use when interviewing people for a BizTalk Server job opportunity. I never use interview questions. I’m not sure if the market and access to BizTalk developers is so good in these places where they use the questions that you can pick and choose to get the “best” one. Here, the demand is far greater then the supply it seems. Especially for companies that might not have an outright image as an attractive IT employer. I try instead to form the questions so that they fit into a natural conversation. I suggest that an experienced BizTalk developer and/or architect can derive how knowledge-able the interviewed individual is from how he (or she, but to be fair they are mostly he) talks about his experience with BizTalk Server, which parts he has been responsible or involved with and things like that, without turning it into an interogation. Most of the time (given the lack of supply) the BizTalk Server experience is only part of the picture anyway. I’m not claiming to be a person termometer in any way, but just listening to someone and what and how they offer information about their previous engagements can tell you alot, often enough. Now on the other hand, if you do find the person to appear knowledge-able, and would really like to make sure before deciding to pay that person that far higher the average salary, by all means, do a deeper knowledge based interview. But to pull that of you really need to already have someone that knows his stuff to evaluate the answers.
BAM Tracking and Failed Messages, and a new issue of BizTalk HotRod
Mikael Håkansson has a post called How to Replace Tracking with BAM in BizTalk that features a performance comparison he made for disabling global tracking in BizTalk Server 2006 and how that would look if you replaced that with BAM – in hard figures. He also posts a sample solution and talks about concepts such as activities and tracking profiles. The post mentions that the approach is meant for tracking successful messages and he suggests (as an example) the use of a WMI service to catch suspended messages. A concept that he leaves out is the tracking of failed messages using BAM and failed message routing. As a fluke, at roughly the same time his post was published there was a white paper released at MSDN that describes the process of creating an activity, tying that to a tracking profile by connecting it to relevant context properties and deploying it for a failed message routing scenario, see How to Track Failed Messages in BAM. It’s a very basic step-by-step article. Now…I am not taking a stance to say that failed message routing is the way to go. There are many considerations to take into account before determining to opt for that or for allowing messages to get suspended. I just wanted to post this to tie these two articles together since I think they are both good reads and gives you a view of what is required to replace tracking in BizTalk with BAM, for both successful and failed messages. And what the performance benefits might be for your solution.
Also check out the new issue of BizTalk HotRod that (among other things) also discusses Failed Message Routing and how to log these message, but does so in the context of the ESB Guidance.
BAM Poster available at Microsoft Download
The BizTalk Team announced that a new poster, the BAM poster, will see the light of day. I really like the posters that have been released as companions to the BizTalk Server documentation. I’m not really the graphical guy, at least not when it comes to creating graphics, but that doesn’t stop me from being just as critical as the next guy when it comes to reviewing graphics created by others 😉
For something that is said to “provide an overview of the entire BAM life cycle”, and since it contains other types of data flow, I would have liked to see something about partitioning and archiving. I see that as an important advantage of BAM, to get an thought through process for data handling out of the box. At least, that’s the story I would have added on top of what is in the poster if I would be explaining BAM to someone. Or is that to low level?
LINQ in BizTalk – Follow up
I’ve previously posted my ideas about using LINQ in BizTalk. At that point it was just theories, and following the links in the comments section of that post I wasn’t the first to have them. Thanks to the red bits/green bits approach BizTalk Server can use LINQ today by using Visual Studio 2008 side-by-side with Visual Studio 2005. This post provides a working sample that does just that – uses LINQ in BizTalk by utilizing a helper assembly, built using Visual Studio 2008 and the .NET Framework 3.5, from a BizTalk Server 2006 R2 Orchestration (built using Visual Studio 2005). If you do have both Visual Studio 2005 and 2008 available, and this doesn’t conflict with the rules of engagement you have as far as your environment goes, I think it’s worth looking at.
The sample consist of the following parts:
A library project named LINQHelperLibrary, with a method that takes in a XLangMessage, extracts the stream, wraps the stream in an XmlReader and feeds that into the constructor for an XElement. Using that XElement a LINQ to XML statement is performed to extract the totalt amount of a Purchase Order document. This library is built using Visual Studio 2008 and the .NET Framework 3.5 compiler.
A BizTalk project named BizTalkLINQ, that contains a generated xsd schema and a very simple orchestration with an expression shape that calls the LINQHelperLibrary and passes in the message, receives the response and outputs a Trace.WriteLine. This project has a reference to LINQHelperLibrary as well as (an explicitly added) reference to System.Xml.Linq.
The sample requires the following:
BizTalk Server 2006 (I used R2)
Visual Studio 2005
.NET 2.0 and .NET 3.5
I am including the dll built using Visual Studio 2008, but if you wan’t to build it yourself you’ll need Visual Studio 2008.
To run the sample do the following:
GAC LINQHelperLibrary.dll. (If you want to build it yourself do so using Visual Studio 2008 first)
Build and Deploy BizTalkLINQ.
Configure the orchestration by assigning it a host instance, a receive and a send port (use the XML pipeline).
Feed a Purchase Order document into the Receive Port. A sample file is included in the sample (in the BizTalk LINQFileDrop folder) – it originates from Sample XML File: Purchase Order in a namespace.
Optionally display the value returned by the helper assembly by using DebugView while it runs. If you don’t there really isn’t muc to see…
Note: This isn’t a LINQ to BizTalk implementation – implementing a provider for BizTalk is a totally different matter, this just uses LINQ to XML from within BizTalk.
Download: biztalklinq.zip
Be Logical - Notes from Johan Hedberg 