Configuring Federated Connections and Remote Tables for Production Use
Learn the practical steps and considerations for setting up connections and remote tables to support federated access in Datasphere, plus how this surfaces through SAC live connections.
Explanation
Moving from concept to implementation, configuring data federation in SAP Datasphere begins with establishing a Connection to the source system. Connections define the technical and authentication details needed to reach a source such as an S/4HANA system, an SAP BW/4HANA system, another SAP HANA Cloud instance, or select non-SAP databases supported by Datasphere's connection framework. Depending on the source, the connection may use principal propagation (passing the end user's identity through to the source, respecting source-level authorizations) or a technical user model (a single service account used for all federated queries, with authorization filtering handled inside Datasphere via data access controls). Once a connection exists, an administrator or data engineer browses available source objects and adds them as remote tables inside a Datasphere space. At this point, a key configuration decision is the access type: remote (federated, live pass-through) or replicated (data physically copied on a schedule or via real-time replication where supported). This choice can often be changed later, but changing it has operational implications: switching from remote to replicated introduces a new scheduling and storage footprint, while switching from replicated to remote removes that footprint but reintroduces dependency on live source performance. For federated (remote) tables, Datasphere pushes down filters, joins, and aggregations to the source system whenever the source's SQL/query engine supports the operation. This push-down is important for performance: if a view built on a remote table forces significant post-processing inside Datasphere (for example, complex calculated columns that cannot be pushed down), then the source system may return a large intermediate result set, and Datasphere does the heavy lifting locally, which can slow down queries significantly. Reviewing the generated query execution details, where available through Datasphere's modeling and monitoring tools, helps identify whether push-down is occurring as expected. A second layer of configuration involves how these federated objects are exposed to SAC. When SAC connects to Datasphere, it typically does so as a live data connection: SAC does not store the query results permanently, so every story interaction generates queries against Datasphere, which in turn may generate queries against the original federated source. This creates a multi-hop federation chain. Latency accumulates across hops, so a story that feels responsive when built against a fully replicated Datasphere model may feel noticeably slower when built against a chain that ends in a remote, federated source table, especially under concurrent user load. Security configuration matters heavily in federated scenarios. If principal propagation is used, the end user querying through SAC must have a valid mapped identity that flows all the way to the source system, and that source system's own authorization objects or roles still apply, meaning data access controls need to be consistent across layers, not just defined once in Datasphere. If a technical user model is used instead, Datasphere-level data access controls (row-level security definitions applied to spaces or views) become the primary enforcement point, and administrators must ensure these controls are correctly scoped so that federated queries do not inadvertently expose broader source data than intended. Troubleshooting federated setups commonly involves three areas: connectivity (network reachability, certificate or credential expiry, firewall rules between Datasphere's cloud environment and on-premise source systems, often requiring a cloud connector or private link setup depending on deployment), performance (identifying whether push-down is happening, checking source system load, and reviewing query timeouts), and data consistency (confirming that what federation returns matches source system reality, since there's no snapshot to independently verify against other than checking the source directly). Production support teams should have a clear checklist to distinguish 'the source system is down or slow' from 'the Datasphere model logic is inefficient' when a federated report fails or times out.
Real project scenario
A finance team building a group-level margin analysis model needed live figures from an on-premise S/4HANA system that could not be fully replicated due to data governance restrictions on financial detail tables. The integration team set up a Datasphere connection using principal propagation so that each analyst's own S/4HANA authorizations were respected at query time. During UAT, certain views ran slowly because a currency conversion calculation prevented push-down; the team restructured the view to push filtering and aggregation to the source first, then applied the currency conversion on the smaller result set, cutting query time significantly.
Common mistakes
• Configuring a technical user connection for a scenario that actually required person-level data restrictions, resulting in over-exposure of federated source data. • Building complex calculated logic directly on top of remote tables without checking whether it blocks push-down, leading to poor performance that gets blamed on 'Datasphere being slow' rather than the model design. • Not planning for network and firewall requirements between the cloud federation layer and on-premise source systems until late in the project, causing delays. • Ignoring the added latency of multi-hop federation chains (source to Datasphere to SAC) when setting user expectations for story responsiveness. • Failing to re-evaluate the remote versus replicated decision after go-live, even as usage patterns and data volumes change significantly.
Best practices
• Choose principal propagation when source-level, user-specific authorization must be strictly respected; choose a technical user model with Datasphere data access controls when centralized governance is preferred. • Design views on remote tables to push filtering and aggregation down first, applying complex calculations only after the result set has been reduced. • Validate network connectivity, credentials, and certificate lifetimes for on-premise source connections proactively, not only at initial setup. • Monitor and periodically reassess whether remote tables under heavy repeated use should be converted to replicated tables to protect source system performance. • Clearly document the full federation chain (source to Datasphere to SAC) for support teams so performance issues can be triaged at the correct layer quickly.
Interview angle
Interviewers assessing intermediate-level federation knowledge often ask candidates to walk through a real configuration decision: which connection type was used, why principal propagation or a technical user was chosen, and how performance issues were diagnosed and resolved. Strong answers reference push-down behavior, the multi-hop latency effect of SAC-to-Datasphere-to-source chains, and concrete troubleshooting steps rather than generic statements about 'connecting systems'.