[jbpm-dev] Features and jBPM 5

[Kris Verlaenen]

Brad,

Thanks a lot for your feedback, very valuable ! I see some issues that 
might already be covered with the current roadmap. Some others might not 
necessarily all make it in the first release, but will hopefully make it 
rather sooner than later. I'll start building a list of requested 
features like this (actually, there is one like this for jBPM4 so I will 
extend this).

Kris

Brad Davis wrote:
>
> Here are features that I have seen a need for in jBPM while using it 
> at our various Red Hat clients. These comments are based on the 
> currently supported 3.2 branch.
>
> 1) The ability to create Typed Actions which can be plugged into the 
> Eclipse UI [similar to Drools Flow]
>
> 2) Truly plug-able Identity Management backing to JAAS.
>
> 3) Email Notification should instead be a general notification framework.
>
> a. Oracle BPEL supports this functionality – See: 
> http://download.oracle.com/docs/cd/E11036_01/integrate.1013/b28981/notif.htm
>
> b. Notifications should be sent to secondary service via JMS to ensure 
> that no notifications are sent until the Transaction completes 
> successfully.
>
> c. Out of the Box Email Notification Support for HTML Email and 
> multiple SMTP servers [similar to what was created for jBPM 4]
>
> 4) Reporting; this has been suggested in jBPM 5 blogs.
>
> a. Contact me for specifics; we can questionnaire our clients.
>
> 5) Service layer to more easily create custom UI for processes.
>
> 6) More Complex Form Generation for Tasks via XForms?!
>
> 7) Better Audit Logging configuration OOTB.
>
> a. Ability to offload this from the main database to a secondary store 
> [like warehouse].
>
> 8) OOTB use of JBoss Cache.
>
> 9) Cluster-ready timer executions.
>
> 10) Keep Decision Handler plug-ability.
>
> a. Provide OOTB Drools support.
>
> b. Reuse existing BRMS tooling and provide jBPM Eclipse integration 
> with BRMS?! for Drools Decisions via Wizard.
>
> 11) Bring Maven Support in-house from the current Codehaus offering 
> [http://mojo.codehaus.org/jboss-packaging-maven-plugin/par-mojo.html]
>
> 12) Support Process Upgrades OOTB.
>
> a. If a new Process Definition is added because the previous one is 
> flawed, give users the ability to bring existing processes to the 
> current version from the jBPM console.
>
> From my experience, no one in the field has asked me for support to 
> edit workflows in the browser. If I were scheduling features, I would 
> put this last. It increases the development effort for the product 
> with little payoff. Our true competitors should be seen as Microsoft 
> Biztalk and Oracle ESB/BPEL, not Activiti. There are so many more 
> features we could spend our time on than in-browser workflow manipulation.
>
> Additionally, I fundamentally believe that all our SOA initiative 
> should start and end in workflow. The integration in SOA-P currently 
> for jBPM and back is not ideal. To create a Service, it should be as 
> simple as configuring an input type and output type in jBPM, configure 
> if the process should be request/response or async, and registering 
> within the jBPM workflow the appropriate ESB gateways. So, my 
> suggestion is to pull the gateway concept into jBPM directly. This has 
> worked well for both Oracle BPEL and Biztalk.
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> jbpm-dev mailing list
> jbpm-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbpm-dev
>