Maximo Scripting: Date Dizziness - Part II
agrippa 06000202D9 Comment (1) Visits (16514)
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
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:
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:
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.
When defining the escalation, I place the following SQL criteria at the escalation header level:
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:
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.
Files accompanying this articleDate Dizziness – Part II.pdf
Automation script in a ZIP file – srddactionjava.py
Migration Manager package containing escalation, action and script
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.