Use of Standard Rules in MDM Forms

In MDM Forms are two types of rules available: Standard and Custom. In this article, we cover the use of Standard rules in an MDM Form.

In the AppBase Eccentex platform, the MDM (Master Data Management) Forms feature offers users a dynamic and versatile approach to streamline data entry and management. Within the realm of MDM Forms, there are two distinct types of rules that play a crucial role in shaping the behavior and functionality of these forms: Standard Rules and Custom Rules. In this article, we will delve into the realm of Standard rules, exploring how they can be effectively harnessed to optimize the performance of MDM Forms.

Standard rules within MDM Forms are pre-defined and structured rules that enable users to set up automated actions and behaviors without the need for intricate coding or programming skills. These rules come pre-packaged with the AppBase Eccentex platform, designed to cater to common scenarios and requirements encountered during the design and usage of MDM Forms.

The implementation of Standard rules provides users with a streamlined and user-friendly approach to configuring their forms. These rules offer a range of functionalities that can be easily applied to fields within the form, enhancing data validation, automating calculations, and enabling conditional actions. By using Standard rules, users can enforce data integrity by specifying validation criteria, automatically populating fields based on certain conditions, or triggering specific actions when data is entered or modified.

A key advantage of utilizing Standard rules is the reduction of complexity and the acceleration of form development. Users can leverage these rules to quickly and efficiently set up common form behaviors, saving valuable time and effort that would otherwise be spent on manual configuration or custom scripting.

In this article, we focus specifically on the utilization of Standard rules within MDM Forms. We will explore their application through practical examples, guiding users through the process of configuring these rules to achieve desired outcomes. By understanding and harnessing the power of Standard rules, users can unlock the full potential of their MDM Forms, creating streamlined, efficient, and user-friendly data entry and management solutions.

Standard rules within AppBase Eccentex's MDM Forms offer a simplified yet robust method for automating actions and behaviors within data entry forms. By providing a library of pre-defined rules that address common use cases, users can enhance their form development process, ensure data accuracy, and create dynamic and responsive form experiences without the need for extensive coding expertise. This article serves as a comprehensive guide to effectively utilize Standard rules and maximize the benefits they bring to MDM Forms within the AppBase Eccentex platform.

Components of the Standard Rules

Condition Type: The Condition Type defines the trigger that initiates the rule. It specifies when the rule should be evaluated and applied based on certain events or conditions. For example, a common Condition Type could be "Field Value Change," indicating that the rule should activate when the value of a specific field changes. Other Condition Types might include "Form Load" (when the form is initially loaded) or "Button Click" (when a particular button is clicked).

Condition(s): Conditions are criteria or requirements that must be met for the rule to be executed. They determine whether the specified Condition Type has been satisfied. Conditions could involve comparisons between field values, the presence of certain data, or specific user roles. For instance, a Condition could be set to check if a dropdown field has a specific option selected or if a numeric field exceeds a certain value.

Action(s): Actions are the predefined behaviors or tasks that the rule triggers when the associated Conditions are met. Actions define what happens as a result of the rule being executed. These can include tasks like populating fields with default values, showing or hiding sections of the form, enabling or disabling certain fields, displaying error messages, or even invoking external processes. For example, when a user selects a particular option from a dropdown list (Condition), an Action could be to automatically populate another field with related data.

Condition Type

You should first select any of the two Condition Types: All or Any.

The Condition Type All means a logical AND, i.e., it'll trigger the form rule Actions only if All the Conditions are True. The Condition Type Any means a logical OR, i.e., it'll trigger the form rule Actions when Any of the Conditions are True.

Conditions

You can add Conditions for any of the MDM Fields on the form. The UI Elements dropdown list shows the fields present in the form. When you select a field from the UI Elements dropdown list, you can select the type of Comparison condition from the dropdown list, and set a Value (if applicable).

In our example, we selected the field Employer from the UI Elements, and select the Is Empty for the Comparison condition which doesn't need a Value.

The available conditions depend on the field type selected. Check the table below for the list of options.

Condition Type	Number/Integer	Date/Percentage	Text/Email	Phone	Reference	Image	Boolean
Is Empty
Is Not Empty
Equal
Not Equal
Contains					(5.3+)
Not Contains					(5.3+)
Less than
Less than or Equal to
Greater than
Greater than or Equal to
Checked
Unchecked

Actions

Actions provide a versatile way to control the behavior and appearance of various components within the form, including UI elements (fields), Containers, and Sections. Each of these elements responds to Actions in distinct ways, enhancing the flexibility and customization options available to form designers. Here's an overview of how Actions work for each type of element:

1. UI Elements (Fields): Actions applied to UI elements, also known as fields, allow for dynamic modifications to individual data entry points on the form. When certain Conditions are met, Actions can be triggered to alter the content, visibility, or behavior of these fields. For example, an Action could be configured to automatically populate a text field with a default value when the form loads or to display an error message if specific validation criteria are not met. Additionally, Actions can enable or disable fields based on user input, creating a responsive and user-friendly form experience.

