SAP SAC Connections Tutorial (Part 1)

SAP Analytics Cloud is a cloud-based analytics and planning platform, but the data it visualizes and plans against rarely lives inside SAC itself. Connections are the configured pathways that let SAC reach out to source systems—SAP Datasphere, SAP BW/4HANA, SAP S/4HANA (on-premise or cloud), SAP HANA Cloud, third-party databases, OData services, and file-based sources—so business users can build stories, analytic applications, and planning models on real enterprise data.

Conceptually, every SAC connection falls into one of two data acquisition modes. Live connections do not copy data into SAC; instead, SAC sends queries to the source system at runtime, and the source system computes and returns results. This means data is always current, but it also means the source system's performance and availability directly affect the SAC user experience, and modeling flexibility inside SAC is constrained by what the live source exposes (for example, calculated measures or currency conversions may need to exist in the source model rather than being added freely in SAC). Import connections copy a snapshot of data into SAC's in-memory model. This gives full modeling flexibility (SAC-side calculations, currency conversion, hierarchies) and fast query performance because everything is local, but the data is only as fresh as the last import/replication job, so a scheduling and monitoring strategy becomes part of the design.

Within these two modes, SAC supports several connection categories that consultants must distinguish clearly. Cloud-to-cloud connections link SAC to other SAP BTP or cloud services such as SAP Datasphere or SAP HANA Cloud, typically using OAuth2 or SAML-based trust rather than static credentials. Live connections to on-premise systems (like an on-premise BW/4HANA or S/4HANA system) typically require a connectivity component—most commonly the SAP Cloud Connector paired with Principal Propagation or a technical user—to securely tunnel traffic from the cloud tenant into the customer's private network without opening inbound firewall ports. Import connections can pull from many of the same sources plus generic OData services, SuccessFactors, Google BigQuery, and flat files, using scheduled or on-demand replication jobs.

Why this distinction matters operationally: a story built on a live connection behaves like a live query tool—every filter change triggers a new round trip to the source—while a story on an import connection behaves like a self-contained cube, fast but stale until refreshed. Architects choose between them based on data volume, source system query load tolerance, real-time requirement, and whether SAC-side modeling (custom calculations, blending multiple sources in one story) is needed, which only import (or a hybrid combination) supports well.

A newer architectural pattern is SAC using SAP Datasphere as a semantic and integration layer: instead of connecting SAC directly to every source system, source data is modeled and harmonized once in Datasphere, and SAC connects to Datasphere via a live connection. This reduces the number of point-to-point connections SAC must maintain and centralizes governance, but it introduces Datasphere as a dependency whose availability and performance now sit in the critical path of SAC dashboards.

From a beginner's perspective, the practical takeaway is: before building any model or story, identify what connection type feeds it, because that decision cascades into what modeling features are available, how fresh the data will be, and who is responsible for keeping the connection alive.

A retail company's finance team wants a daily sales dashboard in SAC. The BI team initially proposed a live connection directly to S/4HANA to guarantee real-time figures, but load testing showed the live queries during month-end close degraded S/4HANA response times for operational users. The team switched the dashboard to an import connection with a nightly replication job, accepting a one-day data latency in exchange for protecting the production ERP system's performance, while keeping a separate live connection for a small executive real-time KPI tile that queries only a lightweight aggregate view.

• Assuming all connection types support the same SAC modeling features, then discovering live connections restrict custom calculations or blending.
• Building live connections to transactional source systems without checking source-side query load impact during peak business hours.
• Not distinguishing between 'live' and 'import' when describing requirements to stakeholders, leading to mismatched expectations about data freshness.
• Treating SAP Datasphere as just another data source rather than recognizing it as a semantic layer that changes the overall connection architecture.
• Ignoring that import connections require an ongoing replication/refresh schedule that must be monitored like any other data load process.

• Document, for every SAC model, which connection type feeds it and why that choice was made.
• Reserve live connections for scenarios genuinely needing real-time data and where source systems can absorb the query load.
• Use import connections for large historical volumes, heavy blending, or when SAC-side calculations are required.
• Consider SAP Datasphere as a centralizing semantic layer when many SAC models need to reuse the same harmonized data.
• Validate connection choice with a load/performance test before go-live, not after user complaints arise.

Interviewers commonly ask candidates to explain the difference between live and import connections and to justify which one fits a given scenario (e.g., real-time operational reporting vs. large-volume historical planning). Strong answers reference source system load impact, modeling flexibility trade-offs, and mention the Cloud Connector for on-premise live connectivity, showing awareness beyond a textbook definition.