Anatoly,
I've not been able to check the user list for about a week, and it seems
you have been wondering about this issue for a while, so let me try to
summarize a little. I'm sure I won't be able to answer all questions in
one email, but I'll give it a shot ;)
First of all, your use case seems to be that you want to write your own
handler for managing human tasks, and that is just fine, the system is
implemented to support this. That said, what you are trying to do is
(from an architectural perspective) probably quite similar to how we
implemented the default human task service implementation (and handler
associated with it). So recommendations to take a look at that are
probably very good ones, you might not be able to reuse code directly,
but understanding how that works might give you a better understanding
of your own use case as well.
So how does it work? It's actually not that difficult. A work item is
created when some unit of work needs to be executed externally (either
synchronously or asynchronously, like for example a human task that
needs to be performed by a human actor). That work item is then handed
to the work item handler for execution. The work item handler should
simply notify the session when that work item has been completed using
ksession.getWorkItemManager().completeWorkItem(..). How you do that is
totally up to you.
But let's take a look at a human task service as an example. Basically,
what usually happens is, when a work item is passed along for executing,
some kind of user task is created somewhere (in a persistent manner) so
that, whenever the human actor uses some kind of human task client to
access his task list, the task will show up there. Since you decided to
not use the default implementation, you're completely free in deciding
how to do that. There is however one important integration point, as
the engine needs to know when the task has been completed (to continue
the flow). So you need to make sure that, if the human actor somehow
indicates that the task has been completed, that you notify the session
that the task has been completed using
ksession.getWorkItemManager().completeWorkItem(workItemId, results).
Only one question left I think: what is this ksession and what is the
workItemId?
First about the ksession: this all depends on your architecture,
basically how many independent instances of the engine are you running?
For example, if you use a centralized process engine, you for example
only have one session (executing all processes), which is active all the
time. That session is for example registered in JNDI, can be accessed
as a web service, or whatever. If you have multiple sessions (like for
example on session per active user), than the session you are looking
for could either be already active (in which case you have some session
pooling mechanism, so you should use that) or you should recreate the
session from the state that was persisted in the database last time it
was active. To do that, you need the session id. The session id is
usually linked to the context (e.g. if you have one session per user,
user-id and session-id are linked and should be stored somewhere for
lookup in case the session needs to be restored).
Next, the work item id. This is simple, as whenever a work item needs
to be executed, it has a unique id. When it has been completed, you
need to use that id to tell the engine to continue. So how do we know
this workItemId? There are numerous options:
a) Set workItemId as a property of the user task. This is what we do
in our implementation, we just create a human task and that object
contains the workItemId, so whenever the task is completed, we simply
take the associated workItemId and tell the engine. Now it seems that
your use case would not allow you to store the workItemId as part of the
user task that you are creating (you seem to indicate that this would be
a terrible choice, to add low-level data like this to your domain
objects, but you shouldn't see it like that, your domain objects don't
need to know what it means, it's just a way to add correlation data).
Too bad, as that is the easy solution, but still, no harm done.
b) In this case, I assume that your user task object has some kind of
unique id as well. So we need to make sure that we can map that unique
task id back to the workItemId. Since you refuse to put the correlation
info in your domain objects, two alternatives are left: put it in the
work item (our model) or put it in neither of the models but store the
correlation external to both models
* In theory it is possible to simply store the unique task id as a
(result) parameters of the work item, so it gets stored as part of the
work item object. If a task has been completed, you should look up the
work item that has a task id parameter equal to the one that has been
completed, and then complete that work item. Problem with this approach
is that it is not a common use case (at least, from what we've seen so
far), so our implementation does not provide a simple interface you can
use to do that. It is possible though, and if you're interested, we can
try to assist you (if you're willing to contribute back ;))
* Another simple alternative is to simply store the mapping
external, just create a simple table that maps the work item id to the
task id. And use this table to look up workItemId if a task has been
completed. Not exactly the most difficult job to implement that in a
work item handler I assume. If you cannot store the workItemId as
correlation data in your domain model, this would probably be my second
best choice. Again, if you're interested, we can try to assist you (if
you're willing to contribute back ;))
So, I don't think you really need a
"processInstance.getActiveWorkItemNodes()" method. Because, even if you
had that, you would still need to know the processInstanceId (and if you
know that, might just as well include the workItemId there as well) and
you still wouldn't be able to figure out which one it is you actually
need if there are multiple active. But even if this method would be all
you ever needed, sure, the api is all there to do what you need. You
probably want to hide the details by using a utility class, but the info
is there. Do we provide this out of the box? Currently, no, sorry. We
try to follow the 80/20 rule, hoping our implementation supports 80% of
the use cases. The other 20% can use the lower level api to do what
they need. And it's so easy to use a utility class or wrap the current
implementation that it might not even be worth the effort. As the use
case of the next user is always slightly different, so we would end up
with a zillion of similar methods to inspect runtime state, while we
already provide access to this as a POJO tree (though, coming to think
of it, a visitor pattern could definitely work out here). But, again,
if you're interested, we can try to assist you (if you're willing to
contribute back ;))
Finally, try to be patient, and be gentle to the people that are trying
to help you on this list ;) Most of them do it in their spare time and
for free. Simply repeating questions several times won't necessarily
help, people will try to help you if they can, and if no-one seems to
know the answer, there's always the option to come and chat to the
developers on our irc channel ;) I also noticed you are trying to help
other people, and that is much appreciated. And if you have feedback on
how to improve our "high-level Drools Flow" documentation, I'm all ears !
Kris
Quoting tolitius <webaka...@gmail.com>:
>
> my point exactly.
>
> "state" IS there in framework's ProcessInstance AND in framework's
> WorkItem,
> hence it IS a framework concern [it is a framework DSL]. Therefore it
> needs
> to be addressed by straightforward clean and simple APIs.
>
> /Anatoly
> --
> View this message in context:
>
http://n3.nabble.com/Resuming-the-Flow-SESSION-ID-PROCESS-INSTANCE-ID-WORKITEM-ID-tp607507p694317.html
> Sent from the Drools - User mailing list archive at Nabble.com.
> _______________________________________________
> rules-users mailing list
> rules-users@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm
_______________________________________________
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
