Common patterns, pitfalls and best practices
Common patterns and pitfalls
NULL vs. fallback
Without fallback, the calculation is aborted and the final result is NULL if a match is not found. You must decide whether this is the desired result or whether a fallback value should be used instead.
Filter expression complexity
If your filter includes ORIGIN(...), watch out for the strict usage rules (simple equals only).
Complex filters are only supported without ORIGIN(...).
Direction confusion
SUCCESSOR → forward in the activity list.
PREDECESSOR → backward in the activity list.
Use named parameters for clarity
They make reading complex expressions easier:
SUCCESSOR( "_ARIS.Activity"."Activity name", filter: "_ARIS.Activity"."cost" > 300, steps: 2, fallback: 'NotFound' )
Check for mixed ORIGIN in the filter
Using ORIGIN(...) incorrectly triggers errors like:
“The ORIGIN operator cannot be mixed with non-ORIGIN access on one side of a simple equals (=) comparison.”
Best practices
Start simple
Test minimal forms first, like SUCCESSOR("_ARIS.Activity"."Activity name") or PREDECESSOR("_ARIS.Activity"."Activity name").
Use filters
Use filters to skip unwanted activities; be mindful of the ORIGIN usage restrictions in simple = comparisons.
Document complex filters
If you use nested calls or ORIGIN references, keep them well-explained.
Handle edge cases
Being at the first or last activity in a list means you have no predecessor or successor, respectively.
Avoid over-nesting
Nested iterations are powerful but complex. Very deep nesting can be harder to maintain and less efficient. Test thoroughly and watch for performance or maintenance pitfalls.
Use fallbacks
Fallback prevent calculation abortions if you want to continue the calculation.