Blog
Maximo escalations demystified (1/3)
Escalations are one of the most common (and easiest) way we use to automate actions in Maximo. They are well known by Maximo specialists but there are some tips to better use them and some undocumented feature you may like to use. The simplest definition of an escalation is the following. An escalation is a mechanism to evaluate records and take actions when a record reaches a defined condition
August 25, 2019
Migrate Maximo configurations with MxLoader
Have you ever struggled migrating configurations from Development to Test environment and then to Production? If the answer is yes, you are not alone. I think this is the one of the most common issues when managing multiple environments in medium-large Maximo projects. Keeping several Maximo environments in synch while ensuring a fast release cycle required in today’s projects is challenging and typically involves two flows. The first flow of configuration changes is the classical release flow. You have to release configurations from Development to Production through all the intermediate environments and entails the build of some sort of ‘configuration package’ that is deployed on each environment. However, in the real world, all those environment will loose sync after some time so we need to realign back through the chain using a database cloning procedure (backup and restore). This is a well known practice to rebuild a development environment ensuring all
August 22, 2019
The hidden features of Work Logs
Work Logs are a very useful feature in Maximo and Control Desk products to allow users to keep notes of the progress of work. A very nice feature of work logs is that Maximo displays all work logs for the current record an related ones. Lets make an example. If there is a work log on a work order originated from a Service Request, Maximo will display both SR logs and Work Order logs in the Work Order Tracking application. In the example below we are in the Work Order Tracking application displaying work logs on work order 1019. The first work log has been added to the work order but the second one is attached to the originating service request 1214.
August 9, 2019
Tracking elapsed time in work order status history
A common requirement from my clients is to track how much time work orders have been in each status. IBM Maximo already has the Work Order History dialog that displays the date and time of each status change. Unfortunately it may be not straightforward for a user to calculate the time spent in each step of the process or to develop a KPI to set processing time goals in your work management flow.
August 4, 2019
Disable default attachment folder
One of the fist lessons I have learned through all these years as Maximo consultant is that every time there is a default value for a field the user will not change it. A very common example of this is the Folder field of the Add Attachment dialog. The value of this field will always default to the first folder available in alphabetical order. If we want to force the user to select the most appropriate folder for the attachment, then we have to remove that default value. The attribute we want to change is DOCLINKS.DOCTYPE. Unfortunately, setting a default value for this field in Database Configuration will not work (believe me I have tried) so we have use a more powerful feature to control the behavior of this attribute. The solution I have found is to use a very simple automation script. Here it is.
August 3, 2019
Where was an asset located at a certain time in the past?
Maximo has a well known feature to display the history of where an asset was located. It is accessible from View Asset Move History from the Asset application. In the following example the asset DS01-A-002 was created in location DS01-S-SA-01 and then moved to other two locations. The data displayed in this dialog is stored in the ASSETTRANS database table. By querying this table we can answer questions like this:
April 26, 2019
Logging in automation scripts
I have to admit, I’m a big fan of automation scripts. Recent updates released with Maximo 7.6.0.9 have almost covered all the possible customization needs including library scripts, REST APIs, MIF processing, before/after save event. All the new features are well documented in this somewhat secret document. However whatever nice feature will be added in the next feature pack, we will never have a debugger like we have with Java and Eclipse. This could be a serious problem when you have to develop and maintain a complex set of scripts in your environment. The best way to mitigate such problem is to correctly use Maximo logging APIs.
April 3, 2019
Avoiding FetchResultStopLimit errors in Java or scripts
Today I had to face an issue deleting a large set of records from a Maximo table using an automation script. My script was something like this. mboSet = MXServer.getMXServer().getMboSet("MYTABLE", mbo.getUserInfo())mboSet.deleteAll()mboSet.save() Unfortunately the table I had to purge (MYTABLE in the example) was having more than 5000 rows so when I launched the script I got the following error.
March 18, 2019
Automation Script to reset user's Start Centers
In a previous post I have explained how to force the reload of a the start center for a specific group of users. I have now developed a useful automation script that can be invoked from the Security Group application to automatically perform this task with just one click. Register the script as a Script with an Action Launch Point and link it to a sigoption and to a menuaction, toolbar icon or application button as described in this post or this one.
November 28, 2018
MTTx Terminology
When it comes to asset reliability measurement all the different MTTx acronyms start to appear but sometimes is not clear to everybody the exact meanings of these terms. In this post I want to give a very simple explanation of these reliability KPIs. MTTD - Mean Time To Detect - How long it takes to discover a problem. MTTK - Mean Time to Know - How long it takes to understand the problem. MTTR - Mean Time To Repair - How long it takes to fix the problem. MTTF - Mean Time To Failure - Amount of time the system is available and operating. Also known as “uptime”. MTBF - Mean Time Between Failures - Amount of time that elapses between one failure and the next. MTBF is the sum of MTTF and MTTR, the total time required for a device to fail and that failure to be repaired. MTBF = MTTR + MTTF
September 28, 2018