AgentryRuleEditorGuide 4 4 2

4.4.
Rules and Rule Editor

Developer Guide
1st Edition
1721 Moon Lake Boulevard | Suite 300
Hoffman Estates, IL 60169
800.567.9256 toll free - North America
info@syclo.com | www.syclo.com
Syclo International Limited | Europe, Middle East & Africa

Fetcham Park House, Lower Road, Fetcham,
Leatherhead, Surrey, KT22 9HD, United Kingdom
+44 (0) 1372 371031 phone | +44 (0) 1372 371032 fax
This document is presented as is and as such no warranty, express or implied, is made by Syclo as
to the accuracy and completeness of this document or related material, nor shall the fact of distri-
bution of this document and the related material constitute any such warranty, and no such respon-
sibility is assumed by Syclo in connection therewith. Information contained within is subject to
change without notice.
This work is protected by the copyright laws of the United States of America and is proprietary to
Syclo, LLC. Disclosure, copying or reproduction, merger, translation, modification, enhancement
or use by anyone other than authorized employees or licensees of Syclo, without prior express
consent of Syclo, is strictly prohibited.
Copyright 2008 Syclo, LLC. All Rights Reserved.
Syclo is a registered trademark of Syclo, LLC. All other products and logos are the trademarks or
registered trademarks of their respective holders.
i
Chapter 1
Rules and the Rule Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
An Introduction to Rules in Agentry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
Rule Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
Rule Term Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
Context and Return Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
The Rule Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
How Rules Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Overview of the Rule Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Adding and Editing Rule Terms. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
How Rules are Used in Agentry. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Chapter 2
The Context of Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
What is Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Rule Data Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Context and Return Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Converting to Booleans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Converting to Strings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Conversion to Collections, Signatures, External Data, and Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Conversion to Dates and Times. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Conversion to Numerical Types. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Context and Target Paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Context and Rule Term Function Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Chapter 3
Rule Term Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Overview of Rule Term Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Strong and Loose Typed Function Arguments. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
More on the Rule Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Rule Term Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Conversion Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
@DECIMAL_NUMBER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
@INTEGRAL_NUMBER. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
@SIG_DECIMAL_NUMBER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
@STRING . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Logical Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
@AND . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
@CASE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
@CASE_INT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
@CASE_STRING . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
@EQBOOL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
@EQDEC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
@EQNUM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
@EQSTRING. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
@IF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
@NAND . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
@NOR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
@NOT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
@OR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
@XOR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Mathematical Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
@ABS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
@DIFF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
@DIV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
@FORMAT_DECIMAL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
@GT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
@GTDEC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
@GTEQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
@GTEQDEC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
@LT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
@LTDEC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
@LTEQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
@LTEQDEC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
@MAX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
@MIN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
@MOD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
@PERCENT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
@PRECISION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
@PROD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
@RANGE_LIMIT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
@ROUND . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
@SIGN. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
@SIGNIFICANT_DIGITS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
@SQRT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
@SUM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
@TRUNC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
Property Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
@COUNT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
@SIZE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
@COLLECTION_MAX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
@COLLECTION_MIN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
@TOTAL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
@MEMBER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
@PROP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
@TYPE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
@CURRENTVALUE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
@SCREENFIELDVALUE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
@SCREENFIELDNAME. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
@UI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
@LASTSCANVALUE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
@IS_SPECIAL_VALUE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
@IS_VALID_DECIMAL_NUMBER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
@NEEDS_XMIT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
@TRANSACTIONPROPERTYNAME . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
@FILE_PATH_AND_NAME . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
@FILE_PATH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
@FILE_NAME . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
@FILE_EXTENSION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
@FILE_SIZE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
@FILE_CHANGED . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
String Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
@CONCATENATE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
@FIND . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
@LEFT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
@LENGTH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
@LOWERCASE. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
@MID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
@NEWLINE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
@REMOVE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
@REPLACE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
@RFIND . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
@RIGHT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
@TAB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
@TRIM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
@UPPERCASE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
System Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
Time and Date Formats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
@DATE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
@DATE_AND_TIME . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
@TIME . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
@MODULE_ENABLED . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
@OFFLINE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
@USERID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
Table Functions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
@COMPLEXTABLE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
@DT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
@ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
1
RULES AND THE RULE EDITOR
TOPICS:
• Introduction to Rules
• Overview of the Rule Editor
• How Rules are Used in Agentry
2 Chapter 1 - Rules and the Rule Editor
An Introduction to Rules in Agentry

Within any real-world application developed using Agentry, there will be several Rule definitions
in use. Rules are the definition type used in Agentry that allow you to enforce the complex busi-
ness logic required by the application. This can include validating data entered by the user’s
when performing a transaction or fetch; updating field values based on the values of other fields
or properties;. setting the initial values of properties based on variable conditions; enabling and
disabling functionality, or even whole modules within an application; and various other tasks.
The Rule definition type is the most involved definition within the Agentry Development Envi-
ronment. It consists of functions, data values, and even other rules, to ultimately determine an
overall return value. Which definition is using the rule also affects its overall behavior, and even
the various functions it contains. Because of this involved structure, the Rule definition type,
while introduced and discussed from a high level in the Agentry Reference Guide, is discussed in
detail in this separate manual, as is the Rule Editor used to create Rule definitions within the
Agentry Editor.
There are several concepts to understand in order to properly create Rules within an application.
These include Rule Terms, Rule Term Functions, Context and Return Type, using the Rule Editor
and, related to this, the structure in which Rules are presented to you within the Rule Editor.
Rule Terms
A Rule Term is any one of several types of components to a rule, from something as simple as a
constant value, to one as complex as a sub-rule included within a Rule definition. Each Rule
Term returns a single piece of data to the term that called it, or to the Rule itself. The data type of
this data is entirely dependent on the Rule Terms Context (discussed shortly). The Rule Terms are
the components of a Rule that give it the desired behavior.
Rule Term Functions

Rule Term Functions are one of the Rule Terms. They are discussed separately from the other
components because it is a Rule’s functions that have the biggest affect on how a Rule behaves.
Rule Term Functions accept arguments. These arguments are processed by the function and a sin-
gle value is then returned by the function to its caller. This return value, as with any Rule Term, is
typed based on the context of the rule. Within Agentry, there are numerous Rule Term Functions.
These functions are described in detail later in this manual.
Context and Return Types

The concept of a Rule’s Context is one of the most important ideas to understand when learning
how to create Rule definitions. A Rule is always called in some context, which is the definition
that is using, or “calling,” the Rule. This may be one of the other definition types within Agentry,
or it may be another Rule. The context also affects the Rule Terms within a Rule. The primary
affect a Rule’s context has is the data type of the value the Rule returns. For instance, a Rule
called in a context in which a Boolean value is needed (such as enabling or disabling an Action),
Chapter 1 - Rules and the Rule Editor 3
the value of that Rule’s return is treated as, or “converted to,” a Boolean value. In this case, if a
Rule returns a string of characters, this return value will ultimately be treated as a Boolean, mean-
ing any value returned is treated as a true return, unless an empty string is returned, which would
be converted to false. The Rule’s Context also determines how target paths to properties and
other definition types are resolved. While Rule’s can be edited from a number of locations,
regardless of context, they may only be added within the Agentry Editor at the point at which they
will be used, so as to be able to determine the Rule’s context.
The Rule Editor

The Rule Editor is the tool within the Agentry Editor used to define and edit all Rules for an
Agentry application. The Rule Editor is a graphical interface that allows you to point and click to
define Rules. This includes selecting functions from a list of all those available, as well as select-
ing other values, such as Properties or Globals. A Rule is displayed in the Rule Editor in a tree
control, with the Rule itself existing at the root level, and the terms of that Rule as child or descen-
dent nodes. The Rule Editor itself is fairly simple to use, consisting of only a handful of controls.
It is the Rules themselves that bring the complexity to the process of define them.
How Rules Work

Before proceeding further into the details of the Rule definition type, it is important to have a gen-
eral understanding of how rules work, and to also clearly define the terminology related to this
definition type. First, Rules are a client-only definition, meaning they affect only the behavior of
the client. They do not directly affect the processing performed by the Agentry Server, nor do
they directly impact communications between the client and server.
When a rule is processed on the Agentry Client, it is said to be evaluated. The functions and
terms within a rule are each evaluated in turn, resulting in the final return value of the rule. Rules
are evaluated at different times on the client, depending on how the rule is used. Normally, this
occurs when the definition using the rule is being used by the Client. For example, the validation
rules of a transaction are validated when that transaction is applied. A rule for a button label is
evaluated when the screen containing that button is initially displayed.
Rules are comprised of Rule Terms. A rule term is any single component of a rule definition and
is represented in the Rule Editor as a single node (see the Rule Editor example later in this chap-
ter.) There are two types of rule terms: those that provide a single piece of data from a property,
Global, constant, or some other such data definition; and Rule Term Functions, which also
return a single piece of data, but as the result of the evaluation of the function. Rule term func-
tions (or simply “functions”) take arguments, which are either rule terms or the return values of
other functions.
Functions also have a an evaluation type and a return type. The evaluation type is the data type
of the value to be returned by the function before that function’s context is considered. The
return type of a function is the data type of the value the function returns after that value has
been converted from its evaluation type to the data type dictated by the function’s context. This is
discussed in Chapter 2 - "The Context of Rules" in greater detail.
Overview of the Rule Editor

The Rule Editor is the tool within the Agentry Editor that allows you to define and edit Rules for
your application. The Rule Editor is displayed from one of several places within the Agentry Edi-
tor. Rules may only be added at the point where they will be used, that is, via the attribute field of
a definition that will use a Rule. For example, a definition within Transactions is the Validation
Rule definition. Within this definition, you can add a new Rule by displaying the Rule Editor
from the Rule attribute field.
The Rule Editor itself is fairly simple, consisting of a small number of fields and buttons, with
most of the area of the screen occupied by the display of the Rule itself. Following is an example
of the Rule Editor, with the key facets highlighted. Following this example, these components are
discussed in more detail.
2
7 8 9
1. Name - The internal name of the Rule Definition. This value must be unique among all
Rule definitions within a given Module.
2. Group - This is the group within which the Rule is organized. This can be useful when
selecting Rules at a later time, as they will be organized into their assigned groups.
3. Description - A description of the Rule and its purpose. As with all definition types in
Agentry, the description is not required, but is recommended.
4. Rule Definition - This portion of the screen displays the actual Rule definition in a tree
control, with the Rule itself at the root node.
5. Reminder - Rules can have a reminder set that will result in a notice being displayed during
publish of the application.
6. Reset Button - Clicking the Reset button will reset the Rule Definition to its state when it
was first displayed in the Editor. For new Rules, this will remove all Rule Terms and Func-
tions from the definition. For existing Rules being edited, this will undo any changes made
to the Rule Definition, resulting in the Rule being as it was prior to the edit.
7. Clear Button - Clicking the Clear button will remove all Rule Terms from the Rule Defi-
nition, resulting in an empty rule.
8. Finish Button - This will save the Rule Definition, including all changes made to it.
9. Cancel Button - Clicking this button will exit the Rule Editor, discarding any changes
made to the Rule definition. If a new rule was being created, it will be discarded and no
Rule will exist within the Module.
Adding and Editing Rule Terms

To add Rule Terms to a rule, whether they be terms or Rule Term Functions, you begin by right
clicking at the location where the term is to be added. This will display a popup menu containing
all of the terms available to be added to the rule. There are also additional tasks that can be per-
formed from this menu including cut, copy, and paste; editing of constant values; and the ability
to view and edit sub-rules. Following is an example of the Rule Editor with the popup menu
open.
In this example, the Conversion Function sub menu is selected, which lists all of the available
Rule Term Functions to be used for converting values from one data type to another.
In addition to the various functions, there is another group of items to select that consist mostly of
other definition types, as well as comments and constants. Selecting one of these items will result
in either the value of the definition or the definition itself being returned, depending on how the
term is used.
When adding or editing a Rule, it is important to understand how the rule is presented in the Rule
Editor. The following example contains a Rule definition, which is then described in more detail.
The overall purpose of this rule is to return to the cost of a number of items. This value is deter-
mined by multiplying the number of items selected in a screen field by the cost of each individual
item. The cost of an individual item is stored in a complex table, Items, which contains records of
each of the items that may be sold, along with various other information, including each item’s
unit cost.
Breaking this rule down, the root node in this tree structure is UpdateItemCost, which is the name
of the Rule definition. Directly below this is the function term PROD. Functions are denoted by
the @ symbol. This function takes two arguments, which are both numerical and will be multiple
by the function. The result of this multiplication will then be returned to the caller of the PROD
function, which, in this case, is the rule itself.
The two arguments to the PROD function in this example are the return value of another function,
COMPLEXTABLE, and the value of the field Qty in the current screen set. This is denoted in the
Rule Editor by the fact that both the COMPLEXTABLE term and the term “:>Current Screen
Set>Current Detail Screen> ‘Qty’ Field” are both child nodes of the node for the PROD.
The COMPLEXTABLE function also takes arguments, four in all. This function returns the value
of a field from a record in the specified complex table. The four arguments to the COM-
PLEXTABLE function are each child nodes of the COMPLEXTABLE node and tell the function
which complex table to read from, which record to look for based on a search value and index,
and the field from the record that is found to be returned.
Overall, it is not important right now to fully understand how each of these functions works. The
main point being described here is how a rule appears in the Rule Editor, specifically the structure
of a function and its arguments, with the arguments displayed as child nodes to the function. Each
of the functions themselves are described in detail later in this guide.
How Rules are Used in Agentry

Within Agentry, the Rule definition is used in a number of different ways by numerous definition
types. A comprehensive list of such places would be difficult to create. However, in general,
Rules are used to perform one of several different tasks. These different tasks are discussed next.
Enable Rules
Rules can be used to enable or disable different definitions within an application. These defini-
tions are those that allow the user to interact with that application. Some examples include Client
Actions, Screens within a Screen Set, and entire Modules. The return value of Enable Rules are
normally treated as Boolean, with true enabling the definition and false disabling it. For example,
an Action that allows the user to edit an object via a Transaction may be disabled if the selected
object is in a state in which it should not be edited by the user. In this case, the disabled, prevent-
ing the user from editing the object.
Initial Value Rules

