We’re experiencing significant delays in our logistics dashboard refresh cycles. Shipment status updates made in the Transportation Management module take 4-6 hours to appear in our OTBI dashboards, which is causing major operational issues.
Our team needs near real-time visibility for customer inquiries and exception management. We’ve noticed the ETL job scheduling seems inconsistent - sometimes updates appear in 2 hours, other times it’s 6+ hours. The data model refresh intervals might not be optimized for our volume.
I suspect there’s also caching in the reporting layer that’s holding stale data. Has anyone dealt with similar latency issues in logistics dashboards? We’re on 23C and using standard OTBI reports with BI Publisher for custom layouts.
I’ve seen this exact issue before. The default ETL refresh for logistics subject areas runs every 6 hours, which explains your lag. You need to check the Incremental Refresh Schedule in BI Publisher administration.
Navigate to Analytics > Administration > Manage BI Publisher > Scheduler and look for the Logistics Data Warehouse jobs. These can be adjusted to run more frequently, though be careful about system load during peak hours.
I’ll walk you through a comprehensive solution that addresses all three areas causing your delays.
First, ETL job scheduling optimization: Access the BI Administration console and navigate to the Data Warehouse Scheduler. Modify your Logistics subject area refresh from 6-hour to 2-hour incremental refreshes. Set the schedule to run at :00 and :30 past each even hour (8:00, 8:30, 10:00, 10:30, etc.) to distribute load. Enable the ‘Skip if Previous Job Running’ flag to prevent overlapping executions during high-volume periods.
Second, data model refresh intervals: Review your RPD (Repository) metadata for the Logistics subject area. Ensure that your logical table sources are properly configured for incremental extraction. Open the Administration Tool, navigate to Physical layer > Logistics_DW, and verify that your ETL_PROC_WID and INTEGRATION_ID columns are properly indexed. These drive incremental detection. Set your cache persistence time to match your new ETL schedule - 2 hours maximum.
Third, caching in reporting layer: This is critical. Navigate to Analytics > Administration > Manage Cache. For your logistics dashboards specifically, implement a hybrid approach: (1) Disable cache entirely for your critical real-time views using the cache control settings in each dashboard’s properties - set Cache Persistence Time to 0 for exception monitoring dashboards. (2) For historical trend dashboards, keep cache enabled but reduce persistence to 2 hours to align with ETL. (3) Implement event-driven cache invalidation by enabling the ‘Clear Cache on Data Change’ option in the BI Publisher scheduler configuration.
Additionally, consider enabling the Real-Time Integration option for your most critical 5-10 metrics. In 23C, you can configure specific subject area queries to bypass the warehouse and query operational tables directly. This is found under Analytics > Subject Areas > Logistics > Advanced Options > Enable Direct Query Mode. Use this sparingly as it impacts transactional system performance.
Finally, set up monitoring alerts in the BI Scheduler to notify you if any ETL job exceeds 30 minutes or fails. This ensures you catch refresh issues before they impact users. After implementing these changes, you should see dashboard latency drop from 4-6 hours to 15-30 minutes maximum, with critical real-time views updating within 5 minutes of transactional changes.
The caching layer is definitely part of your problem. OTBI has multiple cache levels - the BI Server cache and the Presentation Services cache. Even if your ETL runs frequently, cached results can persist for hours.
Go to Administration > Manage Sessions and Caching, then review your cache policies. For critical logistics dashboards, you might want to implement event-based cache invalidation rather than time-based. This way, when shipment status changes trigger in the transactional system, the cache gets cleared automatically.