≡ Menu

Cannot locate document specification because multiple schemas matched the message type


Currently working on BizTalk 2006 applications, during testing freshly created and deployed version of one application, I got error at failure executing the receive pipeline:


There was a failure executing the receive pipeline: “Microsoft.BizTalk.DefaultPipelines.XMLReceive, Microsoft.BizTalk.DefaultPipelines, Version=, Culture=neutral, PublicKeyToken=31bf3856ad364e35” Source: “XML disassembler” Receive Port:

Cannot locate document specification because multiple schemas matched the message type

Basically message type is combination of root node and namespace is one of the most typically used to promoted properties for subscription, in fact almost every orchestration uses Message Type as part of its subscription. So it is important to keep message type unique across the different schema deployed on server.

Possible solution:

Solution Number one :
If schema are same used in different application. Make an extra project for schemas, and placed require schemas there. Compiled the new project and created dll for schema in target applications. In this way we can exclude this exception.
Solution Number Two:
One solution is that if we are using xml Receive then in the pipeline definition at receive location level, set the “Allow Unrecognized Documents” to true. This will solve the schema conflict issue.

Solution Number Three :
if schema are different, but same namespace and root name then
create a new send port for service, go to send pipeline properties and set DocumentSpecNames property to fully qualified name of schema in format <schema type>+<root name> ,<schema assembly full name>. This Pipeline property tells BizTalk exact location of schema to be loaded and thus avoid conflict

for example:

ReportLostV2.CardReportLostPC_Package_STORED_PROCEDURES_2+STOP_LIST, Card.ReportLostV2, Version=, Culture=neutral, PublicKeyToken=9b51853b6987xxxx








you can get DocumentSpecNames value from SchemStrongName context property.

{ 0 comments… add one }

Leave a Comment