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:
- 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
- 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
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.
To use Business Logic:
Why do I need Business Logic?
The logic of Business Logic:
- Business Logic is 50% of the Build Phase
- Within Business Logic, a key need is multi-table logic (sums, counts, references to related parent data)
- 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
- 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:
- Analysis: capture Business Logic by adding rigor to current process
- Design: automated by chained formulas - like a spreadsheet
- Development: declare 7 rules (see next section) - instead of 10 pages of code
- Execution: the Business Logic Engine minimizes/eliminates SQLs
- 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
- Have the the following conversation with a Business User in the course of elaborating the Check Credit requirement (left column), and then (perhaps afterward)
- 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
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
customer.balance = Sum(orders.amountUnPaid where isReady)
What is the AmountUnPaid?
- Discounted amount - amount paid
purchaseorder.amountUnPaid = purchaseorder.amountDiscounted - purchaseorder.amountPaid
What is the discount amount?
- Platinum customers get a 5% discount off the total
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
purchaseorder.totalAmount = Sum(lineitems.amount)
What is the Lineitem Amount?
- Quantity Ordered * Part's Price
lineitem.amount = lineitem.qtyOrdered * lineitem.partPrice
What if the Price changes after the PO?
- Ah, right, customer gets the original price
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.
Spreadsheet Business Logic provides transparency in a number of dimensions:
- 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.
- Logic Debugging provides a full Console of logic execution, with the option to use your IDE's debugger.
- 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.
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
Ordersare inserted, updated and deleted
Forward Chaining: automatic multi-table dependency management
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
Customer.Balancerule 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
PurchaseOrder.AmountDiscountedrule also involves 2 tables with the
Customer.Levelparent 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 logicThe 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 integrationOpen 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
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
- Delete Order - the balance is reduced
- Make Order Ready - the balance is increased
- Pay Order - the balance is reduced
- Reassign Order to a new customer - new customer balance increased, old balance decreased (for IsReady Orders)
- All the various cases of Change Order:
- Change a Line Item Quantity
- Change a Line Item Part
- Add a Line Item
- Delete a Line Item
So, when you make a change, the system automatically reflects it in all the relevant transactions.
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.
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
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