Category nameļ¼šBizTalk 2006 R2 SP 1

I think this is a bug in the orchestration engine but I am not really sure.

May 4, 2011 / Comments Off on I think this is a bug in the orchestration engine but I am not really sure.

Today I had a very weird problem.
I submitted a message via a WCF webservice and had an orchestration listening on the messagebox for that particular messagetype.

The orchestration does some serious data-massage and needs to store the converted message a couple of times. For this I created some helper components that store the changed message in a database (all the logic is in a callable orchestration).
Below is a sample of the orchestration that went wrong.

So it’s nothing too fancy and I have used this pattern a lot and never had any problems. Until today…….
If the message is sent to the messagebox, there could be a failure (no subscribers) this will kick in the errorhandeling and the message is send to the Faultportal where you can resubmit the message.
But today things went a little different than I was used to……

Because there was  was no subscribtion I would expect ONE routing failure, but I got TWO routing failures……. So I did some investigation on those routing failures….. Below is a screenshot of this :

The Field marked with the red square is the ID that I get back from the Database insert (Callable orchestration)….. It is a distinguished field so it sits on the contex of a message.
Thats why I can see these are two different routing failures, and there were two calls made to the Database to store the message. (So the callable orchestration was called twice !)
And both routing failures are from one orchestration. See the instance ID in the header of the window.

For sure I have been looking half a day in the message box for that hidden subscription somewhere but finally I gave up there was nothing, everything seems to be all right…

After a day looking, I think i have found it. First let’s describe what should happen.

  1. Message is received
  2. Some transformations are done
  3. New message is stored in the DB and we get the ID back
  4. Message is Send off to the Messagebox
  5. Subscription fails
  6. Errorhandler kicks in and writes the message to the FaultPortal.

Now let’s rewrite this with the things that happen :

  1. Message is received
  2. Some transformations are done
  3. New message is stored in the DB and we get the ID back
  4. Message is Send off to the Messagebox (First Routing Failure)
  5. Subscription fails
  6. (For some reason we start at two again but  this time with the knowledge that publishing will fail)
  7. Some transformations are done (step 2 again !)
  8. New message is stored in the DB and we get the ID back (step 3 so we get a new ID)
  9. Message is Send off to the Messagebox (Second Routing Failure)
  10. Errorhandler kicks in and writes the message to the FaultPortal.

This is definitely not what I was expecting.
So I had a close look at my other orchestrations that do work with almost the same construct and I did find a very small difference that made all the difference.
Below is a screenshot of this.

 Now the Expected flow and the flow that actually happens are again in sync :

  1. Message is received
  2. Some transformations are done
  3. New message is stored in the DB and we get the ID back
  4. Message is Send off to the Messagebox
  5. Subscription fails
  6. Errorhandler kicks in and writes the message to the Faultportal.

I think this is a bug in BizTalk, but I am not really sure about it so if you think you know why this happens please leave a message on my blog.

It ran on a machine with BizTalk 2006 R2 SP 1, but since the XLANG engine did not change that much this could happen in all BizTalk versions.

Ntrace is available for Visual studio 2010

May 3, 2011 / Comments Off on Ntrace is available for Visual studio 2010

Ntrace is a great tool for logging. It has virtually no impact and is blazing fast. Finally it’s been migrated to Visual studio 2010.
So now I can start building my BizTalk Bestpractice toolbox with it. The author of Ntrace can probably explain best what it is…

What is this ETW thing?

Event Tracing for Windows is a kernel-level tracing service that has been around since Windows 2000. Since it’s baked right into the kernel, it is extremely fast. Most of the developers that use ETW are writing drivers, but why should they have all the fun?

Why should I use ETW?

ETW Tracing has several benefits over the tracing classes provided with the .NET Framework. Most importantly, ETW tracing can be turned on and off without having to restart the application, but it also has features like built-in high performance circular logging (a circular log is one that never grows above a specified size by flushing out older trace messages), and the ability for you to capture the logs from multiple sources into a single trace session.

What is this preprocessor and why do we need it?

Put simply, to maximize application performance when tracing is not enabled. In a perfect world, an application’s performance when tracing is disabled would be identical to one where tracing wasn’t included at all. The problem is that your code is only compiled once; if those trace calls are in there, they’re GOING to get called, and while the ETW functions return quickly when tracing is disabled, the runtime still has to evaluate trace arguments, allocate memory, construct method call stacks, and so on. The application performance would be even faster if the functions were never called in the first place. How much faster is it? Here’s an example: Let’s write a simple application that has a function named DoSomething.

static int DoSomething(String arg0, int arg1, long arg2, DateTime arg3)

As you can see, DoSomething in this case simply returns a value and does no other calculations. It should be blazingly fast, right? Well, it is, but there’s still the overhead of the method call. To demonstrate this, let’s run two loops: one that ends up in a call to DoSomething one million times, and another that will shortcut the call. To do this, we’ll create a method named DoRun that will call DoSomething unless the caller has specified that it should bypass the call entirely. If the value passed to shortcut is true, we’ll skip the DoSomething call altogether.

static void DoRun(bool shortcut)
{
  DateTime start, stop;

  start = DateTime.Now;
  for (int index = 0; index < 1000000; index++)
  {
    if (!shortcut)
    {
      Program.DoSomething("Hi there!", 42, 42L, DateTime.Now);
    }
  }
  stop = DateTime.Now;

  Console.WriteLine(
    "Shortcut {0}: {1} milliseconds", 
    shortcut, 
    (stop - start).TotalMilliseconds);
}

To get our results, we will now call DoRun twice; once with shortcut set to False, and again with shortcut set to True. On my machine (a 2GHz Core2Duo running Windows Vista x86), the results are:

Shortcut False: 546 milliseconds
Shortcut True: 15.6 milliseconds