Initial Value Rules are those rules used to determine the initial value of a property, either in a
Transaction or Fetch. Rules used in this manner return some value that will be the initial value of
the property. When the rule is evaluated is dependent on how the Property is defined and is either
before or after data entry. The return type of rules used in this manner is dependent on the data
type of the property.
Update Rules
Update Rules are those used to update Fields on Detail Screens. These Rules can set the value of
a field based on data entered in another field on the same screen. Ultimately these values are then
set to the value of the property that field displays. Update Rules allow for a field’s display value
to be changed whenever another change occurs that should affect the fields value. For example,
the Rule shown previously, UpdateItemCost, is used as an Update Rule. When the user edits the
Qty (quantity) field on a Detail Screen, the rule is evaluated and the Total Cost field on the same
screen is updated. If the user changes the value of the Qty field, the Update Rule is evaluated
again, and the Total Cost field is updated accordingly. Update Rules allow you to display values
that may change based on changes to other values or conditions. The return type if update rules is
based on the edit type of the field definition.
Validation Rules
Validation Rules are used in Transaction and Fetch definitions. These Rules are used to determine
if a property value is valid or not. The fields in which users enter values contain attributes to
specify some limited validation-type of functionality, such as a range of numeric values, or the
length of a string. However, Validation Rules allow you to validate data entered by the user based
on variable conditions. For example, if a value entered by a user should be greater than one value
and smaller than another, each of which is also entered by the user, a Validation Rule is used.
Both Transactions and Fetches can contain one or more Validation Rules, each of which can vali-
date the value of a Property within the definition. If a Validation Rule fails, the user can then be
prompted to enter new values. Furthermore, this failure can be treated as a warning or error. The
first informs the user of the discrepancy, but does not require them to make any modifications.
The second will force the user to change the value in order to complete the transaction or fetch.
These types of rules return Boolean values, with true treated as valid, and false treated as failure.
Display Rules
Display Rules are those used to directly affect the appearance of the applications user interface.
There are numerous different attributes within the user interface components of an Agentry appli-
cation that can use rules. These include captions for Platforms and Screens, labels for columns,
buttons, and fields; values displayed in header and detail panes; images to be used in List Screen
Icons; and styles to be applied to any of the display components within a screen. These rules may
return string values for components such as labels or captions, or numeric values for items such as
List Screen Icons.
Include Rules
Include Rules are used in certain areas of an application when dealing with Object Collections.
These rules determine which of the objects within a collection are to be included in whatever pro-
cessing is taking place. The most common place for an Include Rule is within a List Screen,
where a rule can be used to determine which objects in a collection should be displayed in the List
Screen’s list control, and which should be excluded. Additionally, certain Rule Function Terms
can take, as one of their arguments, a sub-rule that is used as an include rule. The return type of
include rules is Boolean, where true will include the current object and false will exclude it.
Include rules are evaluated once for each object in the target collection, with the context of the
rule set by the object currently being evaluated by the rule.
Action Rules
Action Rules are those used within a Client Action that contains a SubAction step. This Action
Step can use a rule that returns one of multiple actions that is to be initiated by the SubAction.
This can allow an Action to perform variable sub-actions based on differing conditions.
Sub-Rules
Sub-Rules are those used within other rules. A sub-rule is a rule definition just like any other.
The only difference is that the value it returns is to another rule, rather than to another definition
type. Sub-rules can be defined to accomplish all of the same tasks as other rules and use any of
the functions available. Sub-rules can be useful when there is a particular task that needs to be
performed repeatedly by several other functions. If this task is involved, it may be useful to
define it once in a separate rule, and then use that rule as a sub-rule in other rule definitions where
it is needed.
2
THE CONTEXT OF RULES
TOPICS:
• What is Context
• Rule Data Types
• Context and Return Type
• Context and Target Paths
• Rule Term Functions and Context
12 Chapter 2 - The Context of Rules
What is Context
The concept of a rule’s context is one of the most important to understand when working with
Rules. This is because the context can have a significant affect on both the Rule itself, as well as
the functions that make up the Rule. A rule’s context is determined by how the rule is used, and
by what definition type. A rule that is used by a transaction as a validation rule will have a differ-
ent context then a rule used for an initial value of a property within the same transaction.
Additionally, the Rule’s context will affect its functions, as will the context of each function in
regards to what is calling the function. A function term called by another function expecting a
string value will have a different context then if it is called by a function that is expecting a deci-
mal number.
The context of a rule and its functions has the following affects:
• Return Type - Rule Term Functions do not have a set return data type. Rather, the value
returned by a function will always be of a type expected by that which is calling the func-
tion. This is also true of the rule definition itself. The value ultimately returned by the
rule will be converted to the type expected by the definition using the rule.
• Target Paths - Any target paths within a rule are affected by that rule’s context. If the
property of an object is included in a rule, how that property is found and its value re-
turned is affected by the context of the rule. If no such property is found, a null value will
be returned by the term containing the target path.
• Rule Term Function Behavior - Many rule term functions will behave differently based
on the context in which the function is called. A prime example of this is the @SUM
function. This function, when called in a numerical context, will treat its arguments as
numbers and add the values together, returning the sum. If, however, the function is
called in a string context, the arguments will be treated as strings and concatenated togeth-
er into a single string value that will be returned by the function. In the case of the @SUM
function, both the argument data types, as well as the function’s processing are affected by
the context in which the function is called.
To define the term more precisely, context is the way in which a Rule or Rule Term Function is
called and that affects the behavior, data types, and target path resolution when that rule is evalu-
ated.
This chapter will explain this concept in detail, including examples where different contexts result
in significant differences in the behavior of the same rule. Also, the various data types within
rules are discussed, as it is important to understand these types to fully understand the affects of
context on a rule.
Chapter 2 - The Context of Rules 13
Rule Data Types

The data types of rules include all of those data types of properties. In addition, there are two data
types specific to rules, Actions and Rules. Following is a list of the data types within rules.
• Boolean - A data type for true or false, where any value is true and a null is false.
• Collection - A container for a group of objects of the same type.
• Complex Table Selection - A data type containing the key value of a complex table re-
cord.
• Data Table Selection - A data type containing the key value of a data table record.
• Date - The data type used to store calendar dates. Values are stored as the number of days
before or after epoch, which is January 1, 2001.
• Date and Time - The data type used to store calendar dates and times of day. Values are
stored as the number of seconds before or after epoch, which is 12:00:00 am January 1,
2001.
• Time - The data type used to store time of day values. Values are stored as the number of
seconds since midnight.
• Decimal Number - The data type used to store numerical values that may contain a frac-
tional portion.
• Duration - The data type to store a duration of time. Values are store in seconds.
• External Data - The data type used to associate external files with objects and transac-
tions in the application.
• Identifier - The data type used to store an integral value that is used as a unique identifier
for an object.
• Integral Number - The data type used to store numerical values that are whole numbers
only.
• Object - The data type used to have a single object as a property of a fetch, transaction, or
another object. (This data type is rarely, if ever, used in a Rule.)
• Signature - The data type used to store a signature written on the screen of the client de-
vice. (This data type is rarely, if ever, used in a Rule.)
• String - The data type used to store alphanumerical values.
• Client Action - This data type is used to return an Action definition. Action definitions
are normally only returned by rules used as Action rules for sub-action Client Steps. The
action returned by the rule is the one initiated by the sub-action step.
• Rule - A rule returned by a term is treated as a sub-rule and is evaluated for a return value
used by the parent rule or a function within the parent rule.
There are several Rule Term Functions available that are intended to deal specifically with one or
more of these data types. Others are intended to use various data types depending on context.
Context and Return Type

The return type of both a rule, and the functions within a rule, is determined not by the function
itself, but rather the context in which the rule or function is called. Functions do have an evalua-
tion type. The evaluation type is defined as the data type the function’s return value is in prior to
its conversion based on the context. It is important to know a function’s evaluation type, as this
type will affect the final value returned by the function or rule, as it is a result of the conversion of
the evaluation type to the return type.
An example of this is the @PROD function. This function multiplies two given values and
returns the product. During evaluation of this function, the values are treated as numerical, either
integers or decimals, depending on the arguments. This is the evaluation type of the function.
However, it is completely valid for the context of the function to result in this value being con-
verted to a string. In this case, if the values 3 and 5 are multiplied, and the result is 15, the return
value will be the string “15”. This can be the case if, for example, the rule is setting the value of a
string property, or if the rule’s return is being passed to a function that is expecting a string argu-
ment. There are many other situations when the context results in this type of conversion.
Looking at this example from the standpoint of the @PROD function’s arguments, context will
also affect how these values are treated. If, using the previous example, rather than the numerical
values of 3 and 5 being passed to the function, if the terms used as arguments are the strings “3”
and “5”, the values will be converted to integers before being evaluated by the function. In this
case, the context is set by the @PROD function, resulting in the conversion from a string to a
numerical type.
In order to understand this aspect of context, it is important to understand the data types of the
caller of a term, function, or rule. The following contains a list of the various callers and the
affect each has on context in relation to the return type.
• Initial Values - When a value is returned by a rule to a property definition for an initial
value, it is the data type of that property that affects the rule’s return type. String proper-
ties will result in a string return type, decimals result in conversion of the value to a deci-
mal, etc.
• Update Rules - Update rules are those used to set the display values of detail screen
fields. The value of these rules are converted to the data type that matches the field’s edit
type. Similar to Initial Value rules, this can be any of the supported data types of Agentry.
• Captions, Labels, and other Display Components - Any component of the user inter-
face that is not a list column or detail screen field will result in a conversion to a string val-
ue. All display text for these user interface components are treated as strings.
• Validation Rules - The validation rule definition type in fetches and transactions will
convert the return from any rule to a Boolean value. Validation rules require a true or
false result to validate the data entered by a user for either a transaction or fetch.
• Definition Names - When using rules to set styles or images to be used in display compo-
nents, the return value of a rule is converted to a string that is treated as the name of the
definition type expected by that attribute. For example, styles can be set dynamically to
be applied for a button control on a list screen by using a rule. The value returned by such
a rule is treated as a string. This value is then used to locate the proper style definition to
apply to the button. The exception to this is when image lists are used for list screen icons.
In this case, the return value is converted to an integer, as it is treated as an index value to
display the proper icon image from the image list for the list screen record.
• Enable Rules - Enabling various definition types within Agentry is an either-or situation,
true being enabled and false disabled. Therefore, the return value of an enable rule is con-
verted to a Boolean value.
• Rule Term Function Arguments - Any term that is used as an argument to a function
will be converted to the data type the function expects for that argument. This includes
both the return values from other functions, as well as rule term values providing a data
value.
As a part of this conversion, it is important to understand what occurs when one type is converted
to another. There are certain type-to-type conversions that can be considered “safer” than others
in relation to data preservation. For example, converting an integer to a string value would be
considered a safe conversion. The integer value of 12 will be converted to “12” as a string with
no loss of data or changing the value. However, converting a value from a string to an integer
would not be considered as safe. For example, how would the string “Hello” be represented as a
number? The answer is it cannot. The result of this conversion would be an integer with a value
of 0. However, if the string contains only numeric characters, such as “12.98”, and it is to be con-
verted to a decimal, the conversion would not result in lost or changed data. The result would be
the decimal value of 12.98.
This type of conversion, string to decimal, would still not be considered safe, as there is no guar-
antee that the string will always contain only numeric values. By and large, the resulting value of
a conversion, consider what makes sense. For example, does converting a string that contains the
text “Hello” to a numeric type result in anything meaningful? The answer to this question is most
likely no. Following, some of the general rules for type-to-type conversion are discussed. Addi-
tionally, the various conversion types are listed in Appendix A - "Conversion Types". Review
this appendix after you have become more familiar with rules in general and the affect of context
on return type specifically. It includes the type-to-type conversion, an indicator as to whether or
not the conversion is considered safe, and description of what to expect from such a conversion.
Converting to Booleans
Whenever a value is converted from any other data type to a Boolean, the result will be a true or
false value. If the source type contains a null value, such as 0 for a numeric value, or an empty
string value, the result will be false. Any other value will be treated as true, including negative
numeric values, or whitespace string values.
Converting to Strings
By and large, converting from any other data type to a string is considered the safest conversion
that can be performed. In most cases, the value of the source type will be converted to a string
without the loss of any values due to truncation or other concerns with conversion. There are,
however, some exceptions to this. Following is a list of the handful of data types that should not
be converted to the string data type:
• Collection
• External Data
• Object
• Signature
Fortunately, there is not normally a need to convert such types to a string, as the results would be
meaningless. For example, what would the string value of an object collection be?
Other than these data types, conversion to a string will normally result in a safe conversion.
Conversion to Collections, Signatures, External Data, and Objects

Conversion to the collection, signature, external data, and object data types should rarely, if ever,
be performed. These data types are specific to certain usages and, as a result, should not be con-
verted to another data type or from another data type.
Conversion to Dates and Times

The three data types dealing with dates and/or times, Date, Time, and Date and Time, can be con-
verted safely from an Integral value. The value of the integer will be treated differently by each
type.
For a Date value, the value will be treated as the number of days since the epoch date, which for
Agentry applications is January 1st, 2001. Dates prior to epoch are negative.
For a Time value, the integer must be positive, and will be treated as the number of seconds since
midnight.
For a Date and Time value, the integer will be treated as the number of seconds since epoch,
which is 12:00:00 a.m. on January 1, 2001. A Date and Time prior to epoch is represented by a
negative value.
Conversion to Numerical Types

There are four numerical data types in Agentry Rules: Integrals, Durations, Identifiers, and Deci-
mals. Of these, the first three are all integral values, with the differences in the data types a result
of how they are used. Decimals contain a fractional portion. Converting a value from another
data type to one of these numerical values mayor may not be safe, depending on the source type.
Furthermore, converting from one of these numerical types to another can also have varied
results. Converting to and from Integers, Durations, and Identifiers is considered safe, as all of
these values contain integral values. Converting from a Decimal to one of the other numerical
types, however, will result in the fractional portion of the value being truncated. For example, the
decimal value 12.98, if converted to an Integral, will result in the value 12. The decimal is trun-
cated without any rounding.
Conversion of dates and/or times to a numerical type is also considered safe. The resulting value
will depend on the data type of the source.
Converting from a Date value to a numerical value will result in an integer that represents the
number of days before or after epoch, with a negative value for those that are before it.
Converting from a Time value will result in an integer that represents the number of seconds since
Midnight. This value will always be positive.
Converting from a Date and Time value to a numerical value will result in the number of seconds
before or after epoch, with a negative value for those that are before it.
Strings may also be converted to a numerical type. However, this type of conversion is considered
unsafe, as there is no guarantee that the string value contains only numerical data. Any non-
numeric characters, that is any character other than 0-9, - or +, and . will not be converted and will
be lost, as will any numeric characters following a non-numeric.
Context and Target Paths

The context of a rule can affect the target paths contained within that rule. A target path is the
path from the definition that has set the context of the rule to another definition whose value is
used by the rule. This may be as simple as another property within the same transaction, or as
complex as an action in a different module.
The main point to note regarding the context of a rule and the rule’s target paths is that this only
becomes a concern when the rule is reused by a different definition than the one for which it was
originally written. As an example, an Action that displays the details of a customer may have an
enable rule that enables or disables the action based on the status property in a Customer object.
If the status is inactive, the Action will be disabled. This rule may also be reused by another
Action that initiates a transaction to add new orders to the Customer. The target path to the status
property of the rule will be defined as the current Customer object’s status property. This will
result in no issues, as the current Customer object is valid in both cases.
However, if the same rule were used as an enable rule for another Action that is defined to display
the details of a user’s travel expenses, it would not work property. In this case, it is not likely that
there is a current Customer object, and therefore, the target path to the status property cannot be
resolved. In this case, the Rule will not evaluate correctly and may resulting undesirable behavior
on the Client.
To prevent problems with target paths, review the definition of any rule when it is to be reused. If
a target path will not be valid for the new usage, a new rule should be defined. Otherwise, reuse
the existing rule to save time and resources.
Context and Rule Term Function Behavior

