Small steps with big feet

Native BPMN 2.0 execution with the freshly released jBPM 4.3

Happy 2010 to all the folks who read this blog! I’m extremely pleased to start this  year with a bang by announcing that jBPM 4.3 has been released!

As we announced last month, the major achievement of this release is the native BPMN 2.0 execution on top of the PVM. See the announcement itself for more information, examples and a shiny movie.

The main goal of the first release of our BPMN 2.0 implementation was to implement the ‘basic’ part of the specification. Using the basic constructs, one should already get quite an impression how BPMN 2.0 can be used in practice with jBPM. We’re extremely proud that we’ve managed to include the BPMN 2.0 implementation as an integral part of the jBPM framework. This means that no database or API changes are required when you want to start using BPMN 2.0 with jBPM. Heck, enabling BPMN 2.0 in jBPM requires one single line of configuration. Just check the example of the previous BPMN 2.0 blogpost to see all this sweetness.

The complete distribution zip file can be found on http://sourceforge.net/projects/jbpm/files/

This distribution includes quite a few examples to get you started. The developers guide that is shipped with the distribution also contains a whole new chapter about how to implement BPMN 2.0 processes using jBPM 4.3. The content of the documentation is detailed and people with no prior BPMN 2.0 knowledge should be able to understand it without much problems. See the subdirectory /doc/devguide to find this guide. Or you can take a look online(link to my own version, online doc on docs.jboss.org isn’t yet updated due to past holiday season – but this can change any moment now).

To finish up, let me quote one of our prominent Community Users, Bernd Rücker:

“2010: the year of BPMN 2.0″

Of course, BPMN 2.0 isn’t the only thing we’ve been doing the last two months. Check our JIRA for a complete changelog. Most noteworthy new features are the ejb and jms invocation for JPDL – features that are easy to leverage for a future jBPM BPMN 2.0 release …

As always, thanks for reading!

Upcoming review ‘jBPM Developer Guide’ by Mauricio Salatino

Building an open source framework sure is a rewarding experience. You see community people logging issues, contributing patches, answering forum posts, joining the community days, etc.

And sometimes there is a crazy enthusiast user who sacrifices *a lot* of his free time to write a jBPM book. Heck, writing a jBPM book has been a long-lived dream for me … but some things always seem to come between that dream and reality (you know, like building a BPMN 2.0 implementation on top of jBPM). But that’s probably just an excuse, I know.

Writing a book takes a lot of time and effort and it’s an adventure that’s not to be taken light-heartedly. So many, many, many kudos to Mauricio Salatino for writing the just released “jBPM Developers Guide”! Just click on the book cover on the left to get more information or to order your own copy.

The people of Packt publishing were so kind to send me a review copy of this book, which I received this morning (see picture below). So expect a review coming up soon (I’m going to give it a thorough reading).

jBPM goes BPMN!

For those who follow the jBPM internal discussions a bit, the marriage of jBPM and BPMN will come as no surprise. Since this summer we’re coding away at a native BPMN2 implementation on top of our Process Virtual Machine (PVM), and you might have seen tweets or forum posts passing by where the term ‘BPMN’ pops up. However, the only proof were some classes in our SVN trunk …. until now!

In this post I’ll give you a sneak peek of our current BPMN2 execution effort which will be documented, QA’d and incorporated in the jBPM 4.3 release (scheduled January 1st). Many thanks go out to our community members Ronald Van Kuijk and Bernd Rücker, who have contributed a significant amount of  ideas and code (and in fact, still are contributing to the BPMN2 implementation now as we speak). This is open-source power at its fullest…

Happy times indeed!

What is BPMN2?

Basically, the Business Process Modeling Notation (BPMN) started out a pure graphical notation standard for business processes, maintained by the Object Management Group (OMG). Version 2.0, which currently is in beta, adds execution semantics to the specification and this is of course where it gets interesting for jBPM.

The primary benefit of BPMN2 is that it is a standard accepted by the IT industry, which means that process models become portable (graphical and execution-wise) across process engines such as jBPM. Since process executions are the raison-d-être of jBPM, it is only natural we are now investing in BPMN2. People who are familiar with JPDL (the current native language of jBPM) will have generally no difficulties in learning the BPMN2 language, as many constructs and concepts are shared. In fact, from a high-level point of view, BPMN2 and JPDL are in concept solving the same problem (which is a biiiiig difference with BPEL – but that’s a story I’ll let other tell).

Of course, this is just the nutshell explanation. You can find a lot more information in our wiki.

Enough talking … show me how it works!

The business process we’re going to implement looks as follows (click to enlarge – created using the wonderful editor from our friends at Signavio).

You might recognize this example, since we’ve also implemented it in JPDL as an example in our distribution.

The business process is simple: an employee can start a new process and make a request for a certain amount of vacation days. After the request task has been completed, the manager will find a verification task in its tasklist. The Manager can now decide to accept or reject this request. Depending on the outcome (that’s the little rhombus on the outgoing transitions, or better said ’sequence flow’ as it is called in BPMN. It means that there is  a condition that must be true to follow it), a rejection message is send or the process ends.

As is the case with JPDL, BPMN2 uses an XML language to define the process definition. Our business process looks like this in BPMN2 XML:

<?xml version="1.0" encoding="UTF-8"?>
<definitions id="vacationRequest"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xsi:schemaLocation="http://schema.omg.org/spec/BPMN/2.0 BPMN20.xsd"
 xmlns="http://schema.omg.org/spec/BPMN/2.0"
 typeLanguage="http://www.w3.org/2001/XMLSchema"
 expressionLanguage="http://www.w3.org/1999/XPath"
 targetNamespace="http://jbpm.org/example/bpmn2/vacation_request"
 xmlns:jbpm="http://jbpm.org/bpmn2">

 <process id="vacationRequestProcess" name="BPMN2 Example process">

   <startEvent id="start" />

   <sequenceFlow id="flow1" name="fromStartToRequestVacation"
     sourceRef="start" targetRef="requestVacation" />

   <userTask id="requestVacation" name="Request Vacation"
       implementation="other">
     <potentialOwner resourceRef="user" />
     <rendering id="requestForm">
       <jbpm:form>request_vacation.ftl</jbpm:form>
     </rendering>
   </userTask>

   <sequenceFlow id="flow2"
     name="fromRequestVacationToVerifyRequest" sourceRef="requestVacation"
     targetRef="verifyRequest" />

   <userTask id="verifyRequest" name="Verify Request"
       implementation="other">
     <potentialOwner resourceRef="manager" />
     <rendering id="verifyForm">
       <jbpm:form>verify_request.ftl</jbpm:form>
     </rendering>
   </userTask>

   <sequenceFlow id="flow3" name="fromVerifyRequestToEnd"
       sourceRef="verifyRequest" targetRef="theEnd">
     <conditionExpression xsi:type="tFormalExpression">
        ${verificationResult == 'OK'}
     </conditionExpression>
   </sequenceFlow>

   <sequenceFlow id="flow4"
       name="fromVerifyRequestToSendRejectionMessage" sourceRef="verifyRequest"
       targetRef="sendRejectionMessage">
     <conditionExpression xsi:type="tFormalExpression">
        ${verificationResult == 'Not OK'}
     </conditionExpression>
   </sequenceFlow>

   <scriptTask id="sendRejectionMessage" name="Send rejection Message"
       scriptLanguage="bsh">
     <script>
       <![CDATA[System.out.println("Vacation request refused!");]]>
     </script>
   </scriptTask>

   <sequenceFlow id="flow5"
     name="fromSendRejectionMessageToEnd" sourceRef="sendRejectionMessage"
     targetRef="theEnd" />

   <endEvent id="theEnd" name="End" />

 </process>
