Key concepts
Concepts overview
The add-on manages rules as real assets. This enables a better understanding of which rules are executed on which tables. Additionally, time and effort is saved by eliminating the need for the IT department to hand-code rules. At the same time the ability to apply business audit operations is enforced. Overall, MDM agility and transparency are greatly increased.
The add-on manages both business rules and permission rules. The portfolio of rules automatically displays through a Java introspection of the rules implementation layer (refer to the Java doc to apply the standard Rule Interface when deploying a new rule). After selecting a rule in the portfolio, you can configure and adapt its behavior to meet your specific needs. To achieve optimal configuration, a metadata set are available such as: period of activation (from date to date), user messages, input parameters, contexts of execution, etc.
You can configure a rule to execute on a type of business object such as a table. This table is identified with the generic term 'Data Element Concept' (D.E.C.). A D.E.C. type is not limited to a table; it can be any asset, such as a table, a field, a workflow, a data space, a data set or a service. This is an ISO-IEC 11179 concept already used in the TIBCO EBX® Information Governance Add-on and TIBCO EBX® Insight Add-on for the management of data quality indicators.
Special notation | |
|---|---|
| The scripting language included in the add-on should be used in two situations due to the response time:
|
Global architecture
From an implemented rule (Java implementation) one to many Rule definition(s) are declared in the add-on. Alternatively, you can use a script to create a rule definition.
Every rule definition configures a metadata set, including the parameters published by the rule implementation, the user message in case of error, etc.
The rule definition is attached to a Table on which this rule must be executed. A permission rule type can be applied to other D.E.C.(s). such as a field, a service, a data space or a data set.
A Rule execution can be configured and declares the conditions that must be met before a rule can be executed. For example, conditions that must be met can include: an event such as "on demand" (user activation), the creation of a record, a validity date, etc.
In earlier versions of the add-on, you could configure a Simple expression when complex business conditions beyond an event or record creation are required for rule execution. However, from version 1.3.0, you use a Java implementation or a script to define business conditions for rule execution instead of using a simple expression.
Online quick view
During the process of creating rules, it can be helpful to view reminders of key concepts used in their configuration. To show these reminders, it includes the 'quick view' icon on the top-right of the tabular view. The icon 'quick view' is located at the top-right of the tabular view as illustrated below.
How context expressions and rule definitions interact
The following figure outlines how a context expression and rule definition work. The rule executes if the context expression returns 'True'. You can configure the context expression and the rule using a Java implementation or by writing a script. For the rule definition, you can use a predefined rule provided with the add-on, or implement your own bespoke rule using Java or a script.
In the example below, a context expression declares that a 'Name' must start with an uppercase letter. This expression can be implemented using Java or a script.
If a name starts with an uppercase:
According to the assertion this would be not 'False'.
The 'Rule definition' is bypassed.
No error is raised.
If a name does not start with an uppercase:
According to the assertion this would be a not 'True' scenario.
The rule executes.
A value of 'False' is returned.
