From grayeagle

Spreadsheet Business Logic is the fastest, easiest way to build, run and publish Business Logic for Hibernate systems.

Unlike procedural development, this declarative approach utilizes business-level abstractions (analogous to a spreadsheet) to provide:

1. Business agility to build and adapt systems, with transparency to understand what they are doing -- the example below illustrates replacing 10 pages of code with 7 business-oriented rules
2. IT power to handle complex problems such as a Bill of Materials explosion, with an architecture that integrates into your existing system with high performance, and automatic re-use

Contents 1 What is Business Logic? 2 Why do I need Business Logic? 3 How does Spreadsheet Business Logic work? 3.1 Analysis naturally captures the Business Logic 3.1.1 Transparency 3.2 Design Automated by Chained Formulas - like a Spreadsheet 3.2.1 Formula-based 3.2.2 Forward Chaining: automatic multi-table dependency management 3.2.2.1 Formula Ordering 3.2.2.2 Child Aggregate Adjustment 3.2.2.3 Parent Reference Cascade 3.3 Development: Declare Business Logic 3.3.1 Agility - automated Complexity Management 3.3.2 Power through Open Declarative Business Logic 3.3.3 Automatic Invocation guarantees integrity 3.3.4 Automatic Partitioning promotes re-use and performance 3.4 Architected to handle complexity 3.5 Execution architected for high performance 3.6 Maintenance Automation 3.6.1 Automatic Re-use over transaction type and source 3.6.2 Automatic Re-ordering 3.6.3 Automatic Re-optimization 4 Who uses Business Logic? 5 Next Steps 6 Documentation Map 6.1 Readme First 6.2 Main Concepts 6.3 Operations

What is Business Logic?

Business Logic is the processing you execute on save/submit: derivations, constraints, and actions such as auditing, copying, messaging, business process initiation, etc. Such logic should be architected so that it is shared for multiple User Interfaces and Message-based transactions.

Business Logic Overview

To use Business Logic: Build your applications, And your Domain Objects in the usual manner Specify your Business Logic declaratively, using your IDE (e.g, Eclipse) Your IDE provides code completion and error indications for building rules And a debugger, for use in Logic Debugging Hibernate invokes the Business Logic Engine as an event listener. The engine invokes your logic (re-use is automatic) And performs read/write of your Domain Objects using Hibernate data access / transaction APIs Publish your Logic through automatically generated logicdoc, with transparent Requirements Traceability to Logic Click here to review the documentation, particularly the Training.

Why do I need Business Logic?

The logic of Business Logic:

1. Business Logic is 50% of the Build Phase
2. Within Business Logic, a key need is multi-table logic (sums, counts, references to related parent data)
3. Such needs are poorly addressed by
   • Rete Business Rule Engines that perform poorly, and do not assure integrity
   • Manual code requiring significant code expansion that is neither agile nor transparent
4. Business Logic addresses multi-table logic using simple business expressions
   • replacing 10 pages of code with 7 business-oriented rules, transparent to Business Users
   • executing with Enterprise-class performance optimizations for SQL elimination/minimization

How does Spreadsheet Business Logic work?

The sub-sections below illustrate the use of Business Logic over the life-cycle of your project:

1. Analysis: capture Business Logic by adding rigor to current process
2. Design: automated by chained formulas - like a spreadsheet
3. Development: declare 7 rules (see next section) - instead of 10 pages of code
4. Execution: the Business Logic Engine minimizes/eliminates SQLs
5. Maintenance: automated re-use, re-ordering and re-optimization - just change the rules

Analysis naturally captures the Business Logic

To nail down the understanding of the Check Credit Requirement, an Analyst might

1. Have the the following conversation with a Business User in the course of elaborating the Check Credit requirement (left column), and then (perhaps afterward)
2. Specify the Logic that implements the requirement (right column)

Check Credit Design Process - stepwise definition of terms