</definitions>

Most of the constructs are straightforward, certainly if you’re coming from a JPDL background. Do note that the Resource construct isn’t correctly implemented (yet), but that should be solved for the 4.3 release. Also note that you already can add taskforms to your user tasks (see line 33-35 for example).

Also interesting to note is the way how the outcome of the user task is used is for guiding the flow through the process (line 41 and 49). We could have used an exclusive gateway to do the same (which is also already implemented), but we’re using formal expressions on the outgoing sequence flows coming from the user task, just to show you we can.

That’s cool … but I’m a Java developer!

Rest assured: everything that makes jBPM a blessing to use is here to stay. Tom has put a tremendous effort in the jBPM PVM and we now are reaping the fruits of his work. BPMN2 is implemented on top of the PVM, which means that many things come for free: database persistency, database transactions, the service and query API’s, etc. it all just works.

So, when we want to test a business process, we use the same Java approach which we always had with jBPM:

public class VacationProcessTest extends JbpmTestCase {

  protected void setUp() throws Exception {
    super.setUp();

    NewDeployment deployment = repositoryService.createDeployment();

    deployment.addResourceFromClasspath("vacationrequest.bpmn.xml")
    String deployId = deployment.deploy();
    registerDeployment(deployId);

  }

  public void testRequestRejected() {

    ProcessInstance pi = executionService.startProcessInstanceByKey("vacationRequest");

    // After process start, peter (employee)
    // should be a candidate for the task
    Task requestTasktask = taskService.createTaskQuery()
              .candidate("peter").uniqueResult();
    assertNotNull(requestTasktask);

    // After this task is completed,
    // a manager (eg alex) is be able to see a 'verify' task
    TaskQuery verifyTaskQuery = taskService.createTaskQuery()
                                           .candidate("alex");
    assertNull(verifyTaskQuery.uniqueResult());
    taskService.completeTask(requestTasktask.getId());

    Task verifyTask = verifyTaskQuery.uniqueResult();
    assertNotNull(verifyTask);

    // When completing the verification task,
    // we also need to store the result of the decision
    // (will be done through the taskform normally)
    Map<String, Object> vars = new HashMap<String, Object>();
    vars.put("verificationResult", "not OK");
    taskService.completeTask(verifyTask.getId(), vars);

    // With a rejection, we should see
    // the 'sendRejectionMessage' task in the history log
    HistoryActivityInstance hai = historyService.createHistoryActivityInstanceQuery()
      .activityName("sendRejectionMessage").uniqueResult();
    assertNotNull(hai);
    assertProcessInstanceEnded(pi);

  }

}

So what you’re seeing here is

• Testing BPMN2 business processes in pure Java code that everybody understands
• in a way which is exactly the same as for JPDL
• and using the very same API which we are all familiar with
• and using the very same database schema as before!

What’s there not to like? In my opinion, the argument of the same API is really really really powerful. The PVM is showing its power at its fullest! To configure your jBPM installation for BPMN2, you just have to add this line to your jbpm.cfg.xml file:

<import resource="jbpm.bpmn.cfg.xml" />

Conclusion: using BPMN2 processes in your application with jBPM is extremely easy. Everything you know about embedding and configuring jBPM is just as before … except that you’re now using a portable and standard process language.

What else?

A lot. Just check our wiki to see what’s planned for the 4.3 release. When talking in pure BPMN2 constructs, these are all planned for next month: Exclusive Gateway (XOR), Parallel gateway (AND), Service Task (Java based), Manual Task, Receive Task (Java only), Script Task, User Task, None start event, None end event, Terminate end event, Sequence Flow, Conditional Sequence flow, Formal expression, Interface (Java), Resource + ResourceParameter. More is possible, if we go to bed a bit later than usual

To finish this sneak peek, here is a screencast of our jBPM console executing the BPMN2 example process which is described above. In this screencast, you’ll see Peter (the employee) requesting 5 days of vacation using our business process. After he finishes the request task, he logs out. Mike, a manager, now logs in and finds the vacation request in his task list. He rejects the request since there is too much work. Peter will now be notified with a rejection message (for this demo, just a printout to the console). The forms you see are using the same taskform mechanism which I described earlier.

The last part of the screencast shows that the reporting functionality, which was already available for JPDL, also works for the BPMN2 processes. Even better, since the PVM defines a shared database schema, reports can aggregate data based on JPDL and BPMN2 processes without any problem!

Until next post!

Joram

New feature in jBPM 4.2: Auto-upgrade your jBPM installation

Introduction

With the 4.2 release coming close (somewhere beginning next week), I feel is time to write about one the new nice features of this particular release.

As a software engineer, I’m always eager to try out a new release when of one of the products/frameworks/… I use on a daily basis hits the shelves. I’ve also learned that I’m not alone on this matter and that it is a common thing among developers to have this burning itch to try out new stuff. But with every new release it’s also always keeping fingers crossed and hoping that everything stays working as it was without actually having the system blow up in your face.

With a new jBPM release, there are three ‘change-areas’ which could disrupt your current system:

* API changes. As I wrote a few months ago, starting from jBPM 4.0, there is a new API. Our policy is is to keep changes to the API (extremely) limited and deprecate any to-be-changed operations for two or three releases before actually replacing them completely. This means you have plenty of time do execute the change. So no blow-up on this front.

* JPDL schema changes. A New jBPM release often means additional features, which could lead to jPDL schema changes that make existing process definitions incompatible with the latest release. This issue has been addressed in the upcoming 4.2 release: old process definitions will remain backwards compatible with newer releases of the engine. Not a single change to your precious process definitions will be needed when upgrading your jBPM4 installation. So for example process definitions coded in 4.1 style will be deployable to a 4.7 engine. For more info, see the Jira issue. So again, no fear for blow-ups here.

