look at the sourcecode of the current head. There are .xhtml files for pages to be associated with tasks. These can be complex pages.
little more detail: lool at the example processes in the source
Thank you for your answer.
Not sure whether or not I understand what you mean. Do you mean I have to download the source code and poke around?
For my understanding, a workflow engine with complex human interaction ability should be able to support kind of a human interaction/web form type of Action out of box. I downloaded the starter kit, and read through the user guide, don't see anywhere mention anything about web form, human interaction. Only four examples in the tutorial:
3.1. Hello World example
3.2. Database example
3.3. Context example: process variables
3.4. Task assignment example
3.5. Custom action example
The human interaction I am looking for is not just xhtml page, it's more like the web form built by a MVC framework (e.g. struts, webwork or JFS). It contains an action to load anything needed by the page, a JSP form, an action to handler validation and form processing.
Does jBPM has some built in support for this kind of human interaction Action? I did some research. A lot of workflow engine claims that it's able to handle it. However, none of them can show me a working example how to build a complex human interaction form I just described. I wish jBPM can do a better job.
Which part of the source code should I look at? Does what I am looking for make sense?
The reason I mentioned the source and not the tutorial, is that you wanted complex configurable forms. You have to either build those yourself, including the usage of the jBPM api, or wait for jBPM 3.2. That one is currently under development so only available in CVS.
Out of the box support via a webui of all kinds of different environments is a utopia. The free jBPM in its webbased ui is already as advanced as expensive license based commercial products, so it will probably never fit 100% out of the box.
The ui in CVS is fully JSF based, you can combine this with custom build backingbeans, combine information from jBPM and external systems in it so it will largely support what you need, not fully 100% out of the box, but to a great extend. When this is released, it is more flexible than the UIs of many other.
So please stay tuned or look at the webapp in CVS and the corresponding xhtml files.
Thanks. Guess I have to stay tuned. Wish you guys can make the webform/human interaction stuff generic enough.
The decision using JFS is questionable. JFS mantained too much state information on the server side (or client through hidden field). It is good for certain kind of rich UI. Ideally, user can ke their choice and use different MVC framework to build the webform within the workflow.
I will not go into the 'questionable' thing for several reasons, but the issue of using a different MVC framework is already sloved.
Everybody can use it's own framework of choice. The jBPM api is straight forward.
Besides that the webforms will be generic, but can easily be customized to a great extend.
You might want to take a look to the great Getting Started guide written by Kevin Barfield to grasp the kind of stuff jBPM can do out of the box.
In case you find the jBPM web app unable to render your complex forms, you can browse the JSF pages and backing beans source to see how it uses the jBPM API to query and update workflow-related data.
As Ronald says, there is no issue at all with MVC framework choices because jBPM itself does not rely on JSF. We chose it to build the default web interface, but we might as well have used Struts or any other framework.
The wiki page is very helpful. It should be included inside the user guide.
The JFS based default web interface is very impressive, perform well and very neat. However, feature wise, it is not much different then the workflow engine I used three years ago - oakgrove.
The idea is more like define the workflow context variables and store them as more like a key/value pair. When reaches certain state, by default show the webform with text field for each key, then kind of show buttons for each decision/transition (yes or no). Workflow engine save the context variables and move forward. Everything is driven by the tasklist shown on different user's homepage. Basic monitoring ability is provided.
Good enough to simple automation or basic human interaction (e.g. approval process) workflow. However, for serious workflow, real case senario, a couple of things are missing:
1. more flexible UI control, besides text field, how about text area, drop down manual, etc.
2. better validation, not just required.
3. more important - how to store the context variables into business object and be able to query the business object through reporting. Like the web sales order sample workflow, all the variables are associated with the workflow instance, however, there's no concept of saving/creating an order business object.
I think to build a generic form builder and be able to design the whole complex workflow driven web application is more like a fantasy, so hard to achieve, e.g. validation, backend validation, form processing, etc. However, there should be some better support from the workflow engine level. For example, may need some seperation between automation task and human interaction task. For automation task, it's more like run through a piece of code. The human interaction task is the self contained webform with data loading, form presentation, validation and form processing. I did not see this kind of seperation from the jBPML.
Again, not sure if I am on the right track or asking for too much. You guys are definitely doing a great job, however, for my oppinion, there's a long way to go. Wish I have more time and can contribute something.
For now, I still think jBPM is useful. My web application will be loosely coupled with the workflow engine. Everytime needs a decision where to go, query the jBPM engine through API. A lot of customized code. How it works, not sure.
1: that's what 3.2 is going to, you can define your own input types for variables. 3.1 just renders everything as a textinput
2: Look at the Jira, there is an issue for it, so it is on the list. Care to help out?
3: That is the real challenge, and the one where (afaik) all bpm vendors fail to a certain extend. We, the company I work for, also need this. The thing is that our developers tend to want to use spring-mvc instead of jsf. So I have to convince them and we might be able to contribute something on this level. If you have some ideas on how to solve this, we might take this subject to the developer list or even create a Jira issue for this.
The separation of automatic vs human interaction is fully supported by jBPM. (JDPL is the definition language, not jBPML). A generic node can be used for this. Look at the documentation and/or testcases.
hth a little and thanks for the compliments.
Thanks Ronald. I will try to find some time. Hopefully, I can give you guys some help.