Docs‎ > ‎CA Live API Creator‎ > ‎Rules‎ > ‎

Reactive Logic

Reactive Programming addresses the common issue of Change Management, by providing a mechanism for watching for changes and communicating them.  There are two important classes:
  • Procedural: a variation of the Observer pattern, where register listener routines to observers, who invoke the Listeners when changes are made.  Reactive programming extends this to order Listener invocation.

  • Declarative: you provide expressions for variables, where the system watches for changes to referenced data, and reacts by re-evaluating the referencing variable. 
 

Declarative

The declarative approach is dramatically simpler and more powerful, by virtue of specialization to domains such as spreadsheets and database transaction logic.  Live API Creator employs this paradigm for derivation rules (formulas, sums, etc) and validations:
  1. You bind spreadsheet-like expressions (or, more generally, JavaScript functions) to database tables and columns

  2. On RESTful updates, (Post, Put, Delete), the system:
    • Watches for changes to referenced data,
    • Reacts to adjust referencing data,
    • which may Chain to other rules per this video.

  3. Chaining includes references in other tables - SQL and transaction bracketing are automated
Reactive logic works in conjunction with server side JavaScript events.  This provides complete flexibility, including access to extensible JavaScript libraries.

Reactive Logic has key differences to conventional procedural code:
 
 Key Difference  What it means    Why it matters
 Automatic Invocation  The engine (not your code) calls the logic, e.g., changing a LineItem Quantity adjusts the Amount, without the need to explicitly invoke such logic  eliminates errors where certain paths might fail to invoke required logic
 Automatic Chaining  Changes trigger other changes, e.g., changing a Line Item Quantity adjusts the Amount, and that chains to adjust the Order total.  simplifies maintenance, since ordering is dictated by dependencies - recomputed on each change
 Automated SQL  Watch/React includes multi-table logic (in the example above, you do not need to issue the SQL to retrieve the order)  SQL is a chore to code, and to optimize (pruning, caching)



How Watches are established

When you declare Reactive Logic rules, the system processes it to determine its references, and establish watches on the referenced attributes.  Recall there are two ways you specify logic:
  1. By filling out a form - you use this for parent copies, sum, count, min, max

  2. By providing JavaScript - for formulas and validations, you provide an expression, or more generally a function

This determines how references are detected:

 Rule Type  Watch
 parent copies This takes effect when a child is first associated to a parent, either on on insert, or a change to the Foreign Key.

Note: changes to the copied attribute are not watched; to propagate these values, make parent.attribute references in formulas or validations
 aggregates: sum, count, min, max Watches are established on:
  • Foreign Key: These are all based on relationships, so all the elements of the Foreign Key are watched.

  • Sum / Min / Max attribute - the value being summed, min'd etc

  • Qualification Condition - the child condition that identifies which child rows are included in the aggregation

For example:
 
balance = sum(orders.amountTotal where paid = false)

places watches on order attributes customerId (the foreign key), amountTotal, and paid


 formula, validations Your code is scanned, and a watch is established for every row.attribute reference.  For example:
 
amount = row.price * row.quantity

places watches on the price and quantity


How React operates

That is a significant statement.  In the case of our customer.balance rule, this means that this one statement obligates the system respond to all of the following:

  • Order inserted - balance increased
  • Order deleted - balance decreased (if not paid)
  • Order paid - balance decreased
  • Order unpaid - balance decreased
  • Order amountTotal changed - balance adjusted
  • Order reassigned to different customer - balance increased for new customer, decreased for old


How Chain operates

Recall that logic can chain, since one rule can reference the value of another rule.  So, there are dependencies between rules.  In our example above, the Customer.balance refers to the Purchaseorder.amount_total, itself defined by a rule.  So, a change to the Lineitem.amount affects the Customer.balance.

Chaining is implemented as described below.


 Rule Type  React
 parent copies There is no chaining for parent copies.

For child parent.attribute references, the system visits each child and evaluates the rules that are dependent on the parent attribute.
 aggregates: sum, count, min, max The system issues a 1-row update to the parent object, which already be in cache.  Select sum queries are expensive, so are not employed.


 formula, validations The JavaScript code is executed.



Contrast to Traditional

Without such declarative automation, your procedural code must perform all of this watch/react dependency management, ordering, change detection, and optimization - over all the Use Cases.  This is how 5 rules can represent hundreds of lines of code.


Complexity Handling

Declarative Logic is extensible, in particular with server-side JavaScript Logic Events that can utilize loadable libraries.  This enables you to solve very complex problems with remarkably little effort.


Managing Rules

Reactive Logic is not implemented by code generation.  It does not require compilation or deployment - Logic is active as soon as you save and activate.

Rules are maintained in the Repository.  They can be managed via a RESTful API, or by Project Export.

You can categorize rules into Topics, and filter them by topic.