Automation Scripts in Maximo Manage 9.1: The Warning Framework, the Bean-Class Bridge, and What Your 7.6 Code Actually Looks Like in JDK 17

Automation Scripts in Maximo Manage 9.1: The Warning Framework, the Bean-Class Bridge, and What Your 7.6 Code Actually Looks Like in JDK 17If you have been running Maximo for any length of time, your automation script library is one of the most valuable assets you own, and one of the most dangerous. Every business rule your team has ever needed, every edge case the out-of-the-box configuration could not handle, every integration edge that needed a few lines of glue, is probably sitting in an automation script somewhere. The total code base can be hundreds or thousands of scripts. The same scripts that have been quietly running your business for years are now the highest-risk asset in your upgrade to 9.1, because the runtime underneath them has changed more in the last two releases than in the previous ten.

Maximo Manage 9.1 runs on JDK 17, not JDK 8. The Nashorn JavaScript engine that Maximo has used for JavaScript automation scripts since the 7.x line is deprecated in JDK 11 and removed from JDK 15 onward. IBM has shipped a compatibility layer, but it is not a perfect emulation. Scripts that worked in JDK 8 may have edge cases, performance regressions, or outright failures in JDK 17. The same is true of Jython scripts, which run on Jython 2.7.2 and have their own compatibility considerations.

The Warning Framework, the bean-class bridge, and a renewed emphasis on resource cleanup are the three changes you need to understand to take your automation script library safely into 9.1. This article walks through each, gives you a concrete review checklist, and shows you the kind of refactor that turns a problematic legacy script into a clean, modern 9.1 script.

The Warning Framework: Your Script Health Dashboard

The Maximo 9.x Warning Framework is a static and dynamic analysis tool that runs against your automation script library and surfaces the patterns that are most likely to cause problems in production. It is not a code linter in the academic sense. It is a curated set of warnings, each tied to a known failure mode, with severity ratings and remediation guidance. The framework runs in the application, it runs against your specific library, and it produces a report that you can act on.

The warnings that matter most fall into a few categories. The first is direct SQL access. Scripts that call executeQuery or perform update operations against the database are flagged because direct SQL bypasses the MBO framework, bypasses the integration framework, and bypasses the auditing and security layers. In 9.1, the framework warns on every such usage and asks you to justify it. The remediation is to move the logic to an MBO API call, to a publish channel, or to a MIF-driven object structure. The justification is sometimes legitimate — bulk operations that the MBO framework cannot handle, complex joins that the integration layer cannot represent — but in most cases the script is doing something that should be done a different way.

The second category is resource leaks. Scripts that open MboSets, JDBC connections, or HTTP sessions without a finally block that closes them are flagged. This is the single most common source of long-tail JVM issues in Maximo environments. A script that opens a set, hits an exception before the finally block, and never closes the set will hold the database connection for the lifetime of the JVM, eventually causing connection pool exhaustion. The Warning Framework catches these by looking for MboSet allocations that are not paired with a corresponding close() or cleanup() call. The remediation is mechanical: add a finally block, close every set, log the closure, and move on.

The third category is hard-coded credentials, environment-specific paths, and configuration values that should be externalized. Scripts that contain database passwords, LDAP bind credentials, or file system paths that only work in one environment are flagged. The remediation is to move the value to a system property, a maximo.properties entry, or a configuration document. This makes the script portable across environments, and it makes the secret manageable through your secrets management tooling.

The fourth category is synchronous network calls inside database transactions. Scripts that open an HTTP, SOAP, or REST connection inside an object or attribute launch point — which means inside a database transaction — are flagged because they hold the database connection open while waiting for the remote system. This works in a 50-user test environment. It falls over in a 2000-user production environment under load, because the connection pool gets exhausted waiting for slow integrations. The remediation is to move the network call to a publish channel, an external system call, an outbox event, or a queue.

Run the Warning Framework on a non-prod snapshot of your environment as the first step of your upgrade planning. Triage the warnings by severity. Open tickets for everything in the memory leak and direct SQL categories. Make those tickets part of your 9.1 upgrade scope. Do not try to fix them all, but do make the decision consciously for each one.

The Bean-Class Bridge: New Power, New Discipline

