Models
A mobile model might include data from more than one table, and it may include only a subset of columns.
Models are associated with both queries and views, and define the data structure that a query or view works with. For example, the service request viewer in the mobile app uses the CRM_ServiceRequest model to access service request data.
Endpoints
Endpoints define how models connect to the data source. Specifically, an endpoint defines a path that will be appended to the base Rest Services URL in calls to Rest Services. For example, the CRM_ServiceRequest model has this endpoint: /crm/servicerequests/{Id}. If the base URL is http://server/rest840/api, then service calls for this model will take this form:
http://server/rest840/api/crm/servicerequests/{Id}
An endpoint can include one or more qualifiers, such as {Id} in the example. In this case the qualifier represents the primary key of a service request. For example, an HTTP request for the service request with primary key 1124 will take this form:
http://server/rest840/api/crm/servicerequests/1124
Endpoints for most models are defined in the Mobile configuration. Endpoints for some of the standard models are defined in code.
Properties
Model properties correspond to business object properties, which in turn correspond to columns in the database. There are two ways to define a model's properties. You can add properties to your models directly, but this is only necessary if you want certain properties to be available regardless of the view the model is bound to. Otherwise, if a model is bound to a view, the properties that the view's controls are bound to are added automatically.
For example, the CDR_Building_Application model in the Mobile configuration has five properties explicitly defined for it: Address, ApplicationAttachments, Details, Logs, and Spatial. The views that are bound to the model, such as CDR_Building_Application_RecordView_Summary, define additional properties. For example, one of the text boxes in this view is bound to ApplicationNumber, and another is bound to ApplicationType, so both of these properties are added to the model.
The properties that are explicitly bound to a model can also be linked to other models by foreign keys, just as tables can be linked in the database. For example, the Address property mentioned above creates a relationship between the CDR_Building_Application model and the Property_Address model.
Property groups
A property group is a collection of properties that are used under specific conditions. For example, property groups are used to define the properties of different asset types for the AssetManagement_Asset model. This means that you can use the same model for all asset types, rather than defining a separate model for each one.
The AssetManagement_Asset model defines the basic properties of an asset, such as the unit ID and the asset type. Each property group defines additional properties for a specific asset type, such as the manufacturer and model number of a vehicle. Each property group uses one or more filters to define its conditions. For asset property groups, the type property of the AssetManagement_Asset is used to select the correct property group for an asset type.
A property group can also override the moniker of the parent model. For example, the moniker associated with AssetManagement_Asset is Hansen.AssetManagement.Asset, which is the generic moniker for all asset types. The Vehicle property group has its moniker set to Hansen.AssetManagement.Fleet.Vehicle, so it uses the Vehicle object rather than the generic Asset object.