* Database changes. Since jBPM uses a relational database as a persistence mechanism for processes, tasks, audit history, etc… new features in the engine can lead to changes in the database. We try to keep these changes as limited as possible, but sometimes they are simply needed to evolve. Of course, with every release we indicate which changes need to be done to the database, but if you skip a few releases before you upgrade this tends to become cumbersome.

It’s this last point which I want to demonstrate in this post. The 4.2 and every subsequent release have a new mechanism on board to determine the current version of the database schema and update it to the fresh release automatically.

Setting up the ‘old’ data

We’ll start by downloading and unzipping an older release of jBPM, jBPM4.1:

[jbarrez@jenova 4.2_upgrade]$ unzip jbpm-4.1.zip

We’ll now create the jBPM schema using one of the install task shipped in the distribution. Since I’m using a MySQL database, I first need to update the jdbc properties that the install script will be using:

[jbarrez@jenova 4.2_upgrade]$ your-favourite-editor jbpm-4.1/install/jdbc/mysql.properties

and change it to my local database:

We can now create the schema in my local database (notice how we just need to add the ‘database‘ parameter, the script will then take the connection properties from the mysql.properties file we’ve just edited):

[jbarrez@jenova 4.2_upgrade]$ cd jbpm-4.1/install/
[jbarrez@jenova install]$ ant create.jbpm.schema -Ddatabase=mysql
Buildfile: build.xml
 [echo] database......... mysql
 [echo] tx............... standalone
 [echo] mail.smtp.host... localhost
 [echo] current dir = /home/jbarrez/dev/blog/4.2_upgrade/jbpm-4.1

create.jbpm.schema:
 [echo] creating jbpm schema in db jdbc:mysql://localhost:3306/jbpm
Executing resource: /home/jbarrez/dev/blog/4.2_upgrade/jbpm-4.1/install/src/db/jbpm.mysql.create.sql
79 of 79 SQL statements executed successfully
BUILD SUCCESSFUL Total time: 3 seconds

Which gives us a fresh jBPM 4.1 schema in our database:

We now use a basic ‘Hello World’ process definition:

<process name="helloWorld" xmlns="http://jbpm.org/4.0/jpdl">
  <start>
    <transition to="display hello world" />
  </start>
  <custom name="display hello world" class="be.jorambarrez...DisplayHelloWorld">
    <transition to="theEnd" />
  </custom>
  <end name="theEnd" />
</process>

… to start a process instance through the jBPM API:

public static void main(String[] args) {

ProcessEngine processEngine = new Configuration().buildProcessEngine();
RepositoryService repoService = processEngine.getRepositoryService();
ExecutionService executionService = processEngine.getExecutionService();

NewDeployment deployment = repo.createDeployment()
.addResourceFromClasspath("process.jpdl.xml");
deployment.deploy();
executionService.startProcessInstanceByKey("helloWorld");
 }

The debug log shows us the actual execution trace, where our ‘Hello World’ message is displayed between the engine logs.

17:53:15,219 FIN | [ProcessDefinitionImpl] creating new execution for process 'helloWorld'
17:53:15,224 FIN | [DefaultIdGenerator] generated execution id helloWorld.1
17:53:15,229 FIN | [ExecuteActivity] executing activity(25788693)
17:53:15,229 FIN | [ExecuteActivity] executing activity(display hello world)

Hello World!

17:53:15,230 FIN | [ExecuteActivity] executing activity(theEnd)
17:53:15,230 FIN | [ExecutionImpl] execution[helloWorld.1] ends with state ended

Upgrading in one minute

Suppose now that we take this process to production. Life is happy and peace. But then comes a new jBPM release. The developer hands start to itch again … So we take the jBPM 4.2 distribution and unzip it:

[jbarrez@jenova 4.2_upgrade]$ unzip jbpm-4.2.zip

And we change the dependencies of our little Hello World project, by either replacing the 4.1 jar with the 4.2 jar in the build path. Or if you are using Maven:

<dependency>
<groupId>org.jbpm.jbpm4</groupId>
<artifactId>jbpm-jpdl</artifactId>
<version>4.2</version>
</dependency>

<repositories>
<repository>
<id>jboss</id>
<url>http://repository.jboss.com/maven2</url>
</repository>
</repositories>

Of course, since we are adventurous developers, we don’t care about upgrading and just run our Hello World process with the new jBPM version. However, the new upgrade check will now kick in:

Exception in thread "main" org.jbpm.api.JbpmException: jBPM DB schema not in sync
 with library version: no JBPM4_PROPERTIES table.   Run the upgrade target
 first in the install tool.
 at org.jbpm.pvm.internal.cmd.CheckDbCmd.execute(CheckDbCmd.java:54)
 at org.jbpm.pvm.internal.svc.DefaultCommandService.execute(DefaultCommandService.java:42)
 at org.jbpm.pvm.internal.tx.StandardTransactionInterceptor.execute(StandardTransactionInterceptor.java:54)
 at org.jbpm.pvm.internal.svc.EnvironmentInterceptor.executeInNewEnvironment(EnvironmentInterceptor.java:53)
 at org.jbpm.pvm.internal.svc.EnvironmentInterceptor.execute(EnvironmentInterceptor.java:40)
 at org.jbpm.pvm.internal.svc.RetryInterceptor.execute(RetryInterceptor.java:55)
 at org.jbpm.pvm.internal.svc.SkipInterceptor.execute(SkipInterceptor.java:43)
 at org.jbpm.pvm.internal.cfg.ProcessEngineImpl.checkDb(ProcessEngineImpl.java:177)
 at org.jbpm.pvm.internal.cfg.ProcessEngineImpl.buildProcessEngine(ProcessEngineImpl.java:170)
 at org.jbpm.api.Configuration.buildProcessEngine(Configuration.java:140)
 at be.jorambarrez.jbpm4.upgrade.Main.main(Main.java:15)

As you can see in the stacktrace, during the creating of the jBPM ProcessEngine a check on the database schema will take place (tech detail: it uses the JBPM4_PROPERTIES table and some other checks to do this). And since the exception is thrown during ProcessEngine creation, this also stops us from executing processes in a old schema – which is a good thing.

So we follow the instructions of the exception above and run the upgrade script. Don’t forget to change the database properties (as we did above).

[jbarrez@jenova install]$ ant upgrade.jbpm.schema -Ddatabase=mysql
Buildfile: build.xml
 [echo] database......... mysql
 [echo] tx............... standalone
 [echo] mail.smtp.host... localhost

