6 posts tagged with "ABAP"

Every integration tool has two speeds: the one in the benchmark, and the one you actually experience on the first day. For erpl-rev those two numbers were embarrassingly far apart. It replicates 10 million BSEG-shaped rows in about a minute, and 2.5× faster than that since August. Getting to the point where you could run that benchmark took an afternoon.

Not because anything was hard. Because it was scattered. A type-T destination here. A function group there. Eight Z_DUCKDB_* function modules. Fourteen ABAP objects. A reginfo line in a file only Basis can touch. Four documents, each correct, none of them the whole path.

This post is the whole path, and it is now short enough to time with a stopwatch.

In June I wrote up erpl-rev — the little registered RFC server that lets ABAP call out into DuckDB — and it replicated 10 million rows of a 400-column BSEG-shaped table in about a minute. That post did not just claim a number, it explained why the number was what it was.

Since then I put it under a profiler to find out what was still on the table. Two things came back, pulling in opposite directions. A step that genuinely earned its place in June still had about a third of the ingest path left in it. And a constraint I had treated as fixed — SAP's proprietary RFC library — turned out to be removable altogether.

Picture the data team at a mid-sized manufacturer. Every night they need a fresh copy of the FI line items — BSEG and friends — in their lakehouse, where the analysts actually live: DuckDB, Parquet on object storage, the odd Iceberg table. The table is wide (hundreds of columns) and deep (tens of millions of rows), and the window is tight. The "official" answer is SLT: stand up a replication server, license it, configure the per-table settings in LTRS, babysit the queue. It works. It is also a lot of machinery — and budget — for what is, conceptually, "read this table fast and write it somewhere open."

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.

← Part 1: Your SAP Data Is Already Real-Time

In Part 1, a mid-size manufacturer's forecasting team got a live, validated, DuckDB-native view of their SAP order and customer data — fresh within five minutes, anomalies caught at the gate, no warehouse in the middle.

This post is Part 2. It answers the next two questions: how does the AI agent actually reach that data, and what happens when the data is wrong?

The short version: we publish the view as a REST endpoint and an MCP tool with flAPI so the agent can call it, and when the agent finds a bad number it reads the ABAP behind the view, writes a patch, and files a transport with erpl-adt.

Picture the ecommerce team at a mid-sized retailer. They have just shipped a customer-support chatbot — the LLM-driven kind that fields the "where's my order?" and "can you change the delivery address?" tickets that used to eat a third of the call-centre's day. The bot is good. It is also wrong about fifteen percent of the time, because the order data it reasons about is six hours stale: a nightly job dumps VBAK to a Parquet file, the bot reads the file, and customers find out the bot does not know about anything they ordered after lunch.

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.

We built erpl-adt because we got tired of Eclipse being the only way to interact with ABAP systems programmatically. If you wanted to search objects, read source code, or run unit tests against SAP — you had to use Eclipse ADT. No CLI, no scriptable API client, nothing you could plug into a CI pipeline or hand to an AI agent.

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.