ConnectALL interacts with ServiceNow via its ReST API.

Supported Authentication

(tick) HTTP BASIC

(tick) OAuth

Supported Entities

(tick) Incident

(tick) Problem

(tick) Change Request

(tick) Test Management

(tick) Knowledge

(tick) Service Catalog

(tick) TimeCard Support

(tick) Other entities - Check here for advanced configurations 

(tick)  Non-task Entities

Supported Functionalities

(tick) Issue Linking –  Issue Linking is supported for the entity types such as Incident, Problem, Change Request, Epic, Defect, and Enhancement.

(tick) Sync Staging & Master Tables

(tick) Sync Standard & Custom Fields

(tick) Sync Comments

(tick) Sync Attachments

(tick) Sync Service Catalog

(tick) Attachments Deletion

To know about the supported ServiceNow versions, click here.

Here is a common use case for synchronizing ServiceNow incidents:

  • The service desk agent creates an incident in ServiceNow.
  • ConnectALL creates a new bug in Jira for every incident.
  • The developer works on the reported bug and updates the status with a possible resolution.
  • ConnectALL synchronizes the status changes back to ServiceNow to notify about the current resolution.

Required Roles & Permissions

A ServiceNow user configured in ConnectALL (to be used for synchronization) must have the below-mentioned roles and table permissions.

RolesComments
incident_managerRequired for Incident and Problem entity
change_managerRequired for Change Request entity
personalize_choiceRequired if ConnectALL's plugin* is NOT installed
x_11154_g2g.caadminRequired if ConnectALL's plugin*  is installed. By assigning this role, the above three roles will be automatically assigned to the user. Therefore, assigning the above three roles separately is not required.

In addition to the above, the privilege levels mentioned in the following tables have to be created for the role(s) associated with a user at the global level.

TablesACLApplication LevelComments
sys_dictionaryReadGlobal/ConnectALLRequired if the ConnectALL plugin* is NOT installed 
sys_dictionary.*ReadGlobal/ConnectALLRequired if the ConnectALL plugin* is NOT installed 
sys_glide_objectReadGlobal/ConnectALLRequired if the ConnectALL plugin* is NOT installed 
sys_glide_object.*ReadGlobal/ConnectALLRequired if the ConnectALL plugin* is NOT installed 
sys_db_objectReadGlobal/ConnectALL

Required if the ConnectALL plugin* is either installed or not installed 

sys_db_object.*

ReadGlobal/ConnectALLRequired if the ConnectALL plugin* is either installed or not installed 
* ConnectALL's plugin is referred to as an application by ServiceNow and is available in ServiceNow's app store

ServiceNow User Configuration

ConnectALL expects the configured sync user to have GMT as the timezone set in the profile. You can verify or change this timezone by clicking on the Username on the home screen. 


Important Information

When a ConnectALL sync user that is also a non-admin user (in ServiceNow) attempts to create or update a record in the REQUESTED ITEM type in the ServiceNow application, the action will fail with the below error.

{"error":
{"detail":"ACL Exception Insert Failed due to security constraints","message":"Operation Failed"}
,"status”: “failure"}

To overcome this issue, assign a few roles to that sync user in the ServiceNow application. Once you have assigned these roles to the user, the user will be able to create/update records in RITMs. Here's the list of roles:

  • catalog
  • catalog_admin
  • catalog_editor
  • catalog_manager
  • itil
  • itil_admin
  • user_admin

In addition to the above, to ensure that the variable sets (of the catalog items) synchronize successfully into the ServiceNow application, create a custom role for the non-admin user and assign create/read/write privileges to that user for the following tables:

  • sc_item_option
  • sc_item_option_mtom

When you do this, you will be able to sync variables successfully into ServiceNow.

Configure Automation

Enter the ServiceNow connection parameters URL and valid application login credentials to create a mapping. The user must have the required roles and permissions as mentioned above.

LDAP Integration

If you have integrated ServiceNow with LDAP, create a local user account in ServiceNow and use the local user in the ConnectALL configuration. The URL has to be suffixed with /login.do

Example: https://your-instance.service-now.com/login.do

Authentication Using OAuth

ConnectALL requires access to your ServiceNow instance to sync data. To gain access, it allows you to authenticate using OAuth to connect to a ServiceNow Instance. Enabling OAuth authentication in ConnectALL for the ServiceNow application is a two-step process wherein you have to first generate a Client ID and Secret in the ServiceNow application, and the same Client ID and Client Secret has to be entered in the connection that you have created for ServiceNow. Follow the below procedure to generate a client ID and secret in the ServiceNow application.

Step 1: Generating Client ID and Secret in ServiceNow

  1. Navigate to System OAuth>Application Registry. The Application Registries screen will be displayed.
  2. Click New.
  3. Provide a name for the token, other details, and click Submit. You could set a desired value in the Access Token Lifespan field. In the below image, it is set to 2 minutes.

           

You have now obtained the Client ID and Client Secret that is going to enable the access. The next step is to create a connection with the client ID and client secret that you generated in the ServiceNow application. 

Step 2: Creating Connection with a Client ID and Secret in ConnectALL

  1. Log into ConnectALL.
  2. Click Connections from the top navigation bar.
  3. Click Add Connection to add a new connection.
  4. Select Authentication type as OAuth.
  5. Enter the Client ID and Client Secret (from ServiceNow) and click Save. The Authorize Credentials screen will be displayed. Note that the Client ID and Secret are required to get the access token. Along with the Client ID and Secret, ServiceNow requires your ConnectALL user credentials (User Name and Password) to get the access token.
  6. Enter the User Name and Password in the Authorize Credentials screen and click Authorize. This is to ensure that a new access token is obtained.

The new connection that you have configured will be displayed in the Manage Connections screen.

Staging Tables

You can use staging tables if you do not want ConnectALL to write directly to the master tables in ServiceNow. (ConnectALL always reads from the master tables, but can optionally write through staging tables if desired). To set up the staging tables, a few configuration changes must be made in the ServiceNow application. You can manually do those changes (with assistance from ConnectALL support), or you can install the ConnectALL plugin which will make these changes for you.

The plugin must be installed in the same server where you have installed ServiceNow. When you install the plugin, it makes all the required changes including the creation of the staging tables and the required roles. The plugin also enables communication between the staging and the master tables (Records posted to a staging table will not be posted to the master table without certain customizations. Additionally, ConnectALL needs the master table record IDs, not the staging table record IDs, so the plugin also allows ConnectALL to work with staging tables).

The custom role that the plugin creates can be assigned to any user and it provides adequate access for ConnectALL. As a result, you don’t have to assign a separate admin role to the userid used by ConnectALL. This plugin sets up staging table support for three entities: Incident, Problem, and Change Request. If you would like to use staging tables for other entities, write to support@connectall.com describing the required configurations.

Enable Staging 

Ensure that the below property is set to true in the ServiceNowTables.properties. Only when it is set to true, the available staging table information will be displayed in the entity mapping dropdown in ConnectALL. 

ca.ServiceNow.staging.enabled=true

Also, please add the below set of keys in ServiceNowTables.properties to use the staging table.

ServiceNow.staging.caid=x_11154_g2g_ConnectALL_id

ServiceNow.staging.fromca=x_11154_g2g_fromca

ServiceNow.fromca=u_fromca

ServiceNow.caid=u_ConnectALL_id

ServiceNow.worknotes.list=u_work_notes_list

ServiceNow.worknotes=u_work_notes

ServiceNow.comments=u_comments



Important: Restart the Tomcat and ConnectALL core services after changing the property configuration.


Entity Mapping

Note: To use staging tables, you have to configure them along with the required transformation as explained above. 

Select a master table and its corresponding staging table to be synchronized. ConnectALL directly reads records from the master table and updates will always go to the staging table. Optionally, the staging table can be set to none when the sync has to happen on a certain master table directly.

Issue Linking Limitation in ServiceNow

When you enable the issue linking option for ServiceNow in an automation, you will notice the below explained behavior:
In a ServiceNow record when you make an individual change that involves creating or modifying dependent stories, the changes will not be updated in the other application when ConnectALL synchronizes that record. On the other hand, if you do any other modifications along with creating or modifying dependent stories, ConnectALL will be able to read all the changes (including creating and modifying dependencies), and the update will reflect the dependent stories modifications as well when the record is synchronized. This is due to a limitation in the ServiceNow application.

