| Both sides previous revision Previous revision Next revision | Previous revision |
| 3400_how_to:0400_business_rules [2026/08/13 01:10] – external edit 127.0.0.1 | 3400_how_to:0400_business_rules [2026/08/13 07:43] (current) – Imported by DokuWiki Advanced Plugin aware_support3 |
|---|
| ====== Business Rules ====== | ====== Business Rules ====== |
| | |
| | ===== What is the difference between processes and business rules? ===== |
| | Business rules encapsulate business logic of the system, i.e. they encapsulate any rules that are not related to the user interface (or any other external interface to the system). Processes, on the other hand, provide a bridge between business rules and the user interface (or any other external interface to the system). Usually processes just activate business rules in response to some external request and deliver the end result to the requestor. Therefore processes should not include business logic in their rules and conversely, business rules should not invoke actions that interact with a user (such as ''[[ref:a_f:a:enter_new|ENTER NEW]]'', ''[[ref:a_f:a:edit|EDIT]]'', ''[[ref:a_f:a:pick_from|PICK FROM]]'' and others). See also the “[[2000_concepts:0200_basics:0200_business_rules_carriers_business_logic|Business Rules as Carriers of Business Logic]]”, “[[2000_concepts:0200_basics:0300_processes_link_ui_business_logic|Processes as Links Between User Interface and Business Logic]]”, “[[2000_concepts:1000_config_proc:0500_config_guide|Configuration Guidelines]]” sections. See also [[3400_how_to:0100_awareim_basics]]. |
| | |
| | ===== How to ... ===== |
| |
| {{simplenavi>.:0400_business_rules}} | {{simplenavi>.:0400_business_rules}} |
| | |
| | <accordion autoclose> |
| | |
| | <anchor id="define_a_rule"> |
| | <accordion-item title="define a rule"> |
| | Most business rules are evaluated when a particular business object is created or modified and therefore most rules are attached to business objects. Some rules may also be attached to notifications (they are evaluated when a notification is created or received) or to timer events (scheduling rules). A rule consists of a condition (which is optional) and actions. To define a rule you need to specify these conditions and actions using the Rule Language. To make this task simpler //**AwareIM**// provides the Context Assistant, which prompts you for the right actions and conditional expressions to use when defining a rule. You can also use the information provided in the [[:3000_rule_language|AwareIM Rule Language Reference]] section. |
| | </accordion-item> |
| | |
| | <anchor id="find_a_rule"> |
| | <accordion-item title="find a rule"> |
| | An application that you configure may have many rules. If you want to find a particular rule in the Configuration Tool you can use “Search Rules” functionality – see the [[2500_config_apps:0400_finding_element_usage|Searching Rules]] section. You can also use various filtering options available in the Rule Collection Editor. The Rule Collection Editor may display all rules in the application or only rules attached to a particular business object or notification – see the “[[2500_config_apps:0800_add_edit_rules:0100_working_rule_collections|Working with Rule Collection Editor]]” section. |
| | </accordion-item> |
| | |
| | <anchor id="deal_with_rules_that_need_to_be_evaluated_in_a_strict_order"> |
| | <accordion-item title="deal with rules that need to be evaluated in a strict order"> |
| | Quite often you are dealing with the situation when rules need to be evaluated only after the action of the previous rule has been executed, i.e you seem to be dealing with the ordered sequence of rules. However, in //**AwareIM**// most rule sequences are un-ordered (except processes that have “Maintain Order” property checked), i.e. //**AwareIM**// does not guarantee the order in which rules will be evaluated (see the “[[2000_concepts:0800_data_processing:0100_rule_evaluation|Rule Evaluation]]” section). |
| | |
| | One way around this is to use an ordered process, however, this approach is not recommended as the general solution, as the process should not contain any business logic (see [[3400_how_to:0400_business_rules]]). The better solution is to get rid of the explicit order and break up an ordered rule sequence into a number of independent rules that get triggered when the value of some attribute or list changes. One way to do this is to introduce the “State” attribute to the object. The “first” rule may set the state to some value and the “second” rule can be made dependent on this value. The “second” rule can then set the state to some other value which the “third” rule will check and so on. Note that although we are using the terms “second”, “third” etc, each rule is independent of other rules as it only depends on whether the conditions that it checks are true or false (it does not care who sets the value of the state attribute and when - as long as the state has a particular value the rule will be evaluated). State attribute is often a good solution to the problem, however, any other trigger will do (for example, you can check whether an object has been added to a list) – as long as one rule sets the trigger and another rule checks it, we can express any ordered sequence as an un-ordered collection of independent rules. |
| | </accordion-item> |
| | |
| | <anchor id="make_sure_that_action_is_executed_only_once"> |
| | <accordion-item title="make sure that action is executed only once"> |
| | Most rules in //**AwareIM**// are un-ordered, i.e. //**AwareIM**// does not guarantee the order in which the rules will be evaluated. Consequently, the same rule may be submitted for evaluation several times and so its action may be executed several times as well (see the “[[2000_concepts:0800_data_processing:0100_rule_evaluation|Rule Evaluation]]” section). For actions that modify attribute values this is not a problem, provided that the last execution of the action sets the attribute to the correct value. //**AwareIM**// guarantees that this will be the case provided that rules are consistent and independent of one another. |
| | |
| | What about rules that perform a different action, for example report errors or request services? Will they be executed several times as well? The answer is no, because //**AwareIM**// assigns different priorities to rules invoking such actions to make sure that they are evaluated after the rules that modify attributes (see the “[[2000_concepts:0800_data_processing:0100_rule_evaluation:0700_evaluation_unorder_rule_collections:0500_rule_priorities|Rule Priorities]]” section ). Even so, it is probably not a very good idea to execute certain actions from rules attached to business objects without taking special precautions, as the rules will be evaluated every time the object is changed. For example, let us consider the following rule: |
| | |
| | <code aim>IF Account.State = 'Open' THEN |
| | CREATE AccountOpeningLetter WITH |
| | AccountOpeningLetter.Addressee = Account.Holder </code> |
| | |
| | |
| | The way the rule is written the letter to account holder will be created every time the Account object is changed (provided that it is in the “Open” state) – even if changes have nothing to do with the state of the account. This is not what we want. What we really want to do is to create a letter only when the account //becomes open//. Therefore we have to write our rule as follows: |
| | |
| | <code aim>IF Account.State WAS CHANGED TO 'Open' THEN |
| | CREATE AccountOpeningLetter WITH |
| | AccountOpeningLetter.Addressee = Account.Holder </code> |
| | |
| | |
| | |
| | In certain cases it may even be necessary to introduce a state or some other attribute to check whether an action has been performed, for example: |
| | |
| | <code aim>IF Policy.ExpiryDate<=CURRENT_DATE AND Policy.LetterCreated='No' THEN |
| | CREATE ExpiryLetter WITH |
| | ExpiryLetter.Addressee = Policy.Holder </code> |
| | |
| | Note that it is //not// necessary to take any precautions when sending e-mails – //**AwareIM**// will send all e-mails only after all rules have been evaluated (more precisely, e-mails just like any other notifications are sent when the current transaction is committed – see the “[[2000_concepts:0800_data_processing:0200_rules_transactions|Rules and Transactions]]” section). |
| | </accordion-item> |
| | |
| | <anchor id="perform_an_action_on_multiple_business_objects"> |
| | <accordion-item title="perform an action on multiple business objects"> |
| | [[:3000_rule_language|AwareIM Rule Language]] is the language of rules only – it does not include variables or loops as programming languages do. Consequently, it is not possible to iterate over business objects. How can then an action be performed on several business objects? The answer is that any action is automatically performed on all objects that are in the current //context//. The context usually contains objects found by a query, so the action is performed on all found objects. For example, |
| | |
| | <code aim>FIND Account WHERE Account.Balance < 100 |
| | Account.State='CLOSED' </code> |
| | |
| | |
| | The second action that changes the state of the account to ''CLOSED'' will be performed on all objects found by the ''[[ref:a_f:a:find|FIND]]'' action and so all accounts with balances less than 100 will be closed. |
| | </accordion-item> |
| | |
| | <anchor id="check_whether_rules_are_executing_correctly"> |
| | <accordion-item title="check whether rules are executing correctly"> |
| | Execution of rules can be checked using the Execution Log and Log Viewer. See the “[[2000_concepts:0800_data_processing:0300_execution_log|Execution Log]]” section. |
| | </accordion-item> |
| | |
| | </accordion> |
| | |