Skip to main content
Krishnaraj_K
Member
Oct 13, 2026 7:38 PM UTC
Solved

Integration architecture: direct vs SAP BDC vs Databricks vs hybrid

Hi OneStream Community,

We are evaluating integration architecture patterns for a OneStream implementation involving a mix of SAP and non-SAP source systems. I would appreciate insights from others who have implemented similar architectures.

At a high level, we are considering the following patterns:

  1. Direct Integration
    SAP and non-SAP source systems integrate directly with OneStream using the appropriate supported integration mechanisms.

  2. SAP BDC-Centric
    SAP Business Data Cloud serves as the primary governed data layer, with SAP and potentially non-SAP data prepared and exposed to OneStream.

  3. Data Lake / Databricks-Centric
    SAP and non-SAP data are consolidated and governed through an enterprise data platform such as Databricks, with OneStream consuming the curated datasets.

  4. Hybrid: SAP BDC + Data Lake / Databricks
    SAP data is managed through SAP BDC, while non-SAP data is managed through the enterprise data platform, with both supplying the required data to OneStream.

One of the key considerations for us is where transformation, aggregation, and business calculation logic should reside. We want to avoid unnecessary duplication of calculation logic between the upstream data platforms and OneStream, which could create additional synchronization, testing, reconciliation, and maintenance requirements. This reflects a concern we discussed previously about potentially creating a double-maintenance model when formulas and aggregations exist both externally and within OneStream.

I would particularly appreciate hearing from those with real-world OneStream implementation experience:

  • Which of these patterns have you implemented successfully?
  • For a large enterprise with SAP and non-SAP sources, do you typically favor direct integration, a centralized data platform, or a hybrid model?
  • What criteria drove that decision: performance, data volumes, governance, scalability, latency, operational support, or something else?
  • Where do you typically place transformations and aggregations versus planning-specific calculations/business rules?
  • Does introducing an enterprise data platform between source systems and OneStream provide enough value to justify the additional architectural layer?
  • Have you experienced challenges with multiple integration paths into OneStream in a hybrid architecture?
  • How do you handle master data, hierarchies, and cross-reference mappings across SAP, non-SAP sources, and OneStream?
  • What architecture would you recommend if you were designing it again today?

I am especially interested in lessons learned, trade-offs, and architecture patterns that have proven sustainable after go-live, rather than product-specific theoretical capabilities.