upgrade.jbpm.schema:
 [echo] upgrading jbpm schema...

 ... // *snip* Hibernate setup etc

 12:30:02,501 INF | [DbHelper] --- Executing DB Commands -------------------------
 12:30:02,501 INF | [DbHelper] create table JBPM4_PROPERTY (
 KEY_ varchar(255) not null,
 VERSION_ integer not null,
 VALUE_ varchar(255),
 primary key (KEY_)
 ) type=InnoDB
 12:30:02,544 INF | [DbHelper] --- Result: 0 --------------------------
 12:30:02,544 INF | [DbHelper] alter table JBPM4_HIST_DETAIL drop index IDX_HDETAIL_HACTI
 12:30:02,564 INF | [DbHelper] --- Result: 0 --------------------------
 12:30:02,564 INF | [DbHelper] alter table JBPM4_HIST_DETAIL drop index IDX_HDETAIL_HPROCI
 12:30:02,578 INF | [DbHelper] --- Result: 0 --------------------------
 12:30:02,578 INF | [DbHelper] alter table JBPM4_HIST_DETAIL drop index IDX_HDETAIL_HVAR
 12:30:02,595 INF | [DbHelper] --- Result: 0 --------------------------
 12:30:02,596 INF | [DbHelper] alter table JBPM4_HIST_DETAIL drop index IDX_HDETAIL_HTASK
 12:30:02,610 INF | [DbHelper] --- Result: 0 --------------------------
 12:30:02,611 INF | [DbHelper] create index IDX_HSUPERT_SUB on JBPM4_HIST_TASK (SUPERTASK_)
 12:30:02,625 INF | [DbHelper] --- Result: 0 --------------------------
 12:30:02,736 INF | [PropertyImpl] nextDbid is initialized to 4
 12:30:02,740 INF | [Upgrade] jBPM DB upgrade completed successfully. 
 12:30:02,740 INF | [SessionFactoryImpl] closing
 12:30:02,741 INF | [DriverManagerConnectionProvider] cleaning up connection pool: jdbc:mysql://localhost:3306/jbpm
BUILD SUCCESSFUL Total time: 4 seconds

The output of the script show us that some upgrades were done: a new table was created, some indexes were altered and some colum values were updated.

When we now retry running the Hello World process, everything works fine:

12:41:19,275 FIN | [DatabaseIdComposer] generated execution id helloWorld.10010
12:41:19,279 FIN | [ExecuteActivity] executing activity(28678425)
12:41:19,279 FIN | [ExecuteActivity] executing activity(display hello world)
12:41:19,280 FIN | [ExecuteActivity] executing activity(theEnd)
12:41:19,280 FIN | [ExecutionImpl] execution[helloWorld.10010] ends with state ended
Hello World!

And if you pay close attention to the logs, you’ll see that the schema check is OK now:

12:41:18,687 INF | [CheckDbCmd] jBPM version info: library[4.2], schema[4.2]

NOTE: if you got a grumpy DBA: the jBPM distro also ships with plain .sql files to use for upgrading the schema, which you can hand over to him/her.

Conclusion

And that’s it, folks. We’ve got API stability, backwards schema compatibility and as I just showed you, upgrading the database takes only a minute of your time… leaving more time for you to actually code business processes!

QA

To finish the post, I just want to show you a screenshot from our Hudson continuous integration job. Since the upgrade feature is extremely important for us, we test it against all our supported databases and JDK versions. The test job that is executed is actually very close related to the explanation of the previous section. With every new release, this configuration matrix will continue to grow. Which means that in every future release are certain of backwards compatibility and upgradeability.

Happy jBPM coding!

jBPM4 real-life example: The Train Ticket Demo (part 5: BI and BAM)

Business processes are never finished

As a business changes or grows, business processes will need to incorporate these changes or they will become a drawback for the business. There are the natural changes that come as the business or the market change, but some changes are related to the actual feedback that is received from measuring metrics about the business process executions.

If you take a look at the BPM lifecycle, gathering this feedback means that the process executions must be monitored. Using the metrics gathered there, it will be possible to discover bottlenecks in the process (eg some task is taking long due to a human resource problem) and to act upon them. The next step will then be optimizing the business process, with the new knowledge as background. Now, the lifecyle is completed and we’re back to modeling the actual changes in the process in our BPMN Signavio editor. So, as a developer, it might be interesting investing in jBPM, since your work will never be done (this applies certainly for contractors )

Traditionally, there are two concepts that are often used when one discusses ‘monitoring’ business processes. I’m talking here about Business Intelligence (BI) and Business Activity Monitoring (BAM). Typically, BI is used when the data that is used is historical (eg. monthly reports), whereas BAM is used when the data is real-time. Often, BAM is coupled with Complex Event Processing (CEP) to allow for automatic actions that are triggerd once a certain event or pattern is discovered. Yes, I know these are lot of fancy words, but they all come down to one thing: displaying data of business processes in some way or another.

In this article, I’ll demonstrate how BI and BAM can be done with jBPM. Today, I also have 2 screencast for you, so be sure to read the article to the end (which should be the case anyway )

Business intelligence with jBPM

I’ve already discussed this topic in a previous article, so I’ll be short here. Using the jBPM console, it is very easy to write your own BI reports and display it in the console. Since we are using the Eclipse BIRT engine, this means that the reports are also usable without the console or embedded within your own application. Take a look at the following screencast, where two things are shown:

• The cellhone emulator (aka the jBPM-phone) is used to send text messages to the Ticket Handling Platform and the jBPM console is used to inspect the actual process instances.
• The default BI report is rendered and displayed through the jBPM console.

Business activity monitoring with jBPM explained

For implementing BAM, we’ve used a setup as displayed in the following picture (click for bigger version):

Conceptually, the story goes as follows: inside the process, events (= pojos) are fired to a JSM queue. On this JMS queue, a message driven bean is parsing the events and handing them over to a CEP engine. In the demo, we are using the Esper engine, wrapped in an EJB3 such that the CEP handling scales with our existing architecture. Depending on the type of event, Esper will execute an action by invoking a so-called Subscriber. In our demo, this is mostly writing aggreagations to the database.

Note that this way of working is based upon the ideas from the book ‘Open Source SOA’, by Jeff Davis. Which also includes two big chapters about jBPM, by the way.

We’ll now look more closely into how this is actually done in Java code:

On certain activitites, we define an event listener. In the following example, we listen to the ‘end’ event of the ‘chargecustomer’ activity and send an event using the SendEventToQueue handler class. Also note that the event is send asynchronously, which means that the actual sending of the message is not done in the original thread. This way, the response towards the customer can be send more quickly.

<custom name="charge customer ...">
  <on event="end" continue="async">
    <event-listener>
      <field name="eventClass">
        <string value="org.jbpm.trainticketdemo.event.TicketSoldEvent"/>
      </field>
      ... (more fields, see source for details)
    </event-listener>
  </on>
  <transition to="end"/>
</custom>

The TicketSoldEvent that is fired here, is just a regular pojo:

public class TicketSoldEvent implements Serializable {