Field Mapping

You will be able to map the variables that are defined as variable sets for a specific catalog ID. Note that the field mapping tab will display only the following variable types supported by ConnectALL for a variable set:

  • CheckBox
  • Select Box
  • Single Line Text
  • Multi Line Text
  • Multiple Choice
  • Date/Time
  • Date

If you want to use staging tables, you have to select the corresponding staging table's field configuration. To do that:

  • Click the  icon against that field. The Field Configuration screen is displayed.
  • Select the staging field id from the Value Type dropdown list.

Note: In the below screenshot, u_short_description is the staging field id for the short description master field. Similarly, for all the other fields (except attachments and comments), the staging table field id has to be configured.

Reference Field Mapping

The reference field mapping enables ConnectALL to sync the value of the reference field (of a particular work item that you have mapped). If you do not configure the reference field, the sysID of the reference object will be synchronized instead of the relevant reference field.


ConnectALL allows you to specify which field on the referred-to object will be synchronized to the other application. Click the cogwheel icon against that field, and select the required field from the Field Configuration dialogue box. Considering that the mapped reference field is a drop-down, you should be able to do the value mapping based on the choices for that reference field. 

Comment Field Mapping (supported for all entity types)

Comments syncing can be achieved mapping Work notes and/or Additional comments, with differing results.

The below mapping without any value mapping will sync the work notes from ServiceNow to the other adapter and vice-versa.

The below mapping without any value mapping will sync the public comments from ServiceNow to the other adapter and vice-versa.

For control over comment visibility between Jira and ServiceNow, click on the pencil icon to edit the value mappings and click the "Enable Comment Visibility Value Mapping" box to enable it. After enabling this option, you can provide value mapping for the comment synchronization.

  • *Null      => represents the public comment.
  • *Private => represents the private comment.

Let's look at some common use cases while integrating ServiceNow and Jira. The below use cases explain how comments (public and private) and other variable values are synchronized when you integrate ServiceNow and Jira using the Field Mapping and Advanced Value Mappings.

Use Case 1

  • Sync Public comments from Jira to ServiceNow and vice-versa.
  • Sync Private/Restricted Developers comments to ServiceNow as Private Comment (Work Notes) with work_notes_list or restricted to the users mentioned as below.
  • Other private comments will be skipped for synchronization.
  • The value mentioned in the above table are Developers (Jira role) and users. (adela.cervantsz,aileen.mottern,allan.schwantd) => indicates the user name of the users in ServiceNow.
  • In the case of Jira, the restricted comment can be mapped only to a specific role, whereas the restricted comment or work_notes in ServiceNow can be assigned to multiple users. Therefore, we have mapped a single role ("Developers") in Jira to multiple users (adela.cervantsz,aileen.mottern,allan.schwantd) in ServiceNow or you can map it to a single user also.
  • In the case of multiple users, the usernames should be separated by a comma (,).
    (e.g:
    adela.cervantsz,aileen.mottern,allan.schwantd).


Use Case 2

  • Sync Public comments from Jira to ServiceNow and vice-versa.
  • The ServiceNow Work Notes comments with work_notes_list (adela.cervantsz,aileen.mottern,allan.schwantd) will be skipped (will not be synced to Jira).
  • Other private comments from ServiceNow other than the mapping, will be written as developers comment in Jira.


Use Case 3

  • Sync Public comments from Jira to ServiceNow.
  • Public comments of ServiceNow will be skipped and not synced to Jira.


Use Case 4

  • If you are mapping two ServiceNow instances, if some users are same between these two instances and if you want to retain those users, you can configure the value mapping as shown in the image.


Use Case 5

  • Sync Public comments from Jira as Private comments in ServiceNow.
  • Sync Private comments from ServiceNow as a Public comment in Jira.


Use Case 6 

In an automation between ServiceNow and VSTS, when you have mapped the ServiceNow worknotes and VSTS Comments, here is what happens: 

