Vaadin Demo Installation

BusLogicDemoVaadin is a simple project that demonstrates the use of ABL's transactional business logic engine with the Vaadin framework.  This page explains how to install and run the demo, which includes the runtime jar.  Visit the downloads page to obtain the full product, with documentation and samples.

BusLogicDemoVaadin uses the same database schema, and the same business logic, as the basic AutoBusLogic. However, unlike the basic demo, which is built using straight JSP, this demo is built entirely using Vaadin as the GUI framework.

Under Construction: this demo is operational, but there are several issues with the installer and licensing that require resolution.


The project can be downloaded as a ZIP'ed file.

Once you have the file, you'll want to extract it, which will result in a directory named BusLogicDemoVaadin. This directory is a Vaadin project that can be imported into Eclipse, or any other IDE. We'll focus on Eclipse here, but the process should be similar in other environments.

Loading the project into Eclipse

Before doing this, you'll want to make sure that you have the Vaadin Studio plugin installed, since it does make life easier. It is available from the Vaadin web site.

You will also require JDK 1.5 or later. This demo does not work with JDK 1.4 or earlier.

To load the project into Eclipse (typically in a new workspace):
  • select File -> Import
  • select General -> Existing Projects into Workspace
  • select the BusLogicDemoVaadin directory
  • finish the import
  • add the jpacontainer jar to WebContent/WEB_INF/lib
  • assign the application to a new Tomcat server
  • start the server
  • connect to http://localhost:8080/BusLogicDemo

At that point, you should see a screen similar to:

What does the demo do?

The demo is a simplistic (but not trivial) order management application. In this application, you can:
  • navigate from customer to customer using the drop-down at the top
  • change a customer's credit limit
  • create and delete orders
  • make an order paid or unpaid
  • edit an order's notes
  • change an order item's quantity
Whenever you edit something (e.g. change the customer's credit limit, add an item to an order, change an item's quantity, etc...), the transactional business logic fires when the transaction is committed. If it succeeds, the GUI is then notified to refresh whatever data has been changed.

A few things to try

Once you are in the demo, we suggest you try the following:

Mark an order as paid

If you check the "Paid" checkbox for an order, you will notice that the customer's balance will decrease by the amount of the order. That's because only unpaid orders count towards a customer's balance.

Edit a customer's credit limit

If you change a customer's credit limit to be less than the balance, you will get a constraint violation, and the transaction will be rolled back.

Edit Line Item Quantity Ordered

Again, you will see adjustments rolled up to customer.  You can try a very large quantity to fire the Credit Limit Exceeded constraint.

While this may all seem simple, there is actually quite a bit going on here. In this particular case, the following rules are involved:


public void deriveProductPrice() { }

 The product's price will be copied to the order item's productPrice.

@Formula("productPrice * qtyOrdered")

public void deriveAmount() { }

 The order item's amount will then be recomputed, since productPrice has changed.


public void deriveAmountTotal() { }

 The order's amountTotal will then be recomputed, since one of its items' amount has changed.

@Sum("purchaseorders.amountTotal where paid = false")

public void deriveBalance() { }

 If the order is not paid, then the customer's balance will be recomputed, since one of the unpaid orders' amountTotal has changed.

@Constraint(value="balance <= creditLimit",

    errorMessage="Customer balance exceeds credit limit")

public void constraintCreditLimit() { }

 Finally, the customer's freshly-updated balance will be compared to the credit limit, and, if it exceeds it, the transaction will be rolled back.

Notice that we never specifically invoked any of these rules. They were invoked automatically as part of the commit process. And they were invoked in the correct order, because the logic engine understands the dependencies between them.

This means that the application doesn't have to know (or care) about the rules, and can just focus on the task at hand (allowing the user to manipulate data), rather than worry about enforcing the underlying business logic.