Getting Started‎ > ‎

Reactive Logic Tutorial

The reactive logic tutorial is a key element in the training ramp and 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.

The following image shows the rules on the Manage, Rules, By table tab:

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.

Verify Prerequisites

Ensure that you have completed the following prerequisites:

Process Overview

Use the following workflow to use business logic:

  1. Create an API.
  2. Declare your business logic.

Create an API

    1. Create your API.
      For more information about how to create an API, see Create your API Project.
      A default API is created.
    2. Shape your API by defining custom REST resources.
      For more information about how to define custom REST resources, see Define Custom REST Resources.
Your API is created. 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

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.

Declare your business logic in API Creator. The following image illustrates the complete logic for this sample on the Manage, Rules, By table tab:

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.

Note: The examples are provided in the download.

  • You are about to do a project. 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 Business Logic API Project Sample.

Validation (Place New Order) Example


Learn more here.

Validation during the Place Order (Validation) example business transaction has a number of 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 we Placed Orders which typically found in a "Shopping Cart" state (order.is_ready == false), where they do not affect Customer balance and Product quantities until a subsequent Make Order Ready transaction is executed. So, we need to 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, and also 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


Learn more here.

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.

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


Learn more here

Total sales by month and salesrep.
It is common to sub-total 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.

For more information about the database structure, see Logic Sample Database.

Bill of Materials Price Rollup Example


Learn more here.

The Bill of Materials Price Rollup example is a requirement within the Place Order example. 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


Learn more here.

The Bill of Materials Kit Explosion example is a requirement within the Place Order example. 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


Learn more here.

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:

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 access the ability to pass arguments to your rules on the URL (arg.ArgName1=1) using the req.getUserProperties().get("ArgName1"). You can pass additional 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. This can be helpful in passing values from your client system that are useful for updates or special logic processing but are not part of the data model.

Deep Copy Example

The copy operation often includes not just (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 we want to create a new Purchaseorder from an existing one, we need to 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, since they can invoke the domain-encapsulated business logic.

The following code snippet illustrates the logic method based on the Insert Into From 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 RESTlab, GET the first order, paste it to the request, and PUT with the following url argument, like this:

For more information about Deep Copy, see InsertIntoFrom System Method.

More Information

For more information: