Credentials are stored encrypted at rest and decrypted only in memory, for the moment a query runs. Connections are pooled and closed after an idle period, so a busy afternoon does not open a connection per question.
1Create the database user first
Do this before touching NeelAI, as a HANA user with the privilege to grant. The schema name is the SAP company schema — SBODEMOIN below, but it will be the customer's own:
CREATE USER NEELAI_RO PASSWORD "<generated>" NO FORCE_FIRST_PASSWORD_CHANGE;
GRANT SELECT ON SCHEMA SBODEMOIN TO NEELAI_RO;NO FORCE_FIRST_PASSWORD_CHANGE matters: a service account that is asked to change its password on first use will simply fail to connect, with an error that does not say so. Set the password policy for this user so it does not expire, or accept that the connection will break on a schedule nobody remembers.
GRANT SELECT ON SCHEMA covers tables added later — by an upgrade, or by an add-on. Granting table by table means the next SAP patch quietly takes a few answers away.2Configure
HANA_HOST=hana.customer.internal
HANA_PORT=30015
HANA_USER=NEELAI_RO
HANA_SCHEMA=SBODEMOIN
HANA_IDLE_TTL_SECONDS=300The password is set through the admin UI rather than the environment file, so it is written straight to encrypted storage and never lands in a shell history, a compose file or a backup of either.
HANA_SCHEMA is case-sensitive and SAP creates it upper-case. A schema name typed in lower case connects and then finds nothing, which reads exactly like a permissions problem and is not one.3Verify, in this order
- Test connection in Administer → Connection. It reports the HANA version and the schema it reached. If it names a different schema than you expected, stop here.
- Run the schema introspection. It reads table and column metadata into a snapshot NeelAI uses to work out which tables a question needs. Until it has run, answers are generic and often wrong.
- Ask one question you know the answer to. Not a clever one — “what were our sales last month” — and check it against SAP yourself before anybody else sees it.
4Re-running the introspection
The snapshot is a picture of the schema at a moment, so it needs retaking whenever the schema changes: a B1 upgrade, a new add-on, or user-defined fields added by the customer's own consultant. Nothing breaks if you forget — the new fields are simply invisible, which is harder to notice than a failure.
5The three things that usually go wrong
5.1Answers are slow
Check HANA_IDLE_TTL_SECONDS before anything else. A TTL shorter than the gap between questions means every question pays for a fresh handshake, and on a remote HANA that handshake can cost more than the query. Five minutes suits an office that asks questions in bursts.
5.2Everything answers “no data”
Privileges, nearly always. The user connects, so the credentials are right; it sees no objects, so the grant did not happen or landed on a different schema. Run the counting query from Requirements as that user and the question answers itself.
5.3It worked and then stopped
A rotated or expired password, a firewall rule that aged out, or the HANA instance moving port after a restart. The connection test names which of the three it is, and it is worth running before reading any logs.