Open Steamgate - taking ABAP Development Offstack

Open Steamgate - taking ABAP Development Offstack

| Alice Vinogradova |

Vibe Coding Offstack

YouTube

Spotify

Apple

Episode #311

Introduction

In episode 311 of our SAP on Azure video podcast we talk about Open Steam Gate (OSG) and off-stack ABAP development.

Not only in the context of AI development with SAP, off-stack development is becoming more and more important. But what does this mean in practice, and how far can you take it?

In today’s episode, we are happy to welcome back Alice Vinogradova. Together we explore OSG, how it builds on ABAP transpilation and open tooling, and how it enables faster local dev-change-test loops, browser-based runtime scenarios, and a new VS Code-centered development experience.

Find all the links mentioned here: https://www.saponazurepodcast.de/episode311

Reach out to us for any feedback / questions:

#Microsoft #SAP #Azure #SAPonAzure #ABAP #VSCode #OpenSource #DeveloperTools #AgenticAI #CleanCore

Summary created by AI

  • Open Steam Gate Architecture And Purpose:
  • Alice explained to Holger that Open Steam Gate provides a lightweight, open ABAP runtime that can execute ABAP-derived applications outside a complete SAP system, enabling faster development and testing feedback loops.
    • Development Feedback Loop: Holger described the limitation of extracting ABAP code with ABAP Git: developers still need to return the code to an SAP system, activate it, and run it to validate changes. Open Steam Gate addresses this by providing the foundational runtime and activation capabilities outside a full SAP installation, avoiding the overhead of starting an application server, database, and related SAP services for small iterations.
    • Runtime Scope: Holger and Alice clarified that Open Steam Gate is not a complete ERP system and does not include business domains such as finance or procurement or the full set of SAP standard business logic and BAPIs. It is intended as a foundation for ABAP development, including scenarios such as creating and testing OData services.
    • Testing With Mocks: Alice explained that unit-test scenarios can run outside the system when dependencies are sufficiently isolated. Test doubles, mock data, and stubs for SAP standard code can represent unavailable application-server components, allowing code to be tested before it is transported back into SAP.
    • Agentic Development: Alice connected the shorter feedback loop to agentic development. Multiple agents can iterate on code in isolated lightweight runtimes instead of contending for SAP transports and locks, while completed code can be returned to a real SAP system through ABAP Git.
  • Browser And Container Demonstrations:
  • Alice demonstrated Open Steam Gate running as a browser-based progressive web application and in Docker, while Holger highlighted that the demonstrations execute without a conventional SAP kernel, dispatcher, ASCS, or full ABAP backend.
    • Browser Execution: Alice showed that ABAP transpiled to JavaScript can run in a browser, including both backend-like processing and frontend rendering. The progressive web app can be opened from GitHub Pages and used on a mobile device; Alice reported that the iPhone demonstration rendered the workload smoothly without requiring an external SAP connection.
    • System Status: Alice showed a system-status view identifying the browser as the host and describing the lightweight runtime state. The runtime exposed a single process port and represented services such as OData, applications, and channels through the Open Steam Gate environment rather than through a conventional SAP installation.
    • Application Examples: The browser demonstration included system information, a data browser, Workbench content, OData-related applications, and sample services. Alice explained that the system-status application itself was implemented with CDS-based artifacts and that the environment used layered content packs to add code and scenarios.
    • Container Execution: Alice then showed Open Steam Gate running in a Docker container managed through Portainer. She connected to the container using Eclipse ADT, using the local instance port and a local development password, demonstrating that the same runtime can be accessed from standard SAP development tooling.
  • Debugging Tracing And Validation:
  • Alice described detailed tracing and demonstrated code execution, debugging, SQL access, and unit-test integration as mechanisms for finding differences between Open Steam Gate and a conventional ABAP stack.
    • Detailed Tracing: Alice explained that the first major diagnostic capability was a detailed trace of execution, including the positions and values involved in rendering each frame. Comparing traces from the conventional ABAP stack and Open Steam Gate made it possible to identify where behavior diverged, such as differences in mathematical implementations.
    • Time-Travel Diagnosis: Alice described storing variables and execution state at each step so developers can inspect several traces, locate divergence in the call graph, and work backward to identify the variable responsible. She presented this as a basis for more automated root-cause analysis.
    • Eclipse Debugging: In Eclipse, Alice opened ABAP objects and executed CDS and database-related operations against the local Open Steam Gate container. Holger asked whether breakpoints could be used; Alice said the capability was uncertain in Eclipse and noted that VS Code provided a more native direction for the tooling.
    • VS Code Tests: Alice showed that the VS Code extension discovers unit tests from the repository and presents their results inside the editor. The extension is intended to provide a native development workflow with test execution, debugging, system inspection, and source navigation.
  • VS Code Extension And ADT Integration:
  • Alice demonstrated a VS Code extension that starts Open Steam Gate locally, exposes ABAP services and artifacts, supports OData inspection and breakpoints, and provides a development workflow without requiring users to launch Docker separately.
    • Extension Startup: Alice explained that the VS Code extension uses the Node.js runtime already available inside VS Code, allowing Open Steam Gate to run as a thin native extension layer. Holger summarized that users can install the extension and start the local ABAP runtime directly from VS Code instead of managing Docker manually.
    • System Inspection: The extension displayed system information, transactions, services, ICF handlers, APC components, SQL access, short-dump status, and other runtime details. Alice also showed a SQL notebook capability for executing queries against the local system.
    • Code Navigation: Alice navigated from an OData service to its entities and implementation methods using VS Code features such as CodeLens. The service implementation could be invoked from the editor, and the resulting data was displayed within the development environment.
    • Breakpoints And Tests: Alice set a breakpoint in an OData implementation and attempted to inspect local variables while stepping through execution. The live demonstration did not fully populate the expected variable state, but she explained that stepping through code had worked previously and that the extension also supports repository-wide unit-test execution and result reporting.
  • OData Service Generation And Airship Demo:
  • Alice presented the Airship sample repository as a practical learning and demonstration project, including YAML-driven OData service generation, generated ABAP artifacts, and service behavior such as filtering, navigation, and updates.
    • Airship Repository: Alice described the Airship sample as a steampunk alternative to the standard flight examples and said the repository contains installation guidance, basic ABAP examples, OData scenarios, and material associated with the accompanying book and Open Steam Gate releases.
    • YAML Service Definition: Alice explained that an OData service can be described in YAML by defining entities, sets, keys, properties, types, database fields, labels, and read-only or calculated fields. The tooling then generates the project structure and the relevant DPC extension and MPC extension artifacts.
    • Service Builder Alternative: The conventional approach uses the Service Builder to create and export an OData project, but Alice noted that this can involve substantial manual interaction. YAML provides a simpler declarative route while still producing the ABAP project that can be uploaded to a system.
    • Airship Service Behavior: The demonstrated Airship service supported entity retrieval, filtering, ordering, paging, partial MERGE updates, value help, navigation from ships to voyages, and calculated status text. The hand-written DPC extension filled the status text from a separate status table, illustrating how generated service code can be extended.
  • Cross-Platform ABAP Execution:
  • Alice described compiling and running ABAP-related workloads across JavaScript, Go, browsers, mobile devices, and small computer platforms, with Holger identifying this portability as a central direction for the project.
    • Native Go Backend: Alice explained that she wanted a native implementation for her Go-based tooling rather than relying on a JavaScript sidecar. This led to a compiler backend that translates ABAP into native Go, allowing reports and server processes to run as command-line applications.
    • Command-Line Reports: In the Go-based runtime, report parameters can become command-line parameters. When required parameters are not supplied, the application can present a text user interface, allowing ABAP-style interactions outside a traditional SAP GUI environment.
    • Retro Computing Targets: Alice showed that related compiler work can target Z80-based systems and platforms such as the ZX Spectrum, CP/M, and Agon Light. She described the work as a separate compiler path demonstrating that the same or related ABAP logic can execute on constrained hardware.
    • Mobile Execution: Alice demonstrated Open Steam Gate running on an iPhone, emphasizing that the runtime can operate on the device without depending on a remote SAP system. Holger challenged her to extend the work to additional embedded devices, while Alice said future demonstrations could explore that direction.
  • Continuous Testing And Parallel CI:
  • Alice and Holger discussed using lightweight runtimes to run ABAP tests continuously and in parallel, reducing the cost and contention associated with executing every validation cycle on full SAP systems.
    • Parallel Test Runtimes: Alice proposed starting many lightweight Open Steam Gate instances so tests can execute in parallel rather than waiting for shared SAP systems or transport sequences. This would support more frequent validation across branches, agents, or code changes.
    • Continuous Unit Tests: Alice compared the intended workflow to background unit-test tools in other ecosystems: as a developer edits ABAP, tests could run continuously and immediately indicate whether the change remains valid. She noted that this capability was an opportunity rather than a completely implemented feature.
    • CI Simplification: Alice said that testing code outside the SAP system could reduce unnecessary system churn and make CI behavior easier to understand. Holger agreed that the lightweight runtime could support tests running continuously in the background.
  • ABAP Runtime Self-Hosting Research:
  • Alice outlined experimental work to run ABAP tooling within ABAP itself, covering WebAssembly, JavaScript interpreters, and an ABAP compiler path that could make the runtime self-hosting.
    • Runtime Approaches: Alice described several approaches for bringing ABAP tooling onto the ABAP stack, including compiling to WebAssembly, embedding JavaScript interpreters, and compiling the relevant JavaScript or TypeScript subset directly into ABAP and Go.
    • Performance Tradeoffs: Alice said that the JavaScript interpreter approach was too slow for the intended use. The work therefore shifted toward compilation, including a path that translates the relevant TypeScript or JavaScript into an intermediate representation and then into ABAP.
    • Self-Hosting Goal: The longer-term objective is a self-sufficient, self-hosting version of Open Steam Gate. Alice used compiler T-diagrams to explain the chain of tools and languages involved and positioned this as a subject for a future episode.

Links

Video index

Based on and using Hugo Cookbook Theme, Font Awesome Icons and Bulma CSS. | Thanks to Recipes4AJ to get me started. | Contact me via | Imprint & Privacy | Cookie settings