Reactive Logic Operation

Reactive Logic Operation
lac42
Update-business logic is a large part of most database applications. You specify your business logic in familiar update events, in this case, by providing server-side JavaScript. The following page describes how rules operate.
In this article:
 
 
2
 
 
Verify the Prerequisites
Before beginning to specify your business logic, watch the following Reactive Logic video. This video describes reactive logic's concepts and operation for definition and execution (watch, react, and chain):

Declare Spreadsheet-like Expressions
To formalize the Check Credit solution, you declare spreadsheet-like expressions for database columns by entering these rules into API Creator. The rules look like the infamous cocktail napkin specification, 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
API Creator parses the rules to determine the rule dependencies, shown in the following image by the arrows:
  CA Technologies  
Think of the rule dependencies as declarative triggers, ready to detect and propagate changes to dependent data.
How Rules Process an Update Request
Though we might have defined the rules for Place Order, they automatically address other transactions as well. The rules react to changing a line item quantity in the following ways:
  1. API Creator marshalls the RESTful JSON data into row objects that encapsulate the logic.API Creator creates the row objects automatically when you connect and create your API.
  2. API Creator 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 the 
    Amount
     , which is dependent data.API Creator executes the rules automatically when their referenced data changes. You do not need to make an explicit call. 
  4. The change to the 
    Amount
     triggers an adjustment to the 
    A
     
    mountTotal
     . Rules automates multi-table chaining. You need do not need to be concerned about the SQL or performance matters like caching.
  5. The order change raises an update event. A few lines of JavaScript create a JSON document and Post it to an external system. The logic is mostly rules with JavaScript as required.
  6. The adjustment to the 
    A
     
    mountTotal
     triggers an adjustment to the 
    Balance
     .API Creator optimizes the adjustments to one-row updates, not expensive aggregate select sum queries.
  7. The adjustment to the 
    Balance
     triggers re-evaluation of the check-credit constraint.If the evaluation fails, API Creator rolls back the transaction. Since there are no more rows for API Creator to process, it commits the transaction.
Adjustments are one-row "delta" updates, which require that stored values match the rule definitions. Ensure that your existing data is consistent with the rules, such as with SQL commands.
 For more information about performance, see Performance.
Row Events Handled with JavaScript
The object model provides for row events which you can handle in JavaScript. The following image is an example from the Add Payment example:
  Screen Shot 2017-10-16 at 11.10.19 AM.png  
For more information about the Explore Allocation example, see Allocation Example.
Transparency
Rule operation is transparent. You can examine the log to determine the rules and SQL that fire. API Creator shows chaining by nesting. You can see the full row at each execution stage. The following image shows an example of the Logs page for the Demo API:
  image2017-10-16 11:16:11.png  
Value: Business Agility
The rules are completely executable; no invocation logic, no persistence code. The rules, perhaps conceived for Place Order, also address the following transactions:
  • Order inserted - balance increased
  • Order deleted - balance decreased (if not paid)
  • Order unshipped - balance decreased
  • Order shipped - balance decreased
  • Order amountTotal changed - balance adjusted
  • Order reassigned to different customer - balance increased for new customer, decreased for old
  • OrderDetail inserted - obtain price, adjust Order and Customer (and check credit)
  • OrderDetail deleted - reduce Order and Customer totals
  • OrderDetail quantity increased - adjust Order and Customer (and check credit)
  • OrderDetail product changed - obtain price, adjust Order and Customer (and check credit)
  • OrderDetail quantity and product changed - obtain price, adjust Order and Customer (and check credit)
  • Customer CreditLimit changed - check credit
The change detection, change propagation, and SQL is automated. The rules are bound to the data, not a specific use case, so they apply to all in-coming transactions. In other words, the logic automatically processes the following transactions. This results in a meaningful improvement in quality. Reactive programming eliminates an entire class of programming error (for example, balance checked when adding an order, but overlooked on unshipping an order).
The following image illustrates the transactions the rules address:
  Screen Shot 2014-10-13 at 12.31.27 PM - Oct 13, 2014.png  
If you used conventional event-based programming, these five lines would have required hundreds of lines of code. That is over an order of magnitude improvement, for a significant part of your system.
Layer7 Live API Creator
 also addresses maintenance. When you change the rules, 
Layer7 Live API Creator
 handles the ordering and optimizations automatically. Since invocation is automatic, all your existing transactions automatically use and adapt to the new logic.