Hello all,
Is it not possible to use a Rule Expression as the expression that defines the configuration of a Timer Event?
We have an issue with setting up a timer based Exception Flow on a User Input task where the timer is defined as "Skip this node at the date and time specified by this expression" and the logic is implemented as a Rule Expression instead of writing it directly within the Timer event configuration. The issue that users see when the Task is loaded is "This task may have been deleted or completed by another assignee".
However, when we copy the logic from the Rule Expression and paste it directly into the timer event configuration, then there is no such issue.
Discussion posts and replies are publicly visible
We utilize rules to determine exception flows in many locations without issues. Are you able to share your rule definition?
Hello Chris,
Thank you for your response.
The Rule Expression, named "LWS_timerStep10" has a single rule input "entryDate" of type Date and Time.
Its definition is the following simple expression: caladddays(ri!entryDate, 5)
Then, the rule expression "LWS_timerStep10" is used inside the exception timer definition of the User Task, which is enabled through Activity Chaining, meaning the user clicks on an Action and the process leads to this User Task through activity chaining.
That is when we (as users) see the error described in my original note. Just to rule any possible security issues, the same error is thrown for both Basic Users and System Administrators.
As I mentioned in my original note, if we use the definition of the Rule Expression directly in the exception timer then everything works just fine.
Do you see any errors in process instance details? Is the task skipped in task history?
The status of the user task is Paused and the status of the process instance is Paused by Exception. The process history shows the task as assigned.
The error that is displayed in the process monitoring view of appian designer is "ERROR:EVAL:@reason=index". The db log of the execution engine running that process instance has the following ERROR entries.
2021-04-02 07:39:50 [PX021] {pe4747.kdb ,3655838} (Default) ERROR .a.p.PROCESS.i "Event Mapping Runtime 149, attached to Node instance 17823: 'LWS_formStep10', Process 536915545: 'LWS Submit New Case'" "Timer absolute schedule expression (=#"_a-0000e616-f8b9-8000-928d-010000010000_743179"(entryDate: pv!caseBasicData.entryDate)): ERROR:EVAL:@reason=index"2021-04-02 07:39:50 [PX021] {pe4747.kdb ,3655838} (Default) ERROR .events.timer "Timer event errors: 209, Error Messages: "ERROR:EVAL:@reason=index""
I think this is a known issue with doing date/time calculations in process nodes via expressions. Add a script task just before the user task do the calculation and store it into a PV. Then use the PV in the exception. Or omit keyword syntax as described here
community.appian.com/.../kb-1794-details-error-eval-reason-index-error-thrown-when-using-escalations-timers-and-exception-flows
Out of curiosity. Why do you need an exception in that task? Following your description this is just the start of that process. Why not a start form?
Agree with Stefan that while expressions can be used for escalation timers, they are very picky. Especially in the use of expressions containing localVariables, with() or load(), we will calculate the exception timer in a prior script task into pv! as he suggests.
If you want to ensure the timer is more dynamic, include a constant with the day value - and you can use this directly in the User Input Task:
caladddays(ri!entryDate, cons!YOUR_CONSTANT_HERE)
Chris, thanks for your help as well.
We have shifted our implementation of the time event just as you have noted, directly using the caladddays function with a constant.
However, with the link to the KB article that Stefan has sent we have understood the cause of this issue which was the use of keyword syntax when calling the rule expression. This is not supported in events and various other components, including case as the ones you have indicated in your note.
Again, thank you for your help!