Customized jBPM A customized version of jBoss jBPM was built to be part of a collection product. jBPM was customized to allow creation of collection workflows and to cover our business requirements. Its respective Eclipse plug-in was also changed. The whole source-code is available at: http://sourceforge.net/projects/jbpmlhs/ Basically, the following changes were performed: | For Eclipse plug-ing: | | | -> Allowed Events shall be selected from a drop down list; | | | | -> Allowed Actions shall be selected from a drop down list; | | | | -> Allowed Tasks shall be selected from a drop down list; | | | | -> Conditions defined using GUI; | | It was added the capability to define the conditions parameters of 'Condition Nodes' through a GUI, instead of edit the workflow process definition XML. | | | | -> Timers defined using GUI; | | | | -> Usage of Properties file; | | In order to allow selection of events, actions and tasks mentioned above, it was added the capability to read from a property file theses object names (it is possible now to configure a XML file into jBPM Preference page of Eclipse with the list of possible actions, tasks and events). | | | For jBPM Engine: | | | -> jBPM Asynchronous Message Queue handling; | | Current jBPM implementation of modules that execute expired timers (Scheduler) and asynchronous actions (Command Executor) are not thread safe. This could lead to bottlenecks in production environments once only one thread can be used to process queues (timer and asynchronous actions). | | New solution for processing of queues uses a concurrent process where a thread will get all data from the database and add them to a queue. Some threads working together concurrently will process this queue. | | | | -> jBPM Timers; | | Timers’ implementation for jBPM has a major drawback, start date of timer is always the date that timer is created. So, a configurable start date cannot be used while creating timers (in other words, it is not possible to configure another date instead of timer creation date). | | Requirements would not be fulfilled because of this drawback and for that the jBPM timer was modified to support a reference date. Using the start date the system automatically calculates the date when should be executed. The timer is created on the chosen event of the node where it was defined. | | | | -> jBPM Log; | | In order to get a complete history of workflow processing, new values for JBPM_LOG.CLASS_ column were added (there were not specific values for workflow processing cancelation or suspension, for example). | | | | | For further questions, please post them into this forum. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4111257#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...