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

From my point of view, the only part needed to do the integration is a

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 >