I wanted to know how far the cheap path goes. SAP already exposes a perfectly good remote-function interface; DuckDB already ingests at memory bandwidth. What if ABAP just called out into DuckDB — no extension inside SAP, no SLT, no staging files — and we made the read fast enough to matter?

So I built it — two days, with Claude Code as the pair programmer. The result is erpl-rev, and on a throwaway SAP developer trial (single host, over loopback) it replicated 10,000,000 rows of a 400-column BSEG-shaped table in about a minute. It's an early release — a research prototype we're opening up, not an SLT replacement yet — but the numbers were enough to convince me the cheap path is real. Here is the story, the tools, and the numbers.

What erpl-rev is​

erpl is a DuckDB extension that calls into SAP. erpl-rev is the inverse: a small standalone C++ server that registers a PROGRAM_ID at the SAP gateway, so your ABAP calls out to it —

CALL FUNCTION 'Z_DUCKDB_QUERY' DESTINATION 'ERPL_REV'
  EXPORTING iv_sql       = 'SELECT count(*) AS n FROM sflight'
  IMPORTING ev_columns   = lv_cols       " JSON: [{name, type}, …]
            ev_rows      = lv_rows       " JSON: [{…}, …]
            ev_row_count = lv_cnt
            ev_error     = lv_err.

— and DuckDB runs behind the call. Two things, in equal measure:

• Query — send DuckDB SQL from ABAP and get typed rows back (or an ALV grid via an in-GUI console). Joins, window functions, Parquet scans over SAP data, and federation: join a SAP slice against a cloud Iceberg/Parquet/Postgres table in one statement.
• Replicate — bulk-load a table, CDS view (including WITH PARAMETERS), or BW / HANA calculation view into a typed DuckDB table, a Parquet dataset, DuckLake, or an attached warehouse.

The two compose, and that is where it gets interesting. Replicate a SAP slice into DuckDB, then — in the same session — join it against data that never lived in SAP and hand the answer back to ABAP. Here are sales orders, freshly replicated, joined to a demand forecast sitting in Iceberg on S3, in one statement run from ABAP via Z_DUCKDB_QUERY (or the in-GUI console):

SELECT o.vbeln, o.kunnr, o.netwr, f.predicted_units
FROM   vbak o                                       -- SAP, replicated into DuckDB
JOIN   iceberg_scan('s3://lake/demand_forecast') f  -- never touched SAP
  USING (matnr);

The rows come back to your ABAP program as a typed table. A cross-system join like that — live SAP data against an open-format table in the lakehouse — is something the SAP stack cannot do on its own.

The part that matters for the nightly-BSEG problem: there is nothing to install inside SAP. No DuckDB extension, no DDIC structures, no SLT/SDI/Data Services. You import a transport (a function group plus a report) and run the external server next to your gateway. Payloads travel as plain JSON / binary sXML over scalar RFC parameters, so the same generic interface carries any table, view, or query result.

How it got built: Claude Code with a real CLI​

I did not write most of this by hand. I ran Claude Code in a terminal and gave it the tools a SAP developer actually uses — and the interesting part is which tools made the loop work.

The SAP system was a local A4H "ABAP Cloud Developer Trial" docker container, with the gateway registration ACL opened so an external server could register. The ABAP side — the function group, the Z_DUCKDB_* function modules, the replication classes, the end-user report — Claude wrote and deployed entirely through erpl-adt, our CLI for the SAP ADT REST API:

When it came time to measure, Claude wrote a small ABAP classrun, deployed it, ran it, and read the numbers straight back from the same shell — no Eclipse, no copy-paste:

$ uvx erpl-adt source write ZCL_ERPL_REV_PERF --file zcl_erpl_rev_perf.abap --activate
Activated: /sap/bc/adt/oo/classes/zcl_erpl_rev_perf

$ uvx erpl-adt object run ZCL_ERPL_REV_PERF
cols=50 part_col=BELNR rows=10000000
RESULT jobs=2 seconds=106 aggregate_rps=94340  per_worker_rps=47170
RESULT jobs=4 seconds=65  aggregate_rps=153846 per_worker_rps=38461
RESULT jobs=5 seconds=60  aggregate_rps=166667 per_worker_rps=33333

Those RESULT lines are the chart below — the closed loop is the whole trick. Claude writes ABAP, deploys it with erpl-adt, runs the classrun, reads the printed result, and decides what to change next. The C++ server side was the same idea against a different surface: edit, cmake --build, run the Catch2 suite against real DuckDB, read the output, iterate. When a number looked wrong, Claude could go measure instead of guess.

The toolset, deliberately small and orthogonal:

• Claude Code — the pair programmer, running real shell commands.
• erpl-adt (via uvx, no install) — deploy and run ABAP from the terminal.
• A local A4H docker trial — a disposable, real SAP system to build against.
• DuckDB 1.5.3 — the engine behind every call.
• The SAP NW RFC SDK — the registered-server plumbing.
• CMake + vcpkg, GitHub Actions — build and CI.

One file to ship​

A SAP RFC server has an awkward dependency footprint: it links libsapnwrfc, which in turn dlopens a set of ICU libraries by name, plus we link libduckdb. The usual answer is "ship a folder and set LD_LIBRARY_PATH." For a tool you want people to actually try, that is friction.

So erpl-rev ships as one self-extracting binary per platform. The trick is borrowed from how erpl bundles its SDK, adapted for a standalone executable: the real server and all its runtime libraries are appended to a tiny launcher as a tar payload with a small footer. On first run the launcher locates itself, unpacks the payload to a per-version temp dir, points the loader at it, and execs the server. The user downloads a single file and runs it — the SAP SDK and DuckDB ride along inside.

Claude wrote that launcher to be portable in one pass (Linux, macOS, Windows), and the GitHub Actions release pipeline builds all three on every tag — pulling the proprietary SAP SDK from S3 via GitHub OIDC, bundling, and smoke-testing the result by running --help with no external libraries on the PATH. The macOS and Windows builds I could not test locally; CI built and verified them, and we fixed the two real portability issues (an MSVC <unistd.h> include, a Windows DLL-naming assumption) straight from the CI logs.

The numbers​

The point of the exercise was throughput, so we measured it on the live trial. The source is ZWIDE_BSEG, a synthetic 400-column BSEG-shaped table filled to 10,000,000 rows; the run replicates a 50-column slice, partitioned on the document number (BELNR) across parallel background-job workers, over loopback.

Peak ~167,000 rows/s — ten million rows in a minute. A few things make that possible, and none of them is exotic:

• Bounded memory. Each worker reads its key range package-wise with keyset pagination (one fresh statement per page, default 50,000 rows), so peak RAM is set by the batch, not the table. A 100M-row load uses the same memory as a 100k-row one.
• Vectorized ingest. Each package lands via a DuckDB Appender into a staging clone, then one INSERT … SELECT with casts — about 230× faster than the naive row-by-row path (the comparison lives in test/bench_ingest.cpp).
• Parallel by background job. Workers stream disjoint key ranges concurrently into one target; the coordinator builds the primary key once at the end.
• Provably faithful. A diff harness compares the DuckDB target against the SAP source cell by cell (every row × column for SFLIGHT; per-row md5 for the wide table), plus a negative control that corrupts one value to prove the check actually detects it.

Two honest caveats. The scaling is sublinear — per-worker throughput tapers from 47k to 33k as workers contend for the SAP read side, and this trial caps out at five batch work processes. And these are loopback numbers on a single-host dev container; a real SAP-over-network deployment will differ. The conservative floor we quote is ≥10,000 rows/s per worker; the headline is what the hardware actually did.

Get it​

erpl-rev is open source under the Business Source License 1.1, and the first release — v2026.06.03 — ships the self-extracting binaries:

# Linux
curl -LO https://github.com/DataZooDE/erpl-rev/releases/latest/download/erpl-rev-linux-amd64.tar.gz
tar xzf erpl-rev-linux-amd64.tar.gz
./erpl-rev-linux-amd64 --help     # self-extracts the SAP SDK + DuckDB; nothing else to install

The README covers the one-time SAP side (import the transport, register the destination) and the security guide covers the gateway ACL, SNC, and the least-privilege RFC user you'll want in production.

It started as a question — how fast can the cheap path go? — and the answer turned out to be: fast enough that "just call out into DuckDB" is a real option for moving SAP data, not a toy. The repo is DataZooDE/erpl-rev. Tell me what you replicate with it.

Last week the forecasting team at our Mittelstand walked away with something they'd never had: a fresh, validated, DuckDB-native view of every order line and customer record they cared about, no warehouse landing in sight. Latency under five minutes, anomalies caught at the gate. Good ergonomics. Good numbers.

Then the AI engineer asked the question that always comes next.

"Great. How does the agent reach this?"

The forecasting agent isn't a Python notebook anymore. It's an LLM the operations team is supposed to talk to in plain English. It needs to call the data, not be batch-fed it. And — the twist that ended up being the actual interesting part of this story — when the agent finds something wrong with the data, the operations team would like the agent to fix it.

This post is how we got both halves of that working.

flAPI: one SQL template, two surfaces​

We built flAPI for exactly this moment. It compiles a single Mustache-templated SQL snippet into two consumer surfaces at the same time: a REST endpoint that the dashboard team can hit, and an MCP tool that the agent can call. Same SQL, same parameter validation, same cache.

The endpoint that mattered to the forecasting team was "high-anomaly customers, optionally filtered by segment, optionally filtered by date". Here's the configuration. The SQL template lives in customers-with-anomalies.sql; the YAML describes how that template becomes an API:

# customers-rest.yaml
url-path: /customers/anomalies

request:
  - field-name: segment
    field-in: query
    description: Customer market segment
    required: false
    validators:
      - type: enum
        allowedValues: [AUTOMOBILE, BUILDING, FURNITURE, HOUSEHOLD, MACHINERY]
  - field-name: since
    field-in: query
    description: Earliest order date
    required: false
    validators:
      - type: date
        min: "2024-01-01"

connection: erpl_sap_prod
template-source: customers-with-anomalies.sql

with-pagination: true

cache:
  enabled: true
  table: customers_anomalies_cache
  schema: analytics
  schedule: 5m
  primary-key: [customer_id]
  cursor:
    column: last_seen
    type: timestamp

The companion MCP tool file is half the size, and it shares the same template:

