0

I am using Azure Logic Apps and Integration Accounts for receiving the EDIFACT messages.

The EDIFACT incoming message has an underscore character in it, and EDIFACT DECODE validation fails with the message:

Error encountered during parsing. The Edifact transaction set with id '1' contained in interchange (without group) with id '1', with sender id 'XXX', receiver id 'XXXXX' is being suspended with following errors:

Error: 1 (Field level error)

SegmentID: BGM

Position in TS: 2

Data Element ID: XXXX

Position in Segment: 3

Position in Field: 1

Data Value: 1_2017-09-2206:24:42

21: Invalid character found

I want to allow the underscore character to be considered as valid character, appreciate any pointers in resolving the issue.

Vivek Sharma
  • 1,912
  • 1
  • 13
  • 15

3 Answers3

0

It's all driven by the standard character set, see here, I don't recall any that supports underscore, so ultimately the transaction is incorrect according to the EDIFACT standard as the error message states.

  • Thanks Don, I know underscore is not valid in any of the EDIFACT character sets. Was looking to see if there is an easy way to allow it. – Vivek Sharma Apr 01 '19 at 15:35
0

There are 1.5 problems. :)

But, the first thing you need to do is inform your management that your Trading Partner is sending invalid EDIFACT. If the Trading Partner is not able to solve their problem, you will have to spend extra time accommodating their issue.

This is not a problem with you, your app or BizTalk Server.

EDIFACT supports a very limited number of character sets and "_" is not in any of them.

Either they fix their problem or you will have to create a custom Function that removes/changes the invalid characters.

Finally, the .5 problem is that they're not even sending a usable value. That format is not any standard date format so manipulation would be required anyway to use it.

Johns-305
  • 10,908
  • 12
  • 21
  • Thank you for the detailed response, I agree, if there is no in-built way to allow "_" character, will need to create the function to handle that. – Vivek Sharma Apr 02 '19 at 18:07
  • I think the field throwing this error was BGM_02 which is the "Document Identifier" - a string of up to 70 characters assigned by the sender. There's no expectation that it should be able to be parsed as a date. – AdamKent Mar 08 '23 at 04:21
0

UNOC (ISO-8859-1 / Latin1) character set includes the underscore.

I wouldn't expect great support for characters where the encoding is different between ISO-8859-1, Windows-1252 or the first 255 code-points of UTF-8 (meaning characters 0x80 to 0x9F), due to the potential for implementations to use either Windows-1252.

I also wouldn't rely on any non-printable or white-space characters (other than space) being handled consistently well.

AdamKent
  • 366
  • 2
  • 8