Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Follow this fifth Poller Guide to configure an integration, polling the attachment API of your PDI for attachments in two stages - an initial light poll which passess data to a more detailed poll.
We will again be configuring two Pollers and two Poll Processors acting as parent and child. This time, we will use them to pull attachments from bonded records on an external instance, pass the relevant data between them and then pass the attachments to Unifi. We will then configure the relevant inbound Message in order to process those attachments.
The relevant pages for configuring those records are:
If you have been following along with the Outbound Incident Guide and each of the previous Poller Guides you will know that they are given as examples of how you might configure such integrations. They are not meant to be prescriptive. The same applies here.
Having said that, this Guide has been written to follow on from those previous ones and has been structured accordingly.
Because we are building on previously configured elements we may need to go back and edit some of them to facilitate polling both the table & attachment APIs. Full instructions can be found at the appropriate time on the following pages of this guide:
Edit Endpoint URLs (only applies if you have used the full endpoint url in the Connection)
Edit Child Poll Processor (requiresd)
Edit Child Update Poller (required)
This document will guide you through an example of how you might configure a parent and child poller integration - polling the Attachment API of your Personal Developer Instance (PDI).
This Guide is complementary to the Outbound Incident Guide. It assumes that both the Integration and the Connection are still in place and will be using those same elements as configured there (although we may need to edit the Connection). It also assumes that you know how to use the REST API of your PDI to query for information and read ticket data.
If you haven't completed the Outbound Incident Guide, please review & complete the following sections of that document, as some must be in place before continuing with this Guide:
These elements are required to be in place for this integration to work:
Connection (may require editing to facilitate polling different APIs)
These elements are not required to poll for attachments, but depending on how you have configured them, they may need to be edited to facilitate polling different APIs (& will be utilised when testing our integration):
This document builds on the Incident Update Poller Guide. As such, it assumes that the changes made in that Guide are still in place and will make use of some of those same elements.
If you haven't completed the Incident Update Poller Guide, please review & complete the following sections of that document at least, as they must be in place before continuing with this Guide:
Although not required to poll for attachments, these elements will be utilised when testing our integration:
This document makes use of elements configured in the Incident Multiple Message Poller Guide. It assumes that the changes made in that Guide are still in place.
If you haven't completed the Incident Multiple Message Poller Guide, please review & complete the following sections of that document at least, as they must be in place before continuing with this Guide:
Although not required to poll for attachments, if you have configured them, these elements will be utilised when testing our integration:
This document will also make use of elements configured in the Incident Create Poller Guide. It assumes that the changes made in that Guide are still in place (although we may need to edit the Poll Processor & any outbound messages).
If you haven't completed the Incident Create Poller Guide, please review & complete the following sections of that document at least, as they must be in place before continuing with this Guide:
Although not required to poll for attachments, if you have configured them, these elements will be utilised when testing our integration (and some may need to be edited to facilitate polling different APIs):
This document also builds on the Incident Parent and Child Poller Guide. It assumes that the changes made in that Guide are still in place and will make use of some of those same elements (although we will need to edit both the Child Poll Processor & Child Poller).
If you haven't completed the Incident Parent and Child Poller Guide, please review & complete the following sections of that document at least, as they must be in place before continuing with this Guide:
Although not required to poll for attachments, these elements will be utilised when testing our integration (and some may need to be edited to facilitate polling different APIs):
Child Poll Processor (requires editing)
Child Poller (requires editing)
The Incident Parent and Child Poller Guide demonstrated how you might poll for updates from the table API of your PDI, but poll in two stages - an initial light poll, periodically scanning for updated records and a subsequent, on-demand poll, pulling back more detail from the relevant records and deciding how to process that data with the relevant inbound Messages. We will edit the Child Poll Processor so that it also kicks off another on-demand poll, scanning for attachments.
This guide will also demonstrate polling in two stages - an initial, on-demand poll, scanning for attachments added to bonded records and a subsequent, on-demand poll, that takes each of the attachments and passes them to Unifi to process.
The initial, on-demand poll (for attachments) will be kicked off by the edited Child Poll Processor.
It is not always possible for a remote system to send us the data. In such cases, we can make a scheduled request for it using Pollers. We can setup, execute and process those Requests using Poll Processors.
A poller defines the frequency of polling and which logic to use. It is effectively a scheduled job which ties together an Integration and Poll Processor. Although a Poller belongs to only one Integration, an Integration can have multiple Pollers.
A Poll Processor contains the logic that will be applied when polling a remote system for data. It contains three main scripts:
The Setup Script is used to build the environment for the poll and define what it will do (for example, create/setup the URL that will be called).
The Request Script is used to reach into the remote system and execute the request. This is usually done by making a REST call to the URL defined in the Setup Script.
The Response Script is used to process the information returned from the remote system.
Do not build integrations directly within the Unifi application scope. This can create issues with upgrades and application management.
We will be utilising the previously configured Parent & Child Pollers as follows.
The first (Parent) Poll Processor will pull back a list of the relevant records (polling enough data to identify the records). Each record it identifies will be passed on to a second (Child) Poll Processor which will then make a fuller Poll Request against that record and process it deciding between multiple Messages in Unifi.
As well as storing and checking some returned data in order to evaluate when the data was changed and which system has made the updates (we don't want to pull back data we have changed), this Child Poll Processor will also need to store and check other data in order to decide which Message to use to process that data. We will also edit it so that it will kick off the initial, on-demand Poller to scan for attachments.
There is no obligation to utilise the previously configured Parent & Child Pollers in order to poll for attachments. We have chosen to do so as a convenient way to demonstrate polling for attachments at the same time as polling for updates (which would be a likely use case).
The two new Parent & Child Pollers will be configured as follows.
The first (Parent) Poll Processor will scan for and identify any attachments added to bonded Incidents - passing details to the second (Child) Poll Processor, which will retrieve each attachment - building a payload & passing it to Unifi to process.
To facilitate being able to poll both the Table API and Attachment API you may need to edit the Endpoint URLs in the Connection & previously configured Poll Processors (as well as editing the Outbound Message Path for previously configured Outbound Messages).
NOTE: This only applies If you have used the full Endpoint URL in the Connection.
We have previously been polling the Table API of our PDI. We now want to poll the Attachment API. To facilitate this, we will need to make changes to the Endpoint URLs in multiple places.
The instructions on this page only apply if you have configured the Connection with the full endpoint url (including the /table/incident
element).
If you have used the truncated url in the Connection (moving the /table/incident
element to the outbound Message path & Poll Processors), this page may be skipped.
To facilitate polling both the Table API and Attachment API, we will need to edit the Endpoint URLs configured in earlier Guides in the following places:
Connection
Outbound Message Path
Previously Configured Poll Processors
First, edit the Endpoint URL in the Connection.
In Unifi Integration Designer, navigate to the 'Connections' icon. Click to open & edit < Your Connection > (configured following the Outbound Incident Guide).
Remove /table/incident
from the Endpoint URL and Save. (This will be prepended to the Outbound Message Path & previously configured Poll Processors.)
Edit each of the previously configured Outbound Messages:
CreateIncident
UpdateIncident
ResolvIncident
CreateIncidentInboundReceipt
To edit the CreateIncident Message, navigate to the 'Messages' icon & click to open the CreateIncident Message.
Navigate to Outbound > Settings. Add the previously cut /table/incident
to the Path & Save.
Repeat for each of the other Outbound Messages.
DO NOT delete the existing path, rather prepend it with /table/incident
(as cut from the Connection). For example, the Path for the UpdateIncident Message should now read as follows: /table/incident/{bond.getValue("external_reference")}
.
Edit the Endpoint URL in the Setup script for each of the previously configured Poll Processors:*
*(The names of your Poll Processors may differ.)
Unifi - SN REST Poll Processor (as configured in the 'Poll Processor' page of the Incident Update Poller Guide
Unifi - SN REST Poller with Incident DataStore (as configured in the 'Poll Processor' page of the Incident Multiple Message Poller Guide)
Unifi - SN REST Create Poll processor (as configured in the 'Poll Processor' page of the Incident Create Poller Guide)
Unifi - SN REST Poller Single incident (as configured in the 'Child Poll Processor' page of the Incident Parent and Child Poller Guide)
Unifi - SN REST Poller Incident List (as configured in the 'Parent Poll Processor' page of the Incident Parent and Child Poller Guide)
Note: Although it is necessary to edit the Endpoint URL for all of the previously configured Poll Processors for each of them to work, it is only essential (for the purposes of this Guide) that this is done for the Parent and Child Poll Processors and the Create Poll Processor as these will be used when testing our Integration (& the Messages).
To edit the Unifi - SN REST Poll Processor, navigate to the 'Poll Processors' icon & click to open the Unifi - SN REST Poll Processor.
Navigate to Scripts > Setup Script.
Edit the code by prepending the existing Endpoint URL with /table/incident
i.e. insert it immediately after the poll_request.endpoint_url += '
value & click Save. That line of code should now read as follows:
Your Unifi - SN REST Poll Processor Setup Script should now look like this:
Repeat for each of the other previously configured Poll Processors.
Once complete we can configure the first of our Child Poll Processors, the Get Attachment Poll Processor.
A Poller is a configuration record which defines the frequency of polling and which logic to use.
A Poller is a configuration record which defines the frequency of polling and which logic to use (the logic itself is defined in the Poll Processor). Each time it is run, it creates a corresponding Poll Request record.
Click the 'Pollers' icon & then New.
The fields to be configured for our Poller record are as follows:
*These fields are mandatory, or automatically defaulted to true.
Your New Poller modal should look like this:
5) Submit and view to further configure the Poller.
The fields to be configured for the Details form are as follows:
Your Details form should look like this:
7) Save the Poller.
Update the value of the 'get_attachment_poller' Connection Variable with the sys_id.
8) Click on the Hamburger Menu and select Open in platform.
The Poller opens in a new window.
9) Right-click the Header & 'Copy sys_id'.
Next, we will configure the Select Attachments Poll Processor.
A Poller is a configuration record which defines the frequency of polling and which logic to use.
A Poller is a configuration record which defines the frequency of polling and which logic to use (the logic itself is defined in the Poll Processor). Each time it is run, it creates a corresponding Poll Request record.
Click the 'Pollers' icon & then New.
The fields to be configured for our Poller record are as follows:
*These fields are mandatory, or automatically defaulted to true.
Your New Poller modal should look like this:
5) Submit and view to further configure the Poller.
The fields to be configured for the Details form are as follows:
Your Details form should look like this:
7) Save the Poller.
Update the value of the 'select_attachments' Connection Variable with the sys_id of the child Poller.
8) Click on the Hamburger Menu and select Open in platform.
The Poller opens in a new window.
9) Right-click the Header & 'Copy sys_id'.
Next, we will edit our previously configured Child Poll Processor so that it becomes the parent of this.
Connection Variables can be especially useful if you have multiple connection environments - e.g. Dev, Test, Prod - each containing different data.
Although having multiple environments may not apply to this integration, we will create Connection Variables to contain certain data values which will be substituted into the Poll Processor scripts.
Instead of scripting data values directly into the code of your Poll Processor scripts, it may be better practice to use Connection Variables in their place. Not only does it make those scripts cleaner, but it also means that changes in requirements can be more easily enacted by changing the values of the data in those variables, without having to change the code in the scripts.
We will create an additional two Connection Variables to identify the Child Pollers we shall be creating.
Before continuing we would like to draw your attention to some of the relevant icons that will be visible down the left hand navigation strip in Unifi Integration Designer.
The icons are:
a) 'Integration' icon: Opens the current integration's Details page.
b) 'Pollers' icon: Opens the current integration's Pollers page.
c) 'Poll Processors' icon: Opens the current integration's Poll Processors page.
d) 'Connections' icon: Opens the current integration's Connections page.
To open Unifi Integration Designer, navigate to Unifi > Unifi Integration Designer, then navigate to < Your Integration > (created following the Outbound Incident Guide).
Click the 'Connections' icon, then navigate to and open < Your Connection >.
From the Connection, navigate to Connection > Variables & click New.
The 'get_attachment_poller' New Connection Variable fields to be configured are as follows:
*Value may vary. Use the sys_id of the Poller you will create from the Get Attachment Poller page.
Your 'get_attachment_poller' New Connection Variable modal should look like this:
4) Click Submit.
You will be redirected back to the Variables page of the Connection record.
From the Connection, navigate to Connection > Variables & click New.
The 'select_attachments_poller' New Connection Variable fields to be configured are as follows:
*Value may vary. Use the sys_id of the Poller you will create from the Select Attachments Poller.
Your 'select_attachments_poller' New Connection Variable modal should look like this:
8) Click Submit.
The following Connection Variables should now be in place for your Connection:
Now let's move on and edit the Endpoint URLs.
Our previously configured Child Poll Processor only polled for updates against records passed to it from its Parent. We will now edit it so that it will also kick off the Select Attachments Poller.
Rather than just making edits to the existing Child Poll Processor, we will instead copy it & edit the copy. That way we will have one Child Poll Processor that just polls for updates and another that polls for updates and attachments.
To copy the Child Poll processor, in Unifi Integration Designer, click the 'Poll Processors' Icon.
2) Click Copy.
Your Copy Poll Processor modal should look like this:
You will be redirected to the Details page of the newly copied Poll Processor.
The fields to edit for the Copied Poll Processor are as follows:
*Name: We've chosen to append the existing value with, "(with Attachments)".
Your Copied Poll Processor should look like this:
4) Navigate to Scripts > Response Script.
The Response Script field is to be edited as follows:
The code in the Response script field should look like this:
Response script: This script creates a variable to store a time based high water marker and parses the response into a body object to contain the result, (returning if it doesn't contain anything).
It then establishes the environment, getting the Integration, Configuration, Connection & Connection Variables and sets up the essential PollHelper() function (which we initialise from the poll_request) along with the info [] array.
After that it sets up some other functions: get_bond()
finds the bond for the Incident (returning if there isn't one), get_message_name()
works out the message type to send to Unifi based upon the change of state & execute_child_poller()
sets up a Poll Request to check for new attachments.
It then processes each of the results (passed in tickets). For each, it logs the incident number & time, finding the bond & returning any previous data stored on the bond, deciding which Message to use, setting up a payload object and submitting it to Unifi by calling the processInbound()
method. It then runs the execute_child_poller()
function and saves the current incident as the previous incident for the next poll & checks whether the ticket was updated later than the last update time; if so, it sets and stores the last update time as that ‘sys_updated_on’ value (this ‘last_update_time’ is what the Setup script checks against when defining what the Poll will do).
On processing each result, it is then logged to the Response status field of the Poll Request.
params: The params
object is passed through to the subsequent scripts (and on to further Pollers, if required). This is used to pass the int_ref, ext_ref & attachment_hwm elements to the child Poller.
Code Edits - The following code snippets were added to the existing codebase to facilitate polling for attachments:
This is a DataStore name constant to store a time based high water mark.
Causing the execute_child_poller() function to run (as set up above) - passing in the Incident & Bond.
Your Response Script form should look like this:
6) Click Save.
Remember, We have not scripted any business logic to run from the value in the Parent field. It is given for documentary purposes only (for you to easily identify which parent Poll Processor kicked off the child).
The following Poll Processors should now be in place on the Integration:
We could Deactivate the copied "Unifi - SN REST Poller Single Incident" now that we've created this version, "with Attachments". However, we will instead edit the Child Update Poller that runs it.
Now let's move on and edit the Child Update Poller (configured when following the Incident Parent and Child Poller Guide) so that it runs the Poll Processor created above.
We will configure an on-demand poll to query the remote system and pull back a list of attachments added to bonded records that have changed. Each will then be retrieved by another on-demand poll.
To set up an on-demand poll that will query the remote system for attachments and pass each to a subsequent poll, which will then retrieve them and pass them to Unifi to process, we will need to configure a further two each of the following records:
Child Poll Processor
Child Poller
(Note: one of the children will be a parent to the other)
We will also need to edit the previously configured (per the Parent & Child Poller Guide) to kick-off the first of our attachment Child Pollers.
To facilitate polling both the Table API and Attachment API, we may also need to make changes to the Endpoint URLs* configured in earlier Guides in the following places: (*only if the Connection contains the full endpoint url)
Connection
Outbound Message Path
Poll Processor Setup Script
We will look at each of those edits and the polling records in turn over subsequent pages. Before configuring those records, let’s first look at Connection Variables.
Open the variable created on the '' page of this Guide and update the value with the copied sys_id.
Open the variable created on the '' page of this Guide and update the value with the copied sys_id.
This variable will contain the sys_id of the child Poller which we will create on the '' page of this Guide. Once you have created the Poller, copy the sys_id and paste it as the value in this variable.
This variable will contain the sys_id of the child Poller which we will create on the '' page of this Guide. Once you have created the Poller, copy the sys_id and paste it as the value in this variable.
1) Click the ellipsis to the right of < Your Child Poll Processor > (created following the ) & then click Copy.
The x_snd_eb.Poller.execute() method has two parameters. In the first we pass the sys_id of the child Poller (as created on the '' page). In the second we pass an object containing the correlation_id on the bonded Incident as the int_ref element, the sys_id of the bonded Incident as the ext_ref element and the value of the ATTACHMENT_HWM DataStore as the attachment_hwm element (telling the child Poller which attachment records to poll).
Navigate to and open the Select Attachments Poll Processor (created on the ' page) and update the value of the Parent field by selecting its parent Poll Processor created above.
# | Field | Description | Value |
6 | Description | A description of what this Poller is for and/or how it works. | <Your description> |
# | Field | Description | Value |
6 | Description | A description of what this Poller is for and/or how it works. | <Your description> |
# | Field | Description | Value |
1 | Key | A unique name that will be used to get the value. | 'get_attachment_poller' |
2 | Value | The variable value to be used in the integration. | <Your Value>* |
3 | Description | Describe what this connection variable is for and how it should be used. | <Your Description> |
# | Field | Description | Value |
5 | Key | A unique name that will be used to get the value. | 'select_attachments_poller' |
6 | Value | The variable value to be used in the integration. | <Your Value>* |
7 | Description | Describe what this connection variable is for and how it should be used. | <Your Description> |
# | Field | Description | Value |
3 | Name | The name of the Processor. | <Your Name>* |
# | Field | Description | Value |
5 | Response Script | The script that processes the response to the request. | Update the code in the Response script field so that it looks like the code below |
We will need to configure a new inbound Message to process the attachments returned from the poll. We may also utilise all the previously configured Messages in testing our Integration.
In order to process the attachments returned from the remote system we will configure a new inbound Message.
AddAttachmentInbound
If you have edited the Endpoint URLs in the Connection, the Create Poll Processor and the Parent & Child Poll Processors, it will be necessary to utilise the Messages we created in the earlier Guides in order to test the Integration and process the data that is returned from the remote system. The following Messages will be used:
CreateIncidentInbound
UpdateIncidentInbound
ResolveIncidentInbound
CreateIncidentResponse
For the same reason as above and if you have edited the outbound Message Path for the previously configured Messages, it will be necessary to test those also. The following Messages will be used:
CreateIncident
UpdateIncident
ResolveIncident
CreateIncidentInboundReceipt
Let's now configure the AddAttachmentInbound Message.
# | Field | Description | Value |
1* | Name | The name of your Poller. | <Your Name> |
2* | Poll processor | The Poll Processor to use when running this Poller. | <Your Poll Processor> |
3 | Run | The frequency at which the Poller should run. | 'On Demand' |
4 | Run as | Poller will run with credentials of specified user. | <Your Inbound user> (from Connection) |
* | Active | Set to true to use this Poller record for processing. | <true> |
# | Field | Description | Value |
1* | Name | The name of your Poller. | <Your Name> |
2* | Poll processor | The Poll Processor to use when running this Poller. | <Your Poll Processor> |
3 | Run | The frequency at which the Poller should run. | 'On Demand' |
4 | Run as | Poller will run with credentials of specified user. | <Your Inbound user> (from Connetion) |
* | Active | Set to true to use this Poller record for processing. | <true> |
The Poll Processor contains the logic that will be applied when polling a remote system for data.
The Poll Processor is a configuration record which contains the logic that will be applied when polling a remote system for data. There are three main scripts which are used to setup, execute and process the Poll Requests. The scripts given here are examples of how you might configure your Poll. The details of yours may differ depending on your requirements.
This Select Attachments Poll Processor will pull back a list of the relevant attachment records. Each record it identifies will be passed on to its child - Get Attachment Poll Processor.
In Unifi Integration Designer, navigate to & open < Your Integration > (created following the Outbound Incident Guide).
Click the 'Poll Processors' icon & then New.
The fields to be configured for the New Poll Processor modal are as follows:
Your New Poll Processor modal should look like this:
'Parent' - Once we have created its Parent Poll Processor, we can then select it here. We have not scripted any business logic to run from the value in this field. It is given for documentary purposes only.
2) Submit and view to further configure the Poll Processor.
The Setup Script is the first script to run (it runs at the point in time the Poll Request is created). It is used to build the environment for the poll and define what it will do. We will use it to setup the URL that will be called.
Navigate to Scripts > Setup Script.
The initial Poll Processor fields to be configured are as follows:
The code in the Setup script field should look like this:
Setup script: The parameters for which data to return are contained in the endpoint url.
query: Instead of querying all the attachments on the remote instance, we deliberately limit the query to those where the table_sys_id (target record) is the sys_id of a bonded Incident (passed in from the Response script of its Parent Poll Processor), that haven't been updated by the Authentication user (our system) and that were updated either since the last update time (if one exists), or in the last 30 minutes.
Endpoint URL: The value used in the poll_request.endpoint_url was initially generated using the ServiceNow REST API Explorer, substituting a variable in for the uri query. This value is appended to the existing endpoint url in the active connection before being added to the Poll Request.
(We have also chosen to limit the number of records returned to 10.)
Your Setup Script form should look like this:
4) Navigate to Request Script.
The Request Script is used to reach into the remote system and execute the request. We will use the ServiceNow RESTMessageV2() web service to make a REST call to the URL defined in the Setup Script.
The next Poll Processor field to be configured is as follows:
The code in the Request script field should look like this:
Request script: This script uses the ServiceNow RESTMessageV2() web service to make a REST call to the endpoint url created in the Setup script. It returns the body of the request as the answer which it passes to the Response script
Your Request Script form should look like this:
6) Navigate to Response Script.
The Response Script is used to process the information returned from the remote system. We will use it to build an attachment object to pass this data to the next Poll Processor.
The last Poll Processor field to be configured is as follows:
The code in the Response script field should look like this:
Response script: This script creates a variable to store a time based high water marker and parses the response into a body object to contain the result, (returning if it doesn't contain anything).
It then establishes the environment, getting the Integration, Connection & Connection Variables and sets up the essential PollHelper() function (which we initialise from the poll_request) along with the info [] array.
After that it finds the bond for the Incident (returning if there isn't one) & then processes each of the results (returned attachment records). For each, it builds an attachment object and sets up a Poll Request to retrieve & process the remote attachment (returning a PollRequest object). It also tracks the latest sys_created_on time.
After processing each result, the script checks whether the attachment was created later than the latest attachment high water mark; if so, it sets and stores that 'sys_created_on' value as the attachment high water mark (the 'attachment_hwm' is what the Setup script checks against when defining what the Poll will do). The results are then logged to the Response status field of the Poll Request.
x_snd_eb.Poller.execute(): This method has two parameters. In the first we pass the sys_id of the child Poller (as created in the 'Get Attachment Poller' page). In the second we pass an object containing the correlation_id on the bonded Incident as the int_ref element, the sys_id of the bonded Incident as the ext_ref element and the attachment object as the attachment element (telling the child Poller which attachment record to poll).
params: The params
object is passed through to the subsequent scripts (and on to further Pollers, if required). This is used to pass the int_ref, ext_ref & attachment elements to the child Poller.
Your Response Script form should look like this:
8) Save the Poll Processor.
Navigate to and open the Get Attachment Poll Processor (created on the 'Get Attachment Poll Processor' page) and update the value of the Parent field by selecting its parent Poll Processor created above.
Remember, We have not scripted any business logic to run from the value in the Parent field. It is given for documentary purposes only (for you to easily identify which parent Poll Processor kicked off the child).
Now let's move on and configure the Select Attachments Poller.
We will configure another inbound update type Message to process the attachment data returned from the poll and update our target record.
Click on the 'Messages' icon to open the Messages page. Click New.
The fields to be configured for the AddAttachmentInbound New Message modal are as follows:
Your AddAttachmentInbound New Message modal should look like this:
5) Click Submit and view to further configure the Message.
Navigate to Message > Response.
The Response fields to be configured are as follows:
*This field is automatically defaulted to true.
Your Response form should look like this:
8) Navigate to Message > Bond.
The Bond fields to be configured are as follows:
*These fields are automatically populated.
Your Bond form should look like this:
11) Navigate to Inbound > Settings.
The Inbound Settings fields to be configured are as follows:
*Bond reference method:
Internal - lookup using the internal reference only.
External - lookup using the external reference only.
Both - lookup using both the internal and external references.
We have chosen the 'Internal' method because, in the payload we built, we supplied the correlation_id
.
Your Inbound Settings form should look like this:
13) Navigate to Advanced > Script Editor.
Click on View > Inbound.
The Script Editor fields to be configured are as follows:
The code in the 'Payload to Stage' script field should look like this:
Your Script Editor fields should look like this:
15) Click Save.
We can now move on to Testing.
The Poll Processor contains the logic that will be applied when polling a remote system for data.
The Poll Processor is a configuration record which contains the logic that will be applied when polling a remote system for data. There are three main scripts which are used to setup, execute and process the Poll Requests. The scripts given here are examples of how you might configure your Poll. The details of yours may differ depending on your requirements.
This Get Attachment Poll Processor will take take each record passed to it from its parent - Select Attachments Poll Processor - and then make a Poll Request against that record, retrieving the attachment, building a payload and passing it to Unifi to process.
In Unifi Integration Designer, navigate to & open < Your Integration > (created following the Outbound Incident Guide).
Click the 'Poll Processors' icon & then New.
The fields to be configured for the New Poll Processor modal are as follows:
*Run parallel: Each Poll Request will have different input parameters (i.e. the sys_id of one of the attachments passed from its Parent). We can therefore run concurrent Poll Requests on the different records without concern for overlap issues.
Your New Poll Processor modal should look like this:
'Parent' - Once we have created its Parent Poll Processor, we can then select it here. We have not scripted any business logic to run from the value in this field. It is given for documentary purposes only.
3) Submit and view to further configure the Poll Processor.
The Setup Script is the first script to run (it runs at the point in time the Poll Request is created). It is used to build the environment for the poll and define what it will do. We will use it to setup the URL that will be called.
Navigate to Scripts > Setup Script.
The initial Poll Processor fields to be configured are as follows:
The code in the Setup script field should look like this:
Setup script: The parameters for which data to return are contained in the endpoint url.
Endpoint URL: The value used in the poll_request.endpoint_url was initially generated using the ServiceNow REST API Explorer polling the Attachment API, substituting a variable in for the sys_id of a specific attachment to query. This value is appended to the existing endpoint url in the active connection before being added to the Poll Request.
params: The params
object is passed through to the subsequent scripts (and on to further Pollers, if required). This script has been passed the sys_id of a specific attachment from its parent Poller.
Your Setup Script form should look like this:
5) Navigate to Request Script.
The Request Script is used to reach into the remote system and execute the request. We will use the ServiceNow RESTMessageV2() web service to make a REST call to the URL defined in the Setup Script.
The next Poll Processor field to be configured is as follows:
The code in the Request script field should look like this:
Request script: This script uses the ServiceNow RESTMessageV2() web service to make a REST call to the endpoint url created in the Setup script. It returns the body of the request as an attachment who's sys_id it passes to the Response script
saveResponseBodyAsAttachment(): This method takes three parameters:
tableName - the table that contains the record you want to attach the saved file to.
recordSysId - the sys_id of the record you want to attach the saved file to.
fileName - the file name to give to the saved file.
request.execute(): The response object returned by request.execute() provides a method called getResponseAttachmentSysid().
getResponseAttachmentSysid(): This method returns the sys_id
of the attachment generated by the REST call.
Your Request Script form should look like this:
7) Navigate to Response Script.
The Response Script is used to process the information returned from the remote system. We will pass this data to Unifi, telling it which Message to use to process the data.
The last Poll Processor field to be configured is as follows:
The code in the Response script field should look like this:
Response script: This script sets up some objects to help us; this includes the essential PollHelper() function (which we initialise from the poll_request) along with the info [] array.
After that it sets params.attachment.data to the sys_id of the created attachment, setting up a payload object and submitting it to Unifi by calling the processInbound() method.
After processing the single result, it is logged to the Response status field of the Poll Request.
Essential code: the following lines of code must be included in the response script to enable Unifi
Message name: Unifi needs to know the message name in order to know how to process the inbound request. We can either set it in the payload (as we did in previous Guides), or declare a variable that sets it which is passed into the processInbound() function along with the payload (as we have here). (Unifi will always check processInbound() first. If no Message name is set here it will use the 'Identify message script' on the Integration).
Your Response Script form should look like this:
9) Save the Poll Processor.
Now let's move on and configure the Get Attachment Poller.
Follow these instructions to test the outbound Message scenarios.
We will create some bonded tickets in the remote instance - initially testing the outbound Message scenarios. Those bonded tickets will then also be available to test the inbound Message scenarios.
In native ServiceNow, navigate to Incident > Create New.
The Incident fields to configure are as follows:
Though the CreateIncident Message has been configured to map more than just the Short Description & Description fields, we have only filled these fields because that is all whe have included in the payload of our Poller.
Your Incident form should look like this:
4) After you right-click & 'Save', note the Info Message confirming the CreateIncident Message is being sent to your Integration.
5) Note the Bond is 'Open' and both the Internal & External reference are in place.
Repeat as necessary so that there are three bonded tickets in the remote instance:
Update one of the bonded tickets in the originating instance to cause the UpdateIncident Message to fire:
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.
Navigate to Unifi > Unifi Operations Manager.
We can see that the three CreateIncident messages & one UpdateIncident message have been sent. All are Complete & Accepted & display the relevant Incident & Bond numbers.
Confirm the Transaction has updated the bonded ticket in the remote instance:
We can see that the update has reached the bonded ticket (& that the correlation id matches the outbound Incident number)
Resolve the same bonded ticket in the originating instance to cause the ResolveIncident Message to fire:
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.
Navigate to Unifi > Unifi Operations Manager.
We can see that the ResolveIncident messages has been sent. It is Complete & Accepted & displays the relevant Incident & Bond numbers.
Confirm the Transaction has updated the bonded ticket in the remote instance:
We can see that the State, Resolution code & Resolution notes have been updated on the bonded ticket (& that the correlation id matches the outbound Incident number)
Navigate to the Notes tab to view the Activities stream:
We can see that the update has also been logged in the Activities stream.
Next, we shall test the CreateIncidentInbound Message.
A Poller is a configuration record which defines the frequency of polling and which logic to use.
We will edit the previously created Child Update Poller, so that it runs our new "Unifi - SN REST Poller Single Incident with Attachments" (as created in the previous section) instead of the originally configured Poll Processor.
To edit the Child update Poller, click the 'Pollers' icon.
Click to open < Your Child Update Poller > (created following the Incident Parent and Child Poller Guide)
The fields to be edited for the Details form are as follows:
*Poll Processor: Value may vary. Choose the Poll Processor you created in the previous section.
Your Details form should look like this:
3) Save the Poller.
In the next section, we will look at the Inbound Messages.
You should have successfully configured two Poll Processors and two Pollers (plus edited the previously configured Child Poller & Poll Processor and edited the Endpoint URLs. Now to test.
If active, it may help to turn off the Parent Update 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 it off, in Unifi Integration Designer, click the 'Pollers' icon, locate the Parent Update Poller & set Active to false.
If you have edited the Connection, Poll Processors & Outbound Message Paths and because our Poll Processors have been configured to poll for updates from our PDI and make a decision - telling Unifi which Message to use to process that data, it will be necessary to test, utilising all the previously configured Messages, along with the new one. The Message Scenarios we shall be testing are:
CreateIncident
UpdateIncident
ResolveIncident
CreateIncidentInbound
UpdateIncidentInbound
ResolveIncidentInbound
AddAttachmentInbound
We will look in more detail at the steps for each over the next several pages.
If you have not editied the Connection, Poll Processors & Outbound Message Paths (because they were already configured with the /table/incident
element in the Poll Processors & Outbound Message Paths), then you may not need to test the Outbound Scenarios. This is because they would have already been tested as configured when following the Outbound Incident Guide.
However, because the codebase hase been edited in the Response Script of the 'Unifi - SN REST Poller Single Incident with Attachments' Poll Processor, all the Inbound Messages should be tested.
(You will need to create some bonded tickets in the remote system - whether created outbound or inbound - in order to facilitate testing the Inbound Messages.)
First, we shall test the Outbound Scenarios.
Congratulations on using this Attachment Poller Guide to successfully poll your PDI for updates & attachments - passing relevant data between Parent & Child Pollers, deciding which Messages to use.
This Guide has shown us how we might configure a Parent and Child Poller integration - polling data from both the Table API and Attachment API of a Personal Developer Instance (PDI) (building on the previously configured Parent & Child Pollers). We polled for attachments in two stages - an initial on-demand poll, scanning for attachments added to bonded, updated records and a subsequent, on-demand poll, pulling back the attachments and processing that data with the relevant inbound Message. As such, we created the following records:
Get Attachment Poll Processor
Get Attachment Poller
Select Attachments Poll Processor
Select Attachments Poller
We also copied and edited the previously configured Child Poll Processor so that it kicked off our Select Attachments Poller (editing the Child Poller so that it ran the copied Poll Processor).
To facilitate the ability to poll both the Table API and Attachment API we truncated the Endpoint URL in the Connection and prepended the Endpoint URLs in the Poll Processors and the Outbound Message Paths with either /table/incident
or /attachment
(as appropriate).
In testing our integration, we created & updated incidents in both instances (polling for updates each time). We successfully proved that we were only querying bonded records, pulling back updates made in the remote instance since the last update time, only retrieving a select number of fields. For each returned record, more detailed child Poll Requests were triggered, along with poll requests scanning for & retrieving attachments, generating transactions for each updated ticket.
We also proved that we were able to store previously returned records in order to facilitate comparison & enable the decision as to which Message to use to process the data - successfully telling Unifi which Message to use.
By Using the Unifi integration platform, we have discovered that building and testing our integration is simpler and more efficient, saving both time and money. Our hope is that this Guide has been a valuable aid to you in that process.
For further information please see our .
If you have any feedback or questions, please contact us via our website .
Follow these instructions to test the CreateIncidentInbound Message.
In your PDI, navigate to Incident > Create New.
The Incident fields to configure are as follows:
*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 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.
Navigate to Unifi > Unifi Operations Manager.
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.
Follow these instructions to test the UpdateIncidentInbound Message.
In the remote instance, update two of the bonded tickets in turn.
Updates have been made to the Description field only. Correlation ID is highlighted for us to identify the correct bonded ticket.
Open the corresponding Parent Poll Request & confirm that both Incidents were found (and only those) and that subsequent child Poll Requests were also triggered:
Notice the Parent & Child Poll Requests:
Open each of the corresponding Child Update Poll Requests & confirm that the Message name was UpdateIncidentInbound (found in the Response status).
Open each of the corresponding Select Attachments Poll Requests & confirm that the Response status says No Attachments returned (this is expected because no attachments were added).
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.
Navigate to Unifi > Unifi Operations Manager.
We can see that two UpdateIncidentInbound messages have been received. Both are Complete & Accepted & display the relevant Incident & Bond numbers.
Confirm the Transactions have updated the bonded tickets in the originating instance.
Next, we shall test the ResolveIncidentInbound Message.
Follow these instructions to test the ResolveIncidentInbound Message.
In the remote instance (your PDI), navigate to one of < Your Incidents > updated in the earlier test.
Update the Incident record as follows:
Your Incident record should look like this:
4) Right-click & Save.
Back in the originating instance, navigate to & open < Your Parent Poller >. Click Execute Now.
Open the corresponding Child Poll Request & confirm that the Incident was found (and the Message name was ResolveIncidentInbound) & Notice the incident_id passed in as a parameter:
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.
Navigate to Unifi > Unifi Operations Manager.
We can see that the ResolveIncidentInbound message has been received, is Complete & Accepted and displays the relevant Incident & Bond numbers.
Confirm the Transaction has updated the bonded ticket in the originating instance:
We can see that the State, Resolution code & Resolution notes have been updated on the bonded ticket.
Navigate to the Notes tab to view the Activities stream:
We can see that the update has also been logged in the Activities stream.
Follow these instructions to test the AddAttachmentInbound Message.
In the remote instance, select one of the bonded tickets.
Add an attachment to the record .
Back in the originating instance, navigate to & open < Your Parent Poller >. Click Execute Now.
Open the corresponding Parent Poll Request & confirm that the Incident was found and that subsequent child Poll Requests were also triggered:
Notice the Parent & Child Update Poll Requests and the Select & Get Attachment Poll Requests:
Open the corresponding Child Poll Request & confirm that the Message name was UpdateIncidentInbound.
The UpdateIncidentInbound Message was fired because that was set as default in the Response script of our Single Incident Poll Processor if there is an update with no change in state.
Open the corresponding Select Attachments Poll Request & confirm that the Attachment was found. Notice the attachment_hwm, ext_ref & int_ref passed in as parameters:
Open the corresponding Get Attachment Poll Request & confirm that the Attachment was found. Notice the attachment, ext_ref & int_ref passed in as parameters:
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.
Navigate to Unifi > Unifi Operations Manager.
We can see that an UpdateIncidentInbound message and an AddAttachmentInbound message have been received. Both are Complete & Accepted & display the relevant Incident & Bond numbers.
Confirm the Attachment has been added to the bonded ticket in the originating instance.
In Unifi Integration Designer, click on the 'Pollers' icon. Navigate to & open < Your Create Poller > (created on the ). & click Execute Now:
Back in the originating instance, navigate to & open < Your Parent Poller > (as configured on the ). Click Execute Now.
We instructed the Child Poll Processor to fire the Select Attachments Poller when we edited the Response script on the '' page.
#
Field
Description
Value
3
Setup script
The script to setup the Poll Request record.
Update the code in the Setup script field so that it looks like the code below
#
Field
Description
Value
5
Request script
The script that executes the request.
Update the code in the Request script field so that it looks like the code below
#
Field
Description
Value
7
Response script
The script that processes the response to the request.
Update the code in the Response script field so that it looks like the code below
#
Field
Description
Value
1
Message name
The message name that is unique for this integration.
'AddAttachmentInbound'
2
Type
The primary purpose of the message.
'Update'
3
Direction
The direction(s) this message is configured to support.
'Inbound'
4
Description
The description for this message and the requirement it is meeting.
<Your description>
#
Field
Description
Value
6
Response
The immediate synchronous response to this message.
<lookup: 'Response'>
7*
Async
Turn this option on if you want inbound processing to occur asynchronously or this message is the first of an asynchronous message pair.
<false>
#
Field
Description
Value
*
Bond ownership
Determine if the sender should own the bond or not in order for this message to be processed? Use 'Ignore' to process regardless of the owner flag. (Choices: Ignore, Must own, Must not own.)
'Ignore'
*
Bond condition type
The type of conditional check made on the bond. (None: no checks are made. State: checks against the state are made using the conditional checkboxes. Scripted: the 'Bond condition' script is used.)
'State'
9
Bond pending
Process this message when the bond state is Pending.
<true>
10
Bond open
Process this message when the bond state is Open.
<true>
#
Field
Description
Value
12
Bond reference method*
Method of searching for and validating an existing bond for incoming messages.
'Internal'
#
Field
Description
Value
14
Payload to Stage (Inbound)
The script to run.
Replace the commented out instructions with the code below.
#
Field
Description
Value
4
Setup script
The script to setup the Poll Request record.
Update the code in the Setup script field so that it looks like the code below
#
Field
Description
Value
6
Request script
The script that executes the request.
Update the code in the Request script field so that it looks like the code below
#
Field
Description
Value
8
Response script
The script that processes the response to the request.
Update the code in the Response script field so that it looks like the code below
#
Field
Description
Value
1
Poll processor
The Poll Processor to use when running this Poller.
<Your Poll Processor>*
2
Description
A description of what this Poller is for and/or how it works.
<Your Description> (edit accordingly)
#
Field
Description
Value
1
Name
The name of the Processor.
<Your Name>
#
Field
Description
Value
1
Name
The name of the Processor.
<Your Name>
2
Run parallel
Allow concurrent Poll Requests to be executed.
<true>*
#
Field
Description
Value
1
Caller
Person who reported or is affected by this incident.
<Your Caller>
2
Short description
A brief description of the incident.
<Your Short description>
3
Description
Detailed explanation on the incident.
<Your Description>
# | Field | Description | Value |
1 | Caller | Person who reported or is affected by this incident. | <Your Caller> |
2 | Impact | Measure of the business criticality of the affected service. | <Your Impact> |
3 | Urgency | The extent to which resolution of an incident can bear delay. | <Your Urgency> |
4 | Assignment group* | The group to which the ticket is assigned. | <Your Assignment group> |
5 | Short description | A brief description of the incident. | <Your Short description> |
6 | Description | Detailed explanation on the incident. | <Your Description> |
# | Field | Description | Value |
1 | State | The Incident lifecycle state. | ‘Resolved’ |
2 | Resolution code | The Incident resolution code. | <Your Resolution code> |
3 | Resolution notes | The Incident resolution notes. | <Your Resolution notes> |