Reporting on the Performance Data Warehouse (PDW) "the right way" means: tracking groups feed the PDW, a report reads the PDW views, never the live BPMDB. A worked example with the OOB Report Builder (8.5.x Reports in Process Designer) and the same with SQL / an external tool:
- Define a tracking group "OrderTracking" with fields orderId, region, amount, status; enable auto-tracking on the BPD and add tracking points where the status changes (or map the fields on activities); install the snapshot - the PDW creates a view per tracking group with your fields plus timing columns.
- Report Builder (8.5.x): Process Designer > Reports > new report > data source = the tracking group; drag a chart (bar by region, value = count of orderId), add filters (date range on TIME_STAMP), preview, and expose the report as a dashboard item for a team. The report runs SQL against the PDW views under the hood; its parameters become portal filters.
- SQL for external BI (the way most teams end up):
-- PDW: one view per tracking group (name = tracking group name + snapshot suffix), plus the process/task timing views
select region, count(distinct orderId) as orders, avg(amount) as avg_amount
from ORDERTRACKING_V -- exact view name: select viewname from syscat.views where viewname like 'ORDERTRACKING%'
where TIME_STAMP >= current date - 30 days
group by region;
-- process durations from the standard views
select bpd_name, avg(timestampdiff(2, char(end_time - start_time))) as avg_seconds from lsw_bpd_instance_v group by bpd_name; -- PDW process instance view (name per release)
Rules: report on the PDW, not on the runtime tables (locks, missing history); keep tracked fields small and typed (no blobs); name tracking groups by domain and version them with the snapshot; on BAW 20+ / CP4BA prefer Business Automation Insights for dashboards (question on PDW vs BAI) and keep the PDW for the portal's KPIs. The Report Builder of 8.5.x was removed later - build reports in Cognos / Power BI / BAI against the same views.
References