Interesting use case. I do agree that some basic support for more
document management like this could definitely be useful to a lot of
people. These two features you are mentioning, do you see them as
additional node types that you can use in your process if you want to?
Or would this require deeper integration? I think this is a good
example of what is called "domain-specific processes" in the request for
comments (under usability), where the application domain happens to be
document management.
Ideally, I believe most of the features related to document management
should be achieved by providing the necessary integration with a
document management system of some kind, not trying to build similar
functionality closely tied to the process engine itself (like templates,
document management, etc.).
Kris
Hello,
I have seen the architecture model of jBPM 5 and it seems very
complete. Anyway, I don't understand why you do not finish the jBPM 4
designer before developing the jBPM 5 version.
The request I have is based on the introduction of information in the
BPM system. Forms are a good way to map BPM variables, specially if
those forms have validation and are dynamic. This forms are specially
well suited when interacting with external individuals (such as
citizens in a government administration).
But forms are not suited for internal workflow in document based BPM.
Lets say that, for internal work, a user should send a document and
wants the information of this document be processed by the BPM engine
for validation, routing or whatever. In this case the BPM engine
should have two features:
1.- Allow to open a document template, allow to edit it and send it to
the destination of the task.
2.- Map some parts of the text into workflow variables for internal
processing.
The first feature seems to be trivial but the BPM engine should have
some kind of template linked to the task so the user only have to
modify certain parts. For this purpose the BPM should have an HTML
rich editor that can read templates from the workflow definition.
The second feature can be easily done using custom TAGs. For example,
one can write the TAG $<destination_name> in the document wherever the
document should have the name of the destination user. Then, the user
could write the value of the TAG $<destination_name> or optionally
this value could be computed by the BPM engine. This way it is trivial
to map the text content to variables.
The Balearic Islands Government have developed a jBPM 3 opensource
project that allows users to edit documents with Open Office using
templates stored in the tasks. Then users can edit them and FreeMarker
parses the ODF document extracting the values of the variables. I
think it is a good starting point to evaluate document-based workflows.
Here you have a presentation of the project:
http://www.plaanibal.com/c/document_library/get_file?p_l_id=11763&fol...
<
http://www.plaanibal.com/c/document_library/get_file?p_l_id=11763&fol...
http://www.plaanibal.com/c/document_library/get_file?p_l_id=11763&fol...
<
http://www.plaanibal.com/c/document_library/get_file?p_l_id=11763&fol...
The text is in Catalan but slides are self-explaniatiory.
Pau Carré Cardona
------------------------------------------------------------------------
_______________________________________________
jbpm-dev mailing list
jbpm-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbpm-dev