16.3 - Sending Message Events to Process Models

...r as messaging is concerned.

You can still target a process instance by its ID. So I think this will not be a real problem for most of us.

Assuming that's the way the process was built originally, yes - but what about processes that weren't built like that? This change could render those unmaintainable. IMO if something "has negative performance impacts" then the solution should be to fix the underlying issue, rather than deprecate that functionality.

I agree as the best practices regarding inter-process messaging for the past 5 years is to NOT send messages to all instances of a model but to target instances directly. So I think this will not be a big issue ...

It still sounds to me like you're conflating "process model" with "process instance". From where I'm sitting, I don't see any implication at all that they're removing the ability to send messages to instances, though maybe you could clarify on what's leading you to that impression?

Oh, I didn't see stefan's last comment before submitting, but yes maybe the "send message to all running instances" use case is what i'm missing. I've actually never seen this implemented though as it seems pretty risky from a performance standpoint.

The Start Process Smart Service isn't a replacement for process to process messaging - is it just starting processes via a message that' being deprecated. Sending messages to a process instance is often used to terminate a process.

@stefan Again, that's fine but it assumes nobody has any processes that use that functionality - I'm not sure we can assume that nobody uses the functionality without knowing everything everyone has ever done, which of course we don't know! It seems a little short-sighted to just suddenly deprecate this functionality.

@mschmitt It can result in performance issues, presumably if there are many instances of a specific model (as described here - https://forum.appian.com/suite/help/16.3/Messaging_Best_Practices.html). However, it is often useful to message a process model and "correlate" on a piece of business data rather than the alternative, which is to implement a process report to reterieve the process IDs and subsequently message each of them individually. I have seen this implemented in a number of projects, and I'm assuming that those clients don't wish to rewrite what would effectively constitute the core architecture of the solution.

This has me nervous as well since we use process to process messaging fairly heavily. We have many many cases where we target instances, but also a very important administrative use case where we message any process waiting by sending directly to the models. Based on my understanding, this is going to be removed?? Our primary use case is around the legacy Query DB node which we have implemented in over 30 processes that connect to 11 different external DBs. When a DB goes down that we don't control (often), we allow the Query DB nodes to continue on error and wait at a receive message event. Once the outage has ended, we run one admin process which sends messages to the models and the node is retried, thus continuing all processes with one click. I don't know if any of you have had the privilege to manually restart 400 process instances one by one, directly ending your productivity for the remainder of the day, but in the 5 years I've been using this I haven't noticed any performance issues that outweigh the massive amount of manual effort and time needed to administrate. If this is functionality is for sure being removed I will be very disappointed, but I'm still not clear on exactly what the plan is here..

Although it sounds like my case may be ok since we always utilize a Receive Message Event within a Process Model..

• Receive Message Event within a Process Model
• Specific Process
• Specific Process Model [Deprecated]