Alarm Management Open API Incoming Notification Support (TMF 642)

[Grace Petrucci]

What Are Event Notifications

Event notifications provide the ability for ServiceNow to listen to the external events occurring in the customer network and respond to the events in near real time. Events can also be broadcast to external systems using ServiceNow platform capabilities in an event driven architecture.

Some examples include:

• Inbound notifications for Alarm creation

An alarm has been triggered within the network, affecting multiple customers. Within the customer ecosystem, ServiceNow manages the customer base, necessitating communication to inform affected customers. The source system is required to notify the customers accordingly.

• Inbound Notifications for Alarm Attribute Value Change

Numerous alerts have been generated, leading to an escalation in severity. The NOC, stationed within ServiceNow, must be promptly notified of this situation, thus prompting incoming notifications.

• Alarm Clear Notification

The problem has been resolved, and it's necessary to inform the customer about the restoration of service.

Automated Notification from Network Monitoring Tools

ServiceNow implementation of TMF 642 includes the following:

• The support of inbound notifications form 3^rd party systems to the  Alarm Management Open API
• Event monitoring architecture using Kafka or Pub/Sub for on prem customers
• Easily enable listener registration bu configuring callback endpoints
• Receive timely updates to trigger workflow within ServiceNow TSOM & TSM
• Supported Notifications include:
  • Alarm Create Event
  • Alarm Attribute Value Change
  • Alarm State Change
  • Alarm Delete Event

ServiceNow implementation is an Event Based Architecture based on current design guidelines​ for two types of implementation, one is for Cloud Customers and another for on-premise customers. The following sections provide a detailed overview of both implementations.

Cloud Customer Implementation High Level Overview

Messages originating from a customer instance are being sent to a ServiceNow gateway.  Leveraging Hermes (ServiceNow Kafka), all messages are replicated and disseminated to all ServiceNow instances. Kafka Flow Trigger or Script Consumer are used to process those messages followed by creating the target records.  Out of the box demo data is available and includes Topics and Flows. The diagram below is a high level architecture of a customer cloud implementation of Alarm Notification Open API.

 Cloud Customer – High Level Architecture

On-Premise Implementation High Level Overview

Within this section, the on-premise implementation will be detailed. All of the on-premise customers who want to leverage the notification engine can also use the capability of Pub/Sub to send or receive the events from external parties.

As part of the below example, a customer instance will send the following messages.

1. As indicated below, the first step will be to send the topics through the REST API and these topics will then be sent to all the ServiceNow Instances.
2. Once the topics are received, a subscription will be triggered to let the Pub/Sub system know that these are the topics that need to be sent to ServiceNow once the message is received. As part of the subscription process, ServiceNow will supply a Callback url to the Pub/Sub system.
3. In real time, once the event occurs, then this event in the customer site will be sent via Kafka and replicated in a Rest Proxy and the event will be sent directly to an Event Table in the ServiceNow Instance via the Pub/Sub as seen in the diagram below.

On Premise – High Level Architecture

 

Use Case Descriptions

Below is a list of use cases that will be further examined.

1. Create or View Topics: Enable the functionality to observe relevant topics for Alarm APIs and manage them for both Pub/Sub and Hermes messaging services. In other words, if there are any new or existing topics that are created, ServiceNow provides the capability to enable visibility of these topics within the ServiceNow instance.
2. Establish or Administer Subscriptions: Enroll customer interfaces for subscribing to incoming messages. In other words, if the end customer is not registering, then the Pub/Sub system will not be able to identify the consumer needing to receive these messages when the event occurs.
3. Implement Flow Triggers for Kafka and Pub/Sub Messages: Possess the ability to visualize flows designed to manage incoming messages, which are then propagated to the respective target event tables. All the flows created should have the capability to consume the messages and should allow the modification of these messages as needed.

ServiceNow Personas Roles & Responsibilities

Topic Viewers and Managers
Role	sn_api_notif_mgmt.topic_subscription_viewer
	sn_api_notif_mgmt.topic_creator
Responsabilities	Reviews Topics received from pub/sub or Hermes Kafka.
	Manage topics like create new topics, view existing topics.

Topic Viewers and Managers
Role	sn_api_notif_mgmt.topic_subscription_viewer
	sn_api_notif_mgmt.subscription_creator
	sn_api_notif_mgmt.subscription_admin
Responsabilities	Reviews Subscriptions, create new subscriptions
	Create or enable trigger flows to handle incoming events.
	Edit and Delete Subscription

ServiceNow Implementation of Open API Incoming Notification Support (TMF 642)

• Navigate to ALL > Telecom API Notification
  • Click on Topics
  • A new model “Telecom API Notification” has been added.

