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.

Image may be NSFW.
Clik here to view.

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 :

Image may be NSFW.
Clik here to view.

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.

Image may be NSFW.
Clik here to view.

 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.