Designing and Troubleshooting Live Data Connections Between SAC and Datasphere

Explanation

A live connection between SAP Analytics Cloud (SAC) and SAP Datasphere is the primary integration pattern for scenarios where data must remain in Datasphere and be queried on demand rather than replicated into SAC's in-memory model. This is common when data volumes are large, when data freshness requirements are near real time, or when governance rules require that sensitive data never leave the source system's boundary. Understanding how this connection is designed, how requests flow at runtime, and how to diagnose failures is essential for any consultant supporting hybrid SAC-Datasphere landscapes. Design and configuration: In Datasphere, data intended for SAC consumption is typically modeled in a space using views (graphical or SQL-based) and then explicitly exposed for consumption, most often as analytic models or exposed views marked for external access. This exposure step is deliberate and separate from simply building a view - a view can exist in a space without being consumable by SAC until it is flagged accordingly. On the SAC side, an administrator creates a live data connection of the Datasphere connection type, typically authenticated through a trust relationship or OAuth-based mechanism configured between the two cloud tenants, rather than a shared technical user pattern common in on-premise systems. Once the connection exists, story or model builders select the connection and browse exposed spaces and models to build stories or planning models directly against Datasphere data. Runtime flow: When a user opens a story built on a live Datasphere connection, SAC does not import data into its own model; instead, each query interaction (filtering, drilling, changing a variable) generates a query that is sent to Datasphere, which executes it against the underlying view logic and returns only the result set needed for that specific view or chart. This means data always reflects the current state in Datasphere, but it also means every interaction has network and computation latency, and the responsiveness of the story is bound by Datasphere's query performance, not SAC's in-memory engine. Troubleshooting: The most frequent issues fall into a few categories. First, exposure issues: a view exists but was never marked for consumption, or was later unexposed, causing the model to disappear from SAC's connection browser. Second, authorization issues: the user has access in SAC but the underlying Datasphere space does not extend appropriate row-level or space-level authorization to that user context, resulting in empty result sets or authorization errors rather than a clear connection failure. Third, performance issues: complex views with multiple joins or calculations that were fine for smaller queries begin to time out under a live connection as report complexity grows, since each filter change triggers a fresh execution rather than reusing a cached in-memory result. Fourth, connection or session issues: expired trust configurations or changes to tenant URLs can silently break existing connections, requiring the connection to be recreated or re-authenticated. Fifth, semantic mismatches: a view modeled without clear dimension/measure typing in Datasphere can be interpreted unexpectedly by SAC's story builder, producing broken hierarchies or aggregation surprises. Production considerations: Because live connections push query load onto Datasphere at story runtime, teams supporting production must monitor Datasphere-side compute consumption and query performance metrics, not just SAC application logs, when diagnosing slow stories. It is also important to separate development, test, and production spaces in Datasphere and manage connection endpoints consistently across SAC's own multi-environment landscape, since pointing a production SAC tenant at a development Datasphere space by mistake is a common and costly configuration error. When performance cannot be tuned further at the view level, teams often reconsider whether a subset of the data should instead be imported into SAC (a hybrid model) rather than forcing everything through live access.

Code example

-- Example: Datasphere SQL view intended for SAC live consumption-- Illustrative only; actual object types and exposure flags are configured-- through the Datasphere space UI, not raw SQL DDL in production use. CREATE VIEW SALES_ANALYTICS_VIEW ASSELECT    s.SALES_ORDER_ID,    s.CUSTOMER_ID,    c.CUSTOMER_NAME,      -- dimension attribute    s.SALES_DATE,    s.SALES_AMOUNT,        -- measure, must be typed as measure in modeler    s.CURRENCYFROM SALES_ORDERS sJOIN CUSTOMERS c    ON s.CUSTOMER_ID = c.CUSTOMER_ID; -- After creating the view in the Datasphere graphical/SQL view editor:-- 1. Open the view properties and mark it 'Expose for Consumption'.-- 2. Confirm SALES_AMOUNT is typed as a measure and CUSTOMER_ID/DATE as dimensions.-- 3. Assign the view to an analytic model if aggregation logic is required.-- 4. In SAC, create a Live Data Connection of type 'SAP Datasphere'.-- 5. In a new SAC story, select the connection, browse the space,--    and confirm the exposed view/model appears before building charts.-- 6. If the model does not appear, re-check exposure flag and space--    authorization for the SAC integration user or trust configuration.

Real project scenario

A retail analytics team built an SAC story on a live Datasphere connection showing daily sales by region. After go-live, business users reported the story took over 20 seconds to refresh on every filter change. Investigation showed the underlying Datasphere view joined five large tables with a currency conversion calculation executed row by row. The team split the view into a pre-aggregated daily summary view exposed to SAC, moving the row-level currency conversion earlier in the pipeline, which reduced story refresh time significantly. Separately, a production incident arose when a Datasphere developer unexposed a view during cleanup, unaware it was consumed by a live SAC dashboard used by finance leadership; this reinforced the need to track consumption dependencies before modifying exposure settings.

Common mistakes

• Unexposing or renaming a Datasphere view without checking which SAC stories or models consume it live. • Assuming a live connection behaves like an import connection in terms of performance, leading to overly complex views that time out interactively. • Not typing measures and dimensions clearly in the Datasphere view, causing SAC to misinterpret aggregation behavior. • Granting SAC users application access without verifying they also have corresponding Datasphere space or row-level authorization. • Pointing a production SAC tenant connection at a non-production Datasphere space during testing and forgetting to revert it. • Ignoring Datasphere-side query performance metrics and only investigating SAC application logs when a story is slow.

Best practices

• Maintain a simple dependency log or naming convention indicating which Datasphere views are actively consumed by SAC stories before making exposure changes. • Pre-aggregate or simplify views intended for live consumption rather than exposing raw multi-join complexity directly to SAC. • Explicitly type dimensions and measures in Datasphere views to avoid ambiguous interpretation in SAC story builders. • Align space-level and row-level authorization design in Datasphere with SAC user roles as part of the same security review, not as separate afterthoughts. • Keep development, test, and production Datasphere spaces and their corresponding SAC connections clearly separated and documented. • Monitor both SAC story performance and Datasphere query execution metrics when investigating slowness, rather than assuming the bottleneck is on one side only.

Interview angle

Interviewers commonly probe whether a candidate understands the practical difference between live and imported connectivity beyond the marketing definition - specifically, that live connections shift query execution and performance responsibility to the source system at runtime. Be ready to explain a real troubleshooting scenario: how you diagnosed whether a slow story was a modeling issue, an authorization issue, or a source-side performance issue, and what specific steps (checking exposure flags, reviewing view complexity, checking space authorizations) you took to isolate the cause.