CA Service Management

Hello, is there any way to modify default CA trigger without modifying it in bopcfg/magic. 

Hi Giedrius,

As far as I understand, I don't think we can modify the default trigger. However, You may create a duplicate of the same and make your required changed with a delayed trigger time which will run as good a new update to existing trigger.

Duplicate is ignored with the following message:

Ignoring duplicate definition of trigger cr::attached_sla_processing

What i need is to remove some parameters that are passed to attached_sla_processing spel.

How about renaming the exiting trigger with 'z' to note as customization i.e. cr::zattached_sla_processing, which will ensure that its not a duplicate.

However, the original SLA cr::attached_sla_processing will run by all means but will be overwritten by the custom trigger cr::zattached_sla_processing.

May be this can be considered as a workaround given the product limitations.

The problem is that default trigger removes my custom SLA if affected user or affected resource is modified.

Hi!

I have tried to redefine trigger in my test env and seems everything works. Maybe because I'm still on 12.7 and something were changed in next versions. I saw trigger duplicate error many times but as I remember them caused only if trigger is defined in a same folder (bopcfg/majic or mods/majic).

Code which I used to test:

// filename: site/mods/majic/z_test.spl
cr::auto_assign(...) {
     int msg_i;
     logf(SIGNIFICANT, "Redefine trigger");
     for (msg_i=0;msg_i<argc;msg_i++) {
          logf(SIGNIFICANT, "argv[%d]: %s", msg_i, argv[msg_i]);
     }
}

Result:

I noticed followed message for attach_sla_processing but didn't for auto_assign.

SIGNIFICANT intpnoex.c 378 Function cr::attached_sla_processing defined more than once

I can't be sure did attach_sla_processing is overrided correctly because we haven't ootb SLA logic in our env but auto_assign logic overrided correctly.

Hi cdtj i need not to override trigger, but change it's definition.

POST_VALIDATE attached_sla_processing (
site_sla_attrs,
persistent_id,
status,
support_lev,
active,
category,
requestor,
affected_contact,
priority,
group) 1000
FILTER( "$NX_CLASSIC_SLA_PROCESSING" != "Yes" && (template_name == NULL || template_name == ' ' ) ) ;

to

POST_VALIDATE attached_sla_processing (
site_sla_attrs,
persistent_id,
status,
support_lev,
active,
priority) 1000
FILTER( "$NX_CLASSIC_SLA_PROCESSING" != "Yes" && (template_name == NULL || template_name == ' ' ) ) ;

I checked few scenarios and seems like there is no way to redefine them without modifying bopcfg majs.
My suggestion is to remove definition from original file and redefine them in mods, this should save env if someone upgrade/patch the system and forgets to keep changes.
Also I think that you need to create virtual attributes to pass NULL values to redefined trigger:

POST_VALIDATE attached_sla_processing (
site_sla_attrs,
persistent_id,
status,
support_lev,
active,
z_null_pcat,
z_null_cnt,
z_null_cnt,
priority,
z_null_cnt) 1000
FILTER( "$NX_CLASSIC_SLA_PROCESSING" != "Yes" && (template_name == NULL || template_name == ' ' ) ) ;

ATTRIBUTES Call_req {
z_null_pcat LOCAL SREL pcat;
z_null_cnt LOCAL SREL cnt;
}

to keep correct structure and avoid out-of-bounds error.

Regards,

cdtj

From the parts of the spell code that are readable i don't think that i need to passs dummy atributes, it seems they are working with parameter triplets so my guess is that there are no hardcoded indexes

if there is no hardcoded indexes, input arguments doesn't matter

AFAIK if you re-define (i.e. change parameters) to an OOB trigger, you need to do it in the default location and not in the mods folder.

Overriding a trigger (i.e. just change the code, without the signature) works by just re-defining the code body in the mods folder.

Hi Cristi / Giedrius,

Though this approach might work but this is not suggested by CA and not part of Best Practices. Subsequent code changes or patch updates will not have this customization and might be overwritten by CA code during the patch maintenance.