Action launch point
Action launch point
The Maximo Actions framework in Maximo has a built in library of Actions which can be invoked from Workflows, Escalations, UI Menus, UI Buttons and many other components. More often than not those built in library of Actions are not enough and implementers have to develop their own custom Actions in JAVA only. Scripting addresses this concern where an Action can be scripted with a scripting language of your choice using Jython and JavaScript. You can use a scripted Action to do some calculated meters for Assets. The following screenshot shows how to launch the Action Launch Point wizard.
The requirement is to be able to calculate an Asset meter value based on some other meters associated with that Asset. For example, you want to calculate the value of the PRESSURE meter, based on the IN-PRESSUR and O-PRESSUR meter such that the last reading of the PRESSURE meter is the summation of the IN and O-PRESSUR meters readings. Assume that you choose to do it offline as opposed to in real time, for which you would have to use Object Launch points to trap meter modification events. The simplest way to do offline actions repeatedly in Maximo is to use Escalations, which are nothing but cron jobs that execute a predefined Action in the context of an MBO. Instead of writing the Action java code you will use a script as shown in the following steps:
- Define a relationship called assetmeterip [asset meter input pressure] using the DB-Config application, which relates an Asset to the Asset meter named IN-PRESSUR. Use the following where clause:
assetnum=:assetnum and siteid=:siteid and metername='IN-PRESSUR'
Similarly, define the other two relationships:
| Realtion name | Relation where |
|---|---|
| assetmeterop | assetnum=:assetnum and siteid=:siteid and metername=‘O-PRESSUR’ |
| assetmeterp | assetnum=:assetnum and siteid=:siteid and metername=‘PRESSURE’ |
- Use the Action Launch Point wizard to define the Action Launch Point.
Though this wizard will create the Action behind the scene, it is the responsibility of the implementer to attach that Action to the escalation, workflow or the UI button/menu. By default, the launch point name is used as the name of the Action, but you can modify the value to suit your naming convention. However, it is better to avoid renaming it because of name confusion and conflicts later on. In the first step of the wizard you saw that the object name is optional, which is in-line with the Maximo Action framework where an Action may or may not be associated with a Maximo object. In this case however, you want to specify the object as Asset as the Action is specific to the Asset MBO. Since you are defining a new script you must choose the New Script option.
The next page is the bindings page where you have to define the variables that you will use for the script and the variable bindings. You require the last reading value of the IN-PRESSUR and O-PRESSUR meters and must set the calculated value to the new reading attribute of the PRESSURE meter. However, you do not want to set the value if the calculated value is the same as the last reading value of the PRESSURE meter because that would generate meter reading history even though the reading never got modified. To check this, you would need the last reading value of the PRESSURE meter. So the following variable bindings will look like:
| Variable name | Variable type | Binding |
|---|---|---|
| iplr | IN | assetmeterip.lastreading |
| olr | IN | assetmeterop.lastreading |
| plr | IN | assetmeterp.lastreading |
| pnr | OUT | assetmeterp.newreading |
The iplr [IN-PRESSUR meters last reading], olr [O-PRESSUR meters last reading] and plr [PRESSURE meters last reading] are all of type IN as you Require those values to calculate the pnr [PRESSURE meters last reading]. The pnr is of type OUT as you are going to set it back to the PRESSURE meter MBO.
- Use the following script code:
y=float(iplr)+float(olr)if y!=float(plr):pnr=str(y)
The if check in the second line takes care of not updating the pnr value if the calculated value is the same as the plr [PRESSURE
meters last reading]. This calculation was implemented as an example. In real implementations it can be any complicated
mathematical calculation as per your business requirement, only limited by the mathematical support provided by the scripting language of your choice.
- You must now associate this Action to an Escalation. Create an escalation that will only apply to those Assets which have all those three meters. Use the escalation condition to implement that sifting functionality. The following SQL condition is what you should use:
exists (select assetnum from assetmeter where metername='IN-PRESSUR' andassetnum=asset.assetnum and siteid=asset.siteid) and exists (select assetnum from assetmeterwhere metername='O-PRESSUR' and assetnum=asset.assetnum and siteid=asset.siteid) andexists (select assetnum from assetmeter where metername='PRESSURE' andassetnum=asset.assetnum and siteid=asset.siteid)
- Select the Action for this escalation. The name of the Action is the same as the launch point name unless you had modified it in the step 1 of the wizard. After you activate the escalation, the job is complete. The escalation executes the scripted Action for all those Assets with the three meters and the modified Asset meter readings are saved and committed by the escalation framework.
If you had chosen to not attach the Action to a Maximo object, step 2 of the wizard where you specified the variables and bindings, will not let you bind a variable to an MBO attribute. You can however use the literal, system property and maxvar variable binding types. A use case for that might arise when you write a generic Action that for example, invokes a service, like a Web service, which is not specific to an MBO or you intend to do the script code based on direct usage of the MBO APIs and therefore, will not need the MBO attribute bindings.