SUMMARY:

Mark Robbins pointed out that a better title for this post might be:
I'm frustrated with the time that is required for adding logic via OOB functionality vs. automation scripts.

To put it frankly, I'm giving up on putting logic in tables and using OOB mechanisms (like formulas and crossover domains). Instead, I plan to hardcode/customize Maximo with automation scripts -- since that seems to be the more practical option.

---

DETAILS / OPTIONS:

I have a long list of fairly simple requirements like this:
If the top level of the WO classification is FLEET, then set WORKORDER.FLOWCONTROLLED to 1.

My initial thoughts on how to implement that would be:

---

Option #1:

Put the logic in a table (and use OOB functionality like a crossover domain):

1. Add a custom FLOWCONTROLLED YORN field to CLASSSTRUCTURE.
2. Batch update CLASSSTRUCTURE.FLOWCONTROLLED to 1 where the top level of the classification is FLEET.
   • I would do this using MxLoader.
3. Set up a crossover domain to auto-populate WO.FLOWCONTROLLED when the classification is modified in the WO.
   • In reality, we would use an automation script instead of a crossover domain, since we've found Maximo doesn't always honor crossover domains when creating WOs (buggy). For example, crossover domains aren't honored when a WO is created via a PM/JP/route.
4. Deploy and apply the changes to all environments (6).
   • The new FLOWCONTROLLED field in CLASSSTRUCTURE will require a db config outage.
   • I would apply db config changes myself to non-clustered environments (4).
   • We would need to plan/coordinate with the WebSphere team to get them to apply db config changes to the clustered environments (2). This involves after-hours work (after midnight; overtime) and of course, a system outage.

I'm under the impression that it's best to put logic in tables when we can, and use OOB functionality, instead of hardcoding the logic in code (i.e. automation scripts).

Benefits of OOB functionality include:

1. OOB functionality is easier to read/understand than code.
2. DRY - Don't repeat yourself. We only need to enter the logic into the table once.
   • It's easier to make bulk updates to tables, than it is to make bulk updates to code. 
   • It would be easy to refine the logic. For example, if the requirement changed and only some of the FLEET WO classifications required flow control, it would be easy to refine the data in CLASSSTRUCTURE by setting some of the FLOWCONTROLLED values to 0 instead of 1.
3. Database tables and OOB functionality can be easily upgraded. Code is much harder to upgrade.
4. My organization considers automation scripts to be customizations. And customizing systems is a violation of corporate policy. Ideally, I would put logic in tables, and use OOB functionality, to avoid violating corporate policy.

A note about attribute formulas:

I've pretty much given up on attribute formulas as an alternative to automation scripts. I gave formulas a fair shot, but I've found them to be too limited, too buggy, and the documentation too sparse. IBM plans to fix some of the bugs with formulas in future releases, but that doesn't help me right now. Especially since my organization doesn't have the resources to do the testing that would be required to apply iFixes or upgrade to 7.6.1.3 -- at least not in the near term. There would be too many problems to deal with, especially with Maximo add-ons.

Problems:

To be honest, option #1 is way too much work -- since it involves db config changes (including clustered environments). It would require many hours of effort from admins and the WebSphere team. Not to mention an outage.

---

Option #2:

Hardcode the logic in code (automation scripts)

In contrast, I think I could implement the requirement quite easily by hardcoding the logic in an automation script. I don't actually work with automation scripts much yet, but I'm guessing a line of code would do it:

1. If WO.DVISION = FLEET, then set WO.FLOWCONTROLLED to 1.

Benefits to hardcoding the logic in scripts:

1. Takes minutes, not several hours/days.
2. No db config outage required.
   • I could easily make the change myself, by pasting that script into all 6 environments.
3. All logic is in one place -- in the Automation Scripts application.
   • If we're wondering what mechanism is responsible for populating a custom field, we know where to look -- automation scripts. There isn't any hidden functionality in formulas or crossover domains that we forgot about.

Problems:​​​

