[Design of JBoss jBPM] - Re: Cancelling a task fires task-end event
by kukeltje
oh.. and besides that... the patch is so simple (yes I get to grips with the inner workings of jBPM better and better day by day)
in TaskInstance.java change
| task.fireEvent(Event.EVENTTYPE_TASK_END, executionContext);
|
to
| if (this.isCancelled) {
| task.fireEvent(Event.EVENTTYPE_TASK_CANCEL, executionContext);
| } else {
| task.fireEvent(Event.EVENTTYPE_TASK_END, executionContext);
| }
|
and add
public static final String EVENTTYPE_TASK_CANCEL = "task-cancel";
to Event.java.
After that ALL tests still run (hmmmm.... ;-)) so there is NO test on a task-cancel event.... I'll file a jira issue since I do think it should be in a release
Besides that... after analyzing some more code... the end-tasks attribute on the task-node should realy be cancel-tasks (and the corresponding cancel on the tasks instead of end...)
I'll file a separate jira issue for this.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4180673#4180673
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4180673
17 years
[Design of JBoss jBPM] - Re: Cancelling a task fires task-end event
by kukeltje
anonymous wrote : it is almost impossible to come up with a task lifecycle that satisfies all use cases. typically companies have their own view upon the task lifecycle.
Sure, but therefore we should at least support the task-cancel event. I in fact have a real nice use case. For the blog I'm writing an article on 'escalation' of task with lots of info declared in the process definition (that is where it belongs).
The escalation tasks are not any where in the graph, they are separate nodes since they can be called from everywhere. Someone just has to act on it (e.g. changing the priority of the task that is overdue) but I do want this task (the one that is overdue) to just stay where it is. The task that is created this way, e.g. for the manager, is what I call ad-hoc tasks.
Since I cannot act on a transition (there are no outgoing transitions), not on a node leave (the token always stays in the node, it is just ended), I can only run some code on a task-end. In this task-end, I declare that the priority of the task that is overdue should change to a fixed value, or a value set in the task-form. The task-node looks like this:
| <task-node name='task escalated'>
| <task name='escalated task 0' swimlane='escalationSwimlane'
| signalling='false'>
| <!--
| If task has no outgoing transitions,
| signalling gives an error IF
| the task is signalling
| -->
| <controller>
| <variable name='newPriority' />
| </controller>
| </task>
| <event type='task-end'>
| <action class='net.vankuijk.jbpm.utils.ChangeTaskPriority'>
| <taskNodeName>task</taskNodeName>
| <!--
| if the value of priority can be parsed as an int,
| it is used that way,
| otherwise it is tried as a process variable
| -->
| <priority>newPriority</priority>
| </action>
| </event>
| </task-node>
|
But if the task that is overdue is carried out befiore the priority changes, it should be cancelled. That is easy BUT..... the task-end event fires and with the use of a variable priority I can do some checks on the value of the variable, but with a fixed value I cannot differentiate between an end (manager did something) and a cancel...
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4180665#4180665
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4180665
17 years
trying your bpmn editor
by Thomas Diesler
Hi Kris,
is there a way I can use your BPMN editor to draw some basic use cases?
cheers
-thomas
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
BPM Product Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
17 years
[Design of JBoss jBPM] - Re: Process/task search based on variables
by brittm
anonymous wrote : Performant? How performat? Can you be concrete? (Total number of process instances/task instances/new task instances per day/number of concurrent users...)I
Well, certainly performant enough for anything that I would consider a typical task management system. Look at the simple query:
--TASK AGING
| select distinct
| pd.name_ AS process,
| ti.id_ AS task_id,
| tsk.name_ AS task,
| ti.actorid_ as assignee,
| ti.create_ as create_date,
| ti.duedate_ as due_date
| from
| jbpm_taskinstance ti,
| jbpm_task tsk,
| jbpm_token t,
| jbpm_processinstance pi,
| jbpm_processdefinition pd
| where
| ti.end_ is null
| and ti.task_ = tsk.id_
| and ti.token_ = t.id_
| and pi.id_ = t.processinstance_
| and pd.id_ = pi.processdefinition_
| ;
This is a very simply query, and limiting results to those tasks assigned to a particular actor or to tasks from a particular processInstance is obviously trivial. There are only four inner joins on columns that can (or should) be indexed. Add in one more inner join to a "Business Keys" table, and you can return all tasks based on any of your business keys.
If a query this simple is a performance concern, it is because you're truly dealing with many millions of rows or you're returning too many rows at once. I haven't seen a use case for a task management system that would really have many millions of rows, and data returned to a UI from the database should be paginated as part of the query (a user can't visually process more than 20 or 30 rows at a time, so don't force the user or the UI to handle much more than that.)
I don't know really how many "transactions" we've got going on in the course of a day, but I do know that with the simple data relationships in jBPM and our business key table and with the relatively small data sets we're consuming, any performance degradation will be the fault of our own business/UI tier design. For a modern data base, stored row count won't be a practical impact.
Our current application is a Seam/JPA app. We have about 70 group queues with maybe 300 users. We have a particular view in which users can see a series of tabs representing each group queue to which they belong or manage. They can select one of the tabs and will see the tasks in that queue. When a manager selects a group queue to view, in the body of the tab they are presented with two lists of the first 10 assigned tasks and the first 10 unassigned tasks in that queue (each listing is sorted by task priority and due date). If necessary, they can page through the tasks 10 at a time (going back to the data base each time). Each row communicates relevant task data from the task table in addition to customer name, account number, order number, and any associated jeopardy data.
For myself, when I look at this screen (being a universal manager in the system) I see all 70 group queues listed in 70 tabs down the left, each displaying how many unassigned tasks are in that queue. Clicking on a queue to view its tasks (the two tables of assigned and unassigned tasks) seems to take just at 2 seconds regardless of how many underlying tasks there are in the queue.
The view of an individual's personal queue (all tasks assigned to that actor) takes just at a second to present.
Of course any "report view" of the data is exactly that--a report--and the user can be expected to wait several seconds.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4180373#4180373
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4180373
17 years
[Design of JBoss jBPM] - Re: Process/task search based on variables
by frantisek.kocun＠gmail.com
"brittm" wrote : I would second what Ronald mentioned earlier about not trying too hard to store business keys in JBPM. We have a need to be able to look up processes (and tasks) very quickly by any one of various business keys: account number, order number, product number, etc. We created a "Business Keys" table that contains a row for each process instance and records any of the appropriate business key data in the appropriate column. All columns are indexed.
Good idea, I will try it out.
"brittm" wrote : This solution is very performant. Because JBPM has some very direct relationships between processInstance, token, and taskInstance, returning the right tasks based on those business keys is performant as well.
|
Performant? How performat? Can you be concrete? (Total number of process instances/task instances/new task instances per day/number of concurrent users...)I am really interested in this,cos I have never seen jBPM in a big application.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4180341#4180341
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4180341
17 years
