Integrating with SNOW ITOM

ServiceNow® ITOM Enterprise delivers a comprehensive and integrated set of ITOM capabilities including infrastructure discovery, event management, automation/orchestration, operational intelligence, and many more. The ServiceNow Event Management solution in particular, consolidates, correlates, and analyzes data from all of your monitoring tools to deliver real-time information about the health of business services and IT infrastructure.

In eG typically, a group of closely-related problem events are clubbed in a single alarm. eG Enterprise performs event-based integration with SNOW ITOM. In other words, for every problem event that is part of a single alarm in eG, a separate ticket is automatically created in SNOW ITOM.

The first step towards integrating eG with SNOW ITOM is to enable the event-based integration capability. For that, do the following:

  1. Edit the eg_services.ini file in the <EG_MANAGER_INSTALL_DIR>\manager\config directory (on Windows; on Unix, this will be the /opt/egurkha/manager/config directory).

  2. In the [TT_EVENT] integration section, you will find the isEventBasedTroubleTicketingEnabled flag. This flag is set to No by default. To enable ever-based integration, set this flag to Yes.

  3. Finally, save the file.

Then, proceed to 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 SNOW ITOMoption in the right panel (see Figure 11). A SNOW ITOM section will now appear in the right panel (see Figure 12).

    Figure 12 : Configuring integration with SNOW ITOM

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

  6. Then, specify the following in Figure 12:

    • URL: eG Enterprise integrates with ServiceNow using its web service API. The eG manager POSTs eG alerts to the endpoint URL of the API as JSON payloads containing alert information. To enable the eG manager to connect to the API, you need to specify the endpoint URL here.
    • Port: The Port at which ServiceNow listens for problem information sent by the eG manager.

    • Authorization Type: The eG manager sends alarm information to ServiceNow as a web service request to the configured URL. Upon receipt of the request, ServiceNow will attempt to validate the source of the request using one of the following authentication methods:

      • Basic authentication

      • O Auth 2.0 authentication

      If ServiceNow enforces Basic Authentication, then select the Basic option from the Authorization Type drop-down. Where Basic Authentication is enforced, ServiceNow requires that web service requests be accompanied by the username and password of a user who has access to the ServiceNow instance. Accordingly, if Basic is set as the Authorization Type, you need to provide the credentials of a user with the right to access ServiceNow in the User and Password text boxes.

      On the other hand, if ServiceNow enforces the O Auth 2.0 authentication method, then select the OAuth 2.0 option from the Authorization Type drop-down. O Auth 2.0 lets users access instance resources through external clients by obtaining a token rather than by entering credentials with each resource request. This means that where O Auth 2.0 is enforced, the eG manager needs to obtain an access token, so it can create/modify trouble tickets in ServiceNow. For this, the eG manager should first connect to the ServiceNow instance as a user who is authorized to request for an access token, and then submit web service requests as a valid 'Client'. This is why, if OAuth 2.0 is set as the Authorization Type, you will have to specify the following:

      • User and Password: The credentials of a user who is authorized to request for an access token
      • Client ID and Client Secret Key: The Client ID is an auto-generated unique ID of the client application - i.e., in our case, the eG manager application - requesting the access token. The Client Secret Key is a shared secret string that the ServiceNow instance and the client applications - i.e., the eG manager - use to authorize communications with one another.
    • Does ServiceNow use proxy for connections: If the eG manager needs to communicate with the ServiceNow instance via a Proxy server, then set this flag to Yes.
    • Proxy IP/Hostname and Proxy Port: If the Does ServiceNow use proxy flag is set to Yes, then specify the IP/host name of the Proxy server and the port number at which the Proxy server listens in the respective text boxes.
    • Does Proxy require authentication: This flag is applicable only if the Does ServiceNow use proxy flag is set to Yes. If so, then use this flag to indicate whether/not the Proxy server requires authentication. Set this flag to Yes, only if the Proxy server requires authentication.
    • Proxy UserName and Proxy Password: If the Does Proxy require authentication flag is set to Yes, then provide the credentials of a valid Proxy user here.
    • Event Source: Specify the tool that is sending events into ServiceNow. For the purpose of our integration, this can be set to eG Enterprise.
    • Event Sender: Specify the IP/host name of the client that is sending the events into ServiceNow. In our case, this should be the IP/host name of the eG manager.
  7. Finally, click the Update button in .