I currently have a requirement.
A main process is running. It needs to have variables altered in it and the flow diverted when a webapi kicks off a separate process.
At the moment our plan to do this involves send and receive message Appian functionality in the process models to divert flow.
I had noticed some bizarre functionality with this a few months ago and this deprecation page https://docs.appian.com/suite/help/21.2/Send_Message_to_Process_Model.html.
I may have improperly assumed message sending was deprecated or at least not a good practice from some posts.
Send and receive messages are not deprecated correct?
What would you recommend for solving this requirement above?
Discussion posts and replies are publicly visible
Unknown said:I may have improperly assumed message sending was deprecated or at least not a good practice from some posts.
Prior to the introduction of the "start process" node (not to be confused with the subprocess node which we've had pretty much always), the "standard" way to start an asynchronous and "load balanced" external process model from within a process flow, was to use the Send Message event to start a fresh copy of a process model. I'm fuzzy on the details here but apparently the main issue with this was that not directing the message to a specific Process Instance ID caused all existing instances of the target process to also try to "listen" to the message, generating some potentially severe load issues.
So what's been deprecated (to the best of my memory, again a little fuzzy) is the feature to send a message to a process model in general but not directed at a specific instance. Instance-specific messaging is still available.
It sounds like messaging might solve your use case. I always try basically anything else to avoid messaging - since a lot of use cases could be solved using asynchronous subprocess calls and/or synchronous subprocesses with an "update flag" PV passed in by-reference from the parent... all this depends on what your process flow is actually intending to do of course.