It looks like you are calling a web service that takes a single XML parameter containing some contextual information along with the message content. Right? I bet you are using the promoted property just to set the value of the MessageContent within your orchestration. I think the easy fix is to make the MessageContent property a distinguished field instead of a promoted property. (But beware! There is a fundamental flaw in your web service contract.) Distinguished fields are meant for use within orchestrations, and there is no character limit on them. Promoted properties are meant for routing, so you should avoid using them to set values within orchestrations.
So what is the flaw I mentioned? The web service is accepting the message content as a string field. This approach is all too common, and it works, but there are some problems with it. By making the XML a string field, it gets string encoded. See all of the &:lt and &:gt? This bloats your message as it goes over the wire. Also, the contract is not explicit since it does not contain the schema for the message content. This means the web service serialization engine can’t validate the message content.
Do you have control over the web service? If so, here is how to send the data as XML.
- Build the schema that you want to send in the BizTalk schema editor.
- Use XSD.EXE to genearate a C# class for the schema.
- Modify the web service to accept the C# class as a parameter.
- You may need to use the WCF wizard to re-generate the input schema, because the web service will wrap some additional XML tags around the XML data (web method name and parameter name).
- Also, you might want to look at sending the context info (ServiceAuditID, ServiceRequesterID, etc.) in the SOAP header. This is exactly what the SOAP header is meant for.
Hope this helps!