  private String from;

  private String to;

  private Double amount;

  // getters and setters

}

These events are received by a message driven bean and handed over to the Esper runtime engine (see line 17):

@MessageDriven(activationConfig =
{
 @ActivationConfigProperty(propertyName = "destinationType", propertyValue = "javax.jms.Queue"),
 @ActivationConfigProperty(propertyName="destination", propertyValue=JmsConstants.EVENT_QUEUE)
})
public class EventQueueProcessor implements MessageListener {

 // field declarations omitted

  public void onMessage(Message message) {

    try {
      if (message instanceof ObjectMessage) {

        ObjectMessage objMsg = (ObjectMessage) message;
        Object obj = objMsg.getObject();
        epsProvider.getEPRuntime().sendEvent(obj);

      }
    } catch (JMSException e) {
      LOGGER.error(e);
    }
 }
}

Without going into much details about Esper (read their excellent documentation if you are interested). We use Esper in the demo to cope with ‘pojo streams’. These pojo streams can be aggregated and queried upon using regular SQL, which I think is really cool:

EPStatement moneyTracking = admin.createEPL(
 "select count(*) as nrOfTickets, sum(amount) as total, " +
 "avg(amount) as average, stddev(amount) as stddev " +
 "from TicketSoldEvent.win:time(15 sec)");

 moneyTracking.setSubscriber(new MoneyTrackerSubscriber());

Note that we are selecting here the count, sum, average and standard deviation aggreagtion of the ticket sale data, based upon the TicketSoldEvent pojos that were received during the last 15 seconds. The results of that query are handed over to another pojo, the MoneyTrackerSubscriber, which will just store this results in the database for displaying them in the GUI.

Note that we are barely scratching the power of Esper here. It is for example also possible to join pojo streams, based on pojo field values. Take for example a look at the following snippet, where we join the TicketRequestReceived event with the QuoteSentEvent which have the same processInstance id, to calculate the time between receiving a cellphone text message and actually replying on it (which might be an SLA).

// SLA for the time between the ticket request receival and the quote sending
 EPStatement responseTimings = admin.createEPL(
 "select TicketRequestReceivedEvent.timestamp as ticketRcvTime, QuoteSentEvent.timestamp as quoteSentTime, " +
 "TicketRequestReceivedEvent.processInstanceId as processInstanceId " +
 "from TicketRequestReceivedEvent.win:time(24 hours) inner join QuoteSentEvent.win:time(24 hours) " +
 "on TicketRequestReceivedEvent.processInstanceId = QuoteSentEvent.processInstanceId");

But you can go much further with Esper. I particulary like the pattern detection mechanism for streams. I’ve used it in the past a lot, for example to build a fraud-detection system: when a certain pattern in the events is found (I believe it had to do with money that was first refused and than we checked on events that were related to the same customer trying to get smaller amount of money approved), an email would be send out to all the account managers involved. But such features are probably for a next iteration of the demo. By that time, we might be able to leverage the SAM solution which Heiko described in a blogpost.

Bam: The end result

The following screencast shows the end result of the explanation of the previous section. The data that is gathered by the subscribers of our events, are displayed using a Seam application, with Richfaces for the general GUI and Primefaces for the flash chart rendering. Using some ajax magic, the charts are rerendered in real-time.

The demo BAM application shows following information:

• The average and standard deviation time between receiving the text messga eand sending a response (SLA)
• The time it took the customer to respons with an ‘accept message’, shown as a pie chart with catagories (eg < 30 seconds)
• The number of customers who had enough money on their balance vs those who didn’t
• The total money earned (with average and stddev)  in the last 10 windows of 15 seconds

It is easy to see how the information from the BI reports and the BAM application can be used to enhance the business process. Eg when a lot of customers aren’t able to pay because they forgot to add money to their account, it could be wise to add a step to the process that ask ‘do you want to add more money?’, using the credit card registered with the customer. So, your imagination is the only limiting factor here

Like before, the source code can be found in our svn repo:

• The BAM Seam application, can be found on http://anonsvn.jboss.org/repos/jbpm/projects/demos/trainticket-demo/jbpm_on_rails_bam/trunk/
• All of the source code of the train ticket demo can be found at http://anonsvn.jboss.org/repos/jbpm/projects/demos/trainticket-demo/

jBPM4 real-life example: The Train Ticket Demo (part 4: the end application)

The path from a business process model towards an automated business process implementation is often a long one. After the initial process modeling in the Signavio editor, the initial development and prototyping, it is now time to start the actual development of our Train Ticket handling platform.

In reality, development will be mixed with additional discussions between IT and business, enhancements and changes in the BPMN process model and definitely some addtional prototyping will be needed. Here it may look like an easy transition between our prototype and our eventual and application, but do keep in mind that this phase is the one were most often future failures are born. It is of extreme importance to keep in mind that a business process is The Holiest of Holy of a given company. Therefore, business process implementations must be as close as possible to what the business expects, and this often takes time to synchronise all stakeholders involved.

In this article, I’ll present the implementation of the business process as described in the previous articles. The end result will be a high-performant, scalable (by means of clustering) train ticket handling platform, using standard Java EE components. This article will also show how easy it is to integrate jBPM with any given Java tech. As described in my previous article, let jBPM enrich your architecture!

Of course, as a open source project we have a reputation to keep up. All of what we discussed in the previous articles and this article is contained in the download at the bottom of this article. Many people have asked me for the executable demo and so here it finally is! Like I said before, don’t hesitate to show this demo to all the people you know!

Architecture Overview

The following picture shows a high-level overview of the architecture.

Most of it is probably clear by just looking at it, but I’ll summarize what’s going on here:

• The entrypoint to the application is a regular HTTP servlet. SMS gateways communicate between telecom operators using plain HTTP messages, so the choice for this technology is obvious.
• We have a cellphone emulator (swing rich client), aka the jBPM-Phone, at the left side. This cellphone runs on my local machine and it sends text messages to our Ticket Handling Platform using the same HTTP messages used by the SMS gateway. This way, we can test our logic, without actually paying for the text message transfer.
• The Servlet parses the incoming text messages and offers this to the TicketService, depending on the type of the message (a message that starts a new process, or one that triggers the task in a waiting process instance). See line 9 and 16.

