Fiori is SAPs current-generation platform with a rich web-based user interface that is suitable for both desktop and mobile users. There are thousands of pre-built apps, and custom Fiori applications can be built using SAP’s UI5 framework. Fiori was first announced in mid-2013, but many SAP customers are deploying it for the first time in 2020. Load and performance testing helps SAP projects ensure that their new system can support their business-critical processes without being frustratingly slow, or grinding to a halt under heavy load.
Slow by default
While the Fiori user interface is more user-friendly for infrequent users, heavy users in the back-office are generally used to the speed of the desktop SAP GUI application. Fiori must be fully optimized for performance to be acceptable for these staff.
The default platform settings for any SAP system are suitable for a small dev/test environment, rather than a full-sized production environment. It’s nobody’s fault that the defaults are not performant, they will be updated as load and performance problems are found and notes are applied. There may be more pain depending on the amount of customization.
One component that requires optimization on every project is the Fiori Launchpad (FLP). Different tiles will be displayed to a user depending on their role and profile. Intelligently changing the tile settings can have a dramatic improvement on login times, and can reduce load on the back-end servers.
Client-side JavaScript performance plays a big part in end-user response times and, while there are many settings that will reduce server and network time, client-side time can be reduced by steering users who still have Internet Explorer installed on their desktops to using Chrome, which has a much faster JavaScript engine than IE11.
Load testing tools
A big part of load testing is the development of automation scripts to drive load against the application. The rich UI5 user interfaces that are supported by Fiori (and the old Web Dynpro apps that can still be launched from FLP tiles) are complex and almost impossible to script with protocol-level tools like JMeter. Client-side JavaScript, asynchronous calls and complex OData payloads mean that the only practical way to create scripts is with a tool built on a real browser like LoadRunner TruClient.
It is unlikely that all Fiori users will be at a single office location. If all load testing is done over the local network, the measured response times will not be accurate for users in remote offices, or workers on mobile data networks. The initial login to Fiori downloads more than 5MB of JavaScript, which has a big impact on response times for mobile users on slower connections. It is important to use tooling that can emulate network conditions during testing.
Business as usual
Despite the additional scripting effort in load testing Fiori, it has much the same challenges as load testing on any SAP project.
- There will probably be integrations with other systems both SAP (SuccessFactors, Concur, Hybris, Ariba, etc.) and non-SAP (via EDI, etc.). Traffic from these systems must be accounted for in the load test.
- There will probably be a batch component. Data must be generated to measure the running time of the jobs. If an “overnight” operation mode has been set up, these settings must be verified too.
- There may be a cloud-based deployment…and it may be the organization’s first cloud project.
- It will be necessary to organizing bulk test data for volume testing (users, roles, and profiles, master data, etc.). It will be necessary to manage “use once” data like purchase orders that must be approved.
- It will be necessary to set up monitoring for key infrastructure components (NetWeaver, HANA, etc.)
- It will be necessary to work with different teams, from Business Analysts, to Basis, to the SAP MaxAttention team.