Conclusion

Congratulations on using this Parent and Child Poller Guide to successfully poll your PDI for updates - passing relevant data between Pollers, deciding which Messages to use to process that data.

This Guide has shown us how we might configure a parent and child poller integration - polling data from the table API of a Personal Developer Instance (PDI) 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. As such, we created the following records:

• Child Poll Processor

• Child Poller

• Parent Poll Processor

• Parent Poller

In testing our integration, we created some incidents in the remote instance which were bonded. We then updated the bonded records from 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, 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 technical documentation.

If you have any feedback or questions, please contact us via our website contact form.