IDO Data Rules form

The form contains:

Header fields: IDO Name, Rule Name, Operation Type, Active flag, Inherit to UI flag.
Activation Conditions grid: Feature ID and Operator columns.
Filter Conditions grid: Sequence, Property Name, Operator, Value Type, Value, Comparison Property Name, And With Next.
Actions tab with the Actions grid and context-sensitive editor buttons including Edit Validators, Edit Inline List, and Edit List Properties.

What is a data rule?

The IDOs form includes the following additions for data rules:

Rule Name - a unique name identifying the rule within the IDO.
Active - a flag indicating whether the rule is active, useful during development and testing.
Operation Type - the type of operation to which the rule is applicable: Insert, Update, Insert or Update, or Delete.
Inherit to UI - a flag that indicates wheter this rule is iherited to forms.

A rule contains:

Zero or more preliminary activation conditions based on system settings.
Zero or more filter conditions for activation per data row.
Zero or more actions that run when a rule is active.

Activation conditions

Activation Conditions determine if a rule is applicable based on system settings. All Activation Conditions must be true for a rule to be active. Activation Conditions are evaluated once during the first use of a rule and the result is cached. Rules can be cleared from the cache using IDO Cache Clear.

Each Activation Condition includes:

Sequence
Feature ID from Feature Manager or Feature Management in CSI
Comparison Operator, either "Is Active" or "Is Not Active"

Example:

Feature ABC_123 Is Active

Filter conditions

Filter Conditions define data conditions that must be met by a data row for a rule to be activated. Filter Conditions are processed for each data row in a request.

Each IDO Data Rule Filter Condition includes:

Sequence - number for ordering and uniqueness.
Property Name - name of the property in payload whose value is used in the filter.
Comparison Operator - standard comparison operators, Is Modified or Is Not Modified.
And With Next Condition - checkbox, default checked, determining logical AND/OR to combine with the next condition.

The set of conditions must evaluate to true for the rule to be activated for the data row.

Example:

CreditHold = (Literal) 1
CreditLimit Is Modified
QtyShipped < (Property) QtyOrdered

Actions

An IDO Data Rule Action defines an action to be taken when the rule is activated. Actions are started in a sequence order.

These are the action types available:

Set Property Value - sets a property value. Property Name and Property Value are enabled.
Default Property Value - sets a property value if it is blank and is not already modified.
Set Property Updateable - overrides read-only to allow the property to be updated through the IDO. Property Name is enabled.
Note: This action is not inherited to forms
Set Property Enabled - overrides read only to allow the property to be updated through the IDO and enables bound UI components. Property Name is enabled.
Set Property Required - sets the property as required and enforces during save. Property Name is enabled.
Set Property Validator - overrides a property’s validator. Validators are enabled. The Edit Validators button is visible and enabled.
Set Property Inline List - overrides the inline list definition of the property. Inline List is enabled. The Edit Inline List button is visible and enabled.
Set Property Domain - overrides the domain of the property, used by forms as in collection list source. Domain IDO Name, Domain Property, and Additional List Properties are enabled.
Call Action Method Pre-Save - calls a new type of extension class method before standard save. Action Method Name is enabled. Pre-save methods should generally be used for complex validation or other pre-save activity that can be rolled back. Any permanent changes should be made by action methods after save. The Pre-Save Methods fire as a part of the overall save process, but before AES Events and Data Rule Post Save Methods.
Note: This action is not inherited to forms.
Call Action Method Post-Save - calls a new type of extension class method after standard save. Action Method Name is enabled. Post save is most suitable for actions after the data is changed like sending a bod or a notification.
Note: This action is not inherited to forms.

Unlike SQL, having Filter or Action comparison conditions where the Property = blank or no value is allowed and would evaluate like IS NULL in a query.

Note: For clarification in Mongoose saving occurs as a part of an overall process.

A simplified representation of this process including a current order of the process.

DataRules PreSave Methods
Pre-AES (like IDOOnItemUpdate) Events and Extension Class Events
The save of the data being committed to the database
Post-AES (like IDOPostItemUpdate) Events and Extension Class Events
DataRules Post-Save Methods.

So, the Data Rule Methods fire outside or wrap the AES and Extension Class methods.

Action method

An Action Method is a type of method in an IDO extension class that can be called directly from an IDO Data Rule Action.

Action methods can be called before or after standard save processing.
Action methods can be used for use cases that are not covered by other action types.
Action methods apply only to the IDO tier and are not inherited to forms.
An exception thrown in an action method will stop the save operation. The best practice is to add Validators to ensure any data required by the method is provided prior to save.
An action method is called for a single item (row).
An action method accepts two input parameters: UpdateCollectionRequestData and IDOUpdateItem.
Using an Action method would make use of the IDO Extension Class Assemblies form, and its Source Code/Build capabilities.
If it is necessary to send data from a form to a Pre or Post Save method, the components passing the data from the form must be bound to Unbound Properties on the IDO and then the properties can be read from the payload of the request. In the lines of code below, ToEmailAddress, Subject and Body are examples of properties that are being passed to a c# method.
```
string toAddress = updateItem.Properties["ToEmailAddress"].GetValue( string.Empty );
string subject = updateItem.Properties["Subject"].GetValue( string.Empty );
string body = updateItem.Properties["Body"].GetValue( string.Empty );
```

Form inheritance

Data rules inherit to form collections to apply actions to forms.

All action types except Call Action Method and Set Property Updateable are applicable to forms.
A form collection (Primary, Secondary, and Subcollection) setting allows a collection to opt out of inheriting data rules.

Form designer: bypassing data rule inheritance

A form collection setting allows opting out of data rule inheritance at the form level. When bypassed, data rules still apply at the IDO tier during save operations.

The Bypass Data Rule Inheritance option is available in:

The Collection Editor for Primary and Secondary collections.
The Subcollection Editor for Subcollections.
A data rule also contains and Inherit to UI flag to selectively inherit rules to forms.
Rules that are not active, fail activation conditions, or have Inherit to UI set to false are not transferred to the client.
Actions for active rules are transferred to the client to be applied to forms.

Substitution keywords

Specific substitution keywords can be used as the value for Set Property Value and Default Property Value actions. Keywords are substituted with their current value at the time the action runs.

Supported keywords are:

CURDATE() - current date
CURDATE() CURTIME() - current date and time
USERNAME() - current user name

Below is an example of using a substitution keyword that will set the Username property on an IDO based upon the user that is currently logged into Mongoose using the keyword USERNAME().

Keyword substitutions are not currently supported ion the Filter Conditions tab, in the Property Value column.

Feature settings integration

The active or inactive state of a Feature can be checked in a Data Rule Activation Condition. Feature flags are cached per site once retrieved. The cache is cleared by the IDO Cache Clear.

The active status of a feature can be accessed from IDO extension class code using IDORuntime.GetFeatureActive( string featureId ).

The value is loaded into the cache as needed an remains until the cache is cleared.