Maximo

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.

Thanks!

Shivangi Goyal

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.

Thanks!

Shivangi Goyal

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:

worktype='EM'


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. 

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.

Thanks!

Shivangi Goyal