Actions for advanced enrichment and time-based enrichment

Actions are like conditions that are run sequentially on each event that matches the event selection criteria. 

Some actions help you define conditions to get a subset of matching events and other actions help you define conditions to further process or enrich matching events. For example, the Lookup action can be used to retrieve existing events that match the specific criteria. The If-Then-Else actions can be used to process events in the specified way. The Enrich action can be used to enrich event information. Based on your use case, you can combine various actions to build the advanced enrichment and time-based enrichment policy workflows.

Actions can be classified as: 

  • Root action, which is the highest action in the workflow structure. This action has no parent. This action can have one or more child actions, but cannot have a sibling action or be repeated in the same workflow. You cannot add more than one root action in the same workflow. Lookup, Unless, Trigger-If, and Timeout are root actions.
  • Non-root action, which can occur anywhere in the workflow structure and can be repeated multiple times in the same workflow. All actions other than the root actions are non-root actions.   

The following actions are supported for building a policy workflow. Some actions are common and some are specific to advanced enrichment and time-based enrichment policies.

Common actions

The following actions are common to advanced enrichment and time-based enrichment policies.

Variable

Use variables to point to static text, event data (values of event slots), results of mathematical functions, and values of previously-defined variables. 

Variables can be reused for building conditions for processing events, such as the If-Then-ElseEnrich actions. You can specify the variable name as the value of these actions.

Variables are treated in the same way as slots. Therefore, while defining conditions for processing events, you can add variables in the same way as you add slots. For example, while defining conditions for actions such as If, Lookup, or Unless you can select previously-defined variables from the list of slots.

You can also specify variables in text strings by prefixing them with a dollar sign ($). For example, you can specify a variable as input for particular functions or you can add it as a text string value for the Enrich action and similarly, you can add it as a text string value for the Variable action. 

At the time of processing events, the variable name is replaced with the value of the variable. Variables cannot be used globally and the value of a variable persists only in the policy workflow of a single event. This means a variable cannot be referred while processing any other event or be used in any other policy. 

Assigning variables

While creating a workflow, you can assign existing variables that are defined until then in the current workflow, as long as they are in the same branch of the workflow.

In the policy workflow, under Variable Settings, you can set one of the following values:

  • Text string: Assign a text string containing alphanumeric characters.
  • Variable: Assign an existing variable’s value to this variable. 

  • Function: Assign the function value as the variable value. To understand the supported functions, see Functions for advanced enrichment.
  • Event Slot: Assign the slot value as the variable value.

If-Then-Else 

The If-Then-Else construct represents a conditional execution. If the condition specified in the If action is evaluated as true, the Then action is run. If the condition specified in the If action is evaluated as false, the Else action is run. The Else action is optional. 

In the policy workflow, under the If Settings, you can define a condition by specifying slots and existing variables. The process of constructing the If condition is very similar to constructing the event selection criteria for event policies.

The If-Then-Else construct allows you to create branches in the policy workflow. You can have multiple branches in the workflow. You can even define a branch under a branch. This feature can help you separate conditions and add more complex workflows to cater to your use case. 

Enrich

Use this action to enrich event data with meaningful user-specified data, data from other events, or results of functions and existing variables.

You can enrich event information by assigning a new value to the selected event slot. Events come with a set of out-of-the-box slots. However, if you want to change a piece of event information that is not already captured by the out-of-the-box slots, it is important that you have existing custom slots. While defining the enrichment conditions, you can select the custom slot to enrich.

 In the policy workflow, under Enrich Settings, you can select a slot to enrich, and set one of the following values:

  • Text string: Assign a text string containing alphanumeric characters as the slot value.
  • Variable: Assign an existing variable’s value as the slot value.

    Assigning variables

    While creating a workflow, you can assign existing variables that are defined until then in the current workflow, as long as they are in the same branch of the workflow.

  • Function: Assign the function value as the slot value. To understand the supported functions, see Functions for advanced enrichment.
  • Event Slot: Assign another slot's value as the slot value.

Actions specific to advanced enrichment

The following actions are specific to the advanced enrichment policy.

Function

These functions are void functions that do not return a value. Therefore, these functions are different from the functions that can be added as the value for Variable and Enrich actions.

For more information, see Functions for advanced enrichment.

Lookup

