none
Error on changing Component element separator (ISA16)

    Question

  • Hi,

    I am testing an EDI 945 message by changing the Component element separator (ISA16) to be '0x1F' (Hex) in the Agreement Properties.

    Scenario 1: Using PassThruReceive (RcvPort A) and EDISend (SendPort B) ports, once the XML input is dropped, the output is fine with the expected EDI envelops. '0x1F' is shown in ISA16 of the EDI output.

    Scenario 2: I have enable the default Batch Orchestration and add another 2 ports, the EDIReceive (RcvPort C) to grab the files from SendPort B and the second EDISend (SendPort D) which will be proceeded after the Batch trigger. Within the same Agreement Properties, once the message is batched, I have got an error;

    There was a failure executing the send pipeline: "Microsoft.BizTalk.Edi.DefaultPipelines.EdiSend, Microsoft.BizTalk.Edi.EdiPipelines, Version=3.0.1.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" Source: "EDI Assembler" Send Port: "SendPort D" URI: "C:\BizTalkEDI\23_9456030A_Batch\%MessageID%.txt" Reason: '', hexadecimal value 0x1F, is an invalid character. Line 1, position 428.


    What's wrong with it? and How to fix this? 

    Thanks,

    Wednesday, April 3, 2019 12:21 PM

Answers

  • > What's wrong with it?

    Nothing, but the EDI Assembler probably should throw an error because 0x1F is not an allowed character.

    > and How to fix this?

    By using one of the allowed X12 characters instead of 0x1F.

    0x1F is a control character and not listed as an X12 Extended Character.  You can find the list of allowed characters here: http://edi.aaltsys.info/01_standards.html

    Bit of advice, do not try to use special or control characters in your implementation.  No one does this and it will only cause frustration for your trading partners who may not notice this since, well, no one does this.

    Just stick with the ":" which by far the most common.

    • Marked as answer by Abweg 9 Thursday, April 4, 2019 6:42 AM
    Wednesday, April 3, 2019 1:23 PM

All replies

  • > What's wrong with it?

    Nothing, but the EDI Assembler probably should throw an error because 0x1F is not an allowed character.

    > and How to fix this?

    By using one of the allowed X12 characters instead of 0x1F.

    0x1F is a control character and not listed as an X12 Extended Character.  You can find the list of allowed characters here: http://edi.aaltsys.info/01_standards.html

    Bit of advice, do not try to use special or control characters in your implementation.  No one does this and it will only cause frustration for your trading partners who may not notice this since, well, no one does this.

    Just stick with the ":" which by far the most common.

    • Marked as answer by Abweg 9 Thursday, April 4, 2019 6:42 AM
    Wednesday, April 3, 2019 1:23 PM
  • Many Thanks John-305, a couple question with the ISA16;

    By default, the ":" is set to be ISA16 as you mentioned. In this case, How can we handle this if the partner still need us to send him the data with ":"? Ex. "Room: 39" in address field N301. The data with ":" will causing an error "Invalid character in data element" on that field.

    My partner needs to allow transferring all special characters in the list as data (! " & ' ( ) * + , - . / : ; ? = % ~ @ [ ] _ { } \ | < > # $) that why I am try changing all separators to the non-printable characters. At now, only "0x1F" which is using as ISA16 is struck. Do you have any recommendation for this situation?


    Thursday, April 4, 2019 6:42 AM
  • Are they new to EDI?  Because, again, no one does this.

    "We need to send all characters?" might equal "we don't really understand our requirements and don't really know how to do this correctly" :)

    After :, the second most common separator is >. 

    You can always use one of the allowed non-character characters, the ones <18.  In 20 years of EDI, I have never seen this.

    Thursday, April 4, 2019 2:17 PM
  • You read my mind! That's exactly what I thought, John.

    By the way, thanks again for your valuable answer. You might be surprised if I tell you the partner name LoL

    Friday, April 5, 2019 3:27 AM