Analyst / Business User Dialog	Resultant Business Logic Is Executable: replaces 10 pages of code
What does it mean to Check Credit? The Balance can't exceed the Credit Limit	Constraint: customer.balance < customer.creditLimit
What is the Credit Limit? Entered by the Sales Department	Assure Data Model contains this attribute, and that an Application exposes it to the Sales Department
What is the Balance? It is the sum of the unpaid orders marked "ready" by the user	Sum: customer.balance = Sum(orders.amountUnPaid where isReady)
What is the AmountUnPaid? Discounted amount - amount paid	Formula: purchaseorder.amountUnPaid = purchaseorder.amountDiscounted - purchaseorder.amountPaid
What is the discount amount? Platinum customers get a 5% discount off the total	Formula: purchaseorder.amountDiscounted = purchaseorder.amountTotal if (purchaseorder.customer.creditLevel == "P") purchaseorder.amountDiscounted = purchaseorder.amountTotal * 0.95
What is the AmountPaid? Let's defer that until we discuss Make Payment, later in the Order Process
What is the AmountTotal? The total of all the Lineitem Amounts	Sum: purchaseorder.totalAmount = Sum(lineitems.amount)
What is the Lineitem Amount? Quantity Ordered * Part's Price	Formula: lineitem.amount = lineitem.qtyOrdered * lineitem.partPrice
What if the Price changes after the PO? Ah, right, customer gets the original price	Formula lineitem.partPrice = ParentCopy("Part.price") // no cascade

We have denoted the rules in the right column. As you can see, Business Logic closely matches the detailed statement of the problem.

Optionally, you can preserve this analysis discussion in your Logicdoc documentation:

As shown in Implementation, this capture can also list the rules noted in the right column, preserving your design intention.

Transparency

Spreadsheet Business Logic provides transparency in a number of dimensions:

• Design

  Logicdoc (illustrated above) enables you to capture your Requirements in Business User terms, and track the actual implementation into executable Logic. Business Users become partners in the development effort, making your Business Logic a true corporate asset.

• Execution

  Logic Debugging provides a full Console of logic execution, with the option to use your IDE's debugger.

• Administration

  Logic Console enables you to manage a deployed application: understand which logic is running, monitor its performance, etc.

Design Automated by Chained Formulas - like a Spreadsheet

Unlike procedural approaches where there are very complex design decisions around re-use, ordering, optimization and so forth, Spreadsheet Business Logic automates these elements of design. It does so by applying the metaphor of a spreadsheet to business logic, as described in the sub-sections below.

Formula-based

The first key concept of spreadsheets is that you don't write code, you declare formulas. As illustrated in the table below, Spreadsheet Business Logic uses the same declarative metaphor, and provides analogous execution automation.

In a Spreadsheet	In Business Logic
Define cell formulas: cell A is the sum of column B	Define Domain Object attribute formulas Customer.balance = Sum(order.amountUnpaid where isReady) Note: to address a database of related tables, these formula are Multi-table.
From this, the spreadsheet "knows" that adjust A when B elements are inserted, updated and deleted	The Business Logic Engine "knows" to automate the transaction processing adjust Customer.Balance when Orders are inserted, updated and deleted

Forward Chaining: automatic multi-table dependency management

Spreadsheets can express enormously complex problems - without programming - because they support what Computer Scientists call Forward Chaining: formulas can depend on each other. So, you alter a cell, and its effects ripple through the spreadsheet. This is not a simple process, since the spreadsheet must determine a dependency-based execution order to get the correct answer. The same ordering issue exists in Spreadsheet Business Logic, but now both within a row and - much more significantly - between rows. The sub-sections below briefly examine the specific cases the Business Logic Engine must address to automate multi-table transactions (observe: all such Forward Chaining in executed in the context of a Hibernate transaction).

Formula Ordering

The Dependency Analyzer of the Business Logic Engine examines every Formula, and orders their execution with respect to their dependencies. This addresses within a row; the following sections address between rows.

Child Aggregate Adjustment

Observe the Customer.Balance rule involves two related parent/child Domain Objects.

As described in Business Logic Execution triggered by Child changes, changes to child attributes are analyzed. If any attribute is changed that is part of a declared Sum (a summed attribute, a Foreign Key part of the Qualification Condition), the system Forward Chains to execute Parent Business Logic.

