May 2008 - Posts

PDC08 - Meet me there
29 May 08 09:20 PM | Johan Hedberg | 3 comment(s)

PDC08 has opened for registration. I'll be there, will you?

 

Filed under: ,
BAM Tracking and Failed Messages, and a new issue of BizTalk HotRod
22 May 08 09:47 PM | Johan Hedberg

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.

LINQ Material
22 May 08 08:40 PM | Johan Hedberg

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.

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

Filed under: , ,
BAM Poster available at Microsoft Download
19 May 08 07:03 AM | Johan Hedberg

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?

Filed under: , ,
LINQ in BizTalk - Follow up
16 May 08 05:08 PM | Johan Hedberg

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:

  1. 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.
  2. 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:

  1. GAC LINQHelperLibrary.dll. (If you want to build it yourself do so using Visual Studio 2008 first)
  2. Build and Deploy BizTalkLINQ.
  3. Configure the orchestration by assigning it a host instance, a receive and a send port (use the XML pipeline).
  4. Feed a Purchase Order document into the Receive Port. A sample file is included in the sample (in the BizTalk LINQ\FileDrop folder)  - it originates from Sample XML File: Purchase Order in a namespace.
  5. 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

Filed under: , , ,
BizTalk database sizing statistics
07 May 08 09:15 PM | Johan Hedberg

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?

This Blog

News

    Messenger

    Twitter Updates

      Follow me on twitter

      Visitors

      Feedburner Subscribers

      Locations of visitors to this page

      Disclaimer

      All material is provided AS IS voiding any thinkable or unthinkable effect it might have for any use whatsoever. There... is that clear enough ;)

      Pages

    Syndication