I cannot change that property, it is my customer's schema

12 year since last post :)

One thing Í hear is "We can't change the xml schema, it's provided be our customer". That's a truth that can be bent. 

As long as you use a copy of it, like in BizTalk, you can actually do whatever you like, it's not hardwired to the customer. You might not want to change sequence or structure, but it's often data types you do not agree upon. 

So if the customer state it gonna be a date, and then sends 000000 if they don't have a date, change your copy of the schema to string and take care of it before sending it forward, as xs:nil or remove the element. Likewise another customer stated it would be a integer and then sends space if they didn't have a value. Change to string in your copy and take action.

This issue might most often occur in a flat file scenario, but some customers don't validate their xml before sending it.

I understand it demand some maintance if a new version of the schema is released, but I think it's worth it.

10 proofs that you are an experienced BizTalk developer

1. You subscribe to message types and message properties rather than port name


2. You understand that you can change the schema you got from the customer and they will not notice, and it will work


3. You are not afraid to create new message types/schemas, the kind that you haven't got schemas from any customer or endpoint.


4. You create/map to new message types after manipulating messages rather than using advanced filters to avoid infinite loops


5. Your messages could be found in the street and one could still know its purpose


6. You understands that using OR in a rule can make the rule fire more than ones


7. You know better than to bet on that the customer's specifikation meet reality


8. You know that when a customer says the flat file field contains a date it could be one of the following "date" formats: 20100617; 00000000; 20100600; 20100000; " "


9. You know that when a customer's xsd states the type to decimal, it still can contain: 1234,56; 1 234,56; 1,234.56 but sometimes also 1234.56


10. You understand that a non mandatory field in a flat file does not effect the length of the row

Unable to find Stored Procedure

After changing a message flow from loosely coupled to not, I had to, I experienced "Unable to find Stored Procedure" in the event log.

Using SQL Profiler I noticed two calls for every message. One doing the correct thing and another "Exec [A name very similar to the root node of internal message used]".

Of course! The filter previously used by the send port was still there, subscribing to the internal message type :)

Removing the filter and everything worked like a charm.

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 = MaxReceivedMessageSize exceeded

Continuation from two previous posts on the subject.

I forgot to write about the first reason I got "Bad Request". After tracing the message I found the "real" reason:

“The maximum message size quota for incoming messages (65536) has been exceeded. To increase the quota, use the MaxReceivedMessageSize property on the appropriate binding element.”

The default value of the property MaxReceivedMessageSize on WsHttp binding is 65535 bytes. My message was much bigger than that so after increasing the value everything went well.

Workflow Foundation - Message not delivered

When you write a ExternalDataExchange service in WF you

* decorate an interface with the ExternalDataExchange attribute
* add an instance of the ExternalDataExchange service to the WorkflowRuntime
* add an instance of the implementation of your interface to the ExternalDataExchange service (not the WorklowRuntime)

In your interface you probably have some methods and some events. Events that should communicate with WF must have EventArgs that inherits from ExternalDataExchangeEventArgs.

You will get InnerException of "QueueNotFound" exception if
* events that is not part of communication with WF have EventArgs inheriting from ExternalDataExchangeEventArgs
* no workflow subscribing to the event

Workflow Foundation - Look at InnerException

Last week I ended up in a WF project. I had viewed some code and done a presentation in the subject earlier so my experience was not that high.

The project included a WF monitor, designer and a host running WF services and the actual workflows.

We ran into some problem and I want to share two things so you can find issues faster than we did.

1) Allways subscribe to "workflow terminated" and write excaption message to some log or output window
2) Loop all inner exceptions. The real explanation is often hidden in the last one

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"