BPM-Guide.de » jBPM

Successful Process Automation with Open Source and BPMN

Jakob Freund — Wed, 09 Mar 2011 13:15:28 +0000

It took a while, but now we also have one of those fancy “success stories”. Until now, we just did not have the time for such kind of things. But now it’s done, and if you want to, you can learn about a BPM-project we realized in 2010 for the German 1&1 Internet AG (Big Telco Provider). This project was about automating a core process with the open source process engine JBoss jBPM, including process modeling in BPMN, so I hope it’s interesting for you.

Download as PDF

Service Invocation and asynchronous response correlation made lightweight

Bernd Rücker — Wed, 29 Dec 2010 18:11:37 +0000

As a Christmas present we got an assignment for developing a framework, which handles service invocation from processes including correlation support for asynchronous responses. And the best: We can open source it, so it will be available for everybody! Kudos to the customer (hopefully I am allowed to name them soon). In this post I will write a bit about the scope, the tackled problems and the targeted solution. An interesting side information: The framework will be able to work with different Process Engines. At the customer it is jBPM 3, but we plan to do a Proof of Concept with Activiti as well.

In this post I want to give a very easy example of a mini business process: Procurement of material. As you can see in the following BPMN the order is created by a Human, send electronically to the Supplier afterwards and then printed and archived (I needed a manual step here ). After archiving them we wait for the order confirmation of the Supplier and insert the order (maybe including the scheduled delivery date) into our ERP system automatically. Here you can see the BPMN of that process:

The first problem we face: How can we communicate with the supplier and our SAP system? Or in other words: How can we do the Service Invocation? In my post about WebServices within BPMN I already wrote about WebServices being the standard way in BPMN, but often not the best or easiest. Let’s assume in our example the communication with the supplier is done via JMS and the ERP system is developed in Java EE and offers an EJB interface. If we want to use WebServices, we would have to provide a WebService facade to these technologies. Actually I am not a big fan of that. It adds much work and complexity. So we want a more Java based solution…

A second problem we need to solve in that easy example already is correlation. When we get the answer from the supplier, we have to find the right process instance, where the answer belongs to. The BPMN standard defines two correlation approaches:

Correlation Key: A generated key without any business meaning is created for a conversation and added to all messages. This key must be present in the response as well, so it can be easily correlated. This is actually the best and safest way of correlation, since the keys are very unique. The problem typically is, that you have to deal with interfaces not being capable of handling correlation keys, hence the response will not contain that key any more. This is why there is a need for the other approach:
Context-based Correlation: The response is correlated based on payload data in the response, typically business keys. In our case that could be an order reference number or the like. This is pretty handy and works even with legacy services not being capable of handling correlation keys, but is not always unique. Think of situations where you have parallel process paths both sending an order for the same reference number.

Normally you use a combination of both, depending on the capabilities of the service you want to call. But there is a small detail really interesting in that story: In our process printing and archiving the order can take a while (maybe the accountant is on holiday drinking cocktails in the Caribbean), so the response from our supplier may arrive, before the process is in the correct state. What happens to the response? Shall it be thrown away or shall it be saved until the process instance is ready? If it is saved (queued), what if no process instance ever handles that response? These are really interesting questions, and the BPMN spec doesn’t cover them at all. This means, it is product or project specific. And how is it handled there?

Actually that was a funny small research task. I asked some of my contacts (consultants, vendors and end-users) about what they think of it, how their software does it, how they solved it or if they know an open source framework doing it. And the answers were somehow disillusioning (I freely translate and summarize them):

For jBPM we definitely do not know an open source solution. It would be nice to have a more powerful solution in a seperate open source project!
Neither the BPEL nor the BPMN spec demand to save/queue messages.
The workaround in our BPEL projects is to design processes in a way, that they always wait for a pick (where the response is received) in parallel.
JMS and WS callbacks are pretty common, but inside an open source ESB I haven’t seen a lot good solutions (I’d better say none ).
For some OSS ESB: Sadly, the integration doesn’t allow it yet.
If you have existing legacy systems, it always gets ugly.
…

After a lot of mails and some discussions I came to the conclusion, that some single vendors seem to have solved that problem somehow behind closed doors, but despite that, it is still unsolved or solved in very project specific ways. And changing the process models is not an option as well, if we take the Business-IT-Alignment story serious. Especially disappointing was, that the ESB (Enterprise Service Bus) projects or products weren’t really helpful here. In earlier days I was naive enough to think, that this is why ESBs were invented in the first place And not even the JBoss ESB as being hand in hand with jBPM in the JBoss SOA platform has a powerful answer (it is more like a very basic start). But I am not a big fan of ESBs anyway for reasons I mentioned in my WebService blog already. Basically I think they are too complicated and heavyweight, and very often you only need small parts of them to solve punctual problems. And as we can see, the really complicated problems aren’t solved anyway

Hence, the conclusion was to go for an own lightweight framework, but provide it open source. It is not about Messaging, Message routing, Enterprise Integration Patterns or other stuff ESBs or framework like Spring Integration provide. It’s “just” about calling services from your process engine and processing the responses. And “just” solving the problems for this problem, not more. And remember: We want to do that in a lightweight way in Java, easy understandable for Java people.

And just to give you an impression of the scope for correlation, these are examples of Patterns in BPMN, which should be supported by such a framework:

Handling multiple responses in an unknown order
Saving responses if the process isn’t yet in the correct state
Handling event based gateways, were we wait for one of multiple possible responses
…

Or the different correlation patterns visualized as BPMN:

Additional Requirements

Beside the correlation problems we face two other requirements in that project, or let’s say goals we try to achieve with it:

Being Process Engine Independent: The whole solution shall not be tied to any specific Process Engine and should make as less assumptions about the environment as possible. Currently in the customers environment the JBoss SOA Platform with jBPM 3 is used, but for how long? Maybe it will be migrated to Activiti in future (see Using BPMN 2.0 Models with jBPM 3 – A migration path and more for some ideas on a migration path).
Productivity for Java People: At this customer (and actually in the most projects I see today) they have a lot of smart Java people but much less WebService or XSLT know how. Hence, the developers are most productive, if they can work in their known Java environment. This is why we tried to work with Java interfaces and Data Transformation being written in Java instead of using XSLT. This eliminates the need for additional tooling as well (and there is still no good open source XSLT Tooling available), you just need your IDE and code completion.

Solution: camunda fox PSI

PSI Building Blocks

After some discussions we named the Open Source component PSI – the Process Service Invocation Framework (unfortunately Babelfox was already taken ). The image on the left shows the big building blocks of PSI on a very high level. An important component are the so called Service Adapters. The idea is to write the code required for data transformation in simple Java classes independent of the concrete process engine. For the service you use a Java Interface. The Adapter can be easily written and tested with pure Unit testing. Here a quick example of how ServiceAdapter currently look like from the camunda fox docs (but it is still subject to change):

public class StoreOrderServiceAdapter implements ServiceRequestAdapter, ServiceResponseAdapter {
  @DataObject
  private OrderDataObject order;
  @Service
  private OrderService orderService;
  @Override
  public void callService() throws Exception {
    orderService.storeOrder(order.getValue());
  }
  @Override
  public void processResponse(Order response) throws Exception {
    // lets assume the EJB call returns a Order object with filled order id or the like as response
    order.setValue(response);
  }
}

To hook them into your Process Engine environment there is the PSI Coordinator. It can be called from your processes (by small binding components providing jBPM Action Handlers or Activiti Delegates) and fulfills the following tasks:

Retrieve process variables from the engine and inject them into the Service Adapter
Writing changes to the variables after the response has arrived
Lookup Service Coordinates from a registry (the registry itself is pluggable)
Steering the correlation service for correlation support, e.g. storing correlation keys or register for responses
Dispatching the service call to the concrete technology like EJB or JMS (which is maybe determined by the answer from the Registry)
Handling responses and translate incoming events to the Process Engine by using the API from PEAL (the Process Engine Abstraction Layer)

Maybe you wonder, how we can use Java Interfaces if we talk about JMS communication? Good questions The plan is to include the Message API, which can easily add Java Interfaces to JMS communication and even hide all the JMS hassle. I hope to give you concrete code examples soon.