1. We don't get any of the benefits from #1.
2. Code is difficult to maintain.
   1. I'm essentially saying, "screw you!" to the next guy who has to maintain the system and eventually upgrade it. That poor soul has no idea what's coming.
      
      

---

THOUGHTS:

To be honest, I'm a bit sad that I've come to this conclusion. I'm basically choosing to manage Maximo the wrong way...since the right way is turning out to be impractical. Goodbye OOB best practices, hello unmaintainable code! :)

---

FOLLOW-UP QUESTION:

How does this compare with your experience? What do successful practitioners end up doing in the long run?

​
#AssetandFacilitiesManagement
#Maximo

This is always a tricky area.
The weaknesses listed for the OOB functionality are pretty much spot on - doing things properly can be time consuming and frustrating.

 

The benefits miss out a positive – the OOB functionality gets tested by IBM.

While the testing has its limits it is certainly useful it will be preventing some issues.

 

The automation script weaknesses you list are dangerously incomplete / flawed.

The biggest scripting weaknesses that aren't covered are:

• IBM Support will not look at a case where custom code, e.g. a script, has fired
• Resource leaks
• Spaghetti code – this is hinted at
• Easier to bypass change control procedures

 

IBM Support will not look at a case where custom code, e.g. a script, has fired

--

They won't support a problem in a script – This is understandable but it would get painful for this organisation if the developer moves on and the replacement doesn't have lots of experience with scripts

 

IBM won't look at an unrelated problem if a script has executed e.g. A script is triggered while saving a WO. The script simply changes one value on a custom field (i.e. nothing that the core Maximo code will interact with) and then calls the MBO Save operation – the MBO Save then fails because of a problem with the core code.

 In this case the customer has to replicate the problem without involving the script – that can be very difficult.

 

Spaghetti code

--

This is one of the biggest weaknesses of code – it gets very difficult to trace which scripts are interacting with a transaction.

 

If scripts aren't designed properly then they can become a nightmare e.g. if there are 5 scripts triggered by a WO save. One aspect that people forget is that there is no way to predict/control the order of script execution.

So the first time you save the WO the scripts could fire like this:

Script1, Script2, Script3 …

The second time it could be like this:

Script1, Script3, Script2 …

And the third time…

Script4, Script3, Script2 …

 

So you have to design your scripts so they can run completely independently and safely….

OR you merge scripts together so you control the flow…. – this is the ideal solution from Support's position / future maintenance

 Developers tend to avoid merging the scripts because it is a lot more work and it means more retesting…

 

I am working on a capability that will trace the execution flow and highlight things that could be impacted e.g. which automation scripts / domains etc – it is a very complex task particularly when you realise that a line of automation script code could implicitly trigger other scripts e.g. by saving a workorder.

 

Its all in one place – for now.

--

Having the scripts in one place is fine for now but the developer can't guarantee that the next person will be as comfortable with scripts or that the organisation won't strictly enforce a rule to move back to OOB functionality

 It is easy to see how rising script maintenance costs will lead to a management rule to use OOB functionality where possible

 

Resource leaks

--

Writing Automation scripts is relatively easy but Maximo's complexity means that it is also easy to create memory leaks that over time will degrade the performance of a JVM or kill it completely.

I spend a significant portion of my time investigating these even with my powerful toolset.

Vetasi offer an automated service to check automation scripts for bad practices / potential leaks. We also have automated tools to speed up the process of resolving performance problems.

 

Easier to bypass change control procedures

--

It is much easier to implement a "quick fix" to a script and so bypass change control procedures.

Change controls are important to help ensure that things are tested and that administrators understand what things could be causing a problem e.g. If this worked last week then what changed in the last 7 days?

Ultimately each organisation needs to make a decision about the best way forward.

Personally I prefer using the OOB features where possible.

------------------------------
Mark Robbins
Support Lead/Technical Design Authority / IBM Champion 2017 & 2018 & 2019 & 2020 & 2021
Vetasi Limited
https://www.linkedin.com/pulse/maximo-support-advice-from-non-ibm-engineer-article-mark-robbins/
------------------------------

#AssetandFacilitiesManagement
#Maximo

I wonder if I could store settings in MAXVARS?

