One of the most common scenarios in an integration context is connecting to external databases. Not surprisingly the JDBC adapter for webMethods Integration Server can therefore be found in most installations. It is also common to have a multitude of connections. Whenever a deployment happens, it is therefore necessary to ensure that the correct connection details are in place. Otherwise data corruption would be a big risk and could lead to extreme problems, up to and including bankruptcy.
Update April 18, 2024: There is a new YouTube video how to build ART Connection Updater from source code .
Update April 15, 2024: The tools is now available on GitHub. There is also a YouTube video with a short demo.
Options available until now
Until now a number of approaches have been available to handle the requirement of updating connection details. But they all come with certain downside, which will be discussed here.
A common issue is that none of the methods below works without running Integration Server. So it is not possible to simply change a setting from a script without the system becoming active.
Manual update using the admin web UI
In an environment that is “static” or has well-working procedures, updates can always be done manually.
However, if you want to do CI/CD that will sooner or later be a problem.
webMethods Deployer
There is functionality in webMethods Deployer to update connection details. But it comes with some details, that do not play too well with some scenarios. Just like it is the better tool compared to mine for other use-cases. And in my opinion building container images is not the ideal scenario for Deployer.
In general Deployer was built to deploy large monolithic applications that span multiple webMethods products. So if you want to deploy integration logic, process models, MWS UIs, Universal Messaging, and Trading Networks all in one go, you should consider Deployer. But for simply updating connection details, it is a bit heavy. That is the main issue.
Another challenge for container images is that Deployer requires a network connection between source and target system, in other words both must be up and running and be able to talk to each other.
There is also a way to export/import the transfer payload. But that is too complex for simply updating a connection setting. Besides, the target system must be running, host Deployer to self-update with it, and later remove it as part of the container image build process. Other configurations are possible as well, but I am not aware of any that is not sufficiently complex.
Sidenote: While not a problem for JDBC or SAP adapter, according to what I have been told a long, long time ago, the connection details update needs to implemented on a per-adapter basis. I never checked whether this was ever true, or still is today. After all, those were the v6.5(?) days of JDBC adapter. Still, if you are using a less popular adapter, you should check whether Deployer works for you.
Microservice Runtime (MSR) dynamic variables
The growing demand from customers has led to the implementation of what is called “dynamic variables“. It is basically a properties file that is read during Integration Server startup and changes the specified settings.
If that is all you need, you are probably already using it. And if it does the job for you, by all means stay with it.
My tool is two advantages, though. Firstly, it also works with Integration Server “classic” and if you have no MSR license the dynamic variables are not an option for you anyway. Secondly, you can use it for all sorts of automation. Think about always disabling connections when a new version of your packages gets deployed. So you wouldn’t have to rely on the discipline of your developers; or need to employ other gatekeepers to ensure this manually.
How the new tool works
The main difference of the JahnTech ART Connection Updater (JTACU), compared to the aforementioned approaches, is that it works without having to start Integration Server at all. Instead it works directly on the file system and changes the values within the node.ndf file (XML format) that holds the connection details. That is the whole trick.
Here is how such a file looks like:
You can see that it contains something that looks a like a BLOB. This is actually a Bas64-encoded IData object. And the best of all is that an API exists to access it. I am not entirely sure how official in nature this API is. But as far as I can tell, it does not use anything that is likely to change any time soon.
As always: Nobody (incl. JahnTech or me personally) will guarantee that things will work with every new version of Integration Server and/or JDBC adapter. So you need to test things carefully.
So here are the steps that are done to update the connection:
- Read file into
Valuesobject - Get entry with
IRTNODE_PROPERTYattribute - Decode it to byte array using Base64
- Build
IDatafrom byte array - Update values in
IDataas needed - Reverse order of the aforementioned steps
Other ART-based adapters
The JTACU is not specific to the JDBC adapter and therefore works with all ART-based adapters for webMethods Integration Server. Please be aware that some adapters (e.g. AS/400) are not built using the ART framework. They are not supported and very unlikely to work at all. On the contrary: There is considerable risk to corrupt settings.
In closing
This article should give you a first understanding about how the JahnTech ART Connection Updater (JTACU) works and what its (so far) intended use-cases are. If you have any questions, please leave a comment or send me an email (address below).
The same applies if you have ideas how to extend it, or for other tools that you might find helpful.
If you want me to write about other aspects of this topic, please leave a comment or send an email to info@jahntech.com. The same applies if you want to talk how we at JahnTech can help you with your project.
© 2024 by Christoph Jahn. No unauthorized use or distribution permitted.
3 Responses
Good one, thanks for sharing. I have some quite an interesting requirement and found that many customers are actually looking for such automation tool to convert SOAP to REST.
Is there a programmatic way to convert Soap web services to REST ?
Thanks for your comment!
The challenge with such tooling is that it has to come with a number of limitations and prerequisites. Just like you cannot reasonably auto-convert from one database type (e.g. hierarchical) to another without a sub-optimal result; you will need to adjust manually afterwards.
Of course it can make sense to automate some of the steps, but every implementation is different and so some more information would be needed. Please feel free to engage here or email me for further discussion.