After our nightly data sync completes, BIRT reports in quote management are still showing yesterday’s pricing instead of the updated rates. The integration job runs successfully according to the logs and shows all pricing records updated, but when sales reps generate quotes using our custom BIRT report, they’re getting stale data. This is causing quoting errors and we’ve had to manually verify pricing on every quote.
The BIRT report queries the pricing tables directly, and when I run the same query in the database, I can see the updated prices. But somehow the BIRT report is cached or not refreshing properly. We’re on R2 2023 and this started happening after our last tenant update two weeks ago. Anyone experienced similar issues with BIRT report data source mapping or report cache management?
I’ll walk through all three focus areas to resolve this:
BIRT Data Source Mapping: After the R2 2023 update, several pricing-related data source views were restructured. Open your BIRT report in Report Designer and examine the data set query. You’re likely using a query like SELECT * FROM PRICING_CURRENT - this view was deprecated in R2 2023. Update your query to use PRICING_EFFECTIVE_DATED instead, which is the new standard view. Also check that your data source connection is pointing to the correct database schema - in R2 2023, reporting views were moved from the WD_REPORTS schema to WD_ANALYTICS_REPORTS. Update your JDBC connection string accordingly. If you’re using multiple data sets in the report, verify each one individually.
Integration Job Monitoring: Your integration job logs showing success doesn’t tell the full story. Log into Integration Cloud and navigate to your pricing sync integration. Click on the execution history and drill into the detailed logs - look specifically for the “Records Updated” count and compare it to the “Records Processed” count. If these numbers don’t match, you have a partial failure that’s not being caught by the summary status. Also check the job’s commit strategy - it should be set to “Commit After Each Batch” rather than “Commit at End” to ensure data is available immediately. Finally, verify the job’s execution time - if it’s running at 2:00 AM but taking 3 hours to complete, your morning reports might be running before the job finishes. Add a post-integration step that triggers a report cache clear.
Report Cache Management: This is likely your main issue. BIRT has three layers of caching that all need to be addressed. First, the report document cache - in your BIRT runtime configuration, set the document cache to expire after 1 hour maximum for pricing reports. Second, the result set cache in your data set properties - open each data set in your report design, go to Property Binding, and set Cache Row Set to False for pricing data sets. Third, the application server cache - if you’re running BIRT on Tomcat or another app server, clear the work directory cache manually after your integration job completes, or better yet, add a cache-clear API call to your integration job’s post-processing script.
Implement these changes in order: fix the data source mapping first, then verify your integration job is truly completing successfully, and finally address the caching layers. After implementing, test by manually triggering your integration job and immediately running a quote report to verify fresh data appears.
This draft is based on general Workday knowledge. It has not been verified against your specific version and environment. Practitioners: verify the steps and share your experience below.
Classic BIRT caching issue. Check your report’s data source connection settings - there’s likely a cache duration parameter that’s too long. In BIRT Report Designer, open your report and go to Data Source properties. Look for the connection pooling and cache settings. You might have result set caching enabled with a 24-hour duration.
We had this exact problem. The issue wasn’t the BIRT report itself but how Workday’s integration job updates the data warehouse tables. Check if your pricing sync is updating the operational tables but not the reporting tables that BIRT uses. You might need to add a refresh step to your integration job that explicitly triggers the reporting table update. Look at your integration job monitoring logs to see which tables are being touched.
This sounds like a data source mapping issue to me. In R2 2023, Workday changed how some of the pricing data sources are structured. Your BIRT report might be pointing to a deprecated data source view. Go into your BIRT report design and check the data set query - verify it’s using the current pricing view name. After the R2 2023 update, some views were renamed from PRICING_CURRENT to PRICING_EFFECTIVE_DATED. If your report is still using the old view name, it might be hitting a compatibility layer that has stale data.
Have you checked the integration job schedule versus when users are running reports? If your nightly sync runs at 2 AM but the BIRT report server caches results starting at midnight, you might be getting the previous day’s cache. The report server might be pre-generating common reports before your data sync completes.
Confirmed this resolves the issue — updating our BIRT data set query from PRICING_CURRENT to PRICING_EFFECTIVE_DATED in Report Designer immediately pulled accurate post-sync pricing data.
Don’t forget about the BIRT report engine’s own cache on the application server. Even if your data source is correct and the database has fresh data, the report engine might be serving cached output. You need to clear the report engine cache or adjust the cache expiration settings in your BIRT runtime configuration.
Check if your integration job is committing transactions properly. Sometimes jobs show as successful but don’t actually commit the final batch of updates due to timeout issues or transaction rollback. Review the detailed integration logs, not just the summary status.