OnTicketResolved rules not running.

Products

• ServiceDesk

Issue/Introduction

The customer noticed that if they try to put a ticket "on hold" or "close" it, they don't get an email notification that it happened.

Cause

The On Hold & Resolved paths of the project create a message file stored in the WorkflowResponseQueue on the file system. The WorkFlow server needs to process this message file for the incident to proceed. 

We discovered an old WorkFlow message in the "Message" table that appeared 270+ days after its associated incident was closed. This old message was blocking the WorkFlow server from processing messages. The customer needed to remove the old message from the Message table and the files in the WorkflowResponseQueue started processing.

Environment

ServiceDesk 8.1 RU5

Resolution

The following steps are provided as a reference of what to do in one of the possible scenarios that could apply to this situation. Deleting records out of the database without understanding the associations on that data and tables could cause leaving orphaned references.

 

1. Move out the files from "%\Program Files\Symantec\Workflow\Data\MQWorkflowFileStorage\localworkflowfilestorage-workflowresponsequeue\"
2. Run the following query to find if there is a ticket that was previously closed but for some reason was recently posted again:
   
   with alltaskmessages as (
   select m.messageid, messageposteddate, m.queuename, attributekey, attributenumvalue, attributecharvalue
   from messages m
   inner join messageproperties mp on m.messageid = mp.messageid
   where m.queuename = 'local.workflowsqlexchange-incident_mgmt.tasks'
   ),
   openprocessmessages as (
   select mp.messageid, rp.reportprocessid, rp.processstarted, rp.result
   from reportprocess rp
   inner join messageproperties mp on rp.sessionid = mp.attributecharvalue
   )
   select
   opm.reportprocessid,
   opm.result as 'ticketstatus',
   atm.messageid,
   opm.processstarted,
   atm.messageposteddate,
   datediff (dd, opm.processstarted, atm.messageposteddate) as 'posteddaysafterstart',
   dateadd (ms, ((atm.attributenumvalue - 599266080000000000) -
   FLOOR((atm.AttributeNumValue - 599266080000000000) / 864000000000) * 864000000000) / 10000,
           DATEADD(d, (atm.AttributeNumValue - 599266080000000000) / 864000000000, '01/01/1900')) +
           GETDATE() - GETUTCDATE() as 'TriggerDate'
   from alltaskmessages atm
   inner join openprocessmessages opm on atm.messageid = opm.messageid
   where atm.attributekey = 'Trigger_Date'
   order by triggerdate
   --order by reportprocessid
   
   
   
3. Use the "MessageID" value from the ticket that appears with "TicketStatus" of "Closed" but the "ProcessStarted" is old but the "MessagePostedDate" is recent. Check the information on "Messages" and "MessageProperties" tables to know more about this ticket:
   
   
   
   
   
4. After checking what was for that Ticket under the "Messages" and "MessageProperties", delete the entry so that old reference could be removed:
   
   
   
   
5. Restart the Symantec Workflow Server Service and IIS service (run IISReset command from the command prompt).
6. Place back the most recent files that you moved out of "%\Program Files\Symantec\Workflow\Data\MQWorkflowFileStorage\localworkflowfilestorage-workflowresponsequeue\"

Additional Information

161432 "Incident Management Timeouts and Escalations Fails to Process Messages Despite Being Configured Correctly"