Configuring Live and Import Connections Between SAC and Datasphere

Explanation

Once the conceptual split between SAC and Datasphere is understood, the next practical skill is actually establishing and configuring the connection, because this decision shapes every downstream story, planning model, and troubleshooting path. In SAC, connections to Datasphere are typically created from the Connections area, where an administrator selects the Datasphere connection type and authenticates using the tenant's configured trust relationship (commonly OAuth-based single sign-on between the SAC tenant and the Datasphere tenant, configured once by an administrator with appropriate tenant-level access). After the connection object exists, individual model or story authors can browse exposed Datasphere spaces and select specific views or analytic models to build against. The first major decision point is live versus import. A live connection means SAC issues queries directly against Datasphere at runtime; no data is copied into SAC's own in-memory engine. This is the right choice when data changes frequently and users need near-real-time figures, when data volumes are large and would be expensive to duplicate, or when row-level security defined in Datasphere must be enforced consistently without being re-implemented in SAC. The trade-off is that story performance depends entirely on Datasphere's own query performance and network latency between the two cloud services, and certain SAC features that require a local in-memory model (such as some planning-specific capabilities or certain calculated measures) may be unavailable or behave differently over a live connection. An import connection instead copies a snapshot of the selected Datasphere view or model into SAC's own model, after which SAC treats it much like any natively modeled dataset. This unlocks full SAC modeling flexibility, including calculated dimensions, currency conversion at the SAC layer, and planning-specific features, but introduces a data latency concern: the SAC model only reflects data as of the last import/refresh, so a refresh schedule (manual or scheduled data import job) must be established and monitored. Import also duplicates storage and consumes SAC's own capacity, which matters for licensing and platform sizing conversations with the customer. On the Datasphere side, the exposure setting on views and analytic models determines whether they even appear as connectable objects to SAC. A view or model must typically be marked or configured for consumption, and depending on the object type, this may also require it to be part of a suitable semantic type (such as an analytic dataset or a fact/dimension model) that SAC can interpret correctly, particularly for dimension hierarchies and measures with proper aggregation behavior. A common early-project defect is a technically correct SQL view in Datasphere that SAC cannot use meaningfully because it lacks a defined measure/dimension semantic structure. Troubleshooting connection issues generally starts in three places: verifying the trust/authentication configuration between the two tenants is still valid (tokens or trust relationships can expire or be revoked during tenant migrations), verifying the specific object is exposed for consumption and the requesting user has appropriate authorization in the Datasphere space, and checking whether the live query is timing out due to an expensive underlying view (which often requires optimizing the Datasphere-side model, such as reducing join complexity or leveraging Datasphere's own performance features, rather than trying to fix it purely from the SAC side). For production support, teams should document, per SAC model, which connection type is used, which Datasphere space and object it targets, and what the refresh cadence is for import models, since this information is essential when a business user reports 'the numbers are wrong' and the actual root cause may simply be a stale import that has not run since a source system planned outage.

Code example

-- Example: Datasphere view exposed for consumption-- (conceptual SQL-like representation of a Datasphere analytic view definition)CREATE VIEW SALES_ANALYTIC_MODEL ASSELECT    s.SALES_ORDER_ID,    s.CUSTOMER_ID,    c.CUSTOMER_NAME,    s.SALES_AMOUNT,    s.CURRENCY,    s.POSTING_DATEFROM SALES_FACT sJOIN CUSTOMER_DIM c    ON s.CUSTOMER_ID = c.CUSTOMER_ID;-- In Datasphere, this view would then be:-- 1. Assigned semantic usage as an Analytic Dataset (facts/measures identified)-- 2. Marked as 'Expose for Consumption' in the space settings-- 3. Selected in SAC's Connections > Datasphere browser when creating--    either a live-connected model or an import model in SAC

Real project scenario

During a phased rollout, a consulting team initially connected an executive sales dashboard to Datasphere via live connection to guarantee real-time figures for daily leadership reviews. Performance complaints emerged because the underlying Datasphere view contained multiple large joins and was queried repeatedly by many concurrent SAC users. The team resolved this by creating a smaller, pre-aggregated Datasphere view specifically for the dashboard's key metrics and switching only the heaviest dashboard pages to an import connection refreshed every two hours, while keeping detailed drill-through pages on the live connection for accuracy, balancing performance and freshness per use case rather than applying one connection type tenant-wide.

Common mistakes

• Choosing import connections by default without evaluating data freshness requirements, resulting in stale figures during audits or leadership reviews • Forgetting to schedule or monitor the import/refresh job, so the SAC model silently goes stale • Exposing overly complex, join-heavy views for live consumption, causing slow story rendering • Not aligning on which layer owns row-level security, leading to either duplicated security logic or unintended data exposure • Assuming a view is usable in SAC without confirming its semantic type supports the required measures and hierarchies

Best practices

• Match connection type to actual business freshness requirements rather than defaulting to one approach across all models • Pre-aggregate or simplify heavy Datasphere views intended for live consumption to protect story performance • Document and monitor import refresh schedules as part of standard operational runbooks • Confirm semantic type (measures, dimensions, hierarchies) is correctly defined on Datasphere objects before troubleshooting from the SAC side • Periodically validate that tenant trust/authentication between SAC and Datasphere remains active, especially after tenant or identity provider changes

Interview angle

A frequent scenario-based interview question asks how a candidate would decide between live and import connections for a given business requirement; strong candidates walk through data freshness needs, expected query complexity/volume, whether planning features are required, and mention monitoring refresh schedules as an ongoing production responsibility, not just a one-time setup task.