Like rules, rule term functions also have a context. This context is set by the caller of the func-
tion, which may be the same as the caller of the rule, or it may be another term within the rule.
The context of a rule term function can, as explained previously, affect the return type of the func-
tion, resulting in a conversion from the functions evaluation type to another data type prior to the
value being returned. Additionally, the context can also affect the overall behavior of a function,
resulting in different processing of its arguments when the function is evaluated.
A good example of context affecting a rule’s behavior is the @SUM function. This function can
be used to add together two or more numeric values and then return the sum. Additionally, this
function can also be used perform a string concatenation on its arguments. This differing behav-
ior is determined, not by the data type of the arguments, but rather the data type enforced by the
function’s context.
For example, assume the @SUM function contains three arguments, 2, 4, and 6. If the @SUM
function is in a context in which an integral value is expected, the return value of this call will be
12 (2+4+6). However, if the same arguments are passed to the function, but in this case the con-
text of the function is a string, the return value will instead be “246”. In this latter case, the argu-
ment values are treated as strings and concatenated together. Thus, both the behavior of the
function is affected by its context, as are the data types of its context.
There are other functions available within rules to which this situation applies. Conversely, there
are other functions that the context does not affect in this manner. The descriptions of the rule
functions contained later in this guide provide this information where applicable.
3
RULE TERM FUNCTIONS
TOPICS:
• Overview of Rule Functions
• The Rule Editor: A Closer Look
• Rule Term Functions Described
22 Chapter 3 - Rule Term Functions
Overview of Rule Term Functions

Rule Term Functions are the heart of must rule definitions within an application. While there are
situations where a rule may be defined to contain a single rule term that returns the value of a
Global or other such data definition type, most rules are more complex than this, consisting of
multiple function calls.
Most Rule Term Functions, or simply functions, take one or more arguments, each of which
passes a data value to the function. When the function is evaluated, these data values are pro-
cessed in some manner. The result of this processing is a single return value that is passed to the
function’s caller. As discussed in the previous chapter, this value has an evaluation data type that
then may or may not be converted to a different return type, based on the context of the function
call.
There are numerous functions available to be used in a rule, organized into several groups:
• Conversion Functions - Conversion functions are those that convert a value to a different
data type. These functions are used to set the context of other functions so that the desired
data type is returned.
• Logical Functions - Logical functions are those that provide the comparison and decision
making functionality to a rule. This includes if-then-else logic, case logic, and greater
than, less than, and equality comparisons, among others.
• Math Functions - Math functions are those that are used to perform mathematical opera-
tions on numerical values. This includes addition, subtraction, multiplication, division,
and modulus operations. It also includes other mathematical functions, such as rounding,
and working with significant digits.
• Property Functions - Property functions are those that operate on properties, usually of a
certain data type. For example, there are several property functions for use specifically
with the external data property type.
• String Functions - String functions are those specifically for manipulating string values,
including concatenation and parsing operations, as well as others.
• System Functions - System functions are those that provide access to information about
the Agentry Client’s host system, or information that is general to the client. This can be
information such as the system’s time and date, or the user ID of the current user.
• Table Functions - The table functions are those that allow for the retrieval of records
from complex tables and data tables.
The grouping of these functions in this manner does not in any way restrict where or when they
can be used. Any Rule can contain any of these functions, regardless of how or where the rule is
used. The purpose of this grouping is purely logical to make it easier to reference the desired rule
more quickly.
Strong and Loose Typed Function Arguments

The arguments to certain functions must always be of a specific data type, or will always be con-
verted to a specific data type upon evaluation of the function. Others may accept multiple data
types for the same argument, depending on the context of the function, or merely on the nature of
Chapter 3 - Rule Term Functions 23
the function itself. Those functions that are more rigid in their argument data types are referred to
as strongly typed. The others are loosely typed. The Rule definition type as a whole is loosely
typed, as values are converted from one data type to another where needed, rather than errors
occurring. However, for those functions that are strongly typed, the data type expected by the
argument should be respected in the definition of the rule. This is the primary purpose of the Con-
version functions, which will set the context of a rule term such that the resulting value is in the
desired data type.
It is also important to understand what data types are supported by a function when its value is
returned. The evaluation type of certain functions may not be converted to the data type of the
context. In this case, the return value is always the same for the function, regardless of the func-
tion’s evaluation. For the numerical data types this is always 0 or 0.0 (integral or decimal), for
Boolean this is always false, and for strings this is always an empty string. For example, the func-
tion @TOTAL is used to add up the values of a specified object property for each object within a
collection. If this function’s context is such that it is to return a string, the return value will
always be an empty string for this function call, as this data type is not supported by the TOTAL
function.
The supported and unsupported return types of each function are provided as a part of the descrip-
tion of each function contained in this chapter. Likewise, the data types of a functions arguments
are also provided. In this case, this is the data type to which the argument value will be converted
when the function is evaluated. If this data type is context specific, this will also be noted.
More on the Rule Editor

The Rule Editor within the Agentry Editor was introduced briefly in the first chapter. Here, we
will discuss it further, focusing on from where the Editor can be started, and on how to use it to
both create and edit Rule definitions.
The Rule Editor displays a rule definition in a tree control. There is a single root node to this con-
trol, which represents the rule itself. Also, there can be only one rule term that is a direct child of
the rule node. This is normally a function term that in turn contains one or more arguments, some
of which may be other functions. An argument to a function is displayed as a child node to the
node of the function node.
To add an argument to a function, you begin by right-clicking on the function. This will display
the popup menu, shown next:
This menu contains several items. The first group allows you to cut, copy, and past rule terms, fol-
lowed by the group of items that allow you to work with sub-rules.
After this is a group of sub-menus, each of which contains several rule term functions. Each sub-
menu contains the functions for a group of functions available for use in a rule.
The next group contains the items for adding rule terms, such as values from Globals, comments,
or hard-coded values, as well as those values from other definitions, such as properties or actions.
Once an item is selected here, it will be placed in the rule as a child node to the one that you orig-
inally right-clicked on. If the term added is a function, you can then right-click that node to add
arguments to the function.
Rule Term Functions

The Rule Term Functions provided to you in the Rule Editor are the heart of almost any Rule you
will develop. Following, each the rules available to you are described in detail. This includes
information on the purpose of the function, the arguments it takes, the evaluation type of each,
and the supported return types.
These descriptions are organized according to the categories of functions, as they are presented
within the Rule Editor.
Conversion Functions
The Conversion functions are those that allow you to set the context of a rule term so that the
value of that term is converted to the desired type. Following is a summary of the functions that
fall into this category.
• DECIMAL_NUMBER - This function converts the return value of the given term to a
decimal value. This function takes a single argument of any other non-decimal data type.
• INTEGRAL_NUMBER - This function converts the return value of the given term to an
integral value. It takes a single argument of any other non-integral data type.
• SIG_DECIMAL_NUMBER - This function converts the return value of the given term
to a decimal value, taking into account the rules of significant digits. It takes a single ar-
gument of any other non-decimal data type.
• STRING - This function converts the return value of the given term to a string value. It
takes a single argument of any other non-string data type.
@DECIMAL_NUMBER
The DECIMAL_NUMBER function converts the value of its argument to a decimal number. The
argument may be of any other non-decimal data type. This value will then be returned by the
function to its caller. The value of the argument must contain only numeric characters for conver-
sion and will stop conversion on the first non-numeric character found.
Arguments:
• numericValue - This is the single argument taken by this function. It contains the value to
be converted by the function to a decimal value.
Evaluation Type: Decimal Number
Supported Return Types:
• Decimal Number
• Integral Number
• Property
• String
Examples:
Decimal Return: 12.34

Integral Return: 12
Property Return: Property at position 12
String Return: “12.34”
Decimal Return: 2.0

Integral Return 2
Property Return: Property at position 2
String Return: “2”
@INTEGRAL_NUMBER
The INTEGRAL_NUMBER function converts the given argument to a integral value. The argu-
ment may be of any other non-integral data type. The argument value will be converted, starting
with the first numeric character, and will continue until the end of the value, or until a non-
numeric character is encountered.
Arguments:
• numericArg - The non-integral value to be converted to an integral by the function.
Evaluation Type: Integral Number
• Decimal Number
• Integral Number
• Property
• String
Examples:

Integral Return: 12
Property Return: The property at the 12th position.
String: “12”
Decimal Return: 2.0

Integral Return: 2
Property Return: The property at the 2nd position.
String: “2”
@SIG_DECIMAL_NUMBER
The SIG_DECIMAL_NUMBER function converts the value of the given argument to a decimal
number, using its second argument to determine the number of significant digits the returned
value should contain. The first argument will be converted, starting with the first character and
continue until a non-numeric value is found, or until the end of the value is reached.
Arguments:
• numericArg - the non-decimal value to be converted by the function
• intSigDigits - This argument must be an integer and contains the number of significant
digits the returned value is to contain.
• Decimal Number
• Integral Number
• Property
• String
Examples:

Integral Return: 12
String: “12.3”

Integral Return: 2
Property Return: The property at the 2nd position
String: “2.00”
@STRING
The STRING function converts the value of the given argument to a string. The given value may
be of any non-string data type. The given value can contain any alphanumeric characters, plus
other printable symbols, as well as whitespace. Date and time values may also be converted to
strings, the format for which is dictated by the property containing the date and/or time value.
Arguments:
• characterArg - The value to be converted to a string value.
Evaluation Type: String
• Decimal
• Integral
• Property
• String
Examples:

Integral Return: 12
Decimal Return: 2.0

Integral Return: 2
Property Return: The property at the 2nd position.
String Return: “2He1llo”
Logical Functions
Logical functions are those that provide the decision making functionality to the Rule definition.
This includes if-then-else logic, case statements, equality checks, and inclusive and exclusive
“and” and “or”, as well as others.
The evaluation type of most of the logical functions is Boolean. More often then not, these func-
tions take other functions as arguments. The logical functions allow you to make the necessary
decisions within a Rule to return differing values based on variable conditions.
Most of the rules defined for an Agentry application will contain one or more logical functions, as
these functions provide the decision making functionality that is usually the overall purpose of
using a rule. In the following descriptions, many of the examples used are more simplistic than
the real-world applications of these rules. The primary purpose is to show basic usage. It is
important to remember that the return value of a function may be used as a n argument to any
other function, and that this is how you will most likely implement your rules when developing
real-world applications.
@AND
The AND function performs a logical conjunction between its arguments. Each of its argument is
evaluated in turn as a Boolean, beginning with the first argument. If any argument is evaluated as
false, the return value is false. Otherwise, the function returns true. The function must have at
least two arguments and may contain up to as many as is needed.
Arguments:
• boolArg1 - The first argument to be evaluated by the function for true or false. May be
any data type that can be treated as a Boolean value.
• boolArg2 - The second argument to be evaluated by the function for true or false. May be
any data type that can be treated as a Boolean value.
• boolArgN - The third through N optional arguments to the function to evaluated as true or
false. May be any data type that can be treated as a Boolean value.
Evaluation Type: Boolean
• Boolean
• Decimal Number
• Integral Number
• String
Examples:
Given: All Globals are TRUE

Boolean Return: TRUE
Decimal Return: 1.0
Integral Return: 1
String Return: “TRUE”
Given: Enable.allowEditActions is FALSE
Boolean Return: FALSE
Decimal Return: 0.0
Integral Return: 0
String Return: “FALSE”
@CASE
The CASE function provides switch-case logic, allowing for the evaluation of a single test value
for the purpose of returning one of a multiple number of possible values. The CASE function
takes a variable number of arguments, but with a minimum of three. The first argument is evalu-
ated as an Integral Number. This value is then treated as a positional value for one of the other
arguments to the function, with the second argument at position 1. The argument at the position
specified by the position argument is then returned. The data type of the other functions varies
depending on the function’s context. For example, if the context of the function call is a string,
the arguments 2 through N of the function will be treated as strings.
Arguments:
• intPosition - The argument whose values specifies which of the remaining arguments is to
be returned by the function. This value must be an integral value.
• caseArg1 - The argument whose value will be returned by the function if intPosition is
equal to 1. The value may be of any data type and will be treated as the data type of the
function call’s context. This argument is required.
• caseArg2 - The argument whose value will be returned by the function if intPosition is
equal to 2. The value may be of any data type and will be treated as the data type of the
function call’s context. This argument is required.
• caseArg3-N - The arguments whose values will be returned by the function if intPosition
is 3-N. The values of these arguments may be of any data type and will be treated as the
data type of the function call’s context. These arguments are optional.
Evaluation Type: Context Dependent
• Boolean
• Decimal Number
• Integral Number
• Property
• String
Examples:
Given: InitialVal.propInitVal is 2
Decimal Number Return: 2.0
Integral Number Return: 2
Property Return: The property at the second position.

Given: InitalVal.propInitVal is 3
Property Return: NULL property (There is no property at position “C”)
String Return: “C”
Given: InitialVal.propInitVal is 4
Property Return: NULL property
String Return: empty string
@CASE_INT
The CASE_INT function is used to return a single value from a variable list of multiple possible
returns. The first argument, intTestVal, to the function is converted to an integral value. The last
argument to the function is its default return value and is optional. The remaining arguments are
provided in pairs. The first argument in a pair is the value to which the intTestVal is compared. If
these two values are equal, the second value of the pair is returned by the function. The compari-
son between intTestVal and the first argument of each pair is performed as an integer comparison.
The value of the second argument in each pair may be of any data type and is converted to the
data type dictated by the context. If none of the comparison arguments match the intTestVal
argument, the value provided as the default argument is returned. If no default is provided, the
default value of the context’s data type is returned.
Arguments:
• intTestVal - An integral value tested against each of the comparison arguments in the ar-
gument pairs that follow. This argument must be an integral value and is a required argu-
ment.
• intComparisonArg1 - The first argument in a pair that is compared with the intTestVal ar-
gument. This value must be an integer and is required.
• valueArg1 - This argument contains the value returned by the function if
intComparisonArg1 is equal to intTestVal. This argument is required.
• intComparisonArg2-N - The first arguments in each pair of arguments that each contain
the value to be compared to intTestVal. These arguments are optional, but there are usual-
ly several pairs of comparison and value arguments in a single CASE_INT function call.
• valueArg2-N - The second arguments in each pair of arguments that each contain the val-
ue to be returned by the function if the corresponding comparison argument from the pair
is equal to intTestVal.
• defaultValArg - The defaultValArg argument is the final argument to the function and
contains the value to be returned by the function if none of the comparison arguments
match the intTestVal. This argument is optional.
• Boolean
• Decimal Number
• Integral Number
• Property
• String
Examples:

Decimal Return: 0.0
Integral Return: 0
Property Return: NULL Property
String Return: “Four”

Decimal Return: 0.0
Integral Return: 0
@CASE_STRING
The CASE_STRING function is used to return a single value from a variable list of multiple pos-
sible returns. The first argument, strTestVal, to the function is converted to a string value. The
last argument to the function is its default return value and is optional. The remaining arguments
are provided in pairs. The first argument in a pair is the value to which the strTestVal is com-
pared. If these two values are equal, the second value of the pair is returned by the function. The
comparison between strTestVal and the first argument of each pair is performed as a string com-
parison. The value of the second argument in each pair may be of any data type and is converted
to the data type dictated by the context of the function call. If none of the comparison arguments
match the strTestVal argument, the value provided as the default argument is returned. If no
default is provided, the default value of the context’s data type is returned.
Arguments:
• strTestVal - A string value tested against each of the comparison arguments in the argu-
ment pairs that follow. This argument must be a string value and is a required argument.
• strComparisonArg1 - The first argument in a pair that is compared with the strTestVal ar-
gument. This value must be an string and is required.
• valueArg1 - This argument contains the value returned by the function if
strComparisonArg1 is equal to strTestVal. This argument is required.
• strComparisonArg2-N - The first arguments in each pair of arguments that each contain
the value to be compared to strTestVal. These arguments are optional, but there are usual-
ly several pairs of comparison and value arguments in a single CASE_STRING function
call.
• valueArg2-N - The second arguments in each pair of arguments that each contain the val-
ue to be returned by the function if the corresponding comparison argument from the pair
is equal to strTestVal.
• defaultValArg - The defaultValArg argument is the final argument to the function and
contains the value to be returned by the function if none of the comparison arguments
match the intTestVal. This argument is optional.
• Boolean
• Decimal Number
• Integral Number
• Property
• String
Examples:

