Reto,
You should have access to process variables and globals in your timer
action. There's even a junit test that shows this, testTimerState (last
one on link below):
http://anonsvn.jboss.org/repos/labs/labs/jbossrules/trunk/drools-compiler...
Looking at your code, the timer with event seems to generate a NPE
simply because the timer variable is null so the action
"((DroolsTimer)timer).updateStop();" fails.
By the way, if you define timer of type Object with classname the fully
qualified classname of DroolsTimer, you won't have to cast it.
Kris
Quoting retoy <reto.lamprecht(a)allianz-suisse.ch>:
That timer properties can not be changed dynamically is one thing.
The other
thing is that in the code that is executed each time a wait state
timer
fires, you seem to have no access to any process variables. Would you
agree
on this, Kris? If yes, is this planned to change in the future?
I guess you could at least implement a wait state that continues
after a
variable delay if you could access variables in the timer code.
Namely by
updating some fact in the working memory i.e. influence the rule
constraint
of the wait state.
I also tried signalling an event from within the wait state timer and
update
the working memory from a subsequent action node where I do have
access to
process variables. This although didn't work with me because of a
strange
NullPointerException...
In case anyone is interested: Here is a small project with three
approaches
for a wait state node that continues after a variable delay. Neither
of them
works, but maybe someone can fix that...
Reto
http://drools-java-rules-engine.46999.n3.nabble.com/file/n989829/demo.var...
demo.variableTimer.zip
--
View this message in context:
http://drools-java-rules-engine.46999.n3.nabble.com/how-to-access-process...
Sent from the Drools - User mailing list archive at
Nabble.com.
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
Disclaimer:
http://www.kuleuven.be/cwis/email_disclaimer.htm