Transaction Business Logic

Why is Transaction Business Logic important?

Transaction Business Logic is the processing required in processing database transactions to enforce business policies. It is sometimes characterized as Enforcement logic, since the transaction should be rejected if the rules are not passed. Consider the insertion of a new Purchase Order:

1. Constraints: the system must verify that the Customers' Balance is within the Credit Limit; failures result in transaction rollback.

2. Derivations: the system must compute the Balance by rolling up the Order Total; this is derived by rolling up the Line Item Amounts, computed from the Product's Price times Quantity Ordered. This illustrates the notion of chained derivations, where one derivation is based on the result of another, often across tables.

3. Actions: the system might take various actions, such as sending email if the balance is close to the Credit Limit, starting a Business Process for order approval, or auditing.

Such Transaction Business Logic complements other forms of Business Logic, such as:

• Presentation Business Logic to retrieve data for display and manage page transitions

• Process Business Logic for workflows, or

• Decision Business Logic for Decisioning.

The sub-sections below explain why Transaction Business Logic is important.

Business Critical: Bad Data leads to Bad Decisions

The well-known adage "Garbage in, garbage out" well describes the need for Transaction Logic. Considerable time is invested in OLAP (Online Analytics Processing) and Decisioning, both of which rely on valid incoming data. In our simple example, it is clearly unwise to accept Orders that customers cannot afford, or for which the Products are discontinued.

50% of app - Compromises Business Agility

Transaction Business Logic is not a small problem. Even a small problem as described above can require 500 lines of code, representing several weeks of effort. And it is not trivially easy to design for re-use, so that our insertion logic works for changing Purchase Orders, and for Purchase Orders received from Message Processing.

Rete Engines well-accepted for Decisioning

So, Transaction Logic is a large and important systems element - an ideal candidate for automation. Rete Engines are a well-accepted technology, delivering significant business value as described below.

Business User Access

Separating business logic to make it accessible to Business Users, so they can address many of their needs for Decisioning.

Declarative: automated dependencies / ordering

Rete Business Rules are declarative: you simply state the rule expressions, and the Rete engine manages the dependencies / ordering.

Transaction Business Logic Requirements

To analyze the suitability of Rete engines for Transaction Logic, let's identify the requirements for the enforcement of Transaction Business Logic:

Logic for (ordered, multi-table) Derivations, Constraints, Actions

The example above illustrates the need for the categories of logic noted in the title. Derivations are particularly complicated:

• Dependencies

  Derivations introduce dependencies where 1 derivation can depend on another. Such dependence requires that logic be ordered properly (obviously, we should compute the Customer balance after the Order total is calculated). Dependency Management is complex, since such interactions are an N2 problem.

• Multi-table performance

  The "rollup" of Item Amounts to Purchase Orders and Customers is a very common pattern. Since these derivations span tables, the manner in which they are performed can have profound consequences on performance. For example, reasonable alternatives might be:

  • Aggregate Queries: issue SQL Select Sum() queries to compute the data. But this is not so simple when the derivation results nest multiple levels, and when the underlying data is itself derived. And it can be slow if there are a large number of related rows.

  • Bring Data into Memory: we might exploit caching to bring data into memory

  • Adjustment Logic: we might dramatically reduce database overhead by adjusting a stored total by the change, thus avoiding the aggregate queries

These are not simple design issues. They incur normalization concerns, and the design parameters might not be clear until the system is fully implemented -- at which point it can be very difficult to change.

Enforcement critical: For all changes

The Business need for reliable enforcement is obvious: all changes must be subjected to our organizations rules. The term "Compliance Certification" underscores that this is both important, and not automatic

In technical terms, this is not trivial. There are many factors, but the following are commonly encountered issues:

• Re-use over transaction source:

  Poor design might bind logic to screen functions, requiring replication for message processing.

• Re-use over Use Case

  Experience shows that it might be easy to build insert and delete logic, but the myriad of update changes that might occur can make achieving re-use difficult.

• Dependence Complexities, particularly during Maintenance

  Programming errors become more and more common as the dependencies grow, so maintenance becomes slow and error-prone.

Transition Logic: old value reference

Transition Logic is a very frequent requirement, where the logic depends on comparing the prior database values to the current ones. This can be important in a number of dimensions:

• Logic

  Many business rules explicitly refer to old values: "salary changes must lie within a given range", "invoke verification processes if balance changes exceed a threshold".

• Performance

  Efficiently designed algorithms can exploit old values to prune database access. For example, if I alter a Purchase Orders' date, there is no need to issue SQLs to verify the customer's balance.

Aggregates