Before 9.x, the only way to invoke a Java method from an automation script was to go through one of the framework-supported paths: an MBO setter, a custom field class, an integration endpoint, or a service call. If you needed to call a custom Java class that was not exposed through one of those paths, you were stuck. In 9.x, IBM added the bean-class event bridge, which lets a script invoke a method on a managed bean that has been registered in the application server's bean registry.

The capability is real, and the use cases are legitimate. There are times when a piece of business logic is too complex or too performance-sensitive to live in a script, and you need to invoke a compiled Java class. The bean-class bridge gives you that escape hatch. It is also a way to start moving the most performance-critical scripts out of the script runtime and into compiled code, which is a long-term win for stability.

The discipline is the system property that controls whether the bridge is enabled. The property is mxe.script.allowBeanScript, and it is disabled by default. This is the right default. The bridge should not be turned on globally. It should be turned on per environment, and the scripts that use it should be inventoried, documented, and audited. The setting on the script itself, the Allow Invoking Script Functions checkbox, is the per-script gate. Without that checkbox set, even with the system property on, the bridge will not work for that script. Both controls must be in agreement for the bridge to be usable.

For teams that adopt the bridge, the operational practice should be: turn on the system property in non-prod first, validate the scripts that need it, document the justification, then turn it on in production with a specific list of approved scripts. Treat the bridge the way you would treat any other privileged capability. Audit which scripts use it. Review the list quarterly. Disable the system property in any environment where it is not needed.

The Warning Framework does not flag bean-class bridge usage as a problem, but it does flag the underlying patterns that often lead to it. If a script needs the bridge because it is doing something that the framework cannot do, that is a signal that the framework integration should be reviewed, not a signal that the bridge should be the default solution.

The JavaScript to Jython Decision in JDK 17

The 7.6 era JavaScript automation script and the 9.1 era JavaScript automation script are not the same thing. The underlying engine is different, the available APIs are different, and the performance characteristics are different. The Nashorn engine in JDK 8 was a complete JavaScript implementation. The compatibility layer in JDK 17 is partial. It handles the common cases, but it does not handle every edge case. The result is that some scripts that worked perfectly in 7.6 will run in 9.1 but with subtle differences in behavior, performance, or error handling.

For new development, the default should be Jython. The Jython 2.7.2 implementation is well-maintained, well-documented, and stable in JDK 17. The Maximo framework's own MBO API is most naturally expressed in Jython, and the official IBM documentation and code examples have been Jython-first for several releases. JavaScript is still supported, but it is a second-class citizen in the documentation, the examples, and the support experience.

For existing scripts, the decision is more nuanced. The pragmatic approach is to leave working JavaScript scripts alone, unless they show up in the Warning Framework report or unless they exhibit behavior changes after the upgrade. The cost of converting a working script to Jython is real. The cost of leaving a working script in JavaScript is low, as long as it is on the inventory and the team understands the engine differences.

The scripts that should be considered for Jython conversion are the ones that do anything more complex than field-level validation. A script that checks a field value and sets another field is fine in JavaScript. A script that iterates a related MboSet, performs calculations, calls multiple MBOs, and writes back to the database is a candidate for Jython. The complexity threshold is roughly the point at which the script starts to use language features that the JDK 17 compatibility layer may not fully support.

The script that should definitely be converted is any script that uses the Nashorn-specific Java extension APIs. These were a feature of Nashorn that allowed JavaScript to call Java classes directly, with a syntax that does not exist in any other JavaScript engine. The compatibility layer in JDK 17 may handle some of these, but the long-term guidance from IBM and from the broader Java ecosystem is to not rely on them.

Cleanup Discipline: The Single Highest-Value Refactor

If you take only one piece of advice from this article, take this one. Every MboSet your script opens must be closed. Every database connection your script opens must be closed. Every HTTP session your script opens must be closed. The closing must happen in a finally block, so it happens even if an exception is thrown.

This is not a stylistic recommendation. It is a stability requirement. A script that opens a set, hits an exception, and never closes the set will leak the database connection. Over time, the leak accumulates. The pool fills. The next script that needs a connection waits. The application appears to hang. The operations team pages the DBA, who finds hundreds of idle sessions held by the application server, restarts the JVM, and the problem goes away until the next leak. This is a real pattern, and it accounts for a meaningful fraction of Maximo availability incidents in environments that have been running for years.

