AutoBusLogicZK is a simple project that demonstrates the use of ABL's transactional business logic engine with the ZK framework. This page explains how to load the demo and the required runtime. To load the entire product (with samples and documentation), see the downloads page.
AutoBusLogicZK 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 ZK as the GUI framework.
Start by downloading the ZK demo from the download area:
Once you have the file, you'll want to extract it, which will result in a directory named AutoBusLogicZK. This directory is a ZK 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.
Before doing this, you'll want to make sure that you have the ZK Studio plugin installed, since it does make life easier. It is available from the ZK 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:
At that point, you should see a screen similar to:
The demo is a simplistic (but not trivial) order management application. In this application, you can:
Note that this app has no "Save" button: all changes are applied immediately. When editing text in a text box, just tab out of the box, or click out of it, and the change will be applied.
This was done to keep the interface simple, but you are of course not required to use the same approach in your own applications.
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.
Once you are in the demo, we suggest you try the following:
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.
If you expand an order (using the + icon in the left column), you'll see that each order has a drop-down titled "Reassign to customer...". If you select a customer from that drop-down, the order will then be moved to that customer, and will therefore disappear from the current view. The current customer's balance will be decreased
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.
If you change the product for an order item (e.g. from a shovel to a hammer), you'll see that the item's amount, the order's total, and the customer's balance (if the order is unpaid) will be updated.
While this may all seem simple, there is actually quite a bit going on here. In this particular case, the following rules are involved:
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.