Rule Event - Not working as expected

Can you add:

• the code for the rule you're calling from the Rule Event
• how you've configured your Rule Event

then we have a better chance of diagnosing what's happening.

Please use the "</>Insert Code" option when posting code

thanks

Rule event is configured on the Process model next to Synchronous sub-process

Rule Event -> New Expression

rule!expressionrulename(pv!parameter)

expressionrulename is an query entity as below

1 input parameter - datatype Integer

code

if(

a!queryEntity(....).totalCount = 0,

true,

false

)

Several things to observe/consider here:

• What do you expect to happen if the expression returns false? There isn't anything that is going to cause the rule to be re-evaluated so your process is going to be suspended indefinitely (well, until Appian decides that it's been waiting too long for its own good!)
• suspending a synchronous process whilst you're waiting for something that may not happen isn't a great user experience. You probably need to re-think your design
• your code can be made simpler - a!queryEntity(....).totalCount = 0 is either true or false, you do not need to wrap it with an if() statement

I would take a step back and try and articulate what you're trying to achieve with this pattern and see if there are other ways it can be achieved.

Several things to observe/consider here:

• What do you expect to happen if the expression returns false? There isn't anything that is going to cause the rule to be re-evaluated so your process is going to be suspended indefinitely (well, until Appian decides that it's been waiting too long for its own good!)
• suspending a synchronous process whilst you're waiting for something that may not happen isn't a great user experience. You probably need to re-think your design
• your code can be made simpler - a!queryEntity(....).totalCount = 0 is either true or false, you do not need to wrap it with an if() statement

I would take a step back and try and articulate what you're trying to achieve with this pattern and see if there are other ways it can be achieved.

Also... how will a!queryentity() even behave if called in the expression for a rule?  I don't assume it will constantly re-execute.  Will it re-execute any time the RI's value is changed, even?  I'd have to try this myself before being able to confidently recommend anything either way.

+1 on understanding the use case more. In general most appian developers don't use rule events on process models very often because there's often a better way to achieve the same solution.

This is what we trying to do , the process variable is a output parameter from the previous sub process. But instead of waiting on the Rule Event it throws the provided error message. can you please confirm the ideal case , will Rule Event get reevaluated once the pv! gets updated. (not for our current implementation but to know how it works.)

Thanks Stewart, we did redesign our code to use script task to check if pv! has been updated if not loop it with timer to wait for 1 minute and rerun the script task.

Yes. I've used the rule event once or twice in the past I(which goes to show how often it gets used) to provide a synchronization point between two threads of processing. Imagine a process flow that splits into two parallel flows that run concurrently. I wanted flow B to do some processing and then wait until flow A had reached a certain point. So I used the Rule Event to suspend flow B, using a Boolean pv! which had initially been set to false. Flow A then at some point flips the Boolean pv! to true and Flow B continues processing.

I can only assume that the Rule Event is "polling" the pv! in this instance to determine if it's true or false.

The problem is you have to be certain that the evaluated value for the Rule Event will resolve to true. In the above example I had designed it explicitly to become true in that I knew Flow A would flip the pv! from false to true.

I would be interested in how many of these processes do you plan to run? Depending on the numbers, I would like so suggest to decouple things completely.