[rules-users] [droolsflow] Code-based constraints for EventWait nodes - is this possible?
Alan.Gairey at tessella.com
Alan.Gairey at tessella.com
Tue Nov 10 04:56:31 EST 2009
Kris,
Many thanks for your continued help. I updated to the latest trunk, and
replaced my milestone node with a state node as suggested, and the process
instance completed as required.
Two things I noticed:
1. The state node isn't currently available in the palette of the Eclipse
plug-in graphical editor - presumably it will be in the final release of
5.1?
2. If the ID of my process definition contains a hyphen, then the process
does not complete. If you change the id in ruleflow.rf in the test case I
sent you from "com.test.ruleflow" to "com.test.ruleflow-x" (and change the
argument to ksession.startProcess() in PersistenceTest.java), you'll see
that the process doesn't complete. Any ideas as to why this is happening?
Anyway, thank you again.
Regards,
Alan
Kris Verlaenen <kris.verlaenen at cs.kuleuven.be>
07/11/2009 01:40
To
Alan.Gairey at tessella.com
cc
rules-users at lists.jboss.org
Subject
Re: [rules-users] [droolsflow] Code-based constraints for EventWait nodes
- is this possible?
Alan,
The problem you are seeing is caused by the fact that you are retrieving
the process instance in the work item manager. There's nothing wrong
with that, but there is an issue that the process instance that is being
executed was not yet registered, so the process instance will be
retrieved from db, but this is the old version.
Also note that you should try the new state node instead of the old
milestone node (aka event wait node), as the new state node is more
powerful but also offers the same features as the milestone node. For
example, your milestone node would be the same as:
<state id="10" name="Retry?" x="382" y="164" width="80" height="40" >
<constraints>
<constraint toNodeId="9" name="retry" priority="1"
>SimpleFact(retry == true)</constraint>
</constraints>
</state>
Updating to the latest trunk and using the state node should fix your
issue.
Kris
Quoting Alan.Gairey at tessella.com:
> Kris,
>
> Thanks yes - the null check fixes the NPE I was seeing.
>
> Unfortunately, I now have a more difficult problem. In my work item
> handler, I use the following code to get the ID of a work item in the
> rule
> flow (i.e. the .rf file itself) given a
> org.drools.runtime.process.WorkItem instance:
>
> private long getCurrentNodeId(WorkItem workItem) {
> ProcessInstance processInstance =
> ksession.getProcessInstance(workItem.getProcessInstanceId());
> if (processInstance instanceof WorkflowProcessInstanceImpl)
> {
> Collection<NodeInstance> nodeInstances =
> ((WorkflowProcessInstanceImpl) processInstance).getNodeInstances();
> for (NodeInstance nodeInstance : nodeInstances) {
> System.out.println(String.format("Node instance: %s",
>
> nodeInstance));
> if (nodeInstance instanceof WorkItemNodeInstance) {
> WorkItemNodeInstance workItemNodeInstance =
> (WorkItemNodeInstance) nodeInstance;
> if (workItemNodeInstance.getWorkItem() ==
> workItem) {
> return workItemNodeInstance.getNodeId();
> }
> }
> }
> }
> throw new RuntimeException(String.format("Error determining
> node
> ID for work item: %s", workItem.toString()));
> }
> The work item in the attached test case, the first time it executes
> sets a
> property on a fact in memory that causes a subsequent Split node to
> send
> the flow to an Event Wait. The code in the overall main() method (in
>
> PersistenceTest.java) then updates the fact in memory so that the
> Event
> Wait's constraint is satisfied, and the work item node is executed
> again.
> The second time around, it sets the property on the fact in memory so
> that
> the subsequent Split node sends the flow to its end. (I hope this
> makes
> sense; looking at the rule flow in the test case should show you what
> I'm
> trying to do.)
>
> If I execute the test case with my session created using the code:
> StatefulKnowledgeSession ksession =
> kbase.newStatefulKnowledgeSession();
> everything works as I would expect, and the output from the
> System.out.println() statement in my getCurrentNodeId() method above
> is:
> Node instance:
> org.drools.workflow.instance.node.WorkItemNodeInstance at 125d568
> Node instance:
> org.drools.workflow.instance.node.WorkItemNodeInstance at 37a04c
>
> However, if I use JPA persistence:
> StatefulKnowledgeSession ksession =
> JPAKnowledgeService.newStatefulKnowledgeSession(kbase, null, env);
> then the RuntimeException in getCurrentNodeId() is thrown, and the
> output
> is:
> Node instance:
> org.drools.workflow.instance.node.WorkItemNodeInstance at 2209db
> Node instance:
> org.drools.workflow.instance.node.MilestoneNodeInstance at d8fd1a
> Somehow it seems as though the node instance isn't quite synchronised
> with
> the overall state when using JPA persistence.
> Any help you could give me here would be very much appreciated.
> Regards,
> Alan
>
>
>
>
> Kris Verlaenen <kris.verlaenen at cs.kuleuven.be>
> 30/10/2009 20:10
>
> To
> Alan.Gairey at tessella.com
> cc
>
> Subject
> Re: [rules-users] [droolsflow] Code-based constraints for EventWait
> nodes
> - is this possible?
>
>
>
>
>
>
> Alan,
>
> Thanks, this indeed seems to be the issue. I have changed this on
> trunk. Does adding this null check solve your issue?
>
> Thx,
> Kris
>
> Quoting Alan.Gairey at tessella.com:
>
> > Kris,
> >
> > Some more information: the NullPointerException from
> GetObjectCommand
> > is
> > thrown by the line:
> >
> >
> >
>
((StatefulKnowledgeSessionImpl)ksession).session.getExecutionResult().getResults().put(
> >
> > this.outIdentifier,
> > object );
> >
> > Method getExecutionResult() is returning null. Debugging my test
> > case, I
> > also notice that this.outIdentifier is also null.
> >
> > I then had a look at the GetObjectsCommand class; in its execute
> > method,
> > there is a line similar to that above. However, it is contained
> > within an
> > if block that checks this.outIdentifier is not null:
> >
> > if ( this.outIdentifier != null ) {
> > List objects = new ArrayList( col );
> >
> >
> >
>
((StatefulKnowledgeSessionImpl)ksession).session.getExecutionResult().getResults().put(
> >
> > this.outIdentifier, objects );
> > }
> >
> > If something similar was done in GetObjectCommand, presumably this
> > would
> > fix my problem?
> >
> > Hope this is of some use - regards,
> >
> > Alan
> >
> >
> >
> >
> > Alan.Gairey at tessella.com
> > Sent by: rules-users-bounces at lists.jboss.org
> > 29/10/2009 17:35
> > Please respond to
> > Rules Users List <rules-users at lists.jboss.org>
> >
> >
> > To
> > Kris Verlaenen <kris.verlaenen at cs.kuleuven.be>
> > cc
> > Rules Users List <rules-users at lists.jboss.org>
> > Subject
> > Re: [rules-users] [droolsflow] Code-based constraints for
> EventWait
> > nodes
> > - is this possible?
> >
> >
> >
> >
> >
> >
> >
> > Kris,
> >
> > Thanks - making the class SimpleFact serializable fixed that error.
>
> >
> > However, I now have a new problem: I have a rule flow containing a
> > work
> > item - the handler attempts to update the SimpleFact instance in
> > memory
> > before completing the task. The code in the executeWorkItem method
> is
> > as
> > follows:
> >
> > Collection<FactHandle> factHandles =
> > ksession.getFactHandles(new
> > ObjectFilter() {
> > public boolean accept(Object object) {
> > return (object instanceof SimpleFact);
> > }
> > });
> > for (Iterator<FactHandle> iterator =
> factHandles.iterator();
> >
> > iterator.hasNext(); ) {
> > FactHandle factHandle = iterator.next();
> > SimpleFact fact = (SimpleFact)
> > ksession.getObject(factHandle);
> >
> > fact.setStatus("Error");
> > ksession.update(factHandle, fact);
> > }
> >
> > workItemManager.completeWorkItem(workItem.getId(), null);
> >
> > The call to getObject() causes the following exception to be
> thrown:
> >
> >
> > java.lang.NullPointerException
> > at
> >
>
org.drools.command.runtime.rule.GetObjectCommand.execute(GetObjectCommand.java:35)
> >
> >
> > at
> >
>
org.drools.persistence.session.SingleSessionCommandService.execute(SingleSessionCommandService.java:254)
> >
> >
> > at
> >
>
org.drools.command.impl.CommandBasedStatefulKnowledgeSession.getObject(CommandBasedStatefulKnowledgeSession.java:369)
> >
> >
> > at
> >
>
com.test.StatusChangeWorkItemHandler.executeWorkItem(StatusChangeWorkItemHandler.java:37)
> >
> >
> > ...
> >
> > I've attached another test case to illustrate the problem.
> >
> >
> >
> > Once again, my sincere thanks for helping me with this.
> >
> > Regards,
> >
> > Alan
> >
> >
> >
> > Kris Verlaenen <kris.verlaenen at cs.kuleuven.be>
> > 29/10/2009 12:00
> >
> >
> > To
> > Alan.Gairey at tessella.com
> > cc
> > Rules Users List <rules-users at lists.jboss.org>
> > Subject
> > Re: [rules-users] [droolsflow] Code-based constraints for
> EventWait
> > nodes
> > - is this possible?
> >
> >
> >
> >
> >
> >
> >
> >
> > Alan,
> >
> > The cause of the rollback of the transaction is this:
> > Caused by: java.io.NotSerializableException: com.test.SimpleFact
> >
> > The reason is that, if you use persistence for your session, the
> > persister will try to save all runtime state of the engine. This
> > does
> > not only include process instances, but also rule-related state.
> By
> > default, this also includes the data inserted in the memory. We
> > support
> > two strategies for storing this data: serialization of the data
> > (default) or JPA-based storage of entities (by reference). In
> this
> > case, the persister is trying to serialize the test object you
> > inserted
> > and fails. Making it serializable should fix this.
> >
> > Kris
> >
> > Quoting Alan.Gairey at tessella.com:
> >
> > > Kris,
> > >
> > > I've attached a simple test case (transaction manager, data
> > source,
> > > etc.
> > > are configured via Spring). The error is thrown on line:
> > >
> > > ksession.insert(new SimpleFact());
> > >
> > > If this line is commented out, the rule flow executes without
> > error.
> > >
> > >
> > >
> > > Many thanks for looking at this.
> > >
> > > Regards,
> > >
> > > Alan
> > >
> > >
> > >
> > >
> > > Kris Verlaenen <kris.verlaenen at cs.kuleuven.be>
> > > 28/10/2009 10:40
> > >
> > > To
> > > Alan.Gairey at tessella.com
> > > cc
> > > Rules Users List <rules-users at lists.jboss.org>
> > > Subject
> > > Re: [rules-users] [droolsflow] Code-based constraints for
> > EventWait
> > > nodes
> > > - is this possible?
> > >
> > >
> > >
> > >
> > >
> > >
> > > Alan,
> > >
> > > Could you send me the entire output / stack trace (as the
> rollback
> > > of
> > > the transaction is usually caused by another exception)?
> > >
> > > Or a simple test case that shows the error, so I can take a
> look?
> > >
> > > Thx,
> > > Kris
> > >
> > > Quoting Alan.Gairey at tessella.com:
> > >
> > > > Kris,
> > > >
> > > > After posting my last question, I quickly came to the same
> > > conclusion
> > > > as
> > > > you, so I'm now using a rule-based constraint in my EventWait
> > > node.
> > > >
> > > > This however has presented a different problem. If I create my
> > > > session
> > > > from JPAKnowledgeService, then when I try to insert my fact
> into
> > > the
> > > >
> > > > session, I get the following error:
> > > >
> > > > bitronix.tm.internal.BitronixRollbackException: transaction
> was
> > > > marked as
> > > > rollback only and has been rolled back
> > > > at
> > > >
> > >
> >
> bitronix.tm.BitronixTransaction.commit(BitronixTransaction.java:153)
> > > > at
> > > >
> > >
> >
>
bitronix.tm.BitronixTransactionManager.commit(BitronixTransactionManager.java:96)
> > > > at
> > > >
> > >
> >
>
org.drools.persistence.session.SingleSessionCommandService.execute(SingleSessionCommandService.java:258)
> > > > at
> > > >
> > >
> >
>
org.drools.command.impl.CommandBasedStatefulKnowledgeSession.insert(CommandBasedStatefulKnowledgeSession.java:305)
> > > > (Everything works fine if I create my session from the
> knowledge
> > > base
> > > > -
> > > > i.e. with no state persistence.)
> > > > Prior to using a rule-based constraint (with no call to
> > > > CommandBasedStatefulKnowledgeSession.insert), the session
> > created
> > > > from
> > > > JPAKnowledgeService worked OK.
> > > > I'm using the default JPA configuration from the Drools
> > > documentation
> > > >
> > > > (persisting to H2 database, etc.).
> > > > Any ideas what might be causing the problem?
> > > > Many thanks,
> > > > Alan
> > > >
> > > >
> > > >
> > > >
> > > > Kris Verlaenen <kris.verlaenen at cs.kuleuven.be>
> > > > 23/10/2009 03:00
> > > >
> > > > To
> > > > Rules Users List <rules-users at lists.jboss.org>,
> > > > Alan.Gairey at tessella.com
> > > > cc
> > > > Rules Users List <rules-users at lists.jboss.org>
> > > > Subject
> > > > Re: [rules-users] [droolsflow] Code-based constraints for
> > > EventWait
> > > > nodes
> > > > - is this possible?
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > No, the constraint of an EventWait node (or the State node in
> > > Drools
> > > > 5.1) can only be rule-based. The reason for this is that the
> > rule
> > > > engine knows when to re-evaluates rules (based on the
> evailable
> > > > input).
> > > > If you would use a code-based constraint, the engine would
> have
> > > no
> > > > idea
> > > > when this code constraint might become true (if it was false
> at
> > > the
> > > > start). Only constant re-evaluation of the code constraint
> > could
> > > > achieve this (which would be tremendously inefficient). Could
> > you
> > > > explain why you would like to have this behaviour? Maybe
> there
> > is
> > > > an
> > > > alternative way to model this.
> > > >
> > > > To change the value of a variable from inside the process
> (using
> > > an
> > > > action), simply use kcontext.setVariable(name, value). We do
> > not
> > > > recommend manually changing the value of a process variable
> from
> > > > outside
> > > > the engine. Again, could you explain why you would like to
> have
> > > > this
> > > > functionality?
> > > >
> > > > Kris
> > > >
> > > > Quoting Alan.Gairey at tessella.com:
> > > >
> > > > > Can the constraint for an EventWait node in a flow be
> > code-based
> > > > > (rather
> > > > > than rule-based)? The Eclipse plug-in (v 5.0.1) doesn't
> allow
> > > this
> > > > to
> > > > > be
> > > > > specified, unlike say for a Split node, although the
> relevant
> > > XML
> > > > can
> > > > > of
> > > > > course be edited.
> > > > > Trying to load such a process flow results in a
> > > > NullPointerException,
> > > > >
> > > > > because the constraint is always interpreted as a rule.
> > > > >
> > > > > Ideally what I'd like to do is have an EventWait node where
> > the
> > > > > constraint
> > > > > tests the value of a process variable. This then leads me to
> > > > another
> > > > >
> > > > > question; is there a way of setting the value of a process
> > > > variable
> > > > > via
> > > > > the Drools Flow API?
> > > > >
> > > > > Thanks in advance for any help,
> > > > >
> > > > > Alan
> > > > > Tessella plc
> > > > > 26 The Quadrant, Abingdon Science Park, Abingdon,
> Oxfordshire,
> > > > OX14
> > > > > 3YS
> > > > > E: Alan.Gairey at tessella.com, T: +44 (0)1235 555511, F: +44
> > > (0)1235
> > > > > 553301
> > > > > www.tessella.com Registered in England No. 1466429
> > > > >
> > > > > This message is commercial in confidence and may be
> > privileged.
> > > It
> > > > is
> > > > >
> > > > > intended for the addressee(s) only. Access to this message
> by
> > > > anyone
> > > > > else
> > > > > is unauthorized and strictly prohibited. If you have
> received
> > > this
> > > > > message
> > > > > in error, please inform the sender immediately. Please note
> > that
> > > > > messages
> > > > > sent or received by the Tessella e-mail system may be
> > monitored
> > > > and
> > > > > stored
> > > > > in an information retrieval system.
> > > > >
> > > >
> > > >
> > > >
> > > >
> > > > Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm
> > > >
> > > >
> > >
> > >
> > >
> > >
> > > Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm
> > >
> > >
> >
> >
> >
> >
> > Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm
> > [attachment "drools-persistence-test.zip" deleted by Alan
> > Gairey/Tessella]
> > _______________________________________________
> > rules-users mailing list
> > rules-users at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/rules-users
> >
> >
>
>
>
>
> Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm
>
>
Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-users/attachments/20091110/1ce851d2/attachment.html
More information about the rules-users
mailing list