-
-
PDC08 has opened for registration. I'll be there, will you?
-
-
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.
-
-
The presentation made available for download through this post is in swedish. The code however is "international". First of I would like to list what I think are two of the best getting started with LINQ resources available online.
-
-
All the
MSDN Nuggets of Microsoft UK, but specifically
Decomposing LINQ by
Daniel Moth that is the best C# 3.0 / LINQ features demo I have ever seen to date. Enough so that I used the approach introduced in my own demo.
With that said, the material provided here is the LINQ presentation and demo code that I used for the LINQ presentation I held.
Presentation: The mechanics of LINQ.pptx (in swedish)
Code: LINQDemo.zip
-
-
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?
-
-
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).
-
-
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
-
-
In the hope that this might help someone who is tasked to estimate the size of BizTalk Server 2006 databases, I'm offering a few statistics.
These statistics comes from an engagement that uses very few orchestrations and more or less does messaging only - ie do all the work in pipeline components and/or maps. Just to give you a hint of the volumes we are talking about - here are some numbers from the beginning of May:
|
AvgRecvKB |
AvgSndKB |
Count |
Month |
Day |
|
812 |
7274 |
476 |
5 |
1 |
|
479 |
4111 |
1130 |
5 |
2 |
|
970 |
10877 |
444 |
5 |
3 |
|
680 |
10328 |
357 |
5 |
4 |
|
443 |
3288 |
1114 |
5 |
5 |
Now we have only been doing the volumes specified in the above table for roughly two months, before that is has been smaller but incrementally increasing (it would too drawn out to give the full story). I know that gives you a somewhat incomplete background, but that's just how it is. Here are the sizes of the base BizTalk Server databases (all figures are in MB).
|
Database |
Data |
Log |
Total |
Free |
|
BAMPrimaryImport |
655 |
380 |
1034 |
637 |
|
BizTalkMgmtDb |
46 |
43 |
87 |
44 |
|
BizTalkMsgBoxDb |
253 |
556 |
807 |
758 |
|
SSODB |
13 |
13 |
25 |
15 |
I guess I should also mention that we have the BizTalk backup jobs doing full backups on a daily basis, as well as trasaction log backups every 20 minutes, and the DTA purge and archive setup for 12 live hours and 7 hard days. We have roughly about 300 receive ports, 1000 receive locations and 400 send ports and 20 or so orchestrations. Regular BizTalk Tracking hasn't been globally turned off, but is at a basic minimum. A BAM Tracking component does the real tracking as far as monitoring goes.
Do you have any statistics that you could perhaps share with me?