Search for	Example	Results
A single word	`cat`	Topics that contain the word "cat". You will also find its grammatical variations, such as "cats".
A phrase. You can specify that the search results contain a specific phrase.	`"cat food"` (quotation marks)	Topics that contain the literal phrase "cat food" and all its grammatical variations. Without the quotation marks, the query is equivalent to specifying an OR operator, which finds topics with one of the individual words instead of the phrase.

Search for	Operator	Example
Two or more words in the same topic	`AND` `and` `+` (plus symbol) `&` (ampersand)	`cat AND dog` `"cat food"+milk` `"cat food"&"dog food"`
Either word in a topic	`OR` `or` `\|` (pipe)	`cat OR dog` `cat \| dog`
Topics that do not contain a specific word or phrase	`NOT` `not` `!` (exclamation point)	`NOT cat` `! dog`
Topics that contain one string and do not contain another	`^` (caret)	`cat ^ mouse`
A combination of search types	`( )` parentheses	`cat + (dog \| mouse)` `cat \| dog + (! mouse)`

Operations Manager i10.62

Develop > Event Processing Interface > EPI overview

EPI overview

This section provides an overview of the Event Processing Interface (EPI), explaining the different steps in the event pipeline, and appropriate entry points for running scripts for modifying and enriching events.

Learn more

Run EPI scripts

The EPI enables you to run user-defined Groovy scripts during event processing. With these scripts, you can modify and enhance events with external data. For example, you could enrich events with additional data from an external SQL database, or an Excel list. For more information about developing and deploying Groovy scripts, see Groovy scripts.

The graphic below provides an overview of the event processing, showing the event pipeline, and how the EPI script execution can be integrated into this process.

Scripts are stored in the database. Any JAR files or libraries that are referenced or used by the scripts are also loaded into the database.

For each pipeline step, you can set up one or more scripts. There is no limit on the number of scripts that can be executed. However, be aware that the time it takes to process events in the pipeline increases with the number of scripts that are executed.

Note You should design and execute scripts in the context of overall event processing. In other words, be aware of the interaction of the scripts with other event processing settings in the Settings Manager, for example for duplicate events suppression and closing related events.

Entry points for running EPI scripts

The event pipeline represents the various steps of event processing. There are four points within the event pipeline at which EPI scripts can be executed:

Before CI/ETI resolution. Scripts can be executed directly before the event enters the event pipeline, so before the resolution of CIs and ETIs takes place.

For example, you may want to execute a script at this point that sets further hints that affect the resolution of CIs and ETIs. An entry point further along the event pipeline would be too late to influence the resolution of CIs and ETIs.
After CI/ETI resolution. Scripts can be executed directly after CI/ETI resolution, but before further processing, such as duplicate events suppression and closing related events automatically.

For example, you may want to execute a script at this entry point in the event pipeline if you want to influence how duplicate events are handled. It could be that you have duplicate events suppression enabled in general, but you are interested in changing the duplicate events suppression setting for a particular type of event, while leaving it unchanged for all other event types. So you could execute a script at this entry point that disables duplicate events suppression for the specified event type. Any entry point further along the event pipeline would be too late to influence duplicate events suppression behavior.
Before the event is stored in the database. Scripts can be executed after all event processing has taken place, but before the event is stored in the database.

For example, at this entry point to the event pipeline, you could execute a script that makes changes to some text, or inserts a link to a knowledge base, and so on, before the event gets stored in the database.
After the event is stored in the database. Scripts can be executed after the event has been stored in the database. In this case, the scripts are all executed in read-only mode, since as soon as an event has been stored on the database, it can no longer be modified.

For example, you may want to execute a script at this entry point in the event pipeline to forward events of a particular type, that have already been stored in the database, to another application. Or you could execute a script that writes specified events stored in the database to an audit log.

Script execution

The steps involved in script execution are as follows:

The EPI server reads the script and calls the init() function.
The EPI server calls the process() function, with the list of events specified as parameter. The script stays in memory, and the process() function is called when matching events arrive.
The EPI server calls the destroy() function if the script is unloaded, for example, if the script is disabled by the user, or at system shutdown.

The destroy() function is also called if the script is modified in the Event Processing Customizations manager. In this case the destroy() function is called on the old, unmodified script, followed by a call to the init() function on the new, modified script.

The call to the process() function of a script conforms to the ACID (Atomicity, Consistency, Isolation, Durability) principle that ensures that database transactions are processed reliably.

Atomicity

If a script cannot be successfully executed (does not return without errors, and no exception is thrown), any changes made so far are rolled back. Subsequent events will get the event list as it was before the script in error was executed.
Consistency

Values that violate the consistency of an event can be over-ridden by the system. For example, setting an user ID and a group ID where the user ID is not a member of the group ID is such a violation, and can be over-ridden.
Isolation

Scripts with read/write access to events are not executed in parallel, but sequentially.
Durability

Changes made to events by executing scripts are stored in the database.

Send Help Center feedback