As noted above, an extremely common requirement is rollups, where logic requires the derivation of a sum or count of related data. We also noted that such logic is extremely performance sensitive, for example when the volumes are large, or when the aggregates have chained inter-dependencies.

Declarative: what (not when/how)

We conclude with our most important requirement. Our key objective must be to achieve substantial automation, where the procedural code can be dramatically simplified and reduced.

Such needs are not met by improved General Purpose Languages - they require declarative approaches that simplify with automated dependency management, and reduce code volume by 90% by replacing procedural logic that is 90% "when / how" algorithms with declarative rules.

This may sound aggressive, but we have seen such advances before. SQL represents a dramatic simplification for database access. Even more relevant are spreadsheets, where cell formulas can express complex logic formerly addressed by custom programming.

Gap Analysis: Rete and Transaction Business Logic

Rete engines are an existing, mature technology. While it fills many of the requirements, it also leaves significant gaps:

This diagram illustrates that all three shortcomingsarise from the same underlying root cause: lack of Persistence integration. You invoke a Rete engine by supplying:

• Rule Set name

  You define Rete rules in named groups called RuleSets, which you supply when you invoke the Rete engine.

• Bean Array

  You also supply a list of objects. While these can be persisted by Hibernate, the Rete engine does not know that. It simply returns the (possibly altered) POJOs; it is your applications' responsibility to persist these objects.

The lack of persistence integration can be a strength for Decisioning applications - you may simply want to ask "what if" questions without any possibility of persistence. But this is a fundamental weakness in the context of enforcing Transaction Business Logic, as described in the sub-sections below.

No Automatic Enforcement - explicit calls are required

Effective enforcement is not elective: it must be applied to all updates, regardless of their source. It should not be an applications choice to invoke the Rete logic, since it might forget, specify the wrong Rule Set, etc.

No Transition Logic

Persistence engines (such as JPA, Hibernate, TopLink, etc) typically provide access to the old values of the submitted rows. Your business logic can use this, as noted above, for logic and/or for pruning.

Poor Aggregate Processing - reloaded, in all cases

It is a well-known issue that aggregate processing is inefficient in Rete engines. The root cause lies in the very model of Rete rule definition, and the data submittal assumptions.

Rete compute values, but the engine is unaware whether the value is the unconditional meaning of the attribute. As such, it cannot analyze changes to the value (eg, new Line Items for an Order), and determine adjustments to the aggregate. Instead, the Rete engine must materialize the aggregate, every time it is referenced... even if the underlying dependent data is not altered. This algorithm is thus un-tuned, and not prune able.

Introducing the need for Transaction Business Logic

The issues above are addressed with the architecture shown here that integrates business logic into the persistence mechanism:

• Business Logic is declarative, with support for ordered, multi-table derivations, constraints, and actions

• Business Logic has access to old and new values

• Updates are automatically subjected to Business Logic

There are a number of reasonable implementations of such an architecture, including:

• Database Triggers

• Object / Relational Managers (ORM), such as JPA/Hibernate

• DAO Objects

In any case, such an architecture addresses the requirements not met by Rete Engines:

• For All Changes – automatic enforcement

  Automatic enforcement is achieved through integration with the Persistence API - there is no way for applications to write transactions without business logic execution.

• Transition Logic - inherent support for old values

  The invocation of the business logic provides old and new values to the logic enforcement

• Optimized aggregates - adjustment (per old values)

  Old values enable the logic to prune SQLs when dependent data is not changes, and to perform adjustment processing to avoid aggregate queries

Ideal implementations will extend basic Declarative provisions for derivations, constraints and actions with supplied action handlers that automate common patterns such as auditing, as well as complex functions like bill of materials processing, and the allocation of goods (e.g., payments) to recipients (e.g, unpaid Purchase Orders).

Author: Val Huber, President of Automated Business Logic LLC

Mr Huber has pioneered the automation of application development over many years.

In the 1980s, he was the driving force behind Wang's highly regarded PACE (Professional Application Development Environment). Pace provided a relational DBMS, with a full automated tool suite for reports and interactive applications. Applications were specified with a simple menu-driven selection that resulted in sophisticated multi-screen systems. Business Logic was specified declaratively, in one of the first Business Rule systems. Mr. Huber was awarded several patents for the unique innovations behind Pace.

After a stint as an Architect in Sybase, Mr. Huber become the driving technical force in Versata. There, he led the development of a Java-based Business Rule Management System. This system enabled sophisticated rich or thin applications to be developed from a site-map drawing, with Business Rule Automation for Transaction, Process and Decision Logic. BRMS systems supported tens of thousands of concurrent users, executing within Application Servers and industry standard databases.