ServiceNow integration with any 3rd party tool - Requirements
Import
·
Feb 06, 2019
·
article
Considering any integration to ServiceNow, these basic steps would lay down a foundation for configuring a seamless integration.
The following tabular notation defines the steps to be followed (not exactly in this sequence). As an example, we are just using our 3rd party tool as Workday.
| s no | Name | description |
|---|---|---|
| 1 | Designing the Flow | We design a flow chart from start to end to highlight data flow between Workday and ServiceNow. This stands for a crude idea which is used in every step below. |
| 2 | Configure the Endpoint URL and Authentication | This will be configured at ServiceNow alone or at both ends based on the 3rd party tool complexity. Allowing Workday access to ServiceNow by giving Workday admin credentials in ServiceNow Authentication list. The same way can be done in Workday tool in a vise versa mode. |
| 3 | Explore the communication channel. Inbound and Outbound Web services are decided here from ServiceNow perspective. | Is it a one-way or two-way communication? If it’s one-way, which way it is? Explore Inbound and Outbound web services in ServiceNow to get more details on this aspect. |
| 4 | MID Server Usage | If there is any MID Server involved, the flow will be via MID Server and configurations may differ. |
| 5 | REST Message (or) Scripted REST API | We request the data from Workday (or request within system) and generate response within ServiceNow for any actions to be taken (or send response back to Workday) |
| (5) | Alternatively: SOAP Web services are also can be used instead of REST | We request the data from Workday (or request within system) and generate response within ServiceNow for any actions to be taken (or send response back to Workday) |
| 6 | Script Include | Use this to modify, filter, decide the flow from and to records. You can do anything using script include, which is a way to play with data here |
| 7 | Deciding on the Message structure | The data can be transferred either in JSON or XML format, which are a kind of standardized way of communicating data between two different tools. |
| 8 | Define parameters, attributes, fields etc., if required. | Communication between tools/platforms need to have a common field/variable, if there is any record-based operation exists. So, having a unique ID which exists at both ends will help in GET, POST, PATCH and DELETE methods. Define a unique ID in ServiceNow table from Workday JSON file. Do the same vise-versa if needed at Workday end. |
| 9 | Define the properties | Properties are easy way to give away script control to non-technical users. Provide a property on front end UI and use this property in any script from step 3 |
| 10 | Create Transform Maps | This step decides the mapping of fields from source to destination, use scripts here to calculate necessary fields. Run this transform once and use this forever whenever you need live-records to be in sync. |
| 11 | Create Scheduled Jobs | These jobs use the mapping assistance from step 10 and will be scheduled periodically or on-demand |
| 12 | Automated Test Framework | You can use ATF, the automated test framework to test success or failure in an automated way for all your records once the integration is setup. RESTful Automated Test Framework is the way we do here. |
| You will get more deeper understanding on the above if you have a hands-on on any integration. My suggestion would be go for: 1. Postman to ServiceNow and vise-versa 2. ServiceNow to ServiceNow one-way communication |
|---|
If this benefits someone and needs more explanation on each step, I can start preparing those. Thank you for reading out.
Regards,
Akash
Labels:
View original source
https://www.servicenow.com/community/developer-articles/servicenow-integration-with-any-3rd-party-tool-requirements/ta-p/2322744
