Data Sync API

Data Sync

syncinfo

The syncinfo query returns the following information about the last Pulsar sync:

  • Previous Sync Date/Time

    • The sync completed prior to the most recent sync.

  • Last Successful Sync Date/Time

  • Last Failed Sync Date/Time

  • Last Failed Sync Error Code

    • Returns a three or four digit number representing the specific error that caused sync to fail, or zero if sync has never failed (Pulsar Error Codes).

  • Last Failed Sync CURL error code

    • Return a one or two digit number representing the CURL network communication error that led to a sync failure, or zero if there was CURL error.

  • Last Failed Sync CURL error message

    • Returns a message associated with the CURL error code if available.

  • Last Failed Sync Salesforce error code

    • Returns the error code from Salesforce as an alphanumeric string if applicable.

  • Last Failed Sync Salesforce error message

    • Returns a message associated with the Salesforce error code.

  • Last Failed Sync HTTP response code

    • Returns a three digit code plus brief descriptive text corresponding to the code. This is only reported when CURL reports an error or Salesforce’s response contains no body.

  • Last Sync Success

    • Returns YES if the last sync was successful, and returns NO otherwise

  • Last Sync Duration

    • Number (#.#) of seconds that the sync took

  • Sync Generation

    • Number of total sync passes since app was installed 

  • Sync Pass Count

    • Number of passes that were performed with the last sync

  • Sync Domain Type

    • all = standard initial or catchup sync,

    • mini = catch-up sync with a subset of objects,

    • single = a sync that at minimum syncs a single object, but can also sync up to one level above (via parent/lookup relationships) and one level below (via child relationships)

    • push = a sync that only pushes local changes to the server.

  • Sync Window Type

    • initial = The first sync performed after installing the app.

    • catchup = Any sync that is performed after the initial sync and is not a complete sync.

    • complete = A sync that is not an initial sync, but is performing a full sync due to a setting change.

  • Sync Resumed

    • Returns YES if the last sync was a continuation of an incomplete sync, and returns NO otherwise

  • Schema Changed

    • Returns YES if the last sync detected a schema change and performed a schema migration, and returns NO otherwise

  • Refresh Performed

    • Returns YES if the last sync resulted in refreshing the session and settings before sync began, and returns NO otherwise

  • Refresh Duration

    • Number (#.#) of seconds that refreshing the settings and session took

  • Metadata Sync Performed

    • Returns YES if the last sync performed a metadata sync, and returns NO otherwise

  • Metadata Sync Duration

    • Number (#.#) of seconds that the metadata sync took

  • Reachability Sync Performed

    • Returns YES if the last sync performed a reachability sync, and returns NO otherwise

  • Reachability Sync Duration

    • Number (#.#) of seconds that a reachability sync took

  • Server Processed Count

    • Number of full or partial records retrieved from the server for any reason (total across all object types)

  • Server Processed Object Count Map

    • Returns a list of server processed counts by object type

  • Server Integrated Count

    • Number of retrieved records ultimately added or updated on the local device

  • Local Created Count

    • Number of local created records sent to the server 

  • Local Deleted Count

    • Number of local deleted Ids sent to the server

  • Local Updated Count

    • Number of local updated records sent to the server

  • Local Updated Unique Count

    • Number of unique updated records sent to the server. This can be less than Local Updated Count if your organization has enabled the chronological changes feature.

Example Response

{ "type": "syncinfoResponse", "object": "", "data": { "lastfailedsync": "1970-01-01T00:00:00.000Z", "lastsuccessfulsync": "2023-06-01T04:10:55.020Z", "previoussynctime": "1970-01-01T00:00:00.000Z", "lastsyncduration": "44.9", "lastsyncsuccess": "YES", "localchangespendingcount": "0", "localcreatedcount": "0", "localdeletedcount": "0", "localupdatedcount": "0", "localupdateduniquecount": "0", "metadatasyncduration": "9.4", "metadatasyncperformed": "YES", "reachabilitysyncduration": "0.0", "reachabilitysyncperformed": "NO", "refreshduration": "0.0", "refreshperformed": "NO", "schemachanged": "NO", "serverintegratedcount": "4304", "serverprocessedcount": "4485", "serverprocessedobjectcountmap": "Account: 4000,Contact: 400,Case: 85", "syncdomaintype": "all", "syncgeneration": "1", "syncpasscount": "1", "syncresumed": "NO", "syncwindowtype": "initial" } }

Example Usage

var request = { "type" : "syncinfo", "data" : { } // empty object- this is required in the current API }; bridge.sendRequest(request, function (results) { console.log('Javascript got its response: ' + results); if (results.type === "syncinfoResponse") { var previoussynctime = results.data.previoussynctime; var lastsuccessfulsync = results.data.lastsuccessfulsync; } else if (results.type == 'error') { errStr = results.data; alert('A problem occurred:\n' + errStr); } });

syncdata

The syncdata request will attempt to initiate a Pulsar sync action. This method is equivalent to pressing the "Sync now" button from the native Pulsar home screen.

A standard sync is run by default without specifying any parameters.  To initiate a non-standard sync, you can specify additional parameters within the data node:

  • singleObjectSyncEnabled: Set to true to run a single object sync. This syncs a single (or root) object at minimum, but by default will retrieve all objects at one level above (parents) and one level below (children) the root object.

    • rootObjectId (required): The Id of the specific record you'd like to sync.

    • parentIdFieldList (optional): A list of reference type field names on the root object to also sync. If not specified, all objects referenced in all reference fields will be synced (for those object types already being synced). To disable this, you may specify a single invalid field (e.g. ["NONE"]).

    • childRelationshipList (optional): A list of child relationships on the root object to also sync. If not specified, all child relationships are utilized to sync objects at this level (for those object types already being synced). To disable this, you may specify a single invalid child relationship (e.g. ["NONE"]).

  • pushChangesSyncEnabled: Set to true to run a push changes sync. This skips directly to the sync stage that pushes all local changes to Salesforce.

  • useComposite: Set to true to explicitly use the Composite API. Currently, this applies only to push changes sync.

  • useCompositeGraph: Set to true to explicitly use the Composite Graph API. Currently, this applies only to push changes sync.

var request = { "type" : "syncdata", "data" : { } // empty object- this is required in the current API }; bridge.sendRequest(request, function (results) { console.log('Javascript got its response: ' + results); if (results.type === "syncDataResponse") { // successfully requested sync } else if (results.type == 'error') { errStr = results.data; alert('A problem occurred:\n' + errStr); } });

An example of a Composite Graph API enabled push changes sync:

An example of a single object sync that syncs the root object and all parent and child objects:

An example of a single object sync that syncs the root object (Contact) and a subset of parent and child objects:

An example of a single object sync that syncs the root object only:

Handling Sync Notifications

Overview

It is important to note that syncdata call returns a value when the sync process initiates, NOT when it finishes. The Pulsar sync process itself then provides a feedback mechanism for monitoring the overall progress of the sync, so the custom app can use that if it needs to know how the sync is progressing.

WARNING: Be aware of your context. If your document is running inside PulsarSFS, you should avoid using the add/remove handler functions on the bridge in favor of some methods that reside on the Pulsar SFS window object. Learn more about the Pulsar SFS window object: Pulsar SFS UI Customizations#Pulsar-FSL-Functions.

You can receive progress and completion notifications from javascript by registering handler functions with the Pulsar bridge. The available handlers are:

syncDataUpdate - returns the progress of the sync process with the pass number and completion percent.

syncDataFinished - runs when the sync process has finished.

These handlers can be used to run other functions in your custom code. For example, when the sync process reaches a certain point, say, 50%, you can run a function to notify users that the sync is halfway complete.

There can only be one handler assigned to a given handler name.

See the examples of handler setup below:

Register your handler before you issue the sync request

It is important to note that syncdata call returns a value when the sync process initiates, NOT when it finishes. It is possible that the sync process can be very short. Thus, handlers should be configured before syncdata is called to ensure they run.

The handler should be configured before a sync is requested. Also, it is important to keep in mind that you could create an infinite loop if you issue a sync request from within a sync handler.

Sync Progress

syncDataUpdate handler

To receive progress updates during a sync initiated with the syncData request, register a handler with the name "syncDataUpdate". This function will receive an object with the progress information:

  1. "syncpass" - The Pulsar sync may take one or more passes to fully complete. This will be delivered as a string containing the pass number, an integer value

  2. "syncpercent" - This value will be delivered as a string containing a floating point value between 0 and 100.00. This value is relative to the current sync pass, so may reach 100.00 more than once.

Sync Completion

syncDataFinished handler

To receive completion notifications for a sync initiated with the syncData request, register a handler with the name "syncDataFinished". This function will receive an object with the completion success status.

interruptsync

The interruptsync request will attempt to stop the currently running sync, if any.

Auto-Sync Status

getAutosyncStatus

The getAutosyncStatus operation will return Pulsar's current auto-sync status. This is the functionality that controls whether a sync starts automatically on login and when you return to the app. This will return the string "FALSE" if this functionality is off, and "TRUE" if this functionality is turned on.

setAutosyncStatus

The setAutosyncStatus operation will attempt to set Pulsar's current auto-sync status. Similar to getAutosyncStatus, this will return the string "FALSE" if this functionality is off after attempting to set it, and "TRUE" if this functionality is turned on after the attempt.

 

Related pages