-
Interlok 3.8.1
Interlok 3.8.1 has been released and is now available for download.
Interlok 3.8.1 has reached GA. It is now available for download. …
-
Testing Interlok config
Integration isn't hard so why should testing it be?!
I’ve been involved in many integration projects sometimes you’ll hear a developer say “You can test it when its deployed”, often true (I’ve caught myself saying it) but that thinking only applies to integration testing what about the world of unit testing. …
-
Parallel Processing
Executing long running services in parallel
One thing that has been difficult to solve in Interlok is the ability to execute two services in parallel against a message. …
-
Using mapped diagnostic contexts for better logging
Adding the message-id to all the logging
Even in production, it can be very useful to have the message unique-id displayed on every log entry that appears in the log file. If the adapter has many workflows, and is processing a large number of messages; it can be hard to see the wood for the trees. Log4j2 supports mapped diagnostic contexts; and Interlok can interact with that via services or a logging-context-workflow-interceptor. …
-
Interlok as a Jira Webhook
Using Interlok as a Jira Webhook endpoint
We’ve been using Jira for a while now, and they have pretty good integrations with other cloud services. If you’re an MS Teams user, then you can have your own webhook to publish into a channel. Rather than using Jira’s own connector for Teams; we thought it might be a nice idea to use Interlok to hook up Jira with Teams; yes it’s time again . …
-
Colourise your log4j output
Making your log4j console output pretty
When you’re testing your workflows, you’re often looking at the console log. I find it really useful to colourise the output so that errors and such are easily recognisable. We can do this quite easily by including a couple of additional jars into the interlok runtime and having a custom pattern. …
-
Interlok temporary file cleanup
Cleaning up temporary files processing; triggering System.gc() periodically
When you’re working with messages that are backed off to eh filesystem, then you may see find that there are a bunch of files that will be written to your tempdir (either configured explicitly or the value of
java.io.tmpdir
). They will be auto-deleted when messages go out of scope, and garbage collection happens. This will be particularly apparent if your configuration contains a large-message-workflow with a large-fs-consumer; you will find that the original file is left on the filesystem until garbage collection occurs which may be long after any processing has completed. …
-
Upgrading EHCache configurations
Upgrading from deprecated EHCache configuration
The EHCache configuration element <cache> was deprecated in Interlok version 3.6.4 in favor of a <cache-connection> element so you don’t have to repeat your cache configuration in each service and can share the definitions easily. …
-
Failed messages not on the filesystem
Storing failed messages, not on the filesystem, but somewhere else entirely
As a general rule, we recommend that failed messages are stored somewhere that always exists like the filesystem; this is always a bit more predictable, having to error handle your error handling can lead to a rabbits’ warren of twisty little passages all alike. There are times, when you can’t do that because the filesystem isn’t appropriate (e.g. if you’re running in a container, and you haven’t got permanent volumes); you still want to write the messages into a permanent store, and retry them on demand. …
-
You've got mail!
Interlok providing real time data exports using email as the provider
Many times working in an IT team you’ll be asked to provide an extract of data from System A in excel friendly format. I’ve seen this solved in many different ways …