In a process, a Java message or an email can be used to send information to your process flow. The Receive Message event allows you to receive that message, trigger events based on the message properties, and store the message properties for later retrieval.
The Receive Message event can be configured as:
Stand-alone node: If the Receive Message Event is configured as an intermediate event in the process model, the event is activated when the process flow reaches the node. The process flow only proceeds once the event has completed execution.
Start Event trigger: If the Receive Message Event is configured as a trigger in a Start Event, the process starts when the message is received.
Note: In nearly all cases, it's better to use the Start Process smart service to start a process than to use process-to-process messaging. See Ways to Start a Process From a Process for more information on the advantages of the Start Process smart services over process-to-process messaging.
Exception Flow trigger: If the Receive Message is configured inside a smart service activity to trigger an Exception Flow, the event is only activated when the process flow reaches the node that contains the event. If the exception flow is triggered, Appian skips any logic in the node other than the Receive Message event.
To configure a Receive Message event:
The Edit Receive Message Event dialog allows you to view and edit the configuration options of Receive Message events.
To access this dialog for stand-alone Receive Message events, click the node in the process model workflow.
To access this dialog for Start Event triggers:
To access this dialog for Exception Flow triggers:
This option is available in the Setup tab for stand-alone Receive Message nodes only.
Receive Message events are activated as soon as a process flow reaches the corresponding event or activity.
If you select the Activate Message Event checkbox, Appian continues listening for messages until the process completes.
If you do not select this checkbox, Appian no longer listens for messages that could cause the event to execute again, once a message is received.
Tip: For optimal performance, keep this option unselected.
As an alternative to keeping the event active throughout the life of the process, you can configure Receive Message events in a subprocess. Use this approach when your process needs to receive more than one message, but does not need to remain active at all times when the process is running. An Exception flow should be used to terminate the subprocess once it no longer needs to listen for message events.
Under Receive Messages in the Setup tab, select a message type from the Listen for messages of type dropdown list.
Supported message types include:
Note: Changing a message type removes all existing event conditions and mappings. Appian will display the following warning: Changing the message type will clear all rules and output expressions. Are you sure you want to do this?
A condition specifies a message property that Appian uses to filter received messages. When a message is received, the event only executes when all conditions are met. If any of the conditions evaluate to false, the event does not execute. Messages received when the conditions evaluate to false are not retained.
You can create an event condition using a guided experience or by writing an expression.
To create a condition using the guided experience:
Select one of the following operators to evaluate the condition.
Operator | Description |
---|---|
= | equal to |
<> | not equal to |
< | less than |
> | greater than |
<= | less than or equal to |
>= | greater than or equal to |
Tip: Creating expressions to specify the conditions under which an event executes can cause a loss in application performance. We recommend using the guided experience instead when configuring conditions.
Condition expressions must evaluate to true or false.
The message properties available to use in expressions vary depending on the message type you selected.
To use an expression to define a condition:
msg!properties.
(including the period), then select a message property from the dropdown list.For a custom message property, enter an expression using the following syntax:
1
msg!properties.<PROPERTY_NAME>
where <PROPERTY_NAME>
is the name of the custom message property. For example, if the incoming message contains a custom property called CaseId
, you can reference it as:
1
msg!properties.CaseId
To delete an event condition:
You can create mappings that capture data from the received message and store the data in process variables. These mappings make the data accessible throughout the process model and in any process reports you create.
The message properties available to use in mappings vary depending on the message type you selected.
To create a new mapping:
msg!properties.
(including the period), then select a message property from the dropdown list.For a custom message property, enter an expression using the following syntax:
1
msg!properties.<PROPERTY_NAME>
where <PROPERTY_NAME>
is the name of the custom message property. For example, if the incoming message contains a custom property called CaseId
, you can reference it as:
1
msg!properties.CaseId
Note: When capturing the output of a property sent using an HTML email, use the stripHtml() function to parse the HTML. For example, striphtml(msg!properties.From)
cleans any HTML tags from the specified message property so that its value can then be stored in a text process variable.
For Operator, select an operator to specify how Appian writes the data to the process variable you'll select next.
The supported operators are dependent on the type of the process variable that you're saving the content into.
For an integer or a decimal type of process variable, the following operators are supported:
For any other type of process variable, the following operators are supported:
For Process Variable, select the process variable where you want to store the message property, or select New… to create a new variable to store the message data.
You can use process variables with custom data types to store received message properties. Learn more about configuring a process variable and custom data type.
To build an expression that combines each desired message property into the format of the custom data type, you can save message properties from an email message into a process variable with the Email data type by using the following expression in the Value field.
{From:msg!properties.From,Subject:msg!properties.Subject,Body:msg!body}
If you need to use an expression function on your message properties (such as using the stripHtml function to remove tags from fields in an HTML email) map each property to its own variable and use a Script Task to combine the separate properties into a single CDT variable.
Optionally, you can provide a default value for all custom properties that you expect from incoming messages using the property() function. This function allows you to provide a default value for a property, which is used if the property is missing from the incoming message.
For example, adding the following definition for a mapping:
property(msg!properties,"Name", "No Name was sent")
ensures that if the custom property called Name
does not arrive in the incoming message, it is assigned No Name was sent as its value.
With Email message types, key-value pairs are treated as custom properties.
To obtain the value of a key specified in a message, the name of the key should be included in the definition of a mapping. For example, if the key-value pair [CaseId=222100]
is sent in an email message, you can capture CaseId in a receive message event by creating a mapping with the following definition:
msg!properties.Key
If you have Editor or Administrator rights for a process model, you can import data mappings that have been configured for other events. Among other uses, this feature allows you to easily connect a Receive Message event with a Send Message event that you have configured in another process model. Alternatively, it allows you to quickly build conditions for executing an event.
To import mappings from a previously configured event:
Attachments sent within an email message are stored within a document folder.
To specify the folder used to store email attachments:
If you add multiple active Receive Message events, it is possible for one message to launch multiple instances of a process. Avoid this problem by creating a Receive Message condition.
Receive Message events listen for messages only when they are activated. Moreover, when messages are targeted at an active Receive Message event, the event only executes if all conditions configured for the event are met. Otherwise, the event does not execute and the message is lost.
Messages sent to a process that is paused are lost and are not available when the process resumes.
In process-to-process messaging, we recommended configuring Receive Message events before Send Message events. Send Message events require a message destination that may not exist until the process model with a Receive Message event is saved and published.
If you need to use a message property in a report, you must map it to a process variable.
You cannot use a record data type in this event. This means you cannot reference a process variable of type record data type, use a record field reference, or use a record type constructor; otherwise, an error will occur.
If you're using the Email message type, review the following additional considerations.
A system administrator must configure your environment to support email and take special care to configure inbound message routing properly
Appian Cloud users should review cloud considerations to properly setup incoming message routing.
Email messages require that anonymous user access be enabled. Whenever a process is started using an email, the process initiator property (pp!initiator) is listed as the Guest user account.
The Public Events option must be enabed for the process model to allow processes to be started using email.
If you configure a Receive Message event (or a Start Event with a Receive Message trigger) to read values (key-value pairs) from incoming email and map them to new or existing process variables, only those emails that include value pairs in the specified format are processed by the system. All other emails are read from the inbox on the mail server, but processes do not store the information from the email message. Instead, a message states that cancellation of the message will be logged in the appropriate db_*.log file.
HTML messages sent to Appian in an email should be converted to plain text before saving the message into a process variable. To facilitate this conversion the expression editor includes a function called stripHtml(). This function can be used to convert all email messages to plain text before they are captured in process variables. The function is not required, but is recommended in case you need to display the text.
When an HTML email is sent with Unicode characters, each character is replaced in the HTML with &#xxxx;
where xxxx
is the Unicode value (in decimal) for that character. These characters cannot be handled by the stripHtml() function. In this case, process designers should use the replace() function in the Expression Editor to replace the Unicode with appropriate characters.
The message type determines which message properties you can use to create event conditions and process variable mappings.
Property | Expression | Description |
---|---|---|
Body |
|
Message entered in the text area within the Configure Send Message Event dialog. |
OriginProcessID |
|
The system-assigned process ID for the process from which the message was received. |
OriginProcessModelID |
|
The system-assigned process model ID for the process model that generated the process from which the received message was sent. |
UserName |
|
Initiator of the process from which the message was sent. |
Property | Expression | Description |
---|---|---|
Body |
|
The body of the JMS message. |
OriginIP |
|
The IP address of the machine from which the message was received. |
UserName |
|
The username of the user who sent the JMS message. |
Custom property |
|
The value of the JMS property with the name given as |
Tip: For a number of email message properties, it can be helpful to use the striphtml() function to parse the HTML before writing the property data to a process variable. For example, striphtml(msg!properties.Bcc)
parses the HTML. This value can then be stored in a Text-type process variable.
Property | Expression | Description |
---|---|---|
Body |
|
The body of the email message. |
AttachmentErrors |
|
Any errors that may occur when saving the attachment from an email. The following errors may be recorded.
|
Attachments |
|
The attachments sent with the email. All attachments, by default, are uploaded to a user-specified folder within Document Management. Selecting this property returns a list of document IDs for all attachments sent with the email. |
Bcc |
|
The name and email address of all users who were sent a blind copy (Bcc) of the message. |
BccEmails |
|
The email addresses of all users who were sent a blind copy (Bcc) of the message. |
BccNames |
|
The names of all users who were sent a blind copy (cc) of the message. |
Body |
|
The body of the email message. If available, the message body with the content type |
Bodies |
|
When a single email message includes additional bodies, these are appended to the
|
BodyContentType |
|
The content type of the message body available in |
BodyTypes |
|
This type stores the content types of each message body stored in the
|
Cc |
|
The name and email address of all users who were sent a copy (Cc) of the message. |
CcEmails |
|
The email addresses of all users who were sent a copy (Cc) of the message. |
CcNames |
|
The names of all users who were sent a copy (Cc) of the message. |
From |
|
The name of the email account and email address from which the message was received. |
FromEmail |
|
The email address from which the message was received. |
FromName |
|
The name of the sender. |
Importance |
|
The priority level configured for the email. |
Key |
|
The entire text between the first set of brackets |
Recipients |
|
The name and email addresses of all users to whom the message was sent. |
RecipientsEmails |
|
The email addresses of all users to whom the message was sent. |
RecipientsNames |
|
The names of all users to whom the message was sent. |
Subject |
|
The subject of the email. |
To |
|
The name and the email address to which the message was sent. |
ToEmails |
|
All of the email addresses to which the message was sent. |
ToNames |
|
The names of the email accounts to which the message was sent. |
In addition to these pre-defined properties, you can also enter any property defined in an incoming message directly into an expression. For example, if the incoming message contains a property called CaseId
you can reference it as:
msg!properties.CaseId
Receive Message Event