Highlighted
Acclaimed Contributor.
Acclaimed Contributor.
294 views

Running SLAs in the foreground vs running them in the background

Hi,

Ever since we started using the SLA module we configured our SLAs to run in the foreground.  We have SLAs on initial Response (assign to an individual), Time to fix, based on priority, etc., so if a ticket is assigned or someone changes the priority it triggers the SLA module/process to add or modify the sla breach or status, etc. in the ticket.  The problem is that the SLA process does not respect locked records therefore one of the most common issues when updating tickets is the message "This record has been modified since you loaded it" (or something similar), because the sla process has modified the ticket while we are still working on it.

Although we don't know if there any significant benefits, we are considering changing our SLA configuration so that they run in the background.  We are wondering if anyone else out there has done this and would offer an opinion.  Does anyone run their SLAs in the background and are there things that need to be considered before switching? Any significant risks? Switching them to run in the background seems to add a schedule record which is processed a couple of minutes or so later, instead of immediately, so this at least gives our users a brief window to finish their update and get out of the ticket without getting this error.  Alternatively does anyone know how to get the SLA module to recognize locks, so that our users can finish their work in the ticket before the SLA process comes along and changes it.

Any thoughts, suggestions, or information would be appreciated.

Audrey

0 Likes
3 Replies
Highlighted
Super Contributor.. Super Contributor..
Super Contributor..

Re: Running SLAs in the foreground vs running them in the background

We recently started using the SLA module too and are running it in the background and today the first 'TOP-Urgent' complaint got in. As you describe, the sla process does not honour a user lock on an incident.

Steps to reproduce:

1) User updates the status of the incident -> a schedule record to update the sla is created with an expiry of tod()+ 2 minutes

2) the user keeps the incident open and continues modifing it for more than 2-3 minutes. In the meantime the schedule records executes and updates the incident even when there is a lock on it.

3) After this period the user decides to save thez incident. --> error "This record has been modified since last read"

4) All the modifications done by the user are lost.

I searched HP support for more info but not much luck in finding something usefull that would solve the issue.

Any idea if it is possible to make the sla process to honour the locks like it does for the scheduled sla alerts (alert proces)?

PS, we are on SM 9 .33

0 Likes
Highlighted
Outstanding Contributor.. Outstanding Contributor..
Outstanding Contributor..

Re: Running SLAs in the foreground vs running them in the background

I have not testet this but I am going on the assumption that when SLA in foreground do not respect locks SLA in background will not either. Afterall it is more or less the same code running regardless of mode.

0 Likes
Highlighted
Super Contributor.. Super Contributor..
Super Contributor..

Re: Running SLAs in the foreground vs running them in the background

Tommy, correct but in the meantime I found out the rootcause (caused by a custom trigger on sloresponse updating the IM) of my problem and fixed it. The strange thing is that HP Support insisted they could "reproduce" the problem 😉
0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.