Constructing a Response Mapping in Pega

Sadly, Pegablog.com had a site outage over the weekend, but we´re back online now. The holidays are coming, which usually means the busiest time of the year — especially when you are in retail. December continues to be the month of the most online orders and deliveries to make all of your customers (and more-so their children) happy.

Reporting in Pega

Regardless of your the business you are in having accurate sales numbers and other tangible metrics is essential to staying on top of CRM. Pega provides out-of-the-box reporting to inspect how your business teams are performing. Some examples of standard reports (by category) are:

• Average duration per flow task (Analyze Performance)
• Case Volume (Case Metrics)
• Effort by organizational unit (Monitor Processes)
• User Timeliness (Service Level Performance)

The possibilities do not end here. In fact, PRPC allows you to report over any class and piece of information you deem valuable. Like to know what parties exist on certain work item? No problem. Rather want specific roles only? No problem either. But how exactly can we return these valuable lists into the right (control) format?

List Source

This article will show you how to select and combine your table data and return is as common class Code-Pega-List for reuse as list data source throughout your application. This means the report data can be leveraged directly for populating GUI components like dropdown lists, radio buttons or autocomplete. Even any detail section could provide just the right information where it matters most.

Constructing a Response Mapping

You will need the following three rule types to construct a generic response list with report data:

1. Report Definition for retrieving the tabular data
2. Data Page for storing the result list
3. Data Transform for mapping into the result list

Use Case

For this example let me explain how to list parties of specific role that exist for certain work item and display that list as detail view. Notice that since the party class (Data-Party) differs from the context of the report (some Work- class) the need arises for a response mapping.

Background: We could settle by defining the data page on that Work class instead, but that would make the solution less generic. As a best practice always try to put the report definition rule in the class where you like to report over.

Report Definition

In our exemplary scenario we would like to report over case law (Rechtspraak) work items and show the associated parties of certain roles ("Insteller" or "Wederpartij"). For input I defined Param.CaseID corresponding to Pega´s pyID, but you could also leverage the standard instance key, pzInsKey, if you are worried about mixing up of different classes.

This report will filter and return the existing parties by full name along with identifier and role for the the requested work item.

Declarative Joins

Note that work parties live in a separate index table. In order for you to access and select or even filter them you need to set a Declarative index join. The standard index is called "PartyURI" which holds a minimal set of party properties, but does includes the pxPartyRole we are interested in for filtering.

Note: Determining and configuring the appropriate JOINs through the Data Access tab to gather the right information is typically one of the first steps in defining a new report definition.

Data Page

Whenever the Data Page´s applies to class differs from what object class is returned by your Report Definition you´ll need to construct a so-called Response data transform. This transforms is needed to map (some or all of) your properties in the report´s class to appropriate properties on the data page.

It could take some time to locate a good example for such a mapping. This is why I wrote this article.

Response Data Transform

Let´s turn to the critical part of this solution. First, I´ll set the common input page for sourcing data. Next, map this source to the appropriate target page and make sure the run-time pages & classes are set correctly.

Parameters and Mapping

The essential input for any response data transform lives on a page called "DataSource".

This DataSource page is where PRPC puts the report definition results and we need to pass it into our transform. The input data page is of the same common list class Code-Pega-List, so it is convenient to construct the response from a simple Append and Map to Primary.pxResults each page in this DataSource.pxResults on the Definition tab.

Note: Joined results end up in a special page group property with the name of the join´s prefix, i.e. pxPages(PartyURI).

Pages & Classes

Make sure you set the run-time Pages & Class appropriately otherwise the rule won´t save.

Enjoy building your Christmas list Turbo Man! ;-)

[Edgar] (12/18/2017 8:14:48 AM)