As a last remark: There are even some more thoughts what the coordinator should do. At the current customer there is an own mechanism in place to handle failures of service calls. If these are technical errors (like the network is down) there is an own retry mechanism (in this case leveraging the jBPM jobs). So this is part of the solution as well, but I don’t want to bore you with all the details at once…

Roadmap

At the moment of writing this blog we already have more than just the rough picture I added here. We already have parts of the solution, but it was built too tightly coupled in the JBoss ESB and is not easily extensible. We already have more detailed architecture pictures, some pseudo-code and interfaces. So I am pretty confident, that we can make quick progress next year. The current project plan says, we should be finished at the end of march. So fingers crossed

And where can I find this Open Source project?

PSI (The Process Service Invocation Framework) is part of camunda fox. On the homepage you can find a link to the documentation as well as to the sources (but actually we haven’t yet committed anything, since till now all the package names are still customer specific and we have to change that first. We plan to move that from our internal SVN repository to the public fox repository as soon as possible).

Last but not least it would be (like always) hear your thoughts about it. So give me feedback! If you are interested in using PSI in your projects and maybe even want to participate in the development now (meaning you are maybe able to influence the development), don’t hesitate to drop me an email.

Using BPMN 2.0 Models with jBPM 3 – A migration path and more

Bernd Rücker — Fri, 24 Dec 2010 10:40:42 +0000

If you are using JBoss jBPM 3 in your current process automation projects you may face the problem, that some stakeholder (business, analysts, customers, marketing, …) ask for BPMN process models. And they often do for a good reason. But how do you get to that world? Do you have to throw away the jBPM 3 engine and start using a BPMN 2.0 Engine like Activiti? If yes, how could a migration path could look like?

But there are good news: Your are not the only one having this problem Hence we already worked out strategies with some of our customers. One is to keep the jBPM 3 engine (at least for some time), but use BPMN 2.0 models anyway. Therefore we wrote a complete transformation and graphical tooling around it. And just in time for Christmas we open source it And together with some other ideas this leads you towards a step by step migration strategy, so read on…

jBPM Process Definition Language

Just to bring everybody on the same page: The problem is, that JBoss jBPM 3 – a proven and pretty stable Open Source process engine we do projects with for around 7 years now – uses a proprietary XML language called jPDL. That wasn’t a problem when jBPM started, because at this time no fitting standard was available (only XPDL which was very weak and BPEL which just emerged and didn’t fit for reasons I want to skip here). But nowadays BPMN 2.0 is the accepted standard, so there is a demand for BPMN process models, at least if you want to gain transparency by modeling your processes. This is not only about nice pictures, it is about being able to use BPMN the right way, e.g. like we describe in our BPMN framework. And additionally, jBPM 3 is in maintenance mode, meaning it is not actively developed any further, so sooner or later you will be asked about a possible migration path.

How to get from jPDL (jBPM3) to BPMN 2.0?

The first thing everybody asks: Can I somehow import my jPDL processes into BPMN? Good question! Currently a XSLT-Transformation (jPDL -> BPMN 2.0) is developed by JBoss itself, but I am not yet sure, how powerful that will get. In our projects we choose another solution, which we are happier with than XSLT (and the XSLT wasn’t available at this time anyway). We implemented an own transformator in Java, using the jBPM 3 object model and creating a JSON file for the Signavio or Activiti Modeler, which then can export the BPMN 2.0 XML (sounds more complicated than it is, since we nicely integrated that in tooling, see below). The Java-Transformator supports basic transformations out of the box but allows for easy extensions in your project. So the goal was to be able to influence the resulting BPMN in every project easily, since for a couple of constructs there is not the one and only right way for transformation.

The transformator doesn’t preserve any layout information, in most cases the jPDL layouts wouldn’t be helpful anyway. In some cases we leveraged the Signavio Auto-Layout mechanism instead. But in all of our cases we did some manual adjustments afterwards, at least for the layout.

Throw away jBPM 3?

So we found a way to migrate process definitions to BPMN 2.0. Fine But that is only part of the story. In a lot of jBPM projects business logic (or service calls) is attached to the process definition as so called ActionHandler’s or DecisionHandler’s (both Java Interfaces). How can we migrate them? Or how to embed a new engine in your environment, where you might have invested time to get going with jBPM 3? These are the hard tasks, and it is advisable to do them step by step.

So for our customers we didn’t migrate the engine immediately, but kept jBPM 3 for a while.

Use BPMN 2.0 to jPDL transformation

If we keep jBPM 3 the interesting question is how to get from the BPMN process model to the jPDL XML, which then is deployed on the jBPM 3 Engine. Surprise, surprise, we introduced a second transformation, from BPMN to jPDL. And this direction is much more important, meaning we invested much more time in it than the reverse direction. We successfully used it at customers in various processes. Hence, it is already pretty proven, even if not totally complete. But again, our focus was to make it easy extensible. It can be done by writing a small Java class being added to the mapping. This is done by customers themselves.

Extending this mapping with own magic

Defining a measuring point in Signavio Modeler in BPMN

I want to give you a quick example to make it more concrete. In a customer project we defined measuring points in the process, at these points an event will be sent to the so called Process Control Center (typical scenario). For sending these event there is a pre-defined jBPM3 ActionHandler doing it. The measuring point is modeled as intermediate event and a boolean property “measuringpoint” is set to true in Signavio (as shown in the screen-shot). This can be used during the Tranformation process and the ActionHandler with the correct configuration is added to the resulting jBPM process. You can see as well, that in that step we validate constructs of the BPMN model. If the name of the measuring point doesn’t match the conventions, an validation error is thrown. The following source code shows the implementation of this extension, as you can see it is a very easy Java code that can be hooked into the transformation:

public class MeasuringPointPattern extends OryxPattern {
  public Node modifyJpdl3(Node node, Shape shape) {
    if (BPMN20.NONE_INTERMEDIATE_EVENT.equals(shape.getStencilId()) &&
"true".equals(shape.getProperty("measuringpoint"))) {
      String name = shape.getProperty("name");
      if (name == null || !name.startsWith(MP_PREFIX)) {
        roundtrip.addMappingValidationError(shape, "The name of the None Intermediate Event '" + shape.getProperty("name") + "' does not start with '" + MP_PREFIX + "'."));
      }
      String mpName = name.substring(PREFIX.length());

      Event event = node.addEvent(new Event(Event.EVENTTYPE_NODE_ENTER));
      Delegation delegation = new Delegation(ACTION_HANDLER_CLASS_NAME);
      delegation.setConfiguration("" + mpName + "");
      Action action = new Action(delegation);
      event.addAction(action);
      action.setName(mpName);
    }
    return node;
  }
}

As a result, customers, departments or even projects may influence the mapping. There is no need to change anything in the “core” transformer.

Graphical tooling for using the transformation

The transformation from BPMN 2.0 to jBPM can be used in different ways. The easiest is to call the transformation via command line or in own Java code:

TransformationPerformer transform = new TransformationPerformer();
// add the patterns you need
transform.addJsonPattern(new Bpmn20JsonPattern());
transform.addJsonPattern(new MeasuringPointPattern());

// Fire it. In the background the Activiti Cycle Signavio Connector is used to read the process from the Signavio or Activiti Modeler
transform.performBpmn20ToJpdl3AndWriteToFile(
  signavioUrl, signavioUser, signavioPassword, sourceModelId, outputfileJson, outputfileXml, outputfileLog);

The Cycle Plug-In can show Validation Errors graphically

But often you want to have more sophisticated tooling. What we did is to include the Mapping as Plug-in in Activiti Cycle. Since Cycle can browse the Signavio Process Repository as well as the Signavio Explorer, the Cycle GUI can be used as entry point for modeling. This allows to add the jBPM transformation as a view and a couple of actions on the fly. Especially interesting is, that by doing so you don’t need an additional Web-GUI, since you just use the tooling you would use anyway.

Additionally it adds a graphical view on transformation warnings and errors, as you can see in the screen-shot on the right. We created an extended Maven project wizard as well, to create technical projects that automatically contain the jBPM process definition (I described the Maven Wizard briefly in my previous blog post about Cycle already).

Forward Engineering

Adding jBPM Action Handler to BPMN process model in Signavio Modeler