When you add a comment in VSTS, it will sync as worknotes in ServiceNow. Likewise, If you add a worknote in ServiceNow, it sync’s as Comments in VSTS.

However, If you add a comment in the Additional Comments field in ServiceNow, it will not sync to Comments in VSTS as the field mapping is between Comments of VSTS and worknotes of ServiceNow.

Use Case 7

In an automation between ServiceNow and VSTS, when you have mapped VSTS comments with ServiceNow additional comments, here is what happens:

When you add additional comments in ServiceNow it will sync as Comments in VSTS, and likewise the Comments in VSTS will sync as Additional Comments in ServiceNow.

However, if you add a worknote in ServiceNow it will not sync as Comments in VSTS as the field mapping is between the Comments of VSTS and Additional Comments of ServiceNow.

Use Case 8

Sync Additional Comments from ServiceNow as Public Comments in Jira and
Sync Work Notes in ServiceNow as Internal Comments in Jira


NOTE:

Say you have created an automation between ServiceNow and VSTS, mapping ServiceNow’s Additional Comments, and VSTS’ History.  When you add History in VSTS, it will sync as Additional Comments in ServiceNow. If you change the field mapping on the ServiceNow side to Work notes (instead of Additional Comments) in the automation, and add History in VSTS — it will resync all the existing comments in VSTS as Work notes in ServiceNow.

Automatic User Value Mapping

ConnectALL supports Automatic user value mapping for ServiceNow. Below is a screenshot that illustrates this where:

  • id=User ID
  • name=First name and Last name
  • email=Email

For more information on automatic user value mapping and to find out how it works, click here.

Advanced Configurations

The ServiceNow adapter has an additional properties file for advanced configuration. The following options can be configured in MULE_HOME/conf/ServiceNowTables.properties:

Table name used to test the connectivity to the server:

test.table.on.connect=incident

Load choice values such as status, etc.– in the value mapping screen:

load.choice.values=true

Load reference fields values such as user, groups, etc.– in the value mapping screen:

load.reference.values=true

Add non-task entity(table) in the entity mapping screen:

entity.types=incident, change_request

Staging tables configuration:

If the access to the following master tables are restricted, you can create mapping for its equivalent staging/abstract tables in the following properties file.

 sys_dictionary=staging_dictionary   

 sys_choice=staging_choice

 sys_db_object=staging_db_object

Catalog tables Configuration:

cat.item.id= <sys_id1>,<sys_id2> 

The property cat.item.id has 2 functions:

  • To be able to restrict the variables for field mapping for specific catalog items.
  • To be able to fetch all the variables of these catalog items for field mapping; as the generic API limit is set to 50/100 variables only unless we query for more using expand option.

Configuring Non-task Entities

It is possible to configure non-task entities in the Connection Advanced Properties screen. To configure a non-task entity, 

  1. Navigate to the Manage Connections screen.
  2. Click the cogwheel icon against the connection (in which you want to configure the non-task entity). The Connection Advanced Properties screen will be displayed.
  3. Enter the Property Key and Property Value as shown in the below image. 
  4. Click Save Properties.

*If you want to enter multiple property values, enter the values separated by a comma. 

Features

Test Management 

ServiceNow has the feature for test management where the archival of test cases and test steps along with planning for the test is feasible. ConnectALL works eloquently for this feature in establishing the relationships as expected with its ally application.

The following table permission is required to use the test management feature.

TablesPermission(s)Purpose
sys_dictionaryReadUsed for fetching metadata and field information
sys_choiceReadUsed for fetching metadata and field information
sys_db_objectReadUsed for fetching metadata and field information
sys_glide_objectReadUsed for fetching field datatype information.
sys_journal_fieldRead/WriteUsed for comments sync
ecc_queueRead/WriteUsed for attachments sync
sys_attachmentReadUsed for fetching attachment content
taskReadUsed for fetching metadata and field information
tm_test_suiteRead/WriteUsed to Create/Update a test suite inside the test repository
tm_test_caseRead/WriteUsed to Create/Update a test cases inside the test repository under a given test suite
tm_testRead/WriteUsed to Create/Update a test step inside the test repository under a given test case
tm_test_planRead/WriteUsed to Create/Update a test plan inside the test execution section
tm_test_environmentRead/WriteUsed to Create/Update a test environment details inside the test execution section
tm_test_case_instanceRead/WriteUsed to Create/Update a test cases instances inside the test execution under a given test plan
tm_test_instanceRead/WriteUsed to Create/Update a test step instances inside the test execution under a given test case instance
m2m_tm_test_case_instance_defectRead/WriteUsed to Create/Update a test case defect under a given test case instance's reference

