ConnectALL interacts with ServiceNow via its ReST API.
Other entities - Check here for advanced configurations
Issue Linking – Issue Linking is supported for the entity types such as Incident, Problem, Change Request, Epic, Defect, and Enhancement (from the version 2.10.2).
Sync Staging & Master Tables
Sync Standard & Custom Fields
Sync Service Catalog
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.
|incident_manager||Required for Incident and Problem entity|
|change_manager||Required for Change Request entity|
|personalize_choice||Required if ConnectALL's plugin* is NOT installed|
|x_11154_g2g.caadmin||Required if ConnectALL's plugin* is installed. By assigning this role, the above three roles will be automatically assigned to the user. Hence, 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.
|sys_dictionary||Read||Global/ConnectALL||Required if the ConnectALL plugin* is NOT installed|
|sys_dictionary.*||Read||Global/ConnectALL||Required if the ConnectALL plugin* is NOT installed|
|sys_glide_object||Read||Global/ConnectALL||Required if the ConnectALL plugin* is NOT installed|
|sys_glide_object.*||Read||Global/ConnectALL||Required if the ConnectALL plugin* is NOT installed|
Required if the ConnectALL plugin* is either installed or not installed
|Read||Global/ConnectALL||Required 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.
Configure Application Link
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.
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
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
- Navigate to System OAuth>Application Registry. The Application Registries screen will be displayed.
- Click New.
- 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
- Log into ConnectALL.
- Click Connections from the top navigation bar.
- Click Add Connection to add a new connection.
- Select Authentication type as OAuth.
- 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.
- 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.
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.
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.
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
Use Case 2
Use Case 3
Use Case 4
Use Case 5
Use Case 6
In an app-link 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 app-link 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
Say you have created an app-link 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 app-link, 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
For more information on automatic user value mapping and to find out how it works, click here.
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:
Load choice values such as status, etc.– in the value mapping screen:
Load reference fields values such as user, groups, etc.– in the value mapping screen:
Add non-task entity(table) in the entity mapping screen:
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.
Catalog tables Configuration:
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.
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.
|sys_dictionary||Read||Used for fetching metadata and field information|
|sys_choice||Read||Used for fetching metadata and field information|
|sys_db_object||Read||Used for fetching metadata and field information|
|sys_glide_object||Read||Used for fetching field datatype information.|
|sys_journal_field||Read/Write||Used for comments sync|
|ecc_queue||Read/Write||Used for attachments sync|
|sys_attachment||Read||Used for fetching attachment content|
|task||Read||Used for fetching metadata and field information|
|tm_test_suite||Read/Write||Used to Create/Update a test suite inside the test repository|
|tm_test_case||Read/Write||Used to Create/Update a test cases inside the test repository under a given test suite|
|tm_test||Read/Write||Used to Create/Update a test step inside the test repository under a given test case|
|tm_test_plan||Read/Write||Used to Create/Update a test plan inside the test execution section|
|tm_test_environment||Read/Write||Used to Create/Update a test environment details inside the test execution section|
|tm_test_case_instance||Read/Write||Used to Create/Update a test cases instances inside the test execution under a given test plan|
|tm_test_instance||Read/Write||Used to Create/Update a test step instances inside the test execution under a given test case instance|
|m2m_tm_test_case_instance_defect||Read/Write||Used 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 app-links 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 app-links 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 application link, 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 application link 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.
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 app-link 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.
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.