Customizing the Workflow Rule that Processes SLA Request Parameters

When users of the Building Operations Console make changes to a work request's request parameters, the work request's escalation date is based on the original Date Requested. This is the way the workflow rule works out-of-the-box. This means that, when request parameters are changed, work could be automatically escalated if the new SLA has shorter response and completion times than the original SLA.

As an alternative approach, you can customize the workflow rule, so that the system uses the date the request parameters were edited to calculate the escalation date. This would give the craftsperson the proper amount of time to fix the problem and complete the request before the escalation occurs.

This can be accomplished in either of two ways:

  • update the Date / Time Requested whenever a craftsperson edits work request parameters, and then base the Escalation times off of that new date / time
  • introduce new database fields to store the date / time that the request was edited, and base the escalation times based on those fields instead of the Date / Time Requested.

To customize the workflow rule:

Edit the file WorkRequestHandler.java in this location:

archibus\schema\ab-products\bldgops\common\src\main\com\archibus\eventhandler\ondemandwork\

The WFR method is

WorkRequestHandler.editRequestParameters().

In this method, it will call the 'updateWorkRequestFromSLA(context, wrId)' method (line 7727) to re-calculate the escalation times. You can add code to update the Date / Time Requested fields before it calls the method updateWorkRequestFromSLA(context, wrId).

Or, you can add new fields to store the date / time of the update and write a similar method like updateWorkRequestFromSLA(context, wrId) to calculate the escalation times based on the new fields.