View Only
  • 1.  Performance Optimization for Workorder WOSTATUS Domain Conditions

    Posted Fri April 12, 2024 08:34 AM

    Hi Team,

    We are working on some business requirements where WOSTATUS domain conditions are heavily configured with multiple conditions causing the delay in load of data upon launch of Status Change dialog in Maximo Work Order Tracking Screen. 

    We are looking for best performance optimized solution to achieve this functionality. Till now, received as automation script as substitute for domain conditions.

    Require expertise on converting MAXDOMVALCOND to AUTOMATION CONDITION SCRIPT.

    Note: We are open for more suggestion for optimized solutions.


    Shivangi Goyal

    Shivangi Goyal

  • 2.  RE: Performance Optimization for Workorder WOSTATUS Domain Conditions

    IBM Champion
    Posted Mon April 15, 2024 10:38 AM

    I agree that a "Retrieve List" script is the best option. It is easier to develop/test/maintain and if you put some logs in the script allows to pinpoint the performance problem.

    Here is a good post to start:

    Bruno Portaluri
    Maximo Technical Solution Architect

  • 3.  RE: Performance Optimization for Workorder WOSTATUS Domain Conditions

    Posted Mon April 15, 2024 09:36 PM

    I personally prefer validation over hiding values so you can throw a helpful error message to the user. For example, if you don't want them to go to COMP until they have entered labor, explain that to the user with an error message. Hiding the COMP status results in a generic error message that isn't helpful to explain to the user WHY they cannot complete the work order. This is particularly important for new employees that will not know all the rules around records. But you wouldn't believe the number of times I explained to a customer admin why they couldn't change a WO to a particular status was because of a condition that they personally had added to Maximo. 

    The retrieve list automation script route is good if you want to hide the values but potentially dangerous on out of the box fields if you're not careful because it will replace out of the box logic on the field. Assuming you're doing this on the non-persistent WOCHANGESTATUS, you should be mostly OK because we have validation in place to handle the bulk status change scenario (where someone could try and complete a WO that is already COMP, go backwards, etc.). 

    If you want to stick with conditions but optimize performance of conditions, it's important to understand how conditions are evaluated. I'll often see conditions written like this:


    What happens when Maximo evaluates conditions is Maximo first tries to evaluate the condition in memory.

    We wouldn't be able to do that with worktype='EM' so we would fall back to a query against dummy_table. This is intended to support use cases like using getdate() or sysdate where we need to query the database but don't need to read the record from the database. Maximo would write a query like select * from dummy_table where worktype='EM';

    That query would fail because worktype doesn't exist on the dummy_table object. Then we go against the main object which would look like:
    select * from workorder where worktype='EM';

    The problem here is twofold. First, from a performance perspective we're reading a large percentage of the WORKORDER table. Second, from an accuracy perspective, we have no clue whether our WO matches the criteria. Just that a record exists in the database.

    You want to use bind variables (IE :worktype='EM') to get the value from the Mbo in memory. This helps avoid the query against the main object which often results in the performance issue. In a scenario like this, you also want to make sure in the condition you pick the object name of WORKORDER & WOACTIVITY because WOCHANGESTATUS will not have the attributes you need and fail to evaluate the condition. By setting the object name you can avoid the Maximo framework from attempting to evaluate it against the non-persistent object. 

    If you need to look at a child table (IE going from workorder to the asset), make sure your query is optimized. Sometimes I'll see conditions like:

    assetnum in (select assetnum from asset where assettype='IT')

    The problem is this can result in a large number of asset records to be read to build a list of assetnum. And it doesn't handle issues like the asset existing in multiple sites. You instead want a condition like:

    exists(select 1 from asset where assetnum=:assetnum and siteid=:siteid and assettype='IT')

    This will read at most 1 record and will use the primary key column on the ASSET (which has a unique index, clustered on DB2 & SQL Server which is the most efficient index to use) to execute the search. 

    Steven Shull

  • 4.  RE: Performance Optimization for Workorder WOSTATUS Domain Conditions

    Posted Tue April 16, 2024 11:50 AM

    If you go to Conditional Expression Manager and use the Condition Expression Builder, the help on the Object Name field says, "The object is not stored as part of the condition." That the object name is not stored can be proven by clicking OK and immediately re-opening the dialog.

    One must distinguish between "design time" and "run time". Condition Expression Builder is a "design time" tool. You, as the developer, may know that your condition will be evaluated against WORKORDER at run-time, and so you may fill in the Object Name field so you can use the Test Expression... feature. But at run time, the then-current-object will be used to supply values to bind variables in your condition or to query if you have column references (bind variables where you forgot the leading colon).

    A big key to success in Maximo configuration and scripting is the art of knowing what the then-current-object object will be.

    Jason Uppenborn
    Sr. Technical Maximo Consultant