Bidirectional Asynchronous Incident Guide
Follow this guide to configure a bidirectional asynchronous integration to the Incident table. This push-push integration will use Unifi both ends.
Welcome
Congratulations on your decision to use Unifi, the only integration platform you need for ServiceNow. We are sure you will be more than satisfied with this extremely powerful, versatile and technically capable solution.
Scope
We have created this Guide as an aid to customers who are beginning their journey in deploying the Unifi integration platform. This document will guide you through an example of how to configure a bidirectional asynchronous Incident integration, sending and receiving messages via the Scripted REST Service.
This guide is here to help you get up and running as quickly as possible, enabling you to realise the enormous benefits to be gained when using Unifi to configure your integration.
For more technical information on how to use Unifi, please see our technical documentation.
Warning
Do not build integrations directly within the Unifi application scope. This can create issues with upgrades and application management.
Guide Structure and Testing Approach
As with the previous release, the vast majority of the configuration is carried out in Unifi Integration Designer (our portal interface) - Processes, Integrations, Connections, Messages, Fields & Field Maps. Although there are many other elements which are configurable in the portal, they fall outside the scope of this document. For the purpose of this Guide, the remaining configuration elements are the Web Service & Trigger. These are to be configured in native ServiceNow as before.
We could have chosen to deal with those elements configured in the portal first & then move on to those configured in native ServiceNow. Instead, however, we have structured this Guide to align with the testing approach. Firstly, we shall configure the main elements which have to be in place for the Integration to work (Process, Web Service, Integration, Connection, Trigger), then we shall move on to build & test each of the scenarios individually. For example, build the CreateIncident Message (along with CreateIncidentReceipt & Response), configure the relevant Fields for those Messages and then test the CreateIncident Message. Then do the same for the UpdateIncident Message (& Receipt) and so on.
Some Dos & Don’ts
We want to include some advice on things to be aware of - either to ensure you do them, or avoid doing them - when building & testing Unifi integrations; in particular and especially if many people are building in one instance at the same time (whether that be a training instance or sub-production instance).
Make sure your Process API name is unique, otherwise use an existing Process.
Make sure your SOAP and/or REST endpoints are also unique.
When setting up a Connection:
Never use your own User as the Inbound User as it will prevent the integration from working.
Always ensure that your Inbound User is NOT used by anyone else for the same Process i.e. if you’re creating a Connection for an Integration on the Incident Process, your Inbound User has to be the only User used by an Integration within that Process.
When configuring a Trigger (Business Rule) on a table to be integrated, make sure one doesn’t exist already. If you have more than one, you will make duplicate updates.
Installation
The prerequisite to configuring Unifi is to have it installed on your instance. As with any other ServiceNow scoped application, Unifi must be purchased via the ServiceNow Store before installation.
We recommend you follow the Setup instructions prior to configuring your Integration.
SetupLast updated