Lesson 3 of 5
Data pools and replenishment
19 min
Listen to this lesson
Some data cannot sensibly be created inside each test. Stock is the classic case: a goods issue needs unrestricted stock, and creating it inline means another posting, another document and, in some designs, a movement type you would rather not use. Open items are another: a payment test needs an open customer invoice, which itself needs an order, a delivery and billing. For data like this, teams use data pools: sets of ready-to-use records that tests take from, and replenishment jobs that keep the sets full.
What belongs in a pool
- Stock in plant 1710 at IM level, outside EWM: CMC-ALT-100 in storage location 171B and CMC-RTR-200 in 171S, for goods issue, transfer and inventory tests.
- Open customer items for Great Lakes Fleet Services-style test customers, for incoming payment, dunning and clearing tests.
- Open supplier items for Lakeside Components-style test suppliers, for payment run tests that Ana, the AP clerk, would recognize.
- Documents in a given state, such as released purchase orders awaiting goods receipt or deliveries ready for goods issue.
- Approved records that need a workflow step, such as purchase requisitions over $10,000 that have already been released.
The common thread is data that is consumed by the test and is expensive or slow to create at the moment it is needed.
How a pool works
- DefineFor each pool: object, criteria (plant, status, amount band), target size and minimum level.
- FillA replenishment job creates records through APIs until the pool reaches its target.
- ReserveA test claims one record and marks it as taken so no parallel run can use it.
- ConsumeThe test runs; the record changes state or is used up.
- Release or retireUnused reservations are released; consumed records leave the pool.
- MonitorPool levels are checked before each run; a low pool blocks the run with a clear message.
The reservation step is the one teams forget. Without it, two parallel runs both query "an open item over $5,000 for a test customer", both find the same one, and one fails because the other cleared it first. A reservation can be as simple as a table that maps record keys to run ids, or a field on the record itself, such as a text or reference field that the test writes before it acts. Whatever you choose, make it atomic, so two runs cannot claim the same record at the same instant.
Replenishment design choices
| Choice | Option A | Option B |
|---|---|---|
| When | Before every run (simple, predictable) | On a schedule or when the level drops (fewer postings) |
| How | Run the real upstream process, e.g. order to billing for open items | Use a direct API or BAPI posting for the end state |
| Where | Same client as the tests | Separate data client copied in (rare, heavy) |
| Ownership | Automation team owns pools | Process teams own their pools with shared tooling |
Running the real upstream process to create open items is slower but gives realistic documents with the right links: the open item has a billing document, a delivery and an order behind it. Direct postings are faster but can produce data that real processes never would, such as an open item with no sales history. As a rule, use direct postings for stock and inventory, and real process chains for documents that later tests will inspect closely.
Sizing and monitoring pools
Size a pool from consumption, not guesswork. Count how many records each test takes per run, multiply by the runs per day including reruns, and add a buffer for growth. Then monitor: a pool-level report at the start of each run, and a trend over time. A pool that drains faster than expected is an early sign that new tests were added without updating the data plan.
- 18:00Pool checkRead levels for stock, open items and released POs; compare to minimums.
- 18:15ReplenishTop up pools that are below target; log every created document.
- 19:00Nightly suiteTests reserve, consume and release records.
- 05:00HousekeepingRelease stale reservations; retire consumed records; report pool trends.
- 08:00ReviewPriya reviews results and pool health together.
What would you do?
Two regression runs in CMQ, one for the order-to-cash team and one for the finance team, both use the open customer item pool. Several payment tests fail each night because the item they chose was already cleared. What is the best fix?
- Pools hold consumable data such as stock, open items and documents in a given state.
- A pool has criteria, a target size, a minimum level, replenishment and monitoring.
- Atomic reservation stops parallel runs from consuming the same record.
- Use real process chains for documents later inspected closely; direct postings for stock.
- Stop the run with a clear message when a pool is below minimum.
Check your understanding · not graded
Lesson check
1. Which data is the best candidate for a replenished pool rather than per-test creation?
2. What problem does an atomic reservation solve?
3. Why might a team create open items by running the real order-to-billing chain instead of posting them directly?
4. The stock replenishment job cannot post because the posting period is closed. What should the nightly suite do?