Event Actions
In Unifi, we throw events for Transaction State changes. Like standard ServiceNow Script Actions, Event Actions respond to those events. Unlike Script Actions, however (where there is a simple one-to-one relationship between the event and the action), Event Actions provide an added level of abstraction in that they offer functionality that enables you to triage the events and make decisions about how you deal with them according to the conditions you configure.
Their primary use case would be in dealing with Transaction errors. For example, you may choose to create an incident after receiving five errors in fifteen minutes, or when a specific error code occurs. The available configuration options make their use case extremely flexible, so you could decide, for example, to auto-close previously opened incidents when the Transaction is complete.
The Event Action executes under the following conditions:
Run Conditions. These stipulate the conditions which cause the Event Action to fire. They specify which Integration* and which Event* the Event Action is responding to (*both Integration & Event are mandatory). They can even be dependent on the status of the integration and apply to specific messages.
Triage Conditions. Triage conditions determine whether or not we take any action i.e. the conditions that must apply for the Action script to run.
Action. This is where you will find the Action script, which is the actual script that will run.
The Details fields that can be configured for the Event Action record are as follows:
Field | Type | Description |
Name | String | The name of this event action. |
Description | String | An explanation of what the event action is intended to do. |
Active | Boolean | Enable/Disable this action. |
The Run Conditions fields that can be configured for the Event Action record are as follows:
Field | Type | Description |
Integration* | Reference | The Integration this record applies to. |
Message | Reference | (Visible when Integration is populated). Only run this Event action for this message. |
Integration status** | Choice | The Integration status this Event Action has to match. (Choices: Up, Down, Ignore) |
Event* | Choice | Which event triggers this Event Action to run. Note, the Triage conditions still need to match as well; this event determines whether the triage conditions are run at all. |
*Integration / Event:
Both Integration & Event are mandatory.
**Integration status:
For example, set the Integration status to ‘Up’ to trigger the Event Action only when the the Integration is Up and use the code in the Script action to set the Integration to ‘Down’. Subsequent Transaction events (triggered whilst the Integration is ‘Down’) would then not cause the Event Action to run, because the run condition would not match.
The Triage Conditions fields that can be configured for the Event Action record are as follows:
Field | Type | Description |
Advanced | Boolean | Use a script to determine if this Event Action should run. |
Table* | Reference | Table to run a filter against. |
Filter | Condition | The condition used to find matching records, e.g. errored transactions in the last 15 minutes. |
Limit | Integer | The number of records found using the specified filter that will trigger this Event Action’s Action script to be run. Zero will always be true. |
*Table
There is a known bug in the current release whereby you can only pick Unifi Tables if you are working in the Unifi application scope. This will be fixed in v2.3. Although ordinarily not advised, the workaround would be to create the Event Action in the Unifi application scope.
The Action fields that can be configured for the Event Action record are as follows:
Field | Type | Description |
Action Script | Script | Run this script if the Triage conditions have matched. |
Example script:
var incident,integration,summary;integration = current.getDisplayValue('integration');summary = 'Issue with integration ' + integration + ': error - ' + (current.error || current.process_error);incident = new GlideRecord('incident');incident.addQuery('short_description', '=', summary);incident.query();if (!incident.next()) {incident.newRecord();incident.short_description = summary;incident.impact = 3;incident.urgency = 3;incident.assignment_group = ''; // Your integration team here;} else {// Increase impact and urgency each time the event action is calledincident.impact = (+incident.impact - 1) < 1 ? 1 : +incident.impact - 1;incident.urgency = (+incident.urgency - 1) < 1 ? 1 : +incident.urgency - 1;}incident.work_notes = 'Integration ' + integration + ' has encountered an' +' error ' + current.error + ' and has triggered the event action ' +action.getDisplayValue();incident.update();
Script Variables (available in both the Action script and the Advanced Condition script)
current: the current Transaction that triggered the event.
action: the Event Action record (GlideRecord object).
In the above example code, we query the incident table for records that match (using short_description as a unique identifier). If one isn’t found, we create a new one and set some values. Otherwise we increment the impact and urgency. Finally, we add a work note to the incident.
