The data tags to access property values are different from other data tags. The basics of there use are the same as all data tags. However, data tags for properties include additional parameters to access the property values and those parameters depend upon the data type of the property they are referencing.
A Boolean property will result in a Boolean data tag. Like their property counterparts, Boolean data tags are either true or false. When passed as an argument to a function tag, there are special syntactical rules that apply to Boolean data tags.
When data tag expansion occurs, a Boolean data tag will result in either the text “true” or “false.” Because of this fact, when a Boolean data tag is used as a parameter to a function tag, it should not be enclosed in markers (<< and >>). When a Boolean is not enclosed in these markers, the value of either true or false is passed to the function, rather than the text values of “true” or “false”. This is important since, if the text values are passed to a function that is expecting a Boolean value, it will always consider the value passed in to be true. Remember that true is a value and false is the absence of a value. The text “false” is a value and, thus, will be treated as true in the context of a Boolean parameter.
<<if <<object.BooleanProp>> ... >>
<<if object.BooleanProp ... >>
<<if “false” ... >>
This will result in the text value of “false” being passed to the function.
The second line will result in the Boolean value of true or false being passed to the <<if...>>, rather then the text “true” or “false.” Note that referencing a Boolean without the markers is only valid when the Boolean tag is passed as an argument to a function.
The customer’s car has front end damage.
The customer’’s car has front end damage.
Note the two single quotes in place of the previously single quote (used as an apostrophe here) within the word “customer’s”. As explained in the chapter on function tags, the <<dequote...>> function also provides this ability. However, for string data tags with a property as its data source, this behavior is automatic.
<<parent.stringDataTag length=n>>
Denoting this data tag in this manner, the value of the string will be truncated to the length of n. This truncation occurs before any quotes are escaped, so that the extra quotes added in that process are not affected by the truncation. As stated, length is an optional parameter and, if not provided, the entire value of the string will be placed in the script file during data tag expansion.
<<object.stringDataTag.raw>>
Integral data tags result from properties of the types Integral Number and Identifier. Decimal data tags result from properties of type Decimal Number. During data tag expansion, the value of these tags are placed in the script without modification. In this respect these two data types are treated the same. It is when these values are passed as arguments to functions where the difference between the two types becomes important.
Integral Number data tags will contain whole number values. These data tags can be used with the math function tags that accept integral numbers. Many of the function tags that can accept the use of numerical values have a type parameter. When using this type of data tag, the value to the type parameter of the function is Int.
Decimal Number data tags will contain numerical values that have a fractional portion, such as 2.4 or 3.00. These data tags can be used with math function tags that accept decimal numbers. Many of the function tags that accept the use of numerical data, math tags as well as others, can accept a type parameter. When using this type of data tag, the value for the type parameter is Float.
<<transaction.StatusDate>>
to_date(‘01/25/2006’, ‘MM/DD/YYYY’)
<<transaction.StatusDate.raw>>
01/25/2006
This can be useful if the date value is to be within some sort of string value within the database, such as a description. In this case, you do not want to convert the value to a database date format, but rather use it as a string.
<<transaction.EndTime>>
to_date(‘13:10:43’, ‘HH24:MI:SS’)
<<transaction.EndTime.raw>>
13:10:43
This is used whenever you wish to access just the time string, without converting it to the database time format.
<<transaction.InspectionDateTime>>
to_date(‘02/13/2005 13:20:35’, ‘MM/DD/YYYY HH24:MI:SS’)
<<transaction.InspectionDateTime.raw>>
02/13/2005 13:20:35
This is used whenever just the date and time value is desired, without wishing to convert it before being processed by the enterprise system.
These three data types that deal with dates and times support the use of the named parameter format=. This parameter accepts one or more of several date and time tokens. These tokens are combined to provide a picture of how the data should be placed in the file. When a date, time, or date and time data tag contains the format parameter, the default format is overridden, including the conversion function within which the values are normally contained.
Token | Description | Example | Short Form |
---|---|---|---|
%a | The three letter abbreviation of the day. | Wed | We |
%A | The name of the day. | Wednesday | Wed |
%b | The three-letter abbreviation of the month. | Feb | n/a |
%B | The name of the month. | February | Feb |
%d | The date of the month. | 07 | 7 |
%j | The Julian date, with a leading 0. | 038 | 38 |
%m | The two digit month (01-12) | 02 | 2 |
%w | The numerical day of the week (0-6 Sunday = 0) | 3 | n/a |
%y | The two-digit year | 01 | 1 |
%Y | The four-digit year. | 2001 | n/a |
%R or %r | The raw format of the value | 36543,37 | n/a |
%H | The hour of the day, 24 hour format. | 10 | n/a |
%h or %I | The hour of the day, 12 hour format | 10 | n/a |
%M | The minutes of the hour. | 09 | 9 |
%p | AM or PM indicator. | A | a |
%S | Seconds of the minute. | 03 | 3 |
%Z | The time zone when the time was recorded. | Central Standard Time | n/a |
non-token characters | Any non-format token character, or any character not preceded by the % sign passed to the named parameter format will be returned unchanged at the position at which it was placed in the parameter value. | n/a | n/a |
Signature data tags result from Signature property types. This data tag type is used with the signature capture functionality available in Agentry. This functionality allows for an application to capture and store a signature the user enters on the screen. The image is stored as a bitmap, and is also available in the raw pixels.
<<transaction.signatureProp.parameter>>
Of these parameters, only type and signed are always available. The others will return a data tag not found error if a signature was not captured on the client, i.e. signed returns false. Therefore, the return value of signed should be checked before attempting to access the other parameters.
Image data tags result from Image property types. This data tag type is used with the image capture functionality available in Agentry. This functionality allows the application to interact with a device’s built in still camera, when present. A captured image is stored on the device as a file and referenced by the image property.
During synchronization this file data is sent to the server for processing as a part of the transaction data. To access this image data there are two options. The first is to use a file document management step. In this case, it is likely not necessary to reference the data tags for the image property, though they can be when necessary. For other step types access to the image data requires the use of SDML data tags. Data tags for the image property include two parameters in the format <<transaction.imageProperty.parameter>>.