Tuesday, November 9, 2010

As part of the bi-weekly JBoss Developer Webinar Series, I will be giving a presentation on jBPM5 next week Wednesday, November 17, 12:00 PM EST / 17:00 GMT.

This presentation will be suited both for people that are not really familiar with jBPM but would like to get an introduction what it is all about as well as for people that have experience with previous versions of the project and would like to know what's new. With the possibility to ask your questions afterwards of course.

I will also touch on how jBPM5 is tackling exciting hot topics like case management, event-driven BPM, etc.

Monday, November 8, 2010

In a recent webinar from Active Endpoints called "Should you bet on jBPM?", Michael Rowley described the findings of his evaluation of jBPM. This includes what he believes jBPM is good at and what it is bad at, relation to standards, etc. It's always a good thing if competitors think they need to do a comparison, right? ;)

Unfortunately, he decided to evaluate jBPM v3. Fair enough, jBPM5 isn't out yet, so selecting jBPM3 probably made sense. But luckily, a lot of the "issues" he has with jBPM3 have already been improved significantly in jBPM5! For those that might have seen the presentation and are wondering what is still applicable for jBPM5, some highlights ...

StandardsjBPM5 is using existing standards wherever possible. BPMN2 is used for process definitions (both at the graphical level as well as the underlying XML). This means that concepts like exception handling, event signaling etc. are all offered using the concepts as defined in the specification (which were agreed upon as the best possible solution to represent these concepts by many experts in the working group). But it's not just BPMN2, but also WS-HT for human tasks (see below), JPA / JTA for persistence and transactions, etc., as we believe the use of these standards only brings benefits to our users.

Human tasksInstead of having an embedded, proprietary human task solution, the new human task service is an independent service based on the WS-HumanTask specification, and allow more advanced features like escalation, reassignment, etc.

Low-level detailsWe try to hide low-level implementation details from the end user as much as possible. For example, there's no more concept of a "token" that the user needs to know. Also, we strongly encourage users to keep implementation details out of their process definitions. No more low-level Java integration code is needed inside your process (or handlers) to link to external services, this all can be handled as domain-specific extensions. The use of code inside a process should be limited to simply expressions / actions.

XML editingWhile people are allowed to edit the underlying XML (used for storing process definitions) themselves, this is not are recommended approach and users should not be forced into doing that. There are property panels, but more importantly, there are user-friendly editors that pop up when double-clicking specific nodes (and yes, you can contribute your own!). For example, a screenshot of how you could specify the details when you need to send an email below.

Service OrchestrationIt is true to say that jBPM is (currently) more focused on a Java environment. This doesn't mean you can't do web service invocations, but if all you're currently interested in is web service orchestration, you might find the default support for process interface generation, correlation and XML data handling a little bit limited. We'll be working on improving that after jBPM 5.0, but luckily JBoss has another project called RiftSaw which does exactly that: offer web service orchestration using WS-BPEL execution based on the Apache ODE engine. Both projects share a few components already and we're working on a combined long-term strategy, but definitely take a look there as well if you need pure service orchestration.

Tuesday, October 26, 2010

Case management was one of the recurring themes last week at the Business Process Forum. There definitely seems to be a growing need amongst end users for more flexible and adaptive business processes, without ending up with overly complex solutions. Everyone seems to agree that using a process-centric approach only in many cases leads to complex solutions that are hard to maintain. The "knowledge workers" no longer want to be locked into rigid processes but wants to have the power and flexibility to regain more control over the process themselves.

The term case management is often used in that context. I'm not going to try and give a precise definition of what it might or might not mean [1,2], but it refers to the basic idea that many applications in the real world cannot really be described completely from start to finish (including all possible paths, deviations, exceptions, etc.). Case management takes a different approach: instead of trying to model what should happen from start to finish, let's give the end user the flexibility to decide what should happen at runtime. In its most extreme form for example, case management doesn't even require any process definition at all. Whenever a new case comes in, the end user can decide what to do next based on all the case data.

A typical example can be found in healthcare (clinical decision support to be more precise), where care plans can be used to describe how patients should be treated in specific circumstances, but people like general practitioners still need to have the flexibility to add additional steps and deviate from the proposed plan, as each case is unique. And there are similar examples in claim management, helpdesk support, etc.

So, should we just throw away our BPM system then? I don't think so! Even at its most extreme form (where we don't model any process up front), you still need a lot of the other features a BPM system (usually) provides: there still is a clear need for audit logs, monitoring, coordinating various services, human interaction (e.g. using task forms), analysis, etc. And, more importantly, many cases are somewhere in between, or might even evolve from case management to more structured business process over time (when we for example try to extract common approaches from many cases). If we can offer flexibility as part of our processes, can't we let the users decide how and where they would like to apply it?

Let me give you two examples that show how you can add more and more flexibility to your processes. The first example shows a care plan that shows the tasks that should be performed when a patient has high blood pressure. While a large part of the process is still well-structured, the general practitioner can decide himself which tasks should be performed as part of the sub-process. And he also has the ability to add new tasks during that period, tasks that were not defined as part of the process, or repeat tasks multiple times, etc. The process uses an ad-hoc sub-process to model this kind of flexibility, possibly augmented with rules or event processing to help in deciding which fragments to execute.

