New Ranks & Badges For The Community!
Notice something different? The ranks and associated badges have gone "Star Fleet". See what they all mean HERE
Highlighted
Absent Member.
Absent Member.
3252 views

SLA and Breach Time in slaactive

Jump to solution

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.

 

file=slaactive

form=slaactive

field=next.breach

 

 

0 Likes
1 Solution

Accepted Solutions
Highlighted
Absent Member.
Absent Member.

My alert.process RAD was broken. Had HP send me a new unload of it.

View solution in original post

0 Likes
9 Replies
Highlighted
Absent Member.
Absent Member.

Justin, in the RAD application sla.refresh.active on the panel set.expiration, the slaactive next breach field gets set under this condition

 

if

(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:

if

(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?

Highlighted
Absent Member.
Absent Member.

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.

0 Likes
Highlighted
Absent Member.
Absent Member.

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.

Highlighted
Absent Member.
Absent Member.

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.

Highlighted
Absent Member.
Absent Member.

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.

0 Likes
Highlighted
Absent Member.
Absent Member.

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.

0 Likes
Highlighted
Absent Member.
Absent Member.

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.

0 Likes
Highlighted
Absent Member.
Absent Member.

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)

0 Likes
Highlighted
Absent Member.
Absent Member.

My alert.process RAD was broken. Had HP send me a new unload of it.

View solution in original post

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.