BizTalk

Cannot locate document specification because multiple schemas matched the message type

Douglas Marsh — Wed, 09 Apr 2008 01:47:31 GMT

I ran into an interesting issue a couple of weeks ago and I thought I would share.

1st, the meat of the post.

If you have extracted the schemas from an XmlSerializable object and deployed those schemas to BizTalk, you can't use that object (or any of its dependant objects) as a BizTalk message type.
Why? Because BizTalk registers XmlSerializable types that are used as messages as schemas. If you have already registered the schema, you will end up with message type duplication.

_____________________________________________________________________________________________________________________________________________________________________
I was working on an application where BizTalk was operating as a SOA messaging bus.
The system was designed to receive data from a number of different systems, map that data to a canonical object model.

The canonical object model consisted of several XmlSerializable classes written in C#.
I used xsd.exe to extract schemas for the objects so that I could use the BizTalk mapper to map to and from the object model.

All of this worked great until I decided to break some common functionality into a separate orchestration.
Since no mapping would occur in the Helper orchestration, I decided to pass the canonical object directly to the orchestration.
I also decided that calling the Helper orchestration via Direct Message Box binding would increase its overall utility and reduce coupling.
The end result was that I created a Message Type and a Port Type that referenced the canonical object instead of the canonical object schemas.

I deployed my changes and submitted a test message.
As soon as my "core" orchestration called the new helper orchestration, I got a familiar error message in an unexpected point in the process.

Cannot locate document specification because multiple schemas matched the message type

My first reaction was total disbelief. I hadn't changed any schemas. In fact, I didn't even redeploy my schema project.
I checked the Schemas folder under BizTalk Application 1 and there was only one schema with the offending namespace#rootnode combination.
So I checked the Schemas folder under <All Artifacts> and there where two schemas... and the new schema was filed under the BizTalk.System Application.

I this point, I was quite confused. You can't deploy to BizTalk.System. It is for system use only.
I dug a little deeper and discovered that my Canonical object C# assembly was the source of the duplicate schema... and then I understood.

My canonical object model was already "registered" in BizTalk via the schema I generated to enable mapping to the object model.
When I used the canonical class as a message type, BizTalk extracted the schema from the serialization metadata and registered the resulting message type with the messaging engine.
Because both schemas are the same, I had duplicate message types.

Luckily the fix was simple. I changed the Message Type and a Port Type to use the canonical object schemas and serialized between the different object representation in the orchestrations before sending the data to the Message Box.

The "Scripting" has [x] input parameter(s), but [y] parameter(s) are excepted

Douglas Marsh — Mon, 31 Mar 2008 01:11:57 GMT

Here is an issue with the BizTalk mapper that resulted in a little hair loss recently.

I was working on a fairly complex BizTalk map that was using scripting functiods to reference functions in an pre-existing .NET assembly.
In a couple of instances, the code in the Helper assembly wasn't quite what needed, so I switched from using the Helper Class function to using inline C#.
Once I changed the functiod to use inline C#, the Configure Functiod Script dialog looked like the screen-shot below.

As you can see, even though the Script type is Inline C#, the configuration for the External Script is still their. This is very important.

For most of the "one-off" functions, I needed more parameters than what was need by the original .NET assembly functions.
So I wired up all of my links, click Build and ended up with the following error.

The "Scripting" functoid has [X] input parameter(s), but [Y] parameter(s) are expected.
Note: X and Y are place holders for the actual number of parameters.

Ok. I've seen this message plenty of time before. I click through each of the scripting functoids in the error list. However, all of them had the right number of parameters.
I clicked build again.

The "Scripting" functoid has [X] input parameter(s), but [Y] parameter(s) are expected.

Ok. Visual Studio must be acting up, so I cycled the entire machine to make sure an potential cache issues are resolved.
Once the machine booted and I got Visual Studio restarted, I tried to build the project again.

The "Scripting" functoid has [X] input parameter(s), but [Y] parameter(s) are expected.

Now I'm mad. I know that the functiods have the right number of parameters. Cycling the box should have fixed any weird "out of synch" errors.
So I start tried a little bit of everything. I disconnect and reconnect links. Nothing. I change the order of the parameters. Nothing.
Finally, I reset the inline script buffer and re-pasted the code... and that function disappeared from the error list.

Hmmm, so what's the difference

Pre-Reset	Post Reset

Resetting the Functoid cleared the External Assembly Configuration.

With this new information in hand, I open the map up a raw XML to take a look at the guts of the situation. This is what I found:

Originally, all of my scripting functoids used methods from the External Assembly. When I decided to use, Inline C#, I modified the existing functiod. Instead of removing the reference to the External assembly function, the functoid added the inline function to the already defined Scripter Code block. Because my inline function required a different number of parameter than the function from the external assembly, I was getting an input parameter count error.

That brings me to the moral of the story, anytime you are changing the way a scripting functoid is being used, hit the "reset" key. It will save you a world of pain.

Workaround from BizTalk 2006 Enterprise Adapters Binding File Issue (KB923733)

Douglas Marsh — Wed, 15 Aug 2007 19:20:37 GMT

If you've ever worked with the BizTalk 2006 Enterprise Adapters (ie Oracle Database, etc) you might have run into the following error when import a binding file or msi:

