Incident Attachment Poller Guide
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:
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:
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):_
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.
Last modified 1yr ago