[jbpm-dev] jBPM 5 User Administration

Brad Davis brad.davis at amentra.com
Thu Sep 2 11:58:18 EDT 2010


Additionally on the tooling side, Oracle BPEL does a great job of incorporating their BPM tooling with JGroups (specifically around users and notifications).

Right now, in jBPM 3 tooling, you have free-form string entry of user names for notification.  If we build the jBPM 5 User Module to have Web Service [SOAP or REST] support, we could start bringing some of this into the fold on our Eclipse tooling.  When you setup your environment in Eclipse, I believe we should have a setting which points to a UAT environment.  This would allow for central configuration of jBPM's tooling, as opposed to the current 3 series, which requires you to point to a specific environment everytime you create a new workflow.

The way they do this in JDeveloper is they allow you to setup multiple BPM environments, configured into the JDevelopers settings directly.  Then, when you pull up the "Notification" node in Oracle BPEL tooling, it has a drop down driven from those settings to indicate where it should pull the users from.  It then provides a drop down in the tooling which allows you to select the user [rather than free form entry].  If we could bring in more interaction between the tooling in Eclipse and live environments, it would really smooth out the process development and really bring jBPM to another level.

Thanks,
Brad

PS. Taking this approach of remotely communicating to live servers to fetch information would also REALLY smooth out the sub-process configuration in jBPM 5.  Currently in jBPM 3, selecting a sub-process is also a free-form text entry, and the tooling is pretty bad.  We should try and address this by having a Web Service interface which can list sub-processes deployed on the jBPM system.  In fact, jBPM sub-process should also be able to define required and optional input parameters and types.  This way, technically the jBPM sub-process itself could generate its own WSDL [one way web service, for example].  This way, the tooling could read the WSDL to prompt users for required information, while also providing an interface for external non-jBPM systems to integrate with jBPM sub-processes.  We can talk through this more later.



More information about the jbpm-dev mailing list