Maximo Manage 9.1: The Automation Script Warning Framework, Bean Class Events, and the New Test Harness

The Maximo Manage automation script framework is the closest thing the platform has to a "developer surface." It is also, historically, the most common source of mysterious production incidents: a script that compiles cleanly but quietly sets a related MBO to the wrong value, or holds a set open and slowly bleeds the JVM heap, or does a setValue in the wrong launch-point context.

The 9.x line of Maximo Manage — building on work that started in 7.6.1.x and matured in 8.x — has added a series of features that move the framework from "interpreted and trusting" to "instrumented and observable." If you have not revisited your automation script practices in 18 months, this is the article to do it with.

What an automation script actually is, in 2026

Quick refresher. An automation script is three things:

1. A launch point that defines when it runs. There are five types: attribute, object, action, custom condition, and (in 9.x) the bean-class event bridge.
2. Variables and binding values that move data in and out of the script. Variables are optional but almost always a good idea.
3. Source code in either JavaScript (Nashorn-style, with caveats for JDK 17) or Jython 2.7.2.

The compiled script is cached in the database and re-compiled on commit. Most engines compile to bytecode; Jython is interpreted at runtime. Both support the MBO API and the standard service / mxserver context.

The framework is interpreted and run by the scripting framework when a target event happens — attribute change, object save, action click, condition evaluation, or (newer) a bean-class callback. None of this requires a server restart.

The Warning Framework: static analysis that runs on a cron

This is the feature that should change how you operate a Manage environment. The Warning Framework analyzes your automation scripts for known anti-patterns and produces persistent warnings that do not block the script from running.

The framework runs as a cron task. By default it executes every 12 hours. You can run it as frequently as you want — the trade-off is analysis time versus how fresh the warnings are. It uses a combination of regular expressions (for things like the literal "mxe.db.shutdown" reference, or hard-coded user names) and Java class checks (for things like API calls that are known to bypass framework behavior).

Warnings persist until you resolve them. The practical implication: the framework is a CI signal for your Maximo configurations. It is the closest thing Maximo has to a SonarQube pass over your script library.

Patterns the framework actually flags

From the field, the patterns the Warning Framework catches most often are:

• Sets that are not closed or cleaned up. A mxserver.getMboSet(...) without a matching set.cleanup() / set.close(). On a long-lived JVM, this leaks references and eventually causes OutOfMemoryError or set corruption.
• Direct SQL via executeQuery / update from within a script. Discouraged because it bypasses the MBO cache and the framework's transaction model. Worse in MAS 9.x because direct SQL may be restricted in managed deployments.
• setValue calls inside attribute launch points during add events that write to related objects without the right app / mbo context.
• Long synchronous calls to external systems (HTTP, SOAP) inside object launch points — which can hold a database transaction open and cause lock waits.
• Hard-coded userName = "MAXADMIN" or other identity references that break in customer-managed environments with rotated admin accounts.

Each of these produces a warning with the script name, the line where the issue is detected, and a recommended fix. You do not have to fix them to ship — but the dashboard of accumulated warnings is the kind of evidence that travels well into a quarterly reliability review.

Bean-class events: scripting the UI layer

There is a class of Maximo customization that has always been awkward: things that need to fire on a UI bean lifecycle event (e.g., a screen opening, a dialog closing, a tab being clicked) and need to interact with the underlying Java UI framework.

Historically, the only path was a Java customization, a JSP modification, or a "cheat" through the CUI bridge from a script. The 9.x line added a bean-class event bridge for scripts. You can now write an automation script that hooks into a bean-class event for a classic (non-role-based) application.

The catch — and this is important — is the gating. Two system properties must be enabled:

• mxe.script.allowBeanScript — disabled by default. Set to 1 to allow bean-class invocation from scripts.
• On the script itself, the Allow Invoking Script Functions checkbox must be set. Without that, even with the system property on, the bridge will not work.

The naming convention is app.<applicationname>.<functionname>. So for an asset application, you'd reference app.asset.initializeApp or app.asset.save, depending on which bean-class method you want to intercept.

