Polling for Changes

Client applications typically poll for changed data periodically. Polling involves the following considerations:

• The polling frequency depends on business requirements for how quickly changes in your organization’s Salesforce.com data need to be reflected in the local copy. Some client applications might poll once a day to retrieve changes, while other client applications might poll every five minutes to achieve closer accuracy.
• Deleted records are written to a delete log, which getDeleted() accesses. A background process that runs every two hours purges records that have been in an organization's delete log for more than two hours if the number of records is above a certain limit. Starting with the oldest records, the process purges delete log entries until the delete log is back below the limit. This is done to protect Salesforce.com from performance issues related to massive delete logs. The limit is calculated using this formula:

      5000 * number of licenses in the organization

  For example, an organization with 1,000 licenses could have up to 5,000,000 (five million) records in the delete log before any purging took place. If purging has been performed before your getDeleted() call is executed, an INVALID_REPLICATION_DATE error is returned. If you get this exception, you should do a full pull of the table.

• The API truncates the seconds portion of dateTime values. For example, if a client application submits a timespan between 12:30:15 and 12:35:15 (Coordinated Universal Time (UTC) time), then the API retrieves information about items that have changed between 12:30:00 and 12:35:00 (UTC), inclusive.
  Note

  Development tools differ in the way that they handle time data. Some development tools report the local time, while others report only the Coordinated Universal Time (UTC) time. To determine how your development tool handles time values, refer to its documentation.
• We recommend polling no more frequently than every five minutes. There are built in controls to prevent errant applications from invoking the data replication API calls too frequently.
• Client applications should save the timespan used in previous data replication API calls so that the application knows the last time period for which data replication was successfully completed.
• To ensure data integrity on the local copy of the data, a client application needs to capture all of the relevant changes during polling—even if it requires processing data redundantly to ensure that there are no gaps. Your client application can contain business logic to skip processing objects that have already been integrated into your local data.
• Gaps can also occur if the client application somehow fails to poll the data as expected (for example, due to a hardware crash or network connection failure). Your client application can contain business logic that determines the last successful replication and polls for the next consecutive timespan.
• If for any reason the local data is compromised, your client application might also provide business logic for rebuilding the local data from scratch.

Note

You can now use Outbound Messaging to trigger actions instead of polling for them.