Every rule application has a number of configurable settings that apply to the entire rule application. Clicking on the Settings button on the Home Tab will bring up the rule application's settings:
Specifies the name of the rule application.
Rule Application Settings
Tree Node Labels
Specifies how element names for Rules, Set Value Actions and other specially handled items are displayed within the tree:
- Static Names- Always display the physical names of rules in the tree
- Derived Names- Always display virtual descriptions of rules in the tree based on the type of rule
- Mixed- Display the virtual descriptions of rules, unless the default rule name has been overwritten, in which case use the new name
Enabling/disabling of rule sets
Specifies that rule elements may be selectively disabled by the author.
Access to parents from Language Rules
Makes the parent context available in the business language rule editor.
Specifies a timeout period for when rules are applied. This setting, along with Max Cycle Count, can be increased for highly complex rule applications.
Max Cycle Count
Specifies a maximum cycle count for rules execution. This is used to prevent infinite while loops and infinite re-execution of rules due to changes in dependencies. The counter is incremented whenever an Entity is walked, a Calculation Field evaluates, or a Rule/Action executes.
Test in Separate Memory
IrVerify runs in an isolated app-domain (separate memory space). This allows memory to be reclaimed and protects irAuthor from errant third-party function libraries that may crash the application. The primary disadvantage is the slower load time of the first test run. The isolated irVerify app-domain may be unloaded at any time from the irAuthor Options menu, freeing up all runtime-specific memory. This will also have the effect of closing all open irVerify windows.
Error handling policy
Specifies how the runtime should proceed after a runtime error occurs during rule processing.
Tells the rule application to make versioning available. This allows the calling application to set dates in the rule application that determines which rule and calculation versions to use if there are other versions in addition to the default. All calculations have a default version which is used if no matches are found.
When the Use versions option is checked, a Versions tab is enabled on all of the following editors:
- If/Then rule (condition expression)
- If/Then/Else rule (condition expression)
- While rule (condition expression)
- Set Value action (value expression)
- Decision Table
- Language Rule
- Calculation Field
- Inline Table
- Database Table
In addition, a Version Settings tab is enabled (providing the ability to override the version criteria at different contexts) on the following editors:
- Rule set
- If/Then rule (only when authored at the root of a rule set)
- If/Then/Else rule (only when authored at the root of a rule set)
- While rule (only when authored at the root of a rule set)
- Language Rule (only when authored at the root of a rule set)
- Decision Table (only when authored at the root of a rule set)
Versions are described in more detail in the Versioning section.
This specifies the effective date used to determine which version to use for a particular rule, calculation or inline/database table at runtime. This may either be the current Date or a specific date, which should be any field name or syntax expression that resolves relative to a versioned element. The version selected will be the one equal to or greater than the resolved date.
This is disabled by default, but adds a second dimension to the version selection at runtime. If enabled, it specifies the created date used in conjunction with the effective date to determine which version to use for a particular rule, calculation or inline/database table at runtime. The current date and specific date options resolve the same way as the Effective date.
Tells the rule application to enable the XML settings for Fields. This allows users to specify whether a field is rendered as an element or attribute in the XML when the schema is defined by the rule application (as opposed to being bound to an external schema).
Internal schema XSD validation
Allows for the internal validation of the XSD contract to be enabled or disabled. By default, XSD validation is enabled.
Allow hierarchical rendering with duplicate instances
Allows for the retrieval of XML from entity state when there are multiple entity references to the same entity instance. This will render duplicate XML for repeat entity references.
Please sign in to leave a comment.