Smooks Data Integration

Renat Zubairov has been doing some really cool stuff with the Smooks UN/EDIFACT support that’s been added for Smooks v1.4.  On top of the ECT tooling, he has built tools for generating Eclipse EMF Ecore (XMI) models for each of the EDI Mapping Models being produced by ECT.  On the back of this work, he has been able to build an Editor for Eclipse, allowing you to read and write UN/EDIFACT messages from inside Eclipse.

See more here on the Smooks Wiki.

The UN/EDIFACT Editor for Eclipse is cool, but I think the wider impact of these capabilities is even cooler.  This is really important work because it will open a number of really important doors in terms of our ability to process and transform not just UN/EDIFACT, but EDI in general (X.12, HL7 etc).  Our long-term goal is to add support for X.12, HL7 etc to ECT (i.e. build conversion tools for these standards).  Once we do this, we will be able to provide out-of-the-box support for these EDI formats on the Smooks Runtime.  We hope it will also mean that we can use this work that Renat is doing to automate building of Ecore/XMI models for these same formats.  Once we have these Ecore/XMI models, we hope we will be able to:

1. Build and provide XML Schemas (XSDs) for all of these messages.
2. Make use of Eclipse EMF Compare to compare models e.g. compare 2 different versions (D93 and D96) of a UN/EDIFACT Invoice specification.
3. Make use of Eclipse EMF M2M to create a transformation model between 2 different models e.g. between UN/EDIFACT and X.12 Invoices.

Note that this will not hit the main codebase until after we have released Smooks v1.4 i.e. we hope to make it available with Smooks v1.5.

This is awesome stuff.  Keep up the great work Renat!!!

All of the existing integrations of Smooks within other frameworks (JBossESB, Mule and others) suffer from a common design flaw, whereby users need to specify Result type information inside the framework’s configurations.  This Result type information is used by the framework to map Smooks filtering results back into the frameworks messaging constructs.

The problem with the above approach is:

1. It makes the framework configuration more verbose than it should be.  Also (in some cases), the embedding framework does not provide a rich enough configuration model for defining this information, resulting in ugly/un-intuitive configuration hacks for defining the result.
2. It means the user needs to read and understand the Smooks configuration and then make the framework level configurations, based on what they have interpreted from the Smooks configuration.  This is a pain!
3. Adding support for new Result types usually involves modifications to the framework integration.
4. It typically only supports mapping of one result type, restricting the use of Smooks.

When doing the Camel integration, we started to encounter this issue again.  The solution that we came up with was to add a configuration element to the Smooks core namespace, pulling all of this configuration back into the Smooks configuration and providing a richer configuration model:

The newly added exports element declares the results that are produced by this Smooks configuration. A export element can contain one or more result elements. A framework that uses Smooks could then perform filtering like this:

// Get the Exported types that were configured.
Exports exports = Exports.getExports(smooks.getApplicationContext());
if (exports.hasExports())
{
    // Create the instances of the Result types.
    // (Only the types, i.e the Class type are declared in the 'type' attribute.
    Result[] results = exports.createResults();
    smooks.filterSource(executionContext, getSource(exchange), results);
    // The Results(s) will now be populate by Smooks filtering process and
    // available to the framework in question.
}

There might also be cases where you only want a portion of the result extracted and returned. You can use the ‘extract’ attribute to specify this:

The extract attribute is intended to be used when you are only interested in a sub-section of a produced result. In the example above we are saying that we only want the object named orderBean to be exported. The other contents of the JavaResult will be ignored. Another example where you might want to use this kind of extracting could be when you only want a ValidationResult of a certain type, for example to only return validation errors.

Below is an example of using the extracts option from an embedded framework

// Get the Exported types that were configured.
Exports exports = Exports.getExports(smooks.getApplicationContext());
if (exports.hasExports())
{
    // Create the instances of the Result types.
    // (Only the types, i.e the Class type are declared in the 'type' attribute.
    Result[] results = exports.createResults();
    smooks.filterSource(executionContext, getSource(exchange), results);
    List