none
Problem parsing an EDIFACT interchange (to release or not to release - UNA5 with UNA4) RRS feed

  • Question

  • Hi,

    It seemed to me that I have a problem in understanding how the EDI Preprocessing Pipeline works.

    We received an EDIFACT file (single transaction set, not batched), which seemed to be correct, when I tested it in Visual Studio doing "validate instance" on the schema file.

    To do this 

    •  we removed the service segments of the envelope (UNA,UNB,UNZ).
    • In the validation dialog we set all requested data exactly as they are in the original UNA segment and UNB Segment (character set).

    The special thing with this message is, that it has some data fields in RFF segments, which contain UNA5 in the value itself. For me it seems correct, that those occurrences are directly released by UNA4 by our communication partner.

     

    EDIFACT:

    UNA:+.? '

    :

    RFF+IT:340934566-0010? LM2007/00126048'

     The instance is valid, the resulting output (xml) shows that every occurence of a pair of UNA4UNA5 in a data field was correctly relaced by just an UNA5.

     XML result of validation

    <ns0:C506_2><C50601>IT</C50601><C50602>340934566-0010 2007/00126048</C50602>

    Our problem is:

    When we use the schema and the message in an Biztalk Server 2006 R2 receive location with EDI disassembler pipeline We get the following error:

     Error: 1 (Field level error)

    SegmentID: RFF              

    Position in TS: 12

    Data Element ID: C50602

    Position in Segment: 2

    Position in Field: 2

    Data Value:       

    6: Invalid character in data element

     

    Looking at the xml-Output of the EDI Pipeline we can see, that the output of the pipeline is

    <ns0:C506_2><C50601>IT</C50601><C50602>340934566-0010? 2007/00126048</C50602>

    We checked the tracked context of the message and the UNA Segment property had the same value that it should have. ( :+.? ' )

    The EDI receive pipeline does EDI checking as well as XML-schmema checking and just in case the pipeline could not find an UNA segment in the message, we set exactly the delimeter values which we found in the UNA-Segment of the original message (0x3A, 0x2B, 0x2E, 0x3F, 0x20, 0x27).

    The EDI party properties we configured (resolution was successful - we could check this in tracked properties) seems to have no influence on the behaviour we observed.

     

    another test

    Just to test it, we removed the UNA4 in all data values and tried it again ( now all occurrences of UNA5 characters in data values are not released by UNA4).

    In this constellation it worked in  my Biztalk Server application but not in validation process with visual studio.

    It is obvious that there is a difference, but which behaviour is the right one. Is the document our pertner sent to us correct?

     

    Thank you in advance for your helping comments,

              Timo

     

    Tuesday, January 29, 2008 10:57 PM

Answers

  •  

    EDI Validation in Visual Studio and in Receive Pipeline had different results in my case.

    I tried to find out, what is the difference between those validation call. I lost out of sight that I could not give UNB1.2 to the validation dialog in visual studio. That seems to make a difference because in syntax version 3 UNA5 has no meaning. It has

     

    We use a syntax version “3” document (UNOC 3), so specification ISO 9735: 1988 (E) http://www.gefeg.com/jswg/v3/data/v1-9735.pdf (page 14) defines the structure an meaning of every character in the UNA segment:

     

    UNA, Service String advice

    Function: To define the characters selected for use as delimiters and indicators in the rest of the interchange that follows:

    The specifications in the Service string advice take precedence over the specifications for delimiters etc. in segment UNB. See clause 4.

    When transmitted, the Service string advice must appear immediately before the Interchange Header (UNB) segment and begin with the upper case characters UNA immediately followed by the six characters selected by the sender to indicate, in sequence, the following functions:

     

    Repr.      Name                                                                                                  Remarks

    an1 M    COMPONENT DATA ELEMENT SEPARATOR

    an1 M    DATA ELEMENT SEPARATOR

    an1 M    DECIMAL NOTATION Comma or full stop

    an1 M    RELEASE INDICATOR If not used, insert space character

    an1 M    Reserved for future use Insert space character

    an1 M    SEGMENT TERMINATOR

     

    That means that UNA 5 is not used in my version. The EDIFACT preprocessing pipeline should replace every character that is relevant for the structure of the document. As UNA 5 is reserved for future use and has not the meaning of an repetition indicator it should not be replaced by an (UNA4 UNA5) sequence.

     

    In version “4” syntax UNA 5 has a meaning and it is defined how to handle occurrences of those in data elements http://www.gefeg.com/jswg/v4/data/v4-9735-1.pdf :

     

    The service string advice shall begin with the upper case characters UNA immediately followed by six

    characters in the order shown below. The space character shall not be used in positions 010, 020, 040, 050

    or 060. The same character shall not be used in more than one position of the UNA.

    POS       REP       S         Name                                Remarks

    010       an1       M         COMPONENT DATA ELEMENT SEPARATOR

    020       an1       M         DATA ELEMENT SEPARATOR

    030       an1       M         DECIMAL MARK                        The character transferred in this position shall be ignored by the recipient. Retained to maintain upward compatibility with earlier versions of the syntax.

    040       an1       M         RELEASE CHARACTER

    050       an1       M         REPETITION SEPARATOR

    060       an1       M         SEGMENT TERMINATOR

     

    The service characters are the component data element separator, data element separator, release character, repetition separator, and segment terminator.

    The component data element separator, data element separator, repetition separator, and segment terminator delineate various syntax structures as defined in clause 7.

    The purpose of the release character is to allow the use of a character that would otherwise be interpreted as a service character. The character immediately following the release character in a interchange shall not be interpreted as a service character. When used, the release character is not counted in the length of the data element value.

    Tuesday, March 25, 2008 3:04 PM

All replies

  • In your example you seem to be trying to escape the space character ! The escape character (?) is used to escape one of the delimiters (:+'). UNA5 is a reserved field.

     

    Thursday, February 21, 2008 8:17 AM
  •  

    " this constellation it worked in  my Biztalk Server application but not in validation process with visual studio.

     

    It is obvious that there is a difference, but which behaviour is the right one. Is the document our pertner sent to us correct?"

    My experience:

    When I try to validate a message, that I have receaved from a partner, in Visual studio if you have spaces bettewn any characters Visual studio whont be able to validate and it will error out.

    I cant say for sure why it appens but it appens. You have to expect that Biztalk Server is the correct one because Visual studio is only for developing...(this concept is strange but it is what I thynk)

    My current solution is to edit the Edifact message and remove all the spaces...not the easy solution but i dont have that many errors all the time.

     

    also chek your UNA segment and see if it is correct. but on visual studio the problem is the one that I referer on top.

     

     

     

     

     

    Thursday, February 21, 2008 10:05 AM
  •  

    EDI Validation in Visual Studio and in Receive Pipeline had different results in my case.

    I tried to find out, what is the difference between those validation call. I lost out of sight that I could not give UNB1.2 to the validation dialog in visual studio. That seems to make a difference because in syntax version 3 UNA5 has no meaning. It has

     

    We use a syntax version “3” document (UNOC 3), so specification ISO 9735: 1988 (E) http://www.gefeg.com/jswg/v3/data/v1-9735.pdf (page 14) defines the structure an meaning of every character in the UNA segment:

     

    UNA, Service String advice

    Function: To define the characters selected for use as delimiters and indicators in the rest of the interchange that follows:

    The specifications in the Service string advice take precedence over the specifications for delimiters etc. in segment UNB. See clause 4.

    When transmitted, the Service string advice must appear immediately before the Interchange Header (UNB) segment and begin with the upper case characters UNA immediately followed by the six characters selected by the sender to indicate, in sequence, the following functions:

     

    Repr.      Name                                                                                                  Remarks

    an1 M    COMPONENT DATA ELEMENT SEPARATOR

    an1 M    DATA ELEMENT SEPARATOR

    an1 M    DECIMAL NOTATION Comma or full stop

    an1 M    RELEASE INDICATOR If not used, insert space character

    an1 M    Reserved for future use Insert space character

    an1 M    SEGMENT TERMINATOR

     

    That means that UNA 5 is not used in my version. The EDIFACT preprocessing pipeline should replace every character that is relevant for the structure of the document. As UNA 5 is reserved for future use and has not the meaning of an repetition indicator it should not be replaced by an (UNA4 UNA5) sequence.

     

    In version “4” syntax UNA 5 has a meaning and it is defined how to handle occurrences of those in data elements http://www.gefeg.com/jswg/v4/data/v4-9735-1.pdf :

     

    The service string advice shall begin with the upper case characters UNA immediately followed by six

    characters in the order shown below. The space character shall not be used in positions 010, 020, 040, 050

    or 060. The same character shall not be used in more than one position of the UNA.

    POS       REP       S         Name                                Remarks

    010       an1       M         COMPONENT DATA ELEMENT SEPARATOR

    020       an1       M         DATA ELEMENT SEPARATOR

    030       an1       M         DECIMAL MARK                        The character transferred in this position shall be ignored by the recipient. Retained to maintain upward compatibility with earlier versions of the syntax.

    040       an1       M         RELEASE CHARACTER

    050       an1       M         REPETITION SEPARATOR

    060       an1       M         SEGMENT TERMINATOR

     

    The service characters are the component data element separator, data element separator, release character, repetition separator, and segment terminator.

    The component data element separator, data element separator, repetition separator, and segment terminator delineate various syntax structures as defined in clause 7.

    The purpose of the release character is to allow the use of a character that would otherwise be interpreted as a service character. The character immediately following the release character in a interchange shall not be interpreted as a service character. When used, the release character is not counted in the length of the data element value.

    Tuesday, March 25, 2008 3:04 PM
  • I think that you are partly right.

    In syntax version “4” for example UNA 5 has a meaning and it is defined how to handle occurrences of those in data elements http://www.gefeg.com/jswg/v4/data/v4-9735-1.pdf :

    POS     REP     S          Name                                                              Remarks

    010       an1       M         COMPONENT DATA ELEMENT SEPARATOR

    020       an1       M         DATA ELEMENT SEPARATOR

    030       an1       M         DECIMAL MARK                                              The character transferred in this position shall be ignored by the recipient. Retained to maintain upward compatibility with earlier versions of the syntax.

    040       an1       M         RELEASE CHARACTER

    050       an1       M         REPETITION SEPARATOR

    060       an1       M         SEGMENT TERMINATOR

     

    The service characters are the component data element separator, data element separator, release character, repetition separator, and segment terminator.

    The component data element separator, data element separator, repetition separator, and segment terminator delineate various syntax structures as defined in clause 7.

    The purpose of the release character is to allow the use of a character that would otherwise be interpreted as a service character. The character immediately following the release character in a interchange shall not be interpreted as a service character. When used, the release character is not counted in the length of the data element value.

     

    My Problem seems to be, that it is not possible to set the value for give UNB1.2 in the visual studio dialog becaus in my case it is syntax version 3.

     

    Tuesday, March 25, 2008 3:15 PM