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.
lac311
The reactive logic tutorial is a key element in the API Creator training ramp. The tutorial is based on simple to complex case studies. Using a case-study approach of a familiar but complex database, this tutorial explains the approach for using API Creator. The tutorial progresses from simple (and typical) examples to complex examples. It illustrates the key design patterns for reactive logic.
 Skim the advanced examples to scan the logic. The logic is complex, 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 custom REST resources. 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 on the Rules, By table page. The following image illustrates the complete logic for this sample on the Manage, Rules, By table tab for the Sample API:
CA Technologies
For more information about the Sample API, see Sample Database.
The following image shows the rules on the Rules, By table tab 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.
 
The examples are provided in the
CA Live API Creator
download.
 
  • 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 Logic 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
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.