Using Attributes in DataSplice

DataSplice understands how critical it is for CMMS clients to work with a product that is configured to meet specific needs. Customized features within DataSplice technology are designed to help network administrators to create a user interface that is simple for the mobile user to operate.

DataSplice uses system variables called attributes to provide dynamic behavior to mobile applications. Attributes are name-value pairs that define field variables which for users and groups that control application behavior. This eliminates the need to create custom settings, and makes the end-user's interraction with the system as painless as possible while in the field.

Attribute Hierarchy

DataSplice uses a hierarchy to define attributes. Attributes can be referenced in any value that allows text entry by surrounding the attribute name with ${ and } - ie, ${AttributeName}. The basic attribute levels include:

• Built-in - These attributes are defined by the system and will always be present. The include the name of the remote user, the current time, the name of the current view, and other fixed values.
• System-wide - Administrators can define attribute values that will be available throughout the system.
• View - Attributes defined for views will only be active when the particular view is being accessed.
• User and Group - Likewise, attributes can be defined such that they are only available for a particular user or group.
• Record - The values of the current record are added to the attribute collection so they can be accessed in the same fashion as other attributes for binding to event actions and filters.

Attributes that are defined at higher levels take precedence over the same attribute defined at a lower level. So for instance, the administrator can define a system-wide attribute DefaultStoreroom that will set the default for the entire system, and then define the same attribute for individual users or groups if they need a custom value.

Record Attributes

Record attributes within DataSplice are essential for defining relationships between views and mapping values to the parameters of database procedures. This allows the value of the current record to be used exactly like any other attribute.

For example, a relationship record could be defined with a filter to reach a specific subset of information:

UserName = ${DSUser} AND Location = ${Location}

In this case, the filter values will be replaced with the name of the current user and the value of the Location field of the selected record. This is an example of a built-in attribute and a record attribute being used in the same way to dynamically find desired information.

Pre-Defined Attributes

DataSplice also supports many pre-defined attributes that can modify application behavior if they are defined. For example:

Login Attributes

Specify whether or not the client should clear the username and/or password when disconnecting.

View Display Attributes

Controls how views are grouped or displayed in the view selection screen, and whether data is presented as a grid or vertical display.

Editing Attributes

Used for data change procedures - should changes be sent to the server automatically or should client wait for user to manually click Save.

Performance Attributes

Regulate timeout and ping settings to manage slow networks gracefully.

Query Attributes

In addition to supporting simple text values, DataSplice also supports attributes that obtain their value as a result of a query against another view. Query attributes define a filter and sorting information that is used to query a value from another view using the specified criteria. These can be used in many ways:

• Provide field defaults by looking up settings in other tables
• Pass complicated results to database procedures
• Query max and min values by sorting results

Once query attributes are defined, they can use other attributes to query values in other records and views. Query attributes are excellent for defining parameters for information that changes often but is part of a common data request.