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.
