Skip to main content

SAP module integration

A standard SAP HANA schema dumps everything — Sales, Finance, HR, Logistics, Z* customisations — into a single namespace, often with 6,000+ tables. Treating that as a flat schema breaks usability: the LLM can't fit the schema in context, RBAC can't be granted per business area, and analysts drown in irrelevant table names.

QRY's SAP module integration adds a module level between schema and table, mapping to SAP's own functional decomposition (MM, SD, FI, HR, Z* for custom).

The full hierarchy becomes: host:port → SID → schema → module → table.

Why this matters​

LLM context budget​

Without modules, every conversation against a HANA datasource has to choose: either pass the full 6,000-table schema (busts the context window) or pass a heavily truncated one (LLM picks the wrong tables). Modules let QRY pass only the relevant module's tables.

RBAC granularity​

Without modules, RBAC at "schema level" is useless because everything is in one schema. With modules, you can grant the Sales team access to the SD module without leaking HR.

Custom-table focus​

LLMs already know SAP's standard tables (e.g. VBAK for sales orders). They don't know your tenant's Z* customisations. Modules let you scope the LLM context to just the customs:

"For the Z module, here's the full schema; for SD, just rely on what the model already knows."

This dramatically reduces token usage without losing accuracy on custom data.

Setting up modules​

In the SAP HANA datasource's settings, open the Modules tab. Add a module per business area:

  • Module code — SD, MM, FI, Z, etc. Use SAP's standard module codes for clarity.
  • Tables — the table names that belong to this module. Either:
    • Manual list — paste table names (one per line).
    • Pattern — regex (e.g. ^Z.* for all custom tables, ^V.* for SD-prefixed).
  • Description (optional) — shown in the LLM's module picker.
  • Is custom flag — if true, full schema is passed to the LLM. If false, QRY relies on the model's prior SAP knowledge and only passes table names.

Click Save. The module appears in the catalog tree under its parent schema.

Permissions: defense in depth​

SAP modules are wired into both layers of access control:

DAC at the module level​

Grant access to a module the same way you grant access to a schema — see DAC. The grant's scope path is:

{datasource_id}/{database}/{schema}/{module}/{table}

A grant at {datasource}/{database}/{schema}/{module} covers all tables in the module; a grant at {datasource}/.../{module}/{table} is per-table.

ABAC at the table level​

Tag tables with classifications (e.g. pii, gdpr-restricted, confidential) and define policies at the ABAC layer. Tag-based row-level security applies regardless of module.

The result: module-level access for coarse business-area segregation, ABAC tag policies for cross-cutting sensitivity controls.

How users see modules​

In the Catalog Explorer, after picking a SAP HANA datasource users see:

HANA-PROD
├── PROD_SID
│   └── SAPABAP1 (schema)
│       ├── SD (module)
│       │   ├── VBAK
│       │   ├── VBAP
│       │   └── ...
│       ├── MM (module)
│       │   ├── EKKO
│       │   ├── EKPO
│       │   └── ...
│       └── Z (module — custom)
│           ├── ZCUSTOMER_LOYALTY
│           └── ...

Clicking a module shows its tables; clicking a table opens table details and lets the user Open in Chat scoped to that module.

Common issues​

A user can see the module but every query against it fails. The module is granted but a parent schema or datasource isn't. RBAC composes top-down — without the parent, the child grant can't take effect.

Tables I added to the module aren't appearing in chat. Schema cache is stale. Refresh the datasource's schema (Datasource details → Refresh schema).

LLM still uses tables from outside the module. The model "knows" SAP standard tables and may reference them even if you didn't pass them. If that's a problem, scope the conversation more aggressively in the prompt:

"Only use tables in the SD module. Don't reference standard SAP tables that aren't in the module."

Custom Z table is in the module but the LLM hallucinates a column.* The is_custom flag should be true so QRY passes the full column schema. Without it, QRY passes table names only and the model guesses columns.

Two modules with overlapping tables. Allowed but confusing. QRY will show the table in both places. RBAC grants compose: a user with grant on either module sees the table.

See also​

QRYA product of IXEN.