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.
We really enjoyed creating and doing the demo, and we hope so will you!
