You can address complex examples using API Creator:
Rules offer the promise of accelerating backend delivery by an order of magnitude. That is a big promise. But rules are a new paradigm, so there are sensible questions:
- Complexity.How do rules address complex problems?
- Performance.Nothing matters if the system is slow.
- Debugging.Are rules a black box or can I address problems easily?
- Learning.Is the paradigm reasonable to learn?
This article addresses these questions.
In this article:
Verify the Prerequisites
Before you learn the rules, ensure that you have reviewed one of the following:
- You understand how rules operate.For more information about a description of how rules operate, see Reactive Logic Operation.
- You have watched the Rule Operation video.
The Promise of Rules
The Check Credit example is a representative transaction, where a insert/update/delete affects multiple related objects.
- Correctness.Building correct code presents its challenges. Reactive programming addresses several of the inherent challenges of quality by automating control flow:
- Automatic Invocation.After you declare a rule, API Creator executes the rule for any use case. In this way, API Creator eliminates an entire class of corner-case bugs (the Customer Balance was not adjusted when the Order was re-assigned to a different account)
- Ordering.Execution is ordered by system-discovered dependencies.
- Maintainability.The same elements that promote correctness make reactive logic easier to maintain. Add/change rules and they execute in the proper order.
- Clarity.Removing the boilerplate Change Detection/Propagation and SQL reveals the intent of the logic. Moreover, the logic is revealed in terms clear to business users. The result: Business users and IT speaking the same language. Logic can reduce the risk of requirement misunderstandings.
Address Complex Examples
You can address complex examples using API Creator:
- Provide logic not addressed by rules using events.You can provide logic that is not addressed by rules using the integrated event model. For example:if ("INSERT" != logicContext.initialVerb && row.amount_total != oldRow.amount_total) SysLogic.insertChildFrom("purchaseorder_audit", logicContext);For more information about the event model and how to create an event, see Logic Event Rule Types.
- Rules reduce complexity.Ordering, dependency management, and automatic invocation inherently reduce complexity. A few simple rules can solve complex problems, in the same way that a few spreadsheet formulas can solve highly complex numerical problems.
For more information about viewing a series of use cases addressed with a few rules, see the Reactive Logic Tutorial.
The API Server automates best practices for performance:
- Pruning.Rules, and associated SQL, are not executed if a specific transaction does not alter their dependent data. For example, changing an Orders'DueDatehas no effect on the Customer'sBalance.
- SQL optimizations.Parent adjustments for aggregates are single row updates. This optimization is significant when aggregates nest, that is, they are based on other aggregates.
- Caching.API Server buffers reads and write in a transaction cache. For example, inserting an Order with fiveOrderDetailsresults in an order and a customer adjustment.
For more information about performance, see Performance.
Rule and SQL Activity
For more information about the log, see Debug.
Revert and Use Previous Versions of Rules
API Creator creates a version of a rule each time you make changes to it and save it. You can revert to and use an older version of a rule.
- With the rule open, click the versions link in the upper right, and then select the datetime stamp for the version to which you want to revert.The following image shows an example of the versions link:
The rule is reverted to a previous version.
Address problems with rules using the following approach. Learning rules is easy, but learning them is different.
Differences between Reactive Programming and Conventional Procedural Programming
The following are some observations about some fundamental characteristics that distinguish reactive programming from conventional procedural (Imperative) programming:
- No control flow
- CA Live API Creatorinvokes rules per changes in referenced attributes.In conventional procedural programming, you must explicitly invoke object methods for them to execute. In reactive programming, the rules are similar to event handlers or triggers, but are more granular. They react to a change in the referenced attributes.
- CA Live API Creatororders rules by their dependencies.In conventional procedural programming, logic within a method or event handler is ordered. In reactive programming,CA Live API Creatororders rules by their dependencies. When you alter the rules, for example, during maintenance or during iterative development,CA Live API Creatoradjusts the logic flow automatically per the new dependencies.
- Elimination of Boiler Plate codeIn conventional procedural programming, the bulk of your code is change detection, change propagation, and persistence handling (SQL commands). In reactive programming,CA Live API Creatorautomates change detection, change propagation, and persistence handling. The previous logic is executable.
A Simple Validation Example
The following code snippet shows a simple example:
Customer Validation: return row.CreditLimit >= row.Balance
Orders Validation: return row.AmountTotal < row.Customer.MaxAmount
For more information about validation rules, see Validation Rule Type.
A simple SUM Example
Ok, but the balance is derived. How does
CA Live API Creatordeal with that? We add another rule, a Sum rule type:
Customer Validation: return row.CreditLimit >= row.BalanceDerive Customer.Balance asSum(OrdersList.AmountTotal where ShippedDate === null)
The rule operands, again, are based on the schema;
OrdersListis a defaulted name, which is derived from to a foreign key relationship. These rules are fully executable. After you have created them, you do not need to worry with the details of calling them, ordering them, reading/writing data. API Creator addresses these rules with system RESTful update processing.
For more information:
Rules Automate Logic Patterns
The Simple Sum example illustrates a key to using rules: they work in combination to achieve a desired behavior.
Validate a Sum
This simple "Balance < CreditLimit" example illustrates one of the most common logic patterns: validating a rollup/constrain derived result. Other examples of the pattern:
- Rollup employee salaries to department, constrain to budget.
- Rollup departments, constrain to budget.
- Rollup Student Course Credit, constrain to max for student, max for course.
- Compute Product Price from the sum of the Component Parts (nested).
- Compute Event GiftsAmount from sum of EventGifts.
Existence Checks: validations on [qualified] counts
For example, order must have items and department must have employees.
Scale to Complexity
- Copy.Invoke copy, including deep copy, for patterns like auditing or cloning. The copy pattern automates a Bill of Materials explosion.
- Allocation.Allocate an amount to a set of recipient, such as a bonus to department employees or a payment to outstanding orders.