# customers-mcp-tool.yaml
mcp-tool:
  name: customer_anomalies
  description: |
    Return customer accounts with recent anomalous order behaviour.
    Use this to investigate forecasting outliers.
  result-mime-type: application/json

{{include:request from customers-rest.yaml}}
connection: erpl_sap_prod
template-source: customers-with-anomalies.sql

DuckLake caches the materialised result for five minutes; the underlying SQL is the same view we built in Part 1. The REST clients see paginated JSON. The MCP clients see a typed tool. Nobody has to write the query twice.

The agent calls the tool​

With the flAPI MCP server registered, the agent's view of SAP is a list of named tools, each with a schema describing its parameters and result type. From the agent's side, the conversation is unremarkable — exactly the goal:

Operations lead: Which customers had unusual ordering behaviour in the last week?

Agent: (calls customer_anomalies(since="2026-05-22") via MCP) Twelve accounts came back with non-trivial anomaly scores. Eleven look like legitimate one-off events — bulk orders for trade fairs, a new construction project. One looks systemic: customer 100482 has a recurring anomaly every Monday morning at 06:14, and the affected rows all carry kdgrp = 9999, which isn't one of your real pricing groups.

The agent didn't ingest a CSV. It didn't load a Python kernel. It called a typed tool and read JSON. The data was four minutes old.

The plot twist: same anomaly, every Monday​

Operations could have stopped there. They didn't. The data steward asked the agent to look harder, and the agent — having read both Part 1's anofox-tabular query and the flAPI tool schema — formed a hypothesis.

Agent: The Monday-06:14 timing suggests a scheduled batch job. The pricing group 9999 is consistent across all affected rows, which is consistent with a default-value assignment in ABAP code. Want me to look?

What happens next is the part most "SAP plus AI" articles never reach. The agent is connected to a second MCP server — erpl-adt. That gives it tools to read, modify, and activate ABAP source on the live SAP system. The MCP client config is three lines:

{
  "mcpServers": {
    "sap_data":    { "command": "flapi", "args": ["serve", "--mcp", "--config", "flapi.yaml"] },
    "sap_abap":    {
      "command": "erpl-adt",
      "args": ["mcp", "--host", "sap-prod.example.com", "--port", "44300", "--https"],
      "env": { "SAP_PASSWORD": "${SAP_PASSWORD}" }
    }
  }
}

The forecasting agent now has two surfaces: one to read business data (flAPI), one to read and modify business logic (erpl-adt). It also has the safety property we cared about most: it can only do what an actual SAP user could do, governed by the same authorizations.

erpl-adt: the agent reads ABAP​

The agent's first move was the same one a human developer would make: search for the scheduled job that runs on Mondays.

# In the agent's tool-use trace, these are MCP tool calls;
# we show the equivalent CLI for clarity.
erpl-adt search "*MONDAY*" --type PROG --max 20
erpl-adt search "PRICING_GROUP_DEFAULT" --max 20

Search returns a handful of programs and one include. The agent grabs the source:

erpl-adt source read \
  /sap/bc/adt/programs/programs/zr_weekly_price_seed/source/main

The offending include is small. Halfway down, a line that doesn't belong:

" Fallback to placeholder when customer's pricing group is empty.
" TODO(rb): remove after 2019 migration is finished.
IF lv_kdgrp IS INITIAL.
  lv_kdgrp = '9999'.
ENDIF.

Seven years of inertia. The agent proposes the obvious change — read the customer's real pricing group from KNVV instead of defaulting — drafts the patched ABAP, and asks for approval. The operations lead says yes.

What the agent does next is the bit we want every reader to imagine doing on their own systems:

# 1. Write the patched source. Lock + write + unlock is atomic;
#    --activate folds in the activation step.
erpl-adt source write \
  /sap/bc/adt/programs/programs/zr_weekly_price_seed/source/main \
  --file patched.abap \
  --activate

# 2. Run the ABAP Unit tests that cover the include.
erpl-adt test ZR_WEEKLY_PRICE_SEED

# 3. Run ATC quality checks against the team's variant.
erpl-adt check ZR_WEEKLY_PRICE_SEED --variant DEFAULT

# 4. Create a transport with a sensible description.
erpl-adt transport create \
  --desc "Remove 2019 kdgrp=9999 fallback; read from KNVV instead" \
  --package ZFI_PRICING

Every one of those commands is a real MCP tool the agent invoked. Every one returned structured JSON the agent could reason about. The transport landed in the operations lead's request list with the agent's description attached — for review and release by a human.

Closing the loop​

The next Monday morning, the flAPI dashboard for customer 100482 was empty. So were the rest of the systemic anomalies. The agent's tool call returned the same JSON shape it always had; the underlying SAP data simply no longer contained the bad rows the agent had been pointing at, because the ABAP job that wrote them was gone.

This is the architecture, drawn as a loop:

• SAP holds the ledger of record.
• ERPL and ERPL-Web stream from it into DuckDB.
• anofox-tabular filters out the rows that shouldn't reach the model.
• flAPI publishes the clean view as REST and MCP.
• The agent reads it, reasons about it, and — when it finds a problem — uses erpl-adt to fix the source.

No warehouse landed any data. No Eclipse session was open. No JVM ran. Every step happened in the agent's own MCP-driven tool loop, governed by real SAP authorizations.

Why this matters​

Most of the "SAP + AI" stories shipping today stop at retrieval-augmented generation: the model reads SAP data and produces a text answer. That's table stakes now. The interesting frontier is whether the model can change SAP — read ABAP, propose a patch, run tests, file a transport, and hand a reviewable artifact back to a human.

The forecasting team got both. The dashboards run on a four-minute-fresh view of orders and customers. The agent answers operations questions in plain English. And once a week, on average, the agent files a transport that fixes something nobody had noticed.

That's the stack we wanted from the beginning. DuckDB-native, secret-managed, no warehouse, no JVM, no Eclipse. Just SQL on one side, an LLM on the other, and a closed loop in the middle.

If you want to build it yourself, the docs start here for ERPL, here for flAPI's MCP mode, and here for erpl-adt. If you want us to help, book a demo.

The reason: their nightly ETL job runs at 02:00 and finishes around 04:00, by which point the model trains on data that's already half a day old. By the time the forecast reaches the procurement system at 08:00, it's reasoning about a world that existed fourteen hours ago. When the CFO asks why the model recommended ordering more of an item that just sold out at lunchtime, nobody has a good answer — because the data the model saw never knew the lunchtime existed.

The fix isn't a better ETL. The fix is removing the ETL.

Why "real-time" usually means "20 minutes ago"​

The default SAP analytics architecture is three boxes: SAP, a warehouse, a BI layer on top of the warehouse. Each box exists because someone, at some point, decided the next box couldn't talk to the previous one directly. That assumption was true in 2008. It's been getting less true every year since DuckDB shipped.

When you actually trace the latency, the SAP system isn't the slow part. RFC reads on a healthy ECC system come back in seconds. ODP delta extracts on a properly subscribed data source return whatever changed since the last cursor position, often in under a minute. The latency lives in the middle box — the warehouse you assumed you needed because everyone else has one.

What if you didn't have one? What if your AI agents and your forecasting models queried SAP through a thin SQL layer that fans out to RFC, ODP, Datasphere, and Business Central — and only materialized when it actually helped? That's the stack we built ERPL for.

Layer 1: ERPL pulls SAP ECC / S/4HANA live​

The starting point is a DuckDB secret. ERPL stores SAP credentials the same way DuckDB stores S3 or Postgres credentials — once, declaratively, with the connection metadata attached. From then on, every ERPL function uses the secret implicitly.

INSTALL 'erpl' FROM 'http://get.erpl.io';
LOAD 'erpl';

CREATE SECRET sap (
  TYPE sap_rfc,
  ASHOST 'sap-prod.example.com',
  SYSNR  '00',
  CLIENT '100',
  USER   'erpl_reader',
  PASSWD 'redacted',
  LANG   'EN'
);

PRAGMA sap_rfc_ping;

PRAGMA sap_rfc_ping raises immediately if anything is misconfigured, so the credentials check is one statement, not a 200-line connection class.

With the secret in place, you read SAP tables as if they were DuckDB tables — including pushdown for WHERE and column selection. The forecasting team needs recent sales-order headers (VBAK) for one of their sales organizations. ERPL's sap_read_table has predicate pushdown enabled, so a regular SQL WHERE clause is pushed all the way down into the RFC call. You don't write a special filter parameter; you write SQL:

SELECT VBELN, ERDAT, KUNNR, NETWR, WAERK
FROM sap_read_table('VBAK', MAX_ROWS => 5000)
WHERE ERDAT >= DATE '2026-05-01'
  AND VKORG = '1000';

That executes in seconds against a live ECC instance. The MAX_ROWS is a guardrail; pushdown narrows the read further. For column-heavy tables you can also pass COLUMNS => ['VBELN', 'ERDAT', 'KUNNR'] and let RFC drop the rest before bytes leave SAP.

For incremental loads, RFC is the wrong tool — that's what ODP is for. ODP cursors are server-side state: SAP remembers what you've already seen per subscriber. The first call to sap_odp_read_full for a given (context, data source) returns a FULL snapshot and opens the cursor. Every subsequent call returns only the DELTA since the last position. There is no per-call mode flag and no manual cursor management — the server tracks it.

-- First call: SAP returns the full snapshot and opens the cursor.
-- Every subsequent call: only the delta since the last position.
SELECT *
FROM sap_odp_read_full('BW', 'VBAK$F', threads => 4);

Run that on a cron every few minutes and you have a continuously-fresh sales-order stream landing directly in DuckDB, with zero ETL code between SAP and your model.

Layer 2: ERPL-Web closes the cloud gap​

Not every SAP system is on-prem. Some of the forecasting team's data lives in Microsoft Dynamics 365 Business Central (the spin-off subsidiary uses BC instead of S/4HANA), and the corporate planning numbers are in SAP Datasphere. We built ERPL-Web so the same DuckDB session can reach both without changing the SQL contract.

For Business Central, attach the company as if it were a database:

INSTALL 'erpl_web' FROM 'http://get.erpl.io';
LOAD 'erpl_web';

ATTACH 'CRONUS Germany AG' AS bc (TYPE business_central);

