Shikhar came to me because he could not process an EDIFACT message like this using the out of the box BizTalk 2010 pipeline;
UNB+UNOB:1+7654321:ZZZ+1234567:ZZZ+353501:3023+UNB5′
UNG+INVOIC+UNG2.1:ZZZ+UNG3.1:ZZZ+060413:2314+UNG5+UN+D:98B’
UNH+UNH1+APERAK:D:98A:UN++13+UNH5.1+UNH6.1+UNH7.1′
BGM+1+C10601′
DTM+10′
FTX+AAA++C10701+C10801′
CNT+1:14′
RFF+AAA’
DTM+10′
NAD+AA+C08201+C05801+C08001+C05901′
CTA++C05601′
COM+C07601:AA’
ERC+C90101′
FTX+AAA++C10701+C10801′
RFF+AAA’
FTX+AAA++C10701+C10801′
UNT+15+UNH1′
UNE+1+UNG5′
UNZ+1+UNB5′
He got the following error;
An output message of the component “Unknown ” in receive pipeline “Microsoft.BizTalk.Edi.DefaultPipelines.EdiReceive, Microsoft.BizTalk.Edi.EdiPipelines, Version=3.0.1.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35” is suspended due to the following error:
Error: 1 (Miscellaneous error)
33: Invalid occurence outside message, package or group.
The sequence number of the suspended message is 1.
If we look at the raw message on the suspended instance we see that the UNB segment has been replaced with a blank line like this;
UNG+INVOIC+UNG2.1:ZZZ+UNG3.1:ZZZ+060413:2314+UNG5+UN+D:98B’
UNH+UNH1+APERAK:D:98A:UN++13+UNH5.1+UNH6.1+UNH7.1′
BGM+1+C10601′
DTM+10′
FTX+AAA++C10701+C10801′
CNT+1:14′
RFF+AAA’
DTM+10′
NAD+AA+C08201+C05801+C08001+C05901′
CTA++C05601′
COM+C07601:AA’
ERC+C90101′
FTX+AAA++C10701+C10801′
RFF+AAA’
FTX+AAA++C10701+C10801′
UNT+15+UNH1′
UNE+1+UNG5′
UNZ+1+UNB5′
What is going on here? Sandro Pereira wrote about a similar problem. His solution was to “Add this segment to your message: UNA (optional), UNB and UNZ and the message will be processed correctly.”. I decided to search for another solution. If the UNA segment is present then the EDI receive pipeline parses the file using the delimiters specified. Now if the UNA segment is not specified then the EDI receive pipeline uses the delimiters specified in EfactDelimiters property on EDI disassembler pipeline component.
Thus it tries to parse the message using the ‘ delimiter. The first line is assumed to be the UNA segment and is deleted from the stream. This is incorrect in this case because it is mandatory UNH segment and the message fails in the pipeline. The solution to this problem in our hands was surprisingly simple. We followed Gyan Prakash and added CRLF as segment terminator suffix. The pipeline now looks like this
This seems to work in our hands at the moment.
