HL7 and BizTalk Blog

There is the issue of the behavior of the mapping process creates invalid XML.

The input instance looks like this:

<xml>
 <loopA />
 <loopB />
 <loopA />
 <loopB />
</xml>

However, when using the mapper, you create your output and it ends up looking like this:

<xml>
 <loopA />
 <loopA />
 <loopB />
 <loopB />
</xml>

How to get this to work (only in R2) is to open up the btm file and change the following attribute from its default value of No to Yes in the mapsource element

PreserveSequenceOrder=”No”

<mapsource Name="BizTalk Map" BizTalkServerMapperTool_Version="2.0" Version="2" XRange="100" YRange="420" OmitXmlDeclaration="Yes" TreatElementsAsRecords="No" OptimizeValueMapping="No" GenerateDefaultFixedNodes="Yes" PreserveSequenceOrder="No" CopyPIs="No" method="xml" xmlVersion="1.0" IgnoreNamespacesForLinks="Yes">

Here is the new code:

<mapsource Name="BizTalk Map" BizTalkServerMapperTool_Version="2.0" Version="2" XRange="100" YRange="420" OmitXmlDeclaration="Yes" TreatElementsAsRecords="No" OptimizeValueMapping="No" GenerateDefaultFixedNodes="Yes" PreserveSequenceOrder="Yes" CopyPIs="No" method="xml" xmlVersion="1.0" IgnoreNamespacesForLinks="Yes">

To extend what I wrote about for the Encoding for HL7 messages post. There are two values that are used for the Message Encoding context properties. It isn’t obvious but follow the logic:

According to Extended Encoding Support page in the Note section of step 5 you can only choose Western European or UTF8, so if I look at the Encoding Class documentation, the table below are the values you can use:

Another one of the gotchas (yes, my blog seems to be full of them) is the ‘association’ of the acknowledgment with the original message that  is generated from the BTAHL7 receive pipeline. In the BTAHL7 Configuration explorer, by default the Acknowledgment settings are as follows:

Notice that the MSH15 and MSH16 overrides are set to AL- Always generate the System and Application Acknowledgment, and that below the Route ACK to send pipeline on request-response receive port is checked. This means that the default behavior of the pipeline is to generate two acknowledgments, and route one of them back along the receive location’s send pipeline. What is it supposed to do with the second acknowledgment that it created?

That is where the error message is generated: Event ID 5778: The Messaging engine failed to process a message submitted by adapter: MLLP Source URL:{whaver server:port} Details: The published message could not be routed because no subscribers were found. This error occurs if the subscribing orchestration or send port has not been enlisted, or if some of the message properties necessary for subscription evaluation have not been promoted.

The resolution: a simple solution is to create a send port for this data and drop it off as a file.

Not quite the elegant solution that I want to deal with, as now there is a maintenance aspect of making sure that this folder is purged.

Let’s just not create the application acknowledgment. You do this by changing the parties definition from Original to Enhanced mode and turning the application acknowledgment to NE (never).