This process can chain. The example above automates a conventional multi-table transaction involving Customer, Purchaseorder, Lineitem and Product.

Parent Reference Cascade

The PurchaseOrder.AmountDiscounted rule also involves 2 tables with the Customer.Level parent reference. The Business Rule Engine's Dependency Analyzer detects all Parent References from child Domain Objects.

If (and only if) Parent Referenced attributes are changed, the Business Logic Engine will Forward Chain to each referencing Child instance so that it can re-evaluate its Business Logic in light of the new data. This is called Cascade processing. See also the Use Case Make Order Ready.

Development: Declare Business Logic

Once your Analysis process has identified the rules, you merely declare them as follows:

Declaring Business Logic

To declare Business Logic: Create a Java/Groovy Business Logic Component This is a class that corresponds to a Hibernate-managed Bean (Domain Object) Create a method for the Business Logic Rule (identified by Annotations) Your component can contain other methods Your Business Logic can reference these and other Java/Groovy services

Agility - automated Complexity Management

The example above illustrates how just 7 Business Logic Rules can replace 10 pages of code. Even if you think you can code and debug 1 page per day, the agility of automation is overwhelming.

The underlying concept is Forward Chaining, a fundamental tool in complexity management. As your local Computer Scientist will tell you, program size depends on the number of interactions**2. So, automatic dependency management results in a profound reduction of code - arithmetic, not geometric.

Power through Open Declarative Business Logic

Your Business Logic is fully declarative: the Business Logic Engine is responsible for Ordering, Re-use and Optimization. You can declare your rules in either Java, or Groovy which provides a more natural syntax and automatic type. You acquire power at two levels:

Declarative Business Logic addresses complex logic

The Check Credit example is a typical transaction in terms of complexity. The Business Logic Rules scale to truly complex transactions, as shown by the fully worked / described examples in the Demo Tutorial that are shipped with the product:

• Computing a Bill of Materials Kit Price, based on the transitive closure of all the components (and sub-components) of the kit
• Exploding a Bill of Materials on Place Order, so inventory reflects the remaining stock for the transitive closure of all the components (and sub-components)
• Cloning an Order (a deep copy)
• Computing a Department Budget, reflecting the transitive closure of all the sub-departments (and sub-sub Departments) budgets
• Placing a Payment, allocating to all the outstanding orders, oldest first

Open Business Logic: Extensible via Java integration

Open Business Logic means you can invoke Java/Groovy from your Business Logic Rules. This enables your organization to use/build a library of re-usable logic services such as date functions, or completely new Business Logic Rule Types such as allocation or copy. The latter are shipped with the product, both for your use, and as illustrations of how to build Extensible logic.

In addition to logic extensibility, the Business Logic Engine is architected for systems extensibility. You can supply your own factories to select the Business Logic Component for a Domain Object (e.g., PurchaseorderRetail vs. PurchaseorderWholesale). Events are provided so you can determine all the changes in a transaction. And, mechanisms are provided to accomodate your Hibernate extensions, such as configuration.

Automatic Invocation guarantees integrity

You do not directly invoke Business Logic with explicit API calls. Instead, the Business Logic Engine is registered as a Hibernate Event. When invoked, Business Logic Engine locates and executes the Business Logic Rules you define in Business Logic Components that correspond to each Domain Object.

Unlike Rete Business Rule Engines which require explicit invocation, this means that integrity is guaranteed. Elective integrity simply cannot guarantee integrity it depends on a programmatic call.

Automation invocation also means Business Logic easy to adapt: you can introduce Spreadsheet Business Logic with minimal impact on the rest of your system (even if portions have already been coded).

Automatic Partitioning promotes re-use and performance

It is sadly true that far too much procedural business logic winds up in client event handlers. This can interfere with re-use between screens, and makes the logic unavailable for message processing. It can also lead to performance issues, since network traffic can be increased by not centralizing the logic in the server.

Unlike manual approaches, Business Logic guarantees that the logic is partitioned for re-use and performance.

Architected to handle complexity