Below are the available task types associated with this feature in the ServiceNow adapter.

In the above screen, among the the task types in the dropdown, TestPlan/Test Plan Test are defined as Test Steps in ServiceNow terms. Every TASK TYPE is considered to be a stand-alone entity and you can map fields as an individual entity accordingly. 

Establishing Parent-Child Relation

ConnectALL can deduce the parent ID (provided mapping for the parent entity is established) and map it with the child entity which is created in ServiceNow Test Management. The below hierarchy depicts the parent-child relationship for the available task types.

As an example — under the test repository, if you have mapped the automations for the test suite and test case respectively, then the test suite ID field is not required to be added in the Field Mapping screen. This will be deduced dynamically and mapped. Below is the sample case where the field is ignored in field mapping.

A similar behavior applies for every parent-child entity, with the thumb rule, that separate automations are created before expecting dynamic linkages.

Mapping Test Suite ID

ConnectALL allows you to map a test suite ID for creating test case Instances inside a test plan. While creating a test plan automation, ConnectALL provides a custom field — "Test Suite Alias" which is always mapped against a constant and advocates only unidirectional support. You can either provide the Test Suite ID (ServiceNow SysId) or the corresponding source application ID for which the mapping is a must in ConnectALL. The below image illustrates it.

In the below screens, the user either directly provides the SYS_ID or the corresponding application's identifier. (Presume that this linkage was established through ConnectALL.)

With the above settings, when the user creates a test Plan, the test cases inside the test suite gets created as new test case instances under the TEST PLAN. (Only the CREATION of TEST CASES are supported.)

Dynamic Creation/Update of Test Steps from Test Cases

When you provide the mapping for the test case, ConnectALL comes up with the provision to map the test steps which is part of every test case. In this case, an exclusive custom field, known as "Test Case Steps" is made available in the list of fields. This field can accommodate a JSON array as an input that is supposed to hold the individual entities of JSON objects which will be Test Name, Test Description, Expected result, and Sequence.

Below is a sample automation between ServiceNow and ALM which is configured to illustrate this feature. 


In this case, the TEST CASE STEPS of ServiceNow is mapped with STEPS in ALM - Where the Steps will return an ARRAY of Test Steps that is deciphered in ServiceNow and recorded accordingly. On top of this, there is a mandatory configuration in the ConnectALL.properties that has to be set to achieve the appropriate synchronization. 

snow.tm.feature.field.test=test,stepName
snow.tm.feature.field.description=test_description,stepData
snow.tm.feature.field.order=order,sequenceId
snow.tm.feature.field.result=expected_result,stepResult

The field names of the source and destination application's test steps are to be added here separated by a comma. This will be verified in the code logic to the respective model object conversion for further processing. In the above example, the property configurations are:

test – ServiceNow Test Step Name | stepName - ALM Test Step Name
test_description – ServiceNow Test Step Description | stepData - ALM Test Step Description
order – ServiceNow Test Step Order | sequenceId - ALM Test Step Sequence
expected_result – ServiceNow Test Step Expected Result | stepResult - ALM Test Step Result

Attachment Synchronization Limitation

Synchronizing attachment as an URL is not supported by the ServiceNow adapter. Say, in an automation between ServiceNow (source) and Jira (destination), when you sync an attachment (as an URL), it will sync as a link to the Jira description field. However, the URL value in the Jira Description field will be displayed as Null.

Timecard Support

For configuring the timecard related synchronization, please refer here.

Time Difference Configuration

To know how to calculate the time difference, and configure it in the ConnectALL UI, read the topic Time Difference Configuration.