The customers using that transformation and tooling currently go for a pure forward engineering approach. Meaning: All information which results in the jBPM process must exist in the BPMN model already, like shown for ActionHandlers in the screen-shot on the right. We added the possibility to easily overwrite a jBPM process model if the BPMN has changed. In Cycle we remember the link between the BPMN model (e.g. in the Signavio Repository) and the jBPM XML (e.g. in the SVN). So it is easy to overwrite the model by one click. And we currently work on notification if models have changed as well. We even generate Java class stubs for ActionHandlers or ServiceAdpaters (see below), if they don’t exist in the project yet.

We currently roll out that tooling into production at one customer, so it is already more than a nice toy. The customer expects to gain speed in the development process and especially lower the learning curve for using BPMN for executable processes and the transformation to jBPM.

Next step: Removing jBPM 3

The next migration step would be to really remove jBPM 3 and introduce a BPMN 2.0 Engine. Therefore the business logic (or service calls) attached to the process definition as ActionHandler’s or DecisionHandler’s must be migrated as well. That is actually the harder part and IMHO cannot be done in the same way in all cases. And it always depends on the target engine. Let’s at least assume you migrate at least to a Java Engine like Activiti, where we have extensions available to call Java code directly. If you have an engine only capable of communication with WebServices it gets really complicated.

With the Java capabilities you could maybe think of some kind of Adapter class, calling your existing and untouched “legacy” jBPM 3 ActionHandlers. Maybe possible, but in our projects we choose another option:

Writing Process Engine independent Service Adapters

We transformed all existing jBPM 3 ActionHandlers into some easy Java POJOs, we call “Adapter”. We currently have three basic types:

ServiceAdapter: Calling Services via EJB, JMS,…
GatewayAdapter: Making decisions
JavaAdapter: Arbitrary Java code

These Adapters have some Injection mechanism for process variables and are then completely independent of the Process Engine. They can even be tested easier (no jBPM ExecutionContext must be mocked). Actually we are currently improving the Adapter concept a lot and add additional features in the infrastructure around them (like asynchronous communication, correlation of responses, supporting different technologies like EJB or WS without the need of changing the Adapter code, calling a Registry, …). Together with a customer we plan to create an own open source project for that soon, so I will for sure blog about this in more detail. If you are interested, drop me an email, it would be interesting to hear your requirements.

But back to our topic. These Adapters now could be used in as well jBPM3 and e.g. Activiti, the only thing you need is a generic Binding class calling the Adapter in the concrete Engine specific way. But this has to be done once for all processes and in the case of our Adapter framework are even provided by us for jBPM 3 and Activiti And it is a pretty thin layer, which is easy to write.

OK, it is effort to migrate all ActionHandlers to Adapters, but it was really worth it, since the resulting code is engine independent once and for all. And since we took the opportunity to clean up and refactor a lot of code in that step, even the quality improved. And the Adapter concept forced us to define the code in a pretty clean and readable way, where no jBPM 3 hacks were allowed any more

Adding ServiceAdapters to BPMN process model

Service Adapter in the BPMN lead to special code generated for jBPM

As described above, we now add the ServiceAdapters to our BPMN process models, exchanging the jBPM ActionHandlers. In a first phase, we could even mix both possibilities, as long as we still run on jBPM3. As soon as we switch the Engine we exchanged the transformation to add the ServiceAdapters correctly e.g. to Activiti process definitions. This can be done once in the transformation, the BPMN process models as well as the Service Adapters keep untouched. You “just” have to exchange the Engine in your environment (which maybe is not that hard, if you used our Process Engine Abstraction Layer ).

Migration Strategy

So in short we currently made good experiences with a migration strategy like this:

Migrate process models from jPDL to BPMN
Keep jBPM 3 and introduce forward engineering from BPMN models to jPDL
Test that everything still works
Migrate ActionHandlers to Engine Independent code (e.g. ServiceAdapters)
Test that everything still works
Migrate Engine by having a “phase out”-phase, where you run jBPM 3 and the new engine in parallel. Actually there are a lot of discussions going on, if that should be avoided by migrating running process instances to the new engine and make a hard cut. I think, phasing out is much easier and less error prone (and is actually not that hard to do), but maybe somebody proves me wrong in future

To be honest, none of our customers has already completely migrated. But hey, jBPM 3 is really stable, there is no time pressure for it, as soon as you can present BPMN process models to anybody asking for it

And where can I find this transformation and Cycle Plug-in?

We are currently releasing the transformation described and the Activiti Cycle Plug-in freely as Open Source on the camunda fox Cycle Plug-ins Page. The downloads will be available together with the release of Activiti Cycle 5.1 (1st of January 2011).

Left. No right! Testing processes with scenarios.

Bernd Rücker — Fri, 18 Jun 2010 05:32:39 +0000

Test Scenarios

In a current project we develop an executable process. Hence, this process is a “piece of software”, which need to be tested. In software development this is common sense, so there are enough tools and best practices. Is that the same for technical process models? Hmm, not that easy. On the one hand we can use proved Java Test frameworks like JUnit for Open Source Process Engines like jBPM. On the other hand processes have some specialties, which aren’t surprising but somehow challenging…

For the process we devloped process scenarios, which indicate on which path a process instance flows through the process. The picture on the left shows a foto from the current project. By the way: The green mark shows: This scneario was successfull tested Sorry for the bad quaility of the picture, but otherwiese I couldn’t have posted it here.

To implement such a scenario we can write a unit test, which set up some test data, trigger the process and waits, till the process arrives in a defined state. As soon as the process waits for an external trigger (like a Human enter some data or a system sends an asychronous answer) the unit tests comes into action and “fakes” that answer. By doing so, the whole process can be walked through to check if the behaviour is as expected. Some sample code is shown at the very end of this blog post, I don’t want to frighten non IT folks too early

To define these kinds of scenarios is pretty typical by the way, we did that in quite some projects already. The downside is at the moment, that there isn’t much good tooling for that. In the area of Open Source Process Engines there exists basically nothing and the commercial tools tend to be too GUI centered, which normally isn’t developers friendly. I see the following requirements for such a tooling:

We want to organize these scenarios! We want to mark them in the real process model, save it and load it later on.
I want to compare the audit data from the really executed process with the defined scnerios (“Did the process really went that way?”). I want to recognize differences easily and graphically.
I want to create “smaller” scenarios for just parts of the process. In our example process we have different parts, e.g. data checking, customer creation, order provisioning, …. We want to test these parts independantly from each other (I want to spare the explanattion why we didn’t create subprocesses for them). So we want to start a scenario at an arbritrary node in the process, provide some input data and stop it at a defined node where we calidate the outgoing data.
Ideally Input and Output data are provided in a non technical format, like spreadsheets or Fitnesse.

Test Coverage

There is another interessting aspect of process testing: The so called Test coverage. The idea is easy: I want to make sure that every node and path in my processes was executed at least once. If you need every possible combination can be an endless discussion, but in my experience it would be already a big improvement for most projects if they had at least executed every path once. In our project I used a marker to indicate which parts we already tested as you can see indicated on the left. But this coverage report could be generated by the tooling itself, so to visualize this automatically would be another item on my wish list.

Currently we implement the mentioned use cases in camunda fox for JBoss jBPM 3.2.x and Signavio. The visualizations are done in the BPMN model in Signavio, the technical implementation and testing is done in jBPM. But we try to achieve that non technical folks can define, refine or at least read the test scenarios as well. Then we could make the tests and test coverage part of a process cockpit or process status as well.

Process Development Status Indication

By the way: Currently we use a printed BPMN diagram to indicate the status if the development, as you can see on the left. We want to link the nodes with JIRA-Issues, so we can create that indication automatically. Even if paper and whiteboards are good tools, that only works if the whole team is in the same room or at least building. Obviously it is nice to stand in front of the whiteboard for discusssions, bit not having it electronically has some disadvantages:

Not transportable: We could’t easily take the status and scenarios with us into meetings.
Changes: If there are process changes, we would have to reprint and redraw all scenarios.
Keep it up-to-date: After the project or in the next project we want to improve the scenarios or change them according to changed processes. The paper from the last project is normally not longer available at that time.
No Continous Integration based on paper
Distributed teams: As soon as your not together at the same physical location any more you need electronical help to get that running and the collaboration intact.

But this is enough content for an own blog post…

Okay, but I promised to give you some more technical details, so I present an example test case here (note that the asserts are hidden in the ProcessHelper);

