Does ml-connector read from SAP ECC or write to it?

ml-connector reads from SAP ECC only. It polls vendors, invoices, purchase orders, GL accounts, and cost centers via RFC/BAPI and writes them into Snowflake. The reverse direction is read-only; Snowflake is a data warehouse and does not push data back to SAP ECC.

Why is an on-premises RFC agent required?

SAP ECC exposes data through RFC/BAPI function modules and OData at the instance URL, both of which can only be called from a host on the customer network. RFC/BAPI calls cannot originate from the cloud, so ml-connector deploys an agent running SAP .NET Connector or Java Connector on a machine with direct network access to SAP ECC. The agent polls the records you specify and sends them to Snowflake over HTTPS.

How does the integration handle SAP ECC's RFC concurrency limits and Snowflake's rate limiting?

SAP ECC typically supports 10 to 50 concurrent RFC calls before returning SYSTEM_FAILURE or COMMUNICATION_FAILURE exceptions; ml-connector respects this by issuing polled reads in serial or small batches, not parallel streams. Snowflake returns HTTP 429 when rate-limited. ml-connector backs off and retries with exponential jitter, so temporary throttles do not cause data loss.

SAP ECCSnowflake

SAP ECC and Snowflake integration

SAP ECC runs production, procurement, and finance on-premises. Snowflake stores data in the cloud. Connecting the two moves SAP ECC master data and transaction records into Snowflake, where finance teams can query and analyze them without tying up the ERP. Vendor changes, invoices, purchase orders, and GL accounts replicate on a schedule, keeping Snowflake's views current with what is in SAP ECC. Every record carries its source transaction, so audit trails are complete.

How SAP ECC works

SAP ECC exposes master data and transactional records through RFC/BAPI function modules (BAPI_VENDOR_GETLIST, BAPI_VENDOR_GETDETAIL, BAPI_ACC_DOCUMENT_POST, BAPI_PO_GETDETAIL1, BAPI_GL_ACC_GETLIST, and others), OData v2 REST via SAP Gateway at the instance URL with HTTP Basic Auth, or IDoc XML over HTTP configured by the customer SAP Basis team. An on-premises agent running SAP .NET Connector or Java Connector is required because RFC/BAPI calls cannot originate from the cloud; the agent sits on the customer network with network access to SAP ECC. Polling is performed on demand or on a scheduled interval via RFC_READ_TABLE; no native webhook registry exists, though outbound IDoc push is available with customer configuration.

How Snowflake works

Snowflake is a cloud data warehouse with user-defined tables for vendors, invoices, purchase orders, GL accounts, and dimensions. It exposes data through SQL API (https://<account_identifier>.snowflakecomputing.com/api/v2/statements) and REST APIs, both supporting JSON request/response. Authentication uses Key Pair Authentication with RSA private key and JWT, or Programmatic Access Token for long-lived bearer credentials. Snowflake is a data warehouse, not an ERP, so all finance objects are user-defined tables created by the customer or ml-connector during setup. It is pull-only; no webhooks push data back out to external systems.

What moves between them

The main flow is SAP ECC into Snowflake. Vendors, purchase orders, invoices, and GL account masters replicate on a schedule controlled by ml-connector. SAP ECC serves as the source of truth; Snowflake receives the records and stores them in designated tables. Cost center masters and GL account hierarchies replicate in the same direction so Snowflake queries can join transactional records to their dimensions. The reverse direction is read-only; ml-connector does not write back to SAP ECC.

How ml-connector handles it

ml-connector runs an on-premises RFC agent on the customer network with direct SAP ECC network access. The agent calls RFC_READ_TABLE or targeted BAPIs (BAPI_VENDOR_GETLIST, BAPI_VENDOR_GETDETAIL, BAPI_PO_GETDETAIL1, BAPI_GL_ACC_GETLIST, BAPI_EMPLOYEE_GETDATA) to extract records, authenticating with HTTP Basic Auth (username and password) configured in the agent. The agent polls on the schedule you set, respecting SAP ECC's RFC concurrency limits (typically 10 to 50 concurrent calls). Each SAP ECC record is mapped to a Snowflake SQL INSERT or UPDATE statement. ml-connector uses Snowflake Key Pair Authentication, presenting the RSA private key and JWT token on each SQL request. Snowflake has no documented rate limit, but returns HTTP 429 when throttled; ml-connector backs off and retries. Because SAP ECC master data changes slowly, polling can run hourly or daily. Every vendor, invoice, and GL account record includes its SAP ECC transaction ID, timestamp, and audit flags, so Snowflake queries can trace any record back to its source and timestamp any downstream finance report.

A real-world example

A mid-sized industrial company runs SAP ECC on-premises for procurement, GL, and cost centers across three plants. The finance team wants to build analytics on invoice approvals, vendor spend by GL account, and cost center allocation without bogging down the ERP server. Before the integration, analysts exported SAP ECC data into Excel on a monthly cycle and rebuilt their reports by hand. After connecting SAP ECC to Snowflake, vendors and invoices replicate every 4 hours, GL accounts and cost centers sync once a day, and the finance team queries Snowflake tables in Tableau or Looker to see vendor spend trends, GL allocation by plant, and year-to-date cost center actuals. Month-end close includes a Snowflake query showing all invoices posted in the period, their GL accounts, and their cost centers, with drill-back to SAP ECC transaction IDs.

What you can do

Replicate SAP ECC vendors, invoices, purchase orders, and GL account masters to Snowflake tables on a polling schedule you control.
Authenticate with SAP ECC via RFC/BAPI with the on-premises agent, and Snowflake via Key Pair Authentication.
Map SAP ECC cost centers and GL accounts to Snowflake dimensions so finance queries can slice spend by plant, department, and account.
Deploy the RFC agent on the customer network so SAP ECC data never traverses the public internet.
Maintain full transaction IDs and timestamps in Snowflake so every vendor and invoice record can be audited back to SAP ECC.

Questions

Does ml-connector read from SAP ECC or write to it?: ml-connector reads from SAP ECC only. It polls vendors, invoices, purchase orders, GL accounts, and cost centers via RFC/BAPI and writes them into Snowflake. The reverse direction is read-only; Snowflake is a data warehouse and does not push data back to SAP ECC.
Why is an on-premises RFC agent required?: SAP ECC exposes data through RFC/BAPI function modules and OData at the instance URL, both of which can only be called from a host on the customer network. RFC/BAPI calls cannot originate from the cloud, so ml-connector deploys an agent running SAP .NET Connector or Java Connector on a machine with direct network access to SAP ECC. The agent polls the records you specify and sends them to Snowflake over HTTPS.
How does the integration handle SAP ECC's RFC concurrency limits and Snowflake's rate limiting?: SAP ECC typically supports 10 to 50 concurrent RFC calls before returning SYSTEM_FAILURE or COMMUNICATION_FAILURE exceptions; ml-connector respects this by issuing polled reads in serial or small batches, not parallel streams. Snowflake returns HTTP 429 when rate-limited. ml-connector backs off and retries with exponential jitter, so temporary throttles do not cause data loss.

Connect SAP ECC and Snowflake

Free to use. Add your credentials, ping your real systems, and see if we fit.

Get started