How Atlan connects to SAP Datasphere
Atlan connects to SAP Datasphere to extract technical metadata and lineage while maintaining network security and compliance. A connection uses two authenticated paths together: the SAP Datasphere APIs (OAuth 2.0) for spaces and analytic models, and the SAP HANA Cloud database that backs your tenant (a database user) for physical tables, views, and columns. You can choose between Direct connectivity for tenants available from the internet or Self-deployed runtime for tenants that must remain behind your firewall.
Connect via direct network connection
Atlan's SAP Datasphere workflow establishes a direct connection to your tenant from the Atlan SaaS tenant. This approach works when your SAP Datasphere APIs and SAP HANA Cloud endpoint can accept connections from the internet.
- Atlan authenticates to the SAP Datasphere APIs over HTTPS using an OAuth 2.0 client-credentials grant.
- Atlan connects to the SAP HANA Cloud SQL endpoint over port 443 (default).
- Your tenant accepts inbound network connections from Atlan's IP addresses, controlled through your firewall rules or network security groups.
For details on how direct connectivity works, see Direct connectivity.
Connect via self-deployed runtime
A runtime service deployed within your network acts as a secure bridge between Atlan Cloud and your SAP Datasphere tenant. This approach works when your tenant must remain fully isolated behind your firewall.
- The runtime maintains an outbound HTTPS connection to Atlan Cloud (port 443) and local connections to your SAP Datasphere APIs and SAP HANA Cloud endpoint.
For details on how Self-Deployed Runtime works, see SDR connectivity.
Lineage
Atlan builds lineage for SAP Datasphere across three complementary areas:
- Analytic-model lineage: how tables and views feed the analytic models built on top of them, at both the asset and column level.
- View lineage: how SQL views derive from the tables and views they're built on.
- Upstream source lineage: for tables replicated into SAP Datasphere, lineage back to their real source assets in Atlan, including SAP S/4HANA, SAP ECC, SAP BW, SAP HANA, Oracle, Microsoft SQL Server, and Amazon S3. Upstream source lineage requires a database user with cross-space read access. Where a replicated table's source connection can't be resolved, Atlan catalogs the asset without an upstream lineage edge rather than inferring one.
Security
Atlan extracts only structural metadata—spaces, tables, views, analytic models, and columns. For example, if you have a sales_orders table, Atlan discovers the table structure and column definitions, but never queries or stores the records themselves.
-
Read-only operations: All access is read-only. The connector can't modify data, create or drop objects, or change any configuration. The OAuth client scope and database user permissions you grant control exactly what the connector can access.
-
Credential encryption: SAP Datasphere connection credentials are encrypted at rest and in transit. In Direct connectivity, Atlan encrypts credentials before storage. In Self-deployed runtime, credentials never leave your network perimeter—the runtime retrieves them from your enterprise-managed secret vaults (AWS Secrets Manager, Azure Key Vault, GCP Secret Manager, or HashiCorp Vault) only when needed, and Atlan Cloud never receives or stores them.
-
Network isolation with Self-deployed runtime: Your SAP Datasphere tenant gains complete network isolation from the internet. It only accepts connections from the runtime within your local network. The runtime itself only makes outbound HTTPS connections to Atlan Cloud, which your network team can control through firewall rules.
See also
- Direct connectivity: How Atlan connects directly to data sources
- SDR connectivity: How Self-Deployed Runtime connects to data sources
- Set up SAP Datasphere: Configure the OAuth client and database user