Inventory of cloud native analytics ObjectServer triggers

Learn about the triggers that get loaded into an ObjectServer that is part of a cloud native analytics deployment.

Default triggers

The default triggers term refers to the set of triggers that are provided by IBM and exist in the ObjectServer when it is first initialized or created, or any triggers published and released by IBM through the extensions directory.

Default triggers must never be modified, unless explicitly allowed by official documentation. For example, the agg_deduplication trigger can be altered to change the way the severity field is updated on deduplication.

The reason for this guideline is that if IBM releases updates to default triggers (in an interim fix or fix pack), existing custom functionality might be lost when the default triggers are overwritten with the new version, for example, by using the CREATE OR REPLACE notation. Even then, certain changes might still need to be reapplied. For this reason, any updates to any default code must be avoided where possible.

The default triggers term includes; any triggers that exist in the ObjectServer on initialization, the set of triggers provided in the standard multitier architecture, and all triggers provided under the extensions directory. Unless stated otherwise in the documentation, do not modify these triggers.

If custom functionality is required to augment the default functionality, for example, additional fields requiring update on deduplication, create a new separate reinsert trigger that is assigned to a custom trigger group and the field updates that are included therein. This step allows a clear delineation between default IBM code and custom code. Which means that updates to either party's code do not overwrite the other code.

IBM Technical Support fully support the default triggers. However, if an existing default trigger is disabled and a replacement custom trigger introduced, this scenario goes beyond the scope of supportability and deployment engineers do so at their own risk.

Although changing default functionality is allowable, if needed by the business requirements, it must be done only if absolutely necessary and extreme care should be taken. If any trigger logic issues arise because of changing default functionality, IBM can help a best effort capacity, however the debugging process is the responsibility of the local engineer.

Listing the default triggers

The following pods load triggers into an ObjectServer at startup. For more information, see Reference inventory of CNEA ObjectServer triggers required.

<release-name>-ea-noi-layer-eanoiactionservice
<release-name>-ea-noi-layer-eanoigateway

To find the SQL script that loads triggers from the <release-name>-ea-noi-layer-eanoiactionservice, run the following command.

oc rsh deploy/<release-name>-ea-noi-layer-eanoiactionservice

Then view the /app/ea-noiomnibus-config/objectserver/cea_aggregation_triggers.sql file.

To find the SQL script that loads triggers from the <release-name>-ea-noi-layer-eanoigateway, run the following command.

oc rsh deploy/<release-name>-ea-noi-layer-eanoigateway

For a hybrid or full cloud deployment, a quick list of triggers that are related to cloud native analytics can be obtained by running the following SQL.

select TriggerName from catalog.triggers where TriggerName like 'cea'

Default cloud native analytics triggers fall into groups that begin with cea, as in the following group examples.

cea_triggers
cea_seasonal_anomaly_triggers
cea_process_type
cea_triggers_gw

On-premises deployment: For an on-premises deployment, use the nco_confpack utility to list all the triggers in an on-premises system. This utility is installed only on an on-premises system. The following steps are for a UNIX shell.

Build a default AGG_P on-premises ObjectServer. For more information, see Installing the primary aggregation ObjectServer in the IBM® Tivoli® Netcool®/OMNIbus documentation.
```
$NCHOME/omnibus/bin/nco_dbinit -server AGG_P -customconfigfile $NCHOME/omnibus/extensions/multitier/objectserver/aggregation.sql
```

Get a list of triggers in the default on-premises AGG_P server.

$NCHOME/omnibus/bin/nco_confpack -list -file onprem.list -user <user> password <passwd> -server <servername>

cat onprem.list | grep Auto | grep -vE 'Class|Role' > onprem_trigs.list

Get a list of triggers from the out-of-box cloud native analytics server that is running on a hybrid or full cloud cluster.

$NCHOME/bin/nco_confpack -list -file cnea.list -user <user> password <passwd> -server <servername>

cat cnea.list | grep Auto | grep -vE 'Class|Role' > cnea_trigs.list

Run the diff command on the two lists.
```
diff onprem_trigs.list cnea_trigs.list
```
The result lists all the triggers that are added or removed for a cloud native analytics system.

Trigger groups

cea_triggers: Triggers in this group handle the correlation updates that are needed when events are grouped. The cloud native analytics pods update the CEACorrelationKey and CEACorrelationDetails fields to inform the ObjectServer of grouping changes.
cea_seasonal_anomaly_triggers: Triggers in this group handle seasonal anomaly changes.
cea_process_type: Triggers in this group update the CEAProcessType field to inform the cloud native analytics pods about which action to take.
cea_triggers_gw: Triggers in this group are responsible for sending events to the EA NOI Gateway.