REST Export REST APIs

Export APIs are primarily used by customers who want to integrate the mobile data back into their own backend systems. Each API call may return zero or more objects from one or more different mobile users. The order of the transactions generated by technicians will be maintained. Typically, a customer will continually call (poll) the export APIs to receive the latest updates from the field and apply them to their own internal system. A separate export API exists for each type of mobile transactions. 

The export API maintains historical data (within a configurable time window), it is possible to extract the same collection of objects again. This can be very useful during QA, troubleshooting, or when there was a processing error on the back-end. Refer to the rowver Usage section below for more details. 

The Export APIs support only the HTTP GET method. However, unlike the Standard REST API GET method that always returns the latest version of the object, the export GET method returns a collection of updates to objects made by the mobile application. The collection may include multiple updates to the same object. 

For example, in the scenario where a technician receives a new work order, begins traveling, stops traveling, and then opens the work order order four distinct transactions will be generated for the same object and uploaded to the system and made available via the export API. In this scenario the transactions that would be generated are:

• Acknowledgement that the work order was received
• Status change of the work order to traveling
• Status change of the work order to stop traveling
• Status change of the work order to on site

rowver Usage

The rowver URL parameters provides a critical role during the export process. It instructs the export API to start returning data after the value specified. The first time an export API is called rowver should be set to 0 to return the first collection of objects. Each result set returned contains a new rowver for the next set of data as well as a unique rowver value for each individual object returned. This requires the backend save the appropriate rowver value to be used ini the next call to the API. 

In the Example Export Result Set below, the rowver value on line 2 identifies the value to be used to return the next collection of objects. The rowver at lines 5, 12 and 19 are object specific rowver values and can optionally be used if the backend has an error while processing the results. For example, if the backend processed the object identified by rowver=61 properly but crashed while processing rowver=65, it can call the export API with a rowver=65 which identifies the last valid object that was processed. The API would then return a collection of objects starting with the next object after the one identified by the rowver=65. 

{
    "rowver" : "72",
	"rows" : [
		{
			"rowver" : "61",
   			"UserID" : "",
            "UserAudit" : {
                .
                .
			}
		},
		{
			"rowver" : "65",
   			"UserID" : "",
            "UserAudit" : {
                .
                .
			}
		},
		{
			"rowver" : "72",
   			"UserID" : "",
            "UserAudit" : {
                .
                .
			}
		}
	]
}