iCalendar wrapper

[aapthorp]

On Koen's recommendation I'm cross posting from my original post on the user forum:
http://www.jboss.com/index.html?module=bb&op=viewtopic&t=131078

I've been exploring the possibilities of leveraging typical PIM / calendar client functionality to manage user task lists assigned through BPM tools such as jBPM using the iCalendar standard. Initially this is to notify users of task assignments via .ics e-mail attachments and to accept or decline a task. In addition to this is a query capability that allows http access from a calendar agent.

I now have this basic functionality prototyped around jBPM with mapping between taskInstance fields and iCalendar VTDO properties. As per my original post there are a few properties with no obvious equivalents in jBPM (e.g. location and scheduled start time) and am using process variables for these for now. The jBPM console URL to the task is sent in the invitation allowing the user to open the specific task instance.

I'm currently testing using the Zimbra mail server, KDE Kontact and Mozilla lightning which have varying degrees of compliance to iCalendar RFC 2445. Going beyond this would be mobile useage, but haven't explored this yet.

Further down the line I'd like to explore extension of the user agents to handle task specific functionality.

I'd be happy to post the query servlet with mapping to progress this and align on the correct mappings between iCalendar and TaskInstance...potentially identifying extensions to jBPM??? I originally based the iCalendar mailer on the current jBPM Mail class but found that this wasn't sufficiently extensible for MIME attachments, so this may need looking at again.

Cheers

Adrian

[fady.matar]

I must say this is a very useful feature that we planned to do as a notification engine where by task notifications would be one feature of it, other notification types could be initiated on process instantiation, process termination, bam notifications, etc...

Regarding mobile notification , I believe you're talking about SMS notification you can have a look at the SNMP protocol a number of messaging gateways have been implemented there.

Posting the code wouldn't be harmful can you do that?

Cheers,
Fady

[koen.aers]

Damn, I should learn to use preview... :-s

"fady.matar" wrote:
I must say this is a very useful feature
[snip]
Posting the code wouldn't be harmful can you do that?

I agree. It would be good to create a JIRA issue for this that we can use as a vehicle to attach code and maybe some design overview document.

Adrian, would you mind creating this and explain a bit more the overall architecture of your work? Is there a place where we can already play with it?

Tom, how do you think we could include this work in our project?

Regards,
Koen

[tom.baeyens]

Adrian, thanks for cross posting, cause this is the first time i see it :-) Great initiative.

First you have to get a contributor's agreement signed. Once that is done, it doesn't really matter how you contribute it. In a jira, here on the forum or directly in the code.

Koen could you take responsibility for getting this contribution ? It would really fit into the overall notification strategy that we have discussed. I think that it is easier to include the code only in a new separate notification component targetted for jPDL 4.

[koen.aers]

"tom" wrote:
Koen could you take responsibility for getting this contribution ? It would really fit into the overall notification strategy that we have discussed. I think that it is easier to include the code only in a new separate notification component targetted for jPDL 4.

Yes I will work with Adrian to get this done.

It would certainly be good to create a new component for jPDL 4 for it. But Adrian has done this for jBPM 3 at the moment, so I think it would probably be good to create some subcomponent there and include it in the source tree. It will give us some concrete way of seeing how it works and what is necessary.

What do you think?

[kukeltje]

A component? Why? Shouldn't it just be part of an assignment mail? Maybe configuring in jbpm.cfg.cml whether you want an iCalendar part in the message or not (the default being no)

[tom.baeyens]

kukeltje, you exactly describe how jpdl should expose it. one option (as we did it before) is to put all those kind of components in the jpdl project.

jbpm can integrate with about anything. keeping all those library dependencies manageable is difficult. some of these integrations like email, jcr and probably ical require whole specific test environments.

merging all of that into the jpdl project can become a problem. that's why i'm thinking of extracting it into separate projects.

but jpdl will still just use it and expose those features as it pleases.

and it's definitely not decided yet. it might go as well into the jpdl subproject directly. i'm just sketching the context so that you (and all other readers) can shed their light on this topic

[aapthorp]

Glad to see this is of interest. I'm currently travelling and will provide more details when I return.

A couple of clarifications. I have a prototype message bean to handle inbound iCal attachments...I was wondering about modelling a process to manage task assignment states (e.g. assigned, declined, accepted etc). Something I see jBPM deliberately avoids.

