BPMN 2.0 data associations discussion

There's some discussion going on about some of the details in the BPMN 2.0 specification, more specifically the use of the process data input and process data outputs.

One of the issues of using an XSD to check the validity of an XML file (as the BPMN2 specification provides), is that the XSD does not express all the constraints that a process must fulfill to be valid. A lot of constraints are expressed in the narrative sections of the specification. That's why Bruce Silver is working on a profile for BPMN interoperability (BPMN-I) that could be used to check additional constraints, with the goal of achieving true interoperability between different vendors by making a lot of the "hidden" rules explicit.

During that work, Bruce (I hope he doesn't mind me calling him Bruce, maybe I should say Mr. Silver based on my appreciation for the work he has done and is still doing in this area ;)) discovered some discrepancies (or at least some confusing statements) in the specification itself when it comes to the use of process data inputs in relation to data input associations. I'm not going to try and explain the issue in detail, I would like to refer the readers that might be interested in the details to his blog and the followup blog, as it contains all the details, including numerous references to the spec itself and a discussion on the topic. But to make a long story short:

Can a process data input be used as the source of a data input association of task that is contained inside the process?

Since Bruce is asking for input from other interested parties, and jBPM is offering a BPMN 2.0 engine, I thought I'd give it a try. But since I couldn't find a way to put all this information and picture as a reply on his blog itself, I decided to write this blog entry and include my reply here (and to avoid splitting up the discussion I would suggest to add comments related to this topic on his blog as well). And at the same time I can invite other readers to give their 2 cents as well ;) So here it goes:

It seems to me, from reading the specification, that data input and output associations are meant to be "local", by which I mean they are not intended to be referenced from outside the element in which they are defined. On top of that, it also seems to me that they are intended to be "immediate" or "instantaneous" (not sure this is the best term but I couldn't come up with a better one at this point), meaning they are "executed" when they are reached, but they don't exist anymore after that.

Therefore, I would agree with your statement that process data inputs should not be the source of a data input association, as the process data input association only exists when the process is invoked and at that point, that data input association is executed. [I also believe that using a process data input when the process is actually started by a timer start event confusing, as it's unclear where this information would come from, but that's another issue.]

So how would you use your process data inputs in the remainder of your bpmn2 process then? I think the ioSpecification of the process, that contains these process data inputs, should also contain data output associations that map these data inputs to more persistent (as opposed to immediate or instantaneous) item-aware elements like a property or a data object. These can then serve as the source of other data input associations. So you don't directly use a process data input as the source of a data input association of (for example) a task, but you rather first map the process data input to a property using a data output association (as part of the process ioSpecification) and then use this property as the source of the data input association of the same task.

A screenshot of this in a real process is shown below (note that I deliberately chose a slightly different example to avoid using a start timer event in combination with a process data input as this makes it only more confusing):

You don't often come across people with such an in depth knowledge of how ioSpecifications in BPMN2 actually work, so I must admit I enjoyed reading the discussion so far ;)

Drools & jBPM Workshops (May 2011) - New York and Washington DC

After JBoss World we have two Drools and jBPM5 workshops in May for New York and Washington. These are free events open to all in the public:

The events will be a mixture of talks with lots of time for questions and discussions.

Speakers:
Mark Proctor - Drools co-creator and Project Lead
Kris Verlaenen - jBPM Project Lead
Edson Tirelli - Drools technical lead.

Event: New York - Registration page and agenda
Date: Tuesday, May 10, 2011
Time: 8:30am – 5:30pm (breakfast, lunch, afternoon snack provided)
Cost: Free but register as seats are very limited.
Location: Affinia Manhattan Hotel
371 Seventh Avenue,
New York, NY 10001

Event: Washington - Registration page and agenda
Date: Thursday, May 12, 2011
Time: 8:30am – 4:00pm
Cost: Free but register as seats are very limited.
Location: Renaissance Washington
999 Ninth Street, NW
Washington, DC 2000

JUnit testing your jBPM5 processes

Even though business processes aren't code (we even recommend you to make them as high-level as possible and to avoid adding implementation details), they also have a life cycle like other development artefacts. And since business processes can be updated dynamically, testing them (so that you don't break any use cases when doing a modification) is really important as well.

When unit testing your process, you test whether the process behaves as expected in specific use cases, for example test the output based on the existing input. To simplify unit testing, jBPM5 includes a helper class that you can use to greatly simplify your junit testing, by offering:

• helper methods to create a new knowledge base and session for a given (set of) process(es)
  • you can select whether you want to use persistence or not
• assert statements to check
  • the state of a process instance (active, completed, aborted)
  • which node instances are currently active
  • which nodes have been triggered (to check the path that has been followed)
  • get the value of variables
  • etc.
    

