I have a service that is loading an EDI file and I’m using wm.b2b.edi:convertToValues to work with.
When loading my document, webMethods is applying some formats in a few fields, like [xxx]/DTM02 that is a date field. In fact, the EDIFF schema is calling a format service, and this is working well for our current processes.
But exceptionally, I want to load my document without this date format being applied. When calling wm.b2b.edi:convertToValues, it seem to have a parameter delimiters/FormatInfo that can be used to force some formats, or to ignore format services on defined fields.
I never worked with that parameter and I’m unable to find an example of package using this parameter. If my assumption is good, is there someone who can visually help me how to fill this parameter?
I would suggest not messing with that paramter and instead simply reformat the date to the desired format after you get the document from convertToValues.
As you said, I decided to loop over the 50,000 IT1 segments and format the DMT02 field manually. I was expecting some performance issues but this is working well.
you are in the right direction:
BTW what format you are changing it to?
In our EDI 4010 810 schema, there is a format service associated to date fields. yyyyMMdd when creating document and yyyy/MM/dd when loading document. We are working on old environment and not all the current processes are done by us!
Long story short, a partner wants to receive one monthly invoicing file and have a large volume of invoices. Our webMethods server is unable to work with an incoming file with more than 100,000 lines and transform this file to our generic invoice document schema in order to work with, in mapping service, to create the EDI 810 doc. So, I’m creating daily 810 files, that I must reload on a monthly basis to ‘merge’ into a final EDI file. Not a really clean process, but now It’s working fine, performance is pretty good, with good validation.
yyyyMMdd is the valid/standard format for the 4010 EDI schema’s…The one should not change it in the schema level and ofcourse it can be customized in the mapping side after parsing the data the better approach:
Thanks for elaborating short story:)