Category: BPMN

Combining Activiti and Camel?

It seems that that ServiceMix/Camel and Activiti are growing together as you can read in the blog post Supersize Activiti with Mule ESB and Apache Camel and Deploy Activiti as OSGi Bundles

Activiti has its roots in business process management, whereas Camel comes from the area of enterprise integration. Both allow to describe and automate processes. Activiti uses BPMN, a graphical modeling language with an XML representation for persistence and execution. Camel uses a textual DSL which can also be expressed in XML. Grahpical modeling is also possible with the Fuse IDE.

BPMN example:

BPMN process
BPMN process

The BPMN XML representation is not intended to be written directly and can be hard to read.

Camel example:

from("file://start")
.choice()
  .when(header("goldCustomer").isEqualTo("true"))
    .to("bean:processor?method=grantDiscount")
    .to("direct:out")
  .otherwise()
    .to("direct:out");

from("direct:out")
.to("file://end");

Basically both examples are identical. The Camel example is more explicit and shows more technical details which are hidden in the BPMN example.

Especially non technical users tend to think that a graphical process notation is easier to understand because it looks better. It might be true for simple processes like the one above. But for more complex processes textual DSLs are often easier to write and understand.

Activiti and Camel overlap in many areas. Does it make sense to use them side by side anyway? I think yes, because neither Activiti nor Camel is complete in terms of features required by a fully featured SOA/BPM runtime. Actually they complement each other very well in some areas.

Unique features added by Camel:

  • Connectivity / Adaptors to connect to external systems using a variety of different protocols 
  • Predefined EIP patterns for message routing

Unique features added by Activiti:

  • Support for long running stateful processes
  • Human workflow integration

In order to avoid unnecessary complexity it helps to recall the difference between mediation- and business processes which I descibed in my blog post from 2006.

For mediation processes Camel is appropriate in most cases, even long running processes can be executed as long as they are stateless. But if you need long running stateful processes and human interaction Activiti is an interesting option. 

Both Camel and Activiti processes can be modeled using prescriptive and analytical BPMN. The software designer has the responsibility to decide which technology is appropriate for implementing the process. If this is not done right you will end up with unnecessary complexity, limited agility and maintainability.

It would be ideal to have an Open Source SOA/BPM Platform that enables end to end process automation without technology boundaries. As long as this is not available, combining Activiti and Camel is an interesting option. Proper solution design and differentiation of process types is key to create sustainable solutions.

Polyglot Workflows with Activiti and Silverlight

My latest article Polyglot Workflows with Activiti and Silverlight has been published in the current issue of JavaSPEKTRUM. After losts of  theory in form of articles and conference sessions, I thought it would be a good idea to present a real example.  The Activiti engine is an interesting product in the area of BPM. If you go beyond simple demo applications you might want to integrate it with existing UIs, such as corporate portals. Silverlight is an interesting candidate for this task. The article focuses mainly on the interoperability aspects of Activiti and Silverlight and shows how easy it is to bring both together.

New Silverlight BPMN Tool

The IYOPRO Process Modeler is SaS solution to model business processes over the internet. While several tools like this are avaliable, this one is especially interesting as it combines BPMN and Silverlight, a strong modeling standard and a powerful RIA technology. It looks and feels like a desktop application and is fun to play with.
In some areas it is limited (e.g. no export) but it is worth to try and see how it evolves in the future.
What I like is the capability to visually simulate processes and the timeline view. This can give you insights about the process flow at runtime.

Executable BPMN for Business Analysts?

People asking for the differences between BPMN and BPEL they often hear BPMN is graph oriented whereas BPEL is block oriented. But what does that actually mean and why is it important?

Block orientation means that there is no way back in the process like a goto statement. In BPEL a common workaround is to use loops to move backwards in a process. But this approach is cumbersome and creates non intuitive models. Block orientation feels natural for developers as it is how programming languages such as Java or C# work.

For business people this feels odd, cause it is not how they perceive processes in their daily business.
Business people regularly need a way to say “Oh wait, there is a problem in step X, let’s go back to step A and fix it.”.

Graph orientation means that the process can flow between tasks even backwards. In terms of Business/IT aligment graph orientation is a clear advantage as it is closer to how people think and work.

