The OpenSymphony team is proud to announce the long awaited release of OSWorkflow 2.8.0
. Primary changes include improved Spring integration, improved Hibernate support, improvements to the Workflow Designer, and a ton of bugfixes.
Release notes can be found at http://www.opensymphony.com/osworkflow/2.8%20Release%20Notes.html
Full download, including sample applications, is at https://osworkflow.dev.java.net/files/documents/635/27138/osworkflow-2.8.0.zip
OSWorkflow documentation, a webstart version of the designer, and the introductory tutorial can be found at http://www.opensymphony.com/osworkflow/
OSWorkflow is a flexible workflow engine designed to be embedded in enterprise applications. It provides support for a number of persistence API's, including EJB, Hibernate, JDBC, and others.
Looks like it is licensed under and Apache style license.
Does anyone know if any open source applications that are currently using OSWorkflow? I would be interested to see examples of how OSWorkflow has been integrated into a realworld application.
Looks like it is licensed under and Apache style license.Does anyone know if any open source applications that are currently using OSWorkflow? I would be interested to see examples of how OSWorkflow has been integrated into a realworld application.
Workflow frameworks have become interesting to me recently. Right now, I'm on a .NET workflow project but we haven't decided to incorporate Microsoft's upcoming WWF(Windows Workflow Foundation). It looks impressive. The tools aren't there yet but I can see how the framework can enable flexible workflow applications.
I'm wondering if we'll see any attempt to provide some standard workflow for the J2EE world?
Uses OSWorkflow for their issue progression. They may be using it in other places as well.
OSWorkflow 2.8 is completely unusable in a highly transactional production system. This point of view stems
from issues with persistence and basic cleanup of runtime
artifacts created in the DB during a given workflow run.
We are using OSWorkflow 2.8 as an internal solution. We found that OSWorkflow creates numerous DB entries during a workflow run. At the completion of a given workflow. These DB entries that are created are never removed. Since our application required that a workflow be run with each network transaction, this resulted in hundreds and thousands of DB rows left over from successive transactions.
The tables of interest are OS_WFENTRY,OS_HISTORYSTEP,
If you look at the JDBCWorkflowStore, you will notice a
method named createEntry(String workflowName),
However what you don't see is a corresponding method,
Our work around, was to add the removeEntry(String aWorkflowName). This method performed the cleanup
of the residual rows in the DB.
Also, the use of primary key generation doesn't make much sense to me when using MySQL as the DB engine. Currently
the primary keys are maintained in a separate table. The WorkflowStore then retrieves the autoincrement sequence
to assign to a given WorkflowEntry and written to the DB.
We cleaned that up so that the primary key sequence is maintained in the same table as the WorkflowEntry. No need to assign an ID to the WorkflowEntry before it's written
to the DB. That's what an autoincrement column does for you.
IMHO, a tool NOT cleaning up after itself is bad software hygene.
It's actually a good thing for a WF product to leave a trail of its work at pretty granular level. This sort of can be crucial for diagnosis and performance tuning.
The question is: is there a purge process available for OSWorkflow?
Fair point, but,after having looked through the code. I seen no purge type code of the WorkflowEntry. That is essentially what the removeEntry should be doing. What I suggested on the OSWorkflow forum is to add
a flag to their initialize method which indicates that a WorflowEntry should be removed or NOT after completion.
The response that I recieved is "write a subclass and remove the entries yourself".
You're right in that entries are not deleted. In 90% of workflow cases, audit history is absolutely vital, and so for the general case, people never want to delete past actions.
So you're right in that the db (history tables) will keep growing. Many industries that use enterprise level workflow solutions expect this and indeed demand it.
So for these reasons, removeEntry will never delete anything. In fact, for these reasons, deletions in the system will not happen. Instead items would just be archived into history tables.
You're right in that the way around it right now is to subclass. However, this is the first time that someone suggests a 'purge' method that does the removal. I have no problem with adding such a method (file an issue!) since it does mean that you can remove stuff if you're really sure you know what you're doing, but doesn't penalise those who need audit trails and the like.
We change the persistence strategy (extends WorkflowStore) for management the persistence myself and improve the performance and we obtain excelent results.
We dont use the osworkflow 2.8.0, but we use osworkflow in a highly transactional production system and it works fine!!!
I have just started to grasp Workflow,BPM etc..concepts!
I have few basic questions :
1. Why OSWorkflow over other solutions like Jboss JBPM or Intalio? I read that OSWorkflow is quite flexible- i am not clear on it.How? Is there any comparision matrix?
2. Does OSWorkflow plan to have eclipse-plugin instead of graph-editor?
3. Which companies are using it ?
We are using OSWorkflow for modelate the transition states of our objects and the actions invoked in this transitions.
We have any state diagrams (UML) implemented in OSWorkflow
I am very happy with OSWorkflow. It is very flexible, adaptable and modificable.
I read that OSWorkflow is quite flexible- i am not clear on it.How?
Is really very easy implement OSWorkflow into your own applications. From definition xml you can simply call your own classes (or Beanshell) where you can simply evalute complicated conditions or call some post or pre-functions. It is not so easy, when you use some 'standard' engine.
What is a 'standard engine' ?
We are using it as well, but use a more simplified workflow definition for readability purposes.
We built our own workflow designer on top of it, same purpose, reduce complexity to end user.
It's been integrated with OpenCMS, an open source WCMS. Not sure of who's using it though.
There is a serious db entries growing problem with osworkflow if you have a loop. When you have a loop, the entries
in os_historystep_prev grows exponentially after each loop,
basically each loop interaction introduces at least the
sum of previous entries + 1 in to os_historystep_prev. In addition, in order to figure join, it has to retrieve all of the historysteps of ALL previous steps, thus if you have a loop, each loop will have to retrieve more and more entries
from os_historystep and os_historystep_prev, leading to
longer and longer response time for the loop. In a loop where the time between loop is short (e.g. 1 min or less), you could
easily have many millions of rows introduced over the cause of just a few days. Does anyone have a solution for this?
For more on what i'm talking about, please look into
the JDBCWorkflowStore findHistorySteps
thanks for any comment on this.
A good article about osworkflow 2.8 integration with hibernate3 : http://www.iptech-offshore.net/blog/?p=48