Decimal Return: 3.0
Integral Return: 3
Property Return: The property at the third position.

Decimal Return: 0.0
Integral Return: 0
@EQBOOL
The EQBOOL function takes two or more arguments, each of which is evaluated as a Boolean
value. If all arguments have the same Boolean value, that is all of the arguments evaluate to
TRUE, or all of the arguments evaluate to FALSE, the function will return true. Otherwise, it will
return false.
Arguments:
• boolArg1 - This is the first argument evaluated by the function. This value is evaluated as
a Boolean. All remaining arguments must have the same Boolean value as this argument
for the function to return TRUE. Otherwise will return FALSE. This argument is re-
quired.
• boolArg2 - This is the second argument to the function and is evaluated as a Boolean.
This argument is required.
• boolArg3-N - These are the 3rd through N arguments to the function, each evaluated as a
Boolean. These arguments are optional.
• Boolean
Examples:
Given: Each Global has a value of TRUE.

Given: Each Global has a value of FALSE.
Given: actionSupported and allowEditActions are TRUE, useAction is FALSE.
@EQDEC
The EQDEC function takes two or more arguments, each evaluated as a decimal value, and com-
pares them for equality. If all argument values are equal, this function returns true. If any value
or values are found to be different, it returns false.
Arguments:
• decArg1 - This is the first argument, evaluated as a decimal number, to be compared to the
other arguments to the function. This argument is required.
• decArg2 - This is the second argument, evaluated as a decimal number, to be compared to
the other arguments to the function. This argument is required.
• decArg3-N - These are the 3rd through N arguments, each evaluated as a decimal number,
to be compared with the other arguments to the function. These arguments are optional.
• Boolean
Examples:

@EQNUM
The EQNUM function takes two or more arguments, each evaluated as an integral number, and
compares them for equality. If all argument values are equal, this function returns TRUE. If any
value or values are found to be different, it returns FALSE.
Arguments:
• intArg1 - This is the first argument, evaluated as an integral number, to be compared to the
other arguments to the function. This argument is required.
• intArg2 - This is the second argument, evaluated as an integral number, to be compared to
the other arguments to the function. This argument is required.
• intArg3-N - These are the 3rd through N arguments, each evaluated as an integral number,
to be compared with the other arguments to the function. These arguments are optional.
• Boolean
Examples:

@EQSTRING
The EQSTRING function takes two or more arguments, each evaluated as a string, and compares
them for equality. If all argument values are equal, this function returns TRUE. If any value or
values are found to be different, it returns FALSE.
Arguments:
• strArg1 - This is the first argument, evaluated as a string, to be compared to the other argu-
ments to the function. This argument is required.
• strArg2 - This is the second argument, evaluated as a string, to be compared to the other
arguments to the function. This argument is required.
• strArg3-N - These are the 3rd through N arguments, each evaluated as a string, to be com-
pared with the other arguments to the function. These arguments are optional.
• Boolean
Examples:

@IF
The IF function provides the if-then-else/else if logic to the Rule definition type. Using this func-
tion, decisions can be made based on the values of other terms. The function can take a variable
number of arguments, and, based on the arguments, will behave slightly differently. First, it can
take a single argument whose value is evaluated as a Boolean. If this argument is true, the IF
function will return true; otherwise it will return false.
Second, the function can take an odd number of arguments, numbering more than one, to provide
the if-then-else/else if logic. The first, or “if”, argument in each pair is evaluated as a Boolean. If
it is true, then the second, or “then”, argument is evaluated by the function the resulting value is
returned. If it is false, the first, or “else if”, argument of the next pair is returned, and so on. If
none of the if arguments evaluate to true, the last, or “else”, argument to the function is evaluated
and the resulting value is returned.
Finally, the IF function can take an even number of arguments, 2 or more, to provide if-then-else
if logic, without a final else. In this case, the function behaves the same as if there are an odd
number of arguments, with the exception of the final “else” behavior. In this case, if all of the “if”
arguments are false, the function will return the default value of the data type dictated by the con-
text of the function call, e.g., FALSE, 0, etc.
Arguments (1st Form - 1 Argument):
• boolArg - This argument is evaluated as a Boolean value and the result of this evaluation
is returned. That is, if this argument evaluates to TRUE, the function returns TRUE, if
FALSE, the function returns FALSE. In this form, this is the only argument to the func-
tion.
Arguments (2nd and Third Forms - Multiple Arguments):
• boolIfArg1 - This is the first argument to the function and is evaluated as a Boolean. If
this argument evaluates to TRUE, then the thenArg1 argument is evaluated and its value is
returned. In this form of the IF function, this argument is required.
• thenArg1 - This is the term that is evaluated by the function and the resulting value re-
turned if boolIfArg1 is TRUE. If boolIfArg1 is FALSE, this argument is not evaluated. In
this form of the function, this argument is required.
• boolElseIfArg2-N - These arguments to the function are each evaluated as a Boolean.
Each is evaluated if the preceding boolElseIfArgN (or boolIfArg1) argument evaluates to
FALSE. If a boolElseIfArgN evaluates to true, its corresponding thenArgN is evaluated
and the resulting value is returned by the function. These arguments are optional.
• thenArg2-N - Each of these arguments immediately follow their corresponding boolElseI-
fArgN arguments. If their corresponding “else if” argument evaluates to true, the the-
nArgN argument is evaluated and the resulting value is returned by the function.
• elseArg - If none of the boolIfArg or boolElseifArg terms evaluate to true, the elseArg ar-
gument is evaluated by the function, and the resulting value is returned. This argument is
required in the second form, but should not be present in the third form of the IF function.
Evaluation Type (1st Form): Boolean
Evaluation Type (2nd and 3rd Forms): Context Dependent

• Boolean
• Decimal Number
• Integral Number
• Property
• String
Examples - 1st Form:
Given: All Globals are True

Boolean Return: True
Decimal Return: 1.0
Integral Return: 1
Property Return: <Not Supported in this Form>
String Return: “TRUE”
Given: Global Enable.actionSupported is FALSE, others are TRUE
Decimal Return: 0.0
Integral Return: 0
Property Return: <Not Supported in the Forms>
String Return: “FALSE”
Examples - 2nd Form:

Given: Global Enable.actionSupported is TRUE
Decimal Return: 0.0
Integral Return: 0
String Return: “Actions Supported”
Given: Global actionSupported is FALSE, allowEditActions TRUE.
Decimal Return: 0.0
Integral Return: 0
String Return: “Edits Allowed”
Given: All Globals are FALSE
Decimal Return: 0.0
Integral Return: 0
Property Return NULL Property
Examples - 3rd Form:
Given: All Globals are FALSE

Decimal Return: 0.0
Integral Return: 0
Property Return NULL Property
@NAND
The behavior of the NAND function is dictated by its context. It takes a variable number of argu-
ments from 1 to N. In general, the purpose of this function is to negate the value of its argument
or arguments. It supports three of the return data types: Boolean; Decimal Number; and Integral
Number. If the context of the function call is Boolean, the function will evaluate all of the argu-
ments as Booleans. If all arguments evaluate to TRUE, the NAND function will return FALSE.
If one or more arguments are FALSE, it will return TRUE.
When the context is either a Decimal Number or Integral Number, the function takes only one
argument of the corresponding data type. The return value is the negative of the value given. So,
1.2 will return -1.2, -3 will return 3, etc.
Arguments:
• valueArg1 - This argument contains the value to be negated by the NAND function. This
argument is required in all contexts. For the Decimal and Integral Number types, this is
the only argument to the function, with any additional arguments being ignored. This ar-
gument is evaluated as the data type dictated by the function call’s context.
• boolArg2-N - These arguments are only evaluated by the function when it is called in a
Boolean context. Each of these optional arguments, along with valueArg1, are evaluated
as Booleans by the function. If any one of these values is FALSE, the function will return
TRUE. Otherwise it will return FALSE.
• Boolean
• Decimal Number
• Integral Number
Examples (Boolean Context):
Given: All Globals are TRUE:

Given: Enable.allowEditActions is FALSE:
Examples (Decimal and Integral Context):
Decimal Return: -1.1

Integral Return: -1

Integral Return: -3

Integral Return: 12
@NOR
The behavior of the NOR function is dictated by its context. This function takes a variable num-
ber of arguments, the data types for which are also dictated by the function call’s context. The
function supports three of the return data types: Boolean; Decimal Number; and Integral Number.
If the context of the function call is Boolean, the NOR function will evaluate each argument as a
Boolean and return TRUE if all of its arguments are FALSE. If any one argument is TRUE, the
function will return FALSE. If the function is evaluated in a Decimal or Integral Number context,
each of its arguments are evaluated as a decimal or integral number type. The function subtracts
each of the argument values for arguments 2 through N from the value of argument 1 and returns
the result.
Arguments:
• valueArg1 - The first argument to be evaluated by the function. The data type of this argu-
ment is the same as the data type of the context in which the function is being evaluated.
• valueArg2-N - The optional arguments to the function, each of which is evaluated as the
same type as is dictated by the context of the function.
• Boolean
• Decimal Number
• Integral Number
Given: All Globals are FALSE:

Given: Enable.actionSupported is TRUE:

Integral Return: -6
@NOT
The behavior of the NOT function is dictated by its context. It takes a variable number of argu-
ments from 1 to N. In general, the purpose of this function is to negate the value of its argument
or arguments. It supports three of the return data types: Boolean; Decimal Number; and Integral
Number. If the context of the function call is Boolean, the function will evaluate all of the argu-
ments as Booleans. If all arguments evaluate to TRUE, the NOT function will return FALSE. If
one or more arguments are FALSE, it will return TRUE.
When the context is either a Decimal Number or Integral Number, the function takes only one
argument of the corresponding data type. The return value is the negative of the value given. So,
1.2 will return -1.2, -3 will return 3, etc.
Arguments:
• valueArg1 - This argument contains the value to be negated by the NOT function. This ar-
gument is required in all contexts. For the Decimal and Integral Number types, this is the
only argument to the function, with any additional arguments being ignored. This argu-
ment is evaluated as the data type dictated by the function call’s context.
• boolArg2-N - These arguments are only evaluated by the function when it is called in a
Boolean context. Each of these optional arguments, along with valueArg1, are evaluated
as Booleans by the function. If any one of these values is FALSE, the function will return
TRUE. Otherwise it will return FALSE.
• Boolean
• Decimal Number
• Integral Number
Given: All Globals are TRUE:

Given: Enable.allowEditActions is FALSE:

Integral Return: -1

Integral Return: -3

Integral Return: 12
@OR
The OR function evaluates its arguments based on the context in which it is called. The data type
of the context dictates the data type of the function’s arguments and also the function’s evaluation
type. It supports the following return data types: Boolean, Decimal Number, Integral Number,
String. If called in a Boolean context, the function will return TRUE if any one or more of its
arguments evaluates to TRUE. If all function arguments FALSE, it will return FALSE. When the
context is one of the two numerical data types, it will sum the arguments according to that data
type and return the result. If the function is evaluated as a string, the function will concatenate the
arguments into a single string value for return.
Arguments:
• valueArg1 - This is the first argument to the function. It is evaluated as the same data type
as that of the function’s context. This argument is required.
• valueArg2 - This is the second argument to the function, which is evaluated as the same
data type as that of the function’s context. This argument is required.
• valueArg3-N - These optional arguments are evaluated according to the context of the
function. These arguments are optional.
• Boolean
• Decimal Number
• Integral Number
• String

Given: actionSupported is TRUE, all others are FALSE:
Examples (Integral or Decimal Context):

Integral Return: 12

Integral Return: 18
Examples (String Context):
String Return: “Hello out there.”
String Return: “Head 2 Head.”

@XOR
The XOR function provides the exclusive or logic to the Rule definition type. This function can
take two or more arguments, each of which is evaluated as a Boolean. The function returns TRUE
if one and only one of its arguments evaluates to TRUE, with all others evaluating to FALSE. If
all of the arguments evaluate to FALSE, or if two or more arguments evaluate to TRUE, this func-
tion will return FALSE.
Arguments:
• boolArg1 - This is the first argument to the function and is always evaluated as a Boolean.
• boolArg2 - This is the second argument to the function and is always evaluated as a Bool-
ean. This argument is required.
• boolArg3-N - These arguments are always evaluated as a Boolean and or optional.
• Boolean
Examples:
Given: actionSupported is TRUE, all other Globals are FALSE:

Given: actionSupported and useAction are both TRUE, allowEditActions is FALSE:
Mathematical Functions
The mathematical category of functions within the Rule definition type are those that provide the
ability to perform mathematical and comparisons operations on numeric values. This includes
functions for the basic mathematical operations of addition, subtraction, multiplication, and divi-
sion. It also includes other math operations, such as modulus, percents, absolute values, working
with precision and significant digits, making greater than and less than comparisons, and other
numeric-based operations.
Most of these functions work exclusively with integral and/or decimal values. There are a small
number of exceptions to this, such as the SUM unction, which can be used to concatenate strings.
By and large, however, the mathematical functions operate on and return numeric values.
There are many functions intended to use specifically decimal values and others specific to inte-
gral values. When using these functions, arguments will be evaluated as one of these two data
types. This is important to note as, if evaluating a decimal as an integral, data loss can occur, as
the fractional portion of a decimal value is truncated when it is evaluated as an integral.
@ABS
The ABS function returns the absolute value of the argument given. The function takes a single
argument, which is evaluated as either an integral or decimal value, depending on the context of
the function. Likewise, the evaluation type of the function is also dependent on this context.
Arguments:
• numericArg - This argument contains the numeric value whose absolute value will be re-
turned. The data type of this argument is either decimal or integral, dependent on the
functions context.
• Decimal Number
• Integral Number
Examples:

Integral Return: 12
Decimal Return: 3.6

Integral Return: 3
@DIFF
The behavior of the DIFF function is dictated by its context. This function takes a variable num-
ber of arguments, the data types for which are also dictated by the function call’s context. The
function supports three of the return data types: Boolean; Decimal Number; and Integral Number.
If the context of the function call is Boolean, the DIFF function will evaluate each argument as a
Boolean and return TRUE if all of its arguments are FALSE. If any one argument is TRUE, the
function will return FALSE. If the function is evaluated in a Decimal or Integral Number context,
each of its arguments are evaluated as a decimal or integral number type. The function subtracts
each of the argument values for arguments 2 through N from the value of argument 1 and returns
the result.
Arguments:
• valueArg1 - The first argument to be evaluated by the function. The data type of this argu-
ment is the same as the data type of the context in which the function is being evaluated.
• valueArg2-N - The optional arguments to the function, each of which is evaluated as the
same type as is dictated by the context of the function.
• Boolean
• Decimal Number
• Integral Number

