I’m looking for a straightforward Java workflow engine that:
- can handle both automated and manual (GUI-based) steps within a workflow
- supports long-running, asynchronous tasks
- provides support for restarting workflows in the event of a server crash
- stores a full audit history of previously executed workflows
- provides easy access to this audit history data
Possible candidates include the new Drools Flow process engine in Drools 5, and OSWorkflow from OpenSymphony. From my current understanding, OSWorkflow seems to offer more of what I want (Drools Flow doesn’t appear to store much in the way of an audit history); however, the most recent release of OSWorkflow was back in early 2006. Is it a mistake to now use OSWorkflow when it’s no longer under active development?
Does anyone have much experience with either/both of these frameworks? Are there any other workflow engines I should be looking at? All recommendations welcome – thanks.
Just to clarify how Drools Flow supports the requirements you are describing (refering to the Drools Flow documentation):
Drools Flow uses (domain-specific) work items (Chapter 8) to interact with external systems. These could be automated services, or a human task management component (Chapter 9) for manual tasks. This human task component is fully pluggable but Drools Flow supports a WS-HumanTask implementation out of the box. Drools 5.1 will include web-based task lists, including custom task forms.
The engine allows you to start processes that can live for a long time. The process supports different kinds of wait states (work item nodes, event nodes, event wait nodes, sub-process, etc.) to model long-running processes. External tasks can be integrated synchronously or asynchronously.
The runtime state of all process instances can easily be stored in a data source by turning on persistence (Chapter 5.1). Therefore, all processes can simply be restored in the state they were in after a server crash.
Drools Flow generates events about what is happening during the execution of your processes. By turning on audit logging (Chapter 5.3), these events can be stored in a database, providing a full audit history of whatever happened during execution.
The history data is stored using a few simple database tables. These tables can be queried directly, or you could use it for generating custom reports (Chapter 12.1) that show the key performance indicators that are relevant for your application.
Furthermore, we believe that a knowledge-oriented approach, allowing you to seamlessly combine processes with rules and event processing whenever necessary, will offer you more power and flexibility compared to aforementioned process-oriented engines.
Kris Verlaenen
Drools Flow Lead