Having seen my fair share of compilation errors over time, I usually know what the cause is right away.
This time however, I couldn’t think of anything that could be wrong:
It was just a basic orchestration, receiving a message of type A, transforming this message into some other format B and sending it out to an external system for further processing. No fancy logic yet, that was still to come.
After some digging around I found the culprit:
The root element in one of my schemas was named ‘task’, which is one of the reserved keywords in the XLANG/s language. For a complete list of reserved XLANG/s words take a look at: http://msdn.microsoft.com/en-us/library/aa547020.aspx.
When building the solution, the compiler generates .NET classes for each schema. When you use reserved names, this results in invalid class names.
Figure 1 Weird build errors
Unfortunately the particular schema was not within my control, since it was part of a third party web service. So renaming the element was out of the question.
So what to do next?
Luckily the designers of the BizTalk platform have provided a solution for these kinds of situations, by adding a property called ‘RootNode TypeName‘ to the schema designer. This allows you to specify an alternative name to use for the generated .NET class for the selected root element.
This way the code can be compiled without a need for modifying the actual node name in the schema and corresponding instance messages, which is generally not feasible when using third party components.
Figure 2 Solution to weird build errors
Note:
When you change the ‘RootNode TypeName‘ of an element like this, all code references to the corresponding element schema will become invalid. You need to update these references manually (there is no auto-update like when you are renaming a class or method during refactoring).
I always use multi-part message types (as one of the Best Practices for BizTalk development), so I only had to adjust the type definition and I was good to go.
Subscribe to our RSS feed