When you create correspondence rules, you can use JSP tags to insert references to properties and other rules (including list view reports) or to insert other kinds of logic. When you configure utility and notify shapes that generate correspondence, you identify correspondence activities and provide values for their input parameters.
This article describes the standard correspondence activities you should use, including their input parameters, and provides an overview of the JSP tags you are likely to use in correspondence rules. It also describes the SendCorrespondence flow action and the correspondence verification flow.
- Common JSP tags for correspondence
- Work-.CorrNew activity
- Work-.Notify activity
- Work-.NotifyParty activity
- Work-.NotifyAssignee activity
- Work-.NotifyAll activity
- Add Party flow action
- Send Correspondence flow action
- Correspondence verification flow
Your correspondence rules act as templates and you can use the Process Commander JSP tag library to provide programming logic in them. This section describes the JSP tags you are most likely to use with correspondence and correspondence fragment rules. For a complete list of the tags in the tag library, see the Application Developer Help.
This tag inserts a property value for a property on the clipboard or the value of an activity parameter. Following are its attributes:
- name — the name of the property, reference to the property, or parameter. For example, .pyID or pyWorkpage.pyID
- format — the name of an HTML property rule to use to display the property if it doesn't have one assigned or you want to override the one assigned to it. If the mode attribute is present, it must be set to "display."
- mode —specifies how the value of the referenced property is to be interpreted. The default value is "display," which means that if the property has an HTML property rule, the system uses that rule when displaying the value of the property in the generated correspondence. You can also specify "input," "literal," "text," "stream," or "normal." For information about these options, see the Application Developer help.
For example, to display the value of a single-value property on the primary page:
<pega:reference name=".pyID" />
To display the value of a property on the cover page:
<pega:reference name="pyCoverPage.pyCoveredCountOpen" />
When you specify a page name in a property reference (other than pyWorkPage or pyCoverPage), be sure to define it on the Pages and Classes tab of the correspondence rule.
This tag identifies an HTML stream or correspondence fragment rule. When the correspondence is generated, the text and/or code from the referenced rule is rendered and combined into the results. Following are the attributes for the include tag:
- name — the name of the rule. For correspondence and correspondence fragment rules, the name includes their correspondence type, using the syntax "name.type." For example, "Confirmation.Email".
- type — the class of the rule being included. Rule-Obj-Corr or Rule-Corr-Fragment, for example.
For example, to display the content from an email correspondence fragment rule named OrderDetails:
<pega:include name="OrderDetails.Email" type="Rule-Corr-Fragment" />
This tag changes the page context from the primary page to the page named by this tag. You are likely to use this tag when you want to display the values of several properties from another page, rather than specifying the name of the page in each reference tag.
<pega:reference name=".pyCoveredCount" />
items you ordered,
will be shipped on <pega:reference name=".shipDate" />.
When you use the withPage tag, be sure to define the identified page on the Pages and Classes tab of theCorrespondence rule form.
Work-.CorrNew is the main correspondence generation activity. It is a utility activity and it is best practice for you to use this activity whenever you want to generate correspondence from a utility shape in a flow.
CorrNew takes the following input parameters for all correspondence types:
- CorrName (required) — the name of the correspondence rule to use
- PartyRole (required) — the role of the person to whom the correspondence is to be sent. Valid values are any of the work party roles specified in the work parties rule associated with the work class. Note that if the role is defined as a repeating role in the work parties rule, the correspondence is sent to all parties specified for that role in the work object.
- Broadcast — specifies that the correspondence should be generated for and sent to all the parties associated with the work object individually. For an email message, you can specify that one generated message be sent to multiple parties with the To and CC parameters, described below.
When the correspondence type of the correspondence rule is email, CorrNew takes the following additional input parameters:
- EmailSubject — the text for the subject line of the message AttachmentCategoriesToSend — if work object attachments should be attached to the email, which attachments (by category) to use as email attachments
- SendAllAttachments — specifies that all the work object attachments will be used as email attachments for the outgoing email message
- To_PartyRoles — additional party roles of people to whom the email message is sent. Valid values are any of the work party roles specified in the work parties rule associated with the work class.
- CC_PartyRoles — the party roles of the people who receive a cc copy of the email message. Valid values are any of the work party roles specified in the work parties rule associated with the work class.
- BCC_PartyRoles — the party roles of the people who receive a blind copy of the email message. (As with any email message, you should carefully consider your situation before deciding to use blind copies.) Valid values are any of the work party roles specified in the work parties rule associated with the work class.
- Priority — the priority level to set in the email header; valid entries are HIGH and LOW; if left blank, the priority is normal
For email messages, note that it is probably best to use the To_PartyRoles and CC_PartyRoles parameters rather than the Broadcast parameter.
A standard notify activity, Work-.Notify calls the Work-.CorrNew activity to generate a message for the person identified by a party role. When you use this activity in a notify shape, you specify values for the CorrName, PartyRole, and Subject parameters.
A standard notify activity, Work-.NotifyParty also calls the Work-.CorrNew activity and has the same input parameters as Work-.Notify, with the addition of the MinimumUrgency parameter.
When a value is provided for the MinimumUrgency parameter, the notify message is sent only if the assignment is at or above the urgency specified.
A standard notify activity, Work-.NotifyAssignee sends an email message to the operator who received the assignment. It has the input parameters CorrName, Subject, MinimumUrgency, and EmailTo. Use the EmailTo parameter only if the assignee is a workbasket and you want to override the contact person specified in the workbasket definition.
The EmailTo parameter accepts an operator ID (instance of Data-Admin-Operator-ID). The activity creates a work party association for the operator specified with this parameter.
A standard notify activity, Work-.NotifyAll calls the Work-.CorrNew activity with the Broadcast parameter set, which means the message is sent to all the work parties associated with the work object. Its input parameters are CorrName and Subject.
The standard section rule AddPartyCoreParty displays work party information on work object forms. Many of the example flows in the PegaSample application include that section on the New and Perform harnesses. It works in conjunction with the AddParty flow action. The AddParty flow action enables users to add work parties to work objects.
The Send Correspondence flow action starts the BuildCorr screen flow and this is the first form in that flow:
The operator specifies a work party role in the Send Correspondence to field and the BuildCorr flow then displays the Select correspondence template form:
If the operator selects a correspondence rule that has a prompt configured, the flow prompts for the value in the Provide Correspondence fields form. For example, here's the Provide Correspondence fields form for the Work-.AcknowledgeSample correspondence rule:
If the correspondence rule has been configured to display the generated correspondence for review, the next form displays the generated correspondence. When the user is finished, the BuildCorr flow returns the user to the assignment.
As described in the Verifying Generated Correspondence section of "Overview of the Correspondence Feature", you can specify that any correspondence generated from a correspondence rule must be verified before it is sent. When the correspondence is generated from that rule, flow processing starts a flow named Work-.VerifySendCorr.
The VerifySendCorr flow creates an assignment and routes the generated correspondence to the work group manager of the operator who caused the correspondence to be generated. In its default state, this flow enables the manager to edit the results, and then to either verify (approve) or reject the correspondence.
Examine the Work-.VerifySendCorr flow to determine whether it provides the appropriate verification steps for your application. If it does not, save it into one of your application RuleSets and modify it as needed.