Maximo Automation Scripting Practices

I hesitate to call this post a “Best Practices” post, because who am I to prescribe a best practice? I won’t call it that. Instead this is a list of practices that I think are sane and maintainable over the long term.

I am currently on a project overhauling a Maximo instance that has gotten to the point where it is hard to maintain and debug, and there are bugs a plenty. It is a spiderweb of duplicitous workflows and automation script spaghetti code. This instance reveals some dangers of “low code” platforms. People seem to get the idea that they do not have to be concerned with clean programming practices or long term maintainability.

Write good clean code in Automation Scripts

This should be obvious, but it apparently is not. Just because we are using a script interpreter built into a web application doesn’t mean we should be lazy about it. Properly comment and structure your code.

Use good script and launchpoint names

Something that I like to do is name my scripts for the object and method they are working on. ASSET.SAVE for example, or WORKORDER.WORKTYPE.VALIDATE. This will make it easy to find an understand what these scripts are for. Name the launchpoint the same, because you need to migrate this as well and this will make it easier on you.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
# Script: ASSET.SAVE
# Launchpoint: ASSET.SAVE

from psdi.mbo import MboConstants

def setLocation():
    mbo.setValue("LOCATION", "FOO", MboConstants.NOACCESSCHECK)

def setSomethingElse():
    mbo.setValue("SOMETHINGELSE", "FOO", MboConstants.NOACCESSCHECK)

setLocation()
setSomethingElse()

The example above shows a pattern I’ve been following. Keeping all logic related to asset.save in one script, instead of many with their own unique names, is much easier to maintain and debug. I have seen examples on my current project where seemingly no pattern was followed, and finding all the bits of pieces of their business logic is more of a scavenger hunt than it should be.

Using the Python function declaration def myFunction(): I can use good program structure to keep all of the different things you might need clean and easy to modify or turn on or off. If you are just testing something, or the customer asks you to disable it, it’s as simple as removing or commenting out your function calls at the bottom of the script.

No matter what it is, even if it is the only thing the script does at the moment, just put it under a function declaration. It could help you in the future.

The Variables tab is pointless and bad

For reasons that I do not understand, there is a tab in the automation script editor called Variables. It is useless, and actually makes things much much harder to read and understand. Don’t use it. Python already has variables, and the MBO framework is available to you. Why use anything else? Keep things clean and easy to read.

Code reuse? Code reuse!!

You can and should employ code reuse in your automation scripts. Seasoned programmers understand this concept well, there are bits of code you may use in more than one place and it’s often appropriate to put these somewhere they can be called by other scripts or classes.

In Maximo these are referred to as LIBRARY scripts. IBM has a page on it here.

From their examples, they have a script called MULTIPLY.

1
z=x*y

They then use this script in another script. I’ll add more comments than their example has.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
# here is an example of a debug logging
service.log("I want to multiply 2 numbers and log the result")

# import the HashMap from the java.util library. 
# we will use a hashmap to store the parameters we
# pass to our MULTIPLY script

from java.util import HashMap
a=3
b=2

# declare our hashmap and put the values in it
ctx = HashMap()
ctx.put("x",a)
ctx.put("y",b)

# and here is where we call our library script
# service.invokeScript("MYSCRIPT",params)

service.invokeScript("MULTIPLY",ctx)
service.log("the result is "+str(ctx.get("z")))

We name our library scripts clearly, like LIBRARY.CALCULATETHEVOLUMEOFTHEUNIVERSE.

When used appropriately, code reuse means you’ll have less code to maintain. That means less work. We all love less work, right?

Read Bruno’s site

Develop in Maximo for long enough and you’ll wind up on Bruno’s site. Bruno has a wealth of information available and the developers on my team use his site frequently. A link particularly relevant to this post is his automation scripting quick reference. I always have this open if I am writing automation scripts. I do not have a good memory.

Conclusion

And that’s it! There’s not much to it, I just wanted to put this out there. If you are just getting started using Maximo, or are new to using automation scripting, I hope something here gives you a head start. If you are used to Java customization then this will all be easy to pick up, and you probably didn’t need to read this anyway. For those that are coming to Maximo from a different background, I hope this helps you avoid future headaches.

BTW: If you are looking at using a Workflow for something, ask “hey can this just be an escalation or automation script instead?”. Asking that question often could save you a LOT of future headaches. :-)