This article will demonstrate the end to end path from firing events in ServiceNow to tracking them and alerting on them through Observer.
In this example we are going to be:
Our example is alerting when an import set run does not complete. If you are familiar and comfortable with firing a custom event within ServiceNow you can skip to step 3.
In our example we are creating a custom event that we are firing for Import Set Runs. Navigate to the Event Registration module and create a new event. The name chosen here should be indicative of event occurring and unique. Below I have created one named sys_import_set_run.failed on the table sys_import_set_run.
Within ServiceNow you can fire the event any number of ways. Scheduled Jobs, UI Actions, Scripting, Business Rules, etc. For simplicity sake this example will utilize a Business Rule to fire the event when we see the Import Set Run state changes to Did Not Complete.
We will then fire the event using the gs.eventQueue command. This will take in the following parameters:
You will choose parameters which will make sense in the context of your event, these values can be anything for the sake of Observer. In my example I am including the table name and Import Set Number.
The first step of utilizing Observer to monitor these events is to create an Event Subscription, which you will find under the Observer module. Create a new one and reference the created event and choose a custom flag. This flag will make more sense in step 5, I chose ISF (Import Set Failed).
Once you hit submit we will auto-generate the Script Action on this event to send out the message. You should not need to modify this for default the behavior.
Assuming your credentials are set up correctly, the message will be sent when the event is fired. The message will be stored based on this instance's name. To create the Alerts navigate to the Observer portal for this instance and go to the settings.
Navigate to the Settings > Notifications > Emails. Then verify your emails and that you have the right box check-marked, according to your priority of this event.
Go to the Settings > Alert Configurations > Events to create the appropriate event handler within Observer.
|Name||The name of the event to trigger an alert. Use “%” at the end of the name to treat the end as a wildcard e.g. “sys_import_set_run%”. This way events such as “sys_import_set_run.success” and “sys_import_set_run.failed” will both trigger an alert.|
|Value||The minimum value to trigger an alert. Leave this blank if any value for this event should trigger an alert.|
|Description||A plain text description for the alert, for your own use.|
|Type||The type of alert to trigger. Options available are High, Medium, and Low.|
Note that events as received by Observer will not have the ^FLAG value at the end so you should not specify the event name as Name^FLAG as this will cause the event alert to not find a match and subsequently not fire an alert.
Also note that this event configuration will map the ServiceNow flag from its original, in our example ISF, to a flag based on the priority assigned, in our example H (High).
In Dubnium, custom events can be tested like the custom alerts after they are saved by clicking on the play icon located under the Actions field. The trash icon replaces the “Delete Selected” button. After being tested, the event will be shown in the monitor and in the list after refreshing the page. Since these custom events have types “High”, “Medium”, and “Low”, they will only show in the Alert lists, not in the Event list, when tested.
Aside from receiving your event within an alert you can also view it within two different monitor panes.
If you assigned it to a High, Medium, or Low priority within the Event Configuration the event will appear on your home monitor page.
The Event will also appear under your trend charts so you can look at metrics relative to the moment the event occurred. In our example it is showing up as a “H” flag for High.
If you do not create a specific event configuration within Observer than it will still appear within the trend chart, but, it will retain the flag that you assigned within ServiceNow. In our example we will see the ISF flag.
You can utilize this for example: to fire an event once you upgrade some subsystem and compare the SQL Response Metrics before and after.