More about
Service Email rules
|
|
The standard Service Email rule EmailDefault.Work-.CreateEmailFlow (and the associated service activity Work-.ProcessInboundEmail) support email conversations. When appropriately configured, each email correspondence contains a unique identifier (in the message header) associated with the originating work object ID. A reply to that email also contains that ID. The ProcessInboundEmail activity attaches the email to the work object.
The Work- base class has a Page
mode property named pyInboundEmail. The page class
of this property, Embed-Services-InboundEmailInfo,
provides standard properties that represent the individual
components of email messages: to, from, subject, body, date,
and so on. When the purpose of your email service is to create
new work objects or to manage delivery failure messages for
correspondence generated during flow processing, you and the
Email Accelerator can use these standard properties to map
email data directly to the clipboard without having to create
additional properties.
When you use the accelerator to generate email services, it configures the following inbound mappings:
You can also use .pyInboundEmail.Date for mapping the value from the Date field.
The Embed-Services-InboundEmailInfo class also provides standard properties that represent the individual components of Delivery Status Notification messages. You can use the following standard properties to map DSN data directly to the clipboard without having to create additional properties:
When the service activity is finished with its processing, the e-mail service sends the response configured on its Response tab through the e-mail listener. If another e-mail message is sent at a later point in the flow processing, that message is managed by an outbound e-mail account and not by the e-mail listener.
The Work- base class has two standard HTML rules that you can use for the service rule’s response:
When you use the Email Accelerator to generate e-mail services, it uses these standard HTML stream rules in the response. You can edit the stream rules or change the outbound mapping as necessary.
If an incoming e-mail message contains attachments, the
e-mail listener creates a page named
pyAttachmentPage of class
Data-ServiceMessage and puts the attachments on
that page. When you use the Email Accelerator to create an
email service that creates work objects, the generated service
activity automatically extracts the files from the
pyAttachmentPage and uses them as work object
attachments.
If you create an email service without using the
Accelerator, and you want the service to use the attached files
as work object attachments, configure the service activity to
handle work objects. For information, see the Pega Developer
Network article 
PRKB-24059 How to save
an incoming email message as a work object attachment using
Email Service rules.
To test arriving e-mail attachments for software viruses, override the extension point activity Data-WorkAttach-File.CallVirusCheck with an activity that calls your third-party virus software. Your activity can call a Java class or (in a Microsoft Windows server) a Dynamic Linked Library routine.
To test outbound email, run through the entire flow (Run > Process) and then verify that notify and other email messages are delivered the way you expect them to be.
To test inbound email, start with the listener. From the listener form, click the Test Connectivity button to ping the email server. Then use the System Management application to verify that the listener is running. Open the email service rule and use the Run Rule feature to run it. Finally, from the external application, send a request message to the inbox monitored by the email listener. Then check the inbox of the external application to determine whether the response message arrived and whether it contains the information you expected.
See also the Pega Developer Network document Testing Services and Connectors for
information.
