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 as a feature of the Add-ons v2.1 download and later. See Install Moogsoft Add-ons for information on how to upgrade.
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.
Back to Workflow Engine Functions Reference.
Arguments
Workflow Engine function dejaVu
takes the following arguments:
Name | Required | Type | Description |
---|---|---|---|
| Yes | String | Source field to use as the key. Can be complex. |
| Yes | String | Source field containing the value to look up. Can be compound. |
| No | Number | Time to reset the 'last seen' value in seconds. Default is forever. |
| No | String | True or false. Specifies if the last seen data should be added to the object (under |
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.