Real-Time SAP to Snowflake Integration with Onibex OneConnect
Onibex Team
Last updated: September 2026
What is real-time SAP to Snowflake integration?
Real-time SAP to Snowflake integration is the continuous delivery of SAP ECC and SAP S/4HANA business events to business-named Snowflake tables through Apache Kafka, without polling, without ABAP development, and without custom ETL. Onibex OneConnect handles capture, serialization, schema registration, and Snowflake writes automatically, from the moment a record changes in SAP.
The 4 key points:
- SAP business events — ABAP RESTful Application Programming (RAP), Business Object Repository (BOR), Business Transaction Events (BTE), and Post Processing Framework (PPF) — fire at the application layer the instant a record is created, modified, or deleted, not on a fixed polling schedule
- The Smart Gateway serializes each record into Avro format, registers the schema automatically in the Confluent Schema Registry, and creates the Kafka topic with no manual configuration
- The Onibex Premium Snowflake Sink Connector reads each topic and writes SAP records directly into Snowflake as business-named tables, using the schema already registered, with no separate mapping layer
- The SAP Data Modeler exposes VBAK, VBAP, custom Z-tables, and Core Data Services (CDS) Views through a visual drag-and-drop interface, with field aliases assigned at the source, so Snowflake tables arrive already readable by analysts and Cortex agents
How does OneConnect model SAP tables for Snowflake?
A sales order in SAP ECC and SAP S/4HANA lives across two tables: VBAK (the header: customer, document date, sales organization) and VBAP (the line items: material, quantity, net value). Modeling that relationship for Snowflake starts inside the Onibex SAP Data Modeler, the same tool described in SAP to Kafka integration with OneConnect.
The SAP Data Modeler provides a visual interface where VBAK and VBAP are added, connected by dragging and dropping, and field aliases are assigned. NETWR becomes "net value." KUNNR becomes "customer." MATNR becomes "material." No SQL, no ABAP function modules, and no developer dependency for every schema change.
The output is a data product: a complete business package with its tables, relationships, and aliases resolved. Once built, it is reusable for any future destination (Databricks, IBM watsonx.data, a dashboard, Snowflake) without rebuilding the SAP logic from scratch.
Data product design for Sales Order in the SAP Data Modeler
No special configuration is needed on the SAP side for the data to land cleanly in Snowflake. The SAP Data Modeler produces a structured, destination-agnostic data product. The same model that feeds Snowflake today can feed Databricks or IBM watsonx.data tomorrow without touching the SAP configuration again.
The SAP Data Modeler also supports custom Z-tables and CDS Views directly, so custom fields and existing CDS Views built for internal reporting are pulled in without re-implementing that logic inside the tool.
How do SAP business events guarantee real-time delivery?
The SAP Data Modeler resolves the structure of the data. Business events resolve the timing.
Every time a sales order is created, modified, or deleted in SAP, an application-layer business event tied to that entity fires. On SAP ECC and SAP S/4HANA installations up to 2022, this runs on BOR Events. On SAP S/4HANA 2023 and later, it runs on RAP Events. The result is the same in both cases: the modified record travels outbound over an HTTP Remote Function Call (RFC) destination of Type G to the Smart Gateway the instant the change is committed, without waiting for a scheduled extraction job.
This is the property that ensures data later consumed by Snowflake, a dashboard, or a Cortex agent is current by design. The change is already in transit from the moment it is committed in SAP.
The same mechanism governs deletes. A delete in SAP triggers the same application-layer business event as a create or update. Delete propagation is part of the design at the source, not a step added afterward in the pipeline.
What does the Smart Gateway do between SAP and Kafka?
Once VBAK and VBAP are modeled and connected to their business events, the Smart Gateway takes over. It performs four steps automatically:
- Receives the delta from SAP. The modified record, whether an insert, update, or delete, arrives at the Smart Gateway at the moment the business event fires, pushed over the RFC Type G destination.
- Serializes the record into Avro format. Avro enforces a defined type for every field and validates each record before writing. This prevents a field from arriving as a string in one record and null in the next, the kind of inconsistency that breaks a downstream pipeline without warning.
VBAK topic message serialized in Avro
- Registers the schema in the Confluent Schema Registry. The schema for each data product is generated automatically from the metadata the SAP Data Modeler already holds about VBAK and VBAP. No manual schema authoring is required.
Avro schema registry for the VBAK topic
- Creates the Kafka topic automatically. The topic name is based on the entity, and the topic is ready from the moment the data product is activated on Apache Kafka.
From that point forward, every change to the sales order writes a new Avro record to the topic, with the schema enforced by the registry.
How does the Onibex Premium Snowflake connector write to Snowflake?
The sales order topic is picked up by the Onibex Premium Snowflake Sink Connector, configured directly from the Smart Gateway alongside the same catalog of pre-built destinations for Databricks, IBM watsonx.data via Presto, HANA, SQL Server, PostgreSQL, DB2, BigQuery, Amazon S3, Google Cloud Storage, Microsoft Fabric, and Iceberg.
Selecting the Snowflake connector in the Smart Gateway's connector catalog
Configuring it follows the same short wizard used for every other destination: a JDBC connection URL pointing at the Snowflake account, the connection user and password, the Onibex license, and either an explicit topic name or a topics regex. Nothing about the SAP side changes because SAP communicates only with Kafka, not with Snowflake directly.
The connector reads the Avro records from Kafka and writes them into Snowflake using the same schema the Smart Gateway already registered in the Schema Registry. Snowflake does not need to infer the structure of the sales order; it reads the schema directly from the registry.
| Step | What happens | Configured by |
|---|---|---|
| SAP Data Modeler | VBAK and VBAP joined, business aliases assigned | Analyst or architect, no ABAP |
| Business event | Change captured at application layer, sent over RFC Type G | Automatic on every commit |
| Smart Gateway | Avro serialization, schema registration, Kafka topic creation | Automatic |
| Snowflake connector | Topic consumed, business-named table written in Snowflake | Configured from Smart Gateway UI |
Where does SAP data land inside Snowflake?
What arrives in Snowflake is not a raw dump of SAP tables. Because the aliasing happened inside the SAP Data Modeler, the table already carries the business name: ORDER_ITEM instead of VBAP, and columns already read as sales_doc, client, item, material, and item_descr instead of vbeln, mandt, posnr, matnr, and arktx.
Browsing the OnibexDemo_DEV_ORDER_ITEM table from Snowflake's Database Explorer
The same Snowflake catalog also holds the rest of the sales order's related entities arriving the same way: billing header and item, customer master data, and the sales document's business and partner data, each modeled once in the SAP Data Modeler and streaming continuously from the moment it changed in SAP.
How do Snowflake Cortex agents use SAP data from OneConnect?
Because the data lands in Snowflake as governed, business-named tables rather than raw SAP exports, it is immediately usable by Snowflake's own Cortex AI Studio: Cortex Analyst for building semantic models, Cortex Search for search services over the data, and Cortex Agents for agents that can reason over it directly.
Snowflake Cortex AI Studio, ready to build agents on top of the SAP data streamed in
None of the Cortex tools need to know anything about SAP's internal table structure. By the time a sales order reaches Snowflake, it already reads like a business table, which is exactly the starting point Cortex Analyst and Cortex Agents need to reason correctly without guessing at what VBAK.NETWR means.
The path from modeling to query looks like this: the SAP Data Modeler removes the need for an ABAP developer for every new entity or custom Z-table. The business event removes the need to poll SAP on a fixed schedule. The Smart Gateway removes the need to build Kafka infrastructure, schemas, and topics by hand. The Snowflake connector removes the need for a custom Kafka-to-Snowflake integration. Remove any one of those steps and the work becomes manual again.
Frequently asked questions
Does real-time SAP to Snowflake integration require ABAP development?
No. The SAP Data Modeler provides a visual drag-and-drop interface for defining the data product, and the Smart Gateway automatically manages Avro schemas, Schema Registry entries, and Kafka topic creation. No ABAP function modules or custom extractors are written at any step of the OneConnect flow.
Why does the Snowflake table already use business names instead of SAP field names?
Because the aliasing happens in the SAP Data Modeler before any data moves. VBAP becomes ORDER_ITEM, and columns like MATNR become "material," so the table landing in Snowflake is already readable by analysts and Cortex agents without a separate translation layer.
Do Snowflake Cortex agents need a separate semantic layer to use this data?
Less than they would starting from raw SAP tables. Because the table is already named and typed in business terms, Cortex Analyst and Cortex Agents have a much cleaner starting point. Defining a formal semantic model in Cortex Analyst is still a separate step, but the naming and typing work that would normally occupy most of that effort is already done.
Does this only work with sales orders?
The sales order is the example in this post, but the same flow applies to any data product modeled in the SAP Data Modeler: billing documents, material masters, customers, vendors, and any Z-table or CDS View in the SAP installation.
What if I want a different destination instead of Snowflake?
The same Smart Gateway wizard is used for every destination in the catalog: real-time SAP to Databricks integration, real-time SAP to IBM watsonx.data integration, HANA, SQL Server, PostgreSQL, DB2, BigQuery, Amazon S3, Google Cloud Storage, Microsoft Fabric, and Iceberg. Only the connector selected and its connection details change; the SAP Data Modeler and business event setup stay exactly the same.
What OneConnect does not do
OneConnect does not access the SAP database layer. All capture happens through application-layer business events (RAP, BOR, BTE, PPF) pushed outbound over an HTTP RFC destination of Type G to the Smart Gateway. No direct database access is involved on the SAP side.
OneConnect does not write to Snowflake directly from SAP. SAP business events travel to Kafka via the Smart Gateway, and the Snowflake Sink Connector handles the write. Snowflake is the destination, not the ingest target for SAP events.
OneConnect does not support SAP S/4HANA Cloud Public Edition. The supported systems are SAP ECC, SAP S/4HANA, and SAP S/4HANA Cloud Private Edition.
OneConnect does not require a separate Kafka Connect deployment. The Snowflake connector is configured and managed from the Smart Gateway interface, with no additional infrastructure to operate.
About Onibex
Onibex builds real-time data streaming and agentic AI solutions for SAP environments. Onibex OneConnect captures business events from SAP ECC and SAP S/4HANA through application-layer mechanisms (RAP, BOR, BTE, PPF), pushes them over an RFC destination of Type G to the Smart Gateway, and streams them to Apache Kafka, Confluent Cloud, Databricks, Snowflake, IBM watsonx.data, and other targets, with topics and Schema Registry entries created automatically and schema evolution supported.
Onibex ASK (Agentic Semantic Knowledge) provides a semantic layer for querying SAP data through natural language agents. Source code for OneConnect is available at the oneconnect-docs GitHub repository. Learn more at onibex.com.