Cadet 2nd Class Cadet 2nd Class
Cadet 2nd Class
226 views

SLA for automatic created OMU-incidents

Hi All,

when adding a default SLA in the SLA Edit control record, the default behavior should be that this SLA should apply when opening any incident that doesn't match any of the SLA's selection criteria processes.

However this is normally occur in case manually opening incidents, But in case of the OMU (Operation Manager for UNIX) automatically created incidents tickets, no SLA being fired at all even if it meets all the SLA/SLO conditions set on the level of SLO.

The question is does the SLA is tight to A RAD application that fires only in case of manual created incidents!!! and if this is the case what should we do to attach SLA to the automatically created incidents.


Thanks in advance for the prompt replies.


Regards,
Soliman

0 Likes
6 Replies
Absent Member.
Absent Member.

Obviously its not system didnot distinguish whether you have created the incident manually or by some events.

If SLA is getting attached to the tickets you are opening then it should also get attached when you are logging your events in SM fro OMU.

So now the question is why its not getting attached ?

One of the reason i can think from here is may be the condition of your SLO's are not getting met on the aouto generated tickets.You first need to check whether the conditon of your SLO's were met on the tickets where your SLA is not getting attached.

Regards,
Cadet 2nd Class Cadet 2nd Class
Cadet 2nd Class


Just would like to highlight that we are using SM 9.20.024 and OMU version 9.11.
And for the SLO condition , already we are setting it to true.

Any clues...


Regards,
Soliman
0 Likes
Absent Member.
Absent Member.

Ok..still tickets created manually are having SLO's attached to them?

As you said you have true against slo's condition.So have you tried restarting the services of SM?

I have created a ticket by aadding record to eventin and found SLO's are getting attached to it.As i told you earlier its not on the system part you might be missing some configurational things at your end.

Do one thing put some condition in SLO's and then trigger a event from OMU end and check on the system whether that condition is met or not.If it met then SLO's surely going to attach to he ticket(to verify i would advice to use RAD debugger).Irespective of SM and OMU version i'm not sure if it works on higher versions but i guess it sould work.
Cadet 2nd Class Cadet 2nd Class
Cadet 2nd Class

however i'm setting the condition to be true, which is supposed that it accepts any thing and the SLO should be fired despite of any incident specific values.

Anyway I tried to set the condition to be as follow:

opened.by in $L.file="SCITO-GDCOMU02"

As per the OMU tickets opened.by values, but no SLA being fired too.

Any clues...



Regards,
Ahmed Soliman
0 Likes
Absent Member.
Absent Member.

Thats right it should have been fired on true it was just to verify certain things.Is this is happening first time or recently you have started facing this issue?

You might be knowing that SLA's are bind with the user on the basis of department and company have your OMU user is configured in such way?

Have you restarted the services?

0 Likes
Cadet 2nd Class Cadet 2nd Class
Cadet 2nd Class

Already did many restarts to the service manager service, but not helps.

For the department and company SLA, I added a calculations in the master format record of the probsummary table, that set the company and department with a static values so that either of the company or the department SLA be fired, but the weired thing is neither the company nor department nor default SLA be attached.

But again if i added a manual incident the department SLA attached normally.
and if it is not exist the company SLA triggered and attached, and when there is no company or department SLA the default attached. all works normally in case of manual created incidents.


Any explanations for this behavior...


Regards,
Ahmed Soliman

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.