A mature Maximo system tends to have layers of configuration, customizations, integrations and moving parts. Often a single record can have multiple processes interacting with it. Recently I worked in an environment where work orders were created by an integration; once the work order hit the new work queues schedulers started updating the record. While updates were being performed, outbound integrations were triggered which led to another inbound integration updating the records. There were also escalations performing updates on some work orders. All to say users and automated tasks were getting “BMXAA4200E - Record has been updated by another user” errors regularly causing some user frustration.
When it comes to ‘record updated by another user’ errors there are as many ways to troubleshoot them as there are reasons they occur. The articles linked below describe two approaches that can be very useful. These approaches give visibility into the error at the time it occurs and these approaches should be in your toolbelt.
https://www.sharptree.io/blog/2023/2023-07-25-updated-by-another-user/
https://www.linkedin.com/pulse/troubleshooting-mxrowupdateexception-error-ibm-maximo-cheremisenov
What most approaches lack is the ability to track the whole lifecycle of a record. Traditionally to achieve a record’s lifecycle, audit tables are used to record every change. Configuring audit tables serves a purpose but it can have some significant overhead and they can be tricky to back out once they are no longer needed. In my example scenario I was looking at specific records in the first few days after they were created. I was not concerned in keeping audit data long term and I wanted something that was easily enabled and disabled.
Leveraging an automation script, I was able to meet all my goals. I was able to add it to the system without an outage and disable it easily once I was complete. Since implementing this I have returned back to the script and enabled it to help troubleshoot on multiple occasions. With a launch point on WORKORDER and WOACTIVITY save I was able to log basic information every time a save was performed.
# Setup a logger
from psdi.util.logging import MXLoggerFactory
projetechLogger=MXLoggerFactory.getLogger("maximo")
# Pull any data that I want to log
mboParent = mbo.getOwner()
strParentName = ""
if mboParent and mboParent.getName():
strParentName = mboParent.getName()
# Write a log entry
projetechLogger.info("Auto Script " + scriptName + " detected a WO save. Site ID:"+mbo.getString("SITEID")+" WONUM:"+mbo.getString("WONUM")+" Change By:"+mbo.getString("CHANGEBY")+" This Mbo:"+mbo.getName()+" Parent MBO:"+strParentName+" Interactive:" + str(interactive))
With the additional logging I was able to capture the data I needed. Using the data logged in conjunction with correlation IDs in the log message I was able to assemble a full picture of a work order creation life cycle quickly. Utilizing the log data, I was able to identify some process improvements that eliminated much of the user frustration. We were also able to identify an unnecessary legacy process.
How can you utilize this? This approach isn’t limited to just work orders. It could be applied to any scenario where an automation script launch point can be fired, and additional logging is required. When utilizing this approach or any approach that adds additional logging it is important to consider the performance impact. Every log entry and automation script launch point that is utilized has a resource and performance cost.
Keep your environment snappy, enable logging while troubleshooting and disable it as soon as possible.
