An object definition encapsulates a business entity and its related data. An object’s child property definitions give that object its characteristics. An object can also define how its data is retrieved from the back end system. The object definition is the primary data definition for modules. At run time objects are instantiated during synchronization by the Agentry Server, which then transmits those instances to the Client. Object instances can also be created at run time on the Agentry Client via add transactions.
The object definition contains only a few attributes related to its identifying value, or “key property,” and the value displayed for the object during synchronization. The heart of an object definition lies in its properties. An object property defines a single piece of data for the parent object. The definition of an object property should always match the aspects and behaviors of the back end value it is created to store. This includes data type, data sizes, and the name.
The name of the object property should match the name of the back end value whenever possible. The Server matches the values returned by any back end steps to the properties within the object by matching the names. Any value returned from the back end whose identity does not match the name of a property in the object is discarded. Any object property that does not have a corresponding value in the return set from the back end is initialized to null upon object instantiation.
If it is not possible to match the property name with the back end value’s identifier, the value should be aliased in some manner within the return set. As an example, in SQL select statements a field can be aliased using the AS keyword, as in Field1 AS Name1. In Java the data structure containing return values can be named to match the properties.
The definition of an object should also include properties that may be needed on the Client side only. These values may be used for client-side processing or behaviors. In this case the values of these properties will be initialized to null when objects are instantiated during synchronization. They can be set via transactions on the client at run time.
Object instances are stored on the Client in one of two ways. First, a single instance of an object can exist as a property of another object. Second, and far more common, is to store objects in a collection property.
Objects are synchronized with the back end system via the module level definitions fetch and push. A fetch defines how the Agentry Server synchronizes data for a target object collection by referencing the step definitions to perform this task. A fetch is processed during synchronization between the Client and Server, with the results being the retrieval of new object instances for the target collection, replacement of existing objects within the collection, and the removal of objects from the collection. All of these determinations are based on the definition of the fetch and its child step usage definitions.
A push defines when it is necessary to push an object in real time from the back end system to the Agentry Client and how that object’s data is retrieved. Pushes are used only when a constant network connection can be maintained between the Client and Server. Like a fetch, a push targets an object collection property and will synchronize object instances within that collection. Objects can be added, replaced, or removed from the collection based on push processing. Differing from a fetch, pushes are run asynchronisly by the Server and pushing objects to the Client when changes to the back end system are made.
Another definition type involved in synchronizing objects are object read steps. An object read step references a step definition run to retrieve data from a back end system to populate an object's properties. When the synchronization process is defined using the exchange data model, it is often the case that the fetch is defined to determine what objects do and do not need to be retrieved, and the read steps are then run to perform the actual data retrieval. This is a common practice but not a requirement of the development. The fetch can be defined to accomplish both tasks without involvement of the object read steps. Likewise, push processing can involve running the read steps of an object to retrieve the object data from the back end system.
Regardless of whether a push or fetch is used, and also whether or not read steps are involved in the process, object data synchronization includes both the object collection targeted by the fetch or push, as well as any collection properties that are descendents of the objects within the targeted collection. Any collection property that is not defined within the main object, but rather as a descendent of the main object, is termed a “nested collection.” Nested collections are objects whose data is considered a part of the parent and ancestor objects within the module data structure. Therefore the synchronization process for a collection includes any nested collections within it.