When your system has no standard SAP APIs
Most guides assume the standard API_ services are there. On an on-premise system they often are not. A tenant can carry a couple of hundred registered OData services and have none of SAP's released APIs among them, because everything was built to order over the years — an estate of custom Z developments, each written for one screen or one report.
You will see this immediately when you connect: the account reports something like "Connected — 182 services registered, none of them standard API_"*. Nothing is broken. It just means the typed tools (s4_list_products, s4_list_business_partners, and the rest) have nothing to call, because they target the standard services by name.
There are three ways forward. They are not alternatives so much as a ladder — most systems end up using two of them.
The three routes
| What it gives you | What it costs | Good for | |
|---|---|---|---|
| Activate standard services | The typed tools start working; clean, supported, SAP's own interface | A registration job for your Basis team, one service at a time | Any system that can adopt them |
| Read-only SQL | Every table, immediately, no development | Developer-grade authorization, which some security teams will refuse | Exploration, one-off analysis, proving value fast |
| Install a small view set | A stable interface that looks the same on every system | One transport through your change process | The durable answer, once you know what you need |
Route one — activate the standard services
Still the best answer where it is possible. The services ship with the system; registering them is routine work, and afterwards Daslab's typed tools work exactly as they do against a cloud tenant. The on-prem guide covers what to send your Basis team.
Worth checking before assuming otherwise: services can exist but be unregistered rather than absent. Activating five of them is often an afternoon.
Route two — read-only SQL
Daslab can read the database directly through SAP's own development tooling — the same data-preview console the ABAP Development Tools use. This reaches every table, including the large majority that no OData service exposes, and it needs no development at all.
Turn it on with the Enable read-only SQL capability on the account. It is off by default, deliberately.
Be clear-eyed about what it asks for. The endpoint sits on the ADT surface, so the SAP user needs developer-tool authorization — meaningfully more than "may read these OData services." Some security teams grant it for a pilot without a second thought; others will not grant it at all. Either answer is reasonable, and it is better to ask early than to design around access you turn out not to have.
Two practical limits once it is on. Every statement is capped at 255 characters — tight, but a two-table join with a filter and a sort fits if you keep aliases short and sort the rows after they come back. And it is ABAP Open SQL, not standard SQL: aggregates need inner spaces (SUM( menge )), sorting is ORDER BY x DESCENDING, and joined fields use ~.
Always call s4_describe_table before querying a table you do not know. Guessed column names come back as an opaque 400, and the describe gives you every field with its key flag, type and human label.
Route three — install a small view set
The durable answer, and the one that makes every system look the same.
Rather than adapting to whatever each system happens to expose, you install the interface: a handful of CDS views, annotated to publish themselves as OData services. After that the tables underneath stop mattering. The view names, the fields and the services are identical everywhere, and day-to-day access needs nothing more than an ordinary read-only user.
That last point is what makes this worth the effort. Developer authorization is needed once, by your own staff, at install — not continuously by Daslab.
What it involves
Creating a repository object needs S_DEVELOP authorization, a proper package, and a transport request. In Daslab that capability is the Enable ABAP write/execute flag on the account, which is off unless you turn it on.
Build and test in your development system, then move the transport through your normal change process into production. This is ordinary ABAP lifecycle work and your Basis team will recognise every step of it.
Do not create the objects directly in production, even if the client is technically open for changes. Some production clients are left unlocked by accident; that is not permission. Objects created outside a transport are invisible to your change history, cannot be reviewed, and cannot be cleanly removed. If a vendor offers to skip your landscape, that is a reason to say no.
When to do it
At onboarding, once, as a single reviewed transport — not per feature and not ad hoc. The right moment is after a period on route two, when you have seen which questions actually get asked and the view set can be small and deliberate rather than speculative.
What to send your Basis team
For read-only SQL: the ICF node /sap/bc/adt needs to be active, and the technical user needs authorization for the ADT data-preview service. Read-only; no write, no execute, no transport access.
For an installed view set: a development package to build in, a transport request, and S_DEVELOP on the development system only. Daslab authors and tests the views there; your team reviews the transport and moves it. Production needs no developer authorization at any point.
A note on what is reachable
Some things genuinely are not in the system, and it saves time to find out early rather than hunt. Quality Management may never have been implemented. A bill of materials view may carry scrap quantities but no consumption quantities. Attachments are usually filed against purchase orders rather than accounting documents, and their contents live in a compressed cluster table that no SQL can read — reaching those needs either a service the customer already built or one that gets installed.
Ask the system before assuming: a single COUNT(*) on the leading table of a module tells you in under a second whether anyone has ever used it.