In 2026 practice, this is mostly useful for legacy applications on the classic UI framework. The role-based applications and work centers run on a different stack and do not use bean classes in the same way. If you are building a new customization, the work center extensibility model is usually the cleaner path.

The Test Script harness: no more "find a record and try it"

For years, testing an automation script meant finding a record that matched the launch-point criteria, opening the application, performing the action, and observing the result. The 9.x line added a Test Script action directly in the Automation Scripts application.

The harness reads the script's launch-point metadata, the variables it declares, and the binding values, then drives a small UI that lets you supply test inputs. For REST-based scripts, it builds a synthetic request and lets you invoke the script as if it were a REST endpoint. For object and attribute scripts, it creates a sandbox MBO and runs the script in that context, then shows you the resulting MBO state.

This is genuinely useful for two reasons:

1. You can develop scripts offline from the business. A configurator can build a script, test it against synthetic data, and only hand it to the business when the logic is right.
2. You can regression-test. Save the test inputs as a "test case" associated with the script, and you can re-run it on every Manage upgrade to see if your logic still behaves the same way after a framework change.

There is a limit to what the harness can do. Scripts that depend on deep integration state, on a specific logged-in user's group membership, or on complex interaction with related MBOs (across multiple MBO sets) still benefit from a real-environment test. But the harness removes the worst of the "just click around and see" friction.

Content-type aware REST scripting

The earlier 7.6.1.x line added a REST launch point that always returned JSON. The 9.x line added a content type flag. The script can now obey the request's Accept header and return:

• JSON (default, unchanged)
• PDF (via BIRT rendering)
• XML
• Plain text

This sounds minor. In practice, it unlocks a pattern that has been awkwardly solved with custom Java for years: a script that returns a printable inspection report (PDF) when called from a Mobile inspection flow, but returns JSON when called from a dashboard. The same script, the same launch point, two content types.

System properties you should know about

Two properties govern how the framework behaves under stress:

• mxe.script.autoCloseSets — when enabled, the framework will auto-close any MBO sets that the script opened but did not clean up. The default is off. The IBM guidance is clear: do not depend on this. Your scripts should clean up after themselves. But when you are debugging a memory issue and you do not know which script is leaking, this is a useful temporary switch.
• mxe.script.disableAll — disables every automation script in the system. Useful when you have a problem in production and you need to know whether the cause is a customization. The classic move — admin mode — does not always isolate customizations cleanly. This property does.

A third property, mxe.script.deactivateAll, is the more surgical version: it lets you deactivate a subset of scripts by some criteria without disabling everything.

A 2026 automation script review checklist

For any team running a 7.6 → 9.1 upgrade, or for any team that has accumulated years of scripts, this is the review checklist I'd run:

1. Run the Warning Framework on a non-prod snapshot. Triage the warnings. Anything that shows up in the "memory leak" or "direct SQL" buckets gets a ticket.
2. 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 — Nashorn is not the same in JDK 17 as it was in JDK 8.
3. 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 a MBO API call? Direct SQL is increasingly a non-starter.
4. Find every script that opens an HTTP/SOAP/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 DB transaction open over a network call is the kind of thing that works fine in a 50-user test and falls over in production.
5. 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.
6. Decide on a testing standard. Use the Test Script harness. Save test cases. Re-run them on every Manage upgrade.
7. 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.

Where this is going

Two things to watch. First, the role-based application framework is becoming the preferred customization surface for new work; the classic UI's bean-class bridge is increasingly a maintenance concern, not a development one. Second, the trajectory is toward more of these diagnostics living in the AI Service layer — pattern detection on your script library, suggestion of fixes, automatic generation of test cases. The Warning Framework is the seed of that.

For now, the Warning Framework + the Test Script harness + the bean-class bridge + the content-type flag are the four capabilities that should reshape how your team thinks about automation scripts. If you have not done a script review in 2026, schedule one. The tooling is finally good enough to make it pay off.