Integration with MS Teams

Microsoft Teams is a unified communication and collaboration platform that combines persistent workplace chat, video meetings, file storage, and application integration.

eG Enterprise integrates with a team channel, so that eG alerts are automatically routed to that channel. This way, users connected to that channel will be notified of anomalies and will be able to track them to closure.

To integrate eG Enterprise with MS Teams, do the following:

  1. Login to the eG administrative interface.

  2. Select the Manager option from the Settings tile.

  3. Figure 11 will then appear. From the manager settings tree in the left panel of Figure 11, 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.

    Figure 11 : Viewing the ITSM/Collaboration tool options

  4. Now, click on the MS Teamsoption in the right panel (see Figure 11). An MS Teams section will now appear in the right panel (see Figure 12).

    Figure 12 : Configuring integration with MS Teams

  5. To enable integration with MS Teams, first slide the MS Teams slider in Figure 12 to the right.

  6. Then, specify the following in Figure 12:

    • Webhook URL: Specify the incoming webhook URL of the team channel with which the eG manager should integrate. Incoming webhooks are special type of Connector in Teams that provide a simple way for any external app to share content in team channels and are often used as tracking and notification tools. Teams will provide a unique URL to which the eG manager should send a JSON payload with the alert message it wants to POST. Refer to the MS Teams documentation to know how to generate this URL. Once you obtain the URL, enter it here.

    • Incident title: Specify the title format for all eG alerts that are routed to the team channel. The default format is as follows:

      • $prior - $ctype / $cname

      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 VictorOps. You are advised against changing any of the key names.

      The other keys that are part of the default format are discussed in the table below:

      $cname

      Will display the name of the problem component

      $ctype

      Will display the component type to which the problem component belongs

    • Custom payload: Use custom payload to customize the alert information you send to a team channel, so that it includes additional static information.

      Typically, the details of an eG alert are sent as a JSON file to the configured Webhook URL. Every piece of information contained within an eG alert - eg., priority, component name, component type etc. - is represented in the JSON file as a $key:$value pair, where 'key' denotes the alert field, and 'value' denotes the actual value of that field at run time. The 'key' is configured based on what the MS TeamsAPI supports. For instance, if the API represents alarm priorities using the key 'prior', then the same key will be used in the JSON file for denoting alarm priorities. Accordingly, the entry for alarm priority in the JSON file will be $prior:$value. The $value will be Critical, Major, Minor, or Normal, depending upon the actual priority of the alarm being sent.

      If you want eG incidents routed to a team channel to include additional information, then you can define a Custom Payload for that information as a $key:$value pair. For example, say, you want incidents to indicate the FQDN of the eG manager that generated the incidents. Say that the FQDN of your eG manager is egmanager.innovations.com. To include this information in MS Teams incidents, do the following:

      • First, check whether the MS Teams API supports a 'key' that can be used for capturing the 'source' of alerts/incidents. If no such key exists, then you cannot proceed with the Custom Payload configuration. On the other hand, if such a key is available, then proceed to replace the $key in your Custom Payload specification, with that key value. For the purpose of our example, let us assume that the API supports the key named 'source'. In this case therefore, substitute '$key' with 'source'.
      • Then, proceed to explicitly specify the FQDN of your eG manager in the place of $value. This is because, you can use the Custom Payload configuration to add only 'static' information - i.e., information that you explicitly configure, and hence will never change. In the case of our example therefore, the $value will be egmanager.innovations.com.
      • The complete Custom Payload specification will now be: source:egmanager.innovations.com
  7. Finally, click the Update button in Figure 12 to save the changes.