Euritmo

[giova....@gmail.com]

Hi Dears,

I have to manage a file format in EURITMO standard (ORDERS and INVOICE messages).

EURITMO is a standard, italian EANCOM subset (GS1 Italy Subset  ex IndicoECR),  used  in large-scale retail trade.

The structure of the user-file is compatible with the structure of the corresponding EANCOM messages, based on the 90.1 and 96.A directories (some records refer to D96A or D90.1 segment and field ... for example NAD3035 = SU) .

EURITMO ORDERS

https://gs1it.org/content/public/ee/70/ee707cfd-a65c-4e24-8960-b90d41507e96/manuale_euritmo_orders_gs1_italy.pdf

document is in italian but from page 7 you can see the subset segments and eventually the reference to segment and field of the flat-file based on EANCOM D90.1 or D96.A (that's what I understood). All EURITMO records are fixed length.

COMPATIBLE D96A ORDERS (not fixed length records)

https://gs1it.org/content/public/57/bf/57bf4398-5b36-4839-a7b6-72d7e21a9a72/manuale_eancom_ordine_orders_96a_gs1_italy.pdf

In attachment you can find a sample orders in EURITMO standard.

Could you please tell me which method to use to parse this document, bind it in java and maybe convert it to a custom XML that is easier to read (Ex: <Order id="xxxx" ><OrderItems><Item>.....). Should I use edifact parser, edi parser with mapping ...?

Thanks.

[Claude Mamo]

Could you please tell me which method to use to parse this document, bind it in java and maybe convert it to a custom XML that is easier to read (Ex: <Order id="xxxx" ><OrderItems><Item>.....)

It really depends on your use-case. You'd have to factor in your non-functional requirements like performance, etc... What you suggest is a common pattern. Smooks ingests the EDI into a format that is easier to process but typically one would want to transform/map the data into a structure that can be consumed by the downstream systems. You could also convert the document to custom XML using FreeMarker or some other template engine as shown in the pipelines example instead of binding to Java objects. If you decide on Java binding, you might want to consider binding with JAXB since it would make your life much easier. Note: we're currently implementing a better way to integrate with JAXB from Smooks but I think it will be a few more weeks until we ship this feature.

Should I use edifact parser, edi parser with mapping ...?

I'd go for edifact:parser. You can easily adapt the DFDL schemas to any customisations in the implementation guides. I should highlight that edifact/edi:parser are meant for data ingestion; not mapping.

Claude

--
You received this message because you are subscribed to the Google Groups "Smooks Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to smooks-user...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/smooks-user/a24c8197-f4c7-4ec0-9224-9150cd62b572n%40googlegroups.com.

[Giovanni Licata]

Hi Claude

Il giorno mer 5 mar 2025 alle ore 10:35 Claude Mamo <claud...@gmail.com> ha scritto:

Could you please tell me which method to use to parse this document, bind it in java and maybe convert it to a custom XML that is easier to read (Ex: <Order id="xxxx" ><OrderItems><Item>.....)

It really depends on your use-case. You'd have to factor in your non-functional requirements like performance, etc... What you suggest is a common pattern. Smooks ingests the EDI into a format that is easier to process but typically one would want to transform/map the data into a structure that can be consumed by the downstream systems. You could also convert the document to custom XML using FreeMarker or some other template engine as shown in the pipelines example instead of binding to Java objects. If you decide on Java binding, you might want to consider binding with JAXB since it would make your life much easier. Note: we're currently implementing a better way to integrate with JAXB from Smooks but I think it will be a few more weeks until we ship this feature.

If I have to natively integrate the import into my java code I think the best idea is to use a custom version of edifact schema and then bind it to java classes and then perform the write operations on the db (or as you suggest use JAXB).

However, I would like to do something more generic, a sort of microservice/gateway that provides EDI support to software that does not support it; in this case mapping and transformation become necessary. 

Should I use edifact parser, edi parser with mapping ...?

I'd go for edifact:parser. You can easily adapt the DFDL schemas to any customisations in the implementation guides. I should highlight that edifact/edi:parser are meant for data ingestion; not mapping.

yes ... I got it. What about fixed length record? Seems that file does not have any separator.

Thanks.

 

Claude

On Tue, Mar 4, 2025 at 11:00 PM giova....@gmail.com <giova....@gmail.com> wrote:

Hi Dears,

I have to manage a file format in EURITMO standard (ORDERS and INVOICE messages).

EURITMO is a standard, italian EANCOM subset (GS1 Italy Subset  ex IndicoECR),  used  in large-scale retail trade.

The structure of the user-file is compatible with the structure of the corresponding EANCOM messages, based on the 90.1 and 96.A directories (some records refer to D96A or D90.1 segment and field ... for example NAD3035 = SU) .

EURITMO ORDERS

https://gs1it.org/content/public/ee/70/ee707cfd-a65c-4e24-8960-b90d41507e96/manuale_euritmo_orders_gs1_italy.pdf

document is in italian but from page 7 you can see the subset segments and eventually the reference to segment and field of the flat-file based on EANCOM D90.1 or D96.A (that's what I understood). All EURITMO records are fixed length.

COMPATIBLE D96A ORDERS (not fixed length records)

https://gs1it.org/content/public/57/bf/57bf4398-5b36-4839-a7b6-72d7e21a9a72/manuale_eancom_ordine_orders_96a_gs1_italy.pdf

In attachment you can find a sample orders in EURITMO standard.

Could you please tell me which method to use to parse this document, bind it in java and maybe convert it to a custom XML that is easier to read (Ex: <Order id="xxxx" ><OrderItems><Item>.....). Should I use edifact parser, edi parser with mapping ...?

Thanks.

--
You received this message because you are subscribed to the Google Groups "Smooks Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to smooks-user...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/smooks-user/a24c8197-f4c7-4ec0-9224-9150cd62b572n%40googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Smooks Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to smooks-user...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/smooks-user/CADvAAujezZAZ4VySUCjkMcqjkTaaskCUWJzjwf0L%2B3%3DdTmD%2Bhg%40mail.gmail.com.

[Giovanni Licata]

Hi Dears,

Is it possible that there are no users in the community who have never had to deal with EURITMO message parsing?

Parsing the content of a file with fixed length record  is not a complicated task using standard methods of reading a file.

Instead, I would like to use Smooks and DFDL. 

The "adapt-edifact-schema-pack" example simply shows a simple adaptation by changing or adding a message, segment.

In my case, specification tell that the subset is compatible with D96A,but  they are differents:
- there is no segment separator since the segments have a fixed length;
- there is no data separator (not even component data separator) since all the data occupies a specific position within the segment;
- the data within the segment that is not present is equally valued with spaces

It is not clear to me what kind of changes I should apply to the D96A schema to acquire the segment data.

Maybe there is a more similar scheme in terms of data organization within segments?

I can't find any examples online that match my scenario. Could you give me a starting point to study?

Thanks.

[Claude]

It's possible. This is not an EDI community of practice. Smooks is used for a lot of things; not just EDI integration.