SAP ECC and SFTP / Flat Files integration

What moves between them

The main flow runs from SAP ECC into SFTP. ml-connector polls SAP ECC on a schedule and reads vendors, purchase orders, GL accounts, and cost centers via RFC_READ_TABLE or BAPI_VENDOR_GETLIST and similar BAPIs. Each batch of records is formatted as CSV or fixed-width flat files and deposited in the inbound folder on the SFTP server. Downstream systems, trading partners, or warehouse loaders poll the SFTP server and process the files. No data flows back from SFTP into SAP ECC; SAP is the authoritative source and SFTP is the distribution channel.

How ml-connector handles it

ml-connector runs an on-premises RFC agent (SAP .NET Connector or Java Connector) on the customer network to establish the connection to SAP ECC. The agent authenticates with HTTP Basic Auth to the SAP system and executes RFC_READ_TABLE to poll vendor and purchase order tables at a configured interval, typically daily or on demand. Each RFC read returns a batch of records; ml-connector transforms them into flat-file schemas (CSV headers, column order, fixed-width position maps) configured per integration and writes the files to the SFTP server using SSH key-pair authentication. The SAP records include a timestamp and a change indicator so ml-connector can detect which records are new or modified since the last poll, avoiding duplicate exports. SFTP has no idempotency key scheme, so ml-connector deduplicates by file hash and line-level checksums before writing to the outbound folder. If an SFTP write fails, ml-connector retries with exponential backoff and logs the failure in the audit trail so the record can be replayed when the SFTP connection is restored. EDI workflows can be triggered by file arrival hooks on the SFTP server or by the downstream system polling the inbound folder on its own schedule.

A real-world example

A mid-sized manufacturing company runs SAP ECC on premises for procurement and finance and has multiple EDI trading partners and a data warehouse that both consume purchase orders and vendor master data. Before the integration, the procurement team exported vendor lists and PO records from SAP by hand each week and manually uploaded them to the trading partner SFTP servers, a process that took two hours and was error-prone. With SAP ECC and SFTP connected, purchase orders and vendor records are exported automatically every night and land in the correct SFTP folders. The trading partners and warehouse load the files on their own schedules, and the procurement team has a full audit trail of what was sent and when. The manual export step is gone, and data is always current.

What you can do

• •Export SAP ECC vendors, customers, materials, purchase orders, and GL accounts as CSV or fixed-width flat files on SFTP on a schedule.
• •Poll SAP ECC via RFC_READ_TABLE or BAPI function modules with an on-premises agent, then write batch files to SFTP without re-keying.
• •Deduplicate records across polls so new exports contain only changed or new records, reducing file size and downstream processing.
• •Detect and log failed SFTP writes so records can be replayed when the connection is restored, with a full audit trail.
• •Authenticate SAP ECC with RFC Basic Auth via the on-premises agent and SFTP with SSH key pairs or password authentication.

Questions

Does SAP ECC need a cloud RFC gateway or IP whitelist to connect to SFTP?

No. ml-connector runs an on-premises RFC agent (SAP .NET Connector or Java Connector) on the customer network, so the agent connects to SAP ECC locally inside the firewall. The agent then initiates outbound HTTPS to ml-connector to poll for scheduled tasks and push records to the SFTP server via the internet. No SAP firewall rules or RFC gateway setup is required.

How does ml-connector deduplicate records when SFTP has no idempotency key?

SFTP has no webhook signature scheme or idempotency key header. ml-connector deduplicates by computing a line-level checksum or hash for each record and tracking which hashes were included in the last export. New exports contain only records with hashes that were not in the prior file, so retries and re-runs produce identical files and do not duplicate vendor or PO records on the SFTP server.

What happens if the SFTP server is down when ml-connector tries to write a file?

ml-connector retries with exponential backoff and logs the failure in the audit trail. When the SFTP connection is restored, the records remain in the queue and can be replayed without manual intervention. The full audit trail shows which records were attempted, when, and whether the writes succeeded, so finance can reconcile SFTP file arrivals with SAP exports.