How inbound email is processed
Email services (Rule-Service-Email) manage inbound email. An email listener monitors an inbox on an email server and, when messages arrive, routes them to an email service rule. Typically, an email service does one of the following:
- Uses the information from the email message to create a new work object or update an existing one.
- Monitors the email account that processes your outbound email (typically generated from flow processing). Such an email service responds appropriately when outbound correspondence triggers delivery failure messages.
To configure an email service, you use the Email Accelerator to set up the following rules and data objects:
- The default service package named EmailDefault
- An email service rule whose service activity creates work objects from the incoming message
- An email server data object that represents a physical email server
- An email listener data object that monitors an inbox on the email server and routes the messages to the email service
Service package (EmailDefault)
Unlike the other service rule types, email service rules have only one key and their names do not include a service package name (Data-Admin-ServicePackage). Instead, email service rules rely on a standard service package named EmailDefault. All email services share the EmailDefault service package, which means that all email services use the same access group unless they run as authenticated users.
Email server data instances (Data-Admin-Connect-EmailServer) represent a physical email server. Email listeners connect to the server represented by the data object and then route messages from the server to email service rules.
Email listeners (Data-Admin-Connect-EmailListener) provide Process Commander with the information it needs to route email messages from an email server to an email service rule. A listener object identifies the email server, the name of the mail folder to monitor, the message format of the incoming messages, which email service rule to route messages to, and so on.
When the flow for the work object created from the email message routes assignments to "current operator," the service requestor must run as an authenticated user. In such a case, you specify a user ID and password that identifies a valid operator ID on the Email Listener form in the Accelerator. Or, after the Accelerator finishes, you can open the generated listener and enter these values on the Properties tab of the listener form.
Like other types of listeners (file, MQ, and JMS), email listeners start when Process Commander starts. When you create new listeners, you can start them from the System Management application.
When an email listener routes a message that has files attached to it, the listener creates a page named pyAttachmentPage (of class Data-ServiceMessage) and puts the file(s) on that page. If email messages contain embedded images and it is important to be able to see them in their original context, configure the listener to save the original email, complete with embedded images, as an attachment.
Email service rule
As do all service rules, the email service rule specifies how to map the information from the incoming message to the clipboard and how to assemble a response, if one is necessary. It also identifies the service activity to use to process the data from the incoming message after it is mapped to the clipboard.
When you select the "create a work object" option, the Email Accelerator specifies the standard activity named CreateWorkFromMail as the service activity. This activity creates the work page, starts the specified flow, and then automatically manages email attachments. It attaches any files from the incoming email messages as work object attachments.
If you are writing your own service activity and you want it to manage email attachments, see How to configure an email service to use an email attachment as a work object attachment.
The generated service activity does not include steps that process delivery failure messages. If you want your email service to process undeliverable or bounced messages, see How to configure an email service to respond to AutoReply and Delivery Status Notification (DSN)messages.
Data mapping defines the relationships between parameter-value pairs in external systems and property-value pairs on Process Commander clipboard pages. When you use the Email Accelerator to generate an email service, the Accelerator maps the request to a set of standard Work- properties and the response from a set of standard HTML rules.
Inbound Mapping ― Request (Map To)
The Work- base class has a page property named pyInboundEmail. This page property is of the class Embed-Services-InboundEmailInfo, which has the following properties:
Because your work classes inherit this property, you (or the Accelerator) can map email data directly to the clipboard without creating additional properties. When you use the Accelerator to generate email services, it configures the following inbound mappings:
- The string from the To field is mapped to .pyInboundEmail.pyTo
- The string from the CC field is mapped to .pyInboundEmail.pyCC
- The string from the From field is mapped to .pyInboundEmail.pyFrom
- The string from the Subject field is mapped to .pyInboundEmail.pySubject
- The message data is mapped to .pyInboundEmail.pyBody
The Embed-Services-InboundEmailInfo class also has standard properties that you can use to map information from Delivery Status Notification messages. For information, see Create an email service that responds to AutoReply and Delivery Status Notification (DSN) messages.
Note: In versions of Process Commander prior to V5.3, the standard, single-value text property Work-.pyEmailBody supports the process of setting up inbound email through the email account data object. This property remains in V5.3+ to support backward compatibility, but you should not use it with email services.
Outbound Mapping — Response (Map From)
When you use the Accelerator to generate email services, it configures the following outbound data mappings on the Response tab:
- The value for the From field is taken from the .pyInboundEmail.pyTo property.
- The value for the Subject field comes from the Work-.EmailHeader HTML stream rule. It uses the text from the original email subject (pyInboundEmail.pySubject).
- The body of the response message comes from the Work-.EmailResponse HTML rule. This rule generates a simple thank-you message that provides the work object ID for the new work object (created by the service processing) and includes the message data from the original email.
You can edit the stream rules or change the outbound mapping as necessary.
When the service activity is finished with its processing, the email service sends the response configured on its Response tab through the email listener. If at a later point in the flow processing another email message is sent, that message is managed by an outbound email account and not by the email listener.
Continue to: Before you begin configuring email
Return to: About Email