2. Containers: Containers are higher-level elements that group multiple fields or components together. Actions applied to Containers impact all the contained elements collectively. This means that when a Condition associated with a Container is fulfilled, the Action will simultaneously affect all the fields or components within that Container. For instance, an Action could be used to collapse or expand a Container's visibility based on user selections, allowing for more efficient use of screen space when needed.

3. Sections: Sections are organizational units that help group related fields and components within the form. Actions applied to Sections function similarly to those applied to Containers, affecting all elements within the Section. These Actions are especially useful for controlling the visibility or accessibility of a group of fields based on specific Conditions. For example, a Section containing fields related to "Payment Information" could be hidden until the user selects a specific payment method, at this point, an Action would reveal the Section and its associated fields.

To add an action, select it from the Action dropdown list. Then you have to select the UI Element, Section, or Container to which the Form Rule should apply the Action.

The available Actions depend on the UI Element type selected. Check the list below for the options available.

• Show, Hide: Change the visibility for UI Elements and Containers.
• Enable, Disable: Change the accessibility for UI Elements and Containers.
• Required, Not Required: Change the allowBlank and toggle the red star (*) label flag on/off.
  • These actions are applicable for Containers and Sections: they change the state of all children's fields.
  • Not applicable for the children's Business Objects Searches.
• Clear: Set the field value to NULL.
  • For Radiogroups without None option it will uncheck the active radio and set an undefined value.
  • If this action is applicable for Containers and Sections, it clears all the children's fields.
  • Not applicable for children's BO Searches.
  • Clear action doesn't set the default value of fields.
• Hide & Clear: Just a combination of Hide and Clear.

Attention! Clear action doesn't work correctly with Default Values of Reference Objects if it is triggered on form load.

Case Sensitivity Handling

Details of the comparison behavior for different form rule conditions within Many-to-Many and One-to-Many relationships.

Many-to-Many Relationships. In the context of Many-to-Many relationships, the comparison behavior for certain form rule conditions is case-sensitive. This means that the comparison considers the characters' exact casing when evaluating conditions. The following conditions fall under this case-sensitive comparison:

Equal: When using the "Equal" condition in a form rule within a Many-to-Many relationship, the comparison between values considers the exact case of the characters. For instance, if you're comparing a value like "Apple" with "apple," the rule would not consider them equal due to the difference in casing.

Not Equal: Similar to the "Equal" condition, the "Not Equal" condition in Many-to-Many relationships also performs a case-sensitive comparison. If the characters' casing is different, the condition evaluates to true.

ContainsThe comparison considers the characters' exact case when using the "Contains" condition within a Many-to-Many relationship. For example, checking whether a text field contains the word "Example" would only match instances with the exact casing of "Example."

Not Contains: Like "Contains," the "Not Contains" condition also performs a case-sensitive comparison in Many-to-Many relationships. If the characters' casing differs, the condition is satisfied.

One-to-Many Relationships: Conversely, in the case of One-to-Many relationships, the comparison behavior for the "Contains" and "Not Contains" conditions is case-insensitive. This means that the comparison ignores the casing of characters when evaluating conditions. Here's how it works:

Contains: The comparison is case-insensitive When using the "Contains" condition within a One-to-Many relationship. This allows for a broader match, disregarding the exact casing of characters. For instance, a search for "example" would match "Example" or "EXAMPLE."

Not Contains: Similar to "Contains," the "Not Contains" condition also performs a case-insensitive comparison within One-to-Many relationships. The condition is not satisfied if the characters are present in any casing.

Understanding these comparison behaviors is crucial when configuring form rules within Many-to-Many and One-to-Many relationships. It ensures that the rules behave as expected and accurately reflect the conditions set by the user. By considering the context of the relationship and the specific condition being used, users can make informed decisions when designing their form rules and achieving the desired outcomes in their data management processes.

To learn more, check the following examples of case sensitivity results.

From the DCM version 5.3+ that supported the Many-2-Many Reference Objects, pay attention to the difference of the Condition types "Contains"/"Not contains" for the different Reference Objects:

1. For One-to-Many Dictionary words, it works as string matching with code: ENG match ENGLISH
2. For Many-to-Many Dictionary words, it matches any code from the common-separated value list: ENGLISH, ARABIC matches ENGLISH or ARABIC, CHINESE etc
3. For One-to-Many Reference Objects, the condition "Contains" does not work for Numeric values like ID
4. For Many-to-Many Reference Objects do not support Numeric values like an ID for "Equal" and "Contains" conditions

Custom Form Rules

You can read about how to add a Custom Rule in the following article How To Add a Custom Rule in MDM Forms

Related Articles

• How To Add a Custom Rule in MDM Forms