"" /> "" /> ""/>

ESL force segment to ignore Component element separator ISA16 [mulesoft]

61 views Asked by At

I have an 850 EDI generated with a non-strict EDI program.

in some Free Form message segment MSG01, text contained the component element separator ">", causing the mule to throw error / refuse to parse the entire Transaction set while parsing the file. Trace Log below

2020-01-21 [MuleRuntime] MSG at 21 matched group component 300_N9_Loop
2020-01-21 [MuleRuntime] parsing structure:
 subsequence from 1:300: [ MSG ] with matcher variants { } terminations { MSG } with matcher variants { }
2020-01-21 [MuleRuntime] starting parse of subsequence from 1:300: [ MSG ] with matcher variants { } terminations { MSG } with matcher variants { }
2020-01-21 [MuleRuntime] MSG at 21 matched segment reference 300_MSG
2020-01-21 [MuleRuntime] parsing segment MSG at 21 (position 1:300)
2020-01-21 [MuleRuntime] fatal transaction error 'Too many data elements (more data elements than defined for the segment)' for component MSG01: 'Free-Form Message Text' at segment 21 of transaction Some(0001) in group Some(902105287) of interchange 902105287
2020-01-21 [MuleRuntime] now positioned at segment 'MSG'
2020-01-21 [MuleRuntime] finished parsing group component 300_N9_Loop with termed false

Since I am already customizing the schema esl file, would want to know if it is possible to force mule to ignore the ">" character in that segment.

the related section I found for the segment in esl

basedef.esl

- id: 'MSG'
  name: 'Message Text'
  values: 
  - { idRef: '933', usage: M }
  - { idRef: '934', usage: C }
  - { idRef: '1470', usage: O }
  rules: 
  - { type: C, items: [3, 2] }

  - { id: '933', name: 'Free-Form Message Text', type: AN, minLength: 1, maxLength: 264 }

850.esl

- groupId: 'N9_Loop'
  count: 1000
  usage: O
  items: 
  - { idRef: 'MSG', position: '300', usage: O, count: 1000 }

1

There are 1 answers

0
FinrodFelagund On

Strictly speaking. If there's a delimiter in the field, it is invalid. If you need that character inside the MSG, why not choose a different delimiter for the message? I know that is a common suggestion for a delimiter, but I have found that non-printable ones open up what can be sent free text.