[Design of JBoss jBPM] - Re: Task Management component?
by kukeltje
"tom.baeyens(a)jboss.com" wrote :
| the technology we build our console in is (should be) unrelated to the technology that we offer to our jPDL users.Hmmm... what about eat your own dogfood? Maintaining multiple frameworks is not handy (e.g. what about the tasklists besides the forms)
"tom.baeyens(a)jboss.com" wrote :
| we can offer facelets to our users to build task forms if we think that is the easiest technology for our jpdl users to work with.Yes, might be true
"tom.baeyens(a)jboss.com" wrote :
| and then separately we can decide to build our console in GWT because we think we can build the greatest console in that tech.Also not against this
"tom.baeyens(a)jboss.com" wrote :
| a consequence of taking both decisions would be that we have to show facelets task forms in a GWT based console. but i don't see a problem with that. do you ?This is where I have no clue and hijacked this thread (sorry about that btw) since it probably is a problem because the exact issue I was refering to was about this and it is rejected....
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4195162#4195162
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4195162
15 years, 5 months
[Design of JBoss jBPM] - Re: Task Management component?
by aapthorp
Tom,
Firstly in terms of the tools, in theory it should be any calendar agent that supports the iCalendar RFCs (2445,2446,2447) and also CalDav(RFC 4791) and the draft caldav sched http://en.wikipedia.org/wiki/List_of_applications_with_iCalendar_support. Of course there is variation in the level of support. In particular support for tasks (VTODO) is not yet as strong as events (VEVENT) in these tools - a workaround is to use events. I've been testing with Thunderbird/Lightning, Evolution and Kontact. Google Calendar and MS Outlook should work. Also, mobile device support for these standards is evolving.
Now to scenarios. The one you present is the basic scenario.
Other Scenarios:
Task Assignment
1) Task gets assigned to an actor
2) Actor is notified of assignment via e-mail with task invitation
3) Actor accepts / or declines task
4a) If actor accepts then proceeds as per your example scenario.
4b) If actor declines then decline message sent to server and depending on task assignment model the task can be reassigned automatically or manually.
Variation: Tasks assigned to a pool
1) Pool members are notified of opportunity to take task via e-Mail invitation.
2) First pool member who accepts invitation will send an accept message.
3) When the server receives the accept message, it will assign the task to the accepting actor and send cancellations to the remaining pool members.
Variation: Cancellation
1) Once a task has been accepted, it may be cancelled by a manager and cancellations sent to all invitees.
Scenario: View assigned tasks
Another simple scenario (for which I posted the code in JIRA some time ago) is the user can set up his task list in the calendar agent using standard HTTP get to query.
1) User queries task list via HTTP client
2) The user can then see all tasks allocated to him/her in the Calendar.
3) The user clicks on a URL in the task can link to the specific task in the JBPM console.
4) User performs task.
Scenario: View FreeBusy time for an actor
As viewing assigned tasks but a manager queries an actors tasks and is returned the free busy time for the actor (i.e. what the actors task loading is).
All of the above scenarios are also possible with CalDav (a WebDav extension). This allows individual manipulation of task entries if required; create, update and delete.
Scenario: Create ad-hoc task
1) User creates task for self or others using Calendar agent.
2) Task is created in JBPM via CalDav.
3) Invitation sent to to other actor via e-mail or CalDav. (Not Implemented)
Scenario: Initiate simple process / task (this needs more thought)
1) The user creates task in calendar agent and selects a category (process name).
2) Request sent to JBPM via CalDav.
3) Process initiated, tasks linked to parent process (not implemented).
Scenario: Task specific form embedded in calendar / task list entry (this is the question in the current thread - not implemented)
1) As per viewing task entry
2) Actor opens task form in Calendar / Task agent
3) Actor performs task and updates task form.
4) Updated task form and task details sent back to server via CalDav (could also be e-mail I guess).
5) Task updated and calendar entry refreshed.
I think that covers all the main scenarios. I have a few more in mind, but would like to get the above fairly robust. The last one being the main open one.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4195158#4195158
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4195158
15 years, 5 months
[Design of JBoss jBPM] - Re: task component interface comments
by alex.guizar＠jboss.com
Creating tasks without a user-provided ID is a must for usability. The generated ID will be the database ID converted to string.
As for task creation, I concur with Joram that (ab-)using the setters for a fluent interface goes against the JavaBeans design principles. Introducing a set of methods called withXXX to the Task interface is also a no-go because they mostly duplicate the setXXX methods.
I propose introducing a TaskBuilder buildTask() method to the TaskService, and move the withXXX methods to TaskBuilder. Actually I'd prefer to drop the "with" prefix, as follows.
Task task = taskService.buildTask()
| .name("test")
| .dueDate(today)
| .asignee(me)
| .done();
TaskBuilder does not even have to be an interface, because it simply delegates to methods in the Task interface.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4195136#4195136
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4195136
15 years, 5 months
[Design of JBoss jBPM] - Creatiing new pooled actors for every task instance
by stringaling
Hi,
I have noticed that for every new task instance that contains an assignment to a pooled-actor within a process, there are new entries added to the jbpm_pooledactor table.
This behavior is a wee bit undesirable, as we end up creating a rapidly growing large table with very redundant records.
The table contains a 'VERSION_' field which would seem to indicate that at least some thought might have been put into doing this differently.
Is there any plans to work on assignment in upcoming releases ? Or is this just how it is going to work for a while ?
Example of my assignment:
| <task name="Manual Address Review">
| <assignment pooled-actors="WD User"/>
| </task>
|
(The same behavior exists with swimlanes)
The source of my concern is trying to improve performance when getting a task list for when there are a large number of outstanding tasks. The number of joins required to do this is expensive, and could possible be reduced if there was a consistent ID for pooled actors in the JBPM_POOLEDACTOR table.
(Couldn't these assignments, actors be determined and setup at the time of process deployment, rather then as part of creating a task instance ?)
Thanks,
David Stringer
(Jboss 4.0.5, Jbpm 3.2.2, Java 1.6, Oracle 10g)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4195127#4195127
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4195127
15 years, 5 months