Application Configuration Best Practices

This article details application configuration best practices.

Simplifying existing applications

Reposition or remove fields

If you have small changes to out-of-the-box applications, you cant make the changes directly within the application.

 A best practice is not to remove entire sections or tabs, but rather to hide them with a Signature Option.

When new versions of the out-of-the-box application are released and this application is upgraded, preserving these old sections and tabs allows for the upgrade process to add these new fields.  You can then examine these applications after upgrade to determine if you want to expose any of the new fields in your UI. 

If you hide sections with a Signature Option - it will have a performance impact.  Therefore, if you require major differences,  you may want to  consider cloning the application and modifying the cloned application.  You can also use this approach to hide sections of an application for certain security groups and show sections of the application to others.

Clone an existing application and edit the clone

You may want to clone an existing application if you want a user interface that is very different from the out-of-the-box application.  You might also decide that different users should see very different views of the application.

Note: There is an enhanced maintenance cost to maintain this separate application.

Any additional changes that future versions of your products make to the out-of-the-box applications must be manually merged into your cloned applications if you want these additional features.  In addition, you will need to manage the security groups and metadata of this new application separately from the original application. 

For instance, if new dialogs and new menu options are added to an application -  you will need to manually add all of this to your cloned application if you want your users access to this new functionality.  

Conditionally modify fields based on the state of the record

Conditional UI is a powerful tool that can change the behavior of your user interfaces based on the state of the current record. You can highlight key data for your users based on a condition. 

For instance, you might choose to change the color of the priority field in the list tab if a record has a priority value of 1.   You may also want to hide additional fields from your end users by default and only show them based on the values of other fields.  For instance, you might only prompt a user for a back-out plan for a change if it is a high risk change request.

Conditional UI is not a replacement for business logic.  Using Conditional UI to make a field required at various aspects of your process is probably a poor decision, since this requirement is enforced only at the user interface level.

 Automation scripting, Java programming, or the workflow engine should be used to enforce business logic in your objects. 

Because the conditional user interface logic is evaluated every time the user interface is rendered, it can be expensive from a performance standpoint. The conditional user interface expressions are also executed each time the value of a field is set by an end user.  This can slow down the time it takes to traverse the page.  For example, if you write a SQL conditional expression that takes a half second to execute, then it will take 10 extra seconds for an end user to fill in a page of 20 fields.

You should carefully consider the condition expressions you have written to make sure they execute against the MBO data available in memory if possible and do not require additional database invocations to related records to determine the result of the condition.

Enhancing Existing Applications

Sometimes out-of-the-box applications do not meet your business needs, and you need to add information to them.

Add existing fields to an application

You may want to show data to your users that is not currently displayed in the application.  To verify the field exists, access Database Configuration application within Maximo.  Locate the object, and confirm that the data you want to display is fy available as an attribute of this object. 

If this is the case, adding this attribute to the application user interface is a simple drag and drop operation from Maximo's Application Designer.  

If the data that you wish to show is available on a field on a related object and the parent and child objects are related in a one-to-one relationship, you can follow a similar approach add the related field to the user interface setting an attributename with this syntax:

RELATIONSHIPNAME.ATTRIBUTENAME.

Best Practices:  It is not recommended to show related fields in the list tab of an application because of performance impacts.  The additional database query can cause significant performance degradation.

You can modify the advanced search dialog for your application to allow searching on this related information using the same related field syntax.  When searching on these related fields, you can search on one-to-many relationships. For instance, you can find any work order with a child task that’s assigned to you.

Add existing related information to an application

For instance you might add a table or dialog to the Person application to show the list of work orders this person currently owns.  This information already exists in the database and is accessible through a relationship.  

Add new fields to an application

Many customers find that new types of data must be collected for their business processes. These unique fields will first add the new fields to the underlying MBO using the Database Configuration application.

• Add a new primitive field (for instance adding a new text attribute, or numerical attribute to the Ticket object). 

• Add a new field that relates to a different object (for instance a new field on the change work order that points to a person).  

Relate two existing objects in a new relationship

You might want to build a mapping table that relates existing objects in a new way.  For instance you might add a list of persons to a change work order. You can use the Database Configuration application to build a new mapping MBO that captures this one-to-many relationship. 

The new MBO will have one set of fields that points to the primary keys of the parent object and one set of fields that point to the primary keys of the child object.  You will then add a new relationship between the parent MBO and the mapping MBO using the Database Configuration application. You’ll then add this relationship to a new table in the application using Application Designer. 

In this table you will put a lookup to allow the end users to select the child object that they want to relate to the parent object (see information on configuring a lookup above).  You might also choose to write a dialog and Bean code to allow them your end users to select multiple “child” objects to relate to the parent object at one time.

Create an entirely new application to capture business information

This is the most expensive option to develop and maintain. Make sure that another existing MBO doesn’t already represent the concept you’re trying to map inside Maximo.  First you must create the new underlying MBO representation in the Database Configuration application.   

You have to consider what kinds of business logic and validation logic this MBO should apply through Automation Scripting or Java code. Make sure to follow best practices when writing the MBO code. Then you must go to the Application Designer and create a new application and point it to your new MBO.