Configuring the PollingAdjustment property

The PollingAdjustment property (measured in seconds), is used for adjusting the ServiceNow update time scope (relative to the gateway's clock) used in polling.

Range of PollingAdjustment

Since the gateway is run remotely from ServiceNow, the clocks at both sides are bound to be out of sync to some degree. This clock difference has an effect on gateway polling for ServiceNow updates.

You cannot rely on the default PollingAdjustment value. Gateway polling might become pointless if the gateway clock is leading without the aid of the PollingAdjustment setting to reverse the gap.

The range for the PollingAdjustment property is determined by which clock is leading.

Case 1:

GW_Clock <= ServiceNow_Clock (ServiceNow_Clock is leading)

PollingAdjustment = X, where 0 <= X < (ServiceNow_Clock – GW_Clock)

Case 2:

GW_Clock > ServiceNow_Clock (Gateway clock is leading)

PollingAdjustment = -X, where X >= (GW_Clock – ServiceNow_Clock)

To keep the gateway operationally healthy and efficient in performing polling for a substantial period, you should use a PollingAdjustment value that makes polled time scope slightly behind the ServiceNow's clock by between 10 seconds and 30 seconds.

Calculation of polled time scope

The gateway polls ServiceNow for updates periodically. Every iteration's polled time scope is based on the gateway's current time offset (forward or backward) as defined by the PollingAdjustment value.

If applied consistently to the clock rules as described above, when the PollingAdjustment property has a positive value, the resultant polled time scope will always be ahead of the gateway’s clock.

In the gateway log, the polled time scope is expressed in UTC. The polled time scope has a lower_bound and an upper_bound). The following example is the first polled time scope. The PollingAdjustment was configured as 200 seconds, and the time local to the gateway (the log timestamp) is UTC+8.

Lower bound
16/09/01 12:07:08: Debug: [Notifications] Encoded value '2016-09-01 04:10:28': 
'2016-09-01%2004%3A10%3A28'
Upper bound
16/09/01 12:07:08: Debug: [Notifications] Encoded value '2016-09-01 04:10:28': 
'2016-09-01%2004%3A10%3A28'

For first polled time scope, the difference between upper_bound and lower_bound is zero seconds. For all subsequent polled time scope, the difference between upper_bound and lower_bound is the length of polling interval. The lower_bound of a polled time scope is the upper_cound of its predecessor. The upper bound value is the gateway’s current time plus polling adjustment value.

Example:

1st polling

16/09/01 12:07:08: Debug: [Notifications]
Polling for updates in ServiceNow from Thu Sep 01 12:10:28 MYT 2016
16/09/01 12:07:08: Debug: [Notifications] 
Encoded value '2016-09-01 04:10:28': '2016-09-01%2004%3A10%3A28'.
16/09/01 12:07:08: Debug: [Notifications] 
Encoded value '2016-09-01 04:10:28': '2016-09-01%2004%3A10%3A28'

2nd polling

16/09/01 12:07:39: Debug: [Notifications] 
Polling for updates in ServiceNow from Thu Sep 01 12:10:28 MYT 2016
16/09/01 12:07:39: Debug: [Notifications] 
Encoded value '2016-09-01 04:10:28': '2016-09-01%2004%3A10%3A28'.
16/09/01 12:07:39: Debug: [Notifications] 
Encoded value '2016-09-01 04:10:59': '2016-09-01%2004%3A10%3A59'.

Problems in polling operations

Progressive clock drift or an inappropriate PollingAdjustment value may lead to these possibilities:

  1. Latent update

    Caused by the resultant polled time scope being behind the ServiceNow's clock. The further the polled time scope is behind the ServiceNow's clock, the more iterations will the gateway need to take to reach subsequent time scopes that may be containing updates.

    As a result ObjectServer's reflection of updates in ServiceNow tickets would appear lagging. If there were series of changes in a ticket’s fields over time, the history (save the latest update) would be oblivious to ObjectServer because of latent polling.

  2. Skipping update

    Caused the resultant polled time scope being ahead of the ServiceNow's clock. This is the worst scenario for the gateway, because there can be no updates in the future time frame that has yet to come in ServiceNow.