Maximo Scripting: Date Dizziness - Part II

Body

Introduction

In my previous article working with dates I showed how elapsed time could be measured. In this second article covering date manipulation with Maximo scripting, I present a Java-based approach to calculating dates. I have chosen a scenario in which an escalation executes a scripted action. I take this opportunity to walk readers through the Tpae scripting framework’s action launch point capability.

Service Request date calculation

In Maximo as well as other products built with the Tivoli process automation engine (Tpae), Service requests form a central unit of work in service desk implementations. Many service requests are managed on the basis of commitments declared in a Service Level Agreement (SLA), however other requests are managed based on request priority, affected asset and so forth without an associated SLA. For the latter type of service request, target dates must be computed and stored into the service request record based on business rules even though a governing SLA may not exist.

We define a simple Tpae escalation to automate the date calculation. The combination of escalation and the scripted action reduce the amount of work a service desk manager or agent needs to perform to complete the service request processing.

The escalation uses SQL criteria to identify a subset of records that qualify for the date calculation. The automation script launched on each of these records through the associated action and action launch point performs the calculation and updates the service request record. Alongside, a work log entry is created for the updated service request record indicating automated work was performed on the request.

Implementation approach - action launch point, script and escalation

The following are the high-level steps to implement the solution:

1. Using Automation Scripts application, define the action launch point and author the script Under the covers, this activity will automatically generate an action.
2. Using Escalation application, define the escalation and associate with the action.

SRDDACTIONJAVA – action launch point and script

Using the Automation Script action launch point wizard, I define my action launch point and associated script code. There are three entities in play here, as shown in Figure 1.

 

Figure 1 Configurations enabling a scripted action in Tpae 7.5

In Step 1 of the Action launch point wizard, fields are presented that enable you to not only name the launch point, but also name the action and provide a description for the action. Figure 2 shows Step 1 of the Action Launch Point wizard.

 Figure 2 Step 1 of the Action Launch Point wizard

I have specified the action launch point name and the action name to be the same - ‘SRDDACTIONJAVA’. The ‘SR’ business object is associated with the launch point as well as the action.

In Step 2 of the wizard I define two output variables ‘targetcontactdate’ and ‘targetstartdate’ which are bound to SR MBO attributes ‘TARGETCONTACTDATE’ and ‘TARGETSTART’ respectively. We define one input variable ‘reportdate’ which is bound to SR MBO attribute ‘REPORTDATE’. The goal of the scripting scenario is to compute targetcontactdate and targetstartdate values from the reportdate value.

In Step 3 of the wizard I author the following lines of code:

from java.util import Calendar

from java.util import Date

 

print 'SRDDACTIONJAVA - script execution started'

 

cal=Calendar.getInstance()

cal.setTime(reportdate)

cal.add(Calendar.DATE, +1)

targetcontactdate =  cal.getTime()

cal.add(Calendar.DATE,+1)

targetstartdate=cal.getTime()

  

worklogset = mbo.getMboSet ('WORKLOG')

worklogentry = worklogset.add()

worklogentry.setValue('clientviewable',1)

worklogentry.setValue('logtype','WORK')

worklogentry.setValue('description','System initiated processing')

 

print 'SRDDACTIONJAVA - script execution complete'

Notice that my script does not have any ‘if’ conditions. I have chosen to delegate the ‘if’ condition to the escalation in the form of escalation criteria. If a SR record meets the criteria, the escalation picks up the record and initiates the action. The job of the script code is to calculate the dates and set them into the output variables which will then be set into the targeted service request record supplied by the escalation. This is a choice I have made to keep my script logic simple.

The script imports the Java Calendar and Date classes. This allows me to utilize a variety of Calendar- and Date-based Java APIs within the body of the script.I obtain an instance of a calendar object. The getInstance() method returns an object that is based on the current time in the default time-zone and default locale of the current JVM where Maximo is running. However, I set the Calendar object’s time to the SR record’s reportdate value in the very next line of code using the Calendar class’ setTime() method. Notice that the parameter to the setTime() method is the input variable reportdate. The scripting framework recognizes that the input variable is bound to a Maximo attribute of DATETIME or DATE type and automatically creates a Java Date object to represent the reportdate from the SR record. This allows me to directly pass the input variable reportdate to setTime().

Now that the Calendar object is initialized with reportdate, I can add time to it. I choose to add 1 day to it and set the ‘targetcontactdate’ to be 1 day from the reported date and time. I add another 1 day to the calendar object and set the ‘targetstartdate’ to be 2 days from the reported date and time. The amount of time added may vary depending upon the type of Service Request we are dealing with.

Following the date calculations, the script creates a work log entry for the given service request indicating that the system initiated processing on the record. This work log entry is created using traditional business object method calls. Since the current record is represented by a Service Request business object, I obtain a handle to the related work log MBO set. Once I have the desired MBO set, I can add records using the MBO add() method.

Now that the action, action launch point and script have been saved, lets take a quick look at the action definition. Figure 3 shows the action definition.

