We will be configuring another Poller and Poll Processor in order to pull data which has been updated from an external instance and then pass it to Unifi. We will then configure the relevant inbound Messages in order to process that data.
This document will guide you through an example of how you might configure a poller integration - polling the table API of your Personal Developer Instance (PDI).
It assumes that both the Integration and the Connection are still in place from the ‘Outbound Incident’ Guide and will be using those same elements as configured there. It also assumes that you know how to use the REST API of your PDI to query for information and read ticket data.
Note: If you haven’t completed the ‘Outbound Incident’ Guide, please review & complete the following sections of that document, as they must be in place before continuing with this Guide:
- Application Scope
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.
Note: 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:
- UpdateIncidentInbound Message
- UpdateIncidentInbound Fields
- Message Identification
- Bond Identification
- Message Configuration
The ‘Incident Update Poller’ Guide demonstrated how you might poll for updates from the table API of your PDI and then configure an inbound Message to process that data. This Guide will also demonstrate how you might poll for updates from the table API of your PDI, but will also require that we store local data in order to decide which Message to use and then configure multiple inbound Messages to process that data
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. Create your own global application and then build your integration within that.
We will again be building in the same Application Scope as our ‘Outbound Incident’ Guide & ‘Incident Update Poller’ Guide.
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), we will also need to store and check other data in order to decide which Message to use to process that data.
We will begin by polling for updates and then process those requests using multiple Messages in Unifi.