protected void doPost(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {
  ...
  if (isTicketRequestMessage(msgContent)) {

    TicketRequest ticketRequest = parse(msgContent, sendDate, senderNr);

    if (ticketRequest != null) {

      ticketService.handleTicketRequest(ticketRequest);

    } else if (isTicketAcceptanceMessage(msgContent)) {

      String acceptanceId = parseTicketAcceptanceMessage(msgContent);
        if (acceptanceId != null) {

          ticketService.handleTicketAcceptance(acceptanceId, senderNr);

        } else {
          LOG.warn("SMS message content invalid. Throwing it away.");
        }

    }
}

• The TicketService is a stateless EJB3 service. The incoming message will be used to start a new process instance of our well-known ticket handling process (see previous articles if you haven’t the slighest clue). This means that the TicketService will actually call one of the jBPM API services, nothing more. Note how easy we have integrated jBPM with the EJB3. No magic involved: this is plain Java code, people. See line 16, 27 and 34 in particular.

@Remote(TicketService.class)
@Local(TicketService.class)
@Stateless
public class TicketServiceImpl implements TicketService {

  ... // field declarations

  public void handleTicketRequest(TicketRequest ticketRequest) {

    Map<String, Object> vars = new HashMap<String, Object>();

    vars.put(ProcessVariable.FROM, ticketRequest.getFrom());
    vars.put(ProcessVariable.TO, ticketRequest.getTo());
    vars.put(ProcessVariable.CELL_NR, ticketRequest.getCellPhoneNr());

    ProcessInstance processInstance = executionService.startProcessInstanceByKey(TICKET_PROCESS, vars);

    if (LOG.isInfoEnabled()) {
      LOG.info("Ticket Process with process instance id " + processInstance.getId() + " started");
    }
  }

  public void handleTicketAcceptance(String acceptId, String cellPhoneNr) {

    // Look up the task through the jBPM API

    Task task = taskService.createTaskQuery()
             .processInstanceId("ticketProcess." + acceptId)
             .assignee(cellPhoneNr)
             .uniqueResult();

    if (task!= null) {

      taskService.completeTask(task.getId());

      if (LOG.isInfoEnabled()) {
        LOG.info("Task " + task.getId() + " completed by " + cellPhoneNr);
      }
    }
  }

}

There are two important notes here:

• The TicketService is a regular service, nothing special there. Here I’ve chosen for an EJB3 approach, but you can well imagine this to be a Spring service, where the jBPM services are injected into the service. The important part here is that the ticketService is a plain service, just like any other (CRUD) service in the application. See my article on “where does jBPM fit into my architecture”.
• I’m using standard JEE components (servlet and EJB3), in a complete stateless way. This means that this architecture can scale up linearly with any given load (eg with a simple load balancer). Also note that the use of jBPM does not imply any limitation on scaling this architecture. jBPM is designed from scratch with concurrent executions in mind, and synchronisation is actually done at the database level. Every API call is self-contained, on which node in the cluster it is executed.

Notice that there is an additional component on the picture: the user registration app. This is a simple Seam application, that just allows for users to register their cellphone and add money to their account. For the moment, adding money is just filling in the form, but I’m sure you can imagine this to be done by MasterCard, or any other payment method.

Use The Source, Luke

If you want to just download the demo, then just scroll down to the next section. If you want to check out the source however, then these instructions are for you.

Check out the source for the Rich client emulator from our public svn repo:

svn co http://anonsvn.jboss.org/repos/jbpm/projects/demos/trainticket-demo/jbpm-phone/trunk/ jbpm-phone

Building the emulator is really easy, just do a standard maven build:

mvn clean install

The executable jar can be found in the target subfolder and is called jBPM-Phone-1.0.jar

Check out the source for the jbpm-on-rails platform from our svn repo:

svn co http://anonsvn.jboss.org/repos/jbpm/projects/demos/trainticket-demo/jbpm-on-rails/trunk/ jbpm-on-rails

The project is structured as a Maven-multiple-module with the following modules:

• domain: contains the simple domain model of the ticket handling application: a TicketRequest, a User and a Quote
• jboss-integration: contains some classes that are used to integrate easily with the JBoss AS, like binding the ProcessEngine to JNDI.
• process-logic: this module has the most interesting classes. Here you’ll find the custom activities, Decision handler, event listeners, etc.
• ejb: EJB module which contains the TicketService implementation as described above. Also contains the QuoteService EJB3, which emulates the external service shown in the architectural overview.
• war: contains the described servlet that handles incoming text messages from customers
• ear: wraps the ejb jar and the war in an ear that is deployable on the JBoss AS.

Building the project is done by just doing a standard maven build

mvn clean install

The resulting ear can be found under /ear/target. This ear is tested on a JBoss AS 4.2.3. I’m using some JBoss-specific extensions, so don’t expect it to run on other containers.

Download the demo

The complete application: a JBoss server (4.2.3) with the user registration app and the ticket handling application, together with the Rich client emulator can be downloaded here (+- 237 MB).

Follow these steps:

• (this is the most intensive step) Go to $UNZIPPED_FOLDER/jboss-4.2.3.GA/server/default/deploy open up the jbpmeditor.war file with any zip utility and open the web.xml file. Look for the fileSystemRootDirectory and change the value to an existing foler on your own hard disk. Currently, the value is set to /home/jbarrez/Desktop/signavio-repository. Take care that the web.xml file is actually rewritten in the zip file (not all tools can do this).
• go to $UNZIPPED_FOLDER/jboss-4.2.3.GA/bin and start up the JBoss server (./run.sh on linux)
• go to $UNZIPPED_FOLDER/ and execute the jar: java -jar jBPM-Phone-1.0.jar
• open your browser and go to http://localhost:8080/user_registration. You can log in with the emulator userid using 123456789/password and add some money to the emulator’s account.
• Play around with the emulator. A ticket request is sent by typing ‘TICKET CITYA CITYB’.

Screencast

You can see how all this looks in reality by viewing the following screencast. In the movie, you’ll see how to use the emulator (aka the jBPM-phone), how to add some money to the emulator’s balance and how the ticket handling server communicates nicely with the jBPM-phone. All of what you see in this movie, can be done by yourself by downloading the demo!

Enjoy!

jBPM4 real-life example: The Train Ticket Demo (part 3: prototyping with the jBPM console)

Business processes are hard to get right from the first try. This is logical, since business processes are hard coded in the mind of the business people and pouring all this knowledge into a model is hard. So typically, it takes some iterations through the BPM lifecyle until a process model is derived that somewhat matches with what the business actually is doing.

So where are we now in the Train Ticket story? We’ve modeled our process and we added business-specific logic to the business process. We’re still in the development phase, according to the BPM lifecycle.  But in these days, nobody will ever rush into development straight away at this point. Agility is all the buzz nowadays, and there is no reason why it shouldn’t be.

In this article I’ll show how you can leverage the jBPM console to  build a prototype of the final application. Of course, the jBPM console can do  a whole lot more than prototyping (like basic process governance, reporting, etc), we’ll come back to these topics later. For this article, we’ll only highlight the prototyping capabilitites of the jBPM console.

Using the taskform functionality of the jBPM console, it is very easy to emulate user input and output without investing a lot of valuable development time. The use of these taskforms will allow you to show the interaction with the business process from the viewpoint of the end-user. It enables discussions between business and development, without actually building a complete application from scratch.

Agility in its purest form, who doesn’t love that?

Enriching the business process with taskforms

In a previous article, I already explained how to add a taskform to a business process. A task form is a HTML form which we can specify in the JPDL process definition, that captures the I/O towards and from the end-user. We’ll do the same here for the train ticket process, which is shown here again as reference:

There are 2 points of input/output in the process:

• The process is started when a cellphone text message is arrived. This text message contains the start and destination train stations.
• Once a price quote for the itinerary is calculated and the credit balance of the customer is verified, a text message is sent back with the price quote. An acceptance task is created for the customer. When the customer sends an acceptance message back, the process is continued by completing the task.

Whenever a process instance is started through the jBPM console, the ’start’ activity is checked to have a start form. This form will be displayed before starting a process instance and the input variables of the form will be stored in the process instance so they can be used later on.

To attach a start form to a process definition, the start activity must be enhanced with a form attribute:

<start form="org/jbpm/trainticketdemo/trainticket_startform.ftl" g="11,105,48,48" name="start">
  <transition to="Calculate quote"/>
</start>

As shown in this snippet, the form is stored as a .ftl file somewhere in the project package tree. This file contains a basic HTML form and input text fields. Remember, the values of these input fields are later used as process variables.

<html>
  <body>
    <form action="${form.action}" method="POST" enctype="multipart/form-data">
      <h3>Send SMS:</h3>
      <table>
        <tr>
          <td>From:</td>
          <td><input type="text" name="from" /></td>
        </tr>
        <tr>
          <td>To:</td>
          <td><input type="text" name="to" /></td>
        </tr>
        <tr>
          <td>Source cellphone nr:</td>
          <td><input type="text" name="cellPhoneNr" value="" /></td>
        </tr>
      </table>
      <input type="submit" name="Send"/>
    </form>
  </body>
</html>

Filling in this form will store the from, to and cellPhoneNr variable in the process instance as a process variable.

Adding a taskform to the ‘accept quote’ task is done in exactly the same way:

<task assignee="#{cellPhoneNr}" form="org/jbpm/trainticketdemo/accept_quote.ftl" ... 

In our final application, a text message will be sent to the customer before arriving in the acceptance task. In the jBPM console, we can emulate this behavior by using the taskform to display process information. Note the usage of expressions ${} to output process variables in the html taskform.

<html>
  <body>
    <form action="${form.action}" method="POST" enctype="multipart/form-data">
      <h3>Accept Quote:</h3>
      <table>
        <tr>
          <td>From:</td>
          <td>${from}</td>
        </tr>
        <tr>
          <td>To:</td>
          <td>${to}</td>
        </tr>
        <tr>
          <td>Price:</td>
          <td><b>${quote.price}</b></td>
        </tr>
      </table>
      <input type="submit" name="Accept"/>
    </form>
  </body>
</html>

Taskforms in action

That’s all there is to it. Just enrich your JPDL process definitions with some taskforms and deploy them to the jBPM database. Don’t forget to add them to the deployment next to the process definition xml by calling the deployment.addResourceFromClasspath(“org/jbpm/…”) operation.

The following screencast shows the end result of this iteration: a protoype of the application using the jBPM console and the taskform functionality.

What’s next?

In the next article, we’ll finally be able to build the real application.

Stay tuned!

(j)BPM: where does it fit architecturally?

“How does jBPM fit into my architecture?“

This question pops up regularly in my mailbox or on the jBPM user forum. Even when I was still a jBPM consultant, this question was the first line new customers asked me.

But there is no ‘all-in-one’ answer to this question. Like many answers in IT, the real answer is ‘it depends’. It depends on which frameworks you selected already. It depends on the expected load of the business processes. It depends on the existing systems which need to be accessed in the process. It depends if you want to centralize BPM knowledge in one application or not. And so on and so on …

jBPM is extremely flexible since our key feature is being embeddable in any Java technology out there. Pick your favorite framework, and I’m sure there is a way to fit in jBPM. But it’s the very same embeddability that often causes people architectural headaches. Mis- or underinformed people often want to take the easy path, and big BPM vendors know this.

A well-dressed sales guy will give a smooth presentation with colorful charts and he will promise you heaven and more. Of course, before acquiring the BPM system, you must first put (a lot of) cash on the table. That’s the way the world turns, right? And what are you getting: a big black-box server. You can send requests to it and it magically gives you the answer (hopefully it is the right one), hence the developer in the picture below that is painting on his screen. Paintings tend to look good from a distance, but you know that once you get close it tends to get blurry.

Big black-box servers don’t give you architectural headaches. No, on the contrary: they define how your architecture should look…

It could be me, but I like to keep things under control. I like to see what’s happening in my architecture, how it all fits together and which systems are communicating with each othe.. You know, that warm, fuzzy feeling you get once your own designed architecture keeps up with every load you throw at it. jBPM just gives you that openness en flexibility you need to build an architecture suited for your business, without having to suit your business to an architecture implied by a big black-box system.

Since jBPM is at its core just a simple Java library, there is no limitation on how you want to include it into your architecture. I’ll list a few of them here, but remember that jBPM will never be the limiting factor when designing your architecture. However, I do have my own ideas and experience. So, there is a definition I tend to use when people ask me about jBPM and architectures:

A business process *is* a part of the domain model, so ideally BPM should be non-intrusive and integratable with *every* architecture and technology. So let me reverse the question now: how does your domain model fit into your architecture?

Many people don’t see a business process as part of the domain model (remember my black-box story …), but it makes a lot of sense if you think about it. What is a domain model? Well, it is a representation of your business domain, of the raison d’être of your business of company. What is a business process? Well … it is a representation of how your business does something to create value. It is a representation of domain objects communication in some fixed way (a ‘flow’) to create some business-specific value.

So what does this mean in practice? It means that concepts like a Task (eg ’send inquiry’), a Process Instance (a ticket sale) or an actor are at the same conceptual level as the domain model. Do note it doesn’t mean to scatter around your logic (like custom activitities, service invocations, etc.). Best practices in architecture design do still apply, and even more with jBPM (since they are applicable without restriction).

So by now I hope you can understand why we at jBPM don’t like the black-box-magical-server approach. A domain model is often scattered around many architectural layers or applications. Nobody asks questions when a domain object tends to be used accross different layers, and it is the same for the business process. If it makes sense in your architecture to not centralize a business process, then do it. It will make your architecture more understandable and easier.

Like I said, this means you can use jBPM in a lot of architectural styles:

• In some designs, a BPM layer is placed either above a service layer – I like to call this a scenario layer
• jBPM code is often wrapped the same way as a DAO (where I most of the times use the term PAO (Process Access Object). Services make calls to the PAO’s, just like they are accessing domain objects through the DAO’s. In a Spring environment, this is a true and tested approach.
• Or you could build a big centralized server that does only BPM operations. This looks very much like the black-box servers I mentioned before. In some architectures this makes sense (eg tax processing split over several clusters), but you now don’t get a black-box server, but an open system that shows you all its internals. No magic involved. If you want to wrap it in WS-*, REST or whatever gets you going, fine. You don’t get that kind of choice with typical BPM products.
• …

I’m sure that if you searched our user forum, you could triple this list in a few minutes.

Conclusion

This article is a bit of a side track in my current ‘jBPM4 real-life example: The Train Ticket Demo’ saga, but you’ll see that my ideas of this article are applied in the eventual Train Ticket Application (ie ‘jBPM on Rails’). Architecture designs tend to get a lot simpler if you look at BPM as part of the business domain. And jBPM just gives you that kind of control: flexibility and embeddability in any Java technlogy.

So, let BPM enrich your architecture, not cripple it.Use jBPM and free your architecture today!

jBPM 4 real-life example: The Train Ticket Demo (part 1: modeling the process with BPMN)

For many technical people, the choice for jBPM is a no-brainer. But more than often framework or product decisions are not made by the tech audience, but by managers, project leads, etc. In most cases  these people have other criteria than mere technical advantages. Sadly, this can lead to a choice for products which are not developer-friendly and are not appealing to the dev crowd. The goal of the article is to demonstrate that jBPM can offer anything you’d expect from a typical BPM product(read: big vendor BPM black-boxes products) and much more, of course .

This article is the first in a series of articles (probably five or six parts) in which I’ll show that jBPM has all the shiny features for both developers and non-technical people. We’ll start from the very beginning (modeling a process), do unit testing, prototyping, BAM, BI and in the end we’ve built ourselves a scalable, high-performant application that could go straight into production. The goal of the article is to show to both sides of the playground that jBPM not only offers shiny development features, but also that it can be used to build any BPM-driven application out there. With all the features that non-technical people adore.

Tom Baeyens smoke tested the demo application in his talk on JBoss World. He received a lot of positive feedback there, and we appreciate any feedback on this and the next articles. All the source code will be put online with the articles, so don’t hesitate to show it to all your co-workers or to convince your managers

The business process explained

Picture this: it’s a rainy work-Monday-morning and somehow the wake-up alarm didn’t go off. You’re barely arrive in time in the train station and you remember you don’t have a train ticket. You could go and buy one at the automatic vending machines, but looking at the crowd there, you just know that you’ll never be able to catch your train. You also could look for the train conductor and buy a ticket from him, but often the tickets costs way more than when you buy it upfront. A last option is to not buy a ticket, and look around anxiously every time you hear someone coming, fearing it is someone official checking the tickets. …. Ah choices, choices, choices ….  it feels like it’s going to be a long long week!

The problem here is that the ways of buying a train ticket is just soooo old-fashioned and not well-suited for this fast-moving world. The business process we’ll be using throughout the articles solves this problem. More precisely, we’ll model and develop a jBPM process that will handle for us a train ticket sale, using only a cellphone! So even if you are running late, just sending a text message will get you a valid ticket.

Note that we’ve named our ticket sale handling platform  ‘jBPM on Rails’, since it seems fancy today to add the ‘rails’ suffix

The business process is graphically shown below (click for a bigger version). Most of it will be described in detail in a next article, but here’s a short summary

• The business process is started when a ticket request is received from a cellphone
• Using the start and end train stations used in the ticket request text message, a price quote will be calculated. The calculation of price quotes is something that already is implemented by the train operator, so we’ll call an external service to actually get the quote.
• If the customer associated with the cellphone has not enough credit on his/her balance, a rejection message is send.
• If the credit is OK, the quote is sent to the customer.
• An ‘accept task’ will now be automatically created.
• The customer can complete this task by sending an acceptance text message.
• Finally the customer is billed and the process finishes. The customer now has a valid ticket.

Modeling for and by the business

The story of every business process starts with the creation of the business process diagram. Often this is done by domain experts (business analysts),  but this could be anyone in reality (I’ve seen developers doing the modeling … but this doesn’t mean I agree with it ). Creating a business process takes time. It involves communication with business end-users, other businesses which are interacted with, stakeholders of a company, etc. Typically, the process that you model today will not look anyhting like the same process, next year.

The jBPM 4 platform just offers you this kind of tool. Through our close collaboration with Signavio, modeling a process has never been easier. The Signavio web editor is shipped with the jBPM distribution (since jBPM 4.1) and can be installed in on a web server in less than a minute.

The following screencast shows the creation of the Train Ticket business process by a business analyst. You can see that process modelers only need a web browser to start modeling the process. The Signavio editor uses the widespread BPMN notation, which is known by virtually every business analyst out there. People can collaborate easily on the same process through the browser. The BPMN diagram is eventually saved on the hard disk in the native jBPM JPDL file format, which can be imported into the jBPM Graphical Process Designer  (GPD).

What’s next

In the next article, we’ll cover the next phase of the BPM lifecycle: development. We’ll use the process definition produced by the Signavio editor and enhance it with Java logic in Eclipse and the GPD. We’ll show how easy it is to test business processes in plain Java unit tests and how easy jBPM embeds with any Java technology.

Stay tuned for more!

Related

jun 09: jBPM goes web-based modeling

aug 09: Web-based BPMN modeling with jBPM and Signavio

Signavio website

Custom Business Intelligence reporting with jBPM4 (‘What’s new’ part 5)

People who have tried the new jBPM4 web console will have noticed that there is a ‘reporting’ tab which renders two reports that are shipped with the jBPM4 distribution.

But few people know that these reports are in fact completely customizeable. We have deliberately included only a few reports in the distribution, because we believe that no business process report is valuable without custom business domain data. Using the Eclipse BIRT tooling, it is possible to take a look at the report templates we ship in the distribution. These reports can then be easily customized or completely new reports can be created.

Don’t be overwhelmed by the features of BIRT when you try it out the first time, BIRT has some excellent tutorials which will get you going quickly. Once you tasted the power of BIRT, you’ll be creating hi-quality reports in no time! After all, it’s not a coincidence that BIRT is an industry-leading tool for reporting.

In the upcoming jBPM 4.1 release we have included 2 new sample report templates. One report is actually used in the 4.1 console and the other one serves as an example of a report with a custom input form. Once JBPM-2453 is fixed, the second template will also be included in the distribution (probably jBPM 4.2).

Click on the picture below to see a very small demo of the new jBPM4 report templates which are shown in Eclipse BIRT and in the jBPM web console. The demo also shows that starting some new process instances will change the report generated by the console.

Enjoy!