shark 工作流引擎新特性 HistoryRelated assigment

shark 工作流引擎新特性 HistoryRelated assigment

shark 新特性:

*  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.


方向:分布式系统设计

你可能感兴趣的:(shark 工作流引擎新特性 HistoryRelated assigment)