I’m never really been all that interested in data manipulation; one of my stock phrases is it’s just data¹. From an integration perspective I might never understand the business semantics around each field in your data file. The critical part of our work is to make sure that your data gets out of System A, and gets to System B in the right format. For me, the interesting part is always understanding the esoteric limitations or complexities around the communications protocol rather than the data formatting itself. This probably goes back to messing around with protocol analyzers and gender benders (not that kind; the kind that you fit to an RS232 port) when I first started.

Anyway, the adapter has an EDI transformation engine which can turn XML into its appropriate EDI representation; one of requirements of EDI is that you need to have a document number for each document. Most of the time, this needs to be generated by us as the original data doesn’t have it. Previously someone; they shall remain nameless (you know who you are); wrote a simplistic java class that wasn’t threadsafe, relied on lots of java behaviour that was prone to errors, to increment a number in a hashmap and this ended up being used in a number of mappings which are now being reviewed. The extensions provided by Xalan that enable behaviour this within a stylesheet is yet another reason why the adapter hasn’t quite moved away from Xalan yet.

Once upon a time, a very long ago now, about last Friday, I was provisioning some new VM images kindly provided to me by our infrastructure team. Apparently I have my own dedicated ESX server (admittedly running on some old hardware they had lying around) with which to play around to my heart’s content. That environment is intended to be a replacement for this server; but truth be told I haven’t had time to migrate all the services running on this machine over. In fact I’m currently having trouble making hudson run the unit tests.

Anyway, I was in a rush and setup mod_ajp_proxy/tomcat on the box without really thinking about what I was doing. To cut a long story short, I missed off the most important line in the proxy configuration Deny From All which meant that effectively this box was operating as an open proxy.

Oh dear…

At the moment, for legacy reasons, the adapter ships with Xalan as the XSLT transformation engine. There are still a lot of stylesheets out that that won’t work with XSLT 2.0. If your environment is XSLT2.0 only then our recommendation has always been to switch the default transformer factory to something like Saxon using the appropriate JVM system property on the commandline : -Djavax.xml.transform.TransformerFactory=net.sf.saxon.TransformerFactoryImpl but this makes all the transforms use saxon as the XSLT processing engine.

What if you wanted to use Saxon and it’s XSLT 2.0 engine on a per transform basis?

This week I had the first real use case for embedding a script inside an adapter workflow. In one particular instance we were actually receiving EDI files that were terminated by an odd character; od and hexdump thought it was \0205 (0x85) but when we read the file in using a java test stub it turned out to be 0xffffff85 which was annoying to say the least.

We can turn it into 0x85 by doing a classic & 0xFF, but you can’t do that terribly easily within the adapter, so this is a perfect chance for us to use [jruby]!

As we all know error handling within the adapter can be configured at the workflow, channel or adapter level. Most of the time we just write the original file out to something that can’t fail (well, unlikely to fail in the context of things) like the file system.

What if you want to do more with it?