convertToValues not returning arrays?

, ,
1

Dear experts,

I have a problem with convertToValues not returning arrays when there are repeating elements.

I have a small test flow, where I am reading from an EDI flat file document(EDI 850) as stream and then converting it into an IDOC using convertToValues. In convertToValues, the only parameters that are being passed are ffData and ffSchema. The Schema is the standard “EDIFFSchema.X12.V4010:T850” generated by WM EDI module (via the EDI menu “Install New TN Documents”) and the ffData is the streamed version of the file.

The issue is that although in the EDI.txt file, I see multiple elements for EDI structures within ST, such as “REF”, “N1”, “ITD” etc, the IData ( ffValues structure) returned by the convertToValues doesnt return these as an array!?

I checked the schema and it looks okay. ( The elements are set to repeat). I also tried both versions of the convertToValues, pub.flatFile:convertToValues as well as wm.b2b.edi:convertToValues.

Am I doing something wrong, or missing something here?

I am on IS 6.5 SP2.

2

For parsing EDI use only the wm.b2b.edi:convertToValues and map the edidata and EDIFFSchema(EDIFFSchema.X12.V4010:T850) and set the delimiters accordingly as per the data file.

Since you already confirmed in the 850 schema those segments were set to maxRepeat=unlimited, you should be good…

Note: Don’t use pub.flatFile:convertToValues for parsing edidata…You might get different results…

Try testing with the above inputs including delimiters…

HTH,
RMG

3

Thanks a bunch for your input, Rmg.

I tried what you said and it yielded the same result.

However, I realized that it was a user-error. In the schema, the elements are expected to be ordered. And the repeatable elements that I was looking at were not.

For .e.g my file was as below, where there were 2 REF elements that were not grouped together. I realized later that the subsequent REF elements were not root elements, but were sub fields under their root elements ( like AMT and N1).

ISA*
GS*
ST*
BEG*
CUR*
REF*
AMT*
REF*
N1*
N2*
N3*
N4*
NX2*
REF*
PER*
…

When I manipulated the file and ordered it differently as below, it worked fine. The issue was with my understanding.

ISA*
GS*
ST*
BEG*
CUR*
REF*
REF*
REF*
AMT*
REF*
N1*
N2*
N3*
N4*
NX2*
REF*
PER*
…

Thanks for your help, RMG.

4

It’s good to know that it is working…:slight_smile: Yeh some times the issue is with the original data file itself…:mad:

-RMG

5

Since you have TN, I’m wondering if you’re planning to be using convertToValues for “real” work? Is what you’re doing simply a learning exercise?

6

Rob,

Right now its an exercise but I am trying to make a prototype that can be used for the ‘real’ work.

Is there an issue with using convertToValues for real work?

7

When EDI data is received (via HTTP, FTP, FTP from a VAN, picked up from a directory, etc.), you’d hand it off to TN.

TN can do all the de-enveloping.

When your service is invoked (via processing rule) for a given transaction set, you will use wm.b2b.editn:bizdocToRecord to convert the EDI to an IS document (which calls pub.flatFile:convertToValues under the covers).

Direct use of services like envelopeProcess and convertToValues isn’t necessary when TN is used.

8

Thank you Rob!! I will use bizDocToRecord going forward.

I guess I’ll use the bizDocToRecord for normal files and convertToValues for large Document handling. Does that sound like the ideal thing to do?

I guess I didn’t come across this service (bizDocToRecord in the guides, and hence did not use it. Wierd that it is’nt mentioned in there, or did I miss it?

Also, another thing I noticed is that this bizDocToRecord service uses the convertToValues from the FF package, not the edi package. What is the difference of using one over the other? It seems like the edi package convertToValues uses the ff convertToValues behind the scenes.

9

Unfortunately, you can’t use bizdocToRecord directly for large docs. It will pull in the entire doc. But, you could clone that service and modify it to use the iterate option that convertToValues exposes.

For the guides not mentioning it isn’t surprising, but the sample code in the doc is essentially what bizdocToRecord does.

I guess my original intent wasn’t really to steer you away from convertToValues as much as wanting to point out that TN will be a big help.

10

That’s great. Thanks Rob!!
Thanks for pointing out the code that already exists. I love not having to re-invent the wheel. :slight_smile:

I modified my post to include this question later:Also, another thing I noticed is that this bizDocToRecord service uses the convertToValues from the FF package, not the edi package. What is the difference of using one over the other? It seems like the edi package convertToValues uses the ff convertToValues behind the scenes.

11

The EDI module version accepts different parameters, which are more suited for EDI processing. But it’s really more of a convenience aspect than anything.

You’ll note too that there are two versions of EDI convertToValues: wm.b2b.edi:convertToValues and wm.b2b.edi.util:convertToValues. The latter is for backwards compatibility with 4.6 and is not supposed to be used directly.

The former is a Java service (not sure why) which calls the service in the util folder and does some mucking around with the pipeline vars but nothing major.

It is safe to use the FF convertToValues.

12

I normally stick with edi.util:getEDIString,wm.b2b.edi:convertToValues services for handling EDI parsing/validation etc… in the service level…what ever might be the EDIModule versions.

Just my thoughts…I am not contradictiong with Rob’s approach though…

PS:Always prefer EDI route via TN …

-RMG

13

Different approaches are always good to consider. Thanks for sharing your view rmg!

14

Thanks to both of you immensely!!