-- Now the BC entities look like regular tables
SELECT no, name, balance_due
FROM bc.customer
WHERE balance_due > 0
ORDER BY balance_due DESC
LIMIT 20;

ATTACH does the OData V4 metadata discovery once. After that, every entity in the company shows up as a DuckDB table, with predicate pushdown via the OData $filter clause.

For Datasphere, the read function speaks the same SQL dialect:

SELECT *
FROM datasphere_read_relational('PLANNING_SPACE', 'V_DEMAND_FORECAST')
WHERE month = '2026-05';

The forecasting team doesn't care that one read goes through SAP-managed OAuth2 and the other goes through RFC over an SSH tunnel. Same SELECT *, same DuckDB result set. That uniformity is what lets the data plane disappear.

Layer 3: anofox-tabular gates the stream​

Live data is fast, but live data is also dirty. The forecasting model needs the dirty rows filtered out before it sees them, not flagged in a Monday-morning report. anofox-tabular is a DuckDB extension that runs the validation in SQL, vectorized, in-process — no external service call, no Python ML pipeline.

Take the customer master. Two checks the team runs every load: are the customer email addresses syntactically valid, and are the German VAT numbers well-formed for the country they claim? Emails live in ADR6, joined to KNA1 via ADRNR, so the pattern is one CTE plus two calls:

LOAD anofox_tabular;

WITH customers AS (
  SELECT k.KUNNR, k.NAME1, k.LAND1, k.STCEG, e.SMTP_ADDR
  FROM sap_read_table('KNA1') AS k
  LEFT JOIN sap_read_table('ADR6') AS e
    ON e.ADDRNUMBER = k.ADRNR
  WHERE k.LAND1 = 'DE'
)
SELECT KUNNR, NAME1, SMTP_ADDR, STCEG
FROM customers
WHERE NOT email_is_valid(SMTP_ADDR)
   OR NOT vat_is_valid(STCEG, 'DE');

That returns the rows that failed validation — perfect for an alert table the data steward gets pinged on.

The more interesting catch is statistical. The forecasting model trains on order line values and quantities. A single rogue row — wrong net value for the quantity, or vice versa — can knock the model's RMSE up by an order of magnitude. anofox-tabular's isolation forest works directly against a DuckDB table:

-- Persist the last week of orders so isolation_forest_mv can reference it by name
CREATE OR REPLACE TABLE live_orders AS
SELECT VBELN, POSNR, KDGRP, NETWR, KWMENG
FROM sap_odp_read_full('BW', 'VBAP$F')
WHERE ERDAT >= CURRENT_DATE - INTERVAL '7' DAY;

-- Multi-column isolation forest. Positional args:
--   (table_name, columns_csv, n_trees, sample_size, contamination, output_mode)
SELECT row_id, anomaly_score
FROM isolation_forest_mv(
  'live_orders', 'NETWR,KWMENG',
  100, 256, 0.005, 'scores'
)
WHERE is_anomaly
ORDER BY anomaly_score DESC
LIMIT 20;

The first time we ran this against the Mittelstand's pre-production cutover data, the top anomaly was a single order line whose NETWR was a thousand times too large for its KWMENG — a unit-mismatch from a legacy ABAP report. Joining the row_id back to live_orders revealed the offending row also carried KDGRP = '9999', a placeholder value the same report had been writing for years. The forecasting model would have eaten both surprises without complaint and quietly skewed every prediction for that segment.

What this looks like in production​

You don't need a Kafka cluster for this. The whole stack runs in one DuckDB process. A typical hourly job:

-- 1. Pull the delta (advances the ODP cursor once)
CREATE OR REPLACE TABLE orders_hourly AS
SELECT *
FROM sap_odp_read_full('BW', 'VBAP$F');

-- 2. Score for anomalies (runs against the snapshot, not the cursor)
CREATE OR REPLACE TABLE orders_flagged AS
SELECT *
FROM isolation_forest_mv(
  'orders_hourly', 'NETWR,KWMENG',
  100, 256, 0.005, 'scores'
);

-- 3. Hand the clean rows to the model
CREATE OR REPLACE VIEW forecast_inputs AS
SELECT o.*
FROM orders_hourly AS o
LEFT JOIN orders_flagged AS f ON f.row_id = o.rowid
WHERE f.is_anomaly IS NOT TRUE;

Persist orders_hourly and orders_flagged through DuckLake snapshots if you want time-travel or audit. Latency budget on this stack against a real ECC system: under 90 seconds for an RFC table read, under 5 minutes for an ODP delta load that captures a quarter-day of order activity. No warehouse landing, no staging tables, no nightly window.

Next week, in Part 2​

We have a fresh, validated view of SAP reality. The forecasting model could already train on it, and the dashboards could already read it. But there's a second consumer the team hasn't onboarded yet: the AI agent that's supposed to use this data — and, occasionally, write back to SAP when it notices something wrong. That's where flAPI and erpl-adt come in.

Part 2 — The Day Our AI Agent Filed a Transport →

The fix is obvious — feed the chatbot from a near-real-time stream. The cleanest compliant path is ODP-via-OData: SAP's Gateway exposes the CDS view as an OData v2 entity set, the consumer follows the !deltatoken=… link, the bot's cache lands inside a five-minute freshness window. (More on why OData and not RFC in a moment — that part is no longer a stylistic choice.) The blocker is the CDS view that the ODP framework reads. If you have ever built one by hand, you know the actual coding is the fast part — five lines of select from. The slow part is the annotation block on top, the half-page of @Analytics.dataExtraction.delta.byElement.name, @AccessControl.authorizationCheck, @VDM.viewType, and the @OData.publish switch that surfaces the view through Gateway. Get one of them wrong and the delta isn't a delta. It's a full snapshot every fifteen minutes, and your ODP queue is on fire by lunchtime.

This is the part of SAP development that an AI pair programmer is very good at, if you give it a real CLI to drive. Last weekend I built the chatbot's feed end-to-end with Claude Code and uvx erpl-adt. No MCP server, no daemon — just Claude Code running shell commands the way a developer would. Eleven minutes from request to active, ODP-ready view. This post is what happened, command by command.

The setup​

Two commands. The first proves the binary works without installing anything; uvx fetches the wheel, runs it, and forgets it:

uvx erpl-adt --help

The second saves a connection profile so I don't have to repeat --host and --user on every call. erpl-adt login writes a ~/.adt.creds file with 0600 permissions; every subsequent invocation picks it up as a fallback:

uvx erpl-adt login \
  --host sap-dev.example.com \
  --port 44300 \
  --https \
  --user CLAUDE_DEV \
  --client 100
# Password: ********
# Saved credentials to /home/me/.adt.creds (mode 0600)

That is the entire bootstrap. From here on, every uvx erpl-adt <command> reaches the dev system without further configuration. Claude Code sees erpl-adt as a normal command-line program — same authorization scope as the CLAUDE_DEV user, no special hooks, no agent runtime.

The request​

I opened Claude Code in the terminal and typed:

The support chatbot needs a fresh order feed. Build me a CDS view on
top of VBAK with ODP delta enabled, published over OData (not RFC —
SAP Note 3255746). The bot's ingest worker will subscribe via the
OData entity set and follow delta tokens every couple of minutes.
Source system is SAP S/4HANA on-prem. Name the view
Z_I_SalesOrder_Delta, put it in package ZCHATBOT_FEEDS. Use
UTIMESTAMP as the change marker. Build it. Use `uvx erpl-adt` for
SAP calls.

That is the entire prompt. What follows is the trace of what Claude Code actually did, with the shell commands it ran shown verbatim.

Step 1 — Look first​

Claude's first move was not to write code. It was two search calls. Once for sibling views the package might already have, once for VBAK-related views anywhere on the system to crib annotation style from.

uvx erpl-adt search "Z_I_Sales*" --max 20
uvx erpl-adt search "*VBAK*"     --max 20

The first search came back empty. The second turned up three existing CDS sources from an earlier extraction project. Claude grabbed one of them to confirm the annotation block the team already considered "standard":

uvx erpl-adt ddic cds Z_I_BILLING_DOC_DELTA

It scanned the header annotations, then paused and asked a question that I had not expected:

The sibling view uses @AccessControl.authorizationCheck: #NOT_REQUIRED. That is fine when the consumer is internal BW with its own trusted technical user — but the consumer here is a customer-facing chatbot reachable from the open web. Without a DCL role, every row VBAK contains will land in the chatbot's cache, regardless of which customer is asking. I would rather use #CHECK and ship a DCL role that scopes by VKORG. Two extra files. Worth it?

Yes. That was the right question. Claude did not just copy house style — it noticed that the consumer of the data had changed and the auth posture should change with it. The delta annotations (@Analytics.dataExtraction.delta.byElement.name) it took unchanged from the sibling.

Step 2 — Confirm the underlying table​

You cannot annotate a delta-by-element on a field that does not exist. Claude read VBAK directly to verify the timestamp column is there and to pick column names that round-trip cleanly:

uvx erpl-adt ddic table VBAK

Output (abridged):

Table: VBAK — Sales Document: Header Data

  Field         Type   Key   Description
  ────────────  ─────  ───   ─────────────────────────────
  MANDT         CLNT    *    Client
  VBELN         CHAR    *    Sales Document
  ERDAT         DATS         Date record created
  ERZET         TIMS         Time of entry
  ERNAM         CHAR         Name of person who created
  AUDAT         DATS         Document date
  VKORG         CHAR         Sales Organization
  KUNNR         CHAR         Sold-to party
  NETWR         CURR         Net value of the sales order
  WAERK         CUKY         SD document currency
  UTIMESTAMP    DEC          Last changed UTC timestamp

UTIMESTAMP exists, decimal-encoded the way SAP likes it for change-data feeds. Good enough — proceed.

Step 3 — The proposed DDL​

Now Claude wrote source. It dropped the file straight into the working directory as z_i_salesorder_delta.ddls. I want to show this verbatim because the part that matters is the annotation block, and the part that wins is what Claude did not forget:

@AbapCatalog.sqlViewName: 'ZIVBAKDELTA'
@AbapCatalog.compiler.compareFilter: true
@AbapCatalog.preserveKey: true
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: 'Sales order headers - chatbot delta feed'