public void scenario2() throws Exception {
  testDataHelper.setCustomerAddressType(CustomerAddressType.VALID_ADDRESS);
  ... // set some more data for testcase

  long orderId = startOrderProcess();

  // provide a test stub for one service called on the way we wanted to "mock" out
  processHelper.setTestStubResult(CheckAddressAdapter.class, createCheckAddressResultResult());

  processHelper.waitForState("Fraud Check aufrufen");
  // "fake" result of fraud service: Fraud OK
  correlationFacade.callCorrelationService("Fraud", orderId, "0");

  processHelper.waitForState("Bonität prüfen");
  // "fake" result of boni service: Boni yellow
  correlationFacade.callCorrelationService("Boni", orderId, "1");

  // wait for the process to end
  processHelper.waitForState("Ende", 70);
}

During the execution the ProcessHelper shows the flow of the process, we “just” need to add some functionality to validate this audit data aginst our expectation in the scenario:

SCENARIO: Storno Boni (yellow); ORDER ID: 4368835; ROOT TOKEN ID: 1495
   - wait for Call Fraud Check
      - status changed to BI: Insert Data
      - status changed to DCN: Insert Data into Duplicate Checker
      - status changed to CCD: Create customer
      ...
      - status changed to Call Fraud Check
   - wait for Check Boni
     ...
      - status changed to Check Boni
   - wait for End
      - status changed to Check Boni
      - ...
      - status changed to End

BPMN 2.0 wird ausführbar – und für jeden verfügbar!

Bernd Rücker — Sun, 13 Dec 2009 11:11:22 +0000

Große Ereignisse werfen ihre Schatten voraus. Nicht nur, dass unser Praxishandbuch BPMN endlich vollbracht ist (siehe Wir haben fertig), daneben hat mein Prototyp einer BPMN 2.0 Engine mit JBoss jBPM (siehe Bauen wir uns eine BPMN 2.0 Engine), den ich im Rahmen des Buches entwickelt habe, tatsächlich einiges angestossen. Somit wird in der kommenden jBPM Version 4.3 pünktlich zum neuen Jahr (am 01.01.2010) eine BPMN 2.0 Process Engine zur Verfügung stehen (siehe auch The First OSS BPMN 2 Process Engine).

Ein erstes lauffähiges (!) Beispiel hat Joram vom jBPM-Team auch bereits online gestellt: jBPM goes BPMN. Natürlich werden im ersten Schritt noch nicht alle BPMN 2.0 Features unterstützt, viel mehr wird priorisiert und Elemente werden nach und nach eingebaut, wobei bis Mitte 2010 schon eine recht vollständige Engine zur Verfügung stehen soll. Dies wird vor allem dadurch möglich, dass “nur” die Sprachelemente neu entwickelt werden müssen, und die eigentliche Engine (mit Themen wie Persistenz, Skalierbarkeit, Clusterfähigkeit usw.) bereits stabil läuft.

Wir wollen uns aber nicht nur für die Initialzündung auf die Schulter klopfen, sondern werden zukünftig auch weiter aktiv an der Entwicklung mithelfen. Wie sollte man eine Sprache besser lernen und eine Spezifikation genauer verstehen, als wenn man eine Engine selbst mitbaut

Aus unserer Sicht macht es übrigens gerade im Process Execution Bereich oft Sinn, quelloffene Software einzusetzen. Weniger wegen der Kosten, sondern damit das Unternehmen statt einer Black-Box die maximale Kontrolle bekommt. Sollte die Software nicht funktionieren oder erweitert werden müssen, dann können Sie das tun! Ihre Entwickler (oder auch eingekaufte Berater ) können sich mit solchen Produkten bis in die Eingeweide auskennen, womit man viele Fehler, Probleme und Anforderungen besser und schneller lösen kann und nicht auf den Support der Hersteller angewiesen ist. Sie wollen Ihre Lösung aber gar nicht so genau kennen? IT muss einfach laufen? Dann ist Open Source sowieso nicht das richtige für Sie, in diesem Fall können Sie doch mal einen Blick auf unsere SaaS-Plattform für BPM werfen

Genug des Marketing. Bleibt nur zu sagen, dran bleiben lohnt sich, da wird die nächsten Monate einiges passieren! Wir werden ebenfalls live dabei sein.

Bauen wir uns eine BPMN 2.0 Engine

Bernd Rücker — Sun, 02 Aug 2009 07:31:34 +0000

Die Spatzen pfeifen es schon von den Dächern: Die BPMN 2.0 steht vor der Tür. Die neue Version heißt jetzt “Business Process Model and Notation” und bringt einige Neuerungen mit. Eine der wichtigsten ist jedoch das sagenumwobene Metamodell sowie die Ausführungssemantik. Cool. Aber was ist das? Im Rahmen des Praxishandbuch BPMN, das wir gerade schreiben, haben wir uns damit natürlich ganz genau auseinandergesetzt. Heute möchte ich einmal zwei kleine Vorgeschmäcker geben: Ein Beispielprozess in BPMN 2.0 Syntax sowie die neusten Infos aus dem Maschinenraum – zur Entwicklung eines Prototyp einer BPMN 2.0 Process Engine.

Ein Bild sagt mehr als tausend Worte – und ein Beispiel mehr als jedes Schema

An dieser Stelle möchte ich eines vorneweg schicken: Mir sind einige graue Haare gewachsen als ich mich durch den BPMN 2.0 Spezifikationsentwurf gekämpft habe. Nun habe ich natürlich kein literarisches Meisterwerk erwartet. Überrascht hat mich dann aber, dass es so gut wie kein Beispiel-XML im gesamten Dokument gibt. Ich hoffe nicht zu lügen, ich meine es war genau ein Mini-Prozess. Vielleicht geht es ja nur mir so, aber ich kann Besipiel-XML-Dateien besser verstehen als weit verstreute XML-Schema-Bruchstücke (XSD). Naja, auch sonst sind Anwendungsbeispiele in der Spec spärlich gesäht. Aber gut, dafür gibt es dann ja auch unser Buch

Nun gut, also habe ich erst mal behende einen Beispielprozess aufgesetzt. Leider habe auch ich noch nicht alle Einzelheiten der Spec und des XML-Formats verstanden. Ich bin mir auch noch nicht sicher, ob der hier abgebildete Prozess wirklich hundertprozentig richtig ist, daher bitte einfach melden, wenn jemand anderer Meinung ist!

Der Prozess, den ich mir vorgenommen habe, entstammt natürlich unserem Buch, es ist ein kleiner Teilprozess für die Lieferung von Ware. Die Story ist ganz simpel: Die eigentliche Tourenplanung – welche Ware in welchem LKW zum Kunden geht – macht ein dafür ausgelegtes System. Wir rufen nur einen Service auf, damit unsere Ware berücksichtigt wird und werden benachrichtigt, wenn die Ware versendet ist. Eventuell benachrichtigen wir dann den Kunden über den Liefertermin, im Beispiel erfolgt dies durch einen Kundenbetreuer. Der Prozess ist hier dargestellt:

Für die Serialisierung als XML gibt es nun zwei wichtige Aspekte:

Semantik: Welcher Service wird aufgerufen, wer kann die Aufgabe bearbeiten, wie wird die Entscheidung getroffen, ob die Lieferterminavisierung notwendig ist, usw.
Layout: Wie sieht das Diagram aus, wie sind die Elemente angeordnet.

