Lesson 5 of 5
APIs as data factories
18 min
Listen to this lesson
Ask any SAP automation team what breaks their UI tests most often and the answer is rarely locators. It is data: the customer was blocked by someone else's test, the stock was consumed, the order the test expected was already delivered, the posting period closed. The most effective cure is to stop sharing data and let each test create what it needs, quickly, through APIs. This lesson shows how to build those data factories and how to clean up afterwards in a system where most documents cannot simply be deleted.
Create fresh, minimal, unique
A data factory is a small, reusable function that creates one business object through a service and returns its key: create a sales order for Great Lakes Fleet Services, create a purchase order to Lakeside Components, post a goods receipt for rotors CMC-RTR-200 into storage location 171S. A UI test calls the factory in its setup, then works on that object only. Three rules make factories reliable.
- Fresh: create data for each run instead of hunting for "a suitable order" in CMQ. Reused data drifts as other tests and people change it.
- Minimal: create only what the test needs, with defaults from master data, so the factory keeps working when unrelated fields change.
- Unique and traceable: stamp every object with a run reference, for example a customer purchase order number like AUTO-0412-017, so tests can find their own data with a filter and cleanup can find it later.
- Arrange by APIFactory creates the sales order through the released OData API; returns the order number.
- Act in the UIThe UI test opens that order by intent and performs the step under test, such as creating the delivery.
- AssertCheck the UI result, then read the documents back through the API.
- Clean upReject open items or reverse postings through APIs; record what was left.
What to create through which interface
| Object | Preferred factory channel | Notes |
|---|---|---|
| Sales orders, purchase orders | Released OData APIs (for example Sales Order (A2X)) | Fast; returns keys; same business logic as the apps |
| Goods movements, billing | Released APIs where available; otherwise a recorded back-end step | Check the API exists and is released for your release |
| Master data (customers, materials) | Prefer a stable, pre-loaded test data set; create via API only when a test needs a special case | Master data creation often triggers approvals, replication and numbering |
| Inbound documents from partners | The real channel (IDoc, SOAP) | When the channel is under test, it is not a factory |
Use released APIs from the SAP Business Accelerator Hub wherever possible. They are documented, versioned and supported, so factories built on them survive upgrades. In SAP S/4HANA Private Edition, a released OData API must be activated in the system before you can call it; plan that with Sam's Basis team for every environment the tests run in. Avoid factories that write directly to database tables: they bypass business logic and create objects that the real application would never produce.
Cleaning up in SAP
In SAP, "delete" is the exception. Posted documents (deliveries, goods movements, billing documents, journal entries) are never deleted; they are reversed or canceled. Open documents can often be rejected, blocked or completed. So cleanup means returning the system to a state where your test data cannot disturb the next test, not making it vanish.
- Is the document still open and unposted?Yes → reject items or set a completion or deletion indicator via API · No → next question
- Was it posted (stock, accounting)?Yes → reverse or cancel it through the business transaction · No → next question
- Is it master data the test created?Yes → block it for posting and mark it with the run reference · No → nothing to clean
- Did cleanup fail?Yes → log the keys for the nightly sweep; never fail the business test for it · No → done
Where API tests replace UI tests
Factories are also a step toward a better regression shape. Once the setup of a UI test runs through APIs, ask of each remaining UI step whether the UI adds information. Rules, calculations and data variants usually move entirely to API tests. User journeys, role checks and screens that carry real logic stay in the UI. The result is fewer UI tests that are shorter and more stable, surrounded by many fast service tests.
What would you do?
Contoso's delivery-creation UI test fails three nights a week because the "test order" it uses was already delivered by someone else in CMQ. What is the best fix?
- Data collisions, not locators, are the top cause of failing SAP UI tests.
- Data factories create fresh, minimal, uniquely referenced objects through released APIs.
- Arrange by API, act in the UI only for the step under test, assert on documents.
- Cleanup in SAP means reject, block, reverse or cancel, not delete; isolate test data to need less cleanup.
- Move rules and data variants to API tests; keep UI tests for journeys, roles and UI logic.
Check your understanding · not graded
Lesson check
1. What is the main purpose of an API-based data factory in UI test automation?
2. How is a posted goods movement typically cleaned up after a test?
3. Why should factories use released APIs rather than writing to database tables?
4. What makes test data traceable for both the test and later cleanup?