From theory to practice: How to integrate SAP BDC with Snowflake from a technical perspective

In our first blog post, we demonstrated why the partnership between SAP and Snowflake paves the way for true data democratisation and how the interaction between SAP Business Data Cloud (BDC) and the Snowflake AI Data Cloud works in theory. In this post, we go one step further. We’ll outline the prerequisites for establishing a connection and explain the specific technical setup process for SAP BDC Connect for Snowflake.

Important to note: Here, we are demonstrating how to connect an existing, standalone Snowflake account to the BDC via SAP BDC Connect for Snowflake – not SAP Snowflake, the SAP-managed Solution Extension variant, where SAP automatically provision and operates a fully integrated Snowflake instance.

Prerequisites before you get started

Before the actual setup begins, it is worth taking a look at a few key conditions that will determine whether the process is a success or a source of frustration:

• Cloud compatibility: On the SAP side, there is a hyperscaler dependency. This means that the SAP source system and the BDC Connect instance must run on the same hyperscaler and in the same region. The Snowflake account is independent of this and can be hosted on a different hyperscaler or in a different region. For example, a combination of an SAP source system and BDC Connect on AWS with a Snowflake account on a different hyperscaler or in a different region is possible.
• Permissions in Snowflake: The terms of use for the connector must be accepted once by an ORGADMIN in Snowflake. Without this step, the Zero-Copy Connector will not appear in the menu at all.
• Permissions in SAP: On the SAP side, an S-User with access to SAP for Me is required, along with the appropriate roles to provision applications in the BDC and authorise data products.
• Data products: Which data products are available depends on the SAP setup. The pre-configured standard data products are only available to customers running S/4HANA in the private or public cloud. Those who have instead connected an SAP ECC or an S/4HANA on-premises system to the BDC can provide their own custom data products.

Once these points have been clarified, the actual setup can begin.

Step by step: Setting up the zero-copy connector

1. Accept the terms of use

The first step takes place in Snowflake, though not in the Ingestion menu, but in the Admin section under Terms. Only an ORGADMIN can accept the additional terms of use for SAP BDC Connect for Snowflake. This step is required only once per Snowflake organisation and enables the connector for all accounts within the organisation.

2. Access Zero-Copy Connectors

In the Snowflake menu bar under ‘Work with data’, navigate via ‘Ingestion’ to ‘Zero-Copy’. There you will find an overview of the available Zero-Copy Connectors, which currently include SAP BDC Connect for Snowflake, amongst others.

3. Selecting a connector

Clicking ‘Connect’ on the SAP BDC Connect for Snowflake tile takes you to the setup dialogue.

4. Naming and placing the connector

In the first part of the dialogue, you assign a name to the connector and specify the database and schema in which the connector object is to be stored. Important to note: Only the connector object itself is stored in this database, not the actual SAP data. It serves purely for technical organisation within the Snowflake account.

5. Establishing a connection to SAP BDC

A wizard then opens to establish the actual connection between Snowflake and SAP BDC. Snowflake provides a Unique Connector Identifier, which must be entered in the ‘External System Instance Identifier’ field in SAP BDC. In return, SAP BDC generates an invitation link, which is then entered back into the wizard in Snowflake. According to SAP, the invitation link can only be used once to establish the connection and expires afterwards. It is only once this two-way exchange has taken place that both systems recognise each other.

6. Finalise and provision the connection

Clicking ‘Connect’ completes the setup on the Snowflake side. The connection must then also be provisioned in SAP BDC Connect. This process may take a few minutes before the status changes to ‘Processing’ or ‘Ready’.

7. Release data products in SAP BDC

Once provisioning is complete, the required data products are selected in SAP BDC Connect for release to Snowflake. Depending on the SAP landscape, either the standard data products or individually modelled, custom data products are available here. For the share option to be visible at all, the user must have the “Data Catalogue Administrator” role, and the target Snowflake instance must be part of the same formation as the source system – if either of these two requirements is missing, the Share button remains greyed out.

8. Mounting data products in Snowflake

As soon as a data product is shared in SAP BDC, it appears in the Snowflake connector overview with the status “Unmounted”. At this stage, mounting means that the shared data product becomes a usable object within the Snowflake account. It is only upon mounting that Snowflake creates the associated catalogue-linked database with all schemas and table references. Before mounting, the data product is visible but is not yet technically usable within the account.