Also, regarding mobile notifications I was referring to calendar sync to blackberries, etc (message push) and the like.

cheers

Adrian

[kukeltje]

@Adrian,

jBPM does not (imo) avoid assignment states at least not at the technical level. The technical level being jbpm, the businesslevel the processdefinition.

Some explanation: You can see if a task is assigned to a person or a group. You can see if it is started, suspended, resumed and ended. Declining a task can be seen as reassigning it back to the pool (if there is one). Declining something at the businesslevel would mean taking a certain transition. Something that is logged as well.

@Tom:
I agree, not to many nodes, functionality where it belongs and making things pluggable (a real good idenity module being (imo) the most important one). Mail could be extended as well to support mime (so html messages can be send), but I'm not even sure jBPM should do all this. Why not leave some functionality up to other SOA parts. ESB conatains mail sender as well. Why not put services in there? But that is another discussion

[tom.baeyens]

@Adrian: i an curious to know more about what you call "bean that handles inbound ical attachments".

In the new pvm, the task states will be managed by a pvm process.

push synchronization with mobiles is not ready yet, i think. Funambol has a good server, but i don't think that the carriers let companies run their own syncML server.

@Ronald: i want jBPM to be self contained. jBPM should package and bundle all of this. If things could be developed and shared together with the ESB the better. But right now, it doesn't yet look that way.

I would like email to be brought in sync with SEAM. Facelets templates, html email,...

[kukeltje]

Tom.

The binary could include all. The source does not need to.... A big difference in my opinion.... Just like we use facelets, seam, etc.... just reuse would be a big plus already for me.

[aapthorp]

"kukeltje" wrote:
jBPM does not (imo) avoid assignment states at least not at the technical level. The technical level being jbpm, the businesslevel the processdefinition.

I was alluding to the statement in the user guide that assignment is not part of the task lifecycle. Tom mentions PVM managing task states being managed by a PVM process. This sounds like what I'm looking for.

"kukeltje" wrote:
Mail could be extended as well to support mime (so html messages can be send), but I'm not even sure jBPM should do all this.

This is effectively what I have done in order to send a calendar/text mime body part. I also wonder if jBPM should do this or if a mail node is strictly part of jBPM. One might imagine other notification channels. To me this is part of an extended portal architecture (but that's another discussion...). As my original intent for developing the wrapper was to validate some thinking around the potential to leverage iCalendar for business tasks I haven't thought too much about this.

"Tom" wrote:
i an curious to know more about what you call "bean that handles inbound ical attachments".

Currently this a message bean that listens on an IMAP mailbox for iCalendar/iTIP replys that acknowledge or decline a task assignment. This is rather rudimentary at the moment. Again you might argue that it would be better for this to be integrated via ESB, but I want to explore the limits of mapping iCalendar to jBPM.

[tom.baeyens]

"kukeltje" wrote:

"Tom" wrote:
i an curious to know more about what you call "bean that handles inbound ical attachments".

Currently this a message bean that listens on an IMAP mailbox for iCalendar/iTIP replys that acknowledge or decline a task assignment. This is rather rudimentary at the moment. Again you might argue that it would be better for this to be integrated via ESB, but I want to explore the limits of mapping iCalendar to jBPM.

We are thinking about exactly that. And then even parsing the response message so that tasks could be completely performed through an email interaction. If the initial email contents would be generated something like this:

Please provide following details:
Amount:
Date:
Owner:

Then the user can reply and fill in the requested data. that could then be parsed and used as the task input.

[kukeltje]

One might imagine other notification channels. To me this is part of an extended portal architecture (but that's another discussion....)

Yes, but a fundamental one...

Then the user can reply and fill in the requested data. that could then be parsed and used as the task input.

I wonder if most Security officers would allow this without the messages being digitally signed. I know the company I work for would only allow this for unimportant task done by consumers

[aapthorp]

I've now logged a feature request in Jira with sample code for servlet access and to highlight the mappings. Hope this is correct.

Then the user can reply and fill in the requested data. that could then be parsed and used as the task input.

Something along these lines...although I was exploring how this could be done with iCalendar VTODO constructs.

I wonder if most Security officers would allow this without the messages being digitally signed. I know the company I work for would only allow this for unimportant task done by consumers

I would expect any channel is subject to the same security considerations...but of course some are more flawed than others....