The analytics dashboard in OutSystems process analytics shows data that’s 24-48 hours old, even though our ETL Scheduler runs successfully every night at 2 AM. The ETL job logs show completion without errors, and I can verify fresh data exists in the reporting tables when I query them directly in SQL.
The dashboard data source binding points to these same reporting tables, but the UI displays stale metrics. I suspect either aggressive cache management is preventing refresh, or the dashboard isn’t properly re-binding to the data source after the ETL job completes.
Here’s what I see in the reporting table:
SELECT MAX(LastUpdated) FROM ProcessMetrics_Report
-- Returns: 2025-01-22 02:15:00 (today)
But dashboard shows KPIs from January 20th. This is causing outdated KPIs to be presented to management. Has anyone dealt with dashboard data source refresh issues after scheduled ETL jobs?
Also look at the reporting table refresh mechanism itself. Sometimes ETL jobs update staging tables but don’t properly swap or refresh the final reporting tables. Use a timestamp column to track when each table was last updated, then compare that to your dashboard query execution time in the logs.
RefreshAllAggregates() can be unreliable for large datasets - it might timeout or skip some aggregates. I recommend using RefreshAggregate() for each specific aggregate your dashboard depends on. Also, check the aggregate refresh interval settings in Service Center. If they’re set to manual refresh only, your scheduled refresh might not be triggering properly.
Another thing - verify your dashboard data source binding is actually pointing to the aggregates, not the base tables. If it’s mixed (some widgets on aggregates, some on tables), you’ll get inconsistent freshness across your dashboard.
I’m betting it’s cache management causing the issue. OutSystems dashboards cache query results aggressively for performance. Check your dashboard screen preparation - is there a CacheInMinutes parameter set? If so, that’s overriding your fresh data. You need to either reduce the cache duration or implement cache invalidation logic that runs after your ETL job completes.