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.
lac42
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
CA Live API Creator
 bounds your logic to database tables and columns. It automatically invokes your logic on all update operations. 
CA Live API Creator
 organizes the listing of the rules by table. You can enter the logic in any order. 
CA Live API Creator
 automatically invokes and orders your business logic. 
CA Live API Creator
 orders the execution based on dependencies and revises the order as you alter the rules. You can see the rules for that topic by selecting a topic link (the colored rectangle to the right of the rule in API Creator).
For more information:
  • About topics, including how to filter rules by topic, see Manage Topics.
  • 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 your API and Define Resources
Create your API and shape it by defining resources in API Creator. Your API is running. The application development team can now get started.
For more information:
Declare your Business Logic
Declare your business logic by creating rules in API Creator.
For more information about the rules you can create, see Rule Types.
The following image shows the rules for the 
Sample
 API:
 Screen Shot 2015-10-23 at 10.49.11 AM.png 
The Logic tutorial uses the Sample database. The Sample database is included with the 
Sample
 API.
For more information about this database, 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 can depend on your objectives:
  • You are evaluating 
    CA Live API Creator
    . 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 Tutorials and 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 about the data model, see Sample Database.
Many basic examples are built upon the 
Demo
 API sample. The following examples are built upon the 
Sample
 API sample, which is similar but larger than the 
Demo
 API sample.
For more information about the 
Demo
 API sample, 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 is a classic example that illustrates providing an allocation reusable service by way of business logic extensibility. In this example, add a payment to a customer and its amount is allocated to that customers' outstanding unpaid orders.
For more information about this example, see 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 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 Employee 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: