Working with Fields

Fields are the input elements that comprise the entity's data structure, along with rule calculations and rules. Fields, unlike calculations and rules, do not have dependencies on other fields, calculations, and rules. Field values are provided to the rule engine from the calling application or are entered by the user in the testing tool.

Beyond its name, data type, and default value, you can describe fields via other properties including field-level validations, UI control representation, notes, and associated categories.

Adding a field

Right-click on the element to which you want to add to. Select Add -> Field

Deleting a field

There are a few ways to do this:

1. Right-click on the field you wish to delete, and select Delete.
2. Click on the field you wish to delete and click Delete on the Home Banner.
3. Click on the field you wish to delete and hit the Delete key on your keyboard. 

You will be prompted to confirm the deletion. Click Yes.

Settings

Name

Specifies the name of the field. For fields that are based on an external source, this value may not be modified.

Display Name

Specifies the name that will be used in the business language editor when referring to this field.

Data Type

Specifies the data type of the field. The available options are:

• Text
• Integer
• Date
• DateTime
• Decimal
• Boolean
• Complex
• Entity

Entity

If Entity is selected for Data Type, the entity type is selected here.

Parent Context

If Entity is selected for Data Type, checking this box will allow rules running on the field's entity type to reference fields on this entity, the parent.

Default Value

Specifies the default value of the field.

The default value may be specified for either value-type fields (text, integer, …) or entity fields.

For Entity Fields, the Default Value checked specifies that the field should be instantiated/assigned when the containing entity is first instantiated. The XML state of the entity may be optionally specified to set its initial state when instantiated.

For fields of type date and datetime, default values must be prefixed and suffixed by a # character. e.g., #2/4/2004#, #2004-02-04#. Optionally time zone suffix can be specified such as #2004-02-04T01:03:00 -06:00# or #2004-02-04T07:03:00Z#

Value List

Any field may have a Value List associated with it, which is a list of values for the field – this list may optionally be set to constrain the valid values for the field at runtime via the “LimitToValueList” constraint.

Vocabulary

Clicking on the hyperlink will navigate to the Vocabulary folder for the entity in which this field is contained. Any field or entity may have one or more classifications associated with it, such as a “Young” classification for an “Age” field meaning < 30 years.

Rules

For fields that have a Data Type of "Entity", a Context rule set can be defined with the field to associate rules that are specific to the context in which the entity is used within the field.

Constraints

Any field may have one or more Constraints associated with it, which will automatically be enforced for any data that is set for the field. When a Constraint is violated, InRule triggers a validation message containing information about the field and Constraint that is in violation. Clicking on the Constraint hyperlink will navigate to the Constraints for the entity in which this field is contained. For fields that have a Data Type of Entity, this link is disabled.

Schema Source

Denotes from where the field is derived. Internal schema sources are those that are defined in irAuthor. External schema sources are imported from .NET assemblies, XML Schema or database schema.

Business Language

The business language section contains options for using the field in business language rules.

Uncheck the Include check box to make the field unavailable when writing business language rules, such as "If field is equal to value."

Uncheck the Allow assignment check box to make the field unavailable in any "Set field to value" business language rules.

Testing

If the Show in irVerify box is not checked, the field is not available when testing the rule application in irVerify.

Storage

The Storage section contains options that will impact a field's inclusion in entity state and runtime capabilities.

Temporary

Any element with this box checked will not be saved with Entity State. This check box is also available for collections and calculations. In schema bound rule applications, checking this box indicates the element is not part of the bound model, and will not be removed after reloading any bound models.

Fields having the Temporary Storage setting checked can be thought of as "Entity scope" variables.

Fields, calculations, and collections set to the temporary state are not saved to the XML output file when saving Entity XML in irVerify; however, these elements can get saved to a Test Scenario output file via irVerify options.

Read Only

This is an authoring-time setting that enforces whether a Field may be modified at runtime. If the rule application is bound to a schema that indicates that the field is read-only (e.g. only Get property exists for a .NET assembly bound schema) this checkbox will automatically be set to true.

During runtime, if either a rule or an SDK call attempts to set the value of a Field with this option selected, a ReadOnlyFieldException will be thrown.

The following are the only mechanisms by which initial data may be loaded into fields with this setting set to true. They must all result in a new Entity State being created as a result of their actions:

• EntityState.Load() / EntityState.LoadXml()
• AddCollectionMember Action
• ExecuteSQLQuery Action
• ExecuteWebService Action
• ExecuteXPathQuery Action

The benefit of setting RuntimeReadOnly on a Field is improved performance when executing one of the following collection functions with a FilterBy and/or OrderBy option:

• Aggregate functions (Count/Sum/Min/Max/Avg/Average)
• CollectionLookup
• GetMember
• GetMemberValue
• GetFirst
• GetFirstValue
• GetLast
• GetLastValue
• GetMemberByIndex
• GetMemberValueByIndex
• ExecuteMemberRuleSet Action

Constraints

Any field may have one or more Constraints associated with it, which will automatically be enforced for any data that is set for the field. When a Constraint is violated, InRule triggers a validation message containing information about the field and Constraint that is in violation. Constraints that are violated result in the associated field being "invalid". Please see the Validity Templates section for more information.

Constraints are evaluated as one of the first steps to the "Apply Rules" process and are re-evaluated every time the value of the associated field has changed.

The Constraint violations can either be set to display the system Default message or custom tokenized messages. Tokenized messages may include one or more embedded rule expressions, such as <%RecID%> to display the contents of the RecID field in the message.

Constraints come in two flavors, they can either be set to "Deny" specified values or "Allow" only specified values.

• Available constraints include:
  • LimitToValueList
  • NotNull
  • MinimumValue
  • MaximumValue
  • NumberOfDigits
  • NumberOfFractionDigits
  • PatternMask
  • =, <>, <, >, <=, >=
• Field Validations continue to be supported but Constraints are recommended for newly developed rule applications.
• When one or more XSD Schemas are in use, Min, Max, and other facets are automatically imported as field Constraints. Enumeration facets are optionally imported as a Field Value List with a LimitToValueList field constraint set.
• When one or more .NET Assembly Schemas are in use, the Enums associated with any properties or fields are optionally imported as Field Value Lists with the LimitToValueList field constraint set.

For many rule applications, Constraints play an important role in providing low-level field validation for an overall validation scheme.

To view/edit constraints for an entity, click on the Create Constraints link,

and the following view is shown.