Daslab Gateway
Some systems will never be reachable from the internet, and the ones worth asking about are usually the ones with the strictest answer. Daslab Gateway is one binary you run on a machine inside that network. It holds a read-only copy of the system, answers questions against the copy, and reaches Daslab over a single outbound connection. You open no inbound port.
The gateway page is the shorter version. This one is for whoever has to run it.
What it reads, and how
For an SAP system the node reads through the application layer, as a named read-only account you create. No database user, no database port. That matters for licensing as much as for security, because direct database access is the part your agreement usually restricts.
Every statement it sends is a SELECT. There is no code path in the binary that writes to the source, and the account it uses has no write authorisation either, so the guarantee holds on both sides.
What lands on the node
Two things, in separate shapes.
Rows land as immutable Parquet files, one per batch, never rewritten. Each row carries the primary key it was fetched under and the time it was observed, so re-reading a page you already hold updates nothing and adds nothing. That is what makes a sync safe to interrupt and safe to repeat.
Documents land as files next to the business object they belong to. The content of an attachment is not reachable from SQL in most systems, so it comes through the attachment service the system publishes, and the catalogue that records it is an ordinary table you can query alongside the rest.
A query from a scene reads the copy. It does not reach your source system.
What it costs the system it reads
Two ceilings, both set by you and enforced in the binary rather than by convention:
| Setting | Default | What it caps |
|---|---|---|
DOC_RATE | 4 | requests per second, shared across every worker |
DOC_MAX | 500 | objects fetched per run |
The second one matters more than it looks. A node that can work through an unbounded backlog unattended is a node that can become a load event on a production system at four in the morning. With a per-run cap it makes steady progress instead, and you can raise it once you know what the source can take.
What is recorded
Every read against the source: the statement, the account that sent it, the row count, and how long it took. Every answer back to a scene: what was asked and what was returned. One trail, both directions, on the node.
That is the log whoever administers the source system asks for first, and it is the reason a read-only claim is checkable rather than something you take on trust.
Where it appears
Once connected, the node is an asset in your workspace. Any scene you give access to can query it, and the questions and answers land in that scene's history like any other work.
Access is per scene. A node in one scene is not reachable from another unless you put it there.
Updated 2026-08-15