3 posts tagged with "CLI"

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.

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.