VARNAME = DIVISION_FLOWCONTROL
VARVALUE = FLEET

The scenarios where we'd store info in MAXVARS would be very limited. But it might have it's place.

---

MAXVARS - Maximo Customisation

"When creating Maximo customisations either MaxVars variables or System Properties can be useful (with a preference to the latter) in order to avoid hard-coding values to provide reusability and flexibility. For example say you have a workflow that routes purchase orders over a particular value to the CEO for approval. Rather than hard-code the currency value in the workflow you could create a custom system property to store the threshold value amount and use a custom condition automation script to compare the PO total cost to the system property value and return a true or false accordingly. Therefore if the value threshold for CEO approval changes in future you only need modify the system property not the workflow."

#Maximo
#AssetandFacilitiesManagement

I advise using the system properties for a number of reasons.
You can use the property name to clearly group related things together e.g.
myorg.custom1.datacheck1.flagToSwitchOnCheck
myorg.custom1.datacheck1.thresholdToApply
myorg.custom1.format.successLineColouur
myorg.custom1.format.FailLineColouur

The system properties can be viewed/modified from the front-end - this makes debugging easier if you have limited access to the database tables

MAXVARS cannot be refreshed on the fly - so you have to restart the JVM to read the new values. Things may have changed but that is my memory when I looked at this.

Whichever way you do it there are several key things to remember:

1. Always consider adding in checks to see if things are null - helps avoid a NullPointerException
2. Always consider what could happen if there is a bug e.g. will it generate a NullPointerException?
3. Build install scripts (e.g. .dbc files) to insert system properties - warnings about missing system properties can quickly generate lots of log entries and delay support teams finding the real error messages

------------------------------
Mark Robbins
Support Lead/Technical Design Authority / IBM Champion 2017 & 2018 & 2019 & 2020 & 2021
Vetasi Limited
https://www.linkedin.com/pulse/maximo-support-advice-from-non-ibm-engineer-article-mark-robbins/
------------------------------

Original Message:
Sent: Thu October 07, 2021 12:50 AM
From: User1971
Subject: Logic in tables vs. hardcoded scripts

I wonder if I could store settings in MAXVARS?

VARNAME = DIVISION_FLOWCONTROL
VARVALUE = FLEET

The scenarios where we'd store info in MAXVARS would be very limited. But it might have it's place.

---

MAXVARS - Maximo Customisation

"When creating Maximo customisations either MaxVars variables or System Properties can be useful (with a preference to the latter) in order to avoid hard-coding values to provide reusability and flexibility. For example say you have a workflow that routes purchase orders over a particular value to the CEO for approval. Rather than hard-code the currency value in the workflow you could create a custom system property to store the threshold value amount and use a custom condition automation script to compare the PO total cost to the system property value and return a true or false accordingly. Therefore if the value threshold for CEO approval changes in future you only need modify the system property not the workflow."

#AssetandFacilitiesManagement
#Maximo

Bottom line - OOTB functionalities rules.
Yes, OOTB has its limitations, but overall it's no match.
0 time maintenance, full support, 100% of numerous 'piece of cake' upgrades successes.

That's the main reason why other systems collapse under the weight of coding while Maximo
just getting better and better with all configurations applied by the business requirements.

------------------------------
Jacob Massa
------------------------------

We had the same problem and spent approx 2 months or so building a Rules engine using custom tables and automation scripts.
The effort was rewarded tenfold since we now can execute an 'if this then that' logic approach to any MBO without having to change any code.
Difficult to explain in a post but the general approach was a table with the following fields
 rulename,
 rulesequence (important)
 isruleactive(to disable rule if needed)
 objectname,
 attributename
 condition (evaluate to true or false) re-used Condition Expression Manager)
 action on (if true) - optional
 action on (if false) - optional

 A generic automation script executed on validate() for the MBO to which determined which rules to execute and in what sequence.

------------------------------
Visium Workflow
------------------------------

@Visium Workflow - Your concept of a Rules Engine is very interesting. I like it.
#AssetandFacilitiesManagement
#Maximo