9. Naming the database

Before mounting, the name of the catalogue-linked database can be customised. If you do not do this, Snowflake automatically adopts the name of the data product from SAP BDC one-to-one as the database name.

What happens technically during mounting

After mounting, Snowflake automatically creates a standalone catalogue-linked database consisting of three components:

• INFORMATION_SCHEMA: the standard metadata schema of every Snowflake database.
• SNOWFLAKE$ schema: contains the semantic view of the data product with all semantic information from SAP.
• Table schema (named after the SAP data product, e.g. dp_ordertocash_srv:v1): contains the actual tables.

These tables are Iceberg-compatible tables that access the data via a catalogue integration; SAP stores this data in the background as delta tables in the HANA Data Lake Files Storage (HDLF) of the SAP BDC. Snowflake does not copy any data into its own account, but merely registers the metadata and accesses the data in SAP in real time for every query. This is the core of the zero-copy approach: the data remains physically where it was created.

A look at a real-world connection illustrates the principle: After mounting, the data product DP_OrderToCash.DELTA_SHARING:v1 results in the database SAP_ORDERTOCASH with the table schema dp_ordertocash_srv:v1, which contains, amongst others, the tables ad_hdlf_sd_lt_businesspartner, ad_hdlf_sd_lt_salesdocitem and vbak.

The Semantic View: Business context instead of cryptic field names

In the SNOWFLAKE$ schema, the wizard automatically creates an object of type ‘Semantic View’. Within this, the traditional SAP designations are translated into understandable business terms: Instead of technical table names as found in the underlying SAP tables, the Semantic View provides descriptive names. For example, the SAP table `ad_hdlf_sd_lt_businesspartner` becomes the logical table ‘Business Partner HDLF Table’ in the Semantic View, whilst `ad_hdlf_sd_lt_salesdocitem` becomes ‘Sales Document Item HDLF Table’. Even the classic SAP table VBAK, which appears in the table schema only under this four-digit abbreviation, is thus given a descriptive name in the SAP Data Dictionary: “Sales Document: Header Data”.

Each logical table in the Semantic View also has structured categories:

• Dimensions: descriptive attributes, such as customer number or sales organisation
• Time Dimensions: time-related attributes for trend and period analyses
• Facts: the actual key figures and measured values
• Named Filters: predefined, reusable filter conditions
• Metrics: aggregated key figures based on the facts

This structure forms the basis for Snowflake Cortex Analyst. Cortex Analyst uses precisely this semantic description to translate natural-language queries from business users into correct SQL queries. Without the clear separation into dimensions, facts and metrics, the agent would not be able to reliably interpret the business logic behind the SAP tables.

The major advantage: All three schemas, the table references and the Semantic View are created fully automatically by the wizard. There is absolutely no need to manually remodel the SAP semantics in Snowflake.

Merging with non-SAP data

In Snowflake, SAP data products are treated just like ordinary tables. This means that SAP and non-SAP data can be easily joined in Snowflake and processed together.

Limitations and pitfalls in practice

However smooth the wizard may seem in an ideal scenario, there are still a few points to bear in mind beforehand:

• Cloud restriction: As mentioned, the cloud binding only applies to the SAP source system and BDC Connect – the hyperscaler and region must match here. This restriction does not apply to the Snowflake side; it can be hosted on a different hyperscaler or in a different region.
• Initial setup requires patience: In practice, it often takes several attempts for the Unique Connector Identifier, invitation link and provisioning to work together properly, particularly if roles or authorisations are initially missing.
• Permissions on both sides: Without the appropriate roles and authorisations, both in SAP BDC and in Snowflake, progress will stall at several points in the process. It is worth clarifying at an early stage who is available as an administrator on both sides.

Conclusion: From concept to a working connection

What was described as an architectural principle in the first article can be implemented in practice in manageable steps. The wizard handles the entire technical modelling process for Snowflake users, from creating the databases and Iceberg tables right through to the semantic view. The actual effort is therefore shifted away from data engineering towards organisational preparation: clarifying permissions, aligning cloud environments and deciding which data products should be made available to which teams.

If you’d like to embark on this journey with an experienced partner: at adesso SE, we support you both with the SAP-side provision of data products and with the Snowflake-side setup, governance and use of Cortex Analyst. Please get in touch.