Every organization will have different opinions here. I think automation scripts play an important role in the Maximo developer experience to implement requirements that would otherwise could be very difficult, inefficient, or potentially impossible to do with pure configuration. For example, if you needed to trigger a delete of a child object (IE POLINE) when the parent object (IE PO) is deleted, that would be a rather simple automation script. Without automation scripts, you would need to do something silly like write an escalation to look for child records where the parent no longer exists to delete. You could technically achieve it with configuration, but the escalation is objectively not the best way to achieve it.
Understanding what well written code is from an automation script, implementing good review processes, and using the appropriate tool for the job are all critical things to being successful with automation scripts.
Automation scripts provide developers the ability to do things that would violate Maximo business logic. For example, setting a value you can use a flag 11L to suppress access control (being able to write to it even if it's read-only), validation, and action (logic that the field invokes to set other values). I sometimes see in customer environments that they use this frequently but it's something that should almost never be done in an automation script. Because without validation or action, you can cause situations that would otherwise be impossible out of the box in Maximo and end up with hard to troubleshoot issues.
You also need to be careful that the code you're writing is as efficient as possible. For example, customers with object initialize event automation scripts are often using the wrong launch point. This event fires every time the Mbo is initialized, including in bulk situations like integrations, list tab, table downloads, PM WOGEN, etc. Often times this is done to default a value in a specific field and an attribute initialize is more efficient in that scenario because it would only fire if that attribute is being retrieved in the current operation. Something may "work" but negatively impact the user experience in these bulk scenarios.
Having someone with the experience to help guide the team in best practices during code reviews, developing standards for configurations, and being able to say no to high-risk configurations are all critical to being successful.
------------------------------
Steven Shull
IBM
------------------------------
Original Message:
Sent: 05-11-2024 10:08
From: mx pro
Subject: Are Automation Scripts considered Customization?
Thanks Steven for your explanation.
So going with the thing of our organization policy.
So with your explanation, are we breaking our organization policy by having automation scripts?
Or what should be our stance with respect of them?
I am asking because it is significant if we take it as Automation Scripts are customization.. then we are breaking our organization policy....
please advise...
------------------------------
mx pro
Private
Original Message:
Sent: 05-10-2024 14:53
From: Steven Shull
Subject: Are Automation Scripts considered Customization?
Automation scripts are complicated because it's a little bit of both. What I mean by that is we support the framework, such as the various launch points, but we don't support your automation scripts. We bring these scripts forward in an update but that doesn't mean they aren't broken by an update. For example, when we went from Java 1.7 to Java 1.8 most of the JavaScript automation scripts were broken due to the nashorn transition. In this particular situation we warned users about the change but there are other scenarios such as a change in the libraries we provide out of the box, or change in our core Java methods, that could lead to issues with your automation script.
At the end of the day, it's custom code and we're not going to troubleshoot or typically make code changes to help your automation script. But it's significantly better than Java code.
Configuration from our perspective are things we directly support. If you utilize a crossover domain for example, even though your crossover domain was not provided out of box, we support that capability and you can open a support case on it. Same thing with adding attributes via Database Configuration or adding new textboxes via Application Designer. Or as you mentioned, conditions are another thing we'll support. These should not be broken in a patch, and we'll open a defect against the product for these if we break them in a patch. Things like this are what we consider configuration.
------------------------------
Steven Shull
IBM
Original Message:
Sent: 05-10-2024 10:04
From: mx pro
Subject: Are Automation Scripts considered Customization?
Hello All,
I need a clarification and if possible IBM's official position on customization vs configuration.
in my organization, we are implementing Maximo with a "No Customization" policy. We have created several Automation Scripts and Conditional Expressions in our system (7.6.13).
We are clear that Java class modification is considered as customization in Maximo.
What about other options in Maximo, e.g., Automation Scripts and Conditional Expressions.
Also, what happens during upgrade process, e.g., Upgrade to MAS. Does Maximo upgrade utility, automatically handles Automation Scripts?
Thanks in Advance
#Customizations
#EverythingMaximo
#MaximoApplicationSuite
#MaximoUserGroups
------------------------------
mx pro
Private
------------------------------