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?
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:
- Report Definition for retrieving the tabular data
- Data Page for storing the result list
- Data Transform for mapping into the result list
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.
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.
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.
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)
@edgarverburgTweets by @edgarverburg
Edgar is a software engineer with experience in TIBCO Middleware and Pega Case Managemement. He holds a master's degree in Computer Science with a specialization in Data Visualization & Computer Graphics.