A fetch defines how the Agentry Server synchronizes data for a target object collection. This object collection must be a top-level collection within the module. A fetch is made up of steps that retrieve the data for the collection from the back end system. These steps are grouped into three categories within the Fetch definition: Client Exchange Steps, Server Exchange Steps, and Removal Steps. A fetch may also include properties to store data captured from the user and validation rules for those property values.
A fetch may be a main or non-main fetch. A main fetch is processed during every transmit between the Agentry Client and Server. A given module may contain multiple main fetches. The order in which multiple main fetches, either within the same module or within multiple main fetches, are processed is undefined and should therefore not be a factor in the synchronization logic.
A non-main fetch will only be executed when an action step of type transmit explicitly defines such a fetch to be processed. Non-main fetches are normally defined to provide the search functionality to end users.
The basic structure of a fetch definition is intended to support the exchange data model of synchronization. This model is intended to allow for the synchronization of data in a more efficient manner, where only data changes on the back end system as compared to the current data on a given client are retrieved. Any data that has not been changed as compared to the client’s data is not retrieved.
A fetch definition can be defined to retrieve new object instances to be added to a client application, replace existing objects on that client, a remove any objects the client should no longer store locally. The read steps of the object type targeted by the fetch are run after the fetch has been processed and may also retrieve objects for the client to either add them or replace existing instances.