The refactor is mechanical. The pattern looks like this:

# Before
def autoCreateWorkOrder():
    woSet = MXServer.getMXServer().getMboSet("WORKORDER", mbo.getUserInfo())
    newWO = woSet.add()
    newWO.setValue("DESCRIPTION", "Auto-generated from inspection")
    newWO.setValue("WONUM", mbo.getString("WONUM"))
    newWO.setValue("SITEID", mbo.getString("SITEID"))
    newWO.setValue("WORKTYPE", "CM")
    woSet.save()

The pattern is the same for any resource your script opens. MboSet, JDBC connection, HTTP session, file handle. Open in the try block. Use in the try block. Close in the finally block. The discipline is not complex, but it must be applied uniformly across the entire script library. The Warning Framework can help you find the scripts that are missing the discipline. The refactor itself is one of the highest-value changes you can make in your 9.1 upgrade.

The Upgrade Checklist: What to Review Before You Promote

For any team running a 7.6 to 9.1 upgrade, or for any team that has accumulated years of automation scripts without a comprehensive review, this is the checklist to run. Each step is something a single technical lead can drive in a week or two of focused time.

Step one: run the Warning Framework on a non-prod snapshot. Triage the warnings. Open tickets for everything in the memory leak and direct SQL buckets. Those are the tickets that go into the upgrade scope.

Step two: inventory scripts by launch-point type and language. Anything still in JavaScript that does anything more complex than field-level validation should be considered for Jython. Anything that uses Nashorn-specific Java extension APIs should definitely be converted.

Step three: find every script that calls executeQuery or update. Decide: does this need to move to an integration object, an automation script with the MIF framework, or to an MBO API call? Direct SQL is increasingly a non-starter.

Step four: find every script that opens an HTTP, SOAP, or REST connection inside an object or attribute launch point. Move those into a publish channel, an external system call, or an outbox event. Holding a database transaction open over a network call is the kind of thing that works fine in a 50-user test and falls over in production.

Step five: make sure every script has a finally block that calls set.cleanup() and set.close() on every set it opens. This is the single biggest source of long-tail JVM issues.

Step six: decide on a testing standard. Use the Test Script harness. Save test cases. Re-run them on every Manage upgrade. The cost of building the test library is real. The cost of not having it is much higher.

Step seven: document the scripts that need the bean-class bridge. The mxe.script.allowBeanScript flag is off by default for a reason. Do not turn it on globally. Turn it on per environment, and audit which scripts actually use it.

Practical Implications

The automation script story in 9.1 is the story of a platform that has matured. The Warning Framework gives you the visibility that you did not have before. The bean-class bridge gives you the escape hatch that you sometimes need. The resource cleanup discipline gives you the foundation that everything else depends on. But none of these work without an upgrade plan that treats the script library as the strategic asset that it is.

The implication for upgrade planning is that the script review is not a footnote. It is a workstream. It needs an owner. It needs a timeline. It needs a definition of done. The teams that get this right treat the script review with the same rigor as the database upgrade, the cluster upgrade, or the integration testing. The teams that get it wrong discover the script issues in production, on day one of the cutover, when there is no time to fix them.

The implication for ongoing operations is that the script review is not a one-time activity. Every new script should go through the same review process. Every significant change to an existing script should be re-validated. The Warning Framework should be run on a regular cadence, not just at upgrade time. The bean-class bridge usage should be audited quarterly. The script library should be a managed asset, not an accumulated one.

Bottom Line

Maximo Manage 9.1 on JDK 17 is a more capable, more secure, more observable platform than any previous Maximo release. The automation script story reflects that. The Warning Framework surfaces the patterns that cause production issues. The bean-class bridge gives you a controlled way to extend the platform when the framework is not enough. The cleanup discipline gives you the operational stability that the platform needs to scale. The upgrade path is well understood, well documented, and within the capability of any team that has done a major Maximo upgrade before. The only mistake is to skip the script review and hope. Hope is not a strategy. The Warning Framework is.