[rules-users] Resuming the Flow: SESSION_ID, PROCESS_INSTANCE_ID, WORKITEM_ID

[Kris Verlaenen]

4>    2. Very interesting point about a "shared" session. I somehow
> automatically assumed that a "StateFull" session should probably not share
> it's state with multiple processes. So, I take it, we can have a
> single(ton?) stateful session to execute multiple processes without any
> issues? [I guess that is due to the fact that processes are different
> threads + "the persistence" is actually per process, and not per session?]
Yes

>    3. Since what we are working on is a very thin "framework" layer ( to
> allow "functional" developers not too worry about Drools Flow specifics +
> some high level business-friendly API + ... ), the solution with IDs (
> session, processInstance, workItem ) should be hidden from them, hence 
> what
> I've been thinking about is some kind of "AbstractWaitingWorkItemHandler"
> that will be responsible for persisting these three IDs before the actual
> child implementation executeWorkitem() is called.
>
>         Persistence here may be approached as explicitly (DAO) creating a
> "WORK_ITEM_ID | SESSION_ID | PROCESS_INSTANCE_ID | BUSINESS_ID" record,
>
>                                                                OR (which
> seems a bit more automatic)
>
>         Setting these variables as (I guess process instance) flow
> variables, and have Drools Flow Variable Persistence mechanism kick in, 
> and
> persist them without any explicit / other "manual crafted help".

I believe the first option (explicitly creating an entry in a table that 
maps all these ids) will be easier.  The second approach (persisting as 
process variables) is also possible but:
 - could result in conflicts (variables containing ids being overridden) if 
you have multiple tasks
 - there's no "clean api" to support automatic retrieval of a process 
instance based on variable values
 - performance of the first approach will be better I think

>    5. As to documentation...
Documentation is always difficult as it takes a lot of time to write, and as 
a developer I usually make assumptions and don't see the issues new users 
are faced with.  Was thinking about creating a new policy: for every 
question I answer on the mailing list or irc, the user that I helped should 
try to improve the documentation so that the next user will find it easier 
to do the same ;)

Kris 


Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm