Importing 3rd party alerts

Centralized ticketing systems are pivotal in managing alerts within IT environments, including those from internal and 3rd party systems. These alerts, indicating events that may require immediate action, are integrated into ticketing systems through various methods, each with its unique advantages and challenges.

There are 3 primary ways in which alerts from the 3rd party system are imported into a ticketing system,

• Polling
• Native Integrations
• WebHooks

Polling: Scheduled API Requests

In this scenario the 3rd party system offers an API to get alerts and you need to periodically poll the API to get new alerts since the last time the request is made. The code to poll the API code can sometimes be run by the ticketing system itself. For example ServiceNow supports this type of mechanism. The other option is to run the code on an internal machine. This code typically will poll the 3rd party system for alerts and the retrieved alerts are then pushed to the ticketing system.

This solution is most commonly used when,

• the external system does not provide any other mechanism to extract alerts from the system
• the ticketing system being used is home built and therefore may not have integration support on the external system
• providing ticketing system credentials with the external system is not an option

From the IT perspective the challenges with this solution are,

• Some coding is required to make API calls to the external system and import the alerts into the ticketing system
• If the code needs to run on an internal machine then then machine needs to be kept up and running and the program needs to be monitored to ensure it is able to reach both the external system and the ticketing system
• External system and maybe even ticketing system credentials need to be protected so that they do not get inadvertently exposed
• Polling frequency needs to be carefully chosen. It cannot be so frequent that the external system rate limits the API calls and they cannot be so infrequent that important alerts are recorded late

From a 3rd party systems perspective the polling mechanism requires it to handle a constant stream of requests which need to be handled efficiently. Rate limiting is a common mechanism used to lower the load on system.

Native integrations: Direct System-to-System Communication

In this scenario the ticketing system needs to have an external API using which alerts can be pushed to it. The 3rd party system needs to support a native integration with that ticketing system using which the 3rd party system can push alerts to the ticketing system as an when the alert happens. For example ServiceNow and several other vendors offer an API to push alerts to it.

When available this is probably the best option to use.

From an IT perspective the challenges with this solution are,

• The ticketing system credentials need to be shared with the 3rd party system. Sometimes this may not be desirable.

From a 3rd party systems perspective the push mechanism may be more challenging. Now it needs to take on the responsibility of delivering the alert to the ticketing system. This means,

• it needs to store state information on which alerts have been delivered to the ticketing system and which ones still need to be sent
• If there are lots of alerts occurring sometimes it may not be possible to deliver the alerts quickly.
• If the ticketing system is down then retries need to be done.
• If the 3rd party system supports multi-tenancy or multiple native integrations then it adds another level of complexity to the implementation

WebHooks: Event-Driven Notifications

In this scenario the 3rd party system offers a way to push the alert to some HTTP endpoint when the alert happens. This is very similar to a native integration. The main difference between native integrations and webhook based integrations is that in the native integration it is the ticketing system that dictates the contract, whereas in the webhook integration the 3rd party system dictates the contract.

The contract between the two systems includes for example,

• the authentication mechanism needs to be used,
• the endpoint url and
• the payload format

With WebHook integrations therefore the IT organization may need to either add an http server to handle the webhook request from the 3rd party system or use tools like zapier or ifttt to receive the webhook request, reformat it and post to the the alert to the 3rd party system.

From an IT perspective the challenges to this solution are,

• When NOT using tools like zapier and ifttt the IT department needs to setup a server which can handle the web request
• Some sort of ip white listing needs to be setup to protect the server from attacks
• Some sort of authentication mechanism needs to be setup on the server
• Monitoring the server and keeping it running is additional work

From a 3rd party system perspective the challenges are pretty much the same as what it would be for a native integration

How to decide which option is right?

• From an IT perspective when a native integration is available choosing it is a no-brainer.
• The second best option may be to use webhooks in combination with a workflow automation tool like zapier.
• The third best option may be to use ticketing systems like ServiceNow with their plugin mechanism which allows for writing simple code to poll 3rd party systems.
• Finally If you already have a way to run and monitor servers and have someone available to do basic coding then using the webhook option with a custom server or polling the 3rd party system should be ok.