Given: Enable.actionSupported is TRUE:

Integral Return: -6
@DIV
The DIV function takes two arguments, the data type for which is dependent on the context of the
function. It divides the first argument by the second and returns the quotient. The evaluation type
of the function is also determined by its context.
Arguments:
• dividendArg - This is the numeric value to be divided by divisorArg. It is evaluated as ei-
ther a decimal or integral value, depending on the context of the function itself.
• divisorArg - This is the numeric value divided into dividendArg. It is evaluated as either a
decimal or integral value, depending on the context of the function itself.
• Decimal Number
• Integral Number
Examples:
Decimal Return: 3.6

Integral Return: 3
Decimal Return: 4.0

Integral Return: 4
@FORMAT_DECIMAL
The FORMAT_DECIMAL function converts the given numeric value into a string. It takes six
arguments, many of which are optional, that are used to create the final string value. The first
argument, decNumArg, is the value to be converted and is required. This argument is evaluated
as a decimal, though integral numbers may be passed in.
Arguments:
• decNumArg - The decimal number to be formatted as a string. This argument is required.
• intPrecision - This argument specifies the precision to which the value of decNumArg
should be converted, that is, the number of places beyond the decimal that should be a part
of the resulting string value. The last digit kept is rounded based on the following digit.
To return an integral value, this should be 0. This argument is optional and, if not present,
the precision is automatically calculated.
• boolUseThousandsChar - This argument is evaluated as a Boolean and specifies whether
or not the resulting value should contain a character at each third number, e.g. 1000000
(FALSE) vs. 1,000,000 (TRUE). This argument is optional and the default value is
FALSE. The default character to use is a comma, though this may be overridden using the
strThousandsChar argument.
• boolUseLeadZero - This argument is evaluated as a Boolean and specifies whether or not
to use a leading zero if decNumArg is a fractional value (e.g. 0.23 vs. .23). This is an op-
tional argument and is TRUE by default.
• strDecChar - This argument is evaluated as a string, though only the first character of the
string is respected, with any extras being ignored. This argument specifies the character to
use to denote the beginning of the fractional portion of the value. This argument is option-
al and the default is to use a decimal (.) character. (NOTE: Many non-English languages
denote the decimal portion of a number using a comma (,) rather than a decimal.)
• strThousandsChar - This argument is evaluated as a string, though only the first character
of the string is respected, with any extra characters being ignored. This argument speci-
fies the character to use if boolUseThousandsChar is true. This argument is optional and
the default value is a comma (,) character. (NOTE: Many non-English languages denote
the thousands place using a decimal (.) rather than a comma.)
• String
Examples:

String Return: “12,345.679”
String Return: “12.345,68”

@GT
The GT function takes at least two arguments, with as many more as needed, each of which are
evaluated as Integral Numbers. The first argument is compared to each additional argument in
turn. If the first argument is found to be greater than all other arguments, the function returns
TRUE. Otherwise, it will return FALSE. Note that this function compares only integral number
values. See the description for GTDEC for comparing decimal numbers.
Arguments:
• intTestNum - This argument contains the value to be tested against the values of all other
arguments to the function. This argument is evaluated as an integral number and is a re-
quired argument.
• intCompareNum1 - The first argument to be compared against intTestNum. This argu-
ment is evaluated as an integral number and is a required argument.
• intCompareNum2-N - The 2nd through N arguments compared against intTestNum. Each
of these arguments are evaluated as an integral number and are optional.
• Boolean
Examples:

@GTDEC
The GTDEC function takes at least two arguments, with as many more as needed, each of which
are evaluated as Decimal Numbers. The first argument is compared to each additional argument
in turn. If the first argument is found to be greater than all other arguments, the function returns
TRUE. Otherwise, it will return FALSE. Note that this function compares only Decimal Num-
bers. See the description for GT for comparing Integral Numbers.
Arguments:
• decTestNum - This argument contains the value to be tested against the values of all other
arguments to the function. This argument is evaluated as an decimal number and is a re-
quired argument.
• decCompareNum1 - The first argument to be compared against decTestNum. This argu-
ment is evaluated as a decimal number and is a required argument.
• decCompareNum2-N - The 2nd through N arguments compared against intTestNum.
Each of these arguments are evaluated as an decimal number and are optional.
• Boolean
Examples:

@GTEQ
The GTEQ function takes at least two arguments, with as many more as needed, each of which are
turn. If the first argument is found to be greater than or equal to all other arguments, the function
returns TRUE. Otherwise, it will return FALSE. Note that this function compares only integral
number values. See the description for GTEQDEC for comparing decimal numbers.
Arguments:
quired argument.
of these arguments are evaluated as integral numbers and are optional.
• Boolean
Examples:

@GTEQDEC
The GTEQDEC function takes at least two arguments, with as many more as needed, each of
which are evaluated as Decimal Numbers. The first argument is compared to each additional
argument in turn. If the first argument is found to be greater than or equal to all other arguments,
the function returns TRUE. Otherwise, it will return FALSE. Note that this function compares
only Decimal Number values. See the description for GTEQ for comparing Integral Numbers.
Arguments:
arguments to the function. This argument is evaluated as a decimal number and is a re-
quired argument.
• decCompareNum2-N - The 2nd through N arguments compared against decTestNum.
Each of these arguments are evaluated as decimal numbers and are optional.
• Boolean
Examples:

@LT
The LT function takes at least two arguments, with as many more as needed, each of which are
turn. If the first argument is found to be less than all other arguments, the function returns TRUE.
Otherwise, it will return FALSE. Note that this function compares only integral number values.
See the description for LTDEC for comparing decimal numbers.
Arguments:
quired argument.
• Boolean
Examples:

@LTDEC
The LTDEC function takes at least two arguments, with as many more as needed, each of which
are evaluated as Decimal Numbers. The first argument is compared to each additional argument
in turn. If the first argument is found to be less than all other arguments, the function returns
TRUE. Otherwise, it will return FALSE. Note that this function compares only Decimal Num-
bers. See the description for LT for comparing integral numbers.
Arguments:
quired argument.
• decCompareNum1 - The first argument to be compared against intTestNum. This argu-
• decCompareNum2-N - The 2nd through N arguments compared against intTestNum.
Each of these arguments are evaluated as a decimal number and are optional.
• Boolean
Examples:

@LTEQ
The LTEQ function takes at least two arguments, with as many more as needed, each of which are
turn. If the first argument is found to be less than or equal to all other arguments, the function
returns TRUE. Otherwise, it will return FALSE. Note that this function compares only integral
number values. See the description for LTEQDEC for comparing decimal numbers.
Arguments:
quired argument.
• Boolean
Examples:

@LTEQDEC
The LTEQDEC function takes at least two arguments, with as many more as needed, each of
which are evaluated as Decimal Numbers. The first argument is compared to each additional
argument in turn. If the first argument is found to be less than or equal to all other arguments, the
function returns TRUE. Otherwise, it will return FALSE. Note that this function compares only
decimal number values. See the description for LTEQ for comparing integral numbers.
Arguments:
quired argument.
• decCompareNum2-N - The 2nd through N arguments compared against decTestNum.
Each of these arguments are evaluated as a decimal number and are optional.
• Boolean
Examples:

@MAX
The MAX function takes two or more arguments containing numerical values and compares each
to the other. It hen returns the largest value found among all its arguments. The arguments are
evaluated as either Decimal or Integral Numbers, depending on the context of the function itself.
Arguments:
• numArg1 and 2 - This first two values to be compared against the others by the function.
This value is evaluated as either a Decimal or Integral number, depending on context.
• numArgN - The last argument to the function, which can take a variable number of argu-
ments. This argument is optional, as are all arguments after the first two. These argu-
ments are evaluated as either Decimal or Integral Numbers, depending on context.
Evaluation Type: Context Dependent.
• Decimal Number
• Integral Number
Examples:

Integral Return: 35

Integral Return: 10
@MIN
The MIN function takes two or more arguments containing numerical values and compares each
to the other. It then returns the smallest value found among all its arguments. The arguments are
evaluated as either Decimal or Integral Numbers, depending on the context of the function itself.
Arguments:
• numArg1 and 2 - This first two values to be compared against the others by the function.
This value is evaluated as either a Decimal or Integral number, depending on context.
• numArgN - The last argument to the function, which can take a variable number of argu-
ments. This argument is optional, as are all arguments after the first two. These argu-
ments are evaluated as either Decimal or Integral Numbers, depending on context.
Evaluation Type: Context Dependent.
• Decimal Number
• Integral Number
Examples:

Integral Return: 15

Integral Return: 18
@MOD
The MOD function performs a modulus operation on its two arguments and returns the result.
The first argument (dividend) is divided by the second argument (divisor) and any remainder is
returned. The arguments are evaluated as either Decimal or Integral Numbers, depending on the
context of the function.
Arguments:
• dividendArg - This argument is the value to be divided by the divisorArg argument. This
value is evaluated as either a Decimal or Integral Number, depending on the context of the
function. This argument is required.
• divisorArg - This argument is divided into the dividendArg argument. This value is eval-
uated as either a Decimal or Integral Number, depending on the context of the function.
• Decimal Number
• Integral Number
Examples:
Decimal Return: 1.0

Integral Return: 1

Integral Return: 2
@PERCENT
The PERCENT function takes a single numeric argument. The value of this argument is then
divided by 100 and the quotient is returned. The value of this argument is evaluated as a Decimal
Number. This function ignores any significant digit rules during the division process.
Arguments:
• decDividendNum - This value is evaluated as a Decimal Number and is the value to be di-
vided by 100.
• Decimal Number
Examples:
Decimal Return: .85

@PRECISION
The PRECISION function takes a single argument, evaluated as a Decimal Number. It then
returns the number of digits after the decimal point in the value.
Arguments:
• decDecimalNum - This argument contains the value whose precision is to be determined.
This argument is evaluated as a Decimal Number and is required.
• Decimal Number
• Integral Number
• String
Examples:
Decimal Return: 4.0

Integral Return: 4
Decimal Return: 0.0

Integral Return: 0
@PROD
The PROD function takes two or more numeric values and multiplies them and then returns the
product. The arguments to the function are evaluated as either Decimal or Integral Numbers,
depending on the context of the function.
Arguments:
• numArg1-N - Each numeric value to be multiplied by the function is passed as a separate
argument to the function. All arguments are evaluated as either a Decimal Number or In-
tegral Number, depending on the function’s context.
• Decimal Number
• Integral Number
Examples:

Integral Return: 50

Integral Return: 630
@RANGE_LIMIT
The RANGE_LIMIT function constrains a given value to within a range of values. The function
takes three arguments: a lower limit; the value to be constrained; and an upper limit. If the value
to be constrained is greater than the lower limit and less than the upper limit, the function will
return the value. If this value is less than the lower limit, the value of the lower limit will be
returned. If the constrained value is greater then the upper limit, the upper limit value will be
returned. Each of the three arguments are evaluated as either Decimal or Integral Numbers,
depending on the context of the function.
Arguments:
• numLowerLimit - This argument specifies the lower limit of the range of values to which
the numConstrainedVal should be limited. This argument is evaluated as either a Decimal
or Integral Number, depending on the function’s context.
• numConstrainedVal - This argument contains the value to be constrained. The value is
evaluated as either a Decimal or Integral Number, depending on the function’s context.
• numUpperLimit - This argument specifies the upper limit of the range of values to which
the numConstrainedVal should be limited. This argument is evaluated as either a Decimal
or Integral Number, depending on the function’s context.
• Decimal Number
• Integral Number
Examples:
Decimal Return: 8.0

Integral Return: 8

Integral Return: 16
@ROUND
The ROUND function will round a numeric value to the specified place. The first argument to the
function is the numeric value to be rounded. This argument is evaluated as either a Decimal or
Integral Number, depending on the function’s context. The second argument is always evaluated
as an Integral Number, and specifies the number of digits before or after the decimal place to
which the number should be rounded. The evaluation type of the function is also dependent on
the context and will be either Decimal or Integral Number.
Arguments:
• numRoundVal - This argument contains the value to be rounded by the function. It is eval-
uated as either a decimal or integral number, depending on the function’s context. This is
a required argument.
• intRoundPrecision - This argument is evaluated as an Integral number and specifies the
precision to which the value of numRoundVal should be rounded. A positive value indi-
cates the position after the decimal within the number. A negative number indicates the
position before the decimal. If this argument is positive and is greater then the number of
places after the decimal within the value of numRoundVal, no rounding will occur and the
value of numRoundVal will be returned by the function. If the value of intRoundPrecision
is negative, and its absolute value is greater then the number of digits before the decimal,
this function will return 0.
• Decimal Number
• Integral Number
Examples:
Decimal Return: 5.3

Integral Return: 5

@SIGN
The SIGN function takes a single argument and returns a value indicating whether the argument
value is negative, zero, or positive. The argument is evaluated as a Decimal Number.
Arguments:
• decTestNum - This argument contains the value to be checked by the function for a posi-
tive, negative, or 0 value. It is evaluated as a Decimal Number.
• Decimal Number
• Integral Number
Examples:
Decimal Return: 1.0

Integral Return: 1

Integral Return: -1
Decimal Return: 0.0

Integral Return: 0
@SIGNIFICANT_DIGITS
The SIGNIFICANT_DIGITS function takes a single argument, evaluated as a Decimal Number,
and returns the number of significant digits it contains.
Arguments:
• decNumArg - This argument, evaluated as a Decimal Number, contains the numeric value
for which the number of significant digits will be counted.
Evaluation Type:
• Decimal Number
• Integral Number
• String
Examples:
Decimal Return: 1.0

Integral Return: 1
String: “1”
Decimal Return: 3.0

Integral Return: 3
Decimal Return: 3.0

Integral Return: 3
@SQRT
The SQRT function returns the square root of a decimal number out to the specified number of
digits after the decimal. The number for which the square root is found is evaluated as a decimal
number. The precision of the result is specified by an integral number.
Arguments:
• decNumArg - This argument contains the value whose square root is to be determined.
This argument is evaluated as a Decimal Number and is required.
• intPrecision - This argument contains the number of digits after the decimal place to
which the square root value should be calculated.
• Decimal Number
Examples:
Decimal Number: 5.0000

@SUM
The SUM function performs three different tasks within the Rule definition, depending on its con-
text. First, as a part of the Mathematical category of rule functions, it takes two or more numeri-
cal arguments and adds them up, returning the sum. In this form, the arguments are evaluated as
either integral or decimal numbers, depending on context.
The second form of the function is when the context calls for a string. In this case, the arguments
to the function are treated as strings and are concatenated together, with the single resulting string
returned. Note that this is similar to, but still different from, the functionality of the CONCATE-
NATE function. The SUM function allows from 2 to N number of string arguments to be concat-
enated, whereas CONCATENATE allows only two strings. Furthermore, the CONCATENATE
function allows for the specification of a length, while SUM does not.
The final form of this function is when its context is a Boolean. In this case, the function behaves
identically to the OR function, including how its arguments are evaluated, as well as the return
values.
In this discussion, the focus is on the Decimal and Integral Number contexts, and the string con-
texts. For details on the Boolean context behavior, see the description of the OR function.
Arguments:
• arg1 - The first argument to the function, which is evaluated based on the context of the
function call. This argument is required.
• arg2 - The second argument to the function, which is evaluated based on the context of the
function call. This argument is required.
• arg3-N - The remaining arguments to the function, each of which is evaluated based on the
context of the function. These arguments are optional.
Evaluation Type: Context Specific
• Boolean
• Decimal Number
• Integral Number
• String
Examples:

