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<<

Really nice BizTalk Admin tool, BizTalk 360

May 3, 2011 / Comments Off on Really nice BizTalk Admin tool, BizTalk 360

Today I stumbled upon a really nice BizTalk admin tool. (thanks google reader)

Have a look at it >>here<<

It’s a kind of Silverlight BizTalk Administration console with quite a few extra’s.
Really good work !

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