How Much Iguana Code Did We Actually Need

I’ve now started looking through some Iguana channels to see what will be involved in moving them to Integration Soup.

One of the first things I noticed was just how much Lua we have. I already knew some of the libraries were quite large, and I suppose I had always taken some comfort from that. All the code was there, we could see what it did, and if we needed the interface to do something different then we could change it.

What I hadn’t really considered was how much of that code had nothing to do with the actual interface.

There is code for logging, opening and closing database connections, handling errors and making sure that a failure doesn’t leave anything in a bad state. We have also written code around TCP connections, certificates and all the other things needed to keep an interface running properly.

Obviously these are all important. The problem is that they are important for every interface, and we have ended up writing much the same code over and over again.

If it is written again for every channel, there is always the chance that one version is going to be slightly different or have a mistake in it. If it is copied from another channel, that helps at the time, but it also means the same code is now scattered everywhere. When something needs to be improved later, every copy has to be found and changed.

You can move it into a common Lua library, and we have done that where it made sense, but then you have a large library that also needs to be maintained and tested. It is better than having lots of copies, but it is still our code and our problem.

This has been particularly noticeable with security. Some of our older TCP interfaces were created without TLS. That is not a situation they should still be in, but adding it means working through the old implementation and making sure the change is made correctly everywhere it is needed.

In Integration Soup the secure TCP/MLLP connection is already part of the product. I still need to configure the certificate and make sure the other system is set up correctly, but I am not having to write or maintain the code that provides the secure connection.

The same thing is happening with the rest of the conversion. Once Integration Soup is handling the connection, logging and normal error behaviour, a surprising amount of Lua is simply no longer required.

What I am left with is mostly the part I am actually interested in: which fields need to be mapped, what needs to be converted, and any business rules that are particular to that interface.

I can still use code when code is the best way to do something. The difference is that I am using it for the unusual part of the interface, rather than using it to provide all the normal features that I would expect the integration engine to handle.

I don’t think there was anything wrong with having Lua available in Iguana. It certainly meant we could get things working. I just don’t think the size of the codebase gave us quite the advantage I had assumed it did.

So far the converted work is smaller and much easier to follow. More importantly, there is less of our own code sitting between a message arriving and it getting where it needs to go.