Load testing SAP systems for Retail Company
Our customer is one of the largest retail chains selling electronics and household appliances.
The company implemented a full-fledged omnichannel approach to sales, which means a unified product assortment, prices, and services, whether buying in stores or online. The stores share format and conceptual design. In addition to an effective retail format and a store concept that is customer-oriented, the company also offers high-quality customer service.
01
SAP PI/PO — Integration bus;
02
SAP ERP — Enterprise resource planning management system (procurement, sales, distribution, accounting, tax and management accounting and reporting, balances, basic data, etc.);
03
SAP POS DM — Store data management system;
04
SAP TM — A system for planning and operational management of transportation along
pre-defined routes (mainline transportation), and inside the city, where the route is not clearly defined and only the start, the end, and intermediate points are known.
Want to learn more about our
performance testing services?
Find out what’s included and how to start working with us
Our team faced the following tasks:
- determine whether the systems being tested meet the performance requirements before and after the transformation;
- determine whether performance worsened after the transformation;
- identify processes that need to be optimized, if any;
- determine whether performance worsened as a result of optimization.
Our solution
To achieve the objectives associated with the project, we conducted tests in which we emulated traffic generated by users and external systems, and background jobs were launched.
To emulate user load on the SAP ERP system, we used the SAP GUI protocol. The system included tasks that corresponded closely to the scheduling in the production environment.
The main load on the SAP PI system comes from data streams from other systems. They were emulated by sending XML files via the SOAP protocol and uploading files to an FTP server.
The load was emulated according to the test scenarios with the specified intensity. The composition of the tested operations was established based on the customer’s expert opinion. Operations were chosen according to the following criteria:
- being business-critical, performed daily, and affecting sales or logistics operations in the system;
- loading the system significantly;
- transformation is expected to result in increased load from the operation.
Information about the target load and SLAs was obtained during interviews with functional consultants.
After each test, we analyzed the results. The load was applied using LoadRunner and Apache JMeter.
The intensity of scenario execution by each virtual user depends on the scenario, system response times, and the amount of delay between two consecutive iterations. In the process of testing, the total intensity of scenario execution by all virtual users (the simulated load on the information system) was changed by adjusting the number of virtual users performing the scenarios and changing the amount of delay between successive iterations.
The problems the team encountered along the way
01
02
The test bench was significantly less powerful than the production environment. Working together, we leveled it out to half-capacity, but we had to cut the load profile in half.
03
The load testing environment was used by a large number of different teams. This led to changes in configurations and distorted test results. After discussing with all the teams, we introduced a testing schedule.
Results
We identified a problem with budget control; that is, we found a database locking problem.
The customer optimized the program.
We identified an overflow problem involving ActiveMQ.
With our help, they debugged and fine-tuned the SAP PI system.
We found a critical error in a TSA patch that nearly went into production.
Based on the test results, a table of product comparison materials and receipt indices was added; without this optimization, the tests caused SAP POS DM to stop working.
