CA Service Management

We have some very complex SLAs which require us to add a lot of Attached Service Type Events (atev's) to some tickets, only a subset of which will apply for each individual ticket. Because we cannot reduce the number at ticket-logging time we are looking at a nightly clean-up of events that would never apply. We would write this in Spel.

Using bop_sinfo to look at the methods on the atev object, I get the following (I've removed a few):

        cancel_by_group( void );
        cancel_me( void );
        delayed_cancel_me( ... );
        delete_wc( object|nil, string, long );
        nuke_by_id( object|nil, string, string|nil, long );

Can anyone tell me what the parameters are for the delete_wc and nuke_by_id methods? Note that the delete_wc on this object is different from the more generic api version that you would use like " send_wait(0, top_object(), "call_attr", "api", "delete_wc", "grpmem", ... "

Also, do I have to cancel an atev before I can delete it? And, if so, what are the advantages of the delayed_cancel_me over just cancel_me?

Using r12.6.

Thanks in anticipation,

Alan

Hi,

Check this thread and download zAttach_sched_end_reminder.spl.zip.  It has an example of how to use cancel_me.  In this example, I get all the events that have the group_name of zSchedCheck and cancel them.  Each script that creates events I give a unique group_name (atev attribute) and query all events that have this tag name to cancel them.  This works for events that are configured to fire off notifications when a specific time is passed.

Thanks for that, Grant.

The main thing I am after is the documentation on the delete_wc and/or nuke_by_id methods, have you or anyone else got any details on those?

Here’s a document on delete_wc. Im not sure it would work on the atev object though, the example is using grpmem.

delete_wc 

I think there is no need to manually delete those events, better to just cancel them using atev cancel_me method and keep canceled events until they collected by Archive and Purge procedure.

my 2 cents.

Hi,

I wouldn't normally consider such an approach as this but we are having to attach very large numbers of atev (even though only a minority of them will apply to each ticket ) to the extent that they are impeding our performance.

I can assure you that a lot of people with good understanding of this tool have tried to think of ways to avoid attaching all the events but the business situation is extremely complex so we are looking for "plan B" options.

So any help anyone can give on those delete/nuke methods (full details in my original posting) would be greatly appreciated.

Hello Alan,

I found this in an old spel and wand guide I have - It may help:

nuke_by_id( string attach_to_id, string | nil group_name)

Delete the atevt's for the attach_to_id. If you pass in a group name it will not delete all, only those that are '
LIKE' the group_name. This method gets a group leader for it's own use and does the checkin before you
return.

Arguments:
string attach_to_id The persistant id to delete from
string | nil group_name The group name to nuke for.

Error Reply:
Misc errors
?? - string error text

Success Reply:
(void) Just replies with no data

Regards,

Gordon

As another workaround you can try to set "Do not keep event history" (not sure how it called in Eng) flag on event template page.

btw:

// this one DELETE atev by search criteria
send_wait(0, top_object(), "call_attr", "atev", "delete_wc",
     gl,                      // group leader, should be checked in to complete action
     "obj_id = 'chg:496740'", // where cluase constraint
     0                        // unknown but affect fetch criteria, 0 working fine
);

// this one CANCEL atev by search criteria
send_wait(0, top_object(), "call_attr", "atev", "nuke_by_id",
     gl,           // group leader, should be checked in to complete action
     "chg:496739", // atev [obj_id]
     "SLA",        // atev [group_name]
     0             // unknown but affect fetch criteria, 0 working fine
);

Thank you very much to Gordon Preston and cdtj, that's exactly what I was after.