Bård (Langöy) and I have been doing lots of work on improving our EDI support, specifically in the area of handling UN/EDIFACT (WikipediA) message Interchanges. The following improvements are now in the Smooks v1.4 codebase (available from the 1.4-SNAPSHOT):
So that’s what’s available in the current 1.4 codebase (1.4-SNAPSHOT), but we’re also in the process of making more additions to this for Smooks v1.4. We’re extending the EDI Java Compiler (EJC) tools to support Java Model generation from the EDI Mapping Model sets generated by the ECT tool (mentioned above). We’ll also make these available as pre-built jar files from the Maven repository.
Another improvement we’ve made in the 1.4 codebase is the addition of support for Java Model to EDI serialization on the EJC generated Java object models, meaning we’ll be able to do full round trip binding of an EDI (and UN/EDIFACT) message to a populated Java Object model that can be modified and then serialize back out to an EDI stream. Or, your app can “manually” construct the same Java Object models and serialize them out to an EDI Stream (think JAXB).
The easiest way to consume UN/EDIFACT messages using Smooks is to use ECT (EDI Conversion Tool) to generate the EDI Mapping Model set (if we haven’t already pre-built them). The steps are really easy:
The following is an example of the maven module POM for generating the EDI Mapping Model set jar for the d03b.zip definitions directory zip file.
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<modelVersion>4.0.0</modelVersion>
<groupId>org.milyn.edi.unedifact</groupId>
<artifactId>d03b-mapping</artifactId>
<version>1.0.SNAPSHOT</version>
<name>UN/EDIFACT - D03B - Mapping Model</name>
<build>
<plugins>
<plugin>
<groupId>org.milyn</groupId>
<artifactId>maven-ect-plugin</artifactId>
<version>1.4-SNAPSHOT</version>
<configuration>
<src>d03b.zip</src>
<srcType>UNEDIFACT</srcType>
</configuration>
<executions>
<execution>
<goals><goal>generate</goal>
</goals></execution>
</executions>
</plugin>
</plugins>
</build>
</project>
Of course when we execute this step, we will perform “mvn clean deploy” and install the jar file in the public maven repository, making it publicly available and thereby removing the need for you to perform this step. A peek into the public SNAPSHOT repo shows that we’ve started this process.
Using a generated EDI Mapping Model set jar in your application (via Smooks) is trivial. You need to:
An example of the <unedifact:reader> configuration for the above generated EDI Mapping Model set jar for the d03b.zip definitions directory zip file would be as follows:
<unedifact:reader
mappingModel="urn:org.milyn.edi.unedifact:d03b-mapping:1.0-SNAPSHOT" />
Using the “urn:<groupId>:<artifactId>:<version>” URN pattern, Smooks can find the EDI Mapping Model set jar file on the classpath,
And that’s about it. The associated Smooks instance will accept a UN/EDIFACT message interchange containing one or more messages defined in the d03b.zip definitions directory zip file, and will generate a stream of SAX events into Smooks, which can be processed using all the other Smooks capabilities (Java Binding, Validation, Templating etc). As stated earlier, the improvements we are working on for EJC will result in us being able to generate Java Object models from an EDI Mapping Model set jar.
Check out and build the Smooks examples from https://svn.codehaus.org/milyn/trunk/smooks-examples (mvn install).
Change into the “ect-unedifact” directory after building all the examples (must build them all so as to install the poms) and run the example using mvn exec:java. The ect-unedifact example depends on the “d03b-mapping” module which has been pre-built and is available in the public SNAPSHOT repo.
And guys…. PLEASE let us know how you get on with this stuff… things you like and dislike etc !!!
I would like to introduce the new factory feature in the Javabean cartridge of the up coming Smooks 1.3 release. This new features makes it possible to use a static factory method or a factory object to instantiate objects with the Javabean cartridge.
Smooks 1.2 adds support for message data Validation as one of its new features. This new feature allows you to perform strong field and fragment validation on not just XML data, but also on EDI, JSON, CSV etc. It currently supports Regex and MVEL rules bases (Drools to follow). Regex rules allow you to perform low level field format validation, while MVEL rules allow you to perform Business rules validation at a fragment/message level.
With the new Smooks Persistence cartridge in Smooks 1.2 you can directly use several entity persistence frameworks from within Smooks. In this post I will show you how this works with Hibernate and any other JPA compatible framework.
One of the major new features in Smooks v1.2 will be the new Persistence Cartridge. This cartridge enables the use of several entity persistence frameworks from within Smooks, currently targeting Hibernate, Ibatis and any JPA compatible framework. It also allows you to use your own Data Access Objects (DAOs).
This cartridge is great for those cases where you already have your data access layer and want to use its power from within Smooks. It also allows you to reuse these persistence resources on any format of data, not just XML e.g. EDI, CSV, JSON etc.
This is the first post of a series of posts about the persistence cartridge. This post is an introduction of the cartridge. I will give an overview of what the cartridge can do and also show an example where I use custom DAO’s to persist the data of an XML document. In the next posts in this series, I will show examples of how Hibernate, JPA and Ibatis entities can be used.
MuleSource recently posted a Podcast about “Smooks for Mule” on their “From the Mule’s mouth” blog. In the Podcast, I get interviewed by Ross Mason about “Smooks for Mule” and “Smooks”. I talk about why I started Smooks for Mule and what Smooks can do. I outline some examples of where Smooks is in use today, as well as what people can expect in the next releases of “Smooks for Mule” and “Smooks”.
You can listen to the podcast via the player on the end of this post or you can go to the original Mule blog post. I hope that you find it interesting and useful.
I would like to thank MuleSource for enabling this interview.
Podcast: Play in new window | Download (4.3MB)
Yeah, we of the Smooks project are also going to do it. Start blogging about our project. The blog is the perfect place to inform you about the latest things that are going on. With this blog we want to get our idea’s out there and introduce you to the latest features of Smooks. You can also expect posts with small tutorials featuring common, experimental or less know features of Smooks or one of it’s child projects.