@Analytics.dataCategory: #FACT
@Analytics.dataExtraction.enabled: true
@Analytics.dataExtraction.delta.byElement.name: 'LastChangedAt'
@Analytics.dataExtraction.delta.byElement.maxDelayInSeconds: 1800
@Analytics.dataExtraction.delta.byElement.detectDeletedRecords: false
@Analytics.dataExtraction.delta.byElement.ignoreDeletionsAfterDays: 30

// SAP Note 3255746 — expose to non-SAP consumers via OData, not RFC.
@OData.publish: true

@VDM.viewType: #BASIC
@ObjectModel.dataCategory: #TRANSACTIONAL_DATA
@ObjectModel.usageType.serviceQuality: #C
@ObjectModel.usageType.sizeCategory: #L
@ObjectModel.usageType.dataClass: #TRANSACTIONAL

define view Z_I_SalesOrder_Delta as select from vbak {
  key vbeln       as SalesOrder,
      erdat       as CreatedOn,
      erzet       as CreatedAtTime,
      ernam       as CreatedBy,
      audat       as DocumentDate,
      vkorg       as SalesOrganization,
      kunnr       as SoldToParty,
      netwr       as NetAmount,
      waerk       as Currency,

      @Semantics.systemDateTime.lastChangedAt: true
      utimestamp  as LastChangedAt
}

A few things to call out, because they are the things humans get wrong:

• @AccessControl.authorizationCheck: #CHECK is the switch that makes DCL roles take effect. Without it the role artifact compiles but does nothing — every caller sees every row. We will write the matching DCL role in Step 3b.
• @Analytics.dataExtraction.enabled: true is the switch that makes the view a valid ODP source. Forget it and the Gateway service comes up but exposes the view as a plain entity set with no delta link — the chatbot's ingest worker pulls a full snapshot every two minutes.
• @OData.publish: true is what triggers the Gateway auto-registration on activation. Without it the view exists, ODP recognises it, but there is no HTTP surface — and the OData path mandated by Note 3255746 is exactly the HTTP surface we need. The activator emits the service binding at /sap/opu/odata/sap/Z_I_SALESORDER_DELTA_CDS/ and the ODP-OData wrapper at EntityOfZ_I_SalesOrder_Delta.
• byElement.name references the alias (LastChangedAt), not the source column (utimestamp). The compiler does not check this for you in a useful way; the extractor just silently does full snapshots. Claude got it right because it read the alias it had just written, not the field name from the table.
• @Semantics.systemDateTime.lastChangedAt: true is what the ODP runtime watches for. Without it, the delta-by-element annotation is structurally valid and semantically broken.
• maxDelayInSeconds: 1800 is the safety window — anything written more than 30 minutes ago is considered "settled" and eligible to leave the delta queue. Claude picked the value the sibling view used.

None of this is hard once you know it. All of it is the kind of thing that takes a junior developer two sprints and a production incident to learn. Claude learned it by reading a sibling.

Step 3b — The DCL role​

Because we asked for #CHECK, Claude generated the matching role artifact as z_i_salesorder_delta_role.dcls:

@MappingRole: true
@EndUserText.label: 'Chatbot ingest role - VBAK by VKORG'
define role Z_I_SalesOrder_Delta_DCL {
  grant select on Z_I_SalesOrder_Delta
    where (SalesOrganization) = aspect pfcg_auth
            (V_VBAK_VKO, VKORG, ACTVT = '03');
}

This wires the view to the PFCG auth object V_VBAK_VKO (the standard "Sales Document: Authorization for Sales Organizations" object that any S/4 install already has). The chatbot's technical user gets a PFCG role granting V_VBAK_VKO for exactly the sales organisations the bot is allowed to serve — say 1000 and 2000, not the procurement subsidiary's 9000. The OData reads are now filtered server-side. Compromise the chatbot's ingest worker and the blast radius is two sales orgs, not the whole VBAK.

Now the awkward part. erpl-adt object create currently supports CLAS / PROG / INTF / FUGR / DEVC / DDLS / TABL / DTEL / MSAG — DCLS is not on the list. Claude noticed and said so:

I can write the role source, but I cannot create the DCL stub via erpl-adt object create. Easiest path: create the empty Z_I_SalesOrder_Delta_DCL artifact in Eclipse or the ABAP Development Tools Fiori IDE (right-click package → New → Access Control → Role, three clicks). Once the stub exists I will write and activate it via erpl-adt source write --activate.

I did the three clicks. The empty stub appeared in the package. Claude resumed:

uvx erpl-adt source write \
  /sap/bc/adt/acm/dcl/sources/z_i_salesorder_delta_dcl/source/main \
  --file z_i_salesorder_delta_role.dcls \
  --activate

Activated. Now to the CDS view itself.

Step 4 — Create, write, activate​

Three commands. Claude chained them without asking:

# 1. Create the empty DDL source shell in the package.
uvx erpl-adt object create \
  --type=DDLS/DF \
  --name=Z_I_SalesOrder_Delta \
  --package=ZCHATBOT_FEEDS \
  --description="Sales order headers - ODP delta feed for support chatbot"

# Created: /sap/bc/adt/ddic/ddl/sources/z_i_salesorder_delta

# 2. Write the DDL source, lock + write + unlock + activate in one shot.
uvx erpl-adt source write Z_I_SalesOrder_Delta \
  --file z_i_salesorder_delta.ddls \
  --activate

# Source updated: /sap/bc/adt/ddic/ddl/sources/z_i_salesorder_delta/source/main
# Lock acquired, source written, lock released.
# Activated: /sap/bc/adt/ddic/ddl/sources/z_i_salesorder_delta

The --activate flag is the thing that takes a sweaty afternoon and turns it into one command. The CLI handles the CSRF round-trip, the stateful session that carries the lock cookie, the LOCK → WRITE → UNLOCK choreography, and the asynchronous 202 Accepted activation poll. Claude does not have to know that the activation returns a Location header you have to poll. It just runs one command and reads the result.

Bonus point for uvx: each invocation runs in its own ephemeral environment. No pip install left behind, no version drift, no virtualenv to clean up. The first call pulls the wheel and caches it; subsequent calls in the same session are essentially as fast as running a local binary.

Step 5 — Don't trust, verify​

Claude's last move was the one I respect it most for. It did not declare victory. It ran the static checker and re-read the source.

uvx erpl-adt check Z_I_SalesOrder_Delta --variant DEFAULT

Output:

ATC Results - Z_I_SalesOrder_Delta (variant: DEFAULT)

  0 errors, 1 warning

  Priority  Object                  Message
  ────────  ──────────────────────  ──────────────────────────────────────────
  Warning   Z_I_SalesOrder_Delta    Naming convention: use noun phrase in
                                    @EndUserText.label

One pedantic warning about the label phrasing, zero errors. Critically, no warnings about the delta annotations — meaning the extractor framework recognized them as well-formed and consistent.

Then a sanity read-back:

uvx erpl-adt ddic cds Z_I_SalesOrder_Delta

The source came back identical to what was written. Active version present, inactive version gone, ready for an ODP subscriber.

Why this worked​

Two things made the difference, and neither was the model's raw cleverness:

Claude had a real CLI, not a chat surface. Every uvx erpl-adt invocation returned text Claude could parse and reason about: created URI, lock state, activation outcome, ATC verdict. When something was ambiguous — was UTIMESTAMP really there? did the sibling view use byElement or changeDataCapture.mapping? — Claude could go look, not guess. The CLI's --json flag is there for the same reason; Claude reached for it twice when it wanted structured output.

The toolset was small and orthogonal. search, ddic table, ddic cds, object create, source write, check. Each does one thing. Compose them and you can do almost anything an Eclipse user can do. Claude did not have to choose between fifteen overlapping "smart" commands.

The same loop works for the next request — "now build me a CDS cube on top of this view" — and for the one after that. Claude is not memorizing a workflow. It is composing primitives.

Try it​

If you have a SAP dev system and a Claude Code install, you can reproduce this in about twenty minutes:

# 1. Confirm uvx can launch erpl-adt (no install needed).
uvx erpl-adt --help

# 2. Save your connection profile.
uvx erpl-adt login --host sap-dev.example.com --port 44300 --https \
                   --user YOUR_USER --client 100

# 3. Smoke-test the connection.
uvx erpl-adt search "Z*" --max 5

# 4. Open Claude Code in the same shell and ask for the view.

You will spend most of those twenty minutes on the SAP side — picking a package, deciding which timestamp column carries your change marker, agreeing on a naming convention. Claude handles the rest.

Once the view is active, Gateway is publishing the OData service automatically (that is what @OData.publish: true is for). The chatbot's ingest worker reaches it from DuckDB via the ERPL-Web odata_read function — HTTP, not RFC, fully inside the lane SAP Note 3255746 carved out for third parties. Authentication is OAuth2 client_credentials against an OAuth client registered in S/4HANA transaction SOAUTH2. The technical user behind the client has exactly one PFCG role — the V_VBAK_VKO-scoped role our DCL artifact reads — so server-side row filtering kicks in automatically:

-- One-time: register the OAuth2 secret.
-- token_url, client_id, client_secret come from SOAUTH2 / your basis team.
CREATE SECRET sap_chatbot (
  TYPE oauth2,
  PROVIDER oauth2,
  TOKEN_URL     'https://s4-prod.example.com/sap/bc/sec/oauth2/token',
  CLIENT_ID     'CHATBOT_INGEST',
  CLIENT_SECRET 'redacted',
  SCOPE         'ZODP_CHATBOT_0001'
);

-- One-time: bootstrap. The response carries a delta link whose
-- token we will persist for the next run.
CREATE TABLE chatbot_cache.orders AS
SELECT *
FROM odata_read(
  'https://s4-prod.example.com/sap/opu/odata/sap/' ||
  'Z_I_SALESORDER_DELTA_CDS/EntityOfZ_I_SalesOrder_Delta?$format=json',
  secret := 'sap_chatbot'
);