Automation is not compelling if you unexpectedly encounter problems it cannot handle. Spreadsheet Business Logic is architected to scale to complexity:

• The Demo Tutorial illustrates simple solutions to well-known complex problems, such as a Bill of Materials explosion, a recursive budget rollup, or the allocation of a Payment to a set of outstanding orders
• When declarative services fall short, Extensibility services enable you not only add Java/Groovy code, but to define new re-usable rules that extend the Business Rules Engine.

Execution architected for high performance

The Business Logic Engine is architected to Minimize/Eliminate SQL overhead.

• Pruning: the Business Logic Engine analyzes updates, and avoids parent access, adjustment and cascade when the referenced data is not changed
• Adjustment Logic: maintains aggregates with a single SQL

  Unlike Rete Business Rule Engines that load all the data into memory, or issue aggregate Select sum queries, this assures optimal performance. This is particularly important with there are chained aggegrates

Maintenance Automation

Maintenance is a process that is expensive, reduces agility, and hated by developers. Business Logic can automate large portions of maintenance as described in the sub-sections below.

Automatic Re-use over transaction type and source

Re-use is a core development objective, requiring substantial design effort. It is certainly not automatic. It is, however, for Business Logic:

• Re-use over transaction source: Your Business Logic is encapsulated to its Domain Object, helping to assure data integrity since your logic is automatically shared over transaction sources (customers get the same answer regardless of the interaction):
  • Interactive business logic is not required in page actions, avoiding the anti-pattern of business logic in page actions which cannot be used for message-based transactions
  • Message-based - services automatically re-use the domain logic, so that services are thin.
• Re-use over Use Cases: since the logic is declaratively encapsulated into the Domain Objects, logic you define for one Use Case is automatically re-used for related Use Cases. The Customer.Balance rule, while declared for Place Order, is encapsulated into the Order Domain Object, so that it is automatically re-used over all these related transactions
  1. Delete Order - the balance is reduced
  2. Make Order Ready - the balance is increased
  3. Pay Order - the balance is reduced
  4. Reassign Order to a new customer - new customer balance increased, old balance decreased (for IsReady Orders)
  5. All the various cases of Change Order:
     1. Change a Line Item Quantity
     2. Change a Line Item Part
     3. Add a Line Item
     4. Delete a Line Item

So, when you make a change, the system automatically reflects it in all the relevant transactions.

Automatic Re-ordering

The core element of maintenance is the archeology to determine how the current code was ordered, so that new code can be merged without error. Business Logic eliminates this requirement, since the ordering is executed automatically the the Business Rule Engine.

Automatic Re-optimization

Unlike traditional systems whose performance degrades with each patch due to time constraints, the Business Logic Engine always applies the performance considerations noted above. On every change.

Who uses Business Logic?

Business Logic can represent a corporate asset since it forms a language understandable to many groups within the organization:

• Developers: use Business Logic to displace Java code they currently must otherwise implement, so they are the main users.
  • Application Developers specify the actual rules
  • Systems Developers and Architects leverage the Extensibility services to extend the Rule Types, and integrate Business Logic into their architecture
• Business Users: as illustrated below, the Business Logic Rules provide transparency to the organization, particularly when present in the context of PURL
• Managers: can also quickly inspect the implementation in ways that are impractical with code
• Business Analysts: can use Business Logic to document the Requirements in such a way as to facilitate the ensuing implementation

Next Steps

If you think Business Logic holds promise for your organization,

• Review the Architecture and the Key Characteristics of Business Logic
• Review the Demo Tutorial
• Download the trial version, and explore the sample database
• Review the Documentation, below

Documentation Map

Readme First Spreadsheet Business Logic: What, Why, How Architecture Demo Tutorial FAQs Quick Start Training Project Integration Beta Readme What's new

Main Concepts Business Logic Components Sum, Count, Formula Constraint, Action Business Logic Execution Design and Documentation Logicdoc Design Patterns Key Characteristics Performance Extensibility Database Design

Operations Logic Syntax Installation Configuration Logic Testing Logic Debugging Trouble Shooting