The second example actually goes a lot further than that. In this example, an internet provider could define how cases about internet connectivity problems will be handled by the internet provider. There are a number of actions the case worker can select from, but those are simply small process fragments. The case worker is responsible for selecting what to do next and can even add new tasks dynamically. As you can see, there is not process from start to finish anymore, but the user is responsible for selecting which process fragments to execute.

And in its most extreme form, we even allow you to create case instances without a process definition, where what needs to be performed is selected purely at runtime. This however doesn't mean you can't figure out anymore what 's actually happening. For example, meetings can be very adhoc and dynamic, but we usually want a log of what was actually discussed. The following screenshot shows how our regular audit view can still be used in this case, and the end user could then for example get a lot more info about what actually happened by looking at the data associated with each of those steps. And maybe, over time, we can even automate part of that by using a semi-structured process.

Monday, October 18, 2010

jBPM5 introduces a new language for representing process definitions based on the BPMN 2.0 specification, replacing older (proprietary) formats like jPDL or RuleFlow. Because not everyone might be familiar with this specification, let me give you some background. [The BPMN 2.0 specification has been finalized for some time now, but still needs to go through the final steps of the administrative process. Nevertheless, the contents of the specification seems to be stable and ready to be used.]

What is BPMN 2.0?

"The primary goal of BPMN is to provide a notation that is readily understandable by all business users, from the business analysts that create the initial drafts of the processes, to the technical developers responsible for implementing the technology that will perform those processes, and finally, to the business people who will manage and monitor those processes."

The second version of the Business Process Model and Notation specification (BPMN 2.0) by OMG not only defines a standard on how to graphically represent a business process (like BPMN 1.x), but now also includes execution semantics for the elements defined, and an XML format on how to store (and share) process definitions.

For example, a very simple process that would write out "Hello World" when it is started would look something like this (both visual and using XML):

The BPMN2 specification contains an explanation of how to represent executable business processes, both visually and syntactically, by combining a large set of different node types (and related elements). jBPM5 supports most of the "Common Executable" subset of the BPMN2 specification (containing the most common node types and attributes for specifying executable business processes) and already a few more node types. The documentation gives a detailed overview of which elements an attributes exactly.

To get started, the BPMN2 specification obviously serves as the reference, but additional to that, the jbpm-bpmn2 module contains a lot of junit tests for each of the currently supported node types. These test processes can also serve as simple examples: they don't really represent an entire real life business processes but can definitely be used to show how specific features can be used. For example, the following figures shows the flow chart of a few of those examples. The entire list can be found here.

Tuesday, October 5, 2010

We've been talking about it for a while now, and working on it even longer, but we believe the time has come to just get the jBPM5 code out there and start asking for community feedback and assistance.

The current jBPM5 snapshot offers open-source business process execution and management, including

Monday, September 6, 2010

After the first success at Boston, JUDCon, the conference for and by JBoss users and developers, is coming to Berlin on October 7-8. This time, there is a special track on Workflow and BPM on day 1. So hopefully there will be a lot of interesting presentations on Drools Flow / jBPM. The call for papers is still open (until September 13), so hurry is you want to submit a session. So if you are or want to become part of the community, don't hesitate!

Tuesday, May 25, 2010

A while ago, we presented a request for comments on jBPM5, where we asked you, our community, to provide feedback on the vision, architecture and key features for (the next version of) the jBPM project. We would like to thank anyone who participated in the discussion and provided feedback or suggested additional requirements.

Based on these requirements we would like to present a proposal for what we would like to include in the first release of jBPM5. While we have not yet pinpointed an exact date for this release (but we will do this asap, stay tuned), we are planning to release this near the end of the year (preferably a few months before even). As many people have requested, this release will focus on delivering a solid core and simple tooling, while additional (more advanced) features will be rolled out in the subsequent releases.

More details on the roadmap can be found here. Disclaimer: this is currently still a proposal, so the content might still change (slightly), but we're planning to put out a confirmed roadmap as soon as possible.

By the way, don't fear that we're only getting started now. A lot has been implemented already, building on top of jBPM4 and Drools Flow. Don't worry, we're not building from scratch. And if you'd like to help a hand, you're more than welcome to drop a note on the mailing list as well.

I'll be doing a one-hour presentation "Looking forward to the future of (j)BPM" on the next JBoss User Group Belgium next week (Thursday, 3rd of June). Things are rapidly changing nowadays, so if you're in the vicinity and might be interested in we're doing regarding BPM in general, and jBPM5 in particular, don't hesitate to register as the seats are limited!

About Me

Kris is a Senior Principal Software Engineer at JBoss, by Red Hat, where he leads the jBPM project (an open-source business process management (BPM) suite), and is also part of the Drools project (an open-source Java rules engine). The jBPM project consists of a lightweight workflow engine in Java that support native BPMN 2.0 execution and various tools and features around that to support business processes throughout their entire life cycle.

Kris did a PhD in Computer Science at the Katholieke Universiteit
Leuven, Belgium. His main research area is policy-based management,
i.e. using declarative policy rules for configuring services, resulting
in highly-configurable, reusable services. He has experience and a
great intrest in policy-based and rule-based systems, workflow
management, service-oriented software development and clinical decision
support.

In his spare time, Kris also does athletics (ROBA) and plays volleybal (Berg Op Wijgmaal, Heren2).