Thanks in advance for sharing your experience.

    RobbSalzmann
    RobbSalzmannAnswer
    Employee - Advisor
    Oct 15, 2026 12:57 PM UTC

    Here are some thoughts about this, just my perspective, plenty of ways to get this done.

    I’d expect an enterprise with this mix of SAP and non-SAP sources to already run a data warehouse or lakehouse for enterprise reporting, and Databricks is on your list. My view is that OneStream works best as the curated layer for financial data, with the existing platform as the integration layer for data beyond the GL. Mapping to the financial model, hierarchies, workflow validation, and the financial calculations all happen in OneStream, and its results are the governed numbers.

    For GL actuals, direct connections from the ledgers keep on-demand import and drill back to the source items during close. Operational, non-SAP, and planning data fit through the warehouse. If the enterprise is adopting BDC then SAP data can be shared from BDC into Databricks over Delta Sharing without being extracted out of SAP’s cloud, and SAP operational data could come to OneStream from there with the non-SAP data. If there’s no enterprise warehouse then direct integration for everything is the simpler fit.

    Design Considerations

    • Close-period support. A connector import runs when the user clicks import in workflow. Against SAP directly, a re-import picks up a correcting journal as soon as it’s posted. Against a warehouse, it only picks it up once the warehouse has refreshed, so any layer in the middle needs on-demand refresh and on-call support through the close calendar. That’s the main reason GL actuals fit best direct.
    • SAP extraction compliance. SAP Note 3255746 prohibits ODP-RFC for SAP-to-non-SAP integration, and from June 2026 a security patch blocks unauthorized ODP-RFC calls. A temporary opt-out lets restricted ODP-RFC calls continue until the end of 2026. RFC itself isn’t banned, and only the ODP Data Replication API over RFC is restricted in SAP-to-non-SAP scenarios. Table and CDS view extractions, BAPIs, function modules, and DeltaQ all remain usable and compliant. The OneStream SAP Connector is a OneStream Solution that uses Smart Integration Connector for its connections, over RFC or Web API. For any SAP extraction, direct or through a platform, the thing to confirm is that it doesn’t use ODP-RFC. 
    • Volume. The cube holds summarized data. Transaction detail stays at the source, in SAP or the warehouse, and is reached through drill back from the connector rule.
    • Audit lineage. Each hop is a control point. Control totals (record count and amount by entity and period) carried from the source and checked at import give a tie-out at every step.

    Where transformations and calculations go

    On the double-maintenance concern so that we reduce technical debt:

    • Upstream: extraction, technical cleanup, filtering, and enrichment from enterprise master data, in the same conformed datasets the platform provides to every consumer.
    • Connector rule SQL: summarizing to the grain OneStream loads. Against the warehouse, the query runs on the warehouse engine at import, and grain changes stay with the OneStream team instead of becoming a ticket on the platform backlog.
    • OneStream: mapping to OneStream members, aggregation along OneStream hierarchies, FX, eliminations, consolidation, allocations, and planning calculations.
    • Kept out of upstream: roll-ups along dimensions OneStream also has, and calculations OneStream also performs. Loading base level lets the cube do the aggregation.

    Transformation rules fit the mapping to OneStream members. Finance admins own those dimensions, and unmapped codes surface at import in workflow where they can be fixed. If a central enterprise mapping already exists then OneStream could consume that and map from the conformed code. Outbound works the same way: consolidated, translated, and planned numbers could flow from OneStream to the lake, so the lake isn’t recalculating them.

    Is the extra layer worth it?
    For data beyond the GL, it’s worth it when the enterprise already runs a warehouse or lakehouse as its governed layer, has several non-SAP sources, and the platform team supports close. Building one mainly to feed OneStream is harder to justify. In that case direct integration, with Stage and workflow as the audit trail, is simpler to support.

    Multiple paths into OneStream
    The problems come when the same kind of data arrives on different paths, like SAP actuals one way and non-SAP actuals another. Each path brings its own refresh timing, reconciliation, support ownership, and cross-reference mappings. Consolidated results then mix data pulled at different times, and the same mapping is maintained in more than one place. Splitting paths by type of data keeps each kind on one path: GL actuals direct from the ledgers, and operational and planning data through the warehouse.

    Master data and cross-references

    • SAP is the system of record for base members of SAP-sourced dimensions: company codes, GL accounts, cost centers, and profit centers. Automated loads of new base members, with a review step, keep OneStream current.
    • Reporting and planning hierarchies live in OneStream, including planning-only members that don’t exist in any source yet.
    • The cross-reference across SAP, non-SAP, and OneStream codes works best with one owner. If an enterprise MDM tool already holds it then OneStream could consume that. Otherwise the transformation rules are the cross-reference.

    Working with the SAP and platform teams

    • SAP change processes are built to protect ERP stability, so every request through them adds lead time. The more the OneStream team owns (mapping, grain, and calculations), the fewer of those requests the project needs.
    • Requesting full standard CDS views or data products with all fields means adding a field later isn’t another change request.
    • Staying on standard objects avoids custom code the SAP team has to maintain through every upgrade.
    • Basis, security, and network each own a piece: service users, authorizations, and the Smart Integration Connector gateway. Bringing them in early keeps those queues off the critical path.
    • A close-period support model agreed in writing with the platform team before go-live settles who’s on call.

    Putting it together
    In this model, OneStream is the curated financial layer and the source of truth for financial results. GL actuals come direct from the ledgers, with SAP over a compliant connection and drill back to the source items. Operational, non-SAP, and planning data come from the enterprise warehouse through connector rules that summarize in their SQL and drill back to the warehouse for detail. Control totals are checked at import, and OneStream results flow back to the lake for enterprise reporting.

    View in thread

    2 replies

    Employee - Advisor
    sameburnEmployee - Advisor
    Employee - Advisor
    Oct 14, 2026 5:51 PM UTC

    Hi ​@Krishnaraj_K 

    I would recommend reaching out to the Remote Consulting team via Support. They can provide best practice guidance here based on experience and your requirements.  Please be advised that this will likely be considered billable 

    Hope this helps 

    Sam

    RobbSalzmann
    Employee - Advisor
    RobbSalzmannEmployee - AdvisorAnswer
    Employee - Advisor
    Oct 15, 2026 12:57 PM UTC

    Here are some thoughts about this, just my perspective, plenty of ways to get this done.

    I’d expect an enterprise with this mix of SAP and non-SAP sources to already run a data warehouse or lakehouse for enterprise reporting, and Databricks is on your list. My view is that OneStream works best as the curated layer for financial data, with the existing platform as the integration layer for data beyond the GL. Mapping to the financial model, hierarchies, workflow validation, and the financial calculations all happen in OneStream, and its results are the governed numbers.

    For GL actuals, direct connections from the ledgers keep on-demand import and drill back to the source items during close. Operational, non-SAP, and planning data fit through the warehouse. If the enterprise is adopting BDC then SAP data can be shared from BDC into Databricks over Delta Sharing without being extracted out of SAP’s cloud, and SAP operational data could come to OneStream from there with the non-SAP data. If there’s no enterprise warehouse then direct integration for everything is the simpler fit.

    Design Considerations

    • Close-period support. A connector import runs when the user clicks import in workflow. Against SAP directly, a re-import picks up a correcting journal as soon as it’s posted. Against a warehouse, it only picks it up once the warehouse has refreshed, so any layer in the middle needs on-demand refresh and on-call support through the close calendar. That’s the main reason GL actuals fit best direct.
    • SAP extraction compliance. SAP Note 3255746 prohibits ODP-RFC for SAP-to-non-SAP integration, and from June 2026 a security patch blocks unauthorized ODP-RFC calls. A temporary opt-out lets restricted ODP-RFC calls continue until the end of 2026. RFC itself isn’t banned, and only the ODP Data Replication API over RFC is restricted in SAP-to-non-SAP scenarios. Table and CDS view extractions, BAPIs, function modules, and DeltaQ all remain usable and compliant. The OneStream SAP Connector is a OneStream Solution that uses Smart Integration Connector for its connections, over RFC or Web API. For any SAP extraction, direct or through a platform, the thing to confirm is that it doesn’t use ODP-RFC. 
    • Volume. The cube holds summarized data. Transaction detail stays at the source, in SAP or the warehouse, and is reached through drill back from the connector rule.
    • Audit lineage. Each hop is a control point. Control totals (record count and amount by entity and period) carried from the source and checked at import give a tie-out at every step.

    Where transformations and calculations go

    On the double-maintenance concern so that we reduce technical debt:

    • Upstream: extraction, technical cleanup, filtering, and enrichment from enterprise master data, in the same conformed datasets the platform provides to every consumer.
    • Connector rule SQL: summarizing to the grain OneStream loads. Against the warehouse, the query runs on the warehouse engine at import, and grain changes stay with the OneStream team instead of becoming a ticket on the platform backlog.
    • OneStream: mapping to OneStream members, aggregation along OneStream hierarchies, FX, eliminations, consolidation, allocations, and planning calculations.
    • Kept out of upstream: roll-ups along dimensions OneStream also has, and calculations OneStream also performs. Loading base level lets the cube do the aggregation.

    Transformation rules fit the mapping to OneStream members. Finance admins own those dimensions, and unmapped codes surface at import in workflow where they can be fixed. If a central enterprise mapping already exists then OneStream could consume that and map from the conformed code. Outbound works the same way: consolidated, translated, and planned numbers could flow from OneStream to the lake, so the lake isn’t recalculating them.

    Is the extra layer worth it?
    For data beyond the GL, it’s worth it when the enterprise already runs a warehouse or lakehouse as its governed layer, has several non-SAP sources, and the platform team supports close. Building one mainly to feed OneStream is harder to justify. In that case direct integration, with Stage and workflow as the audit trail, is simpler to support.

    Multiple paths into OneStream
    The problems come when the same kind of data arrives on different paths, like SAP actuals one way and non-SAP actuals another. Each path brings its own refresh timing, reconciliation, support ownership, and cross-reference mappings. Consolidated results then mix data pulled at different times, and the same mapping is maintained in more than one place. Splitting paths by type of data keeps each kind on one path: GL actuals direct from the ledgers, and operational and planning data through the warehouse.

    Master data and cross-references

    • SAP is the system of record for base members of SAP-sourced dimensions: company codes, GL accounts, cost centers, and profit centers. Automated loads of new base members, with a review step, keep OneStream current.
    • Reporting and planning hierarchies live in OneStream, including planning-only members that don’t exist in any source yet.
    • The cross-reference across SAP, non-SAP, and OneStream codes works best with one owner. If an enterprise MDM tool already holds it then OneStream could consume that. Otherwise the transformation rules are the cross-reference.

    Working with the SAP and platform teams

    • SAP change processes are built to protect ERP stability, so every request through them adds lead time. The more the OneStream team owns (mapping, grain, and calculations), the fewer of those requests the project needs.
    • Requesting full standard CDS views or data products with all fields means adding a field later isn’t another change request.
    • Staying on standard objects avoids custom code the SAP team has to maintain through every upgrade.
    • Basis, security, and network each own a piece: service users, authorizations, and the Smart Integration Connector gateway. Bringing them in early keeps those queues off the critical path.
    • A close-period support model agreed in writing with the platform team before go-live settles who’s on call.

    Putting it together
    In this model, OneStream is the curated financial layer and the source of truth for financial results. GL actuals come direct from the ledgers, with SAP over a compliant connection and drill back to the source items. Operational, non-SAP, and planning data come from the enterprise warehouse through connector rules that summarize in their SQL and drill back to the warehouse for detail. Control totals are checked at import, and OneStream results flow back to the lake for enterprise reporting.

      Terms & ConditionsAccessibility statement