Spring Demo Project

Pre-requisites

This project uses Maven to retrieve all its required libraries. 

Running from the command line

If you're going to run this demo using straight Maven from the command line, you don't need anything beyond Maven.

Running in Eclipse

If you're going to run this demo in Eclipse, make sure that you have the M2E plugin installed. 

In addition, if you use Eclipse or a derivative, you must also have the M2E WTP plugin installed, otherwise some jars will be deployed that shouldn't. Once you have M2E installed, select "Preferences" -> "Maven" -> "Discovery" -> "Open Catalog" and install the m2e-wtp plugin.

You may consider using SpringSource Tool Suite, which is a special edition of Eclipse with all kinds of facilities for Spring. The integration is well done, and it's a powerful environment for Spring work. However, it is not required for this demo.

Running in other IDE's

Other IDE's such as SpringSource Tool Suite 2.8, IntelliJ IDEA 10.5, and NetBeans 7.0 do not seem to require anything special.


Installation

Download the Spring demo from the download area:


and extract it. You then have two choices:

Running using Maven

To run the demo from the command line using Maven, go to the directory you just extracted (the one which contains the pom.xml file) and execute either:

mvn tomcat:run

or:

mvn jetty:run

depending on your preference of server -- either works fine.


Once everything has started up (this can take a little while the first time), you should be able to connect to: http://localhost:8080/BusLogicDemoSpring


Running in your IDE

To run the demo in your IDE, open or import BusLogicDemoSpring as a project. We were able to open and run this project in Eclipse Indigo, IntelliJ 10.5 and NetBeans 7.0.1. In Eclipse, you may need to do a "project clean" before running.

Then run the application on a server. We tend to use Tomcat 7.0 ourselves, but any reasonably recent server should do (Jetty, JBoss, GlassFish, etc...).

Once everything has started up (this can take a little while the first time), you should be able to connect to: http://localhost:8080/BusLogicDemoSpring

The gadget spec URL could not be found


What to do in the app

Once you are in the app, we suggest that you do the following to exercise the business logic:

Edit a customer's credit limit

Change the credit limit for Alpha and Sons to something less than the current balance. This will violate a constraint, which will roll back the transaction and display a message.

Mark an order as paid

If you mark any order as paid, the customer's balance will be decreased by that order's amount.

Change a line item's product

Using the drop-down, change a line item's product. Notice how:
  1. the unit price is updated (copied from the new product)
  2. the amount is recomputed
  3. the order's total is recomputed
  4. the customer's balance is recomputed (assuming the order is not paid)
  5. if the customer's new balance exceeds the credit limit, an error message appears
While this may all seem simple, there is actually quite a bit going on here. In this particular case, the following rules were involved:
@ParentCopy("product.price")
public void deriveProductPrice() { }
The product's price was copied to the order item's productPrice.
@Formula("productPrice * qtyOrdered")
public void deriveAmount() { }
The order item's amount was then be recomputed, since productPrice had changed.
@Sum("lineitems.amount")
public void deriveAmountTotal() { }
The order's amountTotal was then be recomputed, since one of its items' amount had changed.
@Sum("purchaseorders.amountTotal where paid = false")
public void deriveBalance() { }
If the order is not paid, then the customer's balance was recomputed, since one of the unpaid orders' amountTotal had changed.
@Constraint(value="balance <= creditLimit",
    errorMessage="Customer balance exceeds credit limit")
public void constraintCreditLimit() { }
Finally, the customer's freshly-updated balance was compared to the credit limit, and, if it exceeded it, the transaction was 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.


Visualizing the rules

If you select the Show events checkbox at the bottom of the page, any changes you make to the data will result in the display of all the rules that were executed within the transaction.

Where to go from here

We hope this very brief introduction to declarative business logic has been worth your time. This demo is a very simple example, but the same concepts can be used to create very sophisticated transactional applications.  Please drop us a line at support: we always love to hear from you.
Comments