BAM for jBPM

[charlesmnicholls]

I'm looking for jBPM users that would like to share their experiences and requirements for adding Business Intelligence and Business Activity Monitoring as a complement to jBPM. We're are building templates and tight integration with jBPM and would like help in prioritizing our roadmap for the SeeWhy Community Edition. Help here means giving us advice, but you can get more involved if you wish.

You can find more details about this direction at www.seewhy.com/jboss

This capability adds:

* Analysis triggered processes: build ?smarts' into processes by monitoring events
* Real time alerts at process runtime
* Business Activity Monitoring (BAM): visibility of processes executing in real time

If you're willing to participate, and would be happy to share your thoughts and needs please email me at [e-mail]

In advance, thanks for your help

Charles

[kukeltje]

Charles,

I'll try to draw up a more detailed response later this week, but I have at least one question for now. I see in the pictures that you have to define when data is send to seewhy. This could be either a node or an action on a node I presume. But what about the other way around? A long time ago, when we were in the process of selecting an non-foss bpm solution, we looked at one of the BEA products (don't know which anymore since they seem to switch names and implementations more often than M$ has done with dll/com/dcom/activex/.....) They had limited BAM/BI functionality and for that they partnered with a company that retrieved data from the database on a reqular (every x seconds). It had knowledge of the structure and we were told by visiting a satisfied user of that product that this had no major impact on DB performance.

This way, you do not have to change the process when you want to monitor other steps etc.... Any comments on this?

[charlesmnicholls]

Thanks.

You raise a good point, and we need to change the webpage to clarify it. You don't have to put monitoring points in your processes, this is just one way that you can instrument in flight processes.

In short there are four different routes, and the choice is up to you:

1. Publish events from the underlying message transport (JMS or whatever) to SeeWhy. You need to put XML events onto the SeeWhy JMS queue. This can obviously be done with or without a BPM tool being present.

2. Put monitoring points into your processes to put XML events onto the SeeWhy JMS queue (as above).

3. Use the SeeWhy JDBC adapter which can poll a database and create events

4. Use third party software or applicances (such as Goldengate for Databases, Covelight for IP traffic, CastIron etc) to stream events to SeeWhy

SeeWhy is an event driven product which has the capacity to analyze vast quantities of data in real time, and to initiate actions in BPM tools as a result of the analysis. There are clear advantages from going against a stream, rather than a log file, but we are open to the best way to do it specifically in the context of the jBPM integration. There may be a few situations where you want to monitor every node, but the process state data cannot be derived from an underlying event stream. In these cases you either have to go against the log file or you'll need to put a monitoring point into the process.

This is exactly the type of debate I was hoping we'd kick off. If there's universal demand for a log file based approach then we can look at tighter integration in more detail.

I look forward to your any additional thoughts.

Charles