A Scripting Solution to Set Child Work Order Values From the Parent

A Scripting Solution to Set Child Work Order Values From the Parent

Body

Introduction

Crossover domains can be a convenient way to copy values from a parent work order to a new child when adding a child work order. In most cases this works without a problem. However, if the values being copied from parent to child include ASSETNUM, LOCATION, and/or GLACCOUNT, the crossover domain may not work as expected. This is the case if these values do not match, for example, if the ASSETNUM does not reside at the location specified by LOCATION, or if the GLACCOUNT does not match the ASSETNUM/LOCATION combination.

This post describes a technical solution for overcoming the problems that arise from using a crossover domain to copy ASSETNUM, LOCATION and/or GLACCOUNT values from a parent to a child work order when the 'New Row' is clicked on the work order's 'Children of Work Order nnnn' table window. The solution employs Maximo Automation Scripting.

Disclaimer

Before we get into the details please note that this solution should not be deployed directly into a production environment before testing and making sure your individual business case is met. You may need to modify the script to meet your own specific needs. The references provided at the end of this post will be helpful in the event that you need to modify the script or if you would like to further pursue automation scripting to customize your environment.

Overview

ASSETNUM, LOCATION, and/or GLACCOUNT mismatches are permitted when work orders are entered via a non-UI mechanism, or in the UI when the user responds 'No' to any of the following dialogs:

These mismatches are not a problem if this is what is desired on the parent record.

Problem

The problem arises when a user adds a child work order to a parent that does not have matching ASSETNUM, LOCATION, and/or GLACCOUNT values and a customized crossover domain attempts to cross these values over to the new child. One of the above dialogs will be raised when 'New Row' is clicked. When the user responds to the Yes/No/Cancel dialog, a second record is added due to the way that Yes/No/Cancel dialogs work, resulting in two incomplete child records. As a result, the error "BMXAA4195E - The Duration field requires a value" occurs when attempting to save the new child. This error is misleading because in the UI, the Duration field is clearly populated:

The error is coming from the second child that was erroneously added as a result of the response to the Yes/No/Cancel dialog. This second record does not appear in the UI.

Solution Using an Automation Script

This problem can be avoided by using the TPAE automation scripting functionality instead of the crossover domain. The reason for this is that in the script one can avoid the raising of the Yes/No/Cancel dialog when ASSETNUM, LOCATION, and/or GLACCOUNT is set.

The following steps explain how to copy parent work order values (ASSETNUM, LOCATION, and GLACCOUNT) to the child when the child is being added:

Go to System Configuration > Platform Configuration > Automation Scripts.

1. Create > Script with Attribute Launch Point.

Click 'Next'.

2. Specify the script name and scripting language.

Click 'Next'.

3. Create the script:

.

#*************Script Text******************

from psdi.mbo import MboConstants

wo = mbo.getOwner()

if onadd and wo is not None and not mbo.isNull("parent"):
    mbo.setValue("location",wo.getString("location"),MboConstants.NOVALIDATION)
    mbo.setValue("assetnum",wo.getString("assetnum"),MboConstants.NOVALIDATION)
    mbo.setValue("glaccount", wo.getString("glaccount"),MboConstants.NOVALIDATION)

#********************************************

The key to the automation script working is to specify MboConstants.NOVALIDATION when setting the values. This is not possible with crossover domain functionality.

Scripting with Maximo

Today I am going to introduce you to the world of scripting with Maximo. Maximo scripting let you customize a slew of Maximo components. These components include these kinds of customizations:

• Customizing MBOs through save-point and initialization-point validations and actions and MBO field validations and actions.
• Customizing workflow, escalation, conditional UI, menus, and push-button actions via scripted actions and conditions.

It is important to understand that the Automation scripts are a server-side artifact, as opposed to a client-side one. So all your scripts are executed on the server side as opposed to say in the browser.

The cool part about scripting is that you can use it without writing a line of Java code, or without restarting the server or rebuilding the EAR file. We understand that sometimes you need to customize using MBO code or the Maximo SDK and the scripting framework does not remove that power. You still have access to all of Maximo APIs as well the MBO instances in context. You can use a MBO to access any related MBO or set and can call all public APIs, such as those to invoke a Web service or a send an email from a script.

As for languages, you can code the script in the language of your choice. Jython and JavaScript are enabled by default. However, you should be able to use any JSR-223 compliant scripting engine or language, provided that you add the java-engine.jar file to the Maximo classpath (either ear or system). So if you are a JRuby or Groovy geek, try the version of those languages that supports JSR-223 and start grooving in Maximo. Just so you know, Maximo Support supports questions about scripts written only in JavaScript and Jython.