Error to Solve

“Cannot locate document specification because multiple schemas matched the message type” as shown in context here:

There was a failure executing the response(receive) pipeline:
“Microsoft.BizTalk.DefaultPipelines.XMLReceive, Microsoft.BizTalk.DefaultPipelines, Version=3.0.1.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35”
Source: “XML disassembler” Send Port: “sp_someWebServiceSendPortName”
URI: “http://MyServer/MyDir/MyService.svc.svc?wsdl”
Reason: Cannot locate document specification because multiple schemas matched the message type “http://tempuri.org/#SendMessageResponse”.

One Possible Solution: Set AllowUnrecognizedMessage to True

I

I’ve never encountered this in the past.  I’ve often worked for clients where I develop the webservice and more of the BizTalk.  I recently started working for a client that had a large existing base of production jobs.  When in Rome, sometimes you have to do like the Romans.

I probably wouldn’t have had this error before, because I typically self-enforced on myself the following procedures:

1) I assign a unique namespace to all webservices, never default to http://tempuri.org.  In my opinion, that is just sloppy. I think when you create a new WCF service, that is the default namespace, but anyone with experience would override it.

2) I probably would have created one application with this schema in it (or an app of common schemas), and I would have referenced it from all the other applications. (In other words, you would run the “Add Generated Item/Consume WCF” wizard just once per webservice. The downside of that is that you build a “dependency stack” that you must remember and document.  Then when you change an underlying schema, you have to roll-off (undeploy) and roll back on (re-deploy) all the other apps.  This is not a big deal when using BizTalk Deployment Framework, but it can result in some downtime (maybe a 5 to 30 minute window, depending on the apps).

For a company that values minimal or no down-time to unaffected applications, then this is what you can do.  You can reconsume the same webservice over and over in each application (resulting in it being deployed multiple times).  This now causes a problem when you have XMLReceive instead of PasThru on the Receive Pipeline of the SendPort that calls the webservice (and by the way, you need XMLReceive there if you want to catch SOAP Faults properly).

So to use the XMLReceive Pipeline and NOT get the error above, you can set “AllowUnrecognizedMessage” to True.

Stephen Thomas points out that you can also set this property in your orchestration.  Not sure why you would want to do it there, maybe for a dynamic SendPort?

OutMessage(XMLNORM.AllowUnrecognizedMessage) = true;

Microsoft documents the field here or here, saying only “Indicates whether to allow messages that do not have a recognized message type to be passed through the disassembler.”  That’s about as clear as crystal (yes, I’m being sarcastic).

Alternate Search Keywords (to help people find this post easier): AllowUnrecognizableMessage , Allow Unrecognized Message, Configure Pipeline XMLReceive