Yossi Dahan [BizTalk]


Friday, June 23, 2006

Setting a custom SOAP header to null

Again - this is related to my two posts from today.

I've already mentioned the facts that you cannot have a decision inside a construct shape and you cannot set a context property to null.

Now I'll add the last layer on top of this -

Our context proeprty is actually a custom SOAP header implementation.
I will not discuss this in detail here as it is described quite nicely in the documentation (at least in 2006).

The bottom line is that to add a custom SOAP header to a response going out of BizTalk you need to set a context property value to an xml as it needs to appear in the SOAP header.

In our case we needed to do this conditionally. so in some cases we needed a header and in others we didn't

we could have had a decision with two branches, and a construct message shape in each one that would construct the response and then set the context proeprty in one branch and not set it on the other. but this would mean duplicating all the logic of the message creation which is not a good idea.

so in our implementation we used an external web method to construct to soap error header.
When a header was needed the method will return the xml as it should appear in the header.

if a header was not needed the method would return only the root node of the xml and add the xsi: nil attribute.

When the SOAP adapter serialises the message it will omit the header alltogher - which is exactly what we wanted.

bare in mind you will have to set the root node to nullable in the schema, and you will need to define the namespace declaration for xsi in the xml you return. so it would look something like:

<http://www.w3.org/2001/XMLSchema-instance xsi:nil="true" />


Post a Comment

<< Home