# dejaVu

A Workflow Engine function that allows you to determine if a workflow has processed a piece of data. You can optionally specify a time frame to limit the amount of time that the data was last seen. Deja vu is a French phrase that means "already seen."

This function returns true if the item has been seen previously within the time frame. It returns false if the item has not been processed or the lookup mechanism failed.

This function uses the Enrichment API to persist 'seen' values and allow 'seen' values to be seeded into the system. See Enrichment API.

This function is available for alert workflows.

This function is available for event, alert, and Situation workflows.

The workflow sweep up filter applies to this function.

## Arguments

Workflow Engine function dejaVu takes the following arguments:

Name

Required

Type

Description

key

Yes

String

Source field to use as the key. Can be complex.

value

Yes

String

Source field containing the value to look up. Can be compound.

age

No

Number

Time to reset the 'last seen' value in seconds. Default is forever.

enrich

No

String

True or false. Specifies if the last seen data should be added to the object (under custom_info.dejaVu.<key>).

## Example

The following example demonstrates typical use of Workflow Engine function dejaVu.

An application emits event messages containing an error code. You want to address these event so you add the alert to a Situation. You only want to add the first instance of the error message to a Situation and mark subsequent instances as 'error seen'. You also want to decrease the alert severity of subsequent instances.

Given the following event data:

"description" : "Application : APP001, Error code : 0001, a memory allocation error has occurred."

In an event workflow you want to extract the “signature” of the error, the application identifier and the error code. Write the signature to the workflow context so you can use it later in the dejavu action. For example, create a searchAndReplace action with the following settings:

• field: description

• expression: Application : (.*), Error code : (\d+)

• map: {"workflowContext.errorCode":"$extract.2","workflowContext.appName":"$extract.1"}

The WorkflowEngine writes the following data to the workflow context:

{
"errorCode": "0001",
"appName": "APP001"
}

fNext, create a dejavu action to see if the error code has come up before. To qualify that the error codde is an an app error code within the same application, use a compound key comprised of the extracted data in the workflowContext. You can use the key mechanism to increase or decrease the scope/granularity of the dejavu action.

Set the following:

• key: AppErrorCodes::$(workflowContext.appName) • value:$(workflowContext.errorCode)

• age: <leave blank>

• enrich: true

This action logic checks for the "errorCode 0001" for "application APP001." If true, it mark the event has having been seen. It updates the custom_info for the event will be enriched with the details: key, value, last seen as epoch and ISO date, and the dejavu flag.

If you want to limit the timeframe for the check, set the age to 86400 to limit the check to the past 24 hours.

The first time the action dectects the data, it writes the following custom_info. Note the dejaVu value is false:

       "dejavu": {
"appErrorCodes::APP001": {
"dejaVu": false,
"lastSeen": 1591873839,
"lastSeenDate": "2020-06-11T11:10:39.000Z",
"value": "0001"
}
}

For subsequent events, the Workflow Engine sets the deJaVu to true and updates the value of lastSeen. For example:

    "dejavu": {
"appErrorCodes::APP001": {
"dejaVu": true,
"lastSeen": 1591874042,
"value": "0001",
"lastSeenDate": "2020-06-11T11:14:02.000Z"
}
}

You can create subsequent actions to lower the severity and to change the description to indicate that the event has already been seen.

Because the previously seen data is stored in the Enrichment API database, you can use it to seed deny lists and and and allow lists. Instead of building complex filters to drop events, seed the correct key and value data into the enrichment database. Then you can create a single DejaVu based Workflow Engine for that “dictionary”. This allows an external system to control the allow/deny lists via the Enrichment API alone.