So something is odd with our SLA's. I Know I have had other issues with SLA but does anyone know specifically how the slaactive table gets assigned it's breach timer? It seems to be null in our slaactive record and can't pinpoint why.
Justin, in the RAD application sla.refresh.active on the panel set.expiration, the slaactive next breach field gets set under this condition
(not null(expiration.time in $L.sloresponse) and expiration.time in $L.sloresponse>$L.tod and current.status in $L.sloresponse=2) then if (nullsub(suspended in $L.sloresponse, false)=false) then (next.breach in $L.active=min(expiration.time in $L.sloresponse, nullsub(next.breach in $L.active, expiration.time in$L.sloresponse)))
to the min() of expiration time in sloresponse and the current next breach (if not null).
The expiration.time in sloresponse is set on the same panel:
(null(expiration.time in $L.sloresponse) and not (current.status in $L.sloresponse=5 or not breached in $L.sloresponse and suspended in $L.sloresponse)) then (expiration.time in $L.sloresponse=$L.expiration.date)
$L.expiration.date contains the value of:
[nullsub($L.nexttobreachstarttime, nullsub($L.laststarttime, $L.tod))] +
[$L.allowed.time - nullsub($L.nexttobreachduration, nullsub($L.laststartduration, $L.duration))]
or in simple terms, the expiration date of the sloresponse record is calculated (based on a working calendar) as
tod() or start of the next calculated breach PLUS the allowed time for responding to the issue MINUS the duration to the next known breach / duration to alert time. (If I interpreted it all right).
What I find is that the next.breach is only filled, when the schedule record for that breach is in the schedule file. Can you check if you have SLA breach schedule records?
Some have a schedule record and sometimes the change/task doesnt have an associated schedule record.
looking at the record I can't identify a specific condition why it wouldn't. Same category, person, and dates etc.
Edit: This is Service Manager 9.21.
Can you compare the SLOs between the ones that have a next breach and those who don't? Are they using the same SLO? If not, is the difference between the ones that have one and ones that don't that the one "half" has alerts defined? From reading the RAD, I was not totally able to determine the difference yet, but it has something to do with the defined duration between now and the next breach, and there are different ways of determining those (fixed interval, etc.) The trick is figuring out which ones work and which ones don't, based on the SLO(s) used. If you can, can you add a screen print of one that works and one that does not? That my help in figuring it out.
One more quick note - I am running 9.30 and see the next breach in a very, very small amount of records and the associated schedule records ran into an error on my system.
I attached some screenshots of two Tasks and a couple others in the same qbe with similar categories that housing differing dates and user filled information. The screenshots are from two environments, please excuse the color difference.
Based on the conditions of these tasks they would use a single type of SLO, the third screenshot. The condition is pretty basic, just the category of the task. Duration is the only thing that is more complex.
Duration is from the Change Category. The duration the SLA/SLO should take is on the Change Category, it is a customization. I showed it in a screenshot for the 4th screenshot.
Basically the change record is creating an SLA as they normally do but there isn't a breach time. The interval amount of time in the change is populated but isnt creating a projected breach time in the slaactive record.
We are trying to retrieve that breach time after it is populated from the slaactive table and set that as the planned.end but since it's null it doesnt populate planned end.
I tried to set the SLO interval directly but it still did not populate the breach time.
One problem was is the conditions for the SLO's were using status definitions that were not defined in the
slamodulecontrol record cm3r. The slamodulecontrol was using phases. However, some of the records still don't get an slaactive file. Perhaps there is more configuration I am missing.
sorry I did not reply sooner - when i had a minute to reply the site was read-only. There are two things we can try - if you can reproduce the issue, the easiest way is to run rtm:3 and debugdbquery:999 to see where it "avoids" creating the slaactive record. If not, you can send screen prints of the non-working and of the working ones and we can see if we can see the difference (cm3r record, sla / slo records, etc)