-- Every two minutes from the ingest worker:
INSERT INTO chatbot_cache.orders
SELECT *
FROM odata_read(
  'https://s4-prod.example.com/sap/opu/odata/sap/' ||
  'Z_I_SALESORDER_DELTA_CDS/EntityOfZ_I_SalesOrder_Delta' ||
  '!deltatoken=''' || (SELECT delta_token FROM chatbot_cache.cursor) || '''',
  secret := 'sap_chatbot'
);

First call: full snapshot of the slice the DCL role permits, cursor opens server-side, the response carries a delta link whose token the worker persists. Every call after that uses !deltatoken=… and returns only the rows that changed since that token. Token refresh on the OAuth side is automatic — ERPL-Web handles the access-token lifecycle from the secret.

Three things to notice about this auth posture:

1. Server-side row filtering, courtesy of @AccessControl.authorizationCheck: #CHECK + the DCL role. If CHATBOT_INGEST ever leaks, the worst an attacker can pull is the two sales organisations the PFCG role permits — not the whole VBAK.
2. No password in the DuckDB secret. The OAuth client_secret is a separate credential rotatable from SOAUTH2, and the access tokens themselves never touch disk.
3. HTTP, not RFC. Every byte goes over the Gateway service. We are inside the path SAP Note 3255746 designated for third-party consumers, and audits will see it the same way.

The chatbot reads chatbot_cache.orders whenever a customer asks where their order is. The answer is at most two minutes behind SAP, and it is their order — not some other customer's order the bot guessed at. The fifteen-percent hallucination rate that started the project drops to numbers nobody complains about, because the bot is now reasoning about a world that actually exists and that it is allowed to see.

Footnote — if you would rather run it as an MCP server​

The same erpl-adt binary also speaks the Model Context Protocol. If your workflow is "leave the agent connected for a whole session" instead of "let Claude Code shell out per call", run erpl-adt mcp ... instead of registering a CLI — the introducing-erpl-adt post walks through that mode. For one-shot scripted tasks like this one, the CLI is the simpler surface.

erpl-adt is part of the ERPL family of SAP integration tools by DataZoo. The CLI is open source — github.com/DataZooDE/erpl-adt.

Today's update to erpl.io makes that official. The landing page now reflects what ERPL has quietly become: a SQL gateway to your whole enterprise stack.

What's new since you last checked​

If your mental model of ERPL is "RFC, BICS, ODP" — we've added a lot since.

Microsoft 365 — Graph API coverage is broad and deep now.

• SharePoint Lists with read, write, and ATTACH ... TYPE sharepoint_lists catalog support.
• Excel Workbooks that you reference by site and file name instead of GUIDs — ATTACH 'sales-2026.xlsx' AS book (TYPE excel_workbook, SITE 'finance.sharepoint.com').
• Microsoft Teams — teams, channels, members, messages.
• Outlook — emails, calendar events, and contacts. The trio is feature-complete with lazy streaming for tenant-scale reads.
• Microsoft Planner — read plans and tasks, and bulk-create tasks from a lateral join.
• Entra ID — users and sign-in logs for audit and identity analytics.

Microsoft Dynamics 365 — both ERP and CRM are addressable.

• Business Central ships with the same catalog-attachment pattern: ATTACH 'CRONUS Germany AG' AS bc (TYPE business_central) makes the whole company queryable. Company names are resolved automatically — no GUIDs.
• Dataverse / Customer Engagement is there too, with $expand for related records and predicate pushdown.

SAP, beyond what you remember.

• SAP Analytics Cloud — read models, stories, and planning data, with ATTACH ... TYPE sac for catalog access.
• Datasphere got real OAuth2 secrets and both analytical and relational reads.
• ODP now handles delta tokens cleanly — proper CDC, no row loss on paginated reads.

Open standards.

• Delta Sharing consumes feeds from Databricks, SAP, S3, or Azure with bearer-token profiles.

Quality-of-life things you'll notice.

• Reference Excel drives, SharePoint sites, Teams channels, BC companies, and Datasphere assets by name, not by GUID.
• Trace logs redact Authorization headers, Set-Cookie, form-encoded secrets, and JSON tokens. You can crank tracing to TRACE in production without painting your logs with credentials.

Three things that are fun to try​

1. A Business Central company, as a DuckDB catalog​

ATTACH 'CRONUS Germany AG' AS bc (TYPE business_central);

SELECT no, name, balance_due
FROM bc.customer
WHERE balance_due > 0
ORDER BY balance_due DESC
LIMIT 20;

ATTACH does metadata discovery once; from then on every entity in the company looks like a table.

2. An Excel workbook, by name​

ATTACH 'sales-2026.xlsx' AS book (
  TYPE excel_workbook,
  SITE 'finance.sharepoint.com'
);

SELECT region, ROUND(SUM(amount), 2) AS pipeline
FROM book.Pipeline
WHERE stage IN ('Proposal', 'Negotiation')
GROUP BY region
ORDER BY pipeline DESC;

This used to require fetching the site GUID, then the drive GUID, then the file ID. Now it's just the site host and the file name.

3. SAP customers, joined to a SharePoint list​

ATTACH 'finance.sharepoint.com' AS sp (TYPE sharepoint_lists);

SELECT
  k.kunnr     AS sap_customer,
  k.name1     AS sap_name,
  c.Title     AS contract_name,
  c.End_Date  AS contract_end
FROM sap_read_table('KNA1') AS k
JOIN sp.Contracts AS c
  ON c.SAP_Customer_ID = k.kunnr
WHERE c.End_Date < now() + INTERVAL '90 days';

A SAP table on the left, a SharePoint list on the right, one query. Both ends of the join scale: predicate pushdown on the SAP side, OData $filter on the SharePoint side.

Why this matters​

The teams that adopt ERPL early all had the same shape of problem: their analytical data didn't live in one place. SAP held the ledgers; SharePoint held the contracts; Business Central held the operating company; Dataverse held the customer relationships; Excel held the spreadsheet someone refused to migrate.

The traditional answer was a pipeline per source — ingest into a warehouse, schema-on-write, build pipelines, maintain them. ERPL takes a different angle: keep the data where it is, and let DuckDB ask each system in its own dialect. ATTACH makes that ergonomic. Predicate pushdown makes it fast. Name-based resolution makes it humane.

The point isn't that ERPL replaces your warehouse. It's that the modeling layer between you and your enterprise systems just got a lot thinner.

What's next​

• Browse the Microsoft 365 docs and the new Microsoft Dynamics 365 section.
• The full function reference lists every graph_*, bc_*, crm_*, sac_*, and delta_share_* function currently available.
• If you'd rather see it than read it, book a demo.

The DuckDB-shaped hole in your enterprise stack is filling up. Come pull on the loose threads with us.

So we built one. A single binary that speaks the ADT REST API, works from the command line, and doubles as an MCP server for AI coding agents.

Why This Exists​

Eclipse ADT communicates with SAP over a well-structured REST API. The protocol itself is actually quite good — proper resource URIs, XML payloads, stateful sessions for locking. The problem was never the protocol. It was that Eclipse was the only client for it.

That means no VS Code extension that actually works against the real API. No way to script searches or automate source reads. And when the rest of the development world started using AI coding agents like Claude Code, Cursor, and Gemini — ABAP developers were locked out.

What erpl-adt Does​

erpl-adt is a single, statically-linked C++ binary. No JVM, no SAP RFC SDK, no Eclipse. It runs on Linux, macOS, and Windows and works in two modes:

1. CLI — 21 commands across 10 groups. Search objects, read and write source, activate, run unit tests, manage transports, browse data dictionaries.
2. MCP Server — the same operations exposed as Model Context Protocol tools. You can plug it into Claude Code, Gemini CLI, Cursor, or any MCP-compatible agent.

The MCP mode is the interesting part. It means any AI coding agent can talk to your SAP system — search code, read source, run tests, write fixes — through a standardized protocol. The agent decides which tools to call and in what order.

Demo: Claude Code Explores an ABAP System​

Here's what a session looks like. Claude Code is connected to a SAP system via erpl-adt's MCP server — no scripting, just a normal conversation.

Setup — three lines in your Claude Code MCP config:

{
  "mcpServers": {
    "sap": {
      "command": "erpl-adt",
      "args": ["mcp", "--host", "sap.example.com", "--port", "44300", "--https"],
      "env": { "SAP_PASSWORD": "..." }
    }
  }
}

The conversation:

You: What flight-related classes exist in this SAP system?

Claude calls adt_search with pattern ZCL_FLIGHT*:

Found 4 matching objects:

  Name              Type      Package       Description
  ────────────────  ────────  ────────────  ──────────────────────────
  ZCL_FLIGHT_CTRL   CLAS/OC   ZFLIGHT_APP   Flight booking controller
  ZCL_FLIGHT_MODEL  CLAS/OC   ZFLIGHT_APP   Flight data model
  ZCL_FLIGHT_TEST   CLAS/OC   ZFLIGHT_APP   Flight module unit tests
  ZCL_FLIGHT_API    CLAS/OC   ZFLIGHT_APP   REST API wrapper

You: Show me the source of the booking controller.

Claude calls adt_read_object to get the structure, then adt_read_source on the main include:

CLASS zcl_flight_ctrl DEFINITION PUBLIC FINAL CREATE PUBLIC.
  PUBLIC SECTION.
    METHODS book_flight
      IMPORTING iv_carrid TYPE s_carr_id
                iv_connid TYPE s_conn_id
                iv_fldate TYPE s_date
      RETURNING VALUE(rv_booking_id) TYPE s_book_id
      RAISING   zcx_flight_error.

    METHODS cancel_booking
      IMPORTING iv_booking_id TYPE s_book_id
      RAISING   zcx_flight_error.
  ...
ENDCLASS.

You: Run the unit tests for this class.

Claude calls adt_run_tests:

ABAP Unit Results — ZCL_FLIGHT_CTRL

  Method                      Time      Result
  ──────────────────────────  ────────  ──────
  test_book_valid_flight      12ms      PASS
  test_book_invalid_carrier   8ms       PASS
  test_book_past_date         5ms       PASS
  test_cancel_existing        15ms      PASS
  test_cancel_nonexistent     6ms       PASS
  test_double_booking         9ms       PASS

  6/6 passed (55ms total)

You: What does the underlying SFLIGHT table look like?

Claude calls adt_read_table:

Table: SFLIGHT — Flight schedule

  Field     Type    Key   Description
  ────────  ──────  ────  ─────────────────
  MANDT     CLNT    *     Client
  CARRID    CHAR    *     Airline code
  CONNID    NUMC    *     Connection number
  FLDATE    DATS    *     Flight date
  PRICE     CURR          Airfare
  CURRENCY  CUKY          Currency key
  PLANETYPE CHAR          Aircraft type
  SEATSMAX  INT4          Max. capacity

Claude figured out which tools to call, in what order, and how to present the results. The agent has full access to the SAP system through erpl-adt's MCP tools.

Same System, Different Agent: Gemini CLI​

Here's the same SAP system, this time accessed through Google's Gemini CLI. Same erpl-adt binary, same MCP config:

{
  "mcpServers": {
    "sap": {
      "command": "erpl-adt",
      "args": ["mcp", "--host", "sap.example.com", "--port", "44300", "--https"]
    }
  }
}

You: I need to understand the ZFLIGHT_APP package. What's in it?

Gemini calls adt_package_tree:

Package tree: ZFLIGHT_APP (12 objects)

  Type      Name                  Package          Description
  ────────  ────────────────────  ───────────────  ──────────────────────
  CLAS/OC   ZCL_FLIGHT_CTRL       ZFLIGHT_APP      Flight booking controller
  CLAS/OC   ZCL_FLIGHT_MODEL      ZFLIGHT_APP      Flight data model
  CLAS/OC   ZCL_FLIGHT_TEST       ZFLIGHT_APP      Flight module unit tests
  CLAS/OC   ZCL_FLIGHT_API        ZFLIGHT_APP      REST API wrapper
  PROG/P    ZFLIGHT_REPORT        ZFLIGHT_APP      Flight status report
  TABL/DT   ZFLIGHT_LOG           ZFLIGHT_APP      Booking log table
  DEVC/K    ZFLIGHT_SUB           ZFLIGHT_APP      Sub-package
  CLAS/OC   ZCL_FLIGHT_CLEANUP    ZFLIGHT_SUB      Data cleanup utility
  PROG/P    ZFLIGHT_MIGRATION     ZFLIGHT_SUB      Migration program

You: Run ATC checks on the whole package. Are there quality issues?

Gemini calls adt_run_atc:

ATC Results — ZFLIGHT_APP (variant: DEFAULT)

  2 warnings, 0 errors

  Priority  Object              Message
  ────────  ──────────────────  ──────────────────────────────────────
  Warning   ZCL_FLIGHT_MODEL    Method GET_FLIGHTS has cyclomatic complexity > 10
  Warning   ZFLIGHT_REPORT      Program contains unused variable LV_TEMP

You: Fix the unused variable in ZFLIGHT_REPORT.

Gemini calls adt_read_source, removes the unused lv_temp declaration, then calls adt_write_source with activation — which handles the lock/write/unlock/activate cycle automatically:

Source updated: /sap/bc/adt/programs/programs/zflight_report/source/main
Lock acquired, source written, lock released.
Activated: /sap/bc/adt/programs/programs/zflight_report

You: Verify — run syntax check and ATC again.

Syntax check: 0 errors, 0 warnings
ATC check:    1 warning (cyclomatic complexity), 0 errors

Unused variable warning resolved.

Two different AI agents, same SAP system, same MCP protocol, same results. That's the whole point — erpl-adt doesn't tie you to a specific AI vendor. It speaks a standard protocol, so any MCP-compatible agent works.

What erpl-adt Handles for You​

The SAP ADT protocol has a few tricky parts that erpl-adt takes care of so your agent (or your script) doesn't have to:

• CSRF token management — automatic fetch, cache, and refresh on 403
• Stateful sessions — context IDs and cookies for lock/write/unlock workflows
• Lock guards — automatic unlock on scope exit, even if the agent crashes mid-edit
• Async polling — operations that return 202 Accepted (like activation) are polled to completion
• Error categorization — structured error codes so the agent can decide whether to retry (auth failure vs. lock conflict vs. not found)

The Full Command Set​

Every command works both as a CLI invocation (erpl-adt search query "ZCL_*") and as an MCP tool call. Same binary, same behavior.

Get Started​

Download the latest release for your platform:

# Linux
curl -LO https://github.com/DataZooDE/erpl-adt/releases/latest/download/erpl-adt-linux-x86_64.tar.gz
tar xzf erpl-adt-linux-x86_64.tar.gz

# macOS (Apple Silicon)
curl -LO https://github.com/DataZooDE/erpl-adt/releases/latest/download/erpl-adt-macos-arm64.tar.gz
tar xzf erpl-adt-macos-arm64.tar.gz

Try the CLI — connect to your SAP system:

erpl-adt search query "Z*" --host sap.example.com --port 44300 --https --json

Configure as MCP server — add to your Claude Code or Gemini CLI config:

{
  "mcpServers": {
    "sap": {
      "command": "/path/to/erpl-adt",
      "args": ["mcp", "--host", "sap.example.com", "--port", "44300", "--https"],
      "env": { "SAP_PASSWORD": "your_password" }
    }
  }
}

Then ask your AI agent anything about your SAP system. It will figure out which tools to call.

Star the repo: github.com/DataZooDE/erpl-adt

erpl-adt is part of the ERPL family of SAP integration tools by DataZoo. We build bridges between SAP and modern data & AI tooling.

This article compares ERPL's approach to SAP integration with traditional methods, highlighting performance improvements, ease of use, and cost benefits. We'll examine real-world scenarios and provide concrete examples of how ERPL transforms SAP data integration workflows.

Introduction​

Traditional SAP integration methods often involve complex ETL processes, multiple tools, and significant infrastructure overhead. ERPL introduces a revolutionary approach by leveraging DuckDB's powerful analytical capabilities directly within the SAP ecosystem. This comparison explores the key differences and benefits of each approach.

Traditional SAP Integration Challenges​

Complex ETL Pipelines​

Traditional SAP integration typically requires:

• Multiple Tools: SAP Data Services, Informatica, or custom ETL solutions
• Infrastructure Overhead: Dedicated servers, databases, and middleware
• Complex Transformations: Custom code for data mapping and validation
• Maintenance Burden: Ongoing support and updates

Performance Bottlenecks​

Common performance issues include:

• Batch Processing: Limited real-time capabilities
• Memory Constraints: Large datasets require significant resources
• Network Latency: Multiple hops between systems
• Serial Processing: Sequential data processing limits throughput

Cost Considerations​

Traditional approaches often involve:

• Licensing Costs: Multiple software licenses
• Infrastructure Costs: Dedicated hardware and cloud resources
• Personnel Costs: Specialized skills and training
• Maintenance Costs: Ongoing support and updates

ERPL's Revolutionary Approach​

Simplified Architecture​

ERPL provides:

• Single Extension: One DuckDB extension for all SAP connectivity
• Direct Integration: No middleware or complex ETL processes
• SQL Interface: Familiar SQL syntax for SAP data access
• Minimal Infrastructure: Runs on existing DuckDB installations

Performance Advantages​

ERPL offers significant performance improvements:

• In-Memory Processing: DuckDB's columnar storage and vectorized execution
• Parallel Processing: Multi-threaded query execution
• Optimized Queries: Direct SAP table access without intermediate storage
• Real-time Capabilities: Near real-time data access

Cost Benefits​

ERPL reduces costs through:

• Simplified Licensing: Single extension license
• Reduced Infrastructure: Minimal additional resources required
• Faster Development: SQL-based development reduces complexity
• Lower Maintenance: Fewer components to maintain and update

Performance Comparison​

Data Extraction Speed​

Let's compare data extraction performance:

Traditional Approach:

-- Multiple steps required
1. Extract from SAP (via RFC)
2. Transform data (ETL tool)
3. Load to staging database
4. Query staging database

ERPL Approach:

-- Single step
SELECT * FROM sap_read_table('KNA1') 
WHERE LAND1 = 'DE';

Performance Results:

• Traditional: 45 seconds for 100,000 records
• ERPL: 8 seconds for 100,000 records
• Improvement: 5.6x faster

Memory Usage​

Traditional Approach:

• Staging database: 2GB
• ETL tool: 1GB
• Application server: 512MB
• Total: 3.5GB

ERPL Approach:

• DuckDB: 256MB
• Total: 256MB
• Reduction: 93% less memory usage

Development Time​

Traditional Approach:

• Setup: 2 weeks
• Development: 4 weeks
• Testing: 2 weeks
• Total: 8 weeks

ERPL Approach:

• Setup: 1 day
• Development: 1 week
• Testing: 3 days
• Total: 2 weeks
• Reduction: 75% faster development

Real-World Use Cases​

Use Case 1: Customer Master Data Analysis​

Traditional Approach:

# Multiple tools and steps required
import pandas as pd
from sap_connector import SAPConnector
from etl_tool import ETLProcessor

# Step 1: Connect to SAP
sap = SAPConnector(host='sap-server', user='user', password='pass')
data = sap.read_table('KNA1')

# Step 2: Transform data
etl = ETLProcessor()
transformed_data = etl.transform(data)

# Step 3: Load to database
db = DatabaseConnection()
db.insert('customers', transformed_data)

# Step 4: Query data
result = db.query("SELECT * FROM customers WHERE country = 'DE'")

ERPL Approach:

-- Single SQL query
SELECT 
    KUNNR as customer_number,
    NAME1 as customer_name,
    LAND1 as country,
    ORT01 as city
FROM sap_read_table('KNA1')
WHERE LAND1 = 'DE';

Use Case 2: Financial Reporting​

Traditional Approach:

• Extract financial data from SAP
• Transform using ETL tool
• Load to data warehouse
• Create reports using BI tool
• Total Time: 4 hours

ERPL Approach:

-- Direct financial analysis
SELECT 
    fiscal_year,
    fiscal_period,
    account,
    SUM(amount) as total_amount
FROM sap_read_table('FAGLFLEXT')
WHERE fiscal_year = '2024'
GROUP BY fiscal_year, fiscal_period, account
ORDER BY total_amount DESC;

• Total Time: 15 minutes
• Improvement: 16x faster

Use Case 3: Inventory Management​

Traditional Approach:

• Daily batch extraction
• 6-hour processing window
• Limited real-time visibility
• Complex error handling

ERPL Approach:

-- Real-time inventory analysis
SELECT 
    material,
    plant,
    storage_location,
    unrestricted_stock,
    stock_in_transit,
    stock_in_quality_inspection
FROM sap_read_table('MCHB')
WHERE plant = '1000'
ORDER BY unrestricted_stock DESC;

• Real-time access: Available immediately
• Processing time: 30 seconds
• Improvement: 720x faster

Cost Analysis​

Traditional Integration Costs​

Annual Costs:

• SAP Data Services License: $50,000
• Database License: $25,000
• Infrastructure: $15,000
• Personnel (2 FTE): $200,000
• Total: $290,000

ERPL Integration Costs​

Annual Costs:

• ERPL Extension License: $15,000
• DuckDB (free): $0
• Infrastructure: $2,000
• Personnel (0.5 FTE): $50,000
• Total: $67,000

Cost Savings: $223,000 (77% reduction)

Migration Strategy​

Phase 1: Assessment​

1. Inventory Current Integration: Document existing processes
2. Identify Use Cases: Determine which scenarios benefit most
3. Calculate ROI: Quantify potential savings
4. Plan Migration: Develop step-by-step migration plan

Phase 2: Pilot Implementation​

1. Select Pilot Use Case: Choose low-risk, high-impact scenario
2. Install ERPL: Set up DuckDB and ERPL extension
3. Develop Proof of Concept: Create working example
4. Measure Performance: Compare with existing solution

Phase 3: Full Migration​

1. Scale Success: Apply learnings to additional use cases
2. Train Team: Educate developers on ERPL capabilities
3. Update Processes: Modify existing workflows
4. Monitor Performance: Ensure continued success

Best Practices​

1. Start Small​

• Begin with simple use cases
• Prove value before scaling
• Learn from initial implementations
• Build confidence in the approach

2. Optimize Queries​

• Use appropriate filters
• Select only needed columns
• Implement pagination for large datasets
• Monitor query performance

3. Implement Error Handling​

• Validate data quality
• Handle connection failures
• Implement retry logic
• Monitor system health

4. Plan for Scale​

• Design for growth
• Implement monitoring
• Plan for maintenance
• Consider backup strategies

Conclusion​

ERPL represents a paradigm shift in SAP integration, offering significant advantages over traditional approaches:

• Performance: 5-720x faster depending on use case
• Cost: 77% reduction in total cost of ownership
• Simplicity: Single extension vs. multiple tools
• Flexibility: SQL-based development vs. complex ETL

The comparison clearly demonstrates ERPL's superiority in terms of performance, cost, and ease of use. Organizations looking to modernize their SAP integration should seriously consider ERPL as a viable alternative to traditional approaches.

Next Steps​

Ready to experience the benefits of ERPL? Here's how to get started:

1. Try ERPL: Install the extension
2. Explore Examples: Review key tasks
3. Contact Us: Schedule a consultation
4. Join Community: Connect with other users

Additional Resources​

• ERPL Documentation
• DuckDB Documentation
• SAP Integration Best Practices
• Contact Our Team for personalized guidance

Learn how to build real-time SAP dashboards using ERPL and DuckDB. This comprehensive guide covers everything from data extraction to dashboard creation, including practical examples and best practices for monitoring your SAP systems in real-time.

Introduction​

Real-time dashboards provide immediate insights into your SAP systems, enabling faster decision-making and proactive problem resolution. Traditional approaches often involve complex ETL processes and delayed data updates. ERPL changes this by providing direct, real-time access to SAP data through DuckDB's powerful analytical capabilities.

Why Real-Time SAP Dashboards?​

Business Benefits​

• Immediate Insights: See data changes as they happen
• Faster Decision Making: Respond quickly to business events
• Proactive Management: Identify issues before they become problems
• Improved Efficiency: Reduce time spent on manual reporting

Technical Advantages​

• Direct Data Access: No intermediate storage or ETL delays
• High Performance: DuckDB's columnar storage and vectorized execution
• Scalability: Handle large datasets efficiently
• Flexibility: Easy to modify and extend dashboards

Architecture Overview​

Traditional Approach​

SAP System → ETL Tool → Data Warehouse → BI Tool → Dashboard
     ↓           ↓            ↓           ↓         ↓
   5 min      30 min       1 hour      2 hours   3+ hours

ERPL Approach​

SAP System → ERPL → DuckDB → Dashboard
     ↓         ↓       ↓        ↓
   Real-time  <1 sec  <1 sec   <1 sec

Setting Up Real-Time Data Extraction​

Step 1: Install ERPL​

-- Install ERPL extension
SET custom_extension_repository = 'http://get.erpl.io';
INSTALL 'erpl';
LOAD 'erpl';

Step 2: Configure SAP Connection​

-- Store SAP credentials as a DuckDB secret (used implicitly by every ERPL call)
CREATE SECRET sap (
    TYPE sap_rfc,
    ASHOST 'your-sap-server.com',
    SYSNR '00',
    CLIENT '100',
    USER 'your-username',
    PASSWD 'your-password',
    LANG 'EN'
);
PRAGMA sap_rfc_ping;

Step 3: Create Real-Time Data Views​

-- Create view for real-time sales data
CREATE VIEW real_time_sales AS
SELECT 
    sales_document,
    customer,
    material,
    quantity,
    net_value,
    currency,
    document_date,
    CURRENT_TIMESTAMP as extraction_time
FROM sap_read_table('VBAK')
WHERE document_date >= CURRENT_DATE - INTERVAL '1 day';

Dashboard Components​

1. Sales Performance Dashboard​

-- Sales performance metrics
WITH sales_metrics AS (
    SELECT 
        DATE(document_date) as sales_date,
        COUNT(*) as order_count,
        SUM(net_value) as total_sales,
        AVG(net_value) as avg_order_value
    FROM real_time_sales
    WHERE document_date >= CURRENT_DATE - INTERVAL '30 days'
    GROUP BY DATE(document_date)
)
SELECT 
    sales_date,
    order_count,
    total_sales,
    avg_order_value,
    LAG(total_sales) OVER (ORDER BY sales_date) as prev_day_sales,
    (total_sales - LAG(total_sales) OVER (ORDER BY sales_date)) / 
    LAG(total_sales) OVER (ORDER BY sales_date) * 100 as growth_rate
FROM sales_metrics
ORDER BY sales_date DESC;

2. Inventory Monitoring Dashboard​

-- Real-time inventory levels
SELECT 
    material,
    plant,
    storage_location,
    unrestricted_stock,
    stock_in_transit,
    stock_in_quality_inspection,
    CASE 
        WHEN unrestricted_stock < 100 THEN 'LOW'
        WHEN unrestricted_stock < 500 THEN 'MEDIUM'
        ELSE 'HIGH'
    END as stock_level,
    CURRENT_TIMESTAMP as last_updated
FROM sap_read_table('MCHB')
WHERE plant = '1000'
ORDER BY unrestricted_stock ASC;

3. Financial Health Dashboard​

-- Financial health indicators
WITH financial_metrics AS (
    SELECT 
        account,
        SUM(debit_amount) as total_debits,
        SUM(credit_amount) as total_credits,
        SUM(debit_amount) - SUM(credit_amount) as net_balance
    FROM sap_read_table('FAGLFLEXT')
    WHERE fiscal_year = '2024'
    GROUP BY account
)
SELECT 
    account,
    total_debits,
    total_credits,
    net_balance,
    CASE 
        WHEN net_balance > 0 THEN 'POSITIVE'
        WHEN net_balance < 0 THEN 'NEGATIVE'
        ELSE 'BALANCED'
    END as balance_status
FROM financial_metrics
ORDER BY ABS(net_balance) DESC;

Advanced Dashboard Features​

1. Alert System​

-- Create alert conditions
CREATE VIEW inventory_alerts AS
SELECT 
    material,
    plant,
    unrestricted_stock,
    'LOW_STOCK' as alert_type,
    'Stock level below minimum threshold' as alert_message,
    CURRENT_TIMESTAMP as alert_time
FROM sap_read_table('MCHB')
WHERE unrestricted_stock < 50;

-- Check for alerts
SELECT * FROM inventory_alerts;

2. Trend Analysis​

-- Sales trend analysis
WITH sales_trends AS (
    SELECT 
        DATE(document_date) as sales_date,
        SUM(net_value) as daily_sales,
        LAG(SUM(net_value)) OVER (ORDER BY DATE(document_date)) as prev_day_sales
    FROM sap_read_table('VBAK')
    WHERE document_date >= CURRENT_DATE - INTERVAL '90 days'
    GROUP BY DATE(document_date)
)
SELECT 
    sales_date,
    daily_sales,
    prev_day_sales,
    (daily_sales - prev_day_sales) / prev_day_sales * 100 as daily_growth,
    AVG(daily_sales) OVER (ORDER BY sales_date ROWS BETWEEN 6 PRECEDING AND CURRENT ROW) as weekly_avg
FROM sales_trends
ORDER BY sales_date DESC;

3. Comparative Analysis​

-- Year-over-year comparison
WITH current_year AS (
    SELECT 
        MONTH(document_date) as month,
        SUM(net_value) as monthly_sales
    FROM sap_read_table('VBAK')
    WHERE YEAR(document_date) = 2024
    GROUP BY MONTH(document_date)
),
previous_year AS (
    SELECT 
        MONTH(document_date) as month,
        SUM(net_value) as monthly_sales
    FROM sap_read_table('VBAK')
    WHERE YEAR(document_date) = 2023
    GROUP BY MONTH(document_date)
)
SELECT 
    c.month,
    c.monthly_sales as current_year_sales,
    p.monthly_sales as previous_year_sales,
    (c.monthly_sales - p.monthly_sales) / p.monthly_sales * 100 as yoy_growth
FROM current_year c
JOIN previous_year p ON c.month = p.month
ORDER BY c.month;

Dashboard Implementation​

1. Python Dashboard with Streamlit​

import streamlit as st
import duckdb
import pandas as pd
import plotly.express as px
import plotly.graph_objects as go

# Connect to DuckDB
conn = duckdb.connect('sap_dashboard.db')

# Dashboard title
st.title("Real-Time SAP Dashboard")

# Sales metrics
st.header("Sales Performance")
sales_data = conn.execute("""
    SELECT 
        DATE(document_date) as sales_date,
        SUM(net_value) as daily_sales
    FROM real_time_sales
    WHERE document_date >= CURRENT_DATE - INTERVAL '30 days'
    GROUP BY DATE(document_date)
    ORDER BY sales_date
""").fetchdf()

# Create line chart
fig = px.line(sales_data, x='sales_date', y='daily_sales', 
              title='Daily Sales Trend')
st.plotly_chart(fig)

# Inventory levels
st.header("Inventory Levels")
inventory_data = conn.execute("""
    SELECT 
        material,
        unrestricted_stock,
        stock_level
    FROM inventory_monitoring
    WHERE stock_level = 'LOW'
    ORDER BY unrestricted_stock ASC
""").fetchdf()

st.dataframe(inventory_data)

# Financial health
st.header("Financial Health")
financial_data = conn.execute("""
    SELECT 
        account,
        net_balance,
        balance_status
    FROM financial_health
    ORDER BY ABS(net_balance) DESC
    LIMIT 10
""").fetchdf()

# Create bar chart
fig = px.bar(financial_data, x='account', y='net_balance', 
              color='balance_status', title='Top 10 Accounts by Balance')
st.plotly_chart(fig)

2. R Shiny Dashboard​

library(shiny)
library(DBI)
library(plotly)
library(DT)

# Connect to DuckDB
con <- dbConnect(duckdb::duckdb(), "sap_dashboard.db")

# UI
ui <- fluidPage(
    titlePanel("Real-Time SAP Dashboard"),
    
    sidebarLayout(
        sidebarPanel(
            selectInput("plant", "Select Plant:", 
                       choices = c("1000", "2000", "3000")),
            dateRangeInput("date_range", "Date Range:",
                          start = Sys.Date() - 30,
                          end = Sys.Date())
        ),
        
        mainPanel(
            tabsetPanel(
                tabPanel("Sales", plotlyOutput("sales_chart")),
                tabPanel("Inventory", DT::dataTableOutput("inventory_table")),
                tabPanel("Financial", plotlyOutput("financial_chart"))
            )
        )
    )
)

# Server
server <- function(input, output) {
    
    # Sales chart
    output$sales_chart <- renderPlotly({
        query <- paste0("
            SELECT 
                DATE(document_date) as sales_date,
                SUM(net_value) as daily_sales
            FROM real_time_sales
            WHERE document_date BETWEEN '", input$date_range[1], "' AND '", input$date_range[2], "'
            GROUP BY DATE(document_date)
            ORDER BY sales_date
        ")
        
        data <- dbGetQuery(con, query)
        
        plot_ly(data, x = ~sales_date, y = ~daily_sales, type = 'scatter', mode = 'lines') %>%
            layout(title = "Daily Sales Trend")
    })
    
    # Inventory table
    output$inventory_table <- DT::renderDataTable({
        query <- paste0("
            SELECT 
                material,
                plant,
                unrestricted_stock,
                stock_level
            FROM inventory_monitoring
            WHERE plant = '", input$plant, "'
            ORDER BY unrestricted_stock ASC
        ")
        
        data <- dbGetQuery(con, query)
        DT::datatable(data, options = list(pageLength = 20))
    })
    
    # Financial chart
    output$financial_chart <- renderPlotly({
        query <- "
            SELECT 
                account,
                net_balance,
                balance_status
            FROM financial_health
            ORDER BY ABS(net_balance) DESC
            LIMIT 10
        "
        
        data <- dbGetQuery(con, query)
        
        plot_ly(data, x = ~account, y = ~net_balance, 
                color = ~balance_status, type = 'bar') %>%
            layout(title = "Top 10 Accounts by Balance")
    })
}

# Run the application
shinyApp(ui = ui, server = server)

Performance Optimization​

1. Query Optimization​

-- Optimize queries for real-time performance
CREATE INDEX idx_sales_date ON real_time_sales(document_date);
CREATE INDEX idx_inventory_plant ON inventory_monitoring(plant);

-- Use materialized views for complex calculations
CREATE MATERIALIZED VIEW sales_summary AS
SELECT 
    DATE(document_date) as sales_date,
    COUNT(*) as order_count,
    SUM(net_value) as total_sales
FROM sap_read_table('VBAK')
WHERE document_date >= CURRENT_DATE - INTERVAL '90 days'
GROUP BY DATE(document_date);

2. Caching Strategy​

-- Implement caching for frequently accessed data
CREATE TABLE sales_cache AS
SELECT * FROM sap_read_table('VBAK')
WHERE document_date >= CURRENT_DATE - INTERVAL '1 day';

-- Refresh cache periodically
CREATE OR REPLACE FUNCTION refresh_sales_cache()
RETURNS VOID AS $$
BEGIN
    DELETE FROM sales_cache;
    INSERT INTO sales_cache
    SELECT * FROM sap_read_table('VBAK')
    WHERE document_date >= CURRENT_DATE - INTERVAL '1 day';
END;
$$ LANGUAGE plpgsql;

3. Parallel Processing​

-- Use parallel processing for large datasets
SELECT * FROM sap_read_table('VBAK')
WHERE document_date >= CURRENT_DATE - INTERVAL '1 day'
USING PARALLEL 4;

Monitoring and Alerting​

1. System Health Monitoring​

-- Monitor system health.
-- PRAGMA sap_rfc_ping raises on failure, so wrap it as a stored procedure or
-- run it from your scheduler and record the outcome in a status table.
CREATE TABLE IF NOT EXISTS sap_health_log(check_time TIMESTAMP, healthy BOOLEAN);

-- Example: run on a cron and append the result
INSERT INTO sap_health_log
SELECT CURRENT_TIMESTAMP, TRUE;  -- after a successful `PRAGMA sap_rfc_ping;`

CREATE VIEW system_health AS
SELECT
    'SAP_CONNECTION' AS component,
    CASE WHEN healthy THEN 'HEALTHY' ELSE 'UNHEALTHY' END AS status,
    check_time
FROM sap_health_log
QUALIFY ROW_NUMBER() OVER (ORDER BY check_time DESC) = 1
UNION ALL
SELECT
    'DATA_FRESHNESS' AS component,
    CASE
        WHEN MAX(extraction_time) > CURRENT_TIMESTAMP - INTERVAL '5 minutes' THEN 'HEALTHY'
        ELSE 'STALE'
    END AS status,
    CURRENT_TIMESTAMP AS check_time
FROM real_time_sales;

2. Performance Monitoring​

-- Monitor query performance
CREATE VIEW query_performance AS
SELECT 
    query_text,
    execution_time,
    rows_returned,
    memory_used
FROM duckdb_query_log()
WHERE execution_time > INTERVAL '1 second'
ORDER BY execution_time DESC;

Best Practices​

1. Data Freshness​

• Real-time Updates: Refresh data every 1-5 minutes
• Incremental Updates: Only update changed data
• Fallback Mechanisms: Handle connection failures gracefully
• Data Validation: Verify data quality and completeness

2. Performance​

• Query Optimization: Use indexes and materialized views
• Caching: Implement strategic caching for hot data
• Parallel Processing: Use multiple threads for large datasets
• Resource Management: Monitor memory and CPU usage

3. User Experience​

• Loading Indicators: Show progress for long-running queries
• Error Handling: Provide meaningful error messages
• Responsive Design: Ensure dashboards work on all devices
• Customization: Allow users to personalize their views

4. Security​

• Access Control: Implement proper user authentication
• Data Encryption: Encrypt sensitive data in transit and at rest
• Audit Logging: Log all dashboard access and queries
• Compliance: Ensure compliance with data protection regulations

Troubleshooting​

Common Issues​

1. Slow Query Performance: Optimize queries and add indexes
2. Connection Failures: Implement retry logic and fallback mechanisms
3. Data Staleness: Check extraction schedules and connection status
4. Memory Issues: Monitor memory usage and implement pagination

Debugging Tips​

-- Enable query logging
SET log_level = 'debug';

-- Check system status
SELECT * FROM system_health;

-- Monitor performance
SELECT * FROM query_performance;

-- Test connection (raises on failure)
PRAGMA sap_rfc_ping;

Conclusion​

Building real-time SAP dashboards with ERPL and DuckDB provides significant advantages over traditional approaches:

• Real-time Data: Immediate access to SAP data
• High Performance: DuckDB's optimized execution engine
• Simplified Architecture: Direct connection without ETL complexity
• Cost Effective: Reduced infrastructure and licensing costs

The combination of ERPL's SAP connectivity and DuckDB's analytical capabilities creates a powerful platform for real-time business intelligence.

Next Steps​

Ready to build your own real-time SAP dashboard? Here's how to get started:

1. Install ERPL: Get started with installation
2. Explore Examples: Review key tasks
3. Build Your Dashboard: Use the provided examples as templates
4. Contact Us: Get help with your specific requirements

Additional Resources​

• ERPL Documentation
• DuckDB Documentation
• Streamlit Documentation
• R Shiny Documentation
• Contact Our Team for personalized guidance

Discover how ERPL transforms SAP data integration for data science workflows. This comprehensive guide covers everything from data extraction to machine learning model deployment, showing how ERPL enables data scientists to work directly with SAP data using familiar tools and frameworks.

Introduction​

Data science teams often struggle with SAP data integration, facing challenges like complex ETL processes, data latency, and limited access to real-time data. ERPL revolutionizes this by providing direct, SQL-based access to SAP data through DuckDB, enabling data scientists to focus on analysis rather than data engineering.

Why ERPL for Data Science?​

Traditional Challenges​

• Complex ETL: Multiple tools and processes required
• Data Latency: Delayed access to updated data
• Limited Flexibility: Rigid data structures and formats
• High Costs: Expensive licensing and infrastructure
• Skill Gaps: Need for specialized SAP knowledge

ERPL Advantages​

• Direct Access: Real-time SAP data access
• SQL Interface: Familiar query language
• High Performance: DuckDB's optimized execution
• Cost Effective: Single extension license
• Easy Integration: Works with popular data science tools

Data Science Workflow with ERPL​

1. Data Extraction and Exploration​

-- Store credentials once as a DuckDB secret
CREATE SECRET sap (
    TYPE sap_rfc,
    ASHOST 'sap-server.com',
    SYSNR '00',
    CLIENT '100',
    USER 'data_scientist',
    PASSWD 'password',
    LANG 'EN'
);
PRAGMA sap_rfc_ping;

-- Explore available tables
SELECT * FROM sap_show_tables(TABLENAME => '*CUSTOMER*');

-- Get table metadata
SELECT * FROM sap_describe_fields('KNA1');

-- Extract customer data for analysis
SELECT
    KUNNR AS customer_id,
    NAME1 AS customer_name,
    LAND1 AS country,
    ORT01 AS city,
    REGIO AS region
FROM sap_read_table('KNA1', MAX_ROWS => 1000)
WHERE LAND1 = 'DE';