From practice data to your own SAP. Deploying a Labs agent to SAP BTP.

An agent that answers questions about practice data is a good way to learn. An agent that answers questions about your own ECC or S/4HANA is the thing people actually pay for. Syntaai Labs makes those the same agent: build and test it on practice data, then deploy it, unchanged, into your company's SAP BTP subaccount, where it reads your real system through your Cloud Connector. This article walks through what that involves, what your Basis team has to do, and what the agent can and cannot touch once it is there.

Why BTP, and why not "just a server"

The reason is the Cloud Connector. SAP BTP already has a supported, audited, outbound-only way to reach an on-premise SAP system, and most companies with any BTP footprint already run one. Deploying the agent into your subaccount means:

• The agent runs inside your tenant, under your sign-in (XSUAA role collections), not on anyone else's infrastructure.
• SAP is reached through the Cloud Connector you already control, with no inbound ports and no new network path.
• Nothing is installed in ECC or S/4HANA. No transports, no add-ons.
• The data your agent reads never passes through the Labs cloud.

It also means the same setup works for an ECC system on a VM and an S/4HANA system in the data centre. Both have been proven end to end with the one-click deploy, a Cloud Connector on an ordinary Windows machine, and an agent answering questions from each. A deployment to your own server (AWS, Azure, Google Cloud or on-premise) and a pipeline template are on the roadmap and shown as coming soon.

What you need

The deploy, step by step

Deployment is driven from the Studio chat; the Deploy panel is only where the hands go. Tell Syntaai Agent "deploy this to BTP" and it walks you through:

1. Pick the region

   Regions are listed the way the BTP cockpit names them, grouped by provider, because the one-time code you use in the next step is bound to the region. Choosing the wrong one is the most common first mistake, so the list helps you match it to your subaccount.

2. Check the subaccount

   You paste a one-time code from the BTP cockpit into the panel (never into the chat). Labs uses it inside a single request and does not keep it. It reads your orgs and spaces, checks quota, memory and service plans, and tells you exactly what is missing and where in the cockpit to add it.

3. Describe the SAP connection

   Host, instance, client and the RFC user name. No password: that stays in your Cloud Connector and destination. Labs produces a sheet for your Basis team with the Cloud Connector mapping, the destination to create (it must be named exactly S4H_RFC) and the PFCG role.

4. Choose the data

   You can deploy with demo data first: fictional rows generated for exactly the tables your agent uses, or built from CSV exports you upload. That lets the agent answer in your subaccount before the Basis work is done, and you can switch to the live system later without changing the connector address.

5. Deploy

   A new one-time code, and Labs pushes the two apps into your space. The log streams into the panel and the chat narrates each step. A failing step shows its real output, with secrets scrubbed.

6. Connect

   Your agent now has an address inside your subaccount. Add it to your AI chat app the same way you did on practice data, sign in through your subaccount's XSUAA, and ask your first question against your own system.

What the Basis team actually has to do

The sheet Labs generates is deliberately short, because every item on it is standard SAP work:

• Cloud Connector: map the SAP system (host and system number) to a virtual host, and allow the function modules the agent needs. The agent reads tables through the standard SAP table-read function; it does not ship custom function modules.
• Destination: one RFC destination in the subaccount, named S4H_RFC, pointing at the virtual host with the RFC user. If the name is anything else, even a hyphen instead of an underscore, the connection check passes but the agent reports the destination as missing, so Labs checks the name and tells you.
• PFCG role: a generated role with S_RFC for the read function and S_TABU_NAM limited to the specific tables the agent's tools, reports and named tables use. Nothing wider. If you add a tool later, the role sheet changes with it.

When something goes wrong

Two failures account for most first deployments, and both are handled in the chat rather than in a support ticket. If the destination is misnamed, Labs reads the destination names in your subaccount with a short-lived key, finds the near miss, and tells you to duplicate it as S4H_RFC. If the Cloud Connector mapping is wrong, the error that comes back from the bridge is translated into a Cloud Connector hint instead of an RFC error code. Trial subaccounts also stop their apps overnight; "start my apps" in the chat restarts them.

What this gives you

A read-only SAP agent, built from tested tools, running in your own tenant, connected to the system you actually run, that your team can ask questions in plain language. For a security team that is "who has SAP_ALL and when did they last log on" against production, with the answer traceable to the transaction it came from. For Basis it is "which jobs failed since yesterday" without opening SM37. The practice data was the rehearsal; this is the system.