Writing dynamic Correspondence rules in Pega

Although Pega´s case management platform is configuration driven and designed to be a zero code system, like any other platform doing some coding (only where appropriate) can help you to prevent unnecessary rule changes in the future.

One good example of this is writing dynamic Correspondence rules. Writing the proper correspondence can go a long way in maintainability of your application. The math is on reducing such technical dept really simple: the less rules you create, the less maintenance is needed in keeping your communications up to date.

Approach

Consider making a distinction between technical Correspondence rules (for reuse) versus top-level correspondences that you could delegate to the business. This will both involve them better and helps getting self-sufficient more quickly in Pega. Such approach should lead to creating two or more levels of (nested) correspondence rules and templates.

We maintain technical correspondences in "Source only mode" for developers assuming they are familiar with JavaServer Pages (JSP) and HTML, while the delegated correspondence rules remain in normal (WYSIWYG) mode for readability by the business.

Remember: Correspondence fragment rules do not have a ruleset [version] and thus are application global by design. Such fragments are typically used as template for standard text blocks, i.e. sender address block, signatures, etc.

Do´s and Don´ts

Here some guidance to using the Correspondence rule type in PRPC:

• Ideally put your Correspondence in the same class as (most of the properties) the properties it will reference with the pega:reference. In contrast, company stuff such as logos and banner/footer texts can be put in the enterprise layer.
• Personally I strictly write rules of class Rule-Obj-Corr and Rule-Corr-Fragment for pure communication versus Rule-HTML-Section and Rule-HTML-Paragraph which are leveraged for on-screen purposes only. This keeps their intent clear.
• Similarly, Correspondence type Email is for that communication channel only, while type Mail is exercised for both Letters as well as PDFs that we generate on the platform.
• Don´t reference using multiple dot notation (you would expect in Java) on a page or property when actually referring to embedded properties of that page such as pyWorkCover.Order.DeliveryAddress. This caveat can be simply overcome by splitting in a withPage and nested withEmbedded construction like:

<pega:withPage name="pyWorkCover"><pega:withEmbedded name=“.Order.DeliveryAddress"><pega:include name="AddressBlock.Mail" type="Rule-Obj-Corr"></pega:include></pega:withEmbedded></pega:withPage>

• Another best practice is to always make use of standard formatters for displaying properties. For example to display a basic boolean property value with DisplayYesNo:

<pega:when name="IsApprovalRequired">
	<h2>Approval</h2>
	<p>Approved: <pega:reference format="DisplayYesNo" name=".IsApproved"></pega:reference><br />
	<pega:reference format="Text" name=".ApprovalMemo"></pega:reference></p>
</pega:when>

Tip: You could use the shortcut tag for referencing properties instead.

[Edgar] (11/25/2017 9:34:56 AM)