Test CreateIncidentInbound
Follow these instructions to test the CreateIncidentInbound Message.
Follow these instructions to test the CreateIncidentInbound Message.
In your PDI, navigate to Incident > Create New.
The Incident fields to configure are as follows:
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.
You should now have a non-bonded ticket in the remote instance (assigned to <Your Assignment group>):
In Unifi Integration Designer, click on the 'Pollers' icon. Navigate to & open < Your Create Poller > (created on the 'Poller' page of the Incident Create Poller Guide). & click Execute Now:
In native ServiceNow, navigate to Unifi > Polling > Poll Requests. Click to Open & view the generated Poll Request. Confirm that only the one Incident was 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.
Navigate to Unifi > Transport > Transactions.
We can see the CreateIncidentInbound message has been received. It is Complete & Accepted and displays the relevant Incident & Bond numbers.
Confirm the following:
The Transaction has created the bonded ticket in this instance.
Your 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).
Your originating Incident should look like this:
Next, we shall test the UpdateIncidentInbound Message.