Archive for the ‘BizTalk’ Category

‘Lost’ messages from non-transactional called orchestration

4 June, 2007

I encountered a strange issue today which had me stumped – messages I was sending from an orchestration were never getting picked up and processed by subscriptions, but neither were they suspending or generating any error messages at all. It’s as if they were falling into a black hole never to be seen again!

The scenario, which you can test yourself, was that I had two orchestrations (A and B). A calls B, B sends a message to the message box, then A sends a message to the message box. B’s message was ‘disappearing’. Tthe HAT tool would show that it had been processed successfuly, and even more strangely if I put a suspend shape

The answer was of course transactions. A was a long-running transactional orchestration, whereas B was marked for no transaction. Switching B to be transactional solved the problem.

I could reason about why this might be the case, and in a strange way it does make some kind of sense, but needless to say this is a counter-intuitive and rather annoying behaviour! I would expect actions taken in orchestration B to join in with the transaction of the calling orchestration, rather than disappearing entirely!

Unable to promote long context properties

10 May, 2007

I was busy beavering away on a BizTalk solution today, setting up a context property of type ‘long’, when I hit an error in a receive pipeline:

There was a failure executing the receive pipeline: “Microsoft.BizTalk.DefaultPipelines.XMLReceive, Microsoft.BizTalk.DefaultPipelines, Version=, Culture=neutral, PublicKeyToken=31bf3856ad364e35” Source: “Pipeline ” Receive Port: “MasterReceivePort” URI: “C:\dev\BtsDrop\MasterIn\*.xml” Reason: Cannot convert “Id” to “long” because the type is not supported. 

I had mapped this property to a data field on a message type, but was inheriting from MessageContextPropertyBase for the property. Aha! I thought, this is because I’m using a context rather than data property – but no, in fact the same error occurs for normal data properties too.

Seems BizTalk just does not support ‘long’ typed promoted properties!

Changing the type to string solved the problem.

As a side note on why I wasn’t using a MessageDataPropertyBase property: I was faced with a situation where sometimes this property would come from the message, and sometimes it would not. I find this often happens when trying to build generic routing patterns. Luckily, BizTalk promotes MessageContextPropertyBase properties in the same way as data properties if they are used to promote a property within a schema. Charles Young has a good post on this type of property.

BizTalk Web Services Publishing Wizard – can’t find schema?

9 May, 2007

Have you ever find that try as you might you just can’t find your schema in the schema browser when deploying schema files as web services?

I just found an annoying gotcha in the Web Services Publishing wizard for BizTalk, that also seems to affect the WSE Web Services Publishing wizard. Although the schema browser looks for your schema assemblies in the file system, it will actually pull these assemblies from the GAC. So if you haven’t deployed your BizTalk solution to your local machine recently, it may pick up an old version and display an old list of schema files. One to watch out for!

BizTalk Services SDK

9 May, 2007

Some how in the last couple of weeks I managed to miss the public release of the BizTalk Services SDK, over at

If you haven’t seen it already, the SDK is a big step forward for companies using BizTalk as a key component in their SOA platform. It’s billed as a sneak preview of the Internet Service Bus initiative. Key features include:

Identity Services – support for WS-Trust providing authentication, access and federated identity.

Connectivity Services – supporting network bridging and relaying, multicast services and globally addressable naming.

And the feature I’m most excited about: BizTalk Workflow Services – a hosted instance of Workflow Foundation.

For a proper introduction, have a look at this eWeek article.

I’ll post more when I’ve had a proper dig through the SDK…

Tips and tricks for BizTalk

9 May, 2007

May’s MSDN Magazine has a very useful tips and tricks for BizTalk article – well worth taking a look if you haven’t seen it already.

Changing the refresh period for the Business Rules Engine

8 May, 2007

By default the MS BRE only refreshes rules sets and vocabularies every 60 seconds. This is fine for production environments but more than a little annoying for the typical  update/deploy/test cycle of rules development.

In particular you can come a cropper of this limit when writing unit tests that rely on rule policies. Typically in a unit test you’ll want to deploy a particular rule policy and then test against it, but with automated tests you’ll find you hit messages like ‘RuleSet not Deployed’ as the engine will not pick up the new policy quickly enough.

Thanks to my colleague Dan for pointing out the following changes. Firstly this period can be specified in the BTSNTSvc.exe.config configuration file for BizTalk. Add the following two sections:

section name=Microsoft.RuleEngine type=System.Configuration.SingleTagSectionHandler />

<Microsoft.RuleEngine PollingInterval=5/> 

However that isn’t enough, as this only changes the refresh period for rule policies executed by the BizTalk engine. To change the period for the rules editor, you also need to change the following registry key:

How to invoke static methods from the rules engine

8 May, 2007

A colleague pointed out a rather surprising tidbit about the BRE to me recently – that by default it is not possible to invoke static methods on .Net classes.

This caught me out and was not obvious to spot. I had various string constants defined in a .Net assembly and was comparing them to fields in a message instance, but finding that the comparison was failing. When I tested these rules using the Business Rules Composer it seemed these conditions were not even being tested!

The simple solution is a registry change, modifying the key:


and giving it a value of 1.

‘unknown system exception’ error when working with orchestrations

8 May, 2007

Every now and then I run into the most annoying of BizTalk errors – ‘unknown system exception’ – when working with orchestrations. Sometimes this would be fixed by a restart of Visual Studio, but today I hit the problem and it just wouldn’t go away.

It seems this error can occur if you have unreachable Call Orchestration shapes in your orchestration. Specifically if you have a Decide shape where the conditions are hardcoded boolean literals. For example if one branch has the condition ‘true’ and the other branch is never reached, but the other branch contains a Call Orchestration shape. I often do this kind of thing when working on an orchestration, if I’m putting together the flow but haven’t yet worked through the logic.

 I can only presume that compilation is attempting to optimise away the other loop, but getting in a twist somewhere along the way. Nevertheless it’s easily fixed by replacing the literal with a boolean variable.

Schema file type name collision

4 May, 2007

Whilst putting together some schema files for BizTalk I came across this error:

“This schema file has a TypeName that collides with the RootNode TypeName of one of its root nodes. Make sure that they are different”

This signifies a collision between the type name that BizTalk allocates to the schema file itself (specified in the properties window after clicking on the file) and one of the type names specified for a root node inside the schema (specified by the property of the root node called ‘RootNode TypeName’).

The magic property to fix this problem is ‘Root Reference’ (in the properties for the <Schema> entry at the top of the node tree). This identifies the root node type that corresponds to the type for the schema. The default behaviour is to pick the first root node, and if the root node that shares a type name is not the first then you’ll see this error. Simply change the property to the relevant node and compile away.

In my scenario, I’d included a different schema that contained a number of complextype definitions. This pushed the root element down so it was no longer the first root node and this error popped up.