Data tags provide the access to the production data
of the application within the synchronization components of the
mobile application. This includes access to property values, global
definition values, query constants, and client and server information
system information. Each of these items just listed are referred
to as the data tag’s data source.
In addition to the tag’s data source, all data tags also have
a certain data type. The data source and the data type of a tag
combine to give the data tag its overall behavior. This behavior
includes how the value is expanded during data tag expansion, as
well as the parameters that the tag will support. By and large,
the data tags created for properties are the tags that have the
most complex behavior.
Data tags that provide access to data other than from properties
or globals are strings. Those data tags that are based on a property
definition are one of several data types, based on the property
data type.
Data Tag Data Types
Within the SDML, all
data tags have a data type. This data type affects how the data
tag is processed during tag expansion. Do not confuse the data tag’s
type with the data type for that same value in the back end system.
When the Agentry
Server has
completed tag expansion the resulting values within the script are
plain text. At this point, the methodology for denoting the value’s
data type will depend on the type of back end system in use.
As
an example, for a database system connection, data tags with a data
type of date and time will be expanded with the date and time conversion
function for that database as a part of the text, as in:
<<object.statusDate>>
If this data tag is a date and time and used
in a script for an Oracle database, it would expand to:
to_date(‘01/12/2004 14:23:45’, ‘mm/dd/yyyy hh24:mi:ss’)
As you can see, the date and time value has been
wrapped in the to_date function call for Oracle, which
converts string values into dates and times.
The data types
for data tags are as follows. Note that all data types other than
string are applicable only to tags for global and property values:
- String
- Integral Number
- Decimal Number
- Boolean
- Date
- Time
- Date and Time
- Signature
The Scope of Data Tags
The data tags within
the SDML may or may not be valid in one area verses another. The
scope of a data tag will vary from one to the next. Certain tags
are only valid in steps used by a fetch. Others are only available
in steps used by transactions. Still others are available globally.
It is important to note that for scripts within step definitions,
the scope for a data tag is determined by the type of step definition
and also the step usage definition referencing the step to be processed
at run time. For example, the data tags that are in scope for a
step used by an object read step will be different from the tags
that are in scope for a step used by a transaction’s server update
step. The terms used to describe a data tag’s scope are:
- Global:
A data tag with Global scope is valid in all scripts processed by
the Agentry
Server. NOTE:
Do not confuse the term Global used here to denote a tag’s scope
with the definition type global. Values for a global definition
do have a global scope. However, there are other data tags that
also are globally available to the application’s synchronization
components.
- Definition-Type: A data tag with the Definition-Type scope
is one that is in scope only for a certain type of definition, such
as a Transaction or Object. The Type portion of this scope specifies
the definition type for which the data tag is applicable.
- Definition: A data tag with the Definition scope is one
that is only in scope for instances of a specific definition. For
example, the data tags in scope for an Object named Customer will be
different than those for an Object named Order. Data tags that have
a Definition scope are those that provide access to the properties
of an object.