Use this action to retrieve information from the event repository of existing events. The resulting events can be used for further processing. This action is a root action and therefore, must always be specified at the top of the workflow before other actions. 

In the policy workflow, under Lookup Settings, you can:

Specify whether you want to lookup one of the following:

  • Duplicate events that are associated to custom classes. To do this, select a custom class. 
    By default, duplicate events associated to out-of-the-box classes are dropped. Therefore, you cannot lookup such events even if you select an out-of-the-box class under the Lookup events containing Class list.
  • Events matching a custom criteria associated to all the classes irrespective of whether it is out-of-the-box or custom. 

For custom criteria, you must specify a condition. This is similar to constructing the event selection criteria.

The event class value defaults to the class specified under the event selection criteria. If no class is specified, the base EVENT class is considered for the event selection criteria, and therefore, the value defaults to the base class value.

Under the settings, if you:

  • Do not change the value: The same class is used to lookup existing events and incoming events. 
  • Do change the value: The new class value is used to lookup existing (or old) events and the class specified in the event selection criteria is used to lookup incoming (or new) events. 
    While building the condition, you can specify slots prefixed with $OLD and $NEW. Slots prefixed with ‘$OLD’ refer to slots of existing events and slots prefixed with ‘$NEW’ refer to slots of incoming events. This feature allows you to add conditions to compare old and new slot values.

Additionally, you can define whether you want to consider all events or only the latest events matching the Lookup condition. You can also define the duration for the lookup in seconds. If the duration is not specified, the duration is assumed to be active as long as the policy is active. The lookup will continue, until the policy is disabled or deleted.

After configuring the Lookup conditions, you can configure actions to update new events (or incoming events) and old events (existing events). This action allows you to create a logical branch in the policy workflow. Under each branch, you can add subsequent actions for enrichment or further processing. You can even configure actions to update only new or only old events. 

Unless

This action applies the subsequent action(s) only if the specified query condition does not find a match. The Unless action is similar to Lookup, but the logic is reversed.

This is a root action and therefore, must always be specified at the top of the workflow before other actions. 

Similar to the Lookup action, in the policy workflow, under Unless Settings, you can:

  • Specify an event class to query events belonging to that class 
  • Specify a condition to query events matching the condition. This is similar to constructing the event selection criteria.

The event class value defaults to the class specified under the event selection criteria. If no class is specified, the base EVENT class is considered for the event selection criteria, and therefore, the value defaults to the base class value.

Under the settings, if you:

  • Do not change the value: The same class is used to query existing events and incoming events. 
  • Do change the value: The new class value is used to query existing (or old) events and the class specified in the event selection criteria is used to query incoming (or new) events. 
    While building the Where condition, you can specify slots prefixed with $OLD and $NEW. Slots prefixed with ‘$OLD’ refer to slots of existing events and slots prefixed with ‘$NEW’ refer to slots of incoming events. This feature allows you to add conditions to compare old and new slot values.

If the condition specified is not satisfied, subsequent action(s) are run. 

Trigger-If

This action triggers the policy workflow if a specified slot of an existing event is modified. This is a root action and therefore, must always be specified at the top of the workflow before other actions. Unless an event matches the conditions specified in this action, the advanced enrichment process cannot begin. 

In the policy workflow, under Trigger-If settings, you need to specify:

  • The slot that needs to be monitored for changes. Only Enumeration (or Enum) type slots are supported.  
  • Conditions to monitor the value:
    • If the new slot value matches the given condition.
    • If the previous slot value matches the given condition.

This feature allows you to monitor precisely when the slot value changes from or to a particular value. The action is triggered each time the monitored slot's value changes.

Actions specific to time-based enrichment

The following action is specific to the time-based enrichment policy.

Timeout

Use this action to set a timer after which actions are run on incoming events. This is a root action and therefore, must always be specified at the top of the workflow before other actions.

In the policy workflow, under Timeout settings, you need to specify:

  • The duration 
  • Unit for the duration

The specified duration is calculated from the time the event arrived (_arrival_time slot).

You can add subsequent actions for enrichment or further processing. After the specified duration lapses, the subsequent actions are run. 

Where to go from here

Now that you understand actions, see how to build a policy workflow. You can also see workflow examples that show you how to combine various actions to achieve different use cases.

Was this page helpful? Yes No Submitting... Thank you

Comments