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

[Mauricio Salatino]

Good to see that you are agree with me at least in something..

about your other points:

1
a. As you may know, casting and the use of interfaces let us (in the java
world) provide support for different types of processes. So no matter which
type of processes we are handling this method will always return a
ProcessInstance. In your case you cast to RuleFlowProcessInstance, and
that's ok, but if you have another type of process instance you should use
another interface.
b. I'm not sure what you mean with this, but call a method to get node
instances sound pretty easy to be a developer task.
c. we, as developers, iterate stuff all the times
d. getNodeInstances only returns the wait state, not node in progress.
e. depends on the mechanism that you choose, as you can see the WSHT module
uses a client api to not do that kind of queries directly.

2.
Probably you got this feeling because you think about process like things
that you must continue. In drools flow this is not the common way to think
about processes. Because we consider that processes are smart enough to
continue them selves their executions. I see sub processes in the same way,
it don't think that it's a complication. If you see how WSHT works, you will
see that no matter which process is running (parentflow, subflow,
subsubflow,subsubsubflow) all the human task created will be in the same
human task list to be completed.

I think that these "low level" (for you) APIs are enough because it let us
implement a high level layer, like the one you want for each specific
implementation. The problem with high level layers is that you end up with
something that is not too flexible as the "low level" APIs.

Feel free to implement a high level APIs and create a new project that can
be used on top of drools flow.
Greetings!

On Fri, Apr 2, 2010 at 2:27 PM, tolitius <webakaunt at gmail.com> wrote:

>
> yes, but:
>
> 1. It is too low level to be a true clean / simple client API. Instead of
> something as simple as:
>
>                "process.findWorkInProgress()"
>
>    developers need to know to:
>
>                a. cast the processInstance,
>                b. get a hold of NodeInstances
>                c. iterate over them
>                d. filter out what nodes are in progress
>                e. query DB for the data associated with those nodes
>
> 2. There is no "one view" to all the wait nodes, because of the
> sub-processes, so this solution gets even hairier when there are multiple
> subflows, subflows within subflows, etc..
>
> That is why it is rather odd that you think these low level APIs are
> enough.
>
> /Anatoly
> --
> View this message in context:
> http://n3.nabble.com/Resuming-the-Flow-SESSION-ID-PROCESS-INSTANCE-ID-WORKITEM-ID-tp607507p693482.html
> Sent from the Drools - User mailing list archive at Nabble.com.
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>



-- 
- http://salaboy.wordpress.com
- http://www.jbug.com.ar
- Salatino "Salaboy" Mauricio -
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-users/attachments/20100402/1a237e96/attachment.html