Reactive Logic Tutorial

The most common patterns we see in logic design are shown in the illustration. The following sections describe the more complicated cases we have seen through extensive experience.
lac40
The reactive logic tutorial is a key element in the 
CA Live API Creator
 training ramp. Using a case-study approach of a familiar but complex database, this tutorial explains the approach for using 
CA Live API Creator
. It progresses from simple (and typical) examples to complex examples. It illustrates the key design patterns for reactive logic.
The advanced examples include complex logic, but a quick scan gives you a good sense of how reactive logic addresses complex problems.
In this article:
 
 
2
 
 
Use Business Logic
Business logic is:
  • Automatically invoked.
     Your logic is bound to database tables and columns. API Server automatically invokes it on all update operations.
  • Automatically ordered.
     The listing is organized by table. You can enter the logic in any order. API Creator orders the execution based on dependencies and revises the order as you alter the rules.
  • Filterable.
     See the logic for that topic by selecting a topic link (colored rectangle to the right of the rule).
    For more information about topics, including filtering rules by topic, see Manage Topics.
For more information about business logic and reactive logic, see Logic.
Use the following workflow to use business logic:
Verify the Prerequisites
Ensure that you have completed the following prerequisites:
Create an API
Create your API and shape it by defining resources in API Creator. Your application development team can now get started with the running API.
For more information about team development, see Team Development.
Declare your Business Logic
Declare your business logic in API Creator. For more information about the rules you can create, see Rule Types.
The following image shows the rules for 
Sample
 API:
  CA Technologies  
This tutorial uses the Sample database. The Sample database is included with the Sample API.
For more information about the Sample database, see Sample Database.
For more information about the Sample database that is used in the 
Sample
 API, see Sample Database.
The following image shows the rules for the 
Demo
 API:
  CA Technologies  
Basic Examples
The following examples are "typically" complex and are a great place to start learning about business logic. How you review these examples might depend on your objectives:
  • You are evaluating. You want to see some code and understand solutions to a range of use cases.
Review the problems/solutions.
For more information about the samples that 
CA Live API Creator
 includes, see API Samples.
  • You are about to create an API. You need to see how to solve problems and document your work.
    Open a window (or have a sheet of paper) for the data model and for the rules. Then try to solve each problem and compare your solution to the sample.
For more information:
Many basic examples are built upon the Demo database. The following examples are built upon the Sample database (similar but larger).
For more information about the Demo database, see Demo API Sample.
Place Order (Validation) Example
Validation during the Place Order (Validation) example business transaction has some different requirements that illustrate the most common business logic patterns. The validation takes place on a parent table ("sample:customers") but the triggering events are changes in the orders and line items (adding new items, changing quantities, paying an order).
For more information about this example, see Place Order (Validation) Example.
Make Order Ready Example
The Make Order Ready example describes how you place orders typically found in a "Shopping Cart" state (
order.is_ready == false
). The orders do not affect customer balance and product quantities until a subsequent Make Order Ready transaction is executed. So, you must devise logic when an order is "made ready".
For more information about this example, see Make Order Ready Example.
Advanced Examples
The most common patterns we see in logic design are shown in the illustration. The following sections describe the more complicated cases we have seen through extensive experience.
The logic to address complex problems is small. It is also dense. The following examples illustrate the power of logic to address complexity. The examples also illustrate that the real job centers on the design and approach instead of low-level coding. Exactly where it should be.
Explore Allocation (Add Payment - allocate to orders) Example
The Explore Allocation example is a powerful illustration of business logic. This is a classic example of providing an allocation reusable service by way of business logic extensibility. In this example, we add a payment to a customer and its amount is allocated to that customers' outstanding unpaid orders.
For more information about this example, see Explore Allocation Example.
Extensible Libraries Example
The Extensible Libraries example processes and allocates payments by including custom Java and JavaScript code.
For more information about this example, see Extensible Libraries Example.
Group By Rollup Example
Total sales by month and 
salesrep
 . It is common to subtotal object by grouping them. For example, we might to group orders by year, month and 
salesrep
 , to monitor sales activity. These totals are maintained in the table 
empsales
 . Consider when a product price is changed, and that product is a component of a kit. The requirement must be that each of the kits reflect the price change (for example, if a bolt increases in price, so do all the kits that use bolts: wings, fuselages, etc).
For more information about this example, see Group by Rollup Example.
Budget Rollup
You can roll a budget up an org chart as shown in the Budget Rollup Example.
 For more information about the database structure, see Sample Database.
Bill of Materials Price Rollup Example
The Bill of Materials Price Rollup example is a requirement within Place Order. When a component price is changed, logic is required to update the price of all the containing kits, recursively.
For more information about this example, see Bill Of Materials Price Rollup.
Bill of Materials Kit Explosion Example
The Bill of Materials Kit Explosion example is a requirement within Place Order. When ordering a product that is a kit (for example, composed of other Parts, such as a plane with wings, etc.), we want to reduce inventory for each of the components of the kit.
For more information about this example, see Bill of Materials Kit Explosion Example.
Audit Transaction (Salary Change) Example
This example creates an audit by creating child rows on designated parent changes, with control over which attributes are copied into the audit trial. One rule: Auditing is the simplest example of a family of Insert Into From rule extension.
 For more information:
Give Raise Example
In addition to using create, read, update, delete (CRUD) operations to alter data, you can make your API more explicit.
For more information about viewing an example of how to use the Give Raise example, see Give Raise Example
Transaction Parameters (Give Raise) Example
Most updates are updates (POSTS, PUTS, or DELETES) to rows, processed per logic as shown in the previous example. Sometimes, however, transactions require arguments. Alternatively, consider the command pattern.
For more information:
Ignore Extra Attributes in a POST
You can pass arguments to your rules on the URL (
arg.ArgName1=1
 argument) using the 
req.getUserProperties().get("ArgName1")
 method. You can pass more attributes in your JSON during a POST or PUT that are not part of the database structure using the 
main:customer?arg.IgnoreExtraAttributes=1
 argument. Passing arguments can be helpful in passing values from your client system that are useful for updates or special logic processing but that are not part of the data model.
Deep Copy Example
This tutorial is a complex example that illustrates a recursive deep copy, using reactive logic. The copy operation often includes not only (scalar) attributes, but also related data. Copy services are provided for cloning business objects, including provisions for copying related child data such as the 
Lineitems
 for a 
Purchaseorder
 . These are typically called using a single action rule, so cloning a 
Purchaseorder
 is one rule. For example, if your want to create a new 
Purchaseorder
 from an existing one, you must clone both the 
Purchaseorder
 and the 
Lineitems
 .
Business logic is initiated only when performing transactions (inserts, updates, and deletes) to the database. You can trigger this logic from either the source (copied) object, or from the target (inserted) object. You can also build services which expose the functionality more explicitly. Unlike manually coded services, such services can be thin because they can invoke business logic.
The following code snippet illustrates the logic method based on the 
InsertIntoFrom
 rule extension:
var arg = req.getUserProperties().get("clone"); log.debug("cloneXX: checking request arg.clone parameter was provided: " + arg); if (arg !== null && logicContext.logicNestLevel < 1) { log.debug("cloning: " + row); var deepCopy = ["lineitemsList"]; SysLogic.copyTo("orders", logicContext, deepCopy, false); }
To activate the copy function in the REST Lab, GET the first order, paste it to the request, and PUT with the following url argument. For example:
http://server.acme.com/rest/abl/sample/v1/sample:orders/1?arg.clone=true
For more information about the Deep Copy example, see InsertIntoFrom System Method.