Custom Fiori mobile app for warehouse management shows high latency during barcode scanning operations

We developed a custom Fiori mobile app for warehouse inventory management integrated with SAP IBP. Users report significant delays (3-5 seconds) when scanning barcodes to update stock levels. The barcode scan performance is unacceptable for high-volume warehouse operations where workers need to process 100+ items per hour.

The app makes OData calls to update inventory positions in IBP after each scan. We’re suspecting the latency comes from either the OData service response time or the mobile device processing. We’ve tested on various Android devices (Samsung Galaxy Tab A8, Zebra TC52) and iOS devices (iPad 9th gen), and the problem is consistent across all platforms.

Mobile device profiling shows CPU usage spikes to 60-70% during scan operations, which seems excessive for what should be a simple data update. The network latency to our IBP system averages 150ms, so the 3-5 second delay must be coming from somewhere else in the processing chain.

For warehouse operations, I’d recommend a hybrid approach: queue scans locally and sync every 5 items OR every 30 seconds, whichever comes first. This balances real-time visibility with performance. Also, make sure you’re using the offline OData plugin if you’re not already - it handles queuing and conflict resolution automatically.

I’m seeing two issues here. First, your OData model isn’t using deferred batch groups, which means every update hits the backend immediately. Second, the high CPU usage suggests you might have inefficient data binding or unnecessary view re-rendering after each scan. Are you refreshing the entire inventory list after each update? That would definitely cause performance degradation. Consider implementing a local queue with periodic background sync instead of real-time updates for each individual scan.

The synchronous OData update call is blocking your UI thread. Each scan waits for the previous update to complete before processing the next one. You should implement batch operations to queue multiple scans and send them in a single OData batch request. This reduces network round trips significantly.