Version : Appian 20.3.
I have a process with 2 Event Receivers : "External_Escalaion" & "Escalation".
I have a User Input node which escalates, sending a message to destination called "External_Escalation" (in the same process).
I would expect to receive the message only on the "External_Escalation" node, however it triggers
the other as well.
Any clues ?
Discussion posts and replies are publicly visible
I know why! Appian does not initiate a process with a start form until you complete the start form. It actually comes highly recommended that you make as many processes with start forms as you can for this reason. It really, really saves your engines not having to run until the process is really going.
In your case, it prevents the escalations from doing anything until the process is started running, which would be after the start form completes. That's the whole problem, that whoever won't fill out (or can't fill out) the start form, so this process is in limbo.
The solution is to break with best practice and instead make this PM with no start form. Just chain directly into a User Input Task as the first node. Then stick the form that would have been a start form directly in there. If it's not a Site action, users will have absolutely 0 change to their experience. If you're using a Site, you unfortunately NEED a start form, so you may want to consider a very simple start form like "Ready to get going? Click here!" and a single button. In your case you want it to be basically impossible for your users to have not made it past the start form and into the main part of the form, where the escalations can help.
You also might want to consider configuring those End Nodes to Terminate. My project has had no end of woes from processes that like to hang out forever, even after all the nodes are executed. Best practice from Appian is all PMs should contain at least one Terminate node.
This process has a start form. Note that the screenshot above was captured after the start form was completed, and after the "External" node has been activated as well. The "Ëxternal" node as 0 min escalation (because I need the task for the external user to be activated. when she logs in into the system). That escalation, sends a message to the "External_Escalation" event, which works fine, it is being activated properly, however the same message hits the "Escalation" event as well which is unexpected behavior.
Here is a simplified PM which demonstrates the same behaviour
PDF
I wonder if those escalations prevent the Start form from completing properly, or vice versa. Anyway, solution remains the same: if possible, remove the start form.
That will at least show if the escalations are the cause of the problem.
If you absolutely need to have the Start Form, you may need to rethink inter-process communication. Perhaps an entirely separate process receives these messages and puts something in the database, then nodes in this process search the database for an entry, following an exception path when they find it.
Also, why would you ever use inter-process communication to communicate between two nodes in the same process? Use an AND gateway.
Nahum, can you share a screen shot monitoring a process instance of the simplified PM, after it exhibits the undesired behavior?
Such as:
For the Terminate discussion, there is more process model off the screen there, but yes a Terminate End Note will be necessary as those events waiting for messages will keep the process is active even if the other flow(s) have hit non-terminating end nodes.
I echo David's point that you would probably have better luck with a different design pattern. There really isn't a need to send a process message within the same process because you can just set up the logic directly in your process to account for it. For instance, if you set up your process like this it should result in the same behavior:
Then you would only need a single message (that receives a message external to the process). To be honest, I actually have never seen someone try to send a message to another node in the same process - In general it's best to limit usage of process-to-process messaging if there is another design pattern because it's difficult to troubleshoot and easy to create performance issues when using it.
Agreeing on the the design changes and limiting the use of process messaging here. Thinking through the setup, there are many other ways to achieve this. For one, if you are always starting the External Escalation Script when an instance of External User Input is initiated, all you need are 2 additional paths from the outputs of your Log Write to DS and Reassign Task nodes directly to the External Escalation Script node, then you can remove the Receive Message node and the External User Input Escalation.
In the situation where I've had to fire other paths in a process model where a flow didn't make since, you can achieve the same idea as Process Messaging with Rule Events. In this situation, the rule waits for some process variable to be updated, say pv!fireRuleEvent to true(), using different variables for different Rule Events / paths.
The Rule Event will need to have an incoming path before it becomes initiated, we often do this with a path from the Start Event. Say in a loop that records task history (each User Input task flags a variable to true/record history, and the loop fires, resetting the flag to false after the update). For example:
Note the Rule Events after the User Input tasks wait for pv!recordHistory to be set back to false before continuing (prevent race conditions).
Let me explain my motivation, perhaps a better design pattern fits my need.
What I actually need is: handler node.onAssign(taskId) = send_email ( getTaskLink(taskId))
(Send an email to the user with a task link to the task assigned to her).
Could not find a way to implement such handler without escalation (to make sure there is a task) and
then obtaining the task id via analytics (get tasks for user & process) which is a bit awkward.
Your suggestion is OK however requires polling on the report to find out when a task was created for
this user in order to find the task id.
Thanks for reply. however I will exit this rabbit hole without messaging as advised by David, Perter and yourself.