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