@Kris, <br>good to see that you take a lot of time to answer in a comprehensive way Anatoly's questions. I never have time to sit down and write such a cool mail during or after 10 hours work.<br>I'm still don't agree with him, that is our responsibility to include more high level "cleaner" APIs inside the framework, as you said before this kind of things really varies from one implementation from the other.<br>
As far as I saw in all the implementations that I worked for, they all want to have a layer (thin or not) to abstract the framework APIs, and that exactly where all those mappings, and looping using Flow APIs.<br><br>Talking about ENTITIES and DOMAIN objects, probably we are mixing things here. A Human Task or something similar will be related with the Process and how we can express them, so having a work item ID information as part of the framework or another module information is still good for me. I've seen it in my implementations and it never look as a problem.<br>
<br>By the way, if you store variables, the only thing that you will get out-of-the-box is loading that variables back, but you still need to look for them, or hardcode a special variable name.<br><br>As far as repeating questions, Mark post a funny link with the mailing list rules :)<br>
<br><div class="gmail_quote">On Fri, Apr 9, 2010 at 1:06 AM, tolitius <span dir="ltr"><<a href="mailto:webakaunt@gmail.com">webakaunt@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
@Kris,<br>
<br>
This is probably the most comprehensive and useful answer I ever got on<br>
forums, thank you very much!<br>
<br>
1. I am definitely willing to contribute at any level I can [depending,<br>
of course, on my own skill set, time and interest in a certain area].<br>
<br>
2. Very interesting point about a "shared" session. I somehow<br>
automatically assumed that a "StateFull" session should probably not share<br>
it's state with multiple processes. So, I take it, we can have a<br>
single(ton?) stateful session to execute multiple processes without any<br>
issues? [I guess that is due to the fact that processes are different<br>
threads + "the persistence" is actually per process, and not per session?]<br>
<br>
3. Since what we are working on is a very thin "framework" layer ( to<br>
allow "functional" developers not too worry about Drools Flow specifics +<br>
some high level business-friendly API + ... ), the solution with IDs (<br>
session, processInstance, workItem ) should be hidden from them, hence what<br>
I've been thinking about is some kind of "AbstractWaitingWorkItemHandler"<br>
that will be responsible for persisting these three IDs before the actual<br>
child implementation executeWorkitem() is called.<br>
<br>
Persistence here may be approached as explicitly (DAO) creating a<br>
"WORK_ITEM_ID | SESSION_ID | PROCESS_INSTANCE_ID | BUSINESS_ID" record,<br>
<br>
OR (which<br>
seems a bit more automatic)<br>
<br>
Setting these variables as (I guess process instance) flow<br>
variables, and have Drools Flow Variable Persistence mechanism kick in, and<br>
persist them without any explicit / other "manual crafted help".<br>
<br>
Let me know what you think about the later one, as I understand<br>
you discussed the first approach as an acceptable as well.<br>
<br>
4. As to other approaches you suggested:<br>
<br>
4.a Storing a Business ID (task) as a resulting parameter of the<br>
work item.<br>
<br>
I am not sure I fully understand the idea.. The only thing<br>
that I am thinking it is going to only solve the "work item ID" lookup<br>
problem, but there are also session and process instance IDs. Although it is<br>
definitely a good solution to have an option where framework would link work<br>
items to the associated business IDs outside of the box.<br>
<br>
4.b Having "processInstance.findAllWaitingWorkItems()". I still<br>
think this is a nice one to have: no nodes iterations, no worries about<br>
whether it is a subflow, main flow, etc.. + the process instance ID is<br>
something I would already have, if there is a mechanism to store/retrieve<br>
all the needed IDs once the session is reloaded. But again, if the point "3"<br>
is resolved, no need for "4.b" ( at least for now :) )<br>
<br>
5. As to documentation... Once I figure this problem out, I can<br>
definitely contribute back to documentation.<br>
I understand that "high-level Drools Flow documentation" must not be<br>
the nice thing to hear (especially after a very hard work you did to create<br>
it). Let me tell you that thanks to the existing documentation, I was able<br>
to quickly realize / recognize the true potential of Drools Flow, and a<br>
clear superiority to something as e.g. jBPM. And that is what allowed me to<br>
convince people to use the product.<br>
However... :) Once I started to actually implement the business<br>
requirements, that is where I had to look back to source code in order to<br>
figure out how to: "signal events", "reload a JPA session and continue",<br>
"relationship between session, workitems, process instance", "spring<br>
integration", "exception handling", "dynamic sub-process dispatch" (thanks<br>
to your answer), "configuring GWT console, BAM, ...", "DbLogger<br>
configuration", "true multithreading on split", etc.. just something I<br>
recalled from the top of my head.<br>
<br>
6. As far as "repeating same questions": I learned this in Ubuntu<br>
community some years ago, where it worked, and by no means my intention was<br>
to upset anybody, but to have a healthy discussion ( the one where<br>
participating parties do not have to necessarily agree by the way, hence<br>
"discussion":) ). Will definitely check out IRC channel, did not think of<br>
that.<br>
<br>
Your answers are always to the point, and make sense, for that, again, I am<br>
really grateful.<br>
<br>
Thank you,<br>
/Anatoly<br>
<br>
P.S. Still fully convinced that DOMAIN objects / ENTITIES should be<br>
completely agnostic of by what framework they are used by. Hence no<br>
correlation framework related data (Drools Flow work item IDs, Spring / Seam<br>
bean IDs, Mule ESB connector types, etc...) should be part of these BUSINESS<br>
entities. :)<br>
<font color="#888888">--<br>
View this message in context: <a href="http://n3.nabble.com/Resuming-the-Flow-SESSION-ID-PROCESS-INSTANCE-ID-WORKITEM-ID-tp607507p707660.html" target="_blank">http://n3.nabble.com/Resuming-the-Flow-SESSION-ID-PROCESS-INSTANCE-ID-WORKITEM-ID-tp607507p707660.html</a><br>
</font><div><div></div><div class="h5">Sent from the Drools - User mailing list archive at Nabble.com.<br>
_______________________________________________<br>
rules-users mailing list<br>
<a href="mailto:rules-users@lists.jboss.org">rules-users@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/rules-users" target="_blank">https://lists.jboss.org/mailman/listinfo/rules-users</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br> - <a href="http://salaboy.wordpress.com">http://salaboy.wordpress.com</a><br> - <a href="http://www.jbug.com.ar">http://www.jbug.com.ar</a><br> - Salatino "Salaboy" Mauricio -<br>