[jbpm-dev] Features and jBPM 5

[Brad Davis]

Notification
==============
By making this a more generic interface, it will be interesting to see  what the community does.  We have one client who is using a 3rd party tool to notify workers through Text to Speech through a headset driven by jBPM.  Pretty cool.
Other notifications I can think of off the top of my head: Jabber.

Audit Logging
==============
I think we could just pass all Audit Logs into a queue.  However people want to process from that Topic is their business ;)  We are doing this at one client with a large throughput.  The benefit is that their secondary system which processes from the Queue can be responsible for the CPU needed to persist and also display [through a custom UI] the audit logs. OOTB, we could offer a listener to the Topic which can persist to the DB.  Another which may listen to the topic could be responsible for analytics such as throughput.  As the system scales, since these listeners would be standalone, people could move them off the default instance for performance sake.

Web Editor
===============
I think by providing an advanced, rich Eclipse development environment, we will come out ahead for sure.  Sure, it might look nice for presentations; but the minute there is a product bakeoff at a large customer, I imagine that will not stand up.  

That said, a lot of our customers do ask if Workflows can be imported from Visio -- which the Business users generally are using.  Maybe they are targeting it for this purpose.  Regardless, developers always will have to get involved.  Also, I have never seen this as a deal-breaker when it comes to a company adopting the technology = low on the feature list in my opinion.


Brad







-----Original Message-----
From: Alejandro Guizar [mailto:aguizar at redhat.com] 
Sent: Friday, May 28, 2010 1:21 PM
To: Brad Davis
Cc: jbpm-dev at lists.jboss.org
Subject: Re: [jbpm-dev] Features and jBPM 5

The notification framework is a compelling proposal - the ability to
send a message as an email, or alternatively as a fax, SMS, pager or
even a social network, through a regular interface is quite valuable.
This is the kind of feature that differentiates proprietary and open
solutions.

As for offloading audit logs to a separate DB, I don't know what would
be best, relying on the persistence framework capabilities (e.g.
Hibernate Shards) as we have discussed previously, or design with a
secondary DB in mind. The former should be more flexible.

JBoss Cache: this is already going into the platform. This will serve as
an early experience.
https://jira.jboss.org/jira/browse/SOA-1406

Cluster-ready timer executions: noted. The EJB timer service solution
did not make this requirement, but the other two solutions in the
platform did (JCA inflow, Quartz).

I share your opinion on the web designer, the Eclipse/desktop
alternative is richer, more reliable and overall better, with one
exception - the web designer makes for more dramatic presentations. I,
for one, was impressed the first time I saw it. Devs will soon realize
it is more fluff than stuff (at least in its current state), but if it
helps convince the "business analysts", great.

Lastly, your words, "I fundamentally believe that all our SOA initiative
should start and end in workflow", reminded me of an article I read last
year, where the author expresses a similar thought.
http://www.itbusinessedge.com/cm/blogs/byron/talking-with-pierre-fricke-of-red-hat-about-bpm-and-the-stack/?cs=36694

-Alejandro

El jue, 27-05-2010 a las 09:33 -0500, Brad Davis escribió:
> 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