There are two simple ways to program whether a given Receive Message event should process a message: by condition or by expression. Conditions are always the most efficient way to process messages. Appian recommends using conditions over expressions in all process designs.
Conditions are combined and evaluated all at once.
Expressions for message filtering are evaluated one-by-one. The use of expression filtering leads to a linear increase in processing time as the number of messages increase.
Targeting specific process instances for messages by their process IDs is much more efficient than sending messages to multiple processes or a process model because only the Receive Message Events for the process ID are scanned, rather than all events in the other processes.
Rights-management for events may not be required if your organization has other safeguards in place to prevent unauthorized JMS messages from being sent to or retrieved from Appian.
If additional security is not required, select the Public Events checkbox in the Process Model Properties to make the event public.
Synchronization issues can arise if design assumptions are made regarding the order in which messages are received, as messages at a lower tier of the cascade may, on occasion, be sent and delivered earlier than those in an assumed-to-be higher tier.
Where possible, avoid architectures where messages cascade, such as when the sending and subsequent receipt of a message causes multiple other messages to be sent that may trigger other message events.
These process designs create risks which, unless carefully controlled, can cause an exponential growth in the number of messages in the queue and slow the delivery of messages.
Appian does not recommend passing messages between different processes to send data back and forth in a way that mimics a synchronous protocol.
Messaging is not designed as a synchronous transport component, and there are many race conditions as well as performance implications to using messages in this way.
Best practice dictates that when designing a process, messaging loops should be studiously avoided. In some cases, such designs may be practical only when implemented by an expert in this area, as even extensive testing is unlikely to uncover all possible race conditions and performance issues.
Once a flow reaches a Receive Message Event, the event is activated. Any time an untargeted message is sent, all active Receive Message Events are scanned. Generally, the more Receive Message Events there are listening for messages, the higher the performance penalty.
If your architecture presents more and more listeners as sub-processes are created, consider passing information to sub-processes by reference.
See also: Sub-Process Activity
Where high numbers of message listeners are unavoidable, ensure that you apply as many of the other best practices listed in this document as possible.
The amount of data passed within a message can have significant impact on the amount of time taken to process it. This effect becomes more noticeable, as the number of messages increases.
The Activate Message Event checkbox in the Receive Message Event Setup tab allows your process to listen for events for the life of a process. This can negatively impact messaging performance.
If a Receive Message event needs to listen for more than one message, but doesn't need to listen for the entire life of the process, place the Receive Message Event inside a sub-process.
It is possible to configure a Receive Message Event on a Start Event to automatically start a process. However, this technique can produce very high load on the messaging architecture. Instead, it is better to use the Start Process smart service, which does not produce high load on the messaging architecture.
See Ways to Start a Process From a Process for a comparison between the Start Process smart service and process messaging.
Review the Process Execution performance log files to monitor messaging performance.
See also: Monitoring Performance and Usage.
On This Page