Integral Return: 19
Decimal Return: 0.0

Integral Return: 0
String Return: “Hello to you all.”
@TRUNC
The TRUNC function will truncate the given numeric value to the specified place, either before or
after the decimal, in a number. The first argument to the function is the value to be truncated and
will be evaluated as either a decimal or integral number, depending on the context. Likewise, the
evaluation type of the function is also dependent on the context. The second argument is evalu-
ated as an integral number and specifies the precision, or number of digits to which the function
should be truncated. A positive precision value counts the number of digits to the right of the dec-
imal, while a negative precision counts them to the left of the decimal. Note that this function dif-
fers from the ROUND function in that no rounding occurs here. The number is simply truncated
to the specified length.
Arguments:
• numArg - This argument contains the numerical value to be truncated by the function.
This argument is evaluated as either a decimal or integral number and is required.
• intPrecision - This argument contains the precision to which the numArg value should be
truncated. This argument is evaluated as an integral number and is required. Positive pre-
cision values count to the right of the decimal and negative values count to the left, start-
ing with the ones place.
• Decimal Number
• Integral Number
Examples:

Integral Return: 12
Decimal Return: 1300

Property Functions
The Property Functions within the Rule definition provide you with the ability to access and
manipulate various pieces of information within properties. These functions are further organized
into those functions for different property types. For example, there are several functions are spe-
cifically intended to be used with External Data Properties, and others for working specifically
with collections.
Some of the functionality provided by these functions include the ability to determine if a proper-
ties value is equal to the defined special value of that property; access to information about a file
referenced by an external data property; or to determine the number of members in a collection
property.
In the descriptions that follow, the functions are presented in the order in which they are displayed
in the Property Function sub-menu of the Rule Editor. These functions are organized according to
the general type of functionality, or the property type to which they provide access.
@COUNT
The COUNT function takes two arguments. The first is required and is evaluated as a collection
property. The function returns the number of members in this collection. The second argument is
optional and is evaluated as an Include Rule. This rule is evaluated once for each member of the
collection and returns TRUE or FALSE. It is used to include only certain members of the collec-
tion. If an Include Rule is provided, the function will only count those members of the collection
that result in a TRUE return from the include rule. Those that result in a FALSE return will not be
counted.
Arguments:
• collCollectionProp - This argument is evaluated as a collection property. The function
counts the members of this collection and returns the result. This argument is required.
• ruleIncludeRule - This argument is evaluated as an Include Rule. If this argument is pres-
ent, the rule will be evaluated once for each member of the collection, with its context dic-
tated by the member. For each member that results in a return value of TRUE, the
function will count that member. It will not count those for which a FALSE value is re-
turned.
• Boolean
• Integral Number
• String
Examples: In the following examples, the collection Customers contains 10 total members.
Three of these members have a status of Inactive, with the rest having a status of Active.

Integral Return: 10
Boolean Return TRUE

Integral Return: 7
@SIZE
The SIZE function takes two arguments. The first is required and is evaluated as a collection
property. The function returns the number of members in this collection. The second argument is
optional and is evaluated as an Include Rule. This rule is evaluated once for each member of the
collection and returns TRUE or FALSE. It is used to include only certain members of the collec-
tion. If an Include Rule is provided, the function will only count those members of the collection
that result in a TRUE return from the include rule. Those that result in a FALSE return will not be
counted.
Arguments:
• collCollectionProp - This argument is evaluated as a collection property. The function
counts the members of this collection and returns the result. This argument is required.
• ruleIncludeRule - This argument is evaluated as an Include Rule. If this argument is pres-
ent, the rule will be evaluated once for each member of the collection, with its context dic-
tated by the member. For each member that results in a return value of TRUE, the
function will count that member. It will not count those for which a FALSE value is re-
turned.
• Boolean
• Integral Number
• String
Examples: In the following examples, the collection Customers contains 10 total members.
Three of these members have a status of Inactive, with the rest having a status of Active.

Integral Return: 10

Integral Return: 7
@COLLECTION_MAX
The COLLECTION_MAX function searches an object collection for the member whose desig-
nated property contains the largest value of all members of the collection. It then returns this
value. The function takes up to three arguments. The first is the collection to be searched. The
second is the property whose value is to be compared in each object. The third, optional argu-
ment, is a sub-rule used as an Include Rule. If an include rule is provided, it is evaluated once for
each object in the collection. Only those objects that result in the include rule evaluating to true
will then be searched, with all others in the collection ignored. The function then returns the larg-
est value found. Regardless of the function’s context, the properties are compared based on their
data type. The context will then dictate the data type of the function’s return.
Arguments:
• collObjectCollection - This argument is the object collection which is searched by the
function. This is a required argument.
• propTestProperty - This argument contains the property within the object type that makes
up the collection in collObjectCollection that is to be compared from one object to the
next to determine the maximum value. This is a required argument.
• ruleIncludeRule - This argument contains a rule whose return is evaluated as Boolean.
The rule is evaluated once for each object in collObjectCollection and only those objects
that result in a TRUE return from this rule are searched. This argument is optional and, if
not present, all objects in collObjectCollection are searched. The context of this rule is the
object type in the collection being searched.
Evaluation Type: Property Dependent.
• Decimal Number
• Integral Number
• String
Examples: The following examples, the NewOrders collection is a collection of Order objects.
The Cost property contains the total cost of the order. There are four objects in this collection
with costs of 243.56, 982.03, 312.45, and 0.00. This last is a reorder of an undelivered item. The
Max500 Rule returns true for an Order object when its cost property is equal to or less than 500;
otheriwse it returns false.


@COLLECTION_MIN
The COLLECTION_MIN function searches an object collection for the member whose desig-
nated property contains the smallest value of all members of the collection. It then returns this
value. The function takes up to three arguments. The first is the collection to be searched. The
second is the property whose value is to be compared in each object. The third, optional argu-
ment, is a sub-rule used as an Include Rule. If an include rule is provided, it is evaluated once for
each object in the collection. Only those objects that result in the include rule evaluating to TRUE
will then be searched, with all others in the collection ignored. Regardless of the function’s con-
text, the properties are compared based on their data type. The context will then dictate the data
type of the function’s return.
Arguments:
• propTestProperty - This argument contains the property within the object type that makes
up the collection in collObjectCollection that is to be compared from one object to the
next to determine the minimum value. This is a required argument.
object in the collection being searched.
Evaluation Type: Property Dependent.
• Decimal Number
• Integral Number
• String
Examples: The following examples, the NewOrders collection is a collection of Order objects.
NonZeroCost Rule returns true for an Order object when its cost property is greater than 0.00;

Integral Return: 0

@TOTAL
The TOTAL function takes up to three arguments. The first is a collection property and the sec-
ond is the name of a property within the object of the collection referenced in the first argument.
This function will total up the value of this property in each object within the collection. It will
then return the result. The third argument to the function is an include rule and, if present, will
determine which objects within the collection are a part of the resulting total returned by the func-
tion. The properties are totalled by the function based on the function’s context, not the data type
of the properties. This is important to note when the context is in an Integral Number, and the
properties to be totaled are decimals. The fractional portion of the properties will be truncated
from the values prior to their being added together.
Arguments:
• propTestProperty - This argument contains the property within the object that is to be to-
taled in all of the objects of the collection. This is a required argument.
object currently being evaluated by the function.
• Decimal Number
• Integral Number
Examples: In the following examples, the NewOrders collection is a collection of Order objects.
Max500 Rule returns true for an Order object when its cost property is equal to or less than 500;
Decimal Return: 1,538.04

Integral Return: 1,537

@MEMBER
The MEMBER function is used to search an object collection and to return the value of a property
within that collection that matches the given search value. This first match found within the col-
lection will be returned. The function takes two arguments, the first of which is an object collec-
tion and the second is a property with a value the is to be located. The second argument is
normally a property within the definition of the Rule. The object with the same property name,
data type, and value within the object collection is then found and the value of the object’s prop-
erty returned. If no match is found within the collection the function returns the default value of
the data type dictated by the context of the function.
Arguments:
• collObjectCollection - This argument is evaluated as an object collection property. It is
the collection to be searched by the function. This argument is required.
• propSearchProperty - This argument is evaluated as a property. It is the property contain-
ing the value that is to be searched for within collObjectCollection.
Evaluation Type: Property
• Boolean
• Decimal Number
• Integral Number
• Property
• String
Examples: In the following examples, the
@PROP
The PROP function takes a variable number of arguments. Each argument is evaluated as a prop-
erty and this evaluation is within the context dictated by the argument that precedes it in the argu-
ments to the function. The overall purpose of this function is to provide a kind of drill-down
access to the value of a property that may be a descendent of the current object. For example,
assume there is a Customer object. This object contains a collection property of Order objects.
Each Order object, in turn, contains a collection of OrderItem objects, which represent individual
items ordered by a customer. If the context of the function call, or the Rule in which it is con-
tained, is a Customer object, and you wish to retrieve the value of a property in an OrderItem
object, this function can be useful. Each argument to the function is evaluated in the context of
the argument that is before it. So, in this example, to retrieve the desired OrderItem object, the
first argument would be the desired Order for the customer, and the second would be the Order-
Item object. Normally, each of these arguments is actually another function call that locates the
desired property via some sort of search.
Arguments:
• propChildProperty - This is the first argument to the function, evaluated as a property, and
in the context of the function call. It is normally an object property, or a member of a col-
lection property of the current object. This is a required argument.
• propDescendentProp1-N - These are the descendent arguments
Evaluation Type:
•
Examples:
@TYPE
The TYPE function takes a variable number of arguments. Each argument is evaluated as a prop-
erty and this evaluation is within the context dictated by the argument that precedes it in the argu-
ments to the function. The overall purpose of this function is to provide a kind of drill-down
access to a property that may is a descendent of the current object. For example, assume there is a
Customer object. This object contains a collection property of Order objects. Each Order object,
in turn, contains a collection of OrderItem objects, which represent individual items ordered by a
customer. If the context of the function call, or the Rule in which it is contained, is a Customer
object, and you wish to retrieve the value of a property in an OrderItem object, this function can
be useful. Each argument to the function is evaluated in the context of the argument that is before
it. So, in this example, to retrieve the desired OrderItem object, the first argument would be the
desired Order for the customer, and the second would be the OrderItem object. Normally, each of
these arguments is actually another function call that locates the desired property via some sort of
search. The function then returns the type of the property found. Note that this is not the data
type of the property, but rather the definition name, such as “Customer.” In a Boolean context, the
function returns TRUE if the property is found; in a integral number context, the internal ID of the
definition is returned.
Arguments:
• propDescendentProp1-N - These are the descendent arguments
• Boolean
• Integral Number
• String
Examples:

String Return: Order Item
@CURRENTVALUE
The CURRENTVALUE function takes a variable number of arguments. Each argument is evalu-
ated as a property and this evaluation is within the context dictated by the argument that precedes
it in the arguments to the function. The overall purpose of this function is to provide access the
value of a property in a drill-down fashion. It also works with the user interface on the Client in
that, if a file on the current screen is found to be mapped to the last property argument to the func-
tion, the value of the field is returned, not that of the property. This function may also take a sin-
gle argument, in which case that property’s value, or the value of a field that is mapped to the
property, is returned.
Arguments:
• propDescendentProp1-N - These are the descendent arguments, each of which is evaluat-
ed in the context of the argument that precedes it.
• Boolean
• Decimal Number
• Integral Number
• Property
• String
Examples:
Boolean: TRUE
Decimal Number: 11291.0
Integral Number: 11291
Property: The acctnum property of the Customer object.
String: “11291”
@SCREENFIELDVALUE
The SCREENFIELDVALUE function takes a variable number of arguments. Each argument is
evaluated as a property and this evaluation is within the context dictated by the argument that pre-
cedes it in the arguments to the function. The overall purpose of this function is to provide access
the value of the field that is mapped to the final property evaluated by the function, that is, the last
argument of the function. It will also retrieve the value of a field if the function is given a single
argument, and that argument is the name of a field.
Arguments:
• stringFieldName - This argument is evaluated as a string and will return the value of the
field contained in the argument. If this form of the function is used, this argument is re-
quired and is the only argument that should be passed to the function. The field referenced
must be defined on the current screen being displayed.
• Boolean
• Decimal Number
• Integral Number
• Property
• String
Examples:
Given: Qty is a decimal number field on the current screen and has a current value of 4.6
Decimal Return: 4.6
Integral Return: 4
Property Return: The Property mapped to the field.
@SCREENFIELDNAME
The SCREENFIELDNAME function takes no arguments. It will return the name of the Detail
Screen Field that is currently in context.
Arguments: N/A
• String
Examples: The following Rule is used as an Update Rule for a field named Cost.
String Return: “Cost”

@UI
The UI function takes a variable number of arguments. Each argument is evaluated as a property
and this evaluation is within the context dictated by the argument that precedes it in the arguments
to the function. The overall purpose of this function is to provide access the value of the field that
is mapped to the final property evaluated by the function, that is, the last argument of the function.
It will also retrieve the value of a field if the function is given a single argument, and that argu-
ment is the name of a field.
Arguments:
• stringFieldName - This argument is evaluated as a string and will return the value of the
field contained in the argument. If this form of the function is used, this argument is re-
quired and is the only argument that should be passed to the function. The field referenced
must be defined on the current screen being displayed.
• Boolean
• Decimal Number
• Integral Number
• Property
• String
Examples:
@LASTSCANVALUE
LASTSCANVALUE returns the last value scanned in by the client device while the Agentry Cli-
ent was running. If called prior to a value being scanned in, it will return null. The last scanned
value will be returned regardless of where the rule term function is called, or how long after the
value was scanned. Exiting and restarting the Client will remove the scanned value and the func-
tion will return null until a new value is scanned.
Arguments:
• N/A
• String
Examples:
If value scanned in was 1234:

If no value scanned in:
@IS_SPECIAL_VALUE
The IS_SPECIAL_VALUE function takes a variable number of arguments. Each argument is
evaluated as a property and this evaluation is within the context dictated by the argument that pre-
cedes it in the arguments to the function. The overall purpose of this function is to provide a kind
of drill-down access to the value of a property that is a descendent of the current object. The last
property evaluated is compared to the special value defined for that property, if any, and returns
either TRUE, if the value is equal to the special value, or FALSE if it is not equal to the special
value or if there is no special value defined for the property.
Arguments:
• propDescendentProp1-N - These are the descendent arguments, the last of which is evalu-
ated for comparison to its defined special value. These arguments are optional and, if not
present, the first argument, propChildProperty will be evaluated for comparison.
• Boolean
Examples: In the following examples, the OrderDate property has a special value defined of
Invalid Date and time. In the first example, this is also the value of the property. In the second
example, it is not.

@IS_VALID_DECIMAL_NUMBER
The IS_VALID_DECIMAL_NUMBER function is used to check whether or not a Decimal
Number property contains a valid decimal number, or the value NaN (Not a Number). The value
NaN is also returned when any value is divided by 0. If the value is a valid decimal number, this
function returns TRUE. Otherwise it will return FALSE.
Arguments:
• decDecimalVal - This argument is evaluated as a Decimal Number. Its value is checked
for validity by the function.
• Boolean
Examples:

