Behavior when next state in a "job" is the same swimlane

[jwooten]

I can't tell from the documentation how to change the default behavior for handling the next state being for the same swimlane in a process. To explain, I as the "initiator" do step1 filling in some information. The next step(step2) is for a user in the role of "mgr". If they select one transition, the next step(step3) will be for the iniator to handle. However, a different transition would be for the "mgr" to add additional information in step4. It would seem that the process would be queued for someone acting in the role of "mgr", but would automatically show the next screen for step4 to the user who is currently logged in with the role of "mgr". I.e. they would not "have" to select the next step from a tasklist. They could choose to cancel step4 and leave it in the queue, but the default would be to present it. The reason is that there might be several "step4" processes queued. They would like, by default, to continue on the one they were processing.

Is this available in the design? Is it prohibited because of pessimistic locking or is optimistic locking used?

Thanks,

[kukeltje]

Wrong forum, but close. This is a pure ui issue and has nothing to do with the core. If you develop your own ui, you could check if there is a new task for the current user in the same processinstance as the last task that was acted upon. If so, display that, if not, display the tasklist

[camunda]

Yeah, a pattern that can be applied often and is currently under discussion with some of my "consultant colleagues" ;-)

SHIL - Service Human Interaction Layer :-)

As soon as I have time I will write something about it on our homepage (www.camunda.com). As Ronald described, you can just handle it in your interface. If it gets asynchronous you can even wait if a task shows up for the same user in a couple of seconds...

[jwooten]

I'm at the stage where we have a working process and a console that drives several processes. Again, I want to figure out how to create the action or code that would cause the next task queued for the same user to be brought up without having to click in the queue. I created a JSF tag that was like completeTask except it returns the id of the next task IF it is for the same user. I'm trying to figure out how to "redirect" so that a new task gets loaded.

I've been having very good success (with some agony) of morphing the jbpm-console into a useful "application", instead of a demo, that can have several business processes available and gives users of the processes a good experience. A few new tags and some customized pages with "tab" behavior, etc. have made it very useful. The use of the JSF and s4j tags makes it easy to test and retest without starting and stopping the server or having to redeploy the console ( I use Eclipse with my workspace pointing to the unzipped jbpm-console.war and alter it there ). The only time I have to start and stop the server is when I add a class to the console, of course. Business processes are deployed as usual to the console.

While many have stated that one should roll their own application, etc. I feel that the jbpm-console was a very good starting place and a general console is exactly the approach to take rather than separate applications.
It has taken some time to work though how the tags work, what the model for execution is, etc., but it's worth it. Thanks for the help!

[kukeltje]

While many have stated that one should roll their own application, etc. I feel that the jbpm-console was a very good starting place and a general console is exactly the approach to take rather than separate applications.

To some extend yes, but the use of gravel... hmmm...

But... have you seen the new console? Initial checkins are in svn. The idea stays the same, it is not end-user targeted, but it is completely redesigned to be in line with other JBoss console apps.

[jwooten]

Not sure how to get to them to check them out. Is there an RTFM on this?

[kukeltje]

http://www.jboss.org/community/docs/DOC-11184 and then the developer documentation, especially the IDE thing.

After that, see https://www.jboss.org/community/docs/DOC-12879

[heiko.braun]

I've been having very good success (with some agony) of morphing the jbpm-console into a useful "application", instead of a demo, that can have several business processes available and gives users of the processes a good experience. A few new tags and some customized pages with "tab" behavior, etc. have made it very useful. The use of the JSF and s4j tags makes it easy to test and retest without starting and stopping the server or having to redeploy the console ( I use Eclipse with my workspace pointing to the unzipped jbpm-console.war and alter it there ). The only time I have to start and stop the server is when I add a class to the console, of course. Business processes are deployed as usual to the console.

Not "end-user" targeted is wrong. The aim of the new console to provide a proper solution for the most common jBPM use cases. If you are interested in contributing or "shaping" the task management functionality, then I'd gladly here about your ideas.

[kukeltje]

Heiko,

The aim of the new console to provide a proper solution for the most common jBPM use cases.

Most common 'end-user' *BPM* usecases were (almost all) supported in the older console as well.
- Start processes
- See personal and group tasklist
- act on task (via generated forms)
- (re-)assign tasks

End-user being one of the actors in a process, not jBPM 'customers' in general

What users requested from the console are things like:
- Can I remove/adapt/change menus
- Can I customize look and feel (sometimes even per process)
- Can I customize forms
- Can I have taskbuttons be displayed or not based on e.g. transition conditions in the task (guarded transitions)
- Can I integrate my own (JSF/seam) backingbeans
- Can I go directly to the next task if it is in the same swimlane
- ... and more

Some of these could be put in the console, but many of these kinds of customizations make it hard to upgrade to e.g. a newer console. If we want to encourage people to do these kinds of changes, it would require a lot more documentation. Besides that, marketing/sales/... can come up with more requirements than we can (should) support in a generic console.

Looking back, the type of 'developers' that wanted to do these kinds of changes, were not the most bright ones or people under a lot of pressure thinking they had a quick win adapting something that is already there. The brighter ones probably were aware of these issues and developed their own UI.

The intention of e.g. jbpm4jsf library would have made it even easier then it already is to create your own webapp. The combination of jbpm4jsf and gravel never took off due to a lack of documentation, promotion and to complex usage. Gravel (ajax?) functionality should have been hidden in jbpm4jsf components. So I still think a component library that directly knows how to interact with jBPM is something that would be/is great to provide.

So my conclusion would be that the target usage of the console would still be:
- RAD (initial demonstration of a process)
- management things.

[camunda]

So my conclusion would be that the target usage of the console would still be:
- RAD (initial demonstration of a process)
- management things.

+1

So I still think a component library that directly knows how to interact with jBPM is something that would be/is great to provide.

+1! But the problem may be, which technology to provide. But I think Facelets weren't such a bad idea...

[tom.baeyens]

"camunda" wrote:

So I still think a component library that directly knows how to interact with jBPM is something that would be/is great to provide.

+1! But the problem may be, which technology to provide. But I think Facelets weren't such a bad idea...

Heiko, do you mean to a JSF or GWT component library that people can use to display the task list in their apps ?

Find a replacement for Facelets for the task forms technology might be difficult given that Facelets is:
* a simple library for template rendering
* rendering can be done easily programatically
* based on XHTML, so easy for users to customize the generated templates

Seam also uses Facelets for rendering the content of emails. That is what I would like to move to as well. Then seam (ui and email) and jbpm (task forms and email) are all based on the same simple technology.

Heiko, do you see a viable alternative for Facelets ? Maybe there is some templating component in GWT ?

[kukeltje]

That was not Heiko, but Bernd, and I agree with him.

JBoss has knowledge about integrating the two technologies since the have some of the Exadel guys on board (Sergey Smirnov, see http://www.theserverside.com/tt/articles/article.tss?l=GWTandJSF)

Seam btw, also has GWT integration, but indeed is more focussed on JSF afaik.

[jwooten]

I've altered my tag so that if the next process is not servicable by the current actor, it sets the outcome via

context.selectOutcome("error");

and in the task.xhtml i have

<mytag:MyCompleteTask ........./> <!-- this will produce the "error" outcome as above.
<n:nav outcome="error" url="home.jsf" />

BUT, it does not use the outcome="error" tag!

Do I have to have a transition on each node that an error might occur?

How can I cause the error nav tag to be "fired"

Still working to get actor able to continue to work as long as next task servicable by them, and to return to "home.jsf" if not.

[jwooten]

Noticed that if I set the context.setError("message"), then the "error" outcome is taken, BUT the process is not advanced. So, although I now know how to get the process to take the "error" nav, it doesn't help because the process isn't advanced.

I'm handling this for a demo by instead just moving to the next task, BUT putting up a message that it is actually queued for another actor. Any ideas on how to do this better?

Next question: When the process ends, I can't find a way to handle it gracefully. IF I could return a nextTaskId of '0' and have a way to handle redirection to "home.jsf", then this would be handled fine. I can return the nextTaskId okay, but can't find a way to redirect.