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

Reactive Logic

What makes "Reactive Programming" so Powerful?
How does "reactive programming" streamline the work of building business logic?

Reactive programming entails the use of "smart object events." Objects are "smart due to the business logic encoded into event handlers associated with table events like "insert," "update" and "delete." "Smart objects" are used in familiar technologies such as

Building Business Logic Takes Time

Lots of it - often half the application.  But business needs to move faster.  Programming tools are useful, but these provide incremental improvements - we need order of magnitude advances.

Let’s examine the current state of the art - Smart Object Events - in light of a familiar sample.  Let’s consider a database of customer, orders, items and parts, and explore how we provide Check Credit defined like this:
  1. Customer.balance <= Customer.credit_limit
  2. Customer.balance = Sum (Order.amount_total where Order.paid = false)
  3. Order.amount_total = Sum (Item.amount)
  4. Item.amount = Item.quantity * Item.part_price
  5. Item.part_price = copy (Part.price)

The knowledge gained through this analysis is very valuable, since it applies to other transactions beyond Place Order, such as Pay Order, Delete Order, Change Order, Change Item and so on.  Re-use at the abstract level.

The current best practice is Smart Object Events

Objects are “smart” per the business logic coded into event handlers associated with table events like insert, update and delete.  This is a familiar and powerful architecture, provided in a number of different technologies such as database triggers, ORM objects, or REST objects.

While the encapsulation value is very high (all changes invoke the event handler logic), the expressive power is remarkably low.  Just the code for a single qualified sum such as the balance takes pages of code, mainly for dependency management (change detection and propagation), and sql handling (including caching).  While that may the best current alternative, we need a technology designed to address dependency management.

Smart Objects contrast to Fowler's Anemic Data Objects, which do not enforce logic.

Reactive Programming addresses Dependency Management

In reactive programming, you define the meaning of a variable (e.g., A = B + C).  Unlike procedural code, this stipulates that subsequent changes to B or C are watched - if changed, A is recomputed, which may of course chain to variables dependent on A.  

Reactive Programming is an automation of the Observer Pattern used to manage dependencies. It most successful application is the spreadsheet, where cell formulas are Reactive Expressions that provide enormous power yet are very simple. 

This technology maps naturally onto database transaction processing by assigning Reactive Expressions to database columns.  Recall our logic defining the customer balance as the sum of the unpaid order totals.  It's not a free-standing SQL statement: it defines the meaning of your data. 


You can Visualize Reactive Programming like this

When you declare the expressions, the Logic Engine's scans it for dependencies, establishing "watch and react" links from the dependent data to the referencing data.  Our customer balance depends on the Order.amount_total, Order.paid, and Order.customer_name (the foreign key).  It also depends on the state transition of the order - whether it is being inserted, updated or deleted.

And these dependencies chain, as shown here.  So our little 5 line spec essentially wires virtually every field in this database.


Reactive Programming Execution executes the "watch and react" links

When a watched field is updated (or inserted or deleted), the dependent field is re-calculated.

Reactive Re-use

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

Even more powerfully, logic constraints can chain, since one constraint can reference the value of another constraint.  So, there are dependencies between constraints. 

In our example above, the Customer.balance refers to the Purchaseorder.amount_total, itself defined by a constraint.  So, a change to the Lineitem.amount affects the Customer.balance.

Let's further explore the implications of this declarative approach to logic using Constraint and Reactive Expressions.