Using a Loopback adapter is a common pattern in BizTalk for testing or internal message routing. However, when dealing with EDIFACT interchanges, this often triggers a misleading validation error.
In a previous project, I worked with EDI messages to interchange with partners, but before I send the message to the partner, I need to pass it to the loopback adaptor, which was configured with the EDISend pipeline and EDIReceive Pipeline.
The objective is to get some properties configured in the Party that I need to precede the orchestration.
📝 One-Minute Brief
When using the BizTalk Loopback adapter to process EDIFACT interchanges, you may encounter “Data element too long” errors (e.g., in the UNB segment) despite the data being correct. Sometimes the cause of this problem is not the string’s size but the character set configured in the parties.
The send work well and creates a correct EDI message, but on the receive, I expect an Edifact Interchange Message, but when I receive back the message, it gives the following error:
“Transation Set Errors
Sequence No: 1
TS Id code: INVOIC
Control Number: 1Error: 1 (Field level error)
SegmentID: NAD
Position in TS: 13
Data Element ID: C08001
Position in Segment: 5
Position in Field: 1
Data Value: XXXXXXXXX X�X DE X�XXXX XX XXXXX
39: Data element too long
For more information, see Help and Support Center at”
Cause
- The value “C08001” is too long for the defined length of the element.
This error is simple, and it occurs because the total of characters, including spaces, is greater than what is allowed in element C08001, “XXXXXXXXX X�X DE X�XXXX XX XXXXX” contains 36 chars, and the element allows 35.
But, if you look carefully, the string has an encoding problem:
- The first sequence of these 3 characters “�” represents the character “Ô.
- And the second sequence represents the character “Ç”.
In my case, the problem is not the string’s size but the character set configured in the party, which causes the string length to be greater than it actually is.
Solution
- Check the max length of the UNB9 element and correct your data. If you and your trading partner agree, both may increase the max length, in which case you would modify your schema.
To resolve encoding problems (my situation)
- In the party, select EDI Properties and change the character set for a party by setting the UNB1.1 party property in the UNB Segment Definition property page for the party as interchange receiver.
- Under Party as Interchange Receiver > EDIFACT Interchange Envelope Generation > UNB Segment Definition > Syntax (UNB1) > UNB1.1 (Identifier).
- In my case, I used UNOD, more tolerant encoding (As defined in ISO 8859-2 : Information processing – Part 2: Latin alphabet No. 2.)
Hope you find this helpful! If you liked the content or found it useful and would like to support me in writing more, consider buying (or helping to buy) a Star Wars Lego set for my son.
