Our BIRT report for production order status in the production planning module is experiencing severe performance degradation. The report queries approximately 18 months of historical production data across multiple plants and typically takes 8-12 minutes to execute, sometimes timing out completely.
The report includes production order details, material consumption, work center utilization, and variance analysis. We’re querying roughly 250,000 production orders with associated line items. The underlying query joins multiple tables and includes several calculated fields for yield calculations and efficiency metrics.
Users are complaining about report delays impacting daily operations. We’ve tried adjusting the date range to 6 months, which helps somewhat (down to 5-6 minutes), but management needs the full 18-month view for trend analysis. The Report Writer performance seems particularly bad during peak hours. Has anyone optimized BIRT reports handling large datasets in production planning? What’s the best approach for performance tuning without losing required functionality?
Good suggestions. We are filtering at database level with date parameters, but I think we might be selecting too many columns. The calculated fields for yield are definitely computed in the report itself - moving those to a database view makes sense. How do I implement report caching in Workday? Is that a BIRT configuration or Workday-specific setting?
First thing to check - are you using report parameters to filter at the database level or are you pulling all data and filtering in BIRT? Database-level filtering is critical for large datasets. Also, check your BIRT data set query. If you’re doing SELECT *, you’re pulling unnecessary columns. Only select fields actually used in the report.
250K orders is definitely pushing BIRT’s limits. I’d recommend implementing report caching for this use case. Configure the report to cache results for 4-6 hours during business hours. Most users don’t need real-time data for historical trend analysis. Also, consider creating database views that pre-aggregate some of your calculations. Yield and efficiency metrics can be calculated once and stored rather than computed on every report run.