@NEEDS_XMIT
The NEEDS_XMIT function determines whether or not the specified object has any pending
transactions that will be transmitted to the Agentry Server during the transmit. If there are any
pending transactions for the object, this function returns TRUE. Otherwise, it returns FALSE.
Note that if any object that is a descendent of the specified object has a pending transaction, this
function will also return TRUE in this case.
Arguments:
• objObjectArg - This is the object that will be checked for pending transactions. Also, any
property objects or descendent objects will be checked as well. This argument is required
and is always evaluated as an Object.
• Boolean
Examples:
Boolean Return: TRUE if Current Object has a pending transaction, otherwise FALSE.
@TRANSACTIONPROPERTYNAME
This rule term function returns the name of the property being set by the rule from within which
the function is called. This function is only supported in rule definitions evaluated as initial value
rules for transaction properties. Its return value is undefined in all other contexts.
Arguments:
• N/A
• String
@FILE_PATH_AND_NAME
The FILE_PATH_AND_NAME function is provided to work with the external data type property.
This function takes a single argument, evaluated as an external data property, and returns the full
path and file name, as a string, of the file referenced by that property. If the property does not ref-
erence a file, this function returns an empty string. Note that file paths on Windows CE devices
do not contain a drive letter, but rather begin with a single back slash (\).
Arguments:
• edpExternalDataProperty - This argument is evaluated as an external data property by the
function. It is a required argument.
• String
Examples: In the following examples, SchematicProp references files located at the location
\MyDocs\Schematics and are all .jpg files. MapProp references files located at \MyDocs\Maps
and contain files of type .html.
String Return: \MyDocs\Schematics\Sch_ElecMotor_1291.jpg
String Return: \MyDocs\Maps\Map_Warehouse2_21.html

@FILE_PATH
The FILE_PATH function is provided to work with the external data type property. This function
takes a single argument, evaluated as an external data property, and returns the full path, as a
string, of the file referenced by that property. If the property does not reference a file, this func-
tion returns an empty string. Note that file paths on Windows CE devices do not contain a drive
letter, but rather begin with a single back slash (\).
Arguments:
• String
String Return: \MyDocs\Schematics
String Return: \MyDocs\Maps

@FILE_NAME
The FILE_NAME function is provided to work with the external data type property. This func-
tion takes a single argument, evaluated as an external data property, and returns the file name and
extension, as a string, of the file referenced by that property. If the property does not reference a
file, this function returns an empty string. Note that file paths on Windows CE devices do not
contain a drive letter, but rather begin with a single back slash (\).
Arguments:
• String
String Return: Sch_ElecMotor_1291.jpg
String Return: Map_Warehouse2_21.html

@FILE_EXTENSION
The FILE_EXTENSION function is provided to work with the external data type property. This
function takes a single argument, evaluated as an external data property, and returns the file exten-
sion, as a string, of the file referenced by that property. If the property does not reference a file,
this function returns an empty string. Note that file paths on Windows CE devices do not contain
a drive letter, but rather begin with a single back slash (\).
Arguments:
• String
String Return: “.jpg”
String Return: “.html”

@FILE_SIZE
The FILE_SIZE function is provided to work with the external data type property. This function
takes a single argument, evaluated as an external data property, and returns the size of the file, in
bytes and as an integral number, of the file referenced by that property. If the property does not
reference a file, this function returns 0.
Arguments:
Evaluation Type: Integral number
• Integral Number
Examples:

@FILE_CHANGED
The FILE_CHANGED function is provided to work with the external data type property. This
function takes a single argument, evaluated as an external data property, and returns A Boolean
value indicating whether or not the referenced file has been modified since it was downloaded
from the Agentry Server. If it has been modified, the function returns TRUE. Otherwise, it will
return FALSE. If the property does not reference a file, this function returns FALSE.
Arguments:
• Boolean
Examples: In the following examples, the MapProp, which is an external data property, has been
modified in the first example, but not in the second.

String Functions
The string functions provided in the rule editor provide the functionality for working with and
manipulating string values. This includes parsing strings, truncating them, searching for specific
values in strings, case conversion, and various other string-related functionality.
Additionally, some of these functions, such as FIND and RFIND, have two forms, the first of
which will perform operations on strings, and the second will work with collections as well. This
functionality is explained where applicable in the following descriptions.
Many of the string functions return both the string data type, as well as others. These functions
manipulate strings, but allow for different return types, based on the needs of the Rule definition.
As with all rules and rule term functions, this is context dependent.
@CONCATENATE
The CONCATENATE function, as its name implies, concatenates two strings together, returning
the result. This function has two required arguments, which are the two strings to be concatenated
together, and a third optional argument, which is an integral number that specifies the number of
characters in the second string to be used, starting from the left. For example, if two strings,
“John” and “Goes” are to be concatenated, and the third, length argument has a value of 2, then
the resulting string would be “John Go”, not “John Goes”. If this third argument is equal to or
greater then the length of the second argument, the entire string will be returned. If it is 0, only
the first string will be returned.
Arguments:
• strSourceString - This is the first value, evaluated as a string, to which strAddString will
be added. This is a required argument.
• strAddString - This is the value, evaluated as a string, that will be added to the end of
strSourceString. This is a required argument.
• intAddStringLength - This value is evaluated as an integral number and specifies the max-
imum length of the strAddString argument to be added to strSourceString. This argument
is optional and, if not present, the entire strAddString value will be concatenated with
strSourceString.
• String
Examples:
String Return: “Gentlemen, start your engines”
String Return: “Gentlemen, start your engine”

@FIND
The FIND function is used to locate a search string value within a larger source string, and to
return that value, if found. Depending of the arguments provided, this search can be case-sensi-
tive, and can start at either the beginning of the source string, or somewhere in the middle of the
string. The default behavior is for the search to be case-sensitive, and for the search to begin at
the start of the source string. Depending on the context of the function, the return value will be
the position at which the first character of the search string was found in the source string (Inte-
gral Number Context); TRUE if the search string was found or FALSE if it was not (Boolean
Context); or the actual string value found within the source string (String Context).
There is also a second form to this function, which provides the ability to search an object collec-
tion based on a sub-rule argument to the function. In this form, the first argument is the collection
to be searched and the second is the rule used to search the collection. This behavior is only appli-
cable if the function is called in a Property context.
Arguments:
• strSourceString - This argument contains the string value to be search by the function and
is evaluated as a string. This is a required argument in the first form of the function, but
should not be present in a Property context.
• strSearchString - This argument contains the string searched for within strSourceString
and is evaluated as a string. This is a required argument in the first form of the function,
but should not be present in a Property context.
• boolCaseSensitive - This argument is evaluated as a Boolean and specifies whether or not
the function should consider the case of strSearchString as compared to the value of
strSourceString when searching. This argument is optional with a default value of TRUE
if not present. This argument is only valid in the first form of the function and should not
be present in a Property Context.
• intStartPosition - This argument is evaluated as an integral number and specifies the start
position within strSourceString where the function will begin looking for strSearchString.
This is a 0 based value, meaning the beginning of the string is position 0. This argument is
optional. The function will begin searching strSourceString from the beginning, if this ar-
gument is not present. This argument is optional in the first form of the function, but
• collObjectCollection - This argument is evaluated as an object collection property and is
required in a Property Context evaluation of the function. It should not be present in the
first form of this function. It contains the collection of objects to be searched by the func-
tion.
• ruleSearchSubRule - This argument is evaluated as an Include Rule in the context of the
current object in collObjectCollection. It is required in a Property Context evaluation of
the function. It should be present in the first form of this function. This rule is evaluated
once for each object tin the collection until the rule returns TRUE, at which point the cor-
responding object is returned by the FIND function.

• Boolean
• Integral Number
• Property
• String
Examples (1st Form):

Integral Return: 12
String Return: 9.54

Integral Return: -1

Integral Return: 18
String Return: “Three Minutes”

Integral Return: -1
Examples (2nd Form): In the following examples, the term Current Property refers to an object
collection property named NewOrders, which is a collection of Order objects. The Order object is
defined to have a property named Cost. This property is checked by the sub-rule NonZeroCost,
which returns true for an Order object with a Cost property value greater than 0.
Property Return: First Order object with Cost greater than 0. If none found, an empty Order
object.
@LEFT
The LEFT function returns the first N characters from the provided source string, where N is pro-
vided as an argument to the function. The first argument is the source string and the second is the
length of the string returned by the function. If this length is equal to or greater than the length of
the source string, the entire string is returned. If the length is 0 or less, an empty string is returned.
Arguments:
• strSourceString - This argument is evaluated as a string and contains the value that is to be
parsed by the function. This is a required argument.
• intLength - This argument is evaluated as an integral number and specifies the number of
characters, starting from the left most position, to be returned from strSourceString. A 0
intLength value will result in an empty string being returned. A value equal to or greater
than the length of strSourceString will return the entire string unchanged.
• String
Examples:
String Return: “Test”
String Return: “Testing”

@LENGTH
The LENGTH function determines the length of the given source string and returns a value based
on this length and according the context of the function. In an integral context, the number of
characters is returned in the string is returned. In a string context, the number of characters is
returned as a string. In a Boolean context, TRUE is returned strings with one or more characters
and FALSE is returned for an empty string.
Arguments:
• strSourceString - This argument is evaluated as a string and is required. It contains the
string value whose length is to be determined by the function.
• Boolean
• Integral Number
• String
Examples:

Integral Return: 11

Integral Return: 0
@LOWERCASE
The LOWERCASE function converts all alphabetical characters in the source string to lower case
and then returns the result. Any non-alpha characters, such as numbers or symbols are
unchanged, as are any characters that are already lower case.
Arguments:
string value whose alphabetical characters are to be converted to lowercase.
• String
Examples:
String Return: “the sale for $243.98 has been completed!!!”

@MID
The MID function parses a source string to return a sub-string that begins and ends at the posi-
tions specified. The first argument to the function is the string to be parsed. The second is the
stating position, which is 0-based, within the string to begin parsing. The third argument is the
number of characters to return. If a starting position is not provided, the default is zero. If the
number of characters to return is not provided, the default is the length of the source string.
Arguments:
• strSourceString - This argument is evaluated as string and contains the source string from
which a sub-string is to be retrieved. This argument is required.
• intStartPosition - This argument is evaluated as an integral number and contains the start-
ing position within strSourceString to begin counting. This value is 0 based. If not pro-
vided, the default value is 0.
• intCount - This argument is evaluated as an integral number and specifies the maximum
number of characters to return. If this argument is not provided, the default value is the
length of strSourceString. If the value of intCount is greater then the number of characters
after intStartPosition, all characters from the start position to the end of the string are re-
turned. If the value of intCount is 0 or less, an empty string is returned.
• String
Examples:
String Return: “er wishe”
String Return: “this time”

@NEWLINE
The NEWLINE function returns the command characters <CR> <LF>, (0x0D 0x0A), which,
when combined, result in the Windows new line. This return value of this function can be concat-
enated with other strings for formatting purposes.
Arguments: N/A
• String
Examples:
String Return: “John will be available on Tuesday.

The next meeting will be scheduled then.”
@REMOVE
The REMOVE function searches a given source string and removes all instances of a provided
search string and returns the result. By default, the search is case sensitive, but this van be over-
riden. Additionally, an argument can be provided to specify the starting position of the search
within the source string, if desired.
Arguments:
• strSourceString - This argument is evaluated as string and contains the source string to be
searched by the function. This argument is required.
• strSearchString - This argument is evaluated as string and contains the string value to be
removed from strSourceString in the function’s return value. This argument is required.
the search performed by the function should be case sensitive. The default value for this
optional argument is TRUE, meaning the search is case-sensitive.
• intStartPosition - This argument is evaluated as an integral number and specifies the start-
ing position within strSourceString to begin searching for strSearchString. This position
is zero-based and, if the argument is not provided, the default is to search the entire string.
If the value is greater than the length of strSourceString, or if the value is negative, no
search is performed, and an empty string is returned.
• String
Examples:
String Return: “The charge account has been closed.”
String Return: “The charge account has been PERMANENTLY closed.”

String Return: “The charge account has been closed.”
String Return: “The charge account has been PERMANENTLY closed.”

@REPLACE
The REPLACE function searches a given source string for a provided search string. It then
replaces each instance of the search string with a replace string. The search is case sensitive by
default and the entire source string is searched, by default. Both of these behaviors can be over-
ridden, if needed.
Arguments:
• strSourceString - This argument is evaluated as a string and contains the value to be
searched by the function. This is a required argument.
• strSearchString - This argument is evaluated as a string and contains the value to be
searched for within the source string.
• strReplaceString - This argument is evaluated as a string and contains the value that re-
places strSearchString in strSourceString.
the search of strSourceString is case-sensitive. This argument is optional and is TRUE by
default, meaning the search is case-sensitive.
• intStartPosition - This argument is evaluated as an integral number and specifies the zero-
based starting position within strSourceString to begin looking for strSearchString. If this
value is less then 0, or greater than the length of strSourceString, no changes are made and
the value of strSourceString is returned.
• String
Examples:
String Return: “The charge account has been reopened.”
String Return: “The charge account has been permanently Closed.”

String Return: “The charge account has been reopened.”
String Return: “The charge account has been permanently Closed.”

@RFIND
The RFIND function is used to locate a search string value within a larger source string, and to
return the last occurrence of the search value, if found. Depending of the arguments provided,
this search can be case-sensitive, and can start at either the beginning of the source string, or
somewhere in the middle of the string. The default behavior is for the search to be case-sensitive,
and for the search to begin at the start of the source string. Depending on the context of the func-
tion, the return value will be the position at which the first character of the search string was found
in the source string (Integral Number Context); TRUE if the search string was found or FALSE if
it was not (Boolean Context); or the actual string value found within the source string (String
Context).
Arguments:
• strSourceString - This argument contains the string value to be search by the function and
is evaluated as a string. This is a required argument in the first form of the function, but
• strSearchString - This argument contains the string searched for within strSourceString
and is evaluated as a string. This is a required argument in the first form of the function,
but should not be present in a Property context.
the function should consider the case of strSearchString as compared to the value of
strSourceString when searching. This argument is optional with a default value of TRUE
if not present. This argument is only valid in the first form of the function and should not
be present in a Property Context.
• intStartPosition - This argument is evaluated as an integral number and specifies the start
position within strSourceString where the function will begin looking for strSearchString.
This is a 0 based value, meaning the beginning of the string is position 0. This argument is
optional. The function will begin searching strSourceString from the beginning, if this ar-
gument is not present. This argument is optional in the first form of the function, but

• Boolean
• Integral Number
• String
Examples:

Integral Return: 32
String Return: “customer”

Integral Return: -1

Integral Return: 32
String Return: “customer”

Integral Return: -1
@RIGHT
The RIGHT function returns a string of specified length from a given source string, beginning at
the end of this string and counting back towards the beginning. The function takes two aregu-
ments. The first is the source string from which the sub-string is extracted. The second is the
number of characters in the sub-string. If the specified number of characters is greater than the
length of the source string, the entire source string is returned. If the specified number of charac-
ters specified is less than 0, an empty string is returned.
Arguments:
• strSourceString - This argument is evaluated as a string and contains the source string
from which the sub-string is extracted. This is a required argument.
• intLength - This argument is evaluated as an integral number and specifies the number of
characters in strSourceString to return. This is a required argument.
• String
Examples:
String Return: “$23.09”
String Return: “Total Cost: $23.09”

