Feature Request - global lists API

[simonbaker]

It seems unusual that jBPM API has methods to get lists of TaskInstances by actor / groups, but no global (complete) list. It makes it difficult to get a complete list for doing your own filtering.

This applies to other objects as well. If we look at these objects as comprising a collection, it is natural to expect to find an iterator over the collection.

Such global lists are useful for monitoring, troubleshooting, and many production cases, such as implementing a special user role who can work on anyone's tasks for any workflow, or filtering a task list by an arbitrary group of users.

It seems like it would not be hard to implement in many cases, such as for TaskInstance. Can this feature be considered for an upcoming release?

The main objects of interest would be TaskInstances and ProcessInstances.

[kukeltje]

it is not realy unusual. to generic lists are dangerous (performance wise) and filtering walking through the objects is relatively slow etc... jbpm is extensible (databmodel is open) and writing custom/proprietary queries is *not* bad practice. That is one of the reasons these global lists have not been requested by others (therefor not 'unusual')

For troubleshooting, try the hibernate plugin in eclipse. You can query the database easily. You can file a jira issue for this and see if it is accepted or not.

[simonbaker]

OK, but although the db model is open, developers would prefer to have an API that is database neutral and basically hides the persistance layer for ease of use. For small companies like ours, it is expensive to maintain code at the database level. And in general, when a new version of jBPM comes out, custom code for the old version can be a nightmare to integrate in the latest.

I agree you don't want to abuse the "getAllTaskInstances()" type of call for performance reasons, but I have worse situation now. To get all the task instances, I'll have to make a list of all actor ids and, I guess, call "TaskManagementSession.findTaskInstances(List actorIds) which is I suspect a fairly inefficient query.

However, I know I'm new at jBPM so I'd like to learn more about extending it. For example, if I wanted a "getAllTaskInstances()" method, would the best approach be to add my query to the "hibernate.queries.hbm.xml" file (does that mean learning Hibernate generic SQL?) and coding a new method, say "TaskManagementSession.getAllTaskInstances()", following the example of the similar methods? Or is there a better place to hang custom code?

I realize those last questions belong in the user forum.

[jeffdelong]

Yes, the best way is to create a new hibernate query as you suggest. You can us the existing ones as a starting point, adding, or in your example, deleting where clause parameters.

This is a great use of the underlying architecture - using hibernate queries in this fashion.

[simonbaker]

Isn't it quite hard to maintain a customized jBPM as new versions come out? You'd have to keep track of every change or addition to the code, and make them all over again -- or is there a better practice?

[camunda]

In my opinion the best place for your own java code is then a own Command (Command Pattern is introduced in jbpm 3.2.x), for example there exists a

org.jbpm.command.GetTaskListCommand

You can now extend this one to implement your own behaviour and create your own hibernate query.

For the Command pattern you just have to implement a method:

public Object execute(JbpmContext jbpmContext) throws Exception

[simonbaker]

Thanks, I'll look into that.

I'd like to pursue the jira feature request also. Which jira is for jBPM?

[kukeltje]

http://jira.jboss.com/jira/browse/JBPM

and using hibernate makes it db independent.

[estaub]

Camunda,
You wrote:

In my opinion the best place for your own java code is then a own Command (Command Pattern is introduced in jbpm 3.2.x)...

Is this because you are using a J2EE EJB interface?
If not, why do you think this is good way to develop extensions?

Thanks,
-Ed Staub

[camunda]

YOu can use the Command's with a Java-EE-facade.

But even if you don't use it, I think it is a very handy place for own code. And it is quite nice encapsulated. You can use it easly also without a Java-EE-Facade (just hand in a JbpmContext), so you are completly flexible with the environment.

Also there are alraedy Commands which you can use as a starting point.

More or less the "normal" advantages of the Command pattern (ask Google for advantages ;-)).