This is going to be the first in a series of blogs post that help explain automation scripting in Maximo. I’ll cover what it is and why it was added to the product in this post. In future posts I’ll focus primarily on how to utilize them to achieve different types of customization requirements but will also cover some relatively unknown functionality that exists inside of Automation Scripts, highlight the pros/cons between customization options (including non-Automation Script options), and discuss some of our best practices in building scripts. Having some coding experience will be beneficial, but I’ll try and help explain most of the code so you can understand why I’m doing what I’m doing. And if you have any questions, feel free to post them on the Maximo forum so others can benefit from the answer too.
Maximo is a highly configurable product (check out our Maximo as a Service page for our offerings). With minimal technical skills, users can add new fields, make screen changes, or restrict values of attributes in Maximo. But once you start needing to go beyond those capabilities, that’s when people start asking questions about Automation Scripts/Java Customizations. And if it’s something you haven’t done before, it can be quite intimidating at first. Hopefully this blog series will help eliminate most of the intimidation and allow you to achieve your business objectives faster.
Let’s start talking about what Automation Scripts are in Maximo. For those who aren’t aware, Automation Scripts are custom code. These can be small scripts (we have some that are only a single line) or very large scripts (we have some that are almost a thousand lines of code). These scripts are typically written in Jython or JavaScript as those are the two languages supported out of the box in Maximo, but any JSR 223 language can be utilized if you configure it. Automation Scripts were added in Maximo 7.5 (a precursor existed in the IT versions of Maximo prior) and were significantly enhanced in Maximo 7.6. IBM has continued to enhance Automation Scripts in various feature packs since 7.6 was released, so someone on the latest version of Maximo 7.6 (currently 7.6.0.9) will be able to utilize some functionality that won’t exist on earlier versions. When that occurs in our examples, I’ll try and be clear what version first supported that and mention alternative options if possible.
Automation Scripts are typically tied to an event in Maximo using a Launch Point. Some of the newer functionality (like integrations) don’t have an actual Launch Point defined and instead are called by utilizing a special naming structure on the script. Understanding these Launch Point options is critical to developing in Maximo (we’ll cover all the Launch Points in detail in this blog series). This flexibility of event options allows you to execute your code at the most appropriate time. This enables your script to get called less frequently which can dramatically improve performance in Maximo for more complicated scripts.
When should you use Automation Scripts? It’s often tempting once you learn the power of Automation Scripts to utilize it for all your customization needs. I have a very strong opinion that scripts should only be utilized when the Maximo framework doesn’t already support what you need to do. A common example I’ve seen where automation scripts are misused is using an automation script to cross a value from one object to another. If there’s no transformation, you’re better off utilizing a crossover domain. These fire reliably (events can be suppressed, preventing your script from firing, or the application could be in admin mode which prevents all scripts from firing) and honestly just work.
Another example I see misused is using an automation script to require or make fields read-only. There are some scenarios where this makes sense, but in most cases using a Global Data Restriction accomplishes this in a much better and more reliable way. Like before, if your script doesn’t fire (either the event is suppressed or admin mode) then something you’re trying to restrict/require from a business process may not be set. And trying to consolidate most of the field requirements in a single place makes it easy to find when you’re looking to identify where it’s being required and under what conditions.
What are some the advantages and disadvantages of Automation Scripts in comparison to Java customization? The biggest advantage in Automation Scripting is the deployment process. Unlike Java customization, Automation Scripts can be added, modified, or disabled without any downtime. That alone makes it hard to beat for most organization. Java customizations can take hours to deploy if you’re clustered, which makes developing and testing take substantially longer in addition to the business impact of losing Maximo access. I often hear from some developers that this isn’t an issue because the business has scheduled downtime hours to deploy these changes. But what happens when your code has a bug? Issues are often identified during business hours and java customizations can’t be turned off or modified without an outage.
Another advantage is you can easily tie your automation script to fire with multiple events in Maximo. For example, if you wanted a script to fire when the assetnum or location attributes change, you can do that with an automation script and two launch points. You can call the same piece of code with Java Customizations, but you must extend (or write) the field class for each of the attributes which requires you maintaining more code than just writing that common portion.
One of my favorite advantages is utilizing Automation Scripts allows you to take advantage of both languages. Scripts in general are typically simpler than the same code in Java. But where this really saves time is when there’s a really great way to do something in Jython that is more difficult or verbose in Java. A simple example is checking if an attribute in Maximo is set. Sometimes when you call getString(“ATTRIBUTENAME”) you get a NULL value back, sometimes you get a blank string. In Java you have to write both checks like getString(“ATTRIBUTENAME”)!=null and getString(“ATTRIBUTENAME”)!=””. In Jython, I can just say if mbo.getString(“ATTRIBUTENAME”) and it will handle both scenarios. Don’t worry about the example (we’ll cover that in our next blog post), just felt it was easiest to highlight the example.
There are some disadvantages to using Automation Scripts for customization. The first is if it’s something that needs to be done when in Admin mode, you’ll need to write Java code. We don’t find that to be a common use case because most of our customizations are business oriented, and business transactions shouldn’t occur during admin mode for reasons other than just scripting.
Another example where Java customizations are better is when you need to override a method to suppress logic. For example, let’s say IBM does something in one of their class files that you don’t want to occur. You can try and undo what they do in that method in a script, but if you write a java class you can simply prevent the code from being executed and just execute your custom code. Again, this isn’t common for us because if IBM is doing something, it probably should be left alone or you’ll risk causing other issues down the road.
Finally, there are just times where an automation script isn’t possible. IBM has continuously added additional events for automation scripts to listen on and improved functionality (like Yes/No/Cancel dialogs), but there will be times you need to do something that just isn’t possible with the current framework. Some will improve in future releases (like being able to close a dialog!), and some may never make it. Automation scripts will never have 100% coverage but will help the average administrator of Maximo accomplish some amazing things.
The next blog post will cover the various launch points and some important concepts like implicit variables such as mbo and they’ll start working with more detailed examples. Click here to Request a Maximo as a Service Free Trial!
