0

I am using the code below to change a namespace in an existing XML message in a BizTalk pipeline component. This works but how would I add a namespace alias to the document as well.

XNamespace toNs = "http://hl7.org/fhir/Encounters";

XElement doc = XElement.Parse(xmlIn);

doc.DescendantsAndSelf().Attributes().Where(a => a.IsNamespaceDeclaration).Remove();

var ele = doc.DescendantsAndSelf();

foreach (var el in ele)
    el.Name = toNs +  el.Name.LocalName;

return new XDocument(doc);
Charles Mager
  • 25,735
  • 2
  • 35
  • 45
David
  • 139
  • 1
  • 13
  • Have you checked this [answer](https://stackoverflow.com/questions/2339782/xml-serialization-and-namespace-prefixes)? Maybe `XmlSerializerNamespaces` can do the job. – andiblas Jun 30 '17 at 02:09
  • Have you tried using the ESB Add and Remove Namespace Pipeline components? https://msdn.microsoft.com/en-us/library/ee250047(v=bts.10).aspx – Dijkgraaf Jun 30 '17 at 02:22
  • **HOLD ON!** Why are you doing this? I ask because it's unusual for an HL7 message to not have a namespace already. And for clarity, there are more 'correct' ways to accomplish this. – Johns-305 Jun 30 '17 at 14:52
  • I have to do this since the existing namespace and messageType is already in use in the application. Changing the namespace seemed an easy solution, but I'm running into lots of issues with my map and posted another thread for that. I'm sure there is a better way but I'm going to try adding the alias as shown below and see if that works before I start from scratch – David Jun 30 '17 at 17:56
  • @David Oh...well...then...sorry, yes, there is a much better way to handle this then. In fact, there is the correct way to handle this. I will post it as an Answer. – Johns-305 Jun 30 '17 at 20:09

2 Answers2

4

Now that we know the reason for this (duplicate MessageTypes), the correct BizTalk way to handle this is to deploy Custom Pipelines with configured XmlDisassembler components. Everyone should be doing this anyway.

Please refer to this TechNet Wiki Article which describes this exact scenario and how to resolve it: BizTalk: Improve Deployment and Tracking by Always Creating Custom Pipelines

If you absolutely must modify the content, the correct way in a Pipeline Component is to use the XmlTranslatorStream. This is instead of XmlDocument or XDocument.

From a BizTalk perspective, the marked Answer is not correct. Sorry. :(

Johns-305
  • 10,908
  • 12
  • 21
  • This is great, I knew there must be a better way. I did quite a bit of searching on ways to solve this issue but never came up with these links. Thanks! – David Jun 30 '17 at 20:48
1

You can simply add a declaration attribute to the root. Take this example:

<Root>
    <Child>Value</Child>
</Root>

If you run this code:

var root = XElement.Parse(xml);

XNamespace ns = "http://www.example.com/";

foreach (var element in root.DescendantsAndSelf())
{
    element.Name = ns + element.Name.LocalName;
}

root.Add(new XAttribute(XNamespace.Xmlns + "ex", ns));

You'll get this result:

<ex:Root xmlns:ex="http://www.example.com/">
  <ex:Child>Value</ex:Child>
</ex:Root>

See this fiddle for a demo.

Charles Mager
  • 25,735
  • 2
  • 35
  • 45
  • I'll try this now – David Jun 30 '17 at 17:56
  • For future readers, *because this is a BizTalk app*, **this Answer is not correct**. 1) Message Type clashes should be handled by XmlDisassembler settings 2) XmlDocument/XDocument use should fail review with used in a Pipeline Component. I won't Downvote since Charles Mager is not a BizTalk dev. @David – Johns-305 Jun 30 '17 at 20:26
  • @Johns-305 I suppose it depends how you look at it. It's correct in that it gives the answer to the specific question asked. I can't comment on whether the overall approach is correct. – Charles Mager Jun 30 '17 at 20:30
  • @CharlesMager Well, I very much point out that it is incorrect because this is the wrong way to address the problem *in a BizTalk app*. WinForm/ASP/Console, it is 100% correct. It's just not for a BizTalk app because BizTalk has ways to handle this exact issue. – Johns-305 Jun 30 '17 at 20:46