Configuring Email Communication in Pega

While email is one of the oldest applications of the internet – taking shape as early as the 1970s – it remains valuable to us and equally so to businesses around the world. A system being able to send and receive emails is still very useful in the context of Customer Relation Management (CRM). Who wouldn´t expect prompt 24/7 response to and handling of their request by e-mail?

In Pega´s Case Management, applications are very likely to send email notifications to the people involved; especially when they are external parties without Operator access. Your customers will hate you if you spam them from a no-reply address (pun intended). As a direct consequence one can expect to receive replies on these notifications as well. So let us take a closer look at the steps involve in configuring PRPC to support this properly [from a developer´s point of view].

TIP: Managers should start their implementation project by getting email communication enabled for PRPC from day one given the typical lead times for technical challenges and formal approval related to email servers.

Inbound versus Outbound

Although connection settings appear shared on so-called Email Account rules, it is important to understand the service concepts in Pega and the additional classes that implement these. The following UML diagram provides an overview. Each Email Listener is tasked with monitoring a single IMAP or POP3 mailbox on the mail server - as configured on the Receiver part of the Email Account rule. The Listener operates by polling every 60 seconds or whatever interval you configure. Each inbound message will trigger the configured Service Email method call once; by default mapping the Request to the .pyInboundEmail property on the service page.

NOTE: A Service Package can contain multiple service rules with the goal that multiple listeners fire off distinct activities in PRPC.

While the Sender part of the Email Account rule is sufficient to support outbound email notifications, the Receiver part as well as Listener, Package and Email Service rule are mandatory for inbound communication. Because of the dependencies among those rules, it is often practical to run through the Email Wizard at least once for your application; then customized from there.

Observe that outbound communication is based around the Class Group i.e. Work; otherwise the getSenderEmailInfo activity falls back to the account rule named Default. So, if you like to differentiate among multiple From: addresses without relying on some Reply-To override you will have to define additional Class Groups.

TIP: If the Case Type disappears from the menu you might need to re-associate the relevant type in your Application rule after you isolated that class into a new group.

Defining an Account

The Email Account rule (Data-EmailAccount) defines all settings that are common to making connections to an email server. The following email providers are supported by Pega out-of-the-box:

• Apache James
• Google Gmail
• IBM/Lotus Email
• Microsoft Exchange Server 2007
• Microsoft Exchange Server 2010/2013
• Microsoft Outlook.com (Windows Live Hotmail)
• Yahoo! Mail

You can define a single Default sender configuration or have more specific rules named after your Work- class group. You could want to send your notification for Orders from a separate account than for Customer Service; given these processes are supported by different case types. As an example for bookings we provide:

Email Wizard

Once you´ve configured and connection tested your first email account in PRPC, the quickest way to define the remaining rules is by simply using the Email Wizard found under Designer Studio > Integration > Email. The two most important steps are:

In the step Enter Email Information it is the most powerful starting point to keep the option "Receive and email and create/manage a work object". Next, select the Work class and its flow that you would like to create an instance of upon receiving an email. It´s a safe bet to keep pyStartCase until you introduce a dedicated flow. You can consider creating a separate service ruleset for maintaining your listeners and other service rules.

For the Inbound Listener step it is a good practice to provide a functional listener name related to the process it will be handling inbound emails for. Consider creating a dedicated Mailbot Operator which will act as the Requestor in PRPC. This makes it easy to recognize these auto-created case instances.

Finish the subsequent steps by keeping the Service Package defaults. It´s okay the ignore the Email Account details warning when you´ve created the correct account rule up-front (see above). The Service Package (Data-Admin-ServicePackage) should contain at least one method to be useful. The remaining configuration of this rule will tell PRPC how to process incoming requests; in this example individual stateless handling of inbound emails. Pega services by default require authentication after which only access is granted to the extend of what is defined on associated access group.

TIP: Since services represent an attack surface you are encouraged to define a dedicated access group with limited privileges; tailored to the purpose of that service.

More about the Listener

The Email Listener rule (Data-Admin-Connect-EmailListener) governs on which hosts and nodes this listener process is supposed to run. Or it can be blocked for startup.

CAUTION: Unblocked listeners will get started automatically during a reboot.

Customizing your Service

The Service Email rule (Rule-Service-Email) not only defines which activity to trigger, but also houses the Request and Response mappings. These mappings allow you to assign the email headers and body to properties in your Work class.

NOTE: The Email Wizard´s default activity is called pyCreateAndManageWorkFromEmail, but the Pega samples also leverage the CreateWorkFromMail or pyCreateBasicProcess activity as service method.

[Edgar] (7/16/2017 5:44:38 PM)