Docs‎ > ‎Logic Designer‎ > ‎Live Logic‎ > ‎

Rule Operation

Rule Operation

Update business logic is a large part of most database applications.  Like many other systems, Espresso enables you to provide logic in familiar update events, here in server-side JavaScript.

What makes Espresso unique is Reactive Programming: declarative, spreadsheet-like rules.  These enable you to deliver update business logic 10X faster.

While rules hold enormous promise, they operate differently than conventional programming.  Shown conceptually in this video, this page shows how they work.

For more information, see

First, we declare spreadsheet-like expressions

for database columns, to formalize our Check Credit solution.  The rules look very much like the infamous cocktail napkin spec, to collaborate with Business Users:

  • A Validation, to ensure the CreditLimit is greater than the Balance, where

  • The Balance is the sum of the unShipped OrderTotals

  • Which is the Sum of the OrderDetail Amounts

  • Which is the UnitPrice * Quantity

  • Where the UnitPrice is copied from the Product

We enter these rules directly into Espresso.  

The system parses them to determine the rule dependencies,  shown by the arrows.  You can think of these as declarative triggers, ready to Detect and Propagate Changes to dependent data.

And that’s it.  Our 5 simple rules are completely executable - no invocation logic, no persistence code.

Let’s see how rules process an Update Request

Though we might have defined the rules for Place Order, they automatically address other transactions as well.  Let’s see how they react to changing a Line Item quantity.

  1. First, the system marshalls the RESTful JSON data into row objects that encapsulate the logic.  These are created automatically, when you connect and create your Project.

  2. The system performs optimistic locking checks, and obtains the oldRow, so your logic has access to all the required data.

  3. The quantity change triggers a change to dependent data - the amount.  As a developer, this requires no explicit call - rules execute automatically when their referenced data changes.

  4. The amount triggers an adjustment to the amountTotal.  As a developer, you not be concerned about the sql, or performance matters like caching.  Multi-table chaining is fully automatic.

  5. The Order change raises our update event.  A few lines of JavaScript create a JSON document, and Post it to an external system.  So, our logic is mostly rules, with JavaScript as required.

  6. The amountTotal triggers an adjustment to the balance.  Adjustments are optimized to 1 row updates, not expensive aggregate select sum queries.

  7. The balance triggers re-evaluation of our check-credit constraint.  If it fails, the entire transaction is rolled back.

  8. Since there are no more rows to process, the transaction is committed.

JavaScript when you need it

As noted above, the Object Model provides for Row Events which you can handle in JavaScript.  Here is an example from the Add Payment example:


Rule operation is transparent... not a black box.  You can examine the log to determine all the rules and sql that fire.  Chaining is shown by nesting.  You can see the full row at each execution stage.

Value: Business Agility

Our 5 simple rules were completely executable - no invocation logic, no persistence code. Our rules, perhaps conceived for Place Order, actually address these other 12 transactions, completely.  All the Change Detection, Change Propagation and SQL is automated.  

Rules are bound to the data, not a specific Use Case, so they apply to all in-coming transactions. In other words, the logic above automatically processes all of these transactions:
  1. Order inserted - balance increased
  2. Order deleted - balance decreased (if not paid)
  3. Order unshipped - balance decreased
  4. Order shipped - balance decreased
  5. Order amountTotal changed - balance adjusted
  6. Order reassigned to different customer - balance increased for new customer, decreased for old
  7. OrderDetail inserted - obtain price, adjust Order and Customer (and check credit)
  8. OrderDetail Deleted - reduce Order and Customer totals
  9. OrderDetail Quantity increased - adjust Order and Customer (and check credit)
  10. OrderDetail Product Changed - obtain price, adjust Order and Customer (and check credit)
  11. OrderDetail Quantity and Product Changed - obtain price, adjust Order and Customer (and check credit)
  12. Customer CreditLimit changed - check credit
This results in a meaningful improvement in quality.  Reactive Programming eliminates of an entire class of programming error (e.g., balance checked when adding an order, but overlooked on unshipping an order).

If you used conventional event-based programming, these 5 lines would have required hundreds of lines of code.  That’s over an order of magnitude improvement, for a significant part of your system.

Maintenance is addressed too - when you change the rules, ordering and optimizations is handled automatically.  And since invocation is automatic, all your existing transactions will automatically use and adapt to the new logic.