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
All of the configuration is carried out in Unifi Integration Designer (our portal interface) - Processes, Integrations, Connections, Messages, Fields & Field Maps are configured manually. The remaining configuration elements (Web Service & Trigger) - which were previously configured in native ServiceNow - are automatically created by Unifi.
Automatic creation of the Trigger (Busines Rule) and Web Service (REST Method) make configuring Integrations even easier and more efficient than ever before.
The Trigger (Business Rule) is automatically created (if one doesn't already exist) when you run 'Build' either on the Integration or Message once your Create Message is configured.
The Web Service (REST Method) is automatically created when the Process is configured.
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, 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.
There is no need for you to manually create a Trigger (Business Rule) on a table to be integrated if one doesn’t exist already. Unifi will automatically create one. If you have more than one, you will make duplicate updates.
There is no need for you to manually create a Web Service. Unifi will automatically create one when the Process is configured.
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.
Last updated