Unreleased Segment Problem in SAP

For some standard IDOC, Sometimes, SAP team would hesitate to release all the segments due to maintenance overheads,

On the BizTalk side, To enable us to work with these Idoc’s we need to follow the below steps:

In the importing of the schema
Change the properties: GenerateFlatFileCompatible, ReceiveIdocFormat and FlatFileSegmentIndicator
Add the extension Flat File Extension to the schema generated

In the configuration of the receive port
Change the handling of the message body to a specific XPath
Use a pipeline with a Disassemble stage configured to use a Flat File Disassembler
Change the ReceiveIdocFormat property

Beyond the configuration steps above, we need to create one pipeline to each Idoc or at least add one more component in the Disassemble stage of the receiving pipeline for each Idoc.
I also looked if this schema generated in this specific way, is going to work even in case the SAP team does not release all the segments..

These are the configurations I did on the Receive Location:, Note ReceiveIdocFormat should be “String” not Typed (There is a mistake in the screenshot)

  • Where Path = “/*[local-name()=’ReceiveIdoc’]/*[local-name()=’idocData’]”

    For the schema importing process you should change the following properties:



Hl7 Accelerator and xslt.

Actual Problem :

HL7 file coming out of HL7 Accelerator is having empty new line character in-between segments.

Segment looked like


 Cause for this problem.

The XML file that was fed into HL7 Accelerator had as new line character in those elements

<ORC_2_PlacerOrderNumber><EI_0_EntityIdentifier> {cr}{lf}



Solution :

Pass the XML through xslt transformation before sending it to HL7 accelerator

Here is the code that does the transformation.

 public static String  xslRemoveEmptyNodes(String xdoc)
            string strXmlOutput = xdoc;
                XmlDocument xDoc = new XmlDocument();
                string xslstring = @"<xsl:stylesheet version=’1.0′ xmlns:xsl=’http://www.w3.org/1999/XSL/Transform’&gt;
                        <xsl:output method=’xml’ omit-xml-declaration=’yes’ indent=’yes’/>                         
                        <xsl:template match=""node()|@*"">
                           <xsl:apply-templates select=""node()|@*""/>
                         <xsl:template match=""*[not(@*) and not(*) and not(text()) ]""/>

                Stream xslOutStream = new MemoryStream();
                StringWriter writer = new StringWriter();
                using (XmlReader reader = XmlReader.Create(new StringReader(xslstring)))
                    XslCompiledTransform myXslTransform;
                    myXslTransform = new XslCompiledTransform();
                    myXslTransform.Transform(xDoc, null, writer);

                strXmlOutput = writer.ToString();
                int index = strXmlOutput.IndexOf("<ns1:") < 0 ? 0 : strXmlOutput.IndexOf("<ns1:");
                strXmlOutput = strXmlOutput.Substring(index);



Errors encountered during the process

Alternate Error Number: 301

Alternate Error Description: XmlReader not positioned at root elment of ‘ORU_R01_24_GLO_DEF’

Alternate Encoding System: HL7-BTA

Fix for this Error

Add a line <xsl:output method=’xml’ omit-xml-declaration=’yes’ indent=’yes’/>  in your xslt transformation.


Adopted Healthcare Integration Transmission.

HL7 / EDI file using TCP/ IP over VPN : –

  1. Considering the challenges and effort needed to make this happen, I am surprised to see this is still the technology we use to get integrated with most of the healthcare entities such as clinics, hospitals..etc.
  2. In reality, Once the Small Sized Clinics choose the EMR, they tend to stay with it for years and most of them may not opt for the premium support offered by these EMR vendors. Hence the software in the clinic remains old-school and it get hard to get integrated with such EMR using other communication medium.
  3. Main pain point getting integrated using this method, – Network teams from both the ends needs to get involved, exchange the Firewall settings, IP Address, Port numbers and make a Hole in both Firewall so the packets can traverse through it.
  4. Chances of VPN connectivity going down can be seen often  – whenever either entity do any modifications in the Firewall rules / policies.
  5. Here the message would be transmitted in the Transport layer of OSI, hence the overhead of the layers above transport is eliminated.
  6. We can use “ telnet 10.XX.XX.XX <port>” in the command prompt to check if the VPN connectivity is up.
  7. I would recommend this only to entities such as big hospitals / insurance companies which has multiple locations across the country and want to
      • Save over the network bandwidth during exchange of healthcare data (HL7 or HIPAA ) files.
      • Reduce transmission latency.
      • Afford a good network team.

sFTP : –

…To be contd.