Scouring the web for solutions turned up virtually nothing. And so it began, my journey for a workable solution to this enigma that is BizTalk (again). My first attempts were a simple exercise of attrition. It encompassed recompiling, re-referencing, de-referencing and every other ridiculously simple attempt to resolve the problem. None produced the desired outcome; the message persisted and my patience grew increasing limited.
Thus, my next series of attempted fixes resulted in reassigning the message variable. I'll spare you from the multitude of failures incurred before succumbing to the eventual fix.
The resolution consisted of the following:
1. Declare the outgoing message of type System.Xml.XmlDocument
2. Create an xPath string that will populate said outgoing message with the entire contents of the message to be leveraged.
3. In a message construct/message assignment shape, assign the outgoing message by calling an xpath solution.
Here's a sample of the solution that worked for me:
xPathString = "/*[local-name()='Employees' and namespace-uri()='http://mySpecialSchema']"; MsgOutput = xpath(MsgInput,xPathString);
Going to have to try this with a multipart message I'm having the same problem with. Will hopefully confirm if this solves it for my situation as well tomorrow morning.
ReplyDeleteI know this is an old post, but could you give me more detailed instructions? I tried this but it did not work. Thank you
ReplyDeleteOk, it's been awhile since I've actually re-encountered this issue, but what I can offer is this:
DeleteWhen writing your xpath, be certain that the namespace you are declaring is contained within the message content you are extracting. Your sendport should also be of type System.Xml.XmlDocument.
Otherwise, this issue appeared when I tried using a message that was run through a map in an earlier shape.
If that doesn't help, you can give me a little more information on what you're experiencing and we can try troubleshooting together.