JBossWorld Keynote Demo

jBPM was a big part of the JBossWorld keynote demo this year!  The demo featured the JBoss Toy Store, a simple shopping cart application.  You could use your mobile device to order various products (from phones to shirts), and a jBPM process was used to handle and manage the orders, all running in the cloud (on OpenShift).

The full video of the keynote is available below (you can skip to 14min30 if you immediately want to skip to the demo itself, which in total takes about 20min), this blog will explain some of the details on how jBPM was used to achieve this.

Whenever a new order was placed (either through one of the mobile clients or the web-based client), a process described the life cycle of the order. The process itself is shown below.  The process itself is modelled using the BPMN 2.0 standard (both the visualization and the XML format used to store the process) and was defined in the web-based designer.

After some initialization, a Risk Assessment was done to decide whether the order was high or low risk.  This was modelled using a Business Rule Task, that in this case used a web-based decision table to make the decision.  In the demo, we simply look at the amount of the order, to decide whether it is high risk (larger than or equal to 500$) or not (less than 500$), but this could easily be extended with more complex logic.

All orders needed to go through a first Review (where a sales representative would manually check whether the order was valid and would accept or reject the order, for example to get rid of fake or unwanted orders etc.).  High-risk orders would undergo an additional Vice President Review (our VP really wanted to keep control of the company).  In the demo, the VP (played by Jay on stage) automatically rejected orders above 3000$ (just to make sure our participants needed to play smart to win ;)).  Both review tasks were modelled using a User Task and contained various details on who to assign the task to, the data associated with the task, etc.  After the review(s), the order was then either shipped (which we modelled using a domain-specific Service Task), or a rejection email was sent (using the out-of-the-box Email Service Task).

People in the audience were invited to participate in this experiment and put in orders.  A leaderboard was used to show the overall progress.  This showed the total amount of orders per person, and some dials and charts showing the order transaction rate, order backlog (orders still being processed), etc.  The data was collected by listening to and/or querying the jBPM engine and/or task service.

We used a process monitor to visualize where all the orders were waiting.  The number on top of each node shows how many orders are currently waiting there.  This view is actually the web-designer that we extended with this monitoring information (that was updated every few seconds from a REST service that would provide the necessary information).  We're working on getting this integrated in the project by default as soon as possible.

In the demo, we played out a scenario where a lot of the orders got stuck in the VP Review (as Jay wasn't able to approve all the incoming orders fast enough), generating a huge backlog.  It's kinda difficult to explain, so I suggest you just take a look at the demo to see how it played out ;)  By changing the business logic on the fly, we then allowed better throughput (and yes, we also used a bot to help Jay a little with approving all these orders more quickly, but everything was real, no cheating ;)).

Some technical details:

• Everything (web-based designer + guvnor repository, jBPM engine, dashboards and process monitor) was running in the cloud (on OpenShift), on AS7. The laptops simply used a web browser to show the web-based apps running there.
• The jBPM engine was embedded as part of the shopping cart application, and was invoked whenever a new order was retrieved, or when any of the review tasks were done.  One session was used to handle all requests.
• The engine was configured to user persistence (using Hibernate4 / JPA2 and an H2 in memory database)
• The changes done in the application and by the jBPM engine were combined in one user transaction.
• The default task service (that comes with jBPM out-of-the-box) was used to manage the task lists and the life cycle of each tasks.  We used one local task service (running next to the engine) to make sure these changes were also done in the same transaction and avoid remote communication.

The source of the demo application is available here.  You can download and run the application on your own laptop, or even push it to OpenShift as well.

We really enjoyed creating and doing the demo, and we hope so will you!