Using a Global System Properties in an Automation Script

Maximo has a neat feature where you can set any value in the global property, and it will default to that value you have entered. In order to use a global property, you first must create one. In our example we created a global property for the person who does the PO Reorder.

After you create the global property, ensure you click on Live Refresh, so you can use the new global property created.

This is helpful because I could now use this global property in my automation script.  In order to get the global property, First must create a variable like down below. “configData = MXServer.getMXServer().getSystemProperties()”

After that create another variable and get the property you have created.

“reorderAgent = configData.getProperty(“POReorderBuyer”)”

Once you completed these steps you can now use the variable “reorderAgent” which is grabbing the system property and you could use in the automation script any where you want. In our case we are setting the “PURCHASEAGENT” to the “reorderAgent” when the po description has reorder in it.

I highly recommend using this as it is helpful because now you don’t have to create a variable with the value hardcoded. So, example if this person ever goes on vacation, we could simply just adjust the global property value and this automation script will adjust the reorderAgent based on the new person we put. Instead of going into the automation script and changing the variable that was hardcoded.

We have a culture of education and paying it forward at A3J Group. Subscribe below to be the first to get the latest releases from our knowledge bank.

Updating End Points and Reloading Cache in Automation Script

In Maximo you can use End Points to point to External APIs to pull in data. You can invoke those End Points in a variety of ways, including inside an Automation Script. Take the following code as an example:

handler = Router.getHandler('ENDPOINTNAME');
responseBytes = handler.invoke(null, null);

You can then parse the response that comes back and use that data in any way that meets your needs. Recently we were working with an external API that required an initial login to capture an API Key to be used with future calls. We called the Login API and then grabbed an API Key from the response object. We then needed to update a different End Point to utilize this API Key as an HTTP Header in future calls.

This appeared to work in Maximo as we would see the data show up on the updated End Point. However, each time we invoked the End Point it would throw an error that it was not able to connect. We would then restart Maximo and everything would start working. What we found is that End Point data in Maximo is cached. After updating an End Point, we needed to reload the End Point cache to make a successful connection. To do that we added a line in the automation script after we updated and saved the End Point with the new API Key. The line that is needed is:

MXServer.getMXServer().reloadMaximoCache(EndPointCache.getInstance().getName(), true);

After running this code we can now successfully call our updated End Point. Be aware that there are several similar objects that are cached when Maximo starts up, such as Relationships, Integration information, some Domain information, etc. If updates are made to those records, you may need to refresh the Maximo cache for those records as well.

Hope this helps!

MBOs in Maximo Automation Scripts: Intro – Using Java Methods

Maximo has consistently remained at the top of the list of Enterprise Asset Management systems throughout the years. While there are many reasons for this, one of the most important reasons has been its ability to easily adapt to different business requirements through configuration of the system.

In earlier versions, developers were able to extend core Maximo Java classes to invoke specific business logic. This offered an unprecedented amount of control for organizations to be able to tweak the solution to fit their needs. While this capability still exists, many organizations have subsequently shied away from these types of changes as they have upgraded their systems over the years. The skills necessary to maintain these customizations were difficult for a lot of organizations to supply, and IBM, understandably so, did not offer support for those heavily customized systems.

Automation Scripting was a new feature that was introduced in Maximo v7.5 based on the feedback from the user community. Customers yearned to have a simpler, yet effective way of customizing the product without having to go through the pain of system downtime and adopting the steep learning curve that came with Java coding and extending the existing Maximo classes.

Automation Scripting provides a lot of benefits to make custom business logic easy within Maximo. However, having knowledge of the Java methods available on Maximo Business Objects (MBOs) can greatly enhance your ability to perform meaningful or deep business logic changes within the system.

Subsequent blog article entries will cover in detail how to:

  1. Working with collection objects (MBO Sets)
  2. Reading single attributes of a collection
  3. Reading multiple attributes of a collection
  4. Modifying an object in a collection
  5. Adding new objects to the collection
  6. Exception handling
  7. Attributes with value lists
  8. Changing status
  9. Object relationships
  10. Query by example
  11. Long descriptions

… and more.

Hopefully these articles will unlock the ability to make the most out of the Automation Scripting capabilities of Maximo, and allow users to develop some useful business logic enhancements to their Maximo systems.  Look for our MBOs in Automation Scripts Series to run on the third Thursday of the month until completion.  And also check out some of our other articles here.

Automation Scripts: Compatibility with Maximo 7.6.1

I recently setup a Maximo 7.6.1 environment. After browsing the new user interface and investigating some of the new features I imported an old JavaScript-based automation script that I like to use. Upon executing this automation script I was met with an error on Line 1. This particular script is called remotely using OSLC.

Here is the message:

BMXAA7837E – An error occurred that prevented the <script> script for the null launch point from running.\n\tReferenceError: \"importPackage\" is not defined in <eval> at line number 1.

Here is the start of my script:

importPackage(Packages.psdi.server);
...

If you are like me you have many scripts that import Java packages so this was certainly alarming.

Why is this happening?

Maximo 7.6.1 uses a different scripting engine with the move to JDK 1.8. You may also encounter this with 7.6.0.6 (and newer) if using JDK 1.8. Given that, I wasn’t completely surprised my script didn’t work but I was surprised that there was not more written about encountering this message and what to do if your scripts no longer work after upgrading.

How do I fix it?

It turns out the answer was in an IBM document all along, but it took a while for me to use the correct phrase in my search engine in order to locate it. At the very end of the document, Maximo 76 Scripting Features, there is mention that the Rhino JavaScript engine was replaced with Nashorn (V8). I was aware that this was happening but I was not aware of what this change meant. It turns out that Nashorn does not permit the import of whole Java packages which sheds light on why I was getting that error above.

Thankfully there is a workaround for your old scripts! Add the following line to the beginning of your script:

load("nashorn:mozilla_compat.js");

This article references how to properly construct your script to take advantage of the new script engine. At least with the workaround above you can get your script working and improve upon it later.

Hopefully this will save you time when using your old JavaScript based automation script in a Maximo using JDK 1.8.