@TAB
The TAB function takes no arguments. It returns a tab <HT> character (0x09). This function is
most often used to insert a tab into a text value for the purpose of formatting.
Arguments: N/A
• String
Examples:
String Return: “The following are open statuses: Active; Approved; In Progress”
@TRIM
The TRIM function removes any whitespace characters from the beginning and end of a given
string. Any whitespace within the string is unaffected. The following are considered whitespace
characters and will be removed from the beginning and end of the given source string:
• horizontal tab
• vertical tabs
• space
• newline
• carriage return
• formfeed
Arguments:
• strSourceString - This argument is evaluated as a string and contains the source value
from which whitespace characters will be trimmed. This is a required argument.
• String
Examples:
String Return: “The Customer’s first payment is due today.”

@UPPERCASE
The UPPERCASE function converts all alphabetical characters in the source string to lower case
and then returns the result. Any non-alpha characters, such as numbers or symbols, are
unchanged, as are any characters that are already lower case.
Arguments:
string value whose alphabetical characters are to be converted to lowercase.
• String
Examples:
String Return: “TOTAL COST: $354.98”

System Functions
The system functions within the Rule definition type provide access to information about the
Agentry Client application and the system (i.e. the Client Device) upon which it is running. This
information includes the system’s current date and/or time; whether a module of the client appli-
cation is enabled or disabled; whether or not the client is currently offline; and the user ID of the
current user.
Time and Date Formats

There are three system functions that return the time and/or date: DATE, DATE_AND_TIME,
and TIME. When one of these values is returned in a string context, it is possible to specify the
format of the return value. This is not required and, if not present, a default format is used.
To provide a format, an optional argument containing a format string can be provided to each of
these three functions. This format string has a specific syntax. Following is an example of this
syntax, which formats a date and time value.
t={hh:mm:ss tt} d={dddd, MMMM dd, yyy}
This format string will result in a time and date similar to the following:
10:32:04 PM Saturday, December 12, 2001
The format of a time is provided using the syntax:

t={format string}
The date format is provided as:

d={format string}
The t and d characters that begin each string indicate that the format being provided is for the time
or date portion, respectively, of the value. This character is then followed by the equal sign, and
finally the picture of the value to be returned, enclosed in curly braces. The format string within
each of these can consist of specific characters (listed shortly) to provide the desired date and time
format. Any other characters within this string are passed to the result unchanged (such as the
colons in the time or commas in the date of the previous example).
The following two tables list the time and date formats that can be used in the format string:
Table 3-1 Time Formats
PICTURE DESCRIPTION
H Hours with no leading zero for single-digit hours; 12-hour clock.
Hh Hours with leading zero for single-digit hours; 12-hour clock.
H Hours with no leading zero for single-digit hours; 24-hour clock.
HH Hours with leading zero for single-digit hours; 24-hour clock.
M Minutes with no leading zero for single-digit minutes.
Mm Minutes with leading zero for single-digit minutes.
S Seconds with no leading zero for single-digit seconds.
Ss Seconds with leading zero for single-digit seconds.
T One character time-marker string, such as A or P.
Tt Multi-character time-marker string, such as AM or PM.
Table 3-2 Date Formats

PICTURE DESCRIPTION
D Day of month as digits with no leading zero for single-digit days.
Dd Day of month as digits with leading zero for single-digit days.
Day of week as a three-letter abbreviation. The function uses the
ddd LOCALE_SABBREVDAYNAME value associated with the specified
locale.
Day of week as its full name. The function uses the LOCALE_SDAYNAME
dddd
value associated with the specified locale.
M Month as digits with no leading zero for single-digit months.
MM Month as digits with leading zero for single-digit months.
Month as a three-letter abbreviation. The function uses the
MMM LOCALE_SABBREVMONTHNAME value associated with the specified
locale.
Month as its full name. The function uses the LOCALE_SMONTHNAME
MMMM
value associated with the specified locale.
Y Year as last two digits, but with no leading zero for years less than 10.
Yy Year as last two digits, but with leading zero for years less than 10.
@DATE
The DATE function will return a date value that is either the current date of the system, or, if an
argument is provided, the date value of that argument. The argument can be a data type of either
Date, or an integral number representing the number of days since epoch, which is January 1st,
2001. Negative values represent dates prior to epoch. This argument may also be a string value
containing a date, such as 10/19/2000, which will also be converted to a date by the function.
This conversion is dependent on the configuration of the client device and its set locale. If the
function is unable to convert the given argument to a valid date, whether it be a numerical value,
or a string, the function will ignore the given argument and return the current date of the client
device.
Arguments:
• DateValue - This argument is evaluated first as a Date property, then, if found not to be a
date property, then as an integral value, and, finally, a string. The function attempts to
convert the value of this argument to a valid Date. This argument is optional.
• strFomatString - This argument is optional and is only respected by the function if called
in a string context. It specifies the date format of the string returned by the function. If
this argument is not present, the format of the string returned is the one specified by the
client device’s locality settings.
Evaluation Type: Date
• Integral Number
• Decimal Number
• String
Examples:
Integral Return: The number of days since epoch: e.g, 1590 would be the value returned if the
date is May 9th, 2006.
Decimal Return: The number of days since epoch: e.g, 1590.0 would be the value returned if the
date is May 9th, 2006. Though this is a decimal value, the return will always be whole numbers.
String Return: “May 9th, 2006”
@DATE_AND_TIME
The DATE_AND_TIME function will return a date and time value that is either the current date
and time of the system, or, if an argument is provided, the date and time value of that argument.
The argument can be a data type of Date and Time, or an number representing the number of sec-
onds since epoch, which is Midnight, January 1st, 2001. Negative values represent dates and
times prior to epoch. The second argument to the function specifies the format of the return value
in a string context. It is ignored in all other contexts.
Arguments:
• DateTimeValue - This argument is evaluated first as a Date and Time property, then, if
found not to be a date property, as an integral value. The function attempts to convert the
value of this argument to a valid Date and Time. This argument is optional and, if not
present, the function will return the current date and time of the system.
in a string context. It specifies the date format of the string returned by the function. If
• Integral Number
• Decimal Number
• String
Examples:
Integral Return: The number of seconds since epoch; e.g 133200 would be returned for a date and
time of 1:00:00 PM, January 2nd, 2001.
Decimal Return: The number of seconds since epoch; e.g 133200.0 would be returned for a date
and time of 1:00:00 PM, January 2nd, 2001. Though this is a decimal return, the value will
always be a whole number.
String Return: 1:00:00 PM, January 2nd, 2001.
@TIME
The TIME function will return a time value that is either the current time of the system, or, if an
argument is provided, the time value of that argument. The argument can be a data type of either
Time, or an integral number representing the number of seconds since midnight. Negative
numeric values should not be passed as an argument to the function. This argument may also be a
string value containing a time, such as 3:34:05 PM, which will also be converted to a time by the
function. This conversion is dependent on the configuration of the client device and its set locale.
If the function is unable to convert the given argument to a valid time, whether it be a numerical
value, or a string, the function will ignore the given argument and return the current time of the
client device.
Arguments:
• TimeValue - This argument is evaluated first as a Time property, then, if found not to be a
time property, as an integral value, and, finally, a string. The function attempts to convert
the value of this argument to a valid Time. This argument is optional.
in a string context. It specifies the time format of the string returned by the function. If
• Integral Number
• Decimal Number
• String
Examples:
Integral Return: The number of seconds since Midnight; e.g. 38742 would be returned for a time
of 10:45:42 AM.
Decimal Return: The number of seconds since Midnight; e.g. 38742.0 would be returned for a
time of 10:45:42 AM. While this is a decimal value, the return will always be a whole number.
String Return: “10:45:42”
@MODULE_ENABLED
The MODULE_ENABLED function returns either TRUE or FALSE indicating whether or not
the specified module is enabled or disabled, respectively. It will also return FALSE if the function
named in its argument does not exist on the Client.
Arguments:
• strModuleName - This argument is evaluated as a string and is treated as an internal name
for a module definition. The function will evaluate the named module definition to deter-
mine if it exists and if it is enabled.
• Boolean
Examples: In the following examples, the module Customers is defined and is enabled in the cli-
ent. The module Orders is not enabled.

@OFFLINE
The OFFLINE function determines whether or not the Work Offline setting of the Agentry Client
is set to TRUE or FALSE. If it is set to TRUE, this function returns the value of TRUE; otherwise
it returns a value of FALSE. This function takes no arguments.
Arguments: N/A
• Boolean
• Integral Number
Examples:
Boolean Return: TRUE if Client is offline, otherwise FALSE.

Integral Return: 1 if Client is offline, otherwise 0.
@USERID
The USERID function, as its name implies, returns the user ID of the user currently logged into
the Agentry Client. This is the ID entered by the user to log into the Client, not their Windows
login. This function takes no arguments.
Arguments: N/A
Evaluation Type:
• String
Examples:
String Return: “rjones”

Table Functions
The table functions in the Rule definition type allow access to individual records within Complex
Tables and Data Tables on the Agentry Client. The unique value for the desired record must be
known, as must the table name, to retrieve the desired record.
Within the Rule Editor, there are four functions listed in this category, two for complex tables
(BHT and COMPLEX TABLE) and two for data tables (DT and TABLE). However, both the
BHT and COMPLEXTABLE function perform the same operation with the exact same argu-
ments expected. Likewise, the DT and TABLE functions also are identical in both argument list
and behavior. Therefore, the topics in this section will described the COMPEXTABLE and
TABLE functions only.
@COMPLEXTABLE
The COMPLEXTABLE function returns the specified field from a record in a complex table,
based on the provided search information. This function takes a variable number of arguments,
but must be provided at least two. The first argument is always the name of the complex table to
be searched. The second argument is always a search value. The remaining optional arguments
include additional search values for multi-indexed tables where indexes are structured in a parent-
child relationship, the index to be used to search, and the field from the record to be returned by
the function.
If no search index is specified, the unique index for the table will be used to perform the search. If
no return field is specified, the field upon which the unique index has been defined will be
returned.
If a complex table record is to be retrieved using a search index that is a child index, then that
child index should be provided as an argument to the function. Additionally, there must be one
search value for each indexed field for the ancestors of the child index. So, index C has a parent if
index B, which in turn has a parent of index A. A search value for field C, one for field B, and
one for field A must be provided to the function to perform the search.
Arguments:
• strTableName - This argument is evaluated as a string and contains the name of the com-
plex table to be searched by the function. This is a required argument.
• searchValue1 - This argument is evaluated as the data type of the argument value. It con-
tains the search value for which the record is located in strTableName.
• searchValueN - This argument is evaluated as the data type of the argument value. It con-
tains the search value, in combination with searchValue1, for which the record is located
in strTableName. This argument is required only if the search index argument to the func-
tion is a child index. There must be as many searchValue arguments as their are indexes
above the search index in the hierarchy.
• strIndexName - This argument is evaluated as a string and specifies the index to be used to
search for the desired record in the strTableName complex table. This argument is option-
al. If not provided, the unique index of the complex table is used for the search.
• strReturnFieldName - This argument is evaluated as a string and contains the name of the
field whose value is to be returned by the function when the desired record is found. This
argument is optional and, if not present, the field indexed by the unique index of the table
is the value returned.
• Boolean
• Decimal Number
• Integral Number
• String
Examples: In the following examples, the complex table being searched is listed next.
Table 3-3 Customers Complex Table
ID CUSTOMERNAME CITY STATE ZIPCODE
11254 Acme Insurance Chicago IL 60610
11478 Smith Auto Body New York NY 10928
11928 Tom’s Mini-Mart Los Angeles CA 90211
Hoffman
19283 Beef Village IL 60194
Estates
53648 Home Fixit Center Buffalo NY 10029
31291 Anthony’s Yogurt Stand San Diego CA 90941
This table contains the following indexes:

Table 3-4 Customers Complex Table Indexes
INDEX NAME UNIQUE? FIELD PARENT INDEX
IdIndex Yes ID n/a
StateIndex no State n/a
CityIndex no City StateIndex
ZIPCodeIndex no Zipped n/a


Decimal Return: 0.0
Integral Return: 0
String Return: 0

Decimal Return: 0.0
Integral Return: 0
String Return: “Beef Village”

Decimal Return: 0.0
Integral Return: 0
String Return: Beef Village
@DT
The DT function will return the value portion of the record with a matching key to that provided.
This function takes the name of a data table and a key value to located. It then returns the value
portion of the located record, if any, in a string context. In an integral Number context, this func-
tion will return the record number, based on the order in which the records are listed in the data
table. In a Boolean Context, this function will return TRUE if a matching record is found, or
FALSE if no record is found or the table does not exist.
Arguments:
• strTableName - This argument is evaluated as a string and is required. It contains the
name of the data table to be searched for the search value.
• strKeyValue - This argument is evaluated as a string and contains the key value to search
for within the strTableName data table. This argument is required.
• Boolean
• Integral Number
• String
Examples: The following is the data table CustomerStatuses used in the examples of the DT
function.
A - Active
B - Inactive
C - New
D - Delinquent

Integral Return: 3
String: “New”

Integral Return: 0
Arguments:
•
Evaluation Type:
•
Examples:

AgentryRuleEditorGuide 4 4 2

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

AgentryRuleEditorGuide 4 4 2

Uploaded by

Copyright:

Available Formats

4.4.

Rules and Rule Editor

Syclo International Limited | Europe, Middle East & Africa

An Introduction to Rules in Agentry

Rule Term Functions

Context and Return Types

The Rule Editor

How Rules Work

Overview of the Rule Editor

Adding and Editing Rule Terms

How Rules are Used in Agentry

Initial Value Rules

Rule Data Types

Context and Return Type

Conversion to Collections, Signatures, External Data, and Objects

Conversion to Dates and Times

Conversion to Numerical Types

Context and Target Paths

Context and Rule Term Function Behavior

Overview of Rule Term Functions

Strong and Loose Typed Function Arguments

More on the Rule Editor

Rule Term Functions

Decimal Return: 12.34

Decimal Return: 2.0

Decimal Return: 12.0

Decimal Return: 2.0

Decimal Return: 12.3

Decimal Return: 2.00

Decimal Return: 12.34

Decimal Return: 2.0

Given: All Globals are TRUE

Property Return: The property at the second position.

Boolean Return: TRUE

Boolean Return: FALSE

Boolean Return: TRUE

Boolean Return: FALSE

Given: Each Global has a value of TRUE.

Boolean Return: TRUE

Boolean Return: FALSE

Boolean Return: TRUE

Boolean Return: FALSE

Boolean Return: TRUE

Boolean Return: FALSE

Supported Return Types:

Given: All Globals are True

Examples - 2nd Form:

Given: All Globals are FALSE

Given: All Globals are TRUE:

Decimal Return: -1.1

Decimal Return: -3.0

Decimal Return: 12.0

Given: All Globals are FALSE:

Decimal Return: -7.0

Given: All Globals are TRUE:

Decimal Return: -1.1

Decimal Return: -3.0

Decimal Return: 12.0

Given: All Globals are FALSE:

Decimal Return: 13.5

Decimal Return: 18.0

String Return: “Hello out there.”

String Return: “Head 2 Head.”

Given: actionSupported is TRUE, all other Globals are FALSE: