If anyone is interested, a first version of the JT_Health package is there, altough not public yet,

Please let me know if you are intested in early access; either via direct message here in the forum or by email

Great idea Looking into it right now and will get back asap

This is just for smoke testing, and it corresponds more or less to what the MSR /health endpoint provides.
I wanted to highlight the importance of automatically checking the status of adapters after starting the integration runtime. The adapters’ config is automated, the same goes for the checks on these adapters.
At that level, a custom flow service could be implemented, that deals with these checks and exposes status information that can be used by a k8s probe.
But your tool could also provide a generic health feature using pub.art.connection:queryConnectionState

When the following aspects are relevant, the added value could lie in:

• Update happens entirely outside MSR/IS
• One file per connection makes the following things easier
  • Separation of ownership if multiple persons/teams are working on a solution/application
  • Version control
  • Storage location together with the solution as opposed to a single file for the entire system. This can also have an impact on dependency management in (Micro-)services-based architecture.
  • Automated generation

I am also open to add functionality that helps people. How this changes the value proposition remains to be seen.

For MSR users that are happy with the OOTB solution there is indeed no need to switch. That is why I also explicitly mentioned this in my blog post.

Correct

I would usually approach this aspect with a synthetic transaction: Something that the target system more or less ignores, but still reports back a successful connection and also additional aspects. For a database I usually did a check against the version of the schema using something like Liquibase.

Would be interested what other aspects you consider relevant.

Also, if someone needs a specific functionality, please let me know.

Thanks for pointing this out ! This is only relevant for the demo/using the services from IS. The tool runs completely independently and doesn’t even know the value of this setting.

Hope this helps.

Thanks,
Christoph

For MSR users (where there’s properties based configuration available out of the box), what’s the added value of this tool?

For IS users, this provides the externalized configuration capability that’s missing for containerized deployments.
To use it I would:

• build a new custom IS image that includes this package (with the appropriate exec rights for the script)
• in the deployment descriptor
  • mount the cnf files from k8s secrets (since it will usually contain passwords)
  • run the tool using a command. I would probably write a wrapping script here, since I need to include the original entry point, and manage one tool exec per adapter

What would you recommend to check the health of these adapters after starting the IS? The MSR has a health endpoint that we can use to check is connections are active or suspended.

Regarding the AllowInternalPasswordAccess setting, does it have to set to true for the tool to work? Or was it just for your demo?