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.

Performance Lab was hired to test an integrated set of SAP systems, particularly with respect to system performance. These are the integrated systems:

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.

Have a project in mind?

There is no better place for a QA solution than Performance Lab.
Drop us a line to find out what our team can do for you.

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 HP 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

Correctly achieving the objectives required us to carefully study the system first. The customer’s consultants did not always have answers to all of our questions. We were able to accomplish some of the objectives only due to our vast experience in load testing.

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.

Download
brochures

More information about QA solutions we provide is available in our brochures

PL CSV SOLUTION

PL CSV SOLUTION

TEST AUTOMATION SERVICES

TEST AUTOMATION SERVICES

CASE STUDY: TOP 10 BANK AT

CASE STUDY: TOP 10 BANK AT

AGILE PERFORMANCE TESTING

AGILE PERFORMANCE TESTING

IVR LOAD TESTING SERVICES

IVR LOAD TESTING SERVICES

CASE STUDY TOP 10 BANK LT

CASE STUDY TOP 10 BANK LT

CASE STUDY RETAIL

CASE STUDY RETAIL

CASE STUDY GOVERNMENT

CASE STUDY GOVERNMENT

QA OUTSOURCING WHITEPAPER

QA OUTSOURCING WHITEPAPER

Latest posts from us

Top 5 best online testing tools preview
Top 13 Best Online Load Testing Tools
Why is performance testing before Black Friday a must
Why is performance testing before Black Friday a must?
Project management in performance and load testing projects
Project management in performance and load testing projects
Test environment in the project lifecycle
Testing environment in the project lifecycle
10 Steps to Mobile App Performance Testing preview
10 Steps to Mobile App Performance Testing​