In other words, it was 35 times faster to completely bypass the function call. That’s nearly two orders of magnitude! Now, imagine if you were doing something even more complicated there such as calling ToString() on an exception or dumping a string containing the values of all of the properties of the object you are working on and you should be able to see that you get a rather large performance boost by skipping those calls completely. NTrace’s preprocessor provides your code with this boost by automatically injecting conditional statements around your trace calls for you, allowing you to focus on writing your code instead of remembering which conditions to check.

 

I have been waiting for this tool to upgrade to 2010 for a long time. So see what it is and grab your copy of Ntrace >>here<<

Interessante Blog Postings

June 30, 2010 / Comments Off on Interessante Blog Postings

Gedurende een bepaalde periode kom je op het internet interessante zaken tegen of zijn er interesante blogpostings gedaan. Soms google je wat en kom je een oude maar zeer interessante blogposting tegen. In dit artikel wil ik een aantal van deze blogpostings/blogposters/artikelen aanstippen.

 

Maxime Labelle

 

Heeft een interessant blog waar hij af en toe diep ingaat op de werking van BizTalk. Er zitten veel code voorbeelden bij. Enkele noemenswaardige zaken zijn onder andere:

A Base Class for Building Custom Pipeline Components

Een handige base class welke het leven van een BizTalk ontwikkelaar behoorlijk kan versimpelen. In plaats van iedere keer weer alles van de grond af aan op te bouwen zorgt deze base class standaard voor een aantal zaken. Je hoeft eigenlijk alleen nog maar de Execute van de pipeline te programmeren. Erg handig.

Streaming Data in and out of an SQLServer 2005 Database

Interessant artikel over het opslaan van BizTalk Berichten in een database. Absoluut de moeite van het lezen waard.

 

Als je nog wat verder snuffelt op zijn blog zul je zien dat er echt interessante en nuttige zaken tussen staan.

 

Validatie functie BizTalk

 

Gebruikers van de “BizTalk Best Practice” zullen wel weten dat ik een groot voorstander ben van het valideren van xml nadat er gemapped is. Een map biedt immers geen enkele garantie met betrekking tot het valide zijn van het resultaat. Voorheen gebruikte ik daarvoor altijd de ‘Cool XSD Validation Function for Orchestration van de ‘Arch Hacker’ . Deze validatie functie is inmiddels stokoud en compileert niet zonder warnings meer in .Net 2.0 en hoger. Met een aantal ‘Pragma Directives’ kon het nog net compileren zonder warnings maar dat de code ondertussen sterk verouderd is blijft een feit. Onlangs kwam ik een nieuwe versie tegen die wel voldoet aan 2.0. Daarnaast biedt deze wat meer functionaliteit.

 

BizTalk Service Pack 1, Fix Pack1, Fix Pack 2 !

 

Begin dit jaar is voor BizTalk Service Pack 1 uitgerold en zodra deze geïnstalleerd was op de ontwikkel server van de klant waar ik op dit moment zit werkte zaken niet meer zoals ze zouden moeten werken. Omdat dit bij Microsoft Support liep was ik op de hoogte van een BizTalk 2006 R2 SP1 Cumulative Update 1. Hierin waren een aantal zaken opgelost, maar het belangrijkste issue stond nog steeds open. Zeer onlangs kreeg ik te horen dar er nu ook een BizTalk 2006 R2 SP1 Cumulative Update 2 beschikbaar is. Blijkbaar was Service Pack 1 niet de meest geslaagde update uit de BizTalk geschiedenis.

 

 

BizTalk 2006 R2 SP1 alters the disassembling behaviour of a Receive pipeline !

March 19, 2010 / Comments Off on BizTalk 2006 R2 SP1 alters the disassembling behaviour of a Receive pipeline !

In my previous post I mentioned i noticed a change in the disassembling behaviour of BizTalk Server 2006 R2 after installing SP 1.

After I got home after work I sat down and looked somewhere on my harddisk for an old version of  a BizTalk 2006 Virtual PC. After a while I found one that was approximately  one and a half year untouched. So I sat down and Fired it up…

First get all the updates that have been since then, geeeeeez there have been many, I had about 80 of them and i completely forgot that some of them took ages to install (Visual Studio SP / Several Dotnet’s etc). Whel about two hours later i could test my scenario.

I created a solution and I copied (used cut & paste) the envelope and body from the previous post to this solution. Add a strong key, deploy and I was off to test.

With the pre SP1 BizTalk 2006 R2 (On Windows Server 2003 R2) I got the results I expected.

So i copied the entire VPC to a new location and added the extension SP1 to the machine name to distinguish it from the other. Then i downloaded and installed Service pack 1 for BizTalk 2006 R2.

After a reboot I was good to go….

To my dissapointment i got the same result as on work. Below is a

Event Type: Error
Event Source: BizTalk Server 2006
Event Category: BizTalk Server 2006
Event ID: 5719
Date:  3/19/2010
Time:  10:42:38 PM
User:  N/A
Computer: TITANNIC
Description:
There was a failure executing the receive pipeline: “Microsoft.BizTalk.DefaultPipelines.XMLReceive, Microsoft.BizTalk.DefaultPipelines, Version=3.0.1.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35” Source: “Pipeline ” Receive Port: “Batched Receive” URI: “C:ProjectsService Pack TestService Pack TestTestInput*.xml” Reason: The disassembler found an envelope that does not have the body element.

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

So i can definitelye say : SP1 for BizTalk 2006 R2 alters the default disassembling behaviour ! ( And in my case broke my solution)

For everybody who wants to test, I have added a very small solution to demonstrate what goes wrong…..

  • Recent Posts
  • Recent Comments
  • Archives
  • Categories
  • Meta