For example, conside the following hello world process containing a start event, a script task and an end event. The following junit test will create a new session, start the process and then verify whether the process instance completed successfully and whether these three nodes have been executed.

public class MyProcessTest extends JbpmJUnitTestCase {

   public void testProcess() {
       // create your session and load the given process(es)
       StatefulKnowledgeSession ksession = createKnowledgeSession("sample.bpmn");
       // start the process
       ProcessInstance processInstance = ksession.startProcess("com.sample.bpmn.hello");
       // check whether the process instance has completed successfully
       assertProcessInstanceCompleted(processInstance.getId(), ksession);
       // check whether the given nodes were executed during the process execution
       assertNodeTriggered(processInstance.getId(), "StartProcess", "Hello", "EndProcess");
   }
}

Testing processes that don't interact with the environment like this one are really easy to test but in general aren't that realistic ;) Real-life business processes typically include wait states, invocation of external services, etc. One of the advantages of our domain-specific process approach however is that you can easily specify different implementation of the node depending on the context. This means that, when you are unit testing your business process, you can register test handlers that can be used to verify whether specific services are requested correctly, and provide test responses for those services. For example, imagine you have an email node or a human task as part of your process. When unit testing, you don't want to send out an actual email but rather test whether the email that is requested contains the correct information (for example the right to email, a personalized body, etc.).

The following example describes how a process that sends out an email could be tested. This test case in particular will test whether an exception is raised when the email could not be sent (which is simulated by notifying the engine that the sending the email could not be completed). The test case uses a test handler that simply registers when an email was requested (and allows you to test the data related to the email like from, to, etc.). Once the engine has been notified the email could not be sent (using abortWorkItem(..)), the unit test verifies that the process handles this case successfully by logging this and generating an error, which aborts the process instance in this case.

public void testProcess2() {
   // create your session and load the given process(es)
   StatefulKnowledgeSession ksession = createKnowledgeSession("sample2.bpmn");
   // register a test handler for "Email"
   TestWorkItemHandler testHandler = new TestWorkItemHandler();
   ksession.getWorkItemManager().registerWorkItemHandler("Email", testHandler);
   // start the process
   ProcessInstance processInstance = ksession.startProcess("com.sample.bpmn.hello2");
   assertProcessInstanceActive(processInstance.getId(), ksession);
   assertNodeTriggered(processInstance.getId(), "StartProcess", "Email");
   // check whether the email has been requested
   WorkItem workItem = testHandler.getWorkItem();
   assertNotNull(workItem);
   assertEquals("Email", workItem.getName());
   assertEquals("me@mail.com", workItem.getParameter("From"));
   assertEquals("you@mail.com", workItem.getParameter("To"));
   // notify the engine the email has been sent
   ksession.getWorkItemManager().abortWorkItem(workItem.getId());
   assertProcessInstanceAborted(processInstance.getId(), ksession);
   assertNodeTriggered(processInstance.getId(), "Gateway", "Failed", "Error");
}

You can configure whether you want to execute the junit tests using persistence or not (by default using an in-memory H2 database which is started by the junit test itself and by using a history log), simply by passing a boolean whether you want to use persistence or not when calling the super constructor.

We will extend the set of out-of-the-box assert statements over time, but if you do need additional assertions for your use cases, you can already extend the set yourself by looking at the implemention of the existing ones and simply tweaking where necessary. And let us know if you create some reusable ones, we'll add them to the code base!

If you combine these test features with the advanced debugging capabilities, (as for example shown in this screencast) you can use this to walk through the process one step at a time and figure out what's happening internally. We're working on extending this even further to support full simulation and testing capabilities. This would allow you easily define and run various test scenarios, replay an execution log, etc. The foundation is already there (like a simulation clock and the definition of execution paths), but we're still working on the user interface that would make this useable by not just developers but also business users.

jBPM at JUDCon and JBoss World in Boston in May

The first week of May is going to be busy this year!

First, there is 2 days of JUDCon, May 2 - 3. JUDCon is an event by developers, for developers. I attended JUDCon Berlin last year and it is a great place for developers to learn the details of different technologies and meet the core developers and other community developers out there. Presentations will include a range of deep technical dives into JBoss Community projects and related technical topics of developer interest. And the hack fests allow you to do some real coding as well.

There are a handful of jBPM-related presentations, and many many more. Check out the agenda and register today!

Immediate after JUDCon and on the same venue, there is JBoss World and Red Hat Summit, May 3 - 6, where there will be numerous presentations on a lot of different topics, (j)BPM being one of them. We'll be touching on a wide area of from the core engine itself to event-driven BPM and decision management. Details in the agenda, and don't forget to register!