Test Create Poll
You should have successfully configured a Poll Processor and Poller. You should also have configured an inbound create type Message and its outbound receipt. Follow these steps to test.
It may help to turn off the Poller we created (set Active to 'false') whilst conducting these tests and to manually execute it as required (this can still be done even if the Poller is inactive). This is so that we don't have to wait for the Poller to run, but rather manually activate it when needed by clicking 'Execute Now'.
To turn off the Poller, in the Unifi Integration Designer window, navigate to the 'Pollers' icon & set Active to false.
In order to test our Integration we will need to create test Incidents in the remote instance.
In your PDI, navigate to Incident > Create New.
The Incident fields to configure are as follows:
Field | Description | Value |
|---|---|---|
Caller | Person who reported or is affected by this incident. | <Your Caller> |
Impact | Measure of the business criticality of the affected service. | <Your Impact> |
Urgency | The extent to which resolution of an incident can bear delay. | <Your Urgency> |
Assignment group* | The group to which the ticket is assigned. | <Your Assignment group> |
Short description | A brief description of the incident. | <Your Short description> |
Description | Detailed explanation on the incident. | <Your Description> |
*Assignment group: This should be the group you created in your PDI to enable Unifi to identify which newly created, non-bonded tickets to poll and whose sys id was stored in a connection variable and passed into the Setup Script of the Poll Processor.
Your Incident form should look like this:
Note the values entered (including State), so that you can check them against the mapped fields on the corresponding record in the instance being integrated to.
Repeat the above steps, this time choosing a different Assignment group.
Your Incident form should look like this:
Repeat the above steps for a third time, this time leaving Assignment group (empty).
Your Incident form should look like this:
Repeat the above steps for a fourth time, again setting the Assignment group to <Your Assignment group> (as per Step 4 in the table above).
Your Incident form should look like this:
You should now have at least four non-bonded tickets in the remote instance (two of which are assigned to <Your Assignment group>):
In Unifi Integration Designer, click on the 'Pollers' icon. Navigate to & open < Your Poller > (created earlier). & click Execute Now:
In native ServiceNow, navigate to Unifi > Polling > Poll Requests. Click to Open & view the generated Poll Request. Confirm that only the two Incidents were found (this is exactly as we expect because we are only polling for Incidents assigned to a specific Assignment group):
View the Transactions that have been sent. This can be done either in Native ServiceNow, or in Unifi Operations Manager.
Native ServiceNow
Unifi Operations Manager
Navigate to Unifi > Transport > Transactions.
Navigate to Unifi > Unifi Operations Manager.
We can see that two CreateIncidentInbound message has been received. They are Complete & Accepted and display the relevant Incident & Bond numbers.
For each Transaction, confirm the following:
The Transaction has created the bonded ticket in this instance.
First New Incident
Second New incident
Your first new Incident should look like this:
Your second new Incident should look like this:
The calller_id was populated with the default value
gs.getUserID() because the table API was returning display_value instead of value. If the Create Poller was active and running then the caller_id would be the Integration User. Because the Create Poller was manually executed whilst inactive, then the value is the user who executed the poll.The Transaction has updated the bonded ticket in the remote instance (your PDI) (with the correlation id).
First Originating Incident
Second Originating Incident
Your first originating Incident should look like this:
Your second originating Incident should look like this:
For completeness, to prove we are only querying and pulling back data from non-bonded records, create an incident in this instance which causes the outbound CreateIncident Message to fire - as per the Outbound Incident Guide - (creating a new Incident in the remote instance) & run the Poller again.
What do you expect to happen?
Last modified 4mo ago