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 <garr...@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 _______________________________________________ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users