Workload modeling

A load test is only as good as its workload model: the mix of processes, users, rates and data that the test injects. Too light and the test passes a system that will fail at month-end. Too heavy, or the wrong mix, and you tune for a day that never happens. The model should come from production evidence, not from guesses in a workshop.

Start from production

Contoso's current production system, EP1, already records what users do. The workload monitor (transaction ST03) shows workload by task type, such as dialog, background, RFC, update and HTTP, and by transaction or report. Sam's Basis team can extract, for a normal week and for the last month-end, the number of dialog steps per hour for each business transaction, the peak hours and the background jobs that run alongside. Business volumes (orders, deliveries, invoices, journal entries per day) come from the process owners and their reports.

CollectProduction workload statistics and business volumes, normal week and peak
SelectThe 10–20 processes that make most of the load or carry most of the risk
QuantifyUsers, transactions per hour, think time, data per transaction
GrowApply growth and change: acquisitions, new channels, S/4HANA design changes
ReviewProcess owners and Basis confirm the model before scripting
Script and calibrateBuild scripts, run a small test, check the injected rate matches the model

Building a workload model from production evidence.

The Sign-Off Table · thesignofftable.com/academy/sap-tst-306

What goes in the model

Process	Peak hour rate	Concurrent users	Data notes
Create sales order (Great Lakes Fleet Services and others)	1,800 orders	300	3–8 items, CMC-ALT-100 and spare parts
Post goods issue for deliveries, shipping point 1710	900 deliveries	60	With serial numbers for alternators
Post supplier invoices (Ana's team)	400 invoices	25	Mix of PO-based and non-PO; some against POs over the $25,000 approval threshold
Display open items and AR overview	1,200 queries	50	Company code 1710, full open item volume
Background: billing, MRP, output	Per job plan	—	Running in parallel with dialog load

An extract of Contoso's month-end workload model. Figures are illustrative.

A workload model is more than user counts: each process line carries rates, think time and varied data, and background and interface load runs at the same time.

The Sign-Off Table · thesignofftable.com/academy/sap-tst-306

Include think time (the pause a real user takes between steps) or you will inject far more load per user than reality. Include background and interface load that runs at the same time; month-end at Contoso is not just users, it is billing jobs, bank statements and EDI orders arriving. And include data variety: a test that orders the same material for the same customer a thousand times hits caches and locks in ways production never does.

Conversion-specific changes

A system conversion changes the workload even when users do the same work. Some ECC transactions are replaced by SAP Fiori apps, which create HTTP and OData load instead of classic dialog steps. Finance moves to the universal journal. Custom code adapted for S/4HANA may access data differently. So the model starts from ECC production volumes but must be reviewed against the S/4HANA design: which apps Contoso's users will actually use, and which custom reports and interfaces were rewritten.

The conversion changes the shape of the load even when users do the same work, so the ECC-based model must be reviewed against the S/4HANA design.

The Sign-Off Table · thesignofftable.com/academy/sap-tst-306

Load test question	Normal-day model	Peak model
Purpose	Prove everyday responsiveness	Prove month-end and quarter-end survive
Users and rates	Typical working hour	Busiest hour of the last business day
Background load	Normal daytime jobs	Close, billing and interface peaks
Duration	One to two hours steady state	Peak hour plus ramp up and down; then an endurance run

Run both models. Many programs test only the normal day.

The Sign-Off Table · thesignofftable.com/academy/sap-tst-306

What would you do?

The integrator proposes a load test of 300 users each creating sales orders as fast as possible with one customer and one material. What is the main problem?

Hands-on lab · ACCELQ

Give a scripted business flow real data variety

A workload model goes wrong when every virtual user orders the same thing. ACCELQ is not the load generator in this lab. You use it to build one business flow and the varied data behind it, with a Data List feeding Test Cases: the same inputs a workload model needs.

Practice on SAPUI5 Shopping Cart demo app (public, no login)

If you haven't set up ACCELQ yet, do the setup lab first.
Create an Action and record, in Fluid mode, a search for a product, opening it and adding it to the cart. Switch to Intent mode and right-click the cart to add a verification that the item is there.
In the Action's Parameters tab, add an input parameter for the search text. Click the hard-coded search value in its statement, click the parameterization icon and choose Action Parameter.
Browse the app and write down six to eight search terms that land in different categories. Include one that returns several products. Don't repeat a term.
In Resources > Data Lists, click + and enter your terms. Then, on the Action's Parameters tab, point the search parameter's acceptable values to this Data List.
Create a Scenario that starts with Initiate Browser Session and then your Action. Open its Test Cases tab and generate Test Cases from the Data List, or type one row per term if you don't see a generate option. (The label may differ slightly in your version.)
Click Run. The Scenario runs once per Test Case, so keep the list short on this public demo.
In the Test Report, check that each Test Case used a different term and note any row that behaved differently from the rest. Decide whether it belongs in the model or in a separate Scenario.

Done when Every Test Case ran with its own data, and the report shows the variety. Keep the Data List and the report: in a real program they are the data notes column of the workload model.

Learn more in ACCELQ’s docs: Difference between Data Type and Data List · What is a Data List · Concept of Parameterization and Test Cases

Start the free ACCELQ trial Matt Angerer, who runs The Sign-Off Table, works at ACCELQ. Disclosure

Key points

Build the workload model from production workload statistics and business volumes, for a normal day and for peak.
Model processes, rates, users, think time, background and interface load, and data variety.
Adjust for the S/4HANA design: new apps, the universal journal and adapted custom code.
Run on a production-comparable environment and record differences.

Start from production

What goes in the model

Conversion-specific changes

Lesson check