* Included new HistoryRelated implementation of Assignment API - great contribution by Rich Robinson.
  You can use it by commenting standard AssignmentManager and uncommenting HistoryRelated assignment
  manager entries in Shark.conf (if you are configuring shark this way), and test it with
  Publish Document proces from test-JavaScript.xpdl.

I've attached the latest HistoryRelatedAssignmentManager class and also an updated
version of test-JavaScript.xpdl.

The class now supports the following extended attributes (the names of which
can be redefined in Shark.conf):

* ReassignToOriginalPerformer
* ReassignToOriginalPerformer
* DoNotAssignToPerformerOfActivity

As mentioned in the comments, one of each extended attribute should be
associated with any single activity definition.  If anybody wishes to
extend/modify this class in any way, one obvious improvment would be to allow
multiple copies of each extended attribute to be assigned to a single 
activity.
I would ideally have liked to do this, but I don't need such functionality at
the moment, and unfortunately don't have any more time to spend on it.

In order to get the class working, the following properties need to be 
specified
in Shark.conf:

#
# HistoryRelated assigment manager
#
AssignmentManagerClassName=org.enhydra.shark.assignment.HistoryRelatedAssignmentManager
HistoryRelatedAssignmentManager.username=admin
HistoryRelatedAssignmentManager.password=enhydra
HistoryRelatedAssignmentManager.extAttrReassignToOriginalPerformer=ReassignToOriginalPerformer
HistoryRelatedAssignmentManager.extAttrAssignToPerformerOfActivity=AssignToPerformerOfActivity
HistoryRelatedAssignmentManager.extAttrDoNotAssignToPerformerOfActivity=DoNotAssignToPerformerOfActivity

The XPDL example is a "publish document" process that describes the workflow
that may occur when publishing a web-based document.  Note that in the 
following,
a question mark represents either "1" or "2" depending on which moderator we 
are
referring to:

* Initially, an author creates a document and submits it to two moderators.  
The
"DoNotAssignToPerformerOfActivity" ext attrib is used for each
moderate_document_? activity to ensure that two different moderators moderate
the document and that the same moderator cannot moderate it twice.  

* Each moderator moderates the document and says whether or not it is ok by
setting the values of the moderate_?_ok WRD.  If OK, the moderator then has to
submit the document.  Note that the AssignToPerformerOfActivity ext attrib is
used to ensure that the moderator who moderated the document is assigned the
appropriate submit_document_? activity.

* If either moderator rejects the document, then the author has to update it.
Again, we use the AssignToPerformerOfActivity ext attrib to ensure that the
author who originally created the document has to update it.

* When updated, the author has to re-submit the document using the same
submit_document activity.  We use the ReassignToOriginalPerformer ext attrib 
to
ensure that the author who resubmits the document is the same author that
originally submitted it.

* Finally, when both the moderators are happy with the document, a publisher
reviews it (if he rejects it, we head back to "update document" - in exactly
the same way as if a moderator rejects it).  When the publisher is happy with
the document, he publishes it.  We use the AssignToPerformerOfActivity ext
attrib to ensure that the publisher who publishes the document is the same
publisher that reviewed it.

That's it...  I've tested both the class and the XPDL to some extent, but both
could do with some more testing if anybody would like to do it.

Let me know if you have any questions.

This is probably a newbie question so please be tolerant :-)

I am involved in the development of a system that has a business process management component. The system is based on Spring, Hibernate and Web Work 2. The question is, out of all those available BPM engines, which ones can easily be integrated into other infrastructures? My first impression is that BPM engines designed to be the infrastructure itself, so that functions such as data access, business logic and user interface are specified around it. As opposed to using another infrastructure (in our case, Spring + Hibernate + Web Work) where the BPM engine is merely a component.

--->

I feel that the best way to use a Workflow/BPM system is as a database is : something external that you access with some system users.

I think it should be implemented as an aspect

--->

I am currently building a project using Struts, Spring and Hibernate with OSWorkflow. The current development build (2.8) has built-in support for a Spring / Hibernate environment. In this case, performing an action in the workflow can check against a set of pre-conditions, which can refer to logic in the business layer and can then call some functions if the conditions hold, which can also refer to business logic. This is nice because Spring deals with the dependencies for the conditions and functions. The end result is my business logic is protected by the workflow engine, which prevents any action being performed in the wrong stage of the process.

The only downside of OSWorkflow is that you have to call the workflow action by passing the action's id (an int) and a map of all the inputs to the engine. I'm getting around this by writing an abstraction layer that provides nice method signatures (the business facade) for my struts actions (or any other client). These methods will map to an action id, take all the arguments from the signature and wrap them in a map and call the action.

I hope this is helpful.

Adam

http://www.manageability.org/blog/stuff/workflow_in_java/view

 å¦‚果在Shark中未定义½E‹åºæ˜ å°„åQŒSharkž®†è°ƒç”¨é»˜è®¤çš„ToolAgentåQŒåœ¨Shark.conf中可定义åQ?/P>

RuntimeApplicationToolAgent可执行其它外部程序，比如notepad½{‰ï¼Œæ­¤æ—¶åQŒä¼ å…¥çš„application mode如果ä¸?åQŒåˆ™Sharkä¼?x¨¬)等待应用程序的执行¾l“束åQ›å¦‚果不ä¸?åQŒåˆ™Shark在应用程序开始后ä¼?x¨¬)ç‘ô¾l­æµ½E‹çš„处理åQ?/P>

JavaScriptToolAgent可用于执行JavaScriptåQŒapplication modeä¸?åQŒåˆ™¾pȝ»Ÿž®†æœç´¢åä¸ºapplicationNameçš„æ–‡ä»Óž¼Œæ‰§è¡ŒåQ?

Enhydra JaWE is a graphical Java Workflow Editor according to WfMC specifications supporting XPDL as its native file format. JaWE can be used to edit workflow definitions for Enhydra Shark or every other XPDL conformant Workflow server.