With Colin Christie
In this article, we're going to be looking at an example of binding an alert to a non-host CI using event rules in ServiceNow. In this example, we will be looking at where an alert gets bound to an application service type CI. Let’s take a look at how to accomplish this. The default out-of-the-box behavior for events and alerts in ServiceNow is that when an event comes in and it has the node field populated — this node can be found in the CMDB — the alert that is raised from the event will have that configuration item set (reference 1:02 in the video). This is the alert that goes with the event that was just shown; the node field was populated with a CI that could be found in the CMDB, and then the alerts configuration item field got populated.
Now, what if you wanted this alert to have the CI populated with an application service CI, instead of a node CI?
Creating a New Event Rule
When creating a new event rule, you create it from the event itself. You never go into the menu event rules and then click create a new event rule because then you won't get any of the raw info from the event. This is going to be for SCOM binding alert to CI. We are not going to set an event filter. Then we navigate to our Transform and Compose Alert Output. The first thing we need to do is clear out the node field so that the alerts node field won't get populated. Then we set the configuration item as the host CI.
The next thing you need to do is utilize the additional information field on the event. This works by allowing the sender of the event to add an additional information section to the event, so it’s like a JSON payload, would be adding another field called additional info and then you would add whatever data you needed as a JSON type payload. Using the additional information on the ServiceNow side, you can then create an event rule that will parse info from there.
For this event, we had an additional information field called app and the raw data was APAC billing. This allows us to enrich the way the alert will be raised, instead of raising it just against a server CI, it can now be raised against an application CI. Note: we set the Event Input field to use the name because we are going to utilize this as the name field for the application service CI. Essentially what we are doing here is trying to map this APAC billing value to the name of the CI you want to set.
Now let's look at our binding. We are going to override the default binding and use CI field matching. We are going to use the application service CI. Now we can see the instructions (reference video at 4:19). As we already saw, we cleared out the node field, selected the CI type, and application service, and then utilized the additional information, using a name with the same name as a field of the selected CI.
Activated Alert Rule
Let's look at what would happen now if we got that same event, but our alert rule has now been activated. We’re going to send that event again, and here we see our new event with the additional information, so it’s telling us which app is having an issue and now we've got an alert raised. The configuration item was set to APAC billing. Let's take a look at the alert to make sure this is all associated with the right event, and everything checks out. Now we have this alert raised against an application service CI, instead of a server CI, and the benefit of this can be that this alert can now go to the application team instead of the infrastructure team. This will help get the application up and running back to a healthy state more quickly. It also gives us the benefit of being able to triage and remediate issues by their impact on the business.
If you're getting an alert just raised against a server CI, that doesn't necessarily tell you how big of a deal it is. If this server is supporting a very minimally-utilized application that is not very important to the business, then it's not something that needs to be addressed immediately. However, if this is supporting a service that is critical to my business, then that would need to be addressed right away. This is not always clear when you only have a server CI. If you've taken the time to set up application services, then you can take advantage of utilizing that to raise the alerts and triage as it would impact the business.
Did you find this Event Rule With CI Binding in ServiceNow article helpful? Are you ready to start your journey with ServiceNow? If you want to find out more information about GlideFast Consulting and our ServiceNow implementation services, you can reach out to us here.
About GlideFast Consulting
GlideFast is a ServiceNow Elite Partner and professional services firm that provides tailored solutions and professional services for ServiceNow implementations, integrations, managed support services, application development, and training. Reach out to our team here.