Getting Data Out of SAP ECC Without Locking Production: RFC, BAPIs and Change Pointers

Last updated: October 2026

Heavily customised SAP ECC systems are both the most valuable and the most fragile data source a company has. Analysts want the data; the SAP team wants nobody near the production database, and both have good reasons.

This article describes how we extracted data from SAP ECC 6.0 for a third-party logistics company, covered in our SAP logistics case study. The company runs six distribution centres for about 200 enterprise clients, its SAP system carried 230 custom ABAP programs and 18 custom tables, and an S/4HANA migration had been estimated at 18 to 24 months and more than $4 million. Project details come from that engagement. The SQL is a simplified illustration written for this article.

Why direct table reads are off limits

The last time a business analyst ran a report directly against the delivery tables LIPS (delivery items) and LIKP (delivery headers) during business hours, it locked a production table for 45 minutes, and three distribution centres could not process outbound shipments. Direct reads through Open SQL or a database connection bypass SAP's application server, and on a heavily customised system they can cause exactly this kind of lock.

Leadership still needed analytics that SAP could not deliver: cross-client shipment consolidation across all 200 clients, and warehouse utilisation across the six centres during the day instead of in an overnight batch report. The requirement was to get data out safely, without touching the 230 custom programs or risking another outage.

Read through the application layer

We used Talend's SAP connectors to call standard BAPIs, such as BAPI_DELIVERY_GETLIST and BAPI_MATERIAL_GETLIST, and custom RFC function modules that the SAP team exposed for the project. RFC calls go through SAP's application layer, which applies SAP's own locking and buffering, and the SAP system showed no noticeable additional load.

Talend 8's SAP component family includes tSAPBapi for calling BAPIs and function modules, tSAPTableInput for reading tables through a function module, and tSAPODPInput for Operational Data Provisioning. Before building on any particular BAPI, check its release status in SE37 or the BAPI Explorer with your SAP team; community examples are not proof that a BAPI is released for customer use.

SAP Note 3255746 and ODP

One licensing change affects extraction tools generally, and it is worth understanding before choosing an approach. SAP Note 3255746 concerns the RFC modules of the ODP Data Replication API. According to vendors who have published its wording, the note was changed in February 2024 to state that their use by customer or third-party applications is not permitted by SAP. On its June 2026 Security Patch Day, SAP also released Note 3748819, which adds a caller identification check to the ODP Data Replication APIs.

Several vendors read the note as applying to ODP over RFC only, leaving BAPIs and other function modules unaffected, but that is their reading and not SAP's text, and SAP itself points customers towards its Datasphere replication for moving SAP data to external targets. Our practical advice is to confirm with your SAP account team how the note applies to the specific tools and function modules you plan to use, and to avoid ODP-based components such as tSAPODPInput on ECC until that is settled.

Pull only what changed

Full extracts of large SAP tables every 30 minutes would have been slow and risky, so we built two incremental patterns.

• Master data (materials, customers, vendors) used SAP change pointers to pull only records modified since the last extraction. SAP Help notes that on NetWeaver 6.x and later, change pointers should be stored in table BDCP2, which replaces the older BDCP and BDCPS tables. Change pointers are switched on globally with transaction BD61 and per message type with BD50, and BD22 reorganises processed pointers.
• Transactional data (deliveries, shipments, warehouse orders) was filtered on the creation date and time fields ERDAT and ERZET and the change date and time fields AEDAT and AEZET.

Incremental loads ran every 30 minutes, with full extracts weekly as a safety net. Change pointers were not configured for some of the custom Z-tables, so those fell back to timestamp-based extraction. Two patterns mean more code to maintain, and it was still far better than full extracts of large tables every half hour.

Bronze keeps SAP's names, silver makes them readable

The bronze layer in Snowflake holds the raw SAP structures with their original column names, such as VBELN, MATNR and WERKS. We kept them because the SAP team needed to validate the data using names they already knew. Business analysts, on the other hand, refused to use it.

The silver layer is where adoption happened. SAP's normalised delivery data, with headers in LIKP, items in LIPS, status in VBUK and partner functions in VBPA, became one deliveries table with readable column names, and the 18 custom tables were joined to the standard ones there. If you skip the silver layer, the analytics team will not use the data.

CREATE OR REPLACE VIEW silver.deliveries AS
SELECT
    h.vbeln      AS delivery_number,
    i.posnr      AS item_number,
    i.matnr      AS material_code,
    i.werks      AS plant,
    i.lfimg      AS delivered_quantity,
    h.erdat      AS created_on,
    h.wadat_ist  AS actual_goods_issue_date,
    s.wbstk      AS goods_movement_status,
    p.kunnr      AS ship_to_customer
FROM bronze.likp h
JOIN bronze.lips i
  ON i.vbeln = h.vbeln
LEFT JOIN bronze.vbuk s
  ON s.vbeln = h.vbeln
LEFT JOIN bronze.vbpa p
  ON  p.vbeln = h.vbeln
  AND p.posnr = '000000'
  AND p.parvw = 'WE';      -- ship-to party at header level

The gold layer holds the KPIs: warehouse utilisation by centre and zone, carrier on-time performance, client shipment volumes with 7, 30 and 90-day trends, and the cross-client consolidation opportunities leadership had asked for. Twelve Tableau dashboards read from it, including a distribution centre operations dashboard on wall-mounted screens at each site.

What we deliberately left alone

We did not migrate SAP's business logic. The 230 custom ABAP programs kept running exactly as before, the pricing engine was untouched, and no SAP configuration changed. The project read from SAP safely and built an analytics layer on top, which is why it could proceed without the S/4HANA programme.

That programme will come eventually. SAP's mainstream maintenance for SAP ERP 6.0 runs until the end of 2027, with optional extended maintenance until the end of 2030. Snowflake's zero-copy connector for SAP Business Data Cloud, generally available since 4 May 2026, shares SAP data products with Snowflake without copying them, but it covers Business Data Cloud, not an ECC system directly, so an extraction layer like this one remains the route for ECC data until then.

Plan for the SAP side to take longest

The project took 22 weeks, and SAP complexity set the pace. Snowflake and Tableau were set up in the first three weeks. The remaining 19 went on mapping SAP's data model, building and testing the RFC extraction jobs, handling SAP-specific cases such as archived data, deleted records and status codes that mean different things in different transaction types, and getting the SAP team's sign-off on data accuracy. When planning an SAP extraction, we allow three to four times as long for the SAP side as for the analytics side.

The result was visibility across all six distribution centres, 30 minutes behind real time instead of a day, a 12% improvement in warehouse utilisation, no measurable impact on SAP performance, and all 230 custom programs left untouched.