Could not validate configuration of Primary Transport of Send Port 'portname' with SSO server.
Specify user name and password (Microsoft.BizTalk.ExplorerOM)

More information is available here: http://support.microsoft.com/kb/923733

There is a hotfix available but waiting to get the fix from Microsoft Support can consume valuable development time, so here is a dirty little workaround that I know works for the Oracle Database Adapter.

Extract a Binding File from the offended application(s).
Open the file in your favorite text editor and find the Send and/or Receive Port that is reference the Oracle Database Adapter.
Find the Configuration Property for Password and changed the masked password for the real plain text password.

This will fix your binding import issue until you can obtain the hotfix.

Solving the ‘Object Already Defined’ Error in BizTalk

Douglas Marsh — Thu, 12 Jul 2007 19:07:05 GMT

One of the weird BizTalk errors that's been around since version 2004 goes something like this:

Error    35
symbol 'MyNamespace.DataObject' is already defined; the first definition is in assembly c:\Development\Library\MyObjects.dll
C:\Development\Examples\BizTalk\ObjAlreadDefined.odx    169    50

This error has been blogged about several times. Example 1 Example 2
The standard "fix" is to remove the C# code that is found at the end of the orchestration file by:

Open the orchestration in notepad or as XML
Find (Ctrl-F) #endif // __DESIGNER_DATA
Delete all of the code found below #endif // __DESIGNER_DATA
Save and Recompile

Recently, I discovered a critical issue with that fix.
The code that you are removing is the code that allows BizTalk to export that orchestration as a public object.
So if you use the standard fix, you can't call the orchestration from another orchestration.

I believe that I have found the root of the problem and a much simpler fix.
The "Already Defined" object in my example is a reference object called MyNamespace.DataObject.AbstractData which is defined in MyObjects.dll. This object is used to create a varible instance called DataObject.
If I rename the variable DataObject to DataObject_AbstractData the compile issue goes away.

IMHO, when a Web Reference is added to the project, the orchestration compiler is no longer able to distinguish between part of a namespace and a variable instance of the same name.

So the moral of the story is to make sure your variable names don't conflict with any part of a namespace that in reference by your project. This "rule" goes for any variable.

Copying Elements with No Namespace in XSLT 1.0

Douglas Marsh — Sat, 07 Jul 2007 18:26:13 GMT

XSLT 2.0 is a wonderful standard.
One of the very useful additions is the ability to control the copying of namespace attribute within the copy and copy-of functions.
However, you don't always have the opportunity to work with the latest and greatest standard.

Below is a set of XSLT templates that will copy an Element in it's entirely without dragging along the namespaces.
Here is an example of how to call the template to copy and element to the destination document.
The example creates an Destination Name call Data the contains all of the contents of the Source node XmlData.

<xsl:element name="Data">
    <!—COPY CURRENT ELEMENT without Namespaces -->
    <xsl:call-template name="copy-node" >
        <xsl:with-param name="node" select="/XmlData" />
    </xsl:call-template>
</xsl:element>



<xsl:template name="copy-node" >

<xsl:param name="node" />

<xsl:call-template name="copy-element" >

<xsl:with-param name="element" select="$node" />

</xsl:call-template>
</xsl:template>





<xsl:template name="copy-element" >

<xsl:param name="element" />

<xsl:if test="$element" >

<xsl:element name="{name($element)}">



<xsl:call-template name="copy-attribute" >

<xsl:with-param name="attribute" select="$element/@*" />

</xsl:call-template>



<xsl:value-of select="$element/text()"/>



<xsl:for-each select="$element/*" >

<xsl:call-template name="copy-node" >

<xsl:with-param name="node" select="." />

</xsl:call-template>

</xsl:for-each>

              </xsl:element>

</xsl:if>

</xsl:template>





<xsl:template name="copy-attribute" >

       <xsl:param name="attribute" />

       <xsl:if test="$attribute" >

              <xsl:attribute name="{name($attribute)}">

                     <xsl:value-of select="$attribute" />

              </xsl:attribute>

       </xsl:if>

</xsl:template>

Keep Common Message and Port Types in an Empty Orchestration

Douglas Marsh — Thu, 05 Jul 2007 23:23:12 GMT

I'm working on a project where we are using a lot of common message types to abstract message handling logic.
Early on it became a real pain to recreate the same Multi-part message types and Ports for each Orchestration that was using these common messages.
To simplify development and maintenance of these types, I created a "Common Types" orchestration.
There is no logic in the Orchestration; it just defines commonly used schemas as Multi-Part Message Types. The associated Port Types are also defined.
Just define the type as public and reference the Common Types projects in the other Orchestration projects and you are ready to go.

Don’t Forget the Namespace!!!!

Douglas Marsh — Wed, 04 Jul 2007 16:21:43 GMT

This is just a quick tidbit. I will expand in an article that I'm writing on BizTalk mapping and custom XSLT.

When you are using Inline XLST in a BizTalk map, if the document that you are working uses namespaces, you have to explicitly declare the namespace that the element(s) that you are building belongs to.

Compiling the map will not fail but you can run into some really nasty runtime issues that are extremely hard to debug.