CA Service Management

 View Only

SPEL: Dummy atevs cancellation 

Nov 25, 2015 09:44 AM

In our production environment we had about 300 000 active Attached Events but as I found 170 thousands of them was dummy.

 

What I name dummy attached event?

In my vision dummy attached event is event that never triggers,

this could happen on system lag, animator_nxd error, invalid customization, data import or any other abnormal behavior.

 

 

What is condition to determine event as dummy?

I selected 3 filters:

     - atev haven't linked object (obj_id);

     - object is not exists in the system; (regular thing for Workflow Tasks because they could be easily deleted)

     - object is inactive; (as we know all events should stop when object becomes inactive);

 

 

What this macro do?

This macro is looking for active attached events,

I selected 2 statuses for this purpose:

     2 - running;

     12 - paused;

If event matches conditions it will be canceled using "cancel_me" method.

 

 

Before we start

This is fully automated macro but I can't guarantee that everything will pass fine, so I highly recommend to:

     - make a backup of affected atevs, this could be done via this command:

pdm_extract -f "select * from Attached_Events where status_flag IN (2, 12)" > atev.txt

     - run it on testing env first;

     - know SPEL basics;

 

 

Execution

This macro is presented as frg file and can be executed via bop_cmd,

more information could be found inside of file.

 

 

Comments or suggestions are welcome!

Statistics
0 Favorited
17 Views
1 Files
0 Shares
3 Downloads
Attachment(s)
zip file
atev_cncl.frg.zip   1 KB   1 version
Uploaded - May 29, 2019

Tags and Keywords

Comments

Mar 25, 2016 04:44 AM

Make sense for the constraints.

Always several roads for same destination

/J

Mar 25, 2016 03:58 AM

Maybe because we are killing atevs for already "dead" objects that shouldn't have any active events, we can use constraint like "status_flag > 1" to fetch all events that can hide in other statuses without any negative effect on the environment?

 

About repeating events:

we also have loop notifications and they are realised in this way:

- we are attaching event with fixed delay;

- on event's trigger it calculates amount of previously fired events, perfroms action depending on old events amount and attaching same event with new delay;

 

Writing this words I understood that I've selected strange way because I can use num_fire and repeated events without this hard customization,

thanks for idea jmayer!

Mar 25, 2016 03:48 AM

Thanks cdtj  for the quick reply

So you think there is no other status  between 3 and 12?

Interesting too that you don't use repeat events (we use it for sla notifications and increase SLA violation weigth).

I may look next time if those orphans we see time to time are such type of events

 

 

/J

Mar 24, 2016 10:26 PM

Nice questions!

when I was writing this my thoughts was:

- ok, status 0 and 1 already done and waiting for the judgement day depending on arcpur settings;

- we don't have repeating events (status 3) and never use them;

- I never seen status 13 (have selected all status_flag by SQL DISTINCT attribute);

- there also should be Unknown status for atev's but it's another story;

- I ran SQL select to check canceled atev persids in ANIMA t_lock or t_persid, there wasn't any data, so I think that I'm clean

 

upd: I think that status_flag 13 is for paused loop events, that's the reason why I haven't faced them

 

Regards,

cdtj

Mar 24, 2016 01:12 PM

yes J_W wondering too on the other status code.

cdtj, by curiousity

It's appears from above that 13 is another "delayed" event

Did you by hazard eventualy checked if any of those in 13 status was remaining  before or after you did run your process or either better do you know the differecen between 12 and 13 status?

 

Also did you have any orphean remain in your animator after running your frg?

I see time to time with cancel_me that the anima is not always cleared and my reason for asking.

Thanks in advance

/J

Mar 24, 2016 11:36 AM

Thanks for the great procedure!

 

This made me wonder where you determined the status_flags labels since you are only acting on '2' and '12' and these aren't documented in the Wiki.

 

I found these referenced in the aevt_get_attevt_status_text(event_status) function in list_atev.htmpl:

....

case '0':

ret_text=msgtext("Cancelled");

break;

case '1':

ret_text=msgtext("Complete");

break;

case '2':

ret_text=msgtext("Pending");

break;

case '3':

ret_text=msgtext("Repeating");

break;

case '12':

case '13':

ret_text=msgtext("Delayed");

....

 

Did you have any other references to them on the server side as well?

These might be useful to extend your procedure or for other uses.

 

J.W.

Related Entries and Links

No Related Resource entered.