Finding tasks efficiently using ContextInstance?

[johnu]

The TaskMgmtSession class has several methods for finding tasks belonging to "actors" - either individual actors or many at a time.

BUT... is there a way to efficiently find tasks using the values in context variables?

Let me elaborate... I have tasks assigned to users. Each task relates to a Customer (a POJO persistable by Hibernate). I store Customer objects in the ContextInstance associated with each ProcessInstance. jBPM persists my Customer objects and I can examine them later when I retrieve the tasks. So far so good.

Now... I want to list all active tasks, in any process, for a specific customer (e.g. custNumb = 123). Is there an efficient way?

The seemingly inefficient way is to retrieve all active processes, retrieve the ContextInstance, retrieve the variable named "customer" and examine the context to see if the Customer.custNumb == 123.

Thanks
John

[kukeltje]

or write your own hibernatequery

[tom.baeyens]

good question.

you can do this with a hibernate query. you'll have to learn a bit about how jbpm stores the variable instances for that.

the idea is that we provide a few basic queries as examples in the context session.

we also have been thinking about a kind of criteria api... but i don't see yet what kind of features and how we could build such an api in a convenient way.

regards, tom.

[paolodt]

Q:

The TaskMgmtSession class has several methods for finding tasks belonging to "actors" - either individual actors or many at a time.

BUT... is there a way to efficiently find tasks using the values in context variables?

A:

you can do this with a hibernate query. you'll have to learn a bit about how jbpm stores the variable instances for that.

Is this still valid or exists a better way to do that?

Thank you. Paolo DI Tommaso

[kukeltje]

Define better? Hibernate queries are used anyway, either implemented by 'us' in the context or by you externally. The former has not happened yet (as you can see in the api) thus the latter is still valid

[michaelok]

Why not define a custom table, that extends off of one of the jbpm ones?

Disadvantage: you are building a customized version of jbpm, and these tables may change in future. But then, you may need to change a customized Hibernate query anyway.

[kukeltje]

why, why, why is everybody making workarounds, changing things, being afraid it won't be compatible etc..etc..etc IF

they can just implement it as a feature/enhancement to jBPM, submit it as a ' patch' and get in it integrated into the core... EVERYBODY happy

[michaelok]

Of course, good point, I'm in my "commercial software" mindset I guess. This is the "That's how we've always done things" sort of thing.

Fair enough, this will certainly be a consideration. Even as far as a decent Use Case, as I have seen in other situations with open source, that the core group seem to find a much better way to implement anyway, but at least to get the ball rolling, this would be something.

[kukeltje]

I should have put a smiley in my post like this: ;-)