Figure 3 Scripted action definition

This action was automatically generated when the launch point and script were created. The action definition includes the fields and values listed in Table 1.

Table 1 Action definition details

Details regarding the action definition:

• The name of the action is whatever specified by the user.
• The object the action is associated with is the same as the object the corresponding action launch point is associated with.
• The type is ‘Custom Class’ indicating a Java class will be executed whenever this action is invoked.
• The value specifies the complete name of the Java class. This class is supplied out-of-the-box with the Tpae scripting framework.
• The Parameter / Attribute is a comma-separated list of parameters that is processed by the java action to determine the corresponding launch point and script. The number of comma-separated values is always three. The values are interpreted as: <script name>, <launch point name>, <action name>. The implementation of the framework-supplied custom Java class uses these three values to identify, prepare and execute the script.
• The Accessible from is set to ALL indicating this scripted action is available to Escalations, Workflows and any other entity that can consume the action (including user interface button defninitions).

NOTE: Altering the generated values for the Object, Type, Value and Parameter / Attribute fields may break the action definition and its link with the action launch point.

SRDDESC escalation

When defining the escalation, I place the following SQL criteria at the escalation header level:

assetnum is not null and reportedpriority = 1 and status = 'NEW' and targetcontactdate is null and targetstart is null

NOTE: These criteria may be insufficient in your product environments. Adjust the criteria accordingly.

I change the schedule so that the escalation will run every minute. I add an escalation point (left empty). Then add an action. I associate the SRDACTION with my escalation and save all changes. Figure 4 shows the final escalation definition.

Figure 4 SRDDESC escalation definition

Testing the configurations

I activate the escalation and then create a test Service Request record with a reported priority of 1, associated with an asset and save it with ‘NEW’ status. When the escalation runs, the associated action is executed and the script computes new dates and inserts a work log. Figure 5 shows the result of the date computation on the target SR record in the form of input and output.

Figure 5 Result of escalation execution on a SR record

Figure 6 shows the result of the work log record creation.

Figure 6 Work log created by script against the target SR record

Using logs to review script execution

If you choose to set the ‘autoscript’ logger to ‘DEBUG’ and the SRDDACTIONJAVA script log level also to ‘DEBUG’, then the Maximo product log shows the following log statements:

[DEBUG] [MXServer] [CID-CRON-3917] ScriptAction called for scriptName SRDDACTIONJAVA has been called for launch point SRDDACTIONJAVA

[DEBUG] [MXServer] [CID-MXSCRIPT-3918] AbstractScriptDriver context value = null for mbo attribute targetcontactdate

[DEBUG] [MXServer] [CID-MXSCRIPT-3918] AbstractScriptDriver context value = null for mbo attribute targetstartdate

[DEBUG] [MXServer] [CID-MXSCRIPT-3918] AbstractScriptDriver context value = 2011-12-23 22:14:28.0 for mbo attribute reportdate

[DEBUG] [MXServer] [CID-MXSCRIPT-3918] about to execute the cached compiled script for SRDDACTIONJAVA for launch point SRDDACTIONJAVA

[DEBUG] [MXServer] [CID-MXSCRIPT-3918] created script context for cached compiled script SRDDACTIONJAVA for launch point SRDDACTIONJAVA

[DEBUG] [MXServer] [CID-MXSCRIPT-3918] execution completed for cached compiled script SRDDACTIONJAVA for launch point SRDDACTIONJAVA

[DEBUG] [MXServer] [CID-MXSCRIPT-3918] SRDDACTIONJAVA - script execution started

SRDDACTIONJAVA - script execution complete

[INFO] [MXServer] [CID-MXSCRIPT-3918] The total time taken to execute the SRDDACTIONJAVA script for the SRDDACTIONJAVA  launch point is 87 ms.

[DEBUG] [MXServer] [] ScriptAction call ended for scriptName SRDDACTIONJAVA and launch point SRDDACTIONJAVA

The log associated with the SRDDACTIONJAVA action, action launch point and script are bracketed by statements indicating the action launch point was initiated and completed. The script framework writes the values for the input and output variables being passed to the script – notice that the reportdate variable carries the date-time value retrieved from the target Maximo record. The log also shows the output from the print statements I placed within the script – this is useful when a script needs to be debugged. Finally, the script framework also records the total time taken to execute script in milliseconds.

Summary

This article illustrates how an action launch point and script can be exploited to achieve a higher degree of automation in Maximo than previously possible. I used a few Java APIs to implement the script logic. However, I could potentially have utilized Jython or JavaScript functions to achieve the same results. In subsequent articles, I will develop the Jython and JavaScript equivalents of the same script.

Useful Links

Java Calendar class and methods

Maximo 7.5 Scripting Cookbook

Files accompanying this article

Deploy the package into your product environment using Migration Manager application. Admin Mode is not required. The Action launch point should be automatically activated. However, the escalation is left inactive. To test the script, you must be activate the escalation.