Task Management component?

[aapthorp]

Hi,

Is there any progress on the task management component? Having got the iCalendar wrapper http://www.jboss.com/index.html?module=bb&op=viewtopic&t=131571 I've been working on in to a working state I wondered if some of the workarounds I've implemented are being addressed in the task management component. Looking at the Jbpm 4 source I see some potential answers...

Anyway some comments / questions:

- Is there an example lifecycle.xml for the task module?

- As the iCalendar model allows assignment of more than one actor to a task, I've been trying to figure out how / whether to do this with Jbpm. What is the rationale for limiting tasks to one actor?

- External ids. As I am able to create ad-hoc tasks and initiate a process from a Calendar client I need to be able to retrieve tasks via an iCalendar UID set by an external application. I'm using a process variable for this today, but obviously this is not ideal performance wise. The ability to set an alternate key on a task would be useful.

- Ability to create ad-hoc tasks. I have a workaround for this by creating a very simple process. Is this capability part of JBPM 4?

- Will there be any ability to set a scheduled start date.

I have a few other questions / feature requests for this module but would like to understand current thinking on the above before submitting.

Thanks

[tom.baeyens]

great to hear from you, Adrian,

reading the referenced topic and this items, i still don't get the iCal integration that you are envisioning or have build.

the straightforward way that I would see this integration is to send iCal formatted messages that include the due date when a task gets created. This iCal message would then be send to the assignee so that this person can easily (automatically?) create a reminder in his/her calendar referencing the task created by a jPDL workflow.

but somehow your explanations seem to be referring to some different kind of integration. could you explain that a bit more ?

[aapthorp]

Tom,

The original concept started out as you suggest:

- an action handler to send iCalendar / iTip / iMip notifications to a user via e-mail
- message bean yp handle iTip assignment confirmations / declines returned via e-mail.
- http retrieval of tasks in iCalendar format

and then developed further as I experimented with CalDav and CalDav sched:

- retrieval of task entries via CalDav
- accept / decline / complete / update tasks via CalDav
- creation of ad-hoc tasks via CalDav
- view actor free / busy via CalDav

Apart from the currently limited VTODO (task support) in some clients the potential for extending PIM type apps based on standards for Human Task management is evident (have you come across HumanEdj?). The main limitation is task specific variables and rendering, although I have a few ideas on how to address this e.g. Xforms, XUL extensions. Currently a link to access the task instance via the JBPM console is provided, and for simple tasks the user can signal completion from the calendar client.

As much as possible I've limited the integration to layering the iCalendar model over the JBPM task model and exposing this via e-mail, CalDav and HTTP .ics. The questions I outlined are a result of mismatches between the two models. I've also had initial discussions with CalConnect on limitations in the current iCalendar standards for this purpose.

Hope this answers...

[camunda]

Cool, I am waiting for more :-)

[aapthorp]

Am tidying up an hope to provide a demo version soon.

[kukeltje]

I'd like to go for xforms in any form as well. But serverside xforms. I'm still trying to wrap chiba (https://www.r15z.de/trac, with self-signed cert) into a jsf component that can be used with seam.

[tom.baeyens]

i would guess that much more seam developers are familiar with facelets then with xforms, no ?

[kukeltje]

yes, they do, but we do not go for seam right or jsf/facelets? The console components are GWT, not wrapped in a jsf tag (afaik, maybe just not yet). The issue for taskforms is resolved as rejected in jira. so..... you tell me where this is going?

[aapthorp]

I'm not sure the console comes in to it as I can provide a link to open the task via the console.

The issue / opportunity is to embed / extend the task specific function within the client's iCalendar task context. e.g. when you open and perform the task a task specific form is launched by the client and any updates to task state are managed via the client, with communication back via the CalDav protocol. Of course, separation of rendering from the data is preferred.

I realise this likely requires modification to the client (hence why XUL - for prototyping with Lightning - doesn't help that Lightning doesn't currently support attachments) as well as extensions to the ICalendar model. Hopefully though you see the potential.

Any thoughts on my other questions in my original post?

[tom.baeyens]

"kukeltje" wrote:
yes, they do, but we do not go for seam right or jsf/facelets? The console components are GWT, not wrapped in a jsf tag (afaik, maybe just not yet). The issue for taskforms is <a href="https://jira.jboss.org/jira/browse/JBPM-1835">resolved as rejected in jira</a>. so..... you tell me where this is going?

the technology we build our console in is (should be) unrelated to the technology that we offer to our jPDL users.

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.

and then separately we can decide to build our console in GWT because we think we can build the greatest console in that tech.

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 ?

currently those 2 have my preference.

i'll ask heiko to start a thread with his ideas. so that we can discuss.

[tom.baeyens]

"aapthorp" wrote:
I realise this likely requires modification to the client (hence why XUL - for prototyping with Lightning - doesn't help that Lightning doesn't currently support attachments) as well as extensions to the ICalendar model. Hopefully though you see the potential.

Any thoughts on my other questions in my original post?

i only see a .ical attachment that a tool like outlook (thunderbird?) understands and translates automatically to your outlook calendar. maybe gmail does the same with google calendar.

but i don't see the concrete tools that you are referring to for other forms of integration. could you give a scenario ? something like

1) jbpm sends .ical file as an email attachment to the user
2) user's outlook automatically recognizes the .ical attachment and creates a reminder in the calendar for it and a task in the outlook task list
3) user marks task in outlook as completed.
4) outlook sends task completion response back to reply-address of .ical file
5) upon receipt of that mail notification, the jbpm-reply-email-processor completes the task in the jbpm task component.

of course, this is fictious, but it's in that kind of scenarios that i would like to understand what integrations that you have build.

also i would like to understand which concrete tools that we can integrate that way. the more widespread those tools, the more interesting, of course.

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

[kukeltje]

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)

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

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

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

[heiko.braun]

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 ?

Yes, I do see a problem with that. IMO the forms and the data associated with task management shouldn't be implementation specific. JSF is already a particular implementation and as results cannot be easily used with the console. If we would instead focus on data input and output sets to tasks, backed by a data type description (i.e. xsd) then we could easily build applications that interact with the task management by any means. JSF could then be one of them.

[tom.baeyens]

Facelets is not tied to JSF. It's a template technology. Seam uses it to render emails, for example.