Lesson 4 of 5
Contracts and toggles
10 min
Listen to this lesson
Two architecture techniques let teams change and test parts of a solution independently. Contracts pin down what an interface promises, so each side can be tested against the promise instead of against the other side's latest build. Toggles separate deploying code from activating behavior, so changes can reach systems early and be switched on under control.
Interface contracts
An interface contract states the operations, the data structures, the meaning of fields, the error behavior and the versioning rules. In SAP landscapes, contracts come in familiar forms: an OData service's metadata document, an IDoc type, a SOAP service definition, an event's schema. SAP's own extensibility guidance relies on the same idea: clean core extensions use released APIs that come with stability commitments, so that extensions survive upgrades and upgrades survive extensions. For your own interfaces, give the same promise: a published contract, a version, and a rule that breaking changes need a new version.
| Contract element | Example for the portal order interface | What it enables in testing |
|---|---|---|
| Structure and types | Order header, items, portal reference, requested date | Schema checks on every message in CI and CMQ |
| Field meaning | Requested date is the customer's delivery wish, not a confirmed date | Correct expected results; fewer false defects |
| Errors | Unknown material returns a rejection with reason code | Negative tests on both sides |
| Versioning | New optional fields allowed; removing fields requires version 2 | Old consumer tests keep passing during change |
What a useful interface contract contains.
Testing against contracts
Martin Fowler's practical test pyramid describes consumer-driven contract tests: the consuming team writes its expectations of an interface as automated tests, and the providing team runs them in its pipeline, so breaking changes are caught before they reach integration. The pattern works with SAP too. The portal team publishes the messages it sends and the responses it expects; Kenji's team runs those checks against the S/4HANA side in CMD whenever the order interface changes. Neither side waits for an end-to-end environment to learn it broke the other.
- Consumer states expectationsPortal team: "an order with these fields returns a confirmation with an order number"
- Contract storedVersioned with the interface specification
- Provider verifiesS/4HANA team runs the contract checks on every change to the interface
- Consumer verifiesPortal team tests against a stub built from the same contract
- Integration testFewer surprises: end-to-end tests confirm wiring, not basic compatibility
Toggles
A toggle lets code be deployed with a behavior off and switched on later. Fowler's taxonomy distinguishes release toggles (hide unfinished work; short-lived), experiment toggles, ops toggles (degrade or disable a feature under load; some long-lived kill switches) and permissioning toggles (features for specific users). In SAP, activation is often already configuration-driven: customizing switches, condition records valid from a date, and business functions in the Switch Framework. Many business functions cannot be reversed once activated, so check reversibility for each one before treating it as a toggle.
- Must the new behavior reach production before the business is ready to use it?Yes → plan a toggle · No → deploy normally
- Can existing configuration control it (customizing switch, validity date, role assignment)?Yes → use it and document it as the toggle · No → build a simple, owned toggle in custom code
- Is the toggle reversible and tested in both states?Yes → proceed · No → treat activation as a one-way change with its own test and sign-off
- Does it have an owner and a removal date?Yes → proceed · No → add both before deploying
Testing toggles
Fowler's advice is direct: test both the on and off states, and do not try to test every combination of every toggle. Prioritize the configuration you expect in production and the fallback with new toggles off. Keep toggles few and short-lived: each one is inventory with a carrying cost, and old toggles multiply the paths that regression must cover. Add a removal task when you create a release toggle.
What would you do?
A team proposes keeping a toggle permanently "just in case" for a new credit check, and wants to test only the on state. What should the architect say?
- Contracts state structure, meaning, errors and versioning; test each side against them.
- Consumer-driven contract tests catch breaking changes before integration testing.
- Toggles separate deployment from activation; reuse SAP configuration where it fits and check reversibility.
- Test both toggle states, keep toggles few, give each an owner and a removal date.
Check your understanding · not graded
Lesson check
1. Feature toggles support testing by:
2. In consumer-driven contract testing, who runs the consumer's expectations?
3. Which toggle states does Fowler recommend testing at minimum?
4. What must you check before treating an SAP business function as a toggle?