Schema collision using same WCF service from multiple BizTalk projects

I just had a problem I haven't had for some time, "Cannot locate document specification as multiple schemas match the message type".

This happens when schemas with the same Root Node name and Namespace are deployed to BizTalk. To find the correct schema these two parameters are to only thing you got in XML world, so the pair need to be unique.

The new thing was that we are starting to use a lot of WCF services in the current projects, so whats was the relation? The problem occurs since many projects referenced the same service. That way the database would have the same schema deployed several times and a collision is a fact.

I thought this problem should have occured to me before, with multiple projects referencing same web service, but then I found some info about changes in subscription mechanism between SOAP and WCF. Seroter writes: Differences in BizTalk Subscription Handling for SOAP and WCF Adapter Messages and I also thought about how the SOAP adapter was used.

With the SOAP adapter the common settings have been "Passthrough" on both Send and Receive Pipeline. The subscription has been handled by operation name and other mechanisms and there has been no need to promote Message Type and therefore no need for "Xml receive" pipeline, and its schema resolving disassembler.

In WCF the subscription mechanism have change and the common settings are "Passthrough" on the Send pipeline and "Xml Receive" on the Receive pipeline. Then the "Xml disassmbler" will run and Message Type will be promoted.

If you have more than one project consuming the same WCF service deployed you will end up with "Error....multiple schemas...deployed".

Either you can create your own pipeline to limit the disassembler to look for schemas in a specific assembly or, as we have done, create a "Service project" and deploy that to a common Application (with BTS 2006).

So my project structure now looks like

x.y.Schemas.Internal
x.y.Schemas.External
some.companyglobal.namespace.Services
x.y.Map
x.y.Process
x.y.Pipeline

(I started structure my projects different after reading Dan's blog: BizTalk Visual Studio Solution Structure, with the small change of name for the Orchestration project to "Process". )

How do you solve using same WCF service from multiple projects?

Handling Fault Message

I think I have a at least average intelligense, but today I could not figure out have to handle Fault Message in a BizTalk orchestration.

I followed all common samples and added a Scope with Catch Blocks, one for the service Fault Message and one for ordinary Soap Exceptions, but it did not work. I got: "Received unexpected message type 'http://schemas.xmlsoap.org/soap/envelope/#Fault' does not match expected type 'http://x.y#z'" all the time no mather what I tried.

Now it seems to be a vocabulary problem. I googled on handling "Fault Message", but did not find any solution until I stumbled on something like "Typed Fault Contract", then there was information about configuring the send port correctly.

In the send port for an WCF-adapter you can specify where the body of the response message starts. If you expect to receive either your preferred message or a Fault Message you use a XPath expression. See message tab on the properties for the WCF-adapter.

1. Check Path
2. Add an OR-expression for your possible response messages (/*[local-name()='Fault']/*[local-name()='detail']/* "insert pipe character here" /*[local-name()='MyResponseMessageRootNodeName'] for example, see explanation below)
3. Check that Node encoding is set to Xml
4. Check "Propagate fault message", is checked default

The XPath means:

XPath to Soap fault (can be "Detail", if one can trust other samples, but for me it was "detail")
/*[local-name()='Fault']/*[local-name()='detail']/*

XPath OR
"pipe" (could not enter the pipe character here for some reason)

XPath to your expected Fault Contract/Message
/*[local-name()='MyResponseFaultMessageRootNodeName']

Bad request = Validation error

Continuation from previous post.

Solving permission problem I still had "Bad Request", but now the inner exception (and the Event Log) got me a validation error.

My WCF DataContract had a Required=True on a property that did not exist on the incoming message from BizTalk.

HTTP Bad Request can certainly mean a lot of things. Be sure to look in every log.

I recommend to config BizTalk, and the WCF service, to trace WCF-traffic. Use the WCF Config tool and the WCF Trace tool. They are located under "C:\Program Files\Microsoft SDKs\Windows\v6.0\Bin" and called "SvcConfigEditor.exe" and "SvcTraceViewer.exe"

Bad request = Access denied

Consuming services can get you "Bad request" error. The problem can be permissions on the service.

I made a WCF service to be consumed by Biztalk. The service is hosted by IIS and there was no problem running the BizTalk WCF Service Consuming Wizard to create schemas, port types and bindings.

The error came when trying to access the service by posting a request to it. Then I got "400 Bad request".

The problem was related to permissions. I forgot to switch application pool on my web application. After selecting the proper pool, running by correct user, I restarted IIS and everything worked fine.