Die beiden Aspekte werden von BPMN 2.0 getrennt behandeln. Heute wollen wir uns für den Anfang nur die Semantik zu Gemüte führen, ein Blogpost zum Layout folgt noch. Die Spezifiaktion definiert ein XML-Schema für die Semantik. Unter der Annahme, dass wir das Tourenplanungssystem über Webservices ansprechen sieht der Beispiel-Prozess in etwa so aus, wobei ehrlicherweise noch ein paar Aspekte fehlen:




  
  
  
  

  
  

  
  
  
  

  
  
  
  

  
  
    
  
  
    
  

  
  
    
      tns:ProzessStartenNachricht
    
    
      tns:KommissioniertNachricht
    
  
  
    
      tns:LieferungAnlegenNachricht
    
  

  
  

  
  
    Teilprozess der Lieferung

    
    

    
    
      
      
        
          
             getDataOutput('ProzessStartOutput')/shipment
          
          
             getDataObject('lieferungVariable')
          
        
        ProzessStartOutput
        tns:lieferungVariable
      
      
        tns:startShipmentProcess
      
    

    
    
      
      
        
        
          LieferungBuchenInput
        
        
      
      
        
          
             bpmn:getDataObject('lieferungVariable')
          
          
             bpmn:getDataInput('LieferungBuchenInput'/shipment/
          
        
        tns:lieferungVariable
        LieferungBuchenInput
      
    

    
    
      
        
        
        
          KommissioniertOutput
        
      

      
        
          
            getDataOutput('KommissioniertOutput')/shipment
          
          
            getDataObject('lieferungVariable')
          
        
        KommissioniertOutput
        tns:lieferungVariable
      
    

    
    

    
    
      
    

    
    

    
    
    
    
    
      
        getDataObject('lieferungVariable')/confirmationRequired=true
      
    
    
      
        not( getDataObject('lieferungVariable')/confirmationRequired=true )

Ich möchte das XML fast einmal für sich wirken lassen Wie gesagt, sollte jemand einen Fehler finden oder sonst gute Hinweise haben, immer her damit!

Einen Aspekt möchte ich hervorheben: Die BPMN 2.0 lässt offen, in welcher Technologie Daten vorliegen, Services angebunden werden und Ausdrücke ausgewertet werden. Somit kann man sich eine Engine vorstellen die sehr BPEL-ähnlich arbeitet, mit XML und Webservice, oder aber auch eine Engine, die an Java oder ähnliches gebunden ist. Das coole daran ist, dass man sich trotzdem im Standard bewegt und auch eher leichtgewichtige Workflow-Engines durchaus BPMN kompatibel sein können (naja, okay, der Standard ist dick, so leichtgewichtig ist die Engine dann auch nicht mehr ).

Der Nachteil ist natürlich, dass ich einen Prozess nur dann von einer Engine auf die nächste kippen kann, wenn diese die gleiche Technologie unterstützt.

Ein Serviceaufruf könnte bei einer Java-Engine dann evtl. so aussehen:

...


  
  
  

  
  
    
      LieferungAnlegenNachricht
    
  
  ...
  
    

      
        
        
          LieferungBuchenInput
        
        
      

      
        
          #{lieferungVariable}
          #{LieferungBuchenInput.shipment}
        
        lieferungVariable
        LieferungBuchenInput
      

    
    ...

Eine Open Source BPMN 2.0 Engine?

Nun möchte ich noch mein zweites Versprechen einlösen und kurz aus dem Nähkästchen plaudern. Ich bin ja eher so der Typ, der Beispiele braucht und gerne etwas ausprobiert. Theorie und Spezifikationen sind schön und wichtig, aber in der IT muß es ja auch irgendwann irgendwie tatsächlich laufen. Also gut, dachte ich mir, baue ich mal nen Prototypen für ne BPMN 2.0 Engine.

Um nicht von Null zu starten habe ich die JBoss jBPM Process Virtual Machine als Grundlage genommen. Dort sind bereits die wesentlichen Konzepte einer Process Engine umgesetzt. In zwei längeren Zugfahrten konnte ich so schon meinen ersten einfachen BPMN 2.0 Prozess ausführen. Also: Es geht! Problematisch werden dann eher die vielen schmutzigen Details, wovon die Spec einige zu bieten hat

Die Idee und der Prototyp wurde inzwischen aufgegriffen und im jBPM weiterentwickelt. Aktuell eher als Proof of concept und Prototyp. Da er Open Source für jeden verfügbar und einsehbar ist denke ich eine schöne Sache, um BPMN 2.0 den Menschen – naja, den IT-Menschen – näher zu bringen!

Fazit BPMN 2.0 Ausführungssemantik

Mein aktuelles Fazit zur Ausführungssemantik ist: Sehr mächtig, aber auch komplex. Im Prinzip ist es BPEL ähnlicher geworden, die Mächtigkeit ist vergleichbar, die Komplexität dann eben auch. Witzig in diesem Zusammenhang übrigens auch folgendes Zitat, dessen Urheber ich anstandsweise nicht nennen möchte: “It would be a mistake to conclude there was some OMG deep thinking behind these fine points in the spec. More often it was one guy thinking about how his own company’s BPEL engine (now being converted to BPMN 2.0 engine) behaves, and no one else paying attention.”

Doch BPMN hat aus meiner Sicht Vorteile gegenüber BPEL, dies sind vor allem:

Kontrollfluß als Graph: Man kann also tatsächlich fachlich modellieren und das direkt ausführen. Natürlich bringt das Probleme für Process Engine Hersteller mit sich (es hat ja seine Gründe, warum es BPEL gab), ich finde jedoch, sollen sich lieber Hersteller damit rumschlagen als der Nutzer der Werkzeuge!
Grafische Notation entspricht den fachlichen Modellen: Mit BPMN hat man in der technischen die gleiche Notation wie in der fachlichen Modellierun. Ich will damit nicht sagen, dass man das gleiche Modell verwendet (daran glauben wir nicht so richtig, auch das begründen wir ausführlich im Buch). Aber die Modelle sind sich ähnlich und Business und IT sprechen die gleiche Sprache (BPMN).
Keine feste Bindung an Webservices und XML: Auch wenn es die Standardeinstellungen sind, BPMN kann jede Technoligie ausführen. Damit können BPMN Engines auch in Szenarien und Architekturen zum Einsatz kommen, wo BPEL bisher ungeeignet war.

BPMN 2.0 – ist das was für mich? Sollte ich auf BPEL setzen oder abwarten?

Mit diesen Fragen sind wir zur Zeit häufig konfrontiert. Und dies ist verständlich. Das Investment in eine Process Engine ist groß, das Tool wird einen lange Jhre begleiten und nicht selten die gesamte Unternehmens-IT-Infrastruktur mit prägen. BPEL galt als führender Standard hat in Projekten aber oft enttäuscht. Proprietäre Ansätze sind zwar häufig sehr gut, können oder wollen aber politisch nicht durchgesetzt werden.

Und jetzt kommt da BPMN 2.0. Wird jetzt alles besser? Sollte man eventuell auf eine BPMN 2.0 Engine warten? Oder noch BPEL kaufen? Oder was ganz anderes machen? Oder oder oder?

Zu diesem Thema entwickeln wir gerade einen Webcast. Sind Sie interessiert an diesem Thema? Würden Sie daran gerne teilnehmen? Dann sprechen Sie uns an! Teilen Sie uns mit welche Fragen Sie beschätigen. Wir versuchen eine Antwort zu finden… Denn den Kopf in den Sand stecken nützt ja nichts

Und das Buch?

Ach ja, das Buch. Wie bei Büchern so üblich sind wir leider etwas hinter dem Zeitplan. Irgendwie muss man dann ja doch auch noch etwas arbeiten, so nebenbei. Wir sind jedoch zuversichtlich, dass Manuskript bald – endlich – abgeben zu können. Abonnieren Sie doch unseren Newsletter, dann bekommen Sie den Erscheinungstermin auf jeden Fall mit!

Sollten Sie Feedback zu diesem Artikel, der Ausführungssemanik oder meinen Beispielen haben noch einmal der Aufruf: Melden Sie sich einfach! Sie können vielleicht noch das Buch beeinflussen Gerne als Kommentar oder per Email: bernd.ruecker@camunda.com

Ein kleiner jBPM 4 Showcase

Bernd Rücker — Wed, 08 Jul 2009 13:43:17 +0000

Wie versprochen möchte ich pünktlich zum Release der Version 4 der Open Source Process Engine JBoss jBPM am Freitag, den 10.07.2009, gleich einen kleinen Showcase berschreiben. Diesen Showcase habe ich auch bei meinem Vortrag auf dem Java Forum Stuttgart gezeigt und er wird auch nochmals genauer in einem bald erscheinenden JavaMagazin-Artikel erläutert. Gebaut habe ich ihn mal zwischendruch mit dem so genannten Candidate Relase.

Konkret geht es um einen kleinen Shop, der Designertaschen herstellt. Der Prozess dahinter soll nun mit jBPM automtatisiert werden.

An dieser Stelle möchte ich mich kurz fassen und lediglich Showcase und Quellcode dazu vorstellen. Eine detailliertere Beschreibung folgt wie gesagt im JavaMagazin.

Also steigen wir sofort ein, folgender Prozess wurde ausgetüftelt:

Es ist zu sehen, dass jBPM 4 nun auch mit den BPMN-Shapes arbeitet. Auch kann man bereits einige Activity-Typen (=Knotentypen) erkennen, wie zum Beispiel menschliche Interaktion, Wartezustände oder auch “Serviceaufrufe” als Referenz auf Java-Methoden.

Dahinter liegt natürlich ein Prozess als XML-Datei:

Die Beispielanwendung

Um eine Betsellung aufzugeben, also eine Prozessinstanz zu starten, wurde ein kleiner PHP-Shop implementiert. Dabei habe ich Quercus verwendet, so dass ich PGP-Seiten direkt auf dem JBoss deployen kann und in PHP auch Java-Code einbetten kann. Warum? Einfach weil es sich cool anhörteund ich es auch mal kurz ausprobieren wollte . Obenist die resultierende Bestellseite abgebildet, die mir unser Studi Christian dankenswerter Weise fix mal aufgehübscht hat.

Klickt man auf den Bestellbutton wird dabei folgender Code ausfgeführt, zugegeben eine etwas unschöne Mischung aus Java und PHP, aber für einen schnellen Prototypen denke ich ganz nett. Quercus beherrscht es nämlich, Java-Code direkt einzubetten, eigentlich wird sogar der gesammte PHP-Code in Java-Bytecode übersetzt.

import org.jbpm.api.Configuration;
import org.jbpm.api.ExecutionService;
import org.jbpm.api.ProcessEngine;
import java.util.HashMap;
import com.camunda.training.jbpm.domain.Customer;
import com.camunda.training.jbpm.domain.Order;

$conf = new Configuration();

$processEngine = $conf->buildProcessEngine();
$executionService = $processEngine->getExecutionService();

$order = new Order();
$order->setOrderedItem( $_GET['orderedItem'] );
$order->setPrice(99.95);
$order->setCustomer(new Customer());
$order->getCustomer()->setName( $_GET['customer_name'] );
$order->getCustomer()->setEmail( $_GET['customer_email'] );
$order->getCustomer()->setAddress( $_GET['customer_address'] );

$variables = new HashMap();
$variables->put("order", $order);

// start process instance
$pi = $executionService->startProcessInstanceByKey("Bestellung", $variables);

Mehr ist nicht notwendig. Man kann auch sehen, dass in diesem Fall die Bestellung als Java-Objekt als Prozessvariablen übergeben wird. Die entstandene Prozessinstanz kann man sich über die in jBPM 4 mitgelieferte Webcoonsole (Google WebToolkit) auch gleich anschauen, sogat grafisch mit Markierung, wo im Prozessablauf sich die Instanz aktuell befindet:

Die aktive Aufgabe “Bestellung_pruefen” ist in diesem Fall ein Human Task, also wird eine Aufgabe in der so genannten Task Liste erstellt. Im Showcase wird sie zuerst der Gruppe “Lager” zugerodnet (siehe candidate-group Attribut im XML) und erscheint auf der Gruppen Task Liste. Von dort muss sich dier User die Aufgabe zuerst “ziehen” (claim). To claim heißt in diesem Fall, dass ich mir die Aufgabe hole. Damit verschwindet sie von der Gruppenliste und wandert in meine persönliche Task Liste.

Dort kann dann auch ein Formular geöffnet werden um die Aufgabe zu bearbeiten. Aktuell ist das Formular in der Webconsole ein Freemarker-Template, wobei der Dateiname dem Activtiy-Namen entsprechen muss. Dies ist übrigens der Grund, warum im Showcase die Aktivitätsnamen mit Unterstrichen und ohne Umlaute arbeiten Dies soll allerdings in Zukunft verbessert werden, so dass für eine Aktivität konfiguriert werden kann, welches Formular verwendet wird. Dies ermöglicht es dann auch, das gleiche Formular für verschiedene Aufgaben zu verwenden. Der folgende Screenshot verdeutlicht dies:

Nehmen wir den einfachen Fall an, benötigte Rohwaren sind im Lager und die Tasche kann folglich produziert werden, dann würde der Lager-Sachbearbeiter hier auf “Auftrag OK” klicken. Damit wird der Prozess den “unteren” Weg weiter laufen und in “Ware_produzieren” ankommen. Dort würde nun der Designer die Aufgabe in seine Workliste bekommen. Dies habe ich mir als Screenshot an dieser Stelle gespart.

Ist die Ware produziert, muss sie versendet werden. Mit vielen Kunden hatten wir schon die Diskussion, ob dies ein Task oder ein einfacher Wartezustand ist. Ich denke, es kommt darauf an, wie man arbeitet. Soll tatsächlich ein Mitarbeiter auf Grund der fertig gestellten Tasche aktiv loslaufen, diese abholen und verschicken, dann wäre es eine astreine Aufgabe. denn wir müssen dies dem Mitarbeiter ja über seine Aufgabenliste mitteilen.

Wird aber hingegen die Tasche auf eine Palette gelegt und der Versand verschickt diese gesammelt am Nachmittag, dann finde ich ist es aus Sicht des Prozesses ein Wartezustand. Denn wir warten auf das externe Ereignis, dass der erfolgreiche Versand gemeldet wird. Um den Versand zurück zu melden haben wir also nicht die Task Liste als Oberfläche sondern einen eigenen Mechanismus. Im Idealfall würde die Software des Logistikers (DHL o.ä.) diese Rückmeldung automatisch ausgeben und wir könnten es elektronisch importieren. Im Showcase habe ich aber einfach eine simple Oberfläche gebastelt, die alle Prozesse im Zustand “Warten_auf_Versand” ausgibt, so dass versendete Pakete einfach quittiert werden können:

Die ausgewählten Prozessinstanzen werden dann weiter getriggert und in unserem Fall wird der Bestellprozess beendet.

Historische Prozessinstanzen

Vor allem für die Umsteiger von jBPM 3 sei an dieser Stelle erwähnt, dass die neue Version anders tickt. Wird eine Prozessinstanz beendet so wird sie aus der Tabelle der aktiven Instanzen gelöscht und komplett in History-Tabellen verschoben. Dies löst das alte Problem, dass die jBPM-tabellen rasant voll werden, wenn viele Prozesse gestartet werden. Das würde bei unserem Taschen-Designer sicher kein Problem (sonst wäre er glaube ich sehr reich ), kann aber in großen Umgebungen durchaus spannend werden.

Fazit & Download

Der Blog-Post hat jetzt nicht die Hintergründe und Neuerungen in jBPM 4 erläutert. Dafür bitte ich, sich bis zum Erscheinen des JavaMagazin-Artikels zu gedulden. Ziel war es, einen einfachen Showcase kurz darzustellen. Ich hoffe, dass ich dies erreichen konnte.

jBPM 4 selbst ist eine sehr interessante Weiterentwicklung der bekannten Open Source Process Engine, die sich in einigen Punkten bedeutend weiter entwickelt hat (Stichworte: Process Virtual Machine (PVM), API, BPMN). Allerdings muss man auch anmerken, dass aktuell noch nicht alle Features der 3er Version unterstützt werden. Auch muss sich die Stabilität in größeren Umgebungen noch bewären, da die Engine eben ganz frisch ist und nunmal eine Neuentwicklung darstellt (Code aus jBPM 3 wurde kaum wieder verwendet da die interne Architektur stark umgebaut wurde). Man sollte der neuen Version also noch ein paar Monate Zeit geben alle Features nachzuziehen und Kinderkrankheiten zu beseitigen.

Nichtsdestotrotz ist die Dokumentation jetzt schon sehr gut und auch die Test-Suite sehr umfangreich. Erstmals sind beispielsweise auch gute Tests zu Concurrency-Problemen und ähnliches enthalten. Die neue Version ist also auf jeden Fall cool und wird ganz sicher noch spannend! An Feedback und Meinungen sind wir natürlich dabei auch immer interessiert.

Der Showcase zum Runterladen findet sich hier:jbpm4-showcase. Es muss lediglich die build.xml mit dem richtigen JBoss-Pfad angepasst werden. Auch muss natürlich quercus installiert werden, damit die PHP-Seiten funktionieren. Okay, das ist vielleicht ein bisschen uncool an der Lösung, sorry! Trotzdem viel Spaß beim ausprobieren.

Und sollte ich irgendwann keine Lust mehr haben auf die Informatik hab ich somit auch gleich schon mal ein Ausweichgeschäft

Presentation Zen auf dem JFS

Bernd Rücker — Sun, 05 Jul 2009 08:44:32 +0000

Auf dem Java Forum Stuttgart 2009 hatte ich das Vergnügen die Open Source Process Engine JBoss jBPM 4 vorstellen zu dürfen. Erstmalig habe ich mich dabei vom Presentation Zen inspirieren lassen und den Bulletpoints den Kampf angesagt. Das Ergebnis lässt sich hier bewundern: Folien bei Slideshare.

Prinzipiell muss ich sagen, dass mir die Arbeit mit dieser Art Folien sehr viel Spaß gemacht hat. Auch den ca. 130 Teilnehmern im Saal hat es wohl gut gefallen, ich habe sehr viel positives Feedback bekommen. Und das trotz der morgendlichen Stunde.

Nachteilig (vorsicht Ironie) ist nun beim Presentation Zen nur, dass man mit seinen Folien eine gute Story aufbauen sollte und wissen muss, was man erzählen will. Also: Man muss was zu sagen haben

Wer nicht live dabei sein konnte dem bleibt die Möglichkeit, die überarbeitete Version 2 des Vortrags auf dem Herbstcampus der Mathema zu hören oder aber auch die vermutlich etwas umfangreichere Version mit mehr Diskussionsmöglichkeiten am 23.09.2009 bei der Java User Group Hamburg.

Mir bleibt zu sagen, dass ich den Showcase aus dem Vortrag in den nächsten 3 Wochen entsprechend noch hier posten werde, versprochen. Ich muss da sowieso noch so einen Artikel fürs JavaMagazin schreiben…

JBoss jBPM & Drools bei der Java User Group Berlin

Bernd Rücker — Sat, 14 Feb 2009 10:32:22 +0000

Am 04. Februar 2008 habe ich in Berlin bei der Java User Group Berlin Brandenburg (JUG-BB) einen Vortrag über BPM und Business Rules mit den Open Source Frameworks JBoss jBPM und JBoss Drools gehalten.

Trotz dem ich gesundheitlich etwas angeschlagen war, haben wir das Ganze noch ganz gut geschaukelt. Mit ca. 60 Leuten war die Kapazität des Vortragsraumes auch ausgelastet, Gerüchten zufolge wären auch gerne noch mehr gekommen.

Ich habe mich sehr gefreut, dass das Thema entsprechend Interesse anzieht und durfte auf ein interessiertes Publikum mit vielen Fragen treffen, die oft auch durch einen kleinen Exkurs in den Quellcode beantwortet werden konnten. Somit hat es mir auf jeden Fall viel Spaß gemacht!

Ein paar Bilder finden sich auf der “offiziellen” Nachlese von Ralph Bergmann, der die JUG-BB organisiert: http://www.jug-bb.de/2009/02/nachlese-jboss-jbpm-und-drools/.

Wie versprochen sind hier nun auch die Folien zum Vortrag:

JBoss jBPM und Drools – Geschäftsprozesse und Regeln mit Open Source Java

View more presentations from camunda. (tags: jbpm drools)

Ein erster Blick auf jBPM 4

Bernd Rücker — Mon, 26 Jan 2009 20:22:16 +0000

Lange hat es gedauert und teilweise gespannt wurde es erwartet: Die Version 4 der bekannten Open Source Business Process Engine jBPM aus dem Hause JBoss. Jetzt wurde die erste alpha Version veröffentlicht.

Daher habe ich gleich mal einen Beispielprozess mit jBPM 4 umgesetzt und die Version etwas genauer unter die Lupe genommen.

Die Prozessbeschreibungssprache jPDL (jBPM Process Definition Language) sowie die technische Grundlage der Prozessmaschine hat sich in Version 4 stark verändert. Dies ist einigen Neuerungen geschuldet: Der Einführung der Process Virtual Machine (PVM), die Anlehnung an die Business Process Modelling Notation (BPMN), die Einführung einer möglichst generischen API für Process Engines als natürlich auch zahlreiche Verbesserungen auf Grund der Erfahrungen mit jBPM 3.

Beispielprozess

Doch eins nach dem anderen, zu erst einmal möchte ich ein Beispielprozess aus einem unserer Trainings, einen einfachen Ticketprozess, kurz vorstellen. Dazu einmal der Prozess als BPD (BPMN-Diagramm):

Ein Kunde kann für ein Problem ein Ticket aufmachen. Ist für den Kunden noch kein Betreuer festgelegt wird dies nachgeholt. Dann bekommt der Betreuer die Aufgabe zugewiesen. Hat er sie abgeschlossen bekommt der Kunde eine E-Mail und muss bestätigen, dass sein Problem gelöst wurde. Andernfalls bekommt der Betreuer die Aufgabe erneut auf den Tisch.

Installation

Also frisch ans Werk mit jbpm 4. Die Installation beschränkt sich aktuell eigentlich auf die Integration in Eclipse, da Deployments für JBoss AS oder Tomcat noch nicht zur Verfügung stehen. Daher beschränkt sich auch das Testen noch auf JUnit… Dank mitgelieferter guter Doku ging die Installation trotz Eclipse (sorry, es ist einfach nicht mein Lieblingstool ) gut von der Hand.

Der neuen Designer und BPMN

Der neue grafische Prozessdesigner (GPD) überrascht sofort mit einer grafisch ansprechenden BPMN-Darstellung der Prozesse. Allerdings sind in der aktuellen Version auch nur ein Bruchteil der existierenden BPMN-Elemente umgesetzt und manche sogar falsch verwendet, doch dazu später mehr. Viele fehlende Kleinigkeiten, wie beispielsweise die XML-Ansicht oder eine Möglichkeit Properties einzugeben, kennzeichnen den Designer noch deutlich als unfertig, aber das ist in einer alpha Version schließlich ok.

Ein erster Wurf des Ticketprozesses führt zu folgendem Ergebnis:

Das ist ja auch schon sehr ansehlich Auch wenn einige Kleinigkeiten noch nicht perfekt sind, so z.B.:

An den Gateways (Verzweigungen) wird keine Beschriftung angezeigt, auch die ausgehenden Kanten können aktuell nicht beschriftet werden,
Zeilenumbruche in den Aktivitäten sind nicht möglich, was ein Modellieren von links nach rechts, wie in BPDs oft üblich, erschwert wird,
Pools und Lanes sind nicht möglich.

Hier bleibt abzuwarten, was bis zum Release noch alles verbessert wird und wie die entgültige Version aussieht.

Schlimmer finde ich einige Verletzungen der BPMN-Spezifikation die in jBPM 4 versteckt sind. Leider ist es heute wohl etwas hip die grafischen BPMN-Symbole (BPMN-Shapes) zu verwenden es aber mit der Spezifikation nicht ganz so genau zu nehmen, da ist jBPM übrigens in guter Gesellschaft vieler andere Tools. Aus meiner Sicht ist dieses Vorgehen jedoch mehr als unschön, denn der Zweck der Spezifikation ist ja genau die exakte Definition hinter den Symbolen. Hier bin ich aktuell auch noch in der Diskussion mit dem jBPM-Team, auch hier werden wir sehen, wie es in der finalen Version aussieht.

Aber was habe ich denn eigentlich zu meckern. Ich möchte drei konkrete Beispiele anführen:

Ausgehende Sequenzflüsse (Flows, Transitionen) in Activities. Die jBPM-Dokumentation sagt hier:

Dies bedeutet, dass jBPM sich zwischen den zwei ausgehenden Flows für genau einen entscheidet, also eine so genannte XOR-Semantik. Die BPMN-Spezifikation definiert allerdings eine AND-Sematik, also alle ausgehenden Flows werden feuern, außer sie enthalten Bedingungen die nicht erfüllt sind. Was jBPM umsetzt müsste eigentlich korrekterweise als Activity mit folgendem XOR modelliert werden, so wie es in meinem Beispiel oben gezeigt ist. Wird nach der jBPM-Empfehlung gearbeitet aber ohne Gateway nach “Problem bearbeiten” auskommen:

Letzteres ist ganz in bekannter jBPM-Manier und eigentlich sowohl intuitiv als auch in der jBPM-Gemeinde bekannt. Aber es entspricht eben nicht wirklich genau der Spec und ist damit schnell mißverständlich.

Ein weiteres, wenn auch nicht ganz so relevantes Problem, ist in folgender Abbildung visualisiert: jBPM kennt kein zusammenführendes exklusives Gateway (also quasi ein “OR-Join” ). Bei einem exklusiven Gateway wird immer eine Entscheidung erwartet, welcher ausgehende Flow durchlaufen werden soll. Was logisch ist, wenn man weiß, dass dieses Gateway in jBPM die dort bisher so genannte Decision abgelöst hat. Es im Sinne der BPMN zu verwenden erfordert zumindest einen Workaround.

Ein dritter Kritikpunkt ist, dass das terminierende Ende-Ereignis (Der Endknoten mit dem ausgefüllten Punkt) sowohl eine gesammte Prozessinstanz terminieren kann (korrekt!) als auch einen einzelnen Ausführungspfad, beispielsweise in einem Fork (nicht korrekt! Dafür gibt es das “normale” Ende-Ereignis).

Insgesamt noch kein Weltuntergang, aber trotzdem hoffe ich, dass sich hier noch eine korrektere Abbildung der Spezifikation durchsetzt, ich werde es auf jeden Fall anregen. Und schließlich ist bis zur finalen Version auch noch ein bisschen Zeit.

jPDL – Neuerungen

Der modellierte Prozess wird im Hintergrund direkt als jPDL im XML-Format abgespeichert. Das XML ist prinzipiell noch mit dem aus jBPM 3 bekannten Format vergleichbar, jedoch gibt es einige Unterschiede:

Veränderte Namensgebung, an der BPMN orientiert: Transitionen heißen jetzt “flow”, “decision” wird zu “gateway” usw…
Die grafischen Layoutinformationen, in jBPM 3 im gpd.xml abgespeichert, sind jetzt direkt im gleichen XML zu finden,
Es gibt speziell definierte Aktivitäten beispielsweise für die Ausführung von Java-Code. Ementsprechend gibt es dann ein “java”-Element.

Am einfachsten zeige ich hier den oben modellierten Prozess einmal als Quellcode, ein Beispiel sagt schließlich mehr als hundert Worte. Der Prozess ist dabei nur äußert rudimentär ausmodelliert (ich sollte dazusagen, dass ich gerade im Hotel sitze und der Pool ruft), aber bereits lauffähig (Test-Code folgt unten). Auch ist dort mein Workaround für das schließende exklusive Gateway eingebaut.

Was hat sich an jPDL verändert: Einiges, aber doch ist auch viel gleich geblieben. Die Entscheidungen, früher “decision”, jetzt “exclusive” sind eigentlich unverändert. Die bisher bekannten ActionHandler um Java-Code an beliebige Events anzuhängen gibt es in der Form nicht mehr oder sie sind in der Alpha-Version noch nicht verfügbar. Dafür gibt es die “java” Aktivität, bei der eine Methode einer Klasse aufgerufen wird, wobei auch Injection, Parameterübergabe und die Verwertung des Rückgabewertes möglich sind. Auf jeden Fall nett, ersetzt aber die ActionHandler meiner Meinung nach noch nicht.

API

Die API hat sich sehr stark verändert. Die Motivation dahinter war nun aber nicht, den Entwicklern das Leben schwer zu machen, sondern die API möglichst unabhängig von der jBPM jPDL Version zu machen. Im Idealfall entsteht dabei eine API, die von der Implementierung der Engine dahinter unabhängig ist. Zugegeben ein heeres Ziel und auch nicht einfach, aber auch ein guter Ansatz. Übrigens ist diese API zu großen Teilen Schuld, dass jBPM 4 sich etwas mehr Zeit gelassen hat, so eine API aufstellen zu wollen und auszudiskutieren kostet einfach seine Zeit.

Prinzipiell gibt es in jBPM nun die “ProcessEngine” als zentrale Instanz, von der ich mir Services holen kann, wobei folgende eine zentrale Rolle spielen:

ProcessService: Zugriff auf das Prozess-Repository (Prozessdefinitionen)
ExecutionService: Laden, Signalisieren oder verändern von laufenden Prozessinstanzen
TaskService: Zugriff auf Human Tasks
ManagementService: Überwachung und Übersicht über den Status zum Monitoring und Betrieb
(CommandService:) Mit diesem kann ich beliebige Kommandos an jBPM schicken, diese Commands können auch selbst implementiert werden und bieten einen flexiblen Erweiterungspunkt (wie auch bereits in jBPM 3).

Wen das ganze übrigens an das Referenzmodell der WfMC erinnert, das ist kein purer Zufall

Nun aber auch der versprochene JUnit-Test um den Prozess zu testen:

public void testTicket() {
  deployJpdlResource("TicketProcess.jpdl.xml");

  Execution execution = executionService.startExecutionByKey("TicketProcess");
  String executionId = execution.getId();

  execution = executionService.findExecution(executionId);
  assertEquals("Problem bearbeiten", execution.getNodeName());

  List taskList = taskService.getPersonalTaskList("bernd", 0, 10);
  assertEquals(1, taskList.size());
  Task task = taskList.get(0);
  assertEquals("Problem bearbeiten", task.getName());
  assertEquals("bernd", task.getAssignee());

  taskService.submitTask(task.getId());

  execution = executionService.findExecution(executionId);
  assertEquals("Warten auf Feedback", execution.getNodeName());

  execution = executionService.signalExecutionById(executionId);

  assertEquals("end", execution.getNodeName());
  assertTrue(execution.isEnded());
  assertFalse(execution.isActive());
}

Deployment

Die aktuellen Deployment-Optionen sind schnell beschrieben: Es gibt sie noch nicht Wobei das auch nicht die Intension der alpha-Version war. Natürlich wird jBPM 4 auch wieder auf bekannten Tomcats oder JBossen laufen werden…

PVM

Last but not least möchte ich zumindest noch auf die unsichtbare, aber sehr wichtige, Änderung hinweisen: Die Einführung der Process Virtual Machine, oder kurz PVM. jBPM hat eingesehen, dass es nicht die eine perfekte Sprache zur Automatisierung von Geschäftsprozessen gibt, sondern für jedes Problem eigene Lösungen bereit stehen. Daher ist Grundlage von jBPM jetzt die PVM, welche nur die notwendigen Kernabstraktionen für einen Zustandsautomaten implementiert. Die jBPM Process Definition Language (jPDL), welche man meist meint, wenn man über jBPM spricht, baut dann auf der PVM auf und implementiert nur die Besonderheiten der Sprache. Man kann es sich so vorstellen, dass die PVM den abstrakten Zustandsautomat beschreibt und jPDL dann die Knotentypen. Infos dazu sind auch in meinem JavaSpektrum-Artikel zu finden. Interessant hierbei auch, dass die OSS-XPDL-Process Engine von Bull (“Nova Bonita”) in der neusten Version auch bereits auf der jBPM PVM basiert.

Fazit

Ich könnte gerade noch viel, viel mehr schreiben, wenn nicht der Tag bald vorbei wäre und der Pool bald zumachte. Auch in Sachen Web-Console, Reporting und BAM tut sich einiges. Viele Innereien im neuen jBPM sind sehr durchdacht und auf jeden Fall mehr als eine Weiterentwicklung. Der Editor macht bereits jetzt einen netten Eindruck und die Unterstützung der BPMN ist prinzipiell begrüßenswert.

Dennoch gibt es auch Wehrmutstropfen: Die Verletzungen der BPMN-Spec oder auch, dass jBPM 4 noch Zeit brauchen wird, bis die Reife und der Funktionsumfang von jBPM 3 erreicht sein wird. Die ApiDoc ist wesentlich besser als in der alten Version, aber auch immer noch lückenhaft. Einige Exceptions beim Herumspielen mit der alpha Version waren nicht unbedingt sofort selbsterklärend. Durch die vielen Änderungen an Klassennamen oder API’s müssen auch jBPM 3 Cracks auf jeden Fall einiges neu lernen.

Aber ich denke es lohnt sich auf jeden Fall, man muss eben noch ein bisschen Geduld haben. Und das sage ich jetzt nicht nur als Liebhaber und Committer des jBPM-Projektes

Über Feedback & Anregungen bin ich sehr dankbar, gerne hier im Blog, per Email oder auch im jBPM-Forum. Noch kann Einfluss an jBPM 4 genommen werden!