Experience with Drools Flow and / or OSWorkflow?

I am looking for a simple Java workflow mechanism that:

  • can process both automatic and manual (graphical) steps as part of the workflow
  • supports long, asynchronous tasks
  • provides support for restarting workflows in the event of a server failure.
  • stores a complete audit history of previously completed workflows
  • provides easy access to audit history data.

Possible candidates include the new Drools Flow process engine in Drools 5 and OSWorkflow from OpenSymphony. Based on my current understanding, OSWorkflow seems to offer more of what I want (Drools Flow seems to have little audit history); however, the latest release of OSWorkflow was back in early 2006. Is it now possible to use OSWorkflow when it is no longer in active development?

Does anyone have much experience working with both of these structures? Are there any other workflow mechanisms that I should look at? All recommendations are welcome - thanks.

+4
source share
4 answers

Just to clarify how Drools Flow supports the requirements you are describing (referring to the Drools Flow Documentation ):

  • can process both automatic and manual (graphical) steps as part of the workflow

Drools Flow uses (domain-specific) work items (chapter 8) to interact with external systems. These can be automated services or a human task management component (chapter 9) for manual tasks. This component of human tasks is fully connected, but Drools Flow supports the implementation of WS-HumanTask out of the box. Drools 5.1 will include online task lists, including custom task forms.

  • supports long, asynchronous tasks

The engine allows you to run processes that can live for a long time. This process supports various types of wait states (work item nodes, event nodes, event wait nodes, subprocess, etc.) to simulate lengthy processes. External tasks can be integrated synchronously or asynchronously.

  • provides support for restarting workflows in the event of a server failure.

The execution status of all process instances can be easily stored in the data source by enabling persistence (chapter 5.1). Thus, all processes can simply be restored to the state in which they were after a server failure.

  • stores a complete audit history of previously completed workflows

Drools Flow generates events about what happens during the execution of your processes. By enabling audit logging (chapter 5.3), these events can be stored in a database, providing a complete audit history of what happened at run time.

  • provides easy access to audit history data.

History data is stored using several simple database tables. These tables can be requested directly, or you can use them to create custom reports (chapter 12.1) that show key performance indicators that are relevant to your application.

In addition, we believe that a knowledge-based approach that allows you to seamlessly combine processes with rules and event processing will offer you more options and flexibility than the above-mentioned processes.

Chris Verlaenen
Wire flow rolls

+7
source

I had no experience working with the candidates you mentioned, but judging by the projects I worked on, it might be worth a look at jBPM . Quite a lot of the developers I worked with swear by this, and I think it fits your criteria pretty well.

+4
source

Drools Flow is much more complex and powerful than jBPM and OSWorkflow, and development moves faster than either. We offer many details and screenshots: http://www.jboss.org/drools/drools-flow.html

But in the summary. You get interactive debugging through rules, workflow, and event handling. You have a large set of built-in nodes that improves the number of problems that you can directly model declaratively. Correlated (through rules, processes, and events) audit logging and reporting. We provide a very simple and at the same time powerful mechanism for creating a workflow in a domain through our plug-in work items.

Drools 5.0 has just been released, and 5.1 will follow for the next 4-6 weeks. We are adding modeling and testing for this, using the MVEL DSL, which we believe will be a huge hit. This will also include more extensive work for the remote admin GUI for processes integrated into Guvnor.

The Drools team is also proud to be more accessible than any of these other mentioned projects. Feel free to appear in irc for chat.

Mark

+4
source

I have experience with both .. I was also involved in a tool for porting existing processes to OSWorkflow on Drools 5.0. You can read an article about this at: http://blog.athico.com/2009/01/drools-flow-and-osworkflow-migration.html . It is important to note that this migration / translator tool was designed so that older projects using OSWorkflow upgrade to Drools 5.0 and take advantage of the entire Drools 5.0 Business Integration Platform.

Hello

+1
source

Source: https://habr.com/ru/post/1285947/


All Articles