In my last two posts I showed two possible errors, and their respective solutions, that can happen when we are validating dummy EDI message, provided by our partners, against the schema using Visual Studio, but these errors could also happen at runtime.
In this post, I will show you one common error when we are validating an EDI solution.
After I deploy and correctly configured the solution, I was trying to receive an EDI document from a Receive Port, in order to convert it to XML format using the generic EDI pipeline: “Microsoft.BizTalk.Edi.DefaultPipelines.EdiReceive”, but I was always getting this error:
“There was a failure executing the receive pipeline:
“Microsoft.BizTalk.Edi.DefaultPipelines.EdiReceive,
Microsoft.BizTalk.Edi.EdiPipelines, Version=3.0.1.0, Culture=neutral,
PublicKeyToken1bf3856ad364e35″ Source: “EDI disassembler” Receive Port: “IN_ORDER_PORT” URI: “E:\PORTS\EDI\IN_ORDER\*.*” Reason: No Disassemble stage components can recognize the data.“.
The message provided by our partner was this:
UNH+1000100+ORDERS:D:93A:UN:EAN007' BGM+220+01521710' DTM+137:120530:101' DTM+64:120604:101' DTM+63:120004:101' FTX+AAI+++SOME TEXT' FTX+AAI+++SOME TEXT' FTX+AAI+++SOME TEXT' NAD+BY+8000000001164::9' NAD+DP+8000000009463::9' NAD+IV+8000000013002::9' NAD+SU+8000001459008::9' NAD+PR+8000000016003::9' LIN+1++4001518722937:EN' PIA+1+00:PV+14001518722937:EN' IMD+F+M+:::SOME DESCRIPTION' QTY+21:52' LIN+2++5000014010034:EN' PIA+1+00:PV+15701014010031:EN' IMD+F+M+:::SOME DESCRIPTION' QTY+21:152' LIN+3++5000014016142:EN' PIA+1+00:PV+15701014016149:EN' IMD+F+M+:::SOME DESCRIPTION' QTY+21:304' LIN+4++5006879009752:EN' PIA+1+00:PV+15776879009759:EN' IMD+F+M+:::SOME DESCRIPTION' QTY+21:720' UNS+S' UNT+31+1000100'
Cause
After some time trying to understand the reason for this problem, I realize that’s nothing wrong with my project, the problem is actually in the message that I’m using.
This error occurs because the message does not contain the EDIFACT interchange envelope segments (UNB and UNZ). An EDIFACT interchange begins with a UNB. It contains version release information, syntax information, and partner information. An interchange ends with a UNZ.
UNA Segment: The UNA segment is optional in an EDIFACT interchange. The specifications in the UNA segment define the characters used as separators and indicators for the interchange. Use this segment only if the interchange contains non-standard separator characters. (More information here)
UNB Segment: The UNB segment is compulsory to an EDIFACT interchange. This segment acts as the interchange header for a set of EDIFACT documents. The UNB segment elements identify the sender and recipient of the interchange, together with the date and time that the interchange was prepared and the agency controlling the syntax of the interchange. (More information here)
UNZ Segment: This segment is the Interchange Trailer segment of an EDIFACT document. This segment indicates the end of an interchange and checks the interchange reference and number of documents in the interchange. (More information here)
Solution
Add this segment to your message: UNA (optional), UNB and UNZ and the message will be processed correctly.
Correct message:
UNA:+,?*' UNB+UNOB:1+UNB2.1+UNB3.1+012301:0123+UNB5' UNH+1000100+ORDERS:D:93A:UN:EAN007' BGM+220+01521710' DTM+137:120530:101' DTM+64:120604:101' DTM+63:120004:101' FTX+AAI+++SOME TEXT' FTX+AAI+++SOME TEXT' FTX+AAI+++SOME TEXT' NAD+BY+8000000001164::9' NAD+DP+8000000009463::9' NAD+IV+8000000013002::9' NAD+SU+8000001459008::9' NAD+PR+8000000016003::9' LIN+1++4001518722937:EN' PIA+1+00:PV+14001518722937:EN' IMD+F+M+:::SOME DESCRIPTION' QTY+21:52' LIN+2++5000014010034:EN' PIA+1+00:PV+15701014010031:EN' IMD+F+M+:::SOME DESCRIPTION' QTY+21:152' LIN+3++5000014016142:EN' PIA+1+00:PV+15701014016149:EN' IMD+F+M+:::SOME DESCRIPTION' QTY+21:304' LIN+4++5006879009752:EN' PIA+1+00:PV+15776879009759:EN' IMD+F+M+:::SOME DESCRIPTION' QTY+21:720' UNS+S' UNT+31+1000100' UNZ+1+UNB5'
Thank you very much.. adding UNA, UNB and UNZ segment solved my issue
Hi Sandro, I have a query related to the 999 ack being created when an 820 EDI message gets processed in one of the BizTalk applications in my org. The 999 does contain a code R for the AK9 segment which means the file has been rejected. However it does not contain the IK3 and IK4 segments which would have given more details about the reasons for the rejection of the file. Have you experienced this scenario? If yes could you please share your understanding?
Note: I understand that the question might not be applicable for this specific blog post, but this was the closest that I thought I could post my query.