Interlok

Adaptris


Integration anytime any place anywhere.


  1. Testing Interlok interoperability with AWS

    Mocking AWS interactions with localstack

    One of the habits that most of our team have is to try and run everything on their local machine as much as possible to test behaviour and logic before doing any kind of deployment to something that isn’t directly within our control. It’s habit more than anything, coupled with the fact that we often do a lot of work while we’re not connected to the internet. Virtualisation, and container technologies like Docker are our best friends. …


  2. Service testing my mappings

    How can I be confident that my upgrade works?

    Recently I was involved in a task to test any possibly impacts updating the version of Saxon could have on the Interlok’s xslt transformation service and it got me thinking that the service tester could also be very useful when updating any mappings from xslt 1.0 to 2.0 to make sure we still get the same output. …


  3. Interlok 3.9.1

    Interlok 3.9.1 has been released and is now available for download.

    Interlok 3.9.1 has reached GA. It is now available for download. …


  4. How to manage multiple adapters

    Once you're in production; what then?

    Once you’ve developed your solution and deployed it then you’ll want to monitor it in production. Since all the runtime capabilities of Interlok are JMX based; our UI only uses publicly accessible JMX (there is no special sauce); you can leverage your existing JMX tools to manage Interlok. Of course the Interlok UI is perfectly capable of monitoring multiple Interlok instances which means you can use it as a monitoring tool in the absence of anything else. …


  5. Battling with builds in Windows

    Getting gradle builds in windows working.

    More and more we are using build tools to assist in the creation of Interlok artefacts, until recently there were a few scenarios that didn’t work in windows this meant we had to use WSL to run our builds. …


  6. How to change the jetty work directory

    The Interlok UI starts too slowly; I hate it!

    Do you remember when you were at school; someone did something a little bit naughty and the teacher, rather than pinpointing the culprit, punishes the entire class/year/school. Corporate IT and antivirus programs are a bit like that sometimes. By default jetty will extract all web applications into a temporary folder (usually the system temporary folder). This can lead to long start times as your antivirus of course on-demand scans all the jar files, and sometimes (this is true of MS Defender on some of my test boxen) asks you to upload various jar files for analysis. …


  7. Simplified Branching

    The proposed replacement for branching-service-collection is available

    3.9.0 sees the promotion of the interlok-config-conditional package into the main trunk; as a result you can use a number of new services where you might previously have had to use branching-service-collection; the ultimate aim is to remove the need to use branching-service-collection over the next few releases as we achieve feature parity between the likes of if-then-otherwise; along with its associated conditions; and branching-service-collection. There will always be cases where branching-service-collection may be more appropriate; but we think we’ve covered most of the use-cases with the new classes. …


  8. Interlok 3.9.0

    Interlok 3.9.0 has been released and is now available for download.

    Interlok 3.9.0 has reached GA. It is now available for download. …


  9. Interlok 3.8.4

    Interlok 3.8.4 has been released and is now available for download.

    Interlok 3.8.4 has reached GA. It is now available for download. …


  10. My HTTP Workflow is too busy

    Returning a 503 HTTP response might be better than succeeding slowly

    The Interlok configuration that you’ve deployed is part of of a high-volume, sustained load pipeline; it’s awesome because you’re using it to HTTP proxy some legacy backend system that is a critical part of the pipeline. However, you’re now in a situation where your REST API calls to Interlok aren’t timing out when the legacy system is under-stress; they’re blocking for an unacceptable amount of time before finally succeeding. If it was enabled by an HTTP header on the request (naming Expect: 102-Processing) then you would have been getting periodic HTTP 102 Processing responses back; what you really want is a configuration where you fail immediately if you can’t immediately service the inbound request. …