1

I am trying to create Java bindings for EDIFACT messages using Smooks. In particular, I want to automatically generate Java classes and corresponding mappings using Smooks. To this end, Smooks 1.x provides the EDIFACT-to-Java-Compiler (EJC).

With the upcoming version 2, Smooks relies on schemas written in the Data Format Description Language (DFDL) to specify EDIFACT messages instead of Smooks-specific schemas used in v 1.x. To my understanding, this means that EJC v1.x cannot be used to generate EDIFACT bindings for Smooks v2. Is this correct?

If so, what is the preferred way to generate bindings? Will there be an upcoming EJC v2? Or should I use the XML Schema Compiler (XJC) to generate Java classes and then either map them directly in Smooks, or do a two-step transformation EDIFACT -> (Smooks v2) -> XML -> (JAXB) -> Java?

Thanks for your insights!

Ulrich Schuster
  • 1,670
  • 15
  • 24

1 Answers1

1

Is this correct?

Yes.

Or should I use the XML Schema Compiler (XJC) to generate Java classes and then either map them directly in Smooks, or do a two-step transformation EDIFACT -> (Smooks v2) -> XML -> (JAXB) -> Java?

That's the recommended approach as discussed in the Smooks user forum. The Java bindings for many of the EDIFACT versions have already been generated ahead of time and can be pulled down from the public Maven repository as shown in one of the Smooks examples.

Claude
  • 489
  • 4
  • 15
  • If I understand the recommended approach correctly, I must first transform the incoming EDIFACT interchange into a XML string in memory and subsequently feed that string into the JAXB unmarshaller. Is there a way to avoid creating this interim string and to directly feed Smooks SAX events into JAXB unmarshalling? – Ulrich Schuster Jan 17 '22 at 07:05
  • 1
    That isn't efficient in terms of memory and I don't think you'd be gaining much from Smooks by using it like this. The highlighted Smooks example is demonstrating how to create an EDIFACT model from POJOs. It should be possible to stream the raw EDIFACT to Smooks and fire visitors that would bind the event data to the JAXB bean instances. You could then leverage a BeanContextLifecycleObserver to "listen" for these beans during execution. This should leave a small memory footprint as long as the same bean ID is used so that beans don't accumulate in memory. – Claude Jan 19 '22 at 20:05