How To Chain Together Multiple Joins in A Report Definition Rule
How To Chain Together Multiple Joins in A Report Definition Rule
How To Chain Together Multiple Joins in A Report Definition Rule
rule
Summary
When assembling data for a report, it is often necessary to to include information drawn from multiple,
related data tables. To build such reports In V5.x, it is often necessary to write a custom "getContent"
activity with complex SQL statements that establish the relationships ("joins") between the information
in tables A, B, and C, and then to state what data to provide from the three joined tables.
With V6.1 SP2, in many cases it is no longer necessary to write complex SQL statements for querying
the database. Instead, you can chain together multiple joins in a report definition rule.
The example for this article relates to a Project Management Framework installation that tracks product
development. The development effort involves several teams using the Scrum methodology (for those
who do not know Scrum, team tasks are written up as "stories", and stories not yet being worked on are
stored in a "backlog"; stories being worked on are part of a "sprint", typically a two-week development
effort). The manager wants a report that will show how many stories are in the backlog for each team,
and the total number of stories in all backlogs for a specific product development effort.
The data is in a number of classes; each class is associated with a table in the PegaRULES database.
From PegaProjMgmt-WorkGroup, the report gets information about the users stories and backlogs
they are in.
From PegaProjMgmt-Work-Project the report gets information about the development project.
From PegaProjMgmt-Work-Product the report gets information about products, and
From PegaProjMgmt-Work-Product-Version the report gets details about product versions.
The Link-TaskGroup class associates user stories to backlogs or sprints.
The report receives a statement about which product and version to search for, and assembles all the
user stories that are in backlogs of projects associated with that product and version.
The diagram indicates that user stories are related to backlogs through a separate class (Link-
TaskGroup), though both are instances of the PegaProjMgt-WorkGroup class. Backlogs are related to
projects, which are in turn related to products and versions.
The lengthy SQL statement that would be needed to accomplish this complex calculation and five-way
join looks like this:
Using the Data Access tab and Pages & Classes tab of the report defintion rule, you can define these
cascaded join conditions individually. You do not need a custom activity or hand-crafted SQL.
Suggested Approach
For each join, click Edit Conditions to display a form in which to specify the filter conditions. For the five
class joins for this report, the filter conditions are:
In the Rows to Include section, specify filters for the data. In this case, the report wants only work
objects for project PRD-6 that are stories in the various team backlogs: