My Profile Photo

Adaptris


Integration anytime any place anywhere.


  1. When to write custom code revisited

    Interlok is a bit like pick'n'mix; I prefer fizzy cola bottles, maybe you like flying saucers

    We pride ourselves on not having too much of an opinion about whether or not you should write code, or use configuration to achieve your integration. If you have, by instinct, a developer mindset then you’ll naturally gravitate towards writing code because that’s what you’re most familiar with. This is something that we get quite a lot from new customers where their technical team are primarily developers. I can do this in language X; but I can’t in Interlok; why should we bother using it. That’s one way of looking at it; we prefer to look at it in terms of what does Interlok give us that means we can spend more time on providing business value. …


  2. Abusing Interlok as a programming language

    Interlok configuration probably isn't Turing complete; but we can write code in XML...

    We’re busy migrating away from Bitbucket; not because there’s anything wrong with it; but because as an organisation that’s grown out of 6+ companies, you have to rationalise and standardise things like source control; we’re using GitHub, Bitbucket, multiple on-premise Gitlab instances, Azure TFS; you get the picture. Apparently we need a spreadsheet (it’s always a spreadsheet) of all the projects that are currently in Bitbucket and when they were last used. That’s right; it’s Interlok Hammer time. …


  3. build.gradle parent for Interlok

    Import our build parent to simplify your build.gradle

    We’ve standardised on gradle as our build tool of choice when developing solutions with Interlok. Since it’s possible to end up down a rabbit warren of scripting with gradle; maintaining the build script is one of key considerations, while also providing what we consider best practise when working with Interlok. As a result, we have an early preview release of our proposed parent gradle file that you can start using when developing Interlok based projects. …


  4. Upcoming changes in 3.10

    Early notice about things that might break your deployments in 3.10

    3.9.2 was internally named Replacement Killers and the next release currently in development also has a similarly themed name; we had a thing for Chow Yun Fat films this year… This next release is intended to be the last release in the 3.9 series, and 3.10.0 may break some existing deployments. …


  5. Configuration evolves, nothing stays the same

    You can cut and paste old config; but you probably should investigate new features

    One of the things that happen when you start using Interlok for any length of time is that you end up copying old configuration, templated or otherwise; it works, there aren’t any deprecation warnings, and it gets the job done. In some cases, what we might have done previously is different to how we’d approach the problem now. A case in point is the building up of complex metadata values. …


  6. Interlok 3.9.2

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

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


  7. The new PGP services

    A collection of services that provide PGP encryption, decryption, signing, and verification.

    Interlok PGP is a collection of services that provide an easy way to perform the major PGP functions: encryption, decryption, signing, and signature verification. It uses Bouncy Castle to do the heavy lifting. …


  8. R.I.P. Dynamic Service Locator

    Dynamic services have changed; plus ça change, plus c'est la même chose

    In 3.8.4 we deprecated dynamic-service-locator; this decision wasn’t taken lightly, but change and evolution is necessary so that you can get where you want to go. Originally dynamic-service-locator came about so that people could make changes to configuration independently of restarting. It was only really useful if your possible configurations didn’t require new components (e.g. you always dealt in XML, and never used JSON). In fact a lot of the time it was abused by people logging to the production system and modifying config directly which wasn’t nice. Even though it’s deprecated; changing the service chain that you execute based on various things at runtime is still possible within Interlok. …


  9. 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. …


  10. 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. …