Because BPMN is graph oriented it is way better suited for business analysts than BPEL. Does that mean that with BPMN business people can create executable processes? In theory yes! And in reality?

As long as the BPMN model is purely prescriptive, people can freely connect tasks in all directions (more or less). But if the aim is to create executable process models, the BPMN semantics come into play. Although your modeling tool might allow to create all kind of links, process engines are very strict in what they can do. An executable model is like source code and as such follows strict rules.

Let’s create a simple example:

For an analyst this might look like a perfectly modeled process. The problem is that it ignores the BPMN semantics. Neither the modeling tool (Signavio) nor the process engine (Activity) complains, but at runtime the process runs into a deadlock situation. Why that?
The parallel gateway used to join the process after the execution of Task 1 and Task 2 expects two tokens. On the first run it gets two tokens and everyting is fine. If the completed gateway continues with Task 2 on the second run, the joining gateway receives only one token and the process is on hold cause the second token never arrives.

Conclusion:
If the aim is process automation, it is essential that the process strictly adheres to the BPMN semantics.
For most business oriented people (at least the ones that I know) this is new completely new terrain.

Activiti and the Open Source Reference Platform

Now that Activity published the first release (version 5.0) of their Open Source BPMN 2.0 engine and toolset, it was time to integrate it in our Open Source Reference Platform for SOA (OSRP).

Despite some initial weaknesses, such as BPMN error handling, Actitivi is very promising if you are looking for a lightweight, Open Source BPM engine. Especially the features in the areas IT/Business collaboration and human task  integration are worth a closer look. The modularity makes it easy to integrate the engine with other products.

Using the OSRP one can now compare the BPMN and BPEL approaches to BPM, understand how Activiti can be combined with other Open Source SOA technologies such as Apache ServiceMix ESB, and learn about the strenghts and limitations of the product.

Three challenges of BPMN 2.0

There are three major challenges in using BPMN 2.0 as a holistic (360°) approach to Business Process Management (BPM):

  1. Semantic Alignment
    BPMN like all other high-level process languages is context agnostic. This is good, as it allows a wide adoption throughout the industry. On the other hand it means that it does not explicitly express concepts found in business contexts, such as customer, accounts, discounts etc. As people from business and IT often have a very different view on certain business aspects, it is essential that they share the same semantic context in order to understand each other. If not, a process designed by a business person will not be understandable by an IT person and vice versa. In case BPMN is applied in combination with an outsourcing approach things get even worse.
  2. Level of Details
    BPMN2.0 is designed for automatic execution on a process engine. The goal is to have one process model from analysis to execution. But people from business and IT require different very levels of detail in their process descriptions. This is why a processes created by business people are usually not detailed enough for IT people. IT processes are usually full of technical information required for automation, rendering the process almost useless for business people.
  3. Portability
    The BPMN standard introduces several conformance levels (modeling, execution, BPEL, choreography). This is good as it fosters reusability of BPMN diagrams amongst different tools. At the same time the standard explicitly allows model extensions, “to satisfy a specific need, such as the unique requirements of a vertical domain” (quote from the spec). Thus, to avoid vendor lock-in, one at least has to be very careful in choosing the right model elements.

BPMN 2.0 should not be applied naively. Unfortunately this is often happens, especially when the standards are young. To be successful with BPMN 2.0 one has to find the right mixture of standards, design principles and methods.
For instance the semantic aligment problem can be mitigated by applying Scrum for analysis and process development. A multi-layer process design can help to address the level of detail problem. And choosing the the right product can increase portability.
This is nothing that comes for free by just using BPMN 2.0. It is rather something that needs to be actively managed by experienced engineers.

Goto is not Evil

Those of you who tried to convert BPMN to BPEL know the “Goto”-Problem which stems from the fact that BPMN is graph oriented while BPEL is block oriented.
This makes it hard to transform one into the other and causes pain in todays BPMN undertakings.
Although goto is banned in modern programming languages, business-like modeling languages definitely need it.
The upcoming version of Windows Workflow Foundation with its Flowchart support gives a good example how this could look like.
In his blog Maurice De Beijer has a nice image how this looks like in the Visual Studio.NET Workflow Designer.