* Added new functionality of handling Deadlines. Shark now has defined client API, and its implementation for handling Activity deadlines. This API is supposed to be used by shark client to periodically ask shark to check deadines. Shark can be setup to re-evaluate deadlines every time deadline check is performed, or to initially calculate deadline times and store it into DB, and when asked to check deadlines, deadline limit is retrieved from DB. Shark comes with an example XPDL processes contained in deadlineexamples.xpdl file, that shows ASYNC and SYNC deadline handling. In shark deadline expressions along with all process variables, you can use special variables called: 1. PROCESS_STARTED_TIME - the time when the process is started 2. ACTIVITY_ACTIVATED_TIME - the time when process flow comes to activity and assignments for the activity are created 3. ACTIVITY_ACCEPTED_TIME - the time when the first assignment for the activity is accepted NOTE: If activity is being rejected after its acceptance, or it is not accepted at all, the ACTIVITY_ACCEPTED_TIME is set to some maximum value in the future IMPORTANT: - There shouldn't be process variables (DataField or FormalParameter entities from XPDL) that have the same Id as the one of previously listed - The Java type of these variables is java.util.Date. - deadline expression result must be java.util.Date - if shark is setup to not re-evaluate deadlines, but to initially evaluate deadline limit times, ACTIVITY_ACCEPTED_TIME should not be used in expressions because it will contain some maximum time in the future. When starting Shark CORBA server, it can be configured if it will open a thread for checking Deadlines.]]>
* New MailToolAgent is included: - in Shark.conf file you have some settings for MailToolAgent (in fact for the DefaultMailMessageHandler) - when calling this tool agent, AppMode 0 means sending and 1 means receiving mail - when calling this tool agent, AppName is the name of MailMessageHandler class to use. We have default implementation of this interface called DefaultMailMessageHandler which needs 3 String IN parameters (destination address, mail subject and mail content) when sending mails, and 1 OUT or INOUT type parameter (message subject) when receiving mails. The example of usage for this tool agent is in test-JavaScript.xpdl -> Mail Handling process.]]>
* 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: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.
Is this distinction real? Should BPM engines logically be the center-piece of the system? Or am I grossly misunderstanding the issues?
--->
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 have implemented a workflow engine before. I made it completely independent of the business objects etc. However, I had to modify business facades to call into the workflow engine; for example, to start a new process for a new request. At this point, I am thinking of doing it as an aspect in Spring, and I believe this will work out nicely.--->
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
]]>
濡傛灉鍦⊿hark涓湭瀹氫箟紼嬪簭鏄犲皠錛孲hark灝嗚皟鐢ㄩ粯璁ょ殑ToolAgent錛屽湪Shark.conf涓彲瀹氫箟錛?/P>
RuntimeApplicationToolAgent鍙墽琛屽叾瀹冨閮ㄧ▼搴忥紝姣斿notepad絳夛紝姝ゆ椂錛屼紶鍏ョ殑application mode濡傛灉涓?錛屽垯Shark浼氱瓑寰呭簲鐢ㄧ▼搴忕殑鎵ц緇撴潫錛涘鏋滀笉涓?錛屽垯Shark鍦ㄥ簲鐢ㄧ▼搴忓紑濮嬪悗浼氱戶緇祦紼嬬殑澶勭悊錛?/P>
JavaScriptToolAgent鍙敤浜庢墽琛孞avaScript錛宎pplication mode涓?錛屽垯緋葷粺灝嗘悳绱㈠悕涓篴pplicationName鐨勬枃浠訛紝鎵ц錛?
]]>
鐪嬩笅闈㈢殑璧勬簮錛?br> 宸ヤ綔嫻佸紩鎿庡疄鐜幫細[shark]
http://forge.objectweb.org/projects/shark/
宸ヤ綔嫻佸浘褰㈢紪杈戝伐鍏鳳細[jawe]
http://forge.objectweb.org/projects/jawe/
Enhydra Shark is a workflow server with a difference. Shark is completely based on standards from WfMC and OMG using XPDL as its native workflow definition language. The Shark framework can be configured to support different environments.
------------
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.
]]>