THE BACKGROUND

Our most recent SAP engagement covered both Materials Management and Sales & Distribution modules, with the prime requirement being within the warehouse to monitor the performance of product picking (RF gun) through to dispatch and from day-to-day levels to the peaks anticipated in the ramp up to Christmas and Black Friday.

Such were the volumes that this engagement has resulted in the purchase of a 10,000 VU day LoadRunner license.

THE CHALLENGES

As with any performance test, the challenges were multiple, with some of the more notable highlights are detailed below:

•  To send goods out you must have received them in. The initial plan to create and restore a database snapshot of a fully stocked warehouse was not possible due to access to both systems and client personnel. The only option was therefore to script the purchase (inbound) transactions required to keep the warehouse stock levels high enough to perform the performance test (outbound) transactions.  

•  Customer time was at a premium, so our customer walk through of the business processes was brief and only covered a single path.

•  The bar code reader (/SCWM/RFUI) is prone to lock devices if all of the transactions within a task are not completed.

•  Great care had to be taken to ensure that the virtual users did not attempt to process the same individual item during either the inbound or outbound transactions.

•  The performance testers did not have exclusive use of the test system, leading to potentially both missing and unexpected data in the test run and alternative process flows.

THE SOLUTION

For the performance test, eight performance test scripts were created, with four to bring stock into the warehouse and four to ship the stock back out.

Inbound Process

•  Create purchase order.

•  Create inbound delivery.

•  Goods receipting.

•  Goods put away.

Outbound Process

•  Create sales order (SAP EDI).

•  Picking wave release.

•  Picking.

•  Packing & close carton.

The inbound process scripts were run as part of the overall test scenario effectively harvesting data and creating warehouse stock for subsequent executions. Due to the volume of data and data files (effectively one per virtual user), Excel macros were developed to sanitise and evenly distribute data between virtual users.

The scripting for each business process had to be extended to cover the multiple path options discovered within each process, and scripting for the bar code reader (/SCWM/RFUI) was enhanced to detect a locked device and intelligently attempt to release it by following one of many pre-determined processes. Any devices that could not be released were removed from the current execution.

Custom data handling was created to ensure that only one single virtual user could use one item data at any one time and that the data was not re-used during the current and any subsequent executions.  Scripting for picking and packing was developed to seamlessly manage the process paths covered within the scope of the performance test. The scripts switched their path according to the data presented on the SAP GUI screen. The scripts were also developed to process or reject data created by other users on the test system.

THE OUTCOME

Executing test scripts for both inbound and outbound processes created a realistic performance test scenario. Test scenarios were created and executed to achieve a peak load of 250 users for 1 & 2 hours. Initial executions highlighted a peak in response times for the stock picking process when the system was processing a stock wave release.

To rectify, the customer tweaked their test systems load balancing algorithm and therefore the peak was not detected in subsequent executions.  

These algorithm changes were subsequently made implemented in production. Budget permitting, the customer is looking to extend the performance test to cover additional outbound warehouse processes.

THIS EXAMPLE DEMONSTRATES

Our ability to understand the customer’s implementation and customisation of the SAP modules and processes. Creating a series of test scripts to execute against SAP GUI is a relatively simple exercise, enabling the scripts to be resilient and intelligent to manage the alternate flows possible within a business process requires both advanced scripting capability and understanding of the SAP module and the customers implementation.

Understanding how, what and when data is created and consumed within and between SAP modules is critical to the execution of a meaningful performance test scenario.

Over the years, Fimatix have engaged in many SAP testing projects (functional & performance), employing both SAP eCATT and proprietary test tools, from what was Compuware’s TestPartner (as an alternative to and integrating with eCATT) to most recently Micro Focus’ LoadRunner SAP GUI. Over the course, Fimatix have accrued excellent working knowledge of the core modules, from Financials through to Sales, HR and Product Planning.