We will be configuring two Pollers and two Poll Processors in order to pull data which has been updated from an external instance, pass the relevant data between them and then pass it to Unifi. We will then use the relevant inbound Messages in order to process that data.
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.
This document will guide you through an example of how you might configure a parent and child poller integration - polling the table API of your Personal Developer Instance (PDI).
Both the Incident Update Poller Guide and the Incident Multiple Message Poller Guide demonstrated how you might poll for updates from the table API of your PDI and then configure inbound Messages to process that data. This Guide will also demonstrate how you might poll for updates from the table API of your PDI, but will 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.
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.
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.
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.