Defining a reporting strategy
2 Tasks
45 mins
Advanced
English
Scenario
Truck vendors associated with MDC (Metro Delivery Services) are facing significant operational challenges due to over- and under-bookings of trucks. When a surge in delivery request bookings arrives from partners, MDC finds itself short on on-demand trucks, while at other times daily-assignment trucks sit underutilized. This imbalance results in ineffective truck route management and substantial revenue loss for truck vendors.
Truck vendors need visibility into booking trends so they can proactively manage fleet capacity, improve service quality, and protect revenue. MDC, in turn, needs to:
- Compare current revenue against historic revenue on a given day, month, quarter, or year to understand year-on-year yield.
- Analyze delivery request volumes by business partner - comparing current year figures against the previous year, to identify growth patterns and anomalies.
The following table provides the credentials you need to log in to the Delivery Service application. However, this challenge is mainly meant for evaluating the design options, and there are no specific implementation tasks.
| Role | User name | Password |
|---|---|---|
| Admin | admin@deliveryservice | rules |
Detailed Tasks
1 Review design details
MDC's own application stores Data Types corresponding to delivery requests and invoices in an external database, separate from the PegaDATA schema. When evaluating a reporting strategy, the following performance implications must be understood:
- PegaDATA schema reporting requires accessing and aggregating numerous rows across multiple tables. Even with database tuning, placing large amounts of data on the clipboard can severely impact JVM performance and degrade the experience for web-tier users who share the same PegaRULES database.
- Because of this, storing reporting data in the external database and offloading extraction duties to a dedicated component is the recommended approach.
The optimal architecture for MDC's reporting needs is to use Pega BIX to publish data from the external database to a data warehouse such as Google BigQuery, or a corporate ODS (Operational Data Store). BIX functions as a high-performance, multi-threaded ETL (Extract, Transform, Load) tool within Pega Platform™.
The BIX extract process must run on a dedicated type=BIX node. This architectural isolation is critical because it ensures that the resource-intensive extraction workload does not adversely impact type=WebTier nodes, which handle live user interactions and daily operational tasks. The following diagram shows how data flows from the external database to the MDC Delivery Service data warehouse through BIX:
2 Review design alternatives
As an alternative, data can be loaded directly into Pega Platform, and reports can be created using in-platform reporting tools. However, retrieving several thousand rows and aggregating them over time (particularly for year-on-year comparisons) carries a significant performance cost and is not recommended at the anticipated MDC data volumes.
Available in the following mission:
If you are having problems with your training, please review the Pega Academy Support FAQs.
Want to help us improve this content?