EV Observe - ServiceNow Ticketing Integration

Last modified on 2024/03/11 16:51

ServiceNow : Utah

TicketingIntegration_ConstantlyDeveloped

   ServiceNow is in constant development. As such, some of the screens shown in the procedures below may be different from the ones in the final interface.

TicketingIntegration_Definition

The ServiceNow ticketing integration is used to create and synchronize tickets in both ServiceNow and EV Observe.

  • A ticket can be created in ServiceNow when a monitoring alert is acknowledged for a configuration item (CI) (host, service, or user service). Open url.png See Ticketing integration - Overview.
  • You can view information on the ServiceNow ticket in the EV Observe CI.
  • To set up this integration, you must first perform the cross-reference mapping between some of EV Observe information and ServiceNow information.

Notes

TicketingIntegration_Notes

  • Integration is performed using the ServiceNow REST API.
  • In order for tickets to be added to the CI of an EV Observe company or site, the company or site must first be defined with a CRM link to the company defined in ServiceNow.
    • EV Observe: 2024.4 (5.5)+ The adding of the CRM link is optional if the value of the disableCrmCompanyLink parameter is True in the specific information specify in the ServiceNow connector. Open url.png See Configuration in EV Observe.
    • When you define the CRM link in a company in EV Observe, all of the sites in this company will inherit this link.
  • The integration can be performed manually (users open the ticket themselves), in automatic mode (the ticket is opened automatically), or in driven integration mode (the ticket is opened automatically subject to the rules in the cross-reference mapping file). Open url.png See the description.

Caution

TicketingIntegration_Caution

  • To optimize performance, only one call is made to the ServiceNow Web service for processing the list of tickets. If this list of tickets to be synchronized contains one or more tickets that no longer exist in ServiceNow, e.g. ticket permanently deleted from the recycle bin, the Web service will generate an error and the integration will not update the list of tickets. To prevent this, you should avoid permanently deleting any open ticket in monitoring.
  • Based on your context, check which fields are mandatory in ServiceNow for creating tickets. If mandatory fields are considered optional by the integration, the integration will not run correctly.
  • If the integration is configured to run in automatic mode or driven integration mode:
    • Ticket creation will be blocked if a mandatory field is not specified.
    • If urgency and impact values are specified in the cross-reference mapping file, these values will have priority over any other source of information and will be considered as the reference values for the urgency and impact of each ticket.

Cross-reference mapping between EV Observe and ServiceNow

TicketingIntegration_FieldMapping

The cross-reference mapping will map the fields in EV Observe with those in ServiceNow and determine the display of fields when tickets are opened, i.e. mandatory, optional or hidden fields.

  • The first column in the table displays the ticket field in EV Observe.
  • The second column displays the ticket field in ServiceNow.
  • The third column displays operating rules for the integration.
  • The fourth column indicates the mandatory fields required to ensure that the integration runs correctly. There are 3 possible values:
    • Hidden: The field is ignored.
    • Optional: The field can be used.
    • Mandatory: The EV Observe field must be mapped with a ServiceNow field.
EV Observe field ServiceNow field Operating rules Is Required
participant assigned to If this field is mandatory, the option selected for the team field must be Hidden. Yes
contact caller Yes
contract N/A N/A
environment N/A N/A
category N/A N/A
service N/A N/A
service item N/A N/A
priority N/A N/A
team assignment group If this field is mandatory, the option selected for the participant field must be Hidden. Yes
CI configuration item

Hosts and services:

  • The ID of the CI is used if it is specified in the cross-reference mapping rule.
  • If this is not the case, the ITSM_ID specified for the host or parent host of the service will be used.
  • If this is not the case, the host name will be mapped with the CI name.
  • The CI field will be left unspecified if there is no mapped value or if there are two or more mapped values.

User services:

  • The ID of the CI is used if it is specified in the cross-reference mapping rule.
  • If this is not the case, the FR name will be mapped with the CI name.
  • The CI field will be left unspecified if there is no mapped value or if there are two or more mapped values.
No

Cross-reference mapping file

TicketingIntegration_MappingFile

The cross-reference mapping file is used when integration is performed in automatic mode or driven integration mode. It is used to load values in the fields used by the integration and define mapping rules.

File description

     Open url.png See the general description and input rules in the file.

Management of specific fields

ServiceNow ticketing integration allows you to add to the cross-reference mapping file all specific fields available in the API REST ServiceNow.
         Mapping file - Additional fields.png

  • You must comply with the syntax found in the fields. It is defined in the ServiceNow REST API.
  • You must specify the name and value for each specific field.

example  

  • field name 1 :  category ; field value 1 : computer
  • field name 2 :  subcategory ; field value 2 : laptop
  • To add a line break, use the following syntax, <br> or <br/>.

example  comment:  test <br> test

 

  •    contributor and contact fields are mandatory.

  • CI field is optional.
  • Refer to the sys_id of the desired ServiceNow user to fill in the contributor and contact fields.

File example

  Cross-reference mapping file

Tickets will automatically be created when the status changes to Critical for service CIs whose tag ID is ID 2187.

Procedure: How to configure the ServiceNow ticketing system

Step 1: In ServiceNow, configuration of elements required for ticketing integration

A dedicated role called EV Observe will be used to configure the permissions and access rights required for calling the ServiceNow REST API.

  • The role must be assigned to all participants and assignment groups required to work in EV Observe.
  • Permissions required for using the ServiceNow REST API:
    • Rights to view companies and callers
    • Rights to create incidents

Best Practice icon.png  Assign the Itil role to the dedicated user (Web service access only option selected). This user will not be able to log in via the ServiceNow user interface to perform other actions.

Step 2: In EV Observe, configuration of the ticketing integration

Step 2.a: Create a ServiceNow connector used by the integration

     Open url.png See the detailed procedure.

1. Specify the general information.

  • Type: Select the SERVICENOW Web service connector.
  • Module: Select the Ticketing value.
  • URL: URL of your ServiceNow platform.
  • User / Password: Login and password of the dedicated integration user created in ServiceNow.

2. Specify the Specific information fied to insert the additional information required for the integration.

  • Follow the format below.
  • Replace the values highlighted in yellow with the values configured in ServiceNow.
     

{"roles":"<EV Observe role defined in ServiceNow>","ticket":{"closed_status":["<list of closed status>"]},"personal_fields":["<list of field search>"],"impactMatrix": {xx}

example  

{"roles":"itil","ticket":{"closed_status":["Closed","Canceled"]},"personal_fields":["city"],"impactMatrix": { "0": { "2": { "0": { "impact_id": "3", "urgency_id": "1" }, "1": { "impact_id": "2", "urgency_id": "1" }, "2": { "impact_id": "1", "urgency_id": "1" } }, "3": { "0": { "impact_id": "3", "urgency_id": "3" }, "1": { "impact_id": "2", "urgency_id": "3" }, "2": { "impact_id": "1", "urgency_id": "3" } } }, "1": { "1": { "0": { "impact_id": "3", "urgency_id": "2" }, "1": { "impact_id": "2", "urgency_id": "2" }, "2": { "impact_id": "1", "urgency_id": "2" } }, "2": { "0": { "impact_id": "3", "urgency_id": "1" }, "1": { "impact_id": "2", "urgency_id": "1" }, "2": { "impact_id": "1", "urgency_id": "1" } }, "3": { "0": { "impact_id": "3", "urgency_id": "3" }, "1": { "impact_id": "2", "urgency_id": "3" }, "2": { "impact_id": "1", "urgency_id": "3" } } } } }

List of specific parameters

  • role: Role of participants or assignment groups available for assigning.

example  "Itil"

Best Practice icon.png  Create a dedicated role called EV Observe and assign it to all participants and assignment groups required to work in EV Observe.

  • closed_status: List of closed statuses.

example  "Closed","Canceled"

  • personal_fields: Fields in the ServiceNow core_company table used for filtering the search field, CRM link.

example  ["city"], ["country"], ["street"], ["Name"]

  • impactMatrix: Matrix that determines the impact and urgency of tickets dynamically based on the type of CI (i.e. host, service or user service), its business impact and current status in ServiceNow.
    • Type of CI: 0 = Host, 1 = Service, 2 = User service
    • Status: 1 = warning / degraded, 2 = critical / down, 3 = unknown
    • Business impact: 0 = Low, 1 = Medium, 2 = High

example  {"0":{"2":{"0":"3","1":"2","2":"1"}},"1":{"1":{"0":"3","1":"3","2":"2"},"2":{"0":"3","1":"2","2":"1"},"3":{"0":"3","1":"3","2":"2"}}}}

 

Step 2.b: Associate the company with the ServiceNow entity using a CRM link.

     Open url.png See the detailed procedure.
 

Step 3: In EV Observe, create tickets according to ServiceNow integration operating mode.

     Open url.png See the detailed procedures:

Step 4: Track, resolve and close the ticket.

  • Ticket follow-up in ServiceNow and EV Observe
  • Corrective action to resolve alert
  • Close ticket in ServiceNow
Tags:
Powered by XWiki © EasyVista 2024