IDO Data Rules Wizard form

The IDO Data Rules Wizard form provides a guided experience to create a data rule. This form is accessible from both the IDOs form and the IDO Data Rules form. You cannot add a rule to an extended IDO if a rule with the same name already exist in an ancestor IDO. This form is used from the IDO Data Rules form after checking out an IDO, selecting the Data Rules button and then the New Data Rule button.

IDOs form integration

The IDOs form includes these additions for data rules:
  • New Data Rule button launches the IDO Data Rules Wizard. This follows the same enablement rules as new table, new property, and new method.
  • Data Rules button opens the IDO Data Rules form as a linked child. This supports INCLUDEBASE to display rules from ancestor IDOs on extended IDOs.
  • Data Rules tab contains a read-only sub-grid of data rules.

IDO Data Rules IDO

An extension class for IdoDataRules is added in MGCoreExt including inheriting from InheritedObjectBase for support of CVMD and INCLUDEBASE keyword support.

IDO metadata definition caching

IDO Data Rules and Data Rule Actions are added to IDODefinition within IDO MetadataCache for rules that are Active.

  • Activation Conditions for a data rule are converted into a single conditional action expression stored on the Data Rule in the IDODefinition

  • Filter Conditions for a data rule are converted into a single conditional action expression stored on the Data Rule in the IDODefinition

  • Rules can be added to extended IDOs and inherited from base to extended IDOs

  • Extended IDOs cannot override rules from base IDOs

IDO runtime

An IDO-based conditional action evaluator is created based on the form runtime’s DoConditionalAction. This evaluator supports evaluating property values and modified state of a property from IDOUpdateItem and supports the current state of a feature flag. It is used to interpret activation conditions and filter conditions.

During UpdateCollection processing, data rules matching the operation type (insert, update, delete) are found and evaluated:

  • Activation conditions are evaluated per rule and cached per site. The cache is cleared on IDO cache clear.

  • For active rules, filter conditions are evaluated for each row in the update request.

  • All other actions are applied before action methods.

  • Action method pre-save is called before standard save.

  • Action method post-save is called after standard save.

IDO import and export

These IDO objects are included in import and export operations:

  • IDODataRules
  • IDODataRuleActivationConditions
  • IDODataRuleFilterConditions
  • IDODataRuleActions

These are supported in IDO check-in and check-out, IDO import and export forms, AppMetadataTransport, and Deployments.

Form runtime IDO metadata transfer and caching

Metadata for IDO Rules is added to the GetPropertyInfo request and response. The requestor can request the inclusion of rule info. When GetPropertyInfo is called for forms, rule info is requested.

The client metadata cache is updated to hold IDO Rules including the conditional action expression for filter conditions. Rules that are not active, fail activation conditions, or have Inherit to UI set to false are not transferred to the client.

Conditional Action expressions are enhanced to include modified state of a property. Data rules are inherited and applied to forms. Collection-level opt-out from inheritance is supported. All action types except Action Methods and Set Property Updateable are applicable to forms.

Form Diagnostics

Diagnostic messages are added to category component, Dependent Notification. The diagnostics are enabled through View > User Preferences > Diagnostics and is displayed such as below. The Client diagnostics in the web client show evaluation and activation of data rules and component values changed by data rule actions.

Edge cases and additional details

A Set Property Value action runs in the IDO tier during UpdateCollection processing. It should not be used for a value that is set by a rule and later updated by a user in the UI, as the value would be overwritten again during save. It would be best practice here to use Set Property with Read-Only fields on a form.

If multiple rules are active simultaneously and their actions overlap, some results may be arbitrary. Care should be taken when defining data rules to avoid overlapping situations.

  • If multiple Set Property Value actions are active for the same property, the property is set to the value from the last action executed.

  • If multiple Default Property Value actions are active for the same property, the property is set by the first action executed. And because the action leaves the property in a modified state, subsequent actions will not change the value.

  • If multiple Set Property Validator actions are active for the same property, the validators are additive. All validators must pass for the value to be valid.

  • If multiple Set Property Domain or Set Property Inline List actions are active for the same property, the value from one of the actions is used arbitrarily. Avoid this scenario.

UI-based list sources and validators override IDO-based domain, inline list, and validators within the UI. IDO-based settings still apply during UpdateCollection processing. Remove UI-based overrides if IDO-based settings should display in the UI.

New rules can be added to extended IDOs, but rules on ancestor IDOs cannot be changed or overwritten by extended IDOs.

AES row suspension

A row update can be suspended by AES (Asynchronous Event System). If an action method is run before save, it will run before a row update is suspended. The original update transaction is rolled back when the row is suspended. When the suspension is complete and the update is processed, the pre-save action method runs again.

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.

Key decisions

  • Activation Conditions (table: ObjDataRuleActivationConditions) and Filter Conditions (table: ObjDataRuleFilterConditions) are separated for efficiency and readability. Activation conditions are evaluated once and cached. Filter conditions are evaluated per row.
  • Conditions are stored as rows in sub-tables rather than a programmatic conditional action syntax, making them more readable and more maintainable.
  • Rules on ancestor IDOs cannot be changed or overwritten by extending IDOs, ensuring data integrity enforcement.