EDI, or Electronic Data Interchange, has always been a challenging domain to support for organizations. As EDI standards cover a large range of industries, from supply chain to medical to financial services (FSI), the standards rapidly evolve and change over time, thus requiring constant maintenance. The sheer cost of maintaining standards is high, not only for organizations but also for EDI software vendors who struggle to keep up. The expensive fees paid to standards organizations and rapidly evolving releases are the main reasons there are no decent open source EDI tools in the community.
Traditionally, large monolithic proprietary Enterprise Application Integration (EAI) Suites included a parser/transformation engine and tooling at their heart. GUI-based mapping tools were the go-to tool of choice for EDI teams, who could focus on field-level mapping and basic field manipulation using a dedicated graphical Mapping tool. As companies began to move away from an ESB architecture to an Agile Integration (Microservices) approach, a large gap formed in the market for supporting EDI. One such example is Apache Camel - an open source, lightweight, agile integration library for implementing Enterprise Integration Patterns (EIP). Unfortunately, Apache Camel and its competitors have little support for EDI.
The answer to our problem is to use a proprietary Mapping tool. The best one I've found is Trace Transformer. Trace has focused on FSI EDI standards such as SWIFT/CREST/FIX in the past but branched into other areas for Transport (X12) and Healthcare (HL7). What makes Trace Transformer appealing to Fuse customers is the deep integration capabilities with Camel - the ability to update the Camel Exchange, Header or Body at runtime and share data sources. Trace has created the ability to build an OSGi bundle that can talk to your Camel routes and deploy to Karaf, as well as the ability to run inside a SpringBoot container. And the best part - it all deploys and runs seamlessly on Red Hat OpenShift using the Fuse Integration Services (FIS) 2.0 xPaaS images.
To demonstrate Transformer working with FIS 2.0 on OpenShift inside of a SpringBoot container, I've created a very simple project here. The Camel route is very simple - set the Camel body to a constant string, call Transformer to modify the Camel body using a Transformer map, then log the output returned from Transformer to the log file:
Trace has created a Camel endpoint called "txfrmr" using the standard URI syntax. You can specify the EDI project name (SampleTransformerProject) followed by the name of the map (Map1), as highlighted above.
The Trace Transformer editor (below) is simple enough for any EDI business analyst (non-programmer) to get a grip on. The EDI BA can focus on what they know best - the business logic and underlying EDI standard, which they map from an input to the output message. Once the map is complete, the EDI BA simply generates an "exposed service" which can either be a simple JAR library or OSGi bundle, which they hand over to their developers to integrate into the Camel route.
Speaking of Camel, Transformer has some excellent functionality for tightly integrating with your Camel Route. The below screen demonstrates some of the mapping actions that are available to read/write data from the Camel exchange, even passing validation exceptions or interacting with shared OSGi data sources.
In my future posts, I plan to walk through a more complicated EDI format such as X12 (transport), BAI2 (banking) and HL7 (healthcare) and how this would look in a Microservices world. Stay tuned.
To learn about Red Hat Openshift Container Platform, allowing you to provision, manage, and scale container-based applications.