• One Topic has been created which is the AlarmCreateNotification Topic with the header query and the content query.
• Click on the “i”

• The Topic will be expanded
• Click on “Open Record” to see additional details of the Topic table

• The Topic can be created manually as seen below
  • Topic ID: Unique Name
  • Topic Name
  • Type (Can be either Egress or Ingress)
  • Header Query: Details of the type of Query
  • Content Query: Details the content of the Query
  • Description

As per TMF688 guidelines indicating that any Topic can have both a Header and Content associated with it.

• On the previous screen, the TOPICs can also be created automatically by clicking on the UI Action “Get Topics”

•  Once the topic is created, the next step is to implement the subscription
  • Navigate to ALL>Telecom API Notification > Subscription

• Click on the “i”
• Click on “Open Record”

• The Topic Needs to be selected
• A filter query can also be defined
• Generate Callback URL UI Action option is available
  • By clickin on Generate Callback URL, a default url will automatically be generated an will populate the Callback URL field.
• Finally the next step is to click on the Register UI in the UI Action
  • The Registration Status canges to Registered
  • The Registration Message appears: Registration Successful
  • A unique subscription ID is also auto created
    • Indicates that the subscription is unique and cannot be used for a different topic

Flow Designer Process

• Navigate to ALL > Process Automation > Flow Designer

• Click on DefaultAlarmEventNotificationTrigger

• Click On Connections
  • The Inbound and Outbound Connections are available
  • Click on the Telecommunications Alarm Management Open API

• All the connection will appear in the below window
• Click On Edit

• The URL is automatically generated
• When the URL is generated, it will need to be copied and pasted into the external system
  • To copy the URL, click on the icon to the right of the URL
  • This will be the endpoint that the notifications will be delivered
  • The URL will have the instance name and the unique sys ID
  • Close the window

• Click on the DefaultAlarmEvent

• Once the request that was shown previously hits an endpoint, the out of the box DefaultTriggerDef flow will be automatically triggered
  • Once the request appears, it will begin parsing the request and will determine the type of the event
    • If the Event contains AlarmCreateNotification then it will use the AlarmCreateEvent
    • If the event contains AlarmChangeNotificaion then the AlarmChangeEvent will be triggered
    • If the event contains AlarmDeleteNotification then the AlarmDeleteEvent will be triggered

• Click on DefaultTriggerDef to expand the workflow
• Additional Attributes can be added as a trigger definition found on the right hand side

Implementation Details

Plugin Details

A new plugin has been created for API Alarm Notification indicated below.

            API Notification Management (com.sn.api.notif.mgmt)

This new plugin has a dependency on the following:

            ServiceNow IntegrationHub Starter Pack Installer (com.glide.hub.integrations.eterprise)

            Apoke Selector (com.sn_appss)

Dependancy on the existing Telecommunications Alarm Management Open API (com.sn.ind.tmf642)

            API Notification Management (Com.sn_api_notif_mgmt)

• Event types related to alarm creation have been added along with the capability of updating and deleton capability

Data Model Modifications for API Notification Pub/Sub Support

There is the addition of two new tables Topics and Topic Subscription created to support the Topic Creation and Subscription. Below are the characteristics listed for each table.

Topic processing Flow Diagram

The details of the end-to-end processing of Topic is indicated below.

1. Outbound GET API: This will be an action on Topic Table to get Topics generated via broker.
2. Generate CallbackuRL: Once Topics are there, it's time to create subscriptions on them. First insert records in Topic Subscription table and then Generate webhooks for that using this step.
3. Register: Once callbackurl is generated then hit Register button to Subscribe for that Topic.
4. After Registration, we can listen to the requests or event notifications on these webhooks via External Triggers.

External Trigger and Event Handling

The flow diagram for processing external triggers along with handling Events is depicted below.

Integrations with 3^rd Party

The CallbackURL generation is a feature where webhooks are generated where external systems can register and use those webhooks for API notifications calls for events.

• In order to generate webhooks we are using ServiceNow IntegrationHub Enterprise Pack Installer (com.glide.hub.integrations.enterprise) which provides the feature of creating External Event Sources that are webhooks and triggers to initiate requests on those webhooks.
• This will internally use NowMQ for processing of Events via message broker.

To implement the Subscription of Topics an outbound call will need to be made to an external system and after successful registration, a subscription id is sent back to Servicenow. 

• An endpoint for external system is not set but rather Spoke Selector (com.sn_appss) is used as a platform functionality to simulate the response from an external system. Customers can replace this spoke from a Rest endpoint or message or connection alias etc. For an outbound call.

​Acronyms

Pub/Sub: Publisher/ Subscriber

• Publisher are the applications which produce messages
• Subscribers are the applications that consume messages