다음을 통해 공유

BizTalk–Map Incoming Message to a string Field

  • 아티클

In a recent project I worked, one of the requirements was to copy the entire incoming message to a String Field.

Consider the incoming message

<ns0:TestNode xmlns:ns0="https://testEnvelope.SourceSchema">
  < FieldOne>FieldOne_0</FieldOne>
  < FieldTwo>FieldTwo_0</FieldTwo>
< /ns0:TestNode>

This would have to be mapped to

<ns0:Root xmlns:ns0="https://testEnvelope.DestinationSchema">
  < IncomingMsg>IncomingMessageXML</IncomingMsg>
< /ns0:Root>

so the output message should look like

<ns0:Root xmlns:ns0="https://testEnvelope.DestinationSchema">
  < IncomingMsg><ns0:TestNode xmlns:ns0="https://testEnvelope.SourceSchema"> <FieldOne>FieldOne_0</FieldOne> <FieldTwo>FieldTwo_0</FieldTwo> </ns0:TestNode></IncomingMsg>
< /ns0:Root>

image

In the BizTalk Mapper you cannot just map a node to the output field.

image

Well you can but the output is always going to be an empty field as shown below.

<ns0:Root xmlns:ns0="https://testEnvelope.DestinationSchema">
   <IncomingMsg/>
< /ns0:Root>

To achieve this you will have to make use of Scripting Functoids as follows

image

The first Functoid defines a C# function that takes a NodeIterator as the input and returns the OuterXml.

image

The second Functoid uses XSLT to map the incoming message to the string field called IncomingMsg in the output message. To achieve this it calls the NodeToString function that is defined in the previous Functoid. We pass it /TestNode which is the root node of the incoming message.

image

Since the first Functoid is just being used as a place holder to hold the C# function you will receive the following warning when you test the map in Visual Studio. But it can be ignored.

image