We’re redesigning our sales forecasting implementation in SAP CX and debating where to place the core forecasting calculation logic. Currently, we have server-side ABAP logic that runs nightly batch jobs to calculate forecasts based on historical data, pipeline status, and weighted probabilities. It works but the overnight processing means forecasts are always 12-24 hours stale.
We’re considering moving some forecasting logic client-side (Fiori apps with JavaScript calculations) to provide real-time forecast updates as sales reps modify opportunities. The trade-off is performance - client-side calculations might be slower for large datasets, and we’d need to ensure calculation consistency across different users’ browsers. We also have complex analytics integration requirements where forecast data feeds into executive dashboards.
What’s the community experience with server-side versus client-side forecasting logic? Where does the performance impact actually matter most, and how do you handle analytics integration when calculations happen client-side?
We went through this exact debate two years ago. Ended up with a hybrid approach - lightweight client-side calculations for immediate feedback when reps adjust opportunity amounts or probabilities, but server-side for the complex multi-factor forecasting that considers historical trends, seasonality, and territory performance. The key is defining which calculations need to be instant versus which can tolerate slight delays.
Client-side has its place for user-driven scenarios. When a sales manager is doing pipeline reviews and wants to model different scenarios - “what if we move these deals to next quarter” - client-side calculations provide instant feedback without server round-trips. But you need to be smart about it. Use web workers for heavy calculations to avoid blocking the UI thread, implement progressive calculation for large datasets (calculate top opportunities first, then fill in the rest), and always show loading indicators.
Performance impact depends heavily on your data volume. If you’re dealing with territories that have 500+ open opportunities, client-side calculations will struggle. We found that anything over 200 opportunities starts showing noticeable lag in the browser, especially on mobile devices. Server-side processing with caching is more predictable. However, for individual opportunity updates, client-side gives better UX - reps see immediate impact of changing a close date or amount.
From a server-side perspective, ABAP batch processing gives you better control over data consistency and allows for complex calculations that access multiple data sources efficiently. You can optimize database queries, use parallel processing, and handle large datasets without worrying about browser memory limits. The staleness issue can be partially addressed by running incremental updates more frequently - say every 4 hours instead of nightly - rather than moving everything client-side.