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

[tolitius]

@Kris,

    This is probably the most comprehensive and useful answer I ever got on
forums, thank you very much!

    1. I am definitely willing to contribute at any level I can [depending,
of course, on my own skill set, time and interest in a certain area].

    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?]

    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".

          Let me know what you think about the later one, as I understand
you discussed the first approach as an acceptable as well.

    4. As to other approaches you suggested:

            4.a Storing a Business ID (task) as a resulting parameter of the
work item.

                  I am not sure I fully understand the idea.. The only thing
that I am thinking it is going to only solve the "work item ID" lookup
problem, but there are also session and process instance IDs. Although it is
definitely a good solution to have an option where framework would link work
items to the associated business IDs outside of the box.

            4.b  Having "processInstance.findAllWaitingWorkItems()". I still
think this is a nice one to have: no nodes iterations, no worries about
whether it is a subflow, main flow, etc.. + the process instance ID is
something I would already have, if there is a mechanism to store/retrieve
all the needed IDs once the session is reloaded. But again, if the point "3"
is resolved, no need for "4.b" ( at least for now :) )

    5. As to documentation... Once I figure this problem out, I can
definitely contribute back to documentation. 
       I understand that "high-level Drools Flow documentation" must not be
the nice thing to hear (especially after a very hard work you did to create
it). Let me tell you that thanks to the existing documentation, I was able
to quickly realize / recognize the true potential of Drools Flow, and a
clear superiority to something as e.g. jBPM. And that is what allowed me to
convince people to use the product. 
       However... :) Once I started to actually implement the business
requirements, that is where I had to look back to source code in order to
figure out how to: "signal events", "reload a JPA session and continue",
"relationship between session, workitems, process instance", "spring
integration", "exception handling", "dynamic sub-process dispatch" (thanks
to your answer), "configuring GWT console, BAM, ...", "DbLogger
configuration", "true multithreading on split", etc.. just something I
recalled from the top of my head.

    6. As far as "repeating same questions": I learned this in Ubuntu
community some years ago, where it worked, and by no means my intention was
to upset anybody, but to have a healthy discussion ( the one where
participating parties do not have to necessarily agree by the way, hence
"discussion":) ). Will definitely check out IRC channel, did not think of
that.

Your answers are always to the point, and make sense, for that, again, I am
really grateful.

Thank you,
/Anatoly

P.S. Still fully convinced that DOMAIN objects / ENTITIES should be
completely agnostic of by what framework they are used by. Hence no
correlation framework related data (Drools Flow work item IDs, Spring / Seam
bean IDs, Mule ESB connector types, etc...) should be part of these BUSINESS
entities. :)
-- 
View this message in context: http://n3.nabble.com/Resuming-the-Flow-SESSION-ID-PROCESS-INSTANCE-ID-WORKITEM-ID-tp607507p707660.html
Sent from the Drools - User mailing list archive at Nabble.com.