How can BizTalk 2006 R2 consume the serialized response of a WCF service with PreserveObjectReferences = true?

Question

We have an existing .net 3.5 WCF service with which PreserveObjectReferences is set to true on the server side.

When PreserveObjectReferences is set to false BizTalk can consume the response.

Is there a way to get BizTalk to consume the PreserveObjectReferences response payloads...

PreserveObjectReferences manifests itself with a z:id occurring for the first instance of an object and a z:ref occurring for any subsequent object occurrences:

<b:xyz *z:Id="5"* i:type="abc">...</b:xyz>
...
<b:xyz *z:ref="5"* />

Answer 1

What was the option PreserveObjectReferences configured to when generating the xsd's?

The xsd's are generated from the WCF service it's WSDL and if in this WSDL these extra attributes are not defined BizTalk won't know they exist and BizTalk will throw an exception. I don't know for sure if the DataContractSerializer will inlude these attributes when generating a WSDL. If the DataContractSerializer doesn't include these attributes while generating a WSDL you must change the xsd of the response message to allow xs:any attributes on the elements where these attributes are added.

Answer 2

Both BizTalk and JAX-B have issues with dealing with the payload for differing reasons. ID/IDREF are supported XML Schema options but every implementation seems to have problems consuming them.

For JAX-B when both idref and nil=true is specified it is unable to marshall the payload into objects:

<b:xyz z:ref="5" nil="true"  />

Removal of the nil=true or setting preserve object references to false (i.e not returning a a payload utilising the idref capability means that Java coders can work around this.

BizTalk can work around this by re-hydrating the xml without the idref support through xslt transforms or other means.

Our solution to both was to ensure preserve object references was turned off. both systems were then able to integrate without significant hassle.