Differences

This shows you the differences between two versions of the page.

--- docs:2000_concepts:0800_data_processing:0200_rules_transactions [2022/08/31 00:57] – ↷ Links adapted because of a move operation administrator
+++ docs:2000_concepts:0800_data_processing:0200_rules_transactions [2025/06/12 02:09] (current) – Rename to AwareIM aware_support3
@@ Line 3: / Line 3: @@
-In //**Aware IM**// data processing may occur under the following scenarios:
+In //**AwareIM**// data processing may occur under the following scenarios:
   - An external request has been issued to the system, which triggered rule evaluation (see [[docs:2000_concepts:0800_data_processing:0100_rule_evaluation|Rule Evaluation]]). This external request may have been issued either from the User Interface or from an external software system.
-  - A notification has been received by //**Aware IM**//, which triggered rule evaluation.
+  - A notification has been received by //**AwareIM**//, which triggered rule evaluation.
   - A timer event triggered scheduled processes to start executing (see [[docs:2000_concepts:0900_prod_feats:0400_scheduling|Scheduling]]).
-The following section describes how //**Aware IM**// handles database transactions when processing data under the above scenarios (transactions are described in the [[docs:2000_concepts:0500_data_storage|Data Storage]] section).
+The following section describes how //**AwareIM**// handles database transactions when processing data under the above scenarios (transactions are described in the [[docs:2000_concepts:0500_data_storage|Data Storage]] section).
 With scenarios 1 and 3 data processing occurs within a context of a single transaction. This means that if something goes wrong all changes that have been done by any of the rules between the start of the external request (or when the scheduled process started) and the error are discarded (transaction is rolled back).
-What can go wrong? First of all a transaction is rolled back if any of the rules issues the ''[[actions_functionslists:3100_actions:report_error|REPORT ERROR]]'' action. This action indicates an unrecoverable operation error so the current transaction is immediately rolled back and any prior changes are discarded((  Transaction is not rolled back if process failure rules are defined for a process that started rule evaluation in the first place – see [[docs:2000_concepts:0800_data_processing:0200_rules_transactions:0300_process_failure_rules|Process Failure Rules]]. )). A transaction is also rolled back in case of an internal error.
+What can go wrong? First of all a transaction is rolled back if any of the rules issues the ''[[a_f:a:report_error|REPORT ERROR]]'' action. This action indicates an unrecoverable operation error so the current transaction is immediately rolled back and any prior changes are discarded((  Transaction is not rolled back if process failure rules are defined for a process that started rule evaluation in the first place – see [[docs:2000_concepts:0800_data_processing:0200_rules_transactions:0300_process_failure_rules|Process Failure Rules]]. )). A transaction is also rolled back in case of an internal error.
 With scenario 2 the behaviour of the system is slightly different. The rules attached to a notification event are considered to be independent and are executed within separate database transactions, so if one rule fails anywhere it does not affect other rules attached to the notification – their changes are committed provided that these changes themselves did not cause errors.