At JBoss, we’ve been making some good progress with the JBoss Tools Smooks Editor. The following are two rough Screencasts illustrating two use cases that extend from each other.
EDI to Java
In this Screencast, we bind EDI Purchase Order data (but can also be XML, JSON etc) into an “Order” object model (Java). This Screencast was created a few weeks ago, using the v3.1.0.CR1 release of JBoss Tools.
To enlarge, press screen icon (bottom right)
EDI to XML (via XSD)
In this Screencast, we extend the example shown in the above Screencast, applying a template to the “Order” object model to produce an XML Purchase Order. The XML Purchase Order is defined in an XML Schema (XSD), but you’ll see how the editor makes it very easy to work with the XSD. This Screencast was created recently, using one of the Nightly Builds of JBoss Tools.
To enlarge, press screen icon (bottom right)
Status
We are currently working towards the v3.1.0.CR2 release of JBoss Tools, which is due to be released in Feb (not sure of exact date). There are still a number of issues with the editor. We are working on these and will be resolving many of them for the 3.1.0.CR2 release.
We have purposely restricted the 3.1.0 version of the editor:
Supported Use Cases:
Java Mapping/Binding: Drag & Drop mapping/binding of XML, JSON, CSV and EDI data to Java.
CSV and XML Templating: Drag & Drop templating of Java Mappings (see #1 above) to produce CSV or XML (XML via XSD or XML Sample).
Supported Integration:
JBoss Tools ESB Editor: Will have basic open and edit integration with the ESB SmooksAction.
Supported Versions:
Smooks v1.2 Configurations: The Editor will only support Smooks v1.2 configuration namespaces. Therefore, if you have configurations using config namespaces from earlier (or newer v1.3) versions of Smooks, the editor will not open the configurations.
So, the 3.1.0 version of the editor will not support:
Direct Source to Result drag & drop templating e.g. XML to XML, EDI to XML, XML to CSV etc. We hope to support this in a future release (next one hopefully), but for now (in the v3.1.0 release), you need to define a Java Object model to use as the canonical form of the data being mapped i.e. v3.1.0 templating works as Source -> Java -> Result.
A number of features supported by the Smooks Runtime, such as Persistence, Validation, Splitting & Routing etc. We will be adding support for these in future releases.
Smooks v1.1 (and before) configuration namespaces that have newer versions in Smooks v1.2. For example, Smooks v1.2 added a v1.2 javabean config namespace. It is this version of the javabean config namespace that is supported by the editor. The v1.1 javabean config namespace is not supported.
Smooks v1.3 (yet to be released) configuration namespaces.
Try it Out…
Please take the editor for a spin and let us know what you think. It can be downloaded (standalone, or as part of JBoss Tools) from the JBoss Tools Downloads Page. Please log any issues you find with the editor (against the “smooks” component), if not already logged.
We’ve just made a Smooks v1.2.4 patch release (Download).
This contains:
Some performance enhancements (reader pooling),
Some bug fixes and,
One small new feature to support Basic Fragment Splitting and Routing. Right… we normally only do fixes in patch releases, but I wanted to get this into the JBoss SOA Platform before it released, so we made an exception for this one.
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.
Of late, JBoss have been making more of a push on their Smooks Eclipse Tooling within JBoss Tools. Prior to a few weeks ago, Dart Peng was “more or less” left to his own devices on this work, without much help from myself or anyone else. More recently, Brian Fitzpatrick (JBoss) and myself have been more actively contributing to the great work being done by Dart.
Brian has been blogging about this work here on the JBoss Tools blog. Please take a look and contribute your throughs and ideas!!!
Smooks can produce “output” in a number of different ways. It can produce multiple sets of results, as well as output fragments of data to multiple different endpoints (ESB Service Endpoints, Files, JMS Destinations, DBs etc… and in different formats), all in a single filtering pass of a message stream.
Smooks v1.2 has just been released (download). This release adds a number of very interesting features and enhancements to Smooks, most notably:
EDIFACT Java Compiler (EJC): EJC greatly simplifies the process of binding EDI data to a Java object graph. EJC is similar to JAXBs XJC, accept for EDI messages. This is just the first of a number of developer optimization features we are in the process of adding in the area of EDI message processing.
Entity Persistence Framework Support: Reuse your Entity Persistence resources (like Hibernate, iBATIS or any JPA compatible resource) to persist or enrich messages of any format (EDI, XML etc). Access a database and use it’s query language, or CRUD methods, for reading and writing to the database.
Validation: Perform Rule based message fragment validation on messages of any format (EDI, XML etc). Supports Data Field level validation using regular expressions, or Business Rule compliance validation using MVEL expressions.
Simplified CSV Processing: Bind CSV records to Java objects in seconds using a much simplified XML configuration, or using a very simple programmatic API.
Improved Programmatic APIs: Prior to Smooks v1.2, programmatic configuration was not one of Smooks’ strengths. In Smooks v1.2 we’ve made significant improvements in this area. Most Smooks features can now be utilised through Java, without writing a line of XML.
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.
Quite simply, we wanted a site that was easy to edit, and produced something we liked. With all of us doing this in our spare time, we didn’t want to be wasting that time fighting the tools we were using. Google Sites was OK, but was quite restrictive wrt how it allowed us construct the content. The editor was more wysiwyg on Google Sites, but the result was not at all as appealing (in my opinion at least) and ultimately that’s what really counts. An example of one simple thing with the new site…. it’s now very easy to style code snippets that look really well – check the User Guide or any of the Examples.
Anyway, we hope you like it too, and find it easier to work with.
REMEMBER…. it’s a Wiki, so feel free to contribute documentation updates. Don’t be afraid of breaking anything as we have a full revision history. So be bold… go make some edits!!!