Nobody objects in the first week. The frontend team does not want to wait, starts with a few hand-written sample bodies, and the screens come together quickly.
Week two looks fine too. So does week three. Mock data is the quietest technical debt in the project: it grows a little every day and charges its interest all at once.
Payment falls due in the final week of the integration. Real field names, padding characters, fields that arrive empty and error bodies all surface then. The screens are finished and the tests are written; every change to the contract now means rework.
Real field metadata inside an iDataView definition
The real field information was on the table on day one. The moment you pick a source object, an iDataView definition takes the field name, reference field, data type, length, decimals and conversion exit from SAP metadata into the report design. Language-dependent field texts sit in the same definition.
That list differs from mock data in two ways: the names and types are not invented, they come from the source itself, and so do the length and mandatory flags. Run the definition against the real source and you get a controlled sample result in which empty values really do arrive empty.
Once the definition is published as an outbound service, the same object returns JSON or XML. The frontend team works with real field names from day one, and both teams look at the same output while they talk.
Here is a comparison you can run today: put the mock body the frontend team is using next to the service response for the same object. However many places the field names, lengths and empty-value behaviour diverge is how many items you will be discussing in the final week.
Five lines to write into the frontend contract
- Field name, type, length and whether it is mandatory.
- How an empty value arrives: is the field missing, an empty string, or a zero?
- Fixed parameters versus the ones changeable at call time.
- Record limits and the pagination expectation.
- Error bodies: authorization failure, source failure and timeout, separately.
Account for the shared envelope around in-application responses as well: the ApiResponse wrapper that carries error and success metadata is not the same thing as the data. If the frontend team does not know which one to read, the first error response produces an empty screen.
Test output does not stand in for production data
One point should not be overstated. Test output does not represent every exception in production data; special characters, long texts and unexpected unit combinations usually appear only in real data. Versioning the contract and reading it once more after the first real data run is the cheapest insurance available.
We are not promising a duration either. Phrases such as “an API in fifteen minutes” are not a measured result. The claim is plainer: the field list in the frontend team’s hands comes from the metadata of the source itself.
Before the frontend sprint starts, book half an hour: pull the field list out of one iDataView definition, write the error bodies next to it, and record that as version one of the contract. If you would like to set that table up together, say the word.