Maximo Manage Automation Scripts and Launch Points: A Field-Tested Technical Guide
# Maximo Manage Automation Scripts and Launch Points: A Field-Tested Technical Guide
Maximo Manage has always offered two primary paths for extending system behavior: Java-based customization through MBO and MBOSet classes, and automation scripts that live inside the Maximo database and execute at runtime through launch points. For most operational extensions, automation scripts are the better default. They do not require an EAR redeployment, they can be activated without restarting the server, they are portable through Migration Manager, and they place the logic where administrators can see and maintain it.
This article is a deep dive into the automation scripting framework in Maximo Manage as it exists in MAS 9.x and recent Maximo 7.6 feature packs. We cover the five launch point types, the scripting languages supported, how variables and bindings work, common patterns for data validation and work-order automation, integration scenarios, library scripts, and the governance practices that keep a script portfolio maintainable. We also compare automation scripts to Java customizations so teams can choose the right tool for a given problem.
The Five Launch Point Types
A launch point is the bridge between a Maximo event and a script. It defines when the script runs and what data is available to it. There are five launch point types, and choosing the wrong one is the most common source of automation script bugs.
Object Launch Point
An object launch point runs when a record in a business object is added, updated, or deleted, or when it is loaded. It is the most frequently used launch point because it mirrors the lifecycle of a Maximo record. The events available are:
- Before Save
- After Save
- Before Add
- After Add
- Before Delete
- After Delete
- Initialize
Use object launch points when the logic depends on the state of a record as it moves through its lifecycle. A typical example is defaulting field values when a work order is created, validating a purchase requisition before save, or creating a related record after an inspection result is saved. The script has access to the MBO through implicit variables or explicit bindings.
Attribute Launch Point
An attribute launch point runs when a specific field on an object changes. The events are Validate, Initialize, and Action. The validate event is the most common: it fires when a user changes a field and leaves it, giving the script a chance to validate the input, compute a related value, or reject the change. Use attribute launch points for field-level rules that should fire immediately, such as checking that a meter reading is within an acceptable range or populating a description based on a classification.
Action Launch Point
An action launch point runs when a user invokes an action from a toolbar button, the More Actions menu, or a workflow action. It is explicit rather than event-driven, which makes it useful for operations that should only happen on demand. Examples include generating a follow-up work order, recalculating a score, or calling an external service. Action launch points are also the cleanest way to expose automation scripts to users through the UI.
Custom Condition Launch Point
A custom condition launch point is used in workflow conditions or security conditions. It returns a true or false value that determines whether a path is available or whether a user can access a function. Use this launch point when the standard expression builder is not expressive enough for a conditional rule.
Integration Launch Point
Integration launch points are not created through the Automation Scripts application in the same way as the others. They are triggered by naming conventions and configuration in the Maximo Integration Framework. For example, a script can be invoked during an inbound or outbound integration transaction to transform data, add business logic, or call another system. This is a powerful pattern but requires a clear understanding of MIF invocation points and error handling.
Jython versus JavaScript: Choosing the Engine
Maximo Manage supports two primary scripting languages out of the box: Jython 2.7.2 and Nashorn JavaScript. Both engines compile scripts to bytecode and cache them at runtime, so performance is generally similar for simple scripts. The choice usually comes down to team skills, library availability, and the type of integration being built.
Jython
Jython is a Java implementation of Python 2.7. It runs on the JVM and has full access to Java classes and the Maximo MBO API. Teams with Python experience tend to prefer Jython for readability and the ability to reuse Python patterns. The main limitation is that Jython 2.7 is not Python 3, so modern Python libraries that require Python 3 syntax or the CPython runtime will not work. However, Java libraries can be imported directly, which compensates for many gaps.
Example Jython script with explicit variables:
code blockJavaScript (Nashorn)
Nashorn is the JavaScript engine shipped with the JDK. It is also JVM-based and has access to Java classes. Some teams prefer JavaScript because it is familiar to front-end developers or because the syntax is closer to other enterprise scripting languages they use. Nashorn was deprecated in newer JDK releases, so teams on long-term platforms should verify the engine availability in their target Java version. In MAS 9.x, which runs on Java 17, Nashorn is still available through the standalone Nashorn module in many distributions, but this is a compatibility point worth confirming.
Example JavaScript script with implicit MBO access:
code blockWhen to Prefer Java
Automation scripts are not a replacement for all Java customization. Java is still the better choice for complex MBO lifecycle logic, custom field classes with lazy initialization, workflow dialog customization, or performance-sensitive batch operations. The general rule is to start with an automation script and move to Java only when the script becomes too complex, too slow, or requires capabilities that scripts cannot provide. The Maximo Tech Blog comparison of Java and automation script customization remains relevant: both have full access to the Maximo API, but Java offers deeper extension points while automation scripts offer faster deployment.
Variables, Bindings, and the Scripting Context
The automation scripting framework passes data into scripts through variables. Each variable has a name, a type (IN, OUT, INOUT), and a binding. The binding determines where the value comes from: an attribute on the MBO, a literal value, a system property, or a MAXIMO user variable. Proper variable design makes scripts shorter, easier to read, and easier to reuse across multiple launch points.
Input Variables
Input variables are read-only inside the script. They are bound to an attribute value at the time the script runs. For an attribute launch point, an input variable is typically bound to the attribute that triggered the script. For an object launch point, input variables can be bound to any attribute on the object.
Output Variables
Output variables are written back to the bound attribute after the script completes. They are useful when the script computes a value that should be stored on the record. For example, a script that calculates a risk score based on asset criticality and condition can write the result to a custom `RISKSCORE` attribute.
InOut Variables
InOut variables are both read and written. Use them when the script needs to modify a value it also reads, such as normalizing a description field or correcting a capitalization issue.
Implicit Variables
In addition to explicit variables, scripts can use implicit variables such as `mbo`, `mboset`, `user`, and `service` depending on the launch point. These provide direct access to the runtime context. The `mbo` variable is the most common: it is the current business object instance. The `service` variable provides access to MXServer services for operations like creating related records or querying other objects.
Example using the `service` variable to create a follow-up work order:
code blockThis pattern is common in inspection-driven maintenance: a failed inspection result triggers a corrective work order. The script uses the service variable to obtain a remote MboSet, adds a record, sets values, and saves. Error handling and transaction boundaries are important here; if the parent record is rolled back, the related record should also be rolled back unless the script intentionally commits separately.
Common Patterns for Automation Scripts
The same patterns appear across many Maximo implementations. Understanding them saves time and reduces the chance of writing fragile scripts.
Defaulting Values on Record Creation
Object launch points with the Before Add or Initialize event are ideal for setting defaults. Keep defaults simple and avoid database queries during initialize if possible, since initialize fires whenever an MBO is instantiated, which can happen frequently in list views and searches.
Field Validation
Attribute launch points with the Validate event are the right place to enforce input rules. If the script detects an invalid value, it should raise an error using `errorgroup` and `errorkey` so that Maximo displays a meaningful message. Avoid silent corrections in validate events; users should know why a value was rejected.
Example:
code blockCross-Record Updates
When a change on one record must update another, use the `service` variable to open the target set and apply the change. Be careful with recursion: if the target object has its own automation script on save, a circular trigger can occur. Use status fields or flags to prevent loops.
External Service Calls
Automation scripts can make outbound HTTP calls using Java networking classes. This is useful for lightweight integrations that do not justify a full MIF configuration. However, outbound calls from synchronous launch points can block the user interface, so consider using asynchronous patterns or action launch points for long-running calls.
Example outbound HTTP call from Jython:
code blockLibrary Scripts and Reuse
A library script is an automation script that is not tied to a launch point. It contains reusable functions that other scripts can call. Library scripts are useful for shared utilities such as date formatting, logging wrappers, common validation rules, or API clients. They reduce duplication and make it easier to update shared logic in one place.
To create a library script, define it in the Automation Scripts application without a launch point. In another script, import it using the script name. The exact syntax depends on the scripting language. For Jython, library scripts are imported as modules. For JavaScript, they are loaded into the same scripting context.
Best practices for library scripts:
- Keep library scripts focused on a single responsibility.
- Avoid side effects in library scripts; they should be pure utilities or well-documented services.
- Version library scripts through naming or documentation if multiple applications depend on them.
- Test library scripts independently before rolling them out to dependent scripts.
Governance and Lifecycle Management
Automation scripts accumulate quickly in a mature Maximo environment. Without governance, the result is a portfolio of undocumented, overlapping, and fragile scripts that make
...
