A webhook is an HTTP callback which allows one application to provide other applications with real-time information. eG Enterprise is capable of posting event messages - i.e., eG alerts - to any third-party trouble ticketing system that is capable of accepting incoming webhooks.
To implement this integration, do the following:
- Login to the eG administrative interface.
Select the Manager option from the Settings tile.
Figure 5 will then appear. From the manager settings tree in the left panel of Figure 5, select the ITSM/Collaboration Integration node. The third-party ITSM/Collaboration tools that eG Enterprise can integrate with will be listed in the right panel.
- To enable integration using webhooks, first slide the Webhook Integration slider in Figure 6 to the right.
Then, specify the following in Figure 6:
- Integration Name: Specify the name of trouble ticketing system with which eG Enterprise should integrate.
- Webhook URL: Here, specify the incoming webhook URL of the target trouble ticketing system. eG alerts will be transmitted to this URL only.
- HTTP Method: Select the HTTP method that eG Enterprise uses to send event notifications into the trouble ticketing system. The options are GET, POST, and PUT.
- Authorization Type: Some trouble ticketing systems require authorization from the external source to accept the incoming webhook. If the target of this integration requires such an authorization, then first select the type of authorization from this drop-down. The options are as follows:
- Basic authentication
- Content Type: Then, indicate in what format eG alert information is to be sent to the third-party trouble ticketing system. Since the eG manager typically sends alarm information as JSON files, the application/json option is chosen by default here.
Payload: Configure the event payload that is to be fed into the target trouble ticketing system. In other words, configure the type of information that each eG alert sent to the target system should contain. A sample payload specification is provided below:
"text": "$prior - $ctype/$cname - $pdesc/$"
The ‘dollared’ ($) text in the format above is a key, the value of which varies at run time, depending upon the information contained in the eG alarms. For example, in the default format above, $prior is a key that represents the alarms priority, and changes according to the priority of the actual alarm that is sent by the eG manager to the target system.
The other keys that are part of the sample format are discussed in the table below:
Will display the name of the problem component
Will display the component type to which the problem component belongs
Will display a brief problem description
Before specifying the keys, you will have to check which keys are supported by the target trouble ticketing system. Only such keys should be configured in your payload.
If the target trouble ticketing system enforces Basic Authentication, then select the Basic option from the Authorization Type drop-down. Where Basic Authentication is enforced, the trouble ticketing system requires that webhooks be accompanied by the credentials of a valid user with the right to send webhooks. In this case therefore, provide the credentials of such a user in the User and Password text boxes.
Some other trouble ticketing systems may authenticate incoming webhooks using a unique API key. If the eG manager is being integrated with such a trouble ticketing system, then first generate an API key using the third-party system. Next, when configuring eG integration with that trouble ticketing system, set the Authorization Type to API Key and specify the correct API key.
Figure 7 : Setting Authorization Type to API Key
Then, by selecting the appropriate option from the Add API Key to drop-down, indicate where the API key needs to be inserted - in the HTTP request header? or in query params?
- Finally, click the Update button in Figure 6.