This is more of a PSA post rather than a question, but I thought I'd put it up here to a) help anyone else out who is confused by this and b) hopefully get Appian's attention to fix this (I will also make a support case for this issue).
This is regarding how the XOR node in the process modeler evaluates multiple conditions. Looking at how the Decision tab is laid out (with IF...ELSE IF...ELSE IF labels and the ability to change the order of the conditions) my first thought would be that the conditions evaluate in order from top to bottom.
However, in the documentation for this node it states:
But then in other places the same page states:
The actual behavior of the XOR node indicates that the order of the conditions does not matter, all are evaluated simultaneously. I hope that Appian changes the behavior of the node to execute conditions in order as this would be much more useful.
If I have misunderstood anything in the documentation, please feel free to correct me, because as of now I don't really see any value to an XOR node when compared to an OR node.
Discussion posts and replies are publicly visible
The important thing to remember is that all the conditions will be evaluated (as opposed to one at a time until reaching a true condition). What that means is if there are two conditions, one which checks if a list is null, and the next that tries to remove a value of the list, an error will be thrown, since the second condition does not have a null check, even though the first path should be taken. Screenshots attached.
Yes, this was exactly my issue (getting an error for a condition that I didn't expect to run). I was then confused because, if order didn't matter in an XOR I didn't really see much difference between it and an OR. But I think I have a better understanding of how it works now (see my reply to Stefan).
So you mean something like that the code for all conditions is executed in batch, but to find the correct outgoing path, the resulting values are evaluated top-to-bottom?
That's right! It is done that way for performance reasons.
James Lepone said:for performance reasons
That's a surprise to me though, because it seems like performance would generally be improved by allowing XOR to not have to calculate the evaluation expressions for lines it would never even get to.
Think of it this way. I have 4 conditions. The 4th one will be true. Each expression takes 2 seconds. Evaluating in a batch lets us have a result in 2 seconds, if we evaluated serially it would be 8 seconds before we could move on.
That definitely makes sense in that scenario. However in a situation similar to mine, the first 2 conditions takes 1s to evaluate and the 3rd condition takes 15s to evaluate (exaggerated for demonstration). It would be nice in this scenario to be able to "block" the third condition from running with one of the first 2 conditions, resulting in max 2s eval time rather than 15s. The way it's currently done provides more predictable/consistent performance and is better for when all conditions take about the same time, while evaluating it like Mike described allows developers to better control performance (for better or worse), especially when there is a large variation in eval times. So ultimately I'm not sure which way would provide better performance in the majority of cases.
That's fair that this scenario could be negatively affected, but also if you knew there were specific conditions that did take a long time to execute you could theoretically split them out into a separate XOR after the first one. Maybe not the most ideal in terms of the model design, but probably could still achieve the performance gains you're looking for.
How on earth did I make a living from Appian for 15 years, without knowing this !?!