4:30 p.m.
I'm trying to determine 'where' a process is (not the active/completed/
etc. state), but the wait state.
One way of doing this (and tracing the process execution) would be via
a RuleFlowEventListener; however is there a way to query a
ProcessInstance (or something?) for this information?
Effectively I want to know which EventBasedNodeInstances are triggered
for a process and waiting for a response.
Use case is to show in a user interface what the process is waiting
for (i.e. loan approval, timeout, some confirmation).
Furthermore, I am confused as to where a process resumes after being
marshalled from db back into memory. I can see that there is a
'reconnect' method which gets called, but it looks like the
implementation of this calls the start Node again!?!
Thanks,
Garrett
7:16 a.m.
There are several ways of doing this.
1. Using the audit log
You can log the execution events so they can be queried later. The
drools-bam module contains a WorkingMemoryDbLogger that logs these
events to database, so you can easily query them.
2. Inspecting the process instance itself
You can get all active node instances from the process instance itself
by casting it to a WorkflowProcessInstance. Note that this will only
contain info about the currently active node instances, no history
information, but it seems that's exactly what you're looking for. The
Eclipse plugin and gwt-console also use this approach to show the active
nodes in a process instance during execution.
3. Custom event listener
If the above methods are insufficient, you can just implement your own
listener and extract the info you need.
Regarding reconnect, that simply reconnects the process instance to the
engine, nothing more. The engine will then continue by sending the
right triggers to that restored process instance, for example an
incoming event, a work item that has been completed, a timer that has
been triggered, etc. So the engine will restore and reconnect a process
instance if a trigger for that process instance comes in but the process
instance is no longer in memory.
Kris
Quoting Garrett Conaty <garrett(a)conaty.net>:
I'm trying to determine 'where' a process is (not the
active/completed/
etc. state), but the wait state.
One way of doing this (and tracing the process execution) would be
via
a RuleFlowEventListener; however is there a way to query a
ProcessInstance (or something?) for this information?
Effectively I want to know which EventBasedNodeInstances are
triggered
for a process and waiting for a response.
Use case is to show in a user interface what the process is waiting
for (i.e. loan approval, timeout, some confirmation).
Furthermore, I am confused as to where a process resumes after being
marshalled from db back into memory. I can see that there is a
'reconnect' method which gets called, but it looks like the
implementation of this calls the start Node again!?!
Thanks,
Garrett
Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm
10:58 a.m.
Outstanding. Thanks for the help on this.
Was enjoyable to trace through the code, a nice event-driven state
machine.
Question on JPAProcessInstanceManager.getProcessInstances. I see that
it returns an empty array, which I suppose makes sense otherwise it
would load every process instance from the db?
What is the recommended strategy for keeping track of active processes
that need to be loaded into a WorkingMemory for example on application
startup? An enhancement perhaps with different named queries through
JPA or ?
It would seem that to perform some kind of reporting based on the
active nodes, that using the WorkingMemoryDbLogger would be the best
(and most inexpensive) choice. Querying them dynamically has the
potential to load them from the db on each query.
Thanks,
Garrett
On Sep 4, 2009, at 5:16 AM, Kris Verlaenen wrote:
There are several ways of doing this.
1. Using the audit log
You can log the execution events so they can be queried later. The
drools-bam module contains a WorkingMemoryDbLogger that logs these
events to database, so you can easily query them.
2. Inspecting the process instance itself
You can get all active node instances from the process instance itself
by casting it to a WorkflowProcessInstance. Note that this will only
contain info about the currently active node instances, no history
information, but it seems that's exactly what you're looking for. The
Eclipse plugin and gwt-console also use this approach to show the
active
nodes in a process instance during execution.
3. Custom event listener
If the above methods are insufficient, you can just implement your own
listener and extract the info you need.
Regarding reconnect, that simply reconnects the process instance to
the
engine, nothing more. The engine will then continue by sending the
right triggers to that restored process instance, for example an
incoming event, a work item that has been completed, a timer that has
been triggered, etc. So the engine will restore and reconnect a
process
instance if a trigger for that process instance comes in but the
process
instance is no longer in memory.
Kris
Quoting Garrett Conaty <garrett(a)conaty.net>:
>
>
> I'm trying to determine 'where' a process is (not the
> active/completed/
> etc. state), but the wait state.
>
> One way of doing this (and tracing the process execution) would be
> via
> a RuleFlowEventListener; however is there a way to query a
> ProcessInstance (or something?) for this information?
>
> Effectively I want to know which EventBasedNodeInstances are
> triggered
> for a process and waiting for a response.
>
> Use case is to show in a user interface what the process is waiting
>
> for (i.e. loan approval, timeout, some confirmation).
>
>
> Furthermore, I am confused as to where a process resumes after being
>
> marshalled from db back into memory. I can see that there is a
> 'reconnect' method which gets called, but it looks like the
> implementation of this calls the start Node again!?!
>
> Thanks,
> Garrett
Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm
6:45 p.m.
Quoting Garrett Conaty <garrett(a)conaty.net>:
Question on JPAProcessInstanceManager.getProcessInstances. I see
that
it returns an empty array, which I suppose makes sense otherwise it
would load every process instance from the db?
Yes, in that case it doesn't
make sense to fetch all instances from db
(performance wise that could be very bad, so you shouldn't do this), so
returning an empty set there.
What is the recommended strategy for keeping track of active
processes
that need to be loaded into a WorkingMemory for example on
application
startup? An enhancement perhaps with different named queries through
JPA or ?
In theory, you shouldn't worry about loading process instances, the
engine should worry for you. Whenever you send a trigger, it will
determine which instances need to be loaded.
It would seem that to perform some kind of reporting based on the
active nodes, that using the WorkingMemoryDbLogger would be the best
(and most inexpensive) choice. Querying them dynamically has the
potential to load them from the db on each query.
If you can do it using the db
logger, do it ! If you can't do it, first
consider extending the db logger ;) As that should be the preferred way,
as it doesn't impact runtime performance and shields you from internal
details.
Kris
Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm
5563
days inactive
5564
days old
3 comments
2 participants
participants (2)
-
Garrett Conaty -
Kris Verlaenen