Ai-Abap-Development-Series on Marian Zeis Blog

ARC-1 1.0: One Deployment, Multiple SAP Systems

Mon, 03 Aug 2026 07:00:00 +0200

When I published the first ARC-1 post, I explained why I built an MCP server for ABAP development and why security has to be part of it from the beginning. This post is not another deep dive into every tool. The release notes already do that.

For version 1.0 I want to focus on what really changed: ARC-1 became more stable, it can serve multiple SAP systems from one BTP deployment, the BTP and security setup is much better documented, and the project is no longer only one repository.

Most of this happened because people used ARC-1, asked difficult questions, reported problems, opened issues and pull requests, sent me private messages, and invited me to Teams meetings about their plans and experiences. That is the most important part of this release.

What version 1.0 means

Version 1.0 does not mean ARC-1 is finished. It means there is now a stable base.

ARC-1 now has a clearer scope. It is a controlled connection between AI assistants and ABAP systems. It can run locally for one developer or centrally on SAP BTP for a team. It supports classic on-premise ABAP, S/4HANA, BTP ABAP Environment, and S/4HANA Cloud Public Edition.

It stays read-only by default. Changing code, reading business data, running SQL, changing transports, or using Git has to be enabled separately. This makes it possible to start small and only allow more when a team is ready.

The new multi-system mode is still marked as experimental because parts of the setup and behavior may change. But it can already be used and is running in productive BTP environments, not only in my own setup.

That is what 1.0 means to me: not that every possible ADT feature exists, but that the foundation, operating model, and safety boundaries are clear enough to build on.

This release was built through feedback

The first versions were mostly based on my own systems and workflows. That changed quickly. SAP systems, releases, login setups, networks, and transport processes are too different to understand from one landscape.

Public issues and pull requests brought real system shapes into the project. A few examples:

Wouter Lemaire added the first BTP Cloud Foundry deployment, followed it with deployment and write fixes, and continued to give very practical guidance on BTP, destinations, and how a shared ARC-1 service should be operated.
Sami Bouguerra contributed NetWeaver 7.50 probe fixtures and cookie handling, then fixed cases where activation looked successful although SAP had not activated the object in PR #179.
Clément Ringot made BTP login more reliable across deployments in PR #212 and PR #267, and fixed Cloud Connector response handling in PR #440.
Geert-Jan Klaps added S/4HANA Public Cloud support. I do not have access to such a system myself, so his contribution made it possible to add and verify this landscape in ARC-1.
Community pull requests added table queries, newer package creation, safer transport handling, better BTP login, configurable server names, and cookie rotation. You can find them in the repository’s pull requests.

Not every useful contribution was code. Issues such as multi-system connections and how to structure several systems on BTP changed the architecture and documentation. Reports from older systems improved release detection and fallbacks. Questions from Basis and security people forced me to make assumptions explicit instead of hiding them in configuration examples.

I also received many private messages and joined Teams meetings about ARC-1. Some people explained how their teams want to deploy it on BTP and walked me through their real landscape and requirements. Others pointed out security issues, unclear documentation, or places where the safety boundaries were not strong enough. These conversations directly improved login, error handling, audit information, package restrictions, user identity, and the deployment guides.

Thank you especially to everyone who reported a security concern privately. That is exactly how an open-source security process should work. ARC-1 now has a public security policy, private vulnerability reporting, automated checks for code and dependencies, container checks, and an inventory of the software included in each release.

One ARC-1 instance, multiple SAP systems

The biggest addition in version 1.0 is the experimental multi-system mode.

You can now deploy one ARC-1 application on SAP BTP Cloud Foundry and attach several SAP systems or clients through destinations in the same subaccount. An administrator chooses which destinations belong to ARC-1. It does not connect to every destination by accident.

This is already used in productive BTP environments. Experimental in this case means that configuration and behavior can still change as more landscapes use it. It does not mean that the feature is only a local proof of concept or that people cannot use it today.

Each system and client gets its own MCP address. There is also an optional combined connection for tasks that really need several systems. A system-specific address is the safer choice for normal work because the conversation is already connected to the correct target.

Keeping the real user identity is the recommended setup. A user logs in on BTP and the identity is forwarded to SAP. SAP then checks the same authorizations the person already has. A shared technical user is possible for special cases, but it gives less clear responsibility and needs more care.

This feature started with community requests and Wouter’s first multi-backend implementation. His code and BTP experience gave the final design important groundwork. The production-focused design, security review, tests, and administrator documentation then landed in PR #579.

The biggest changes in short

I do not want to explain every feature here. These are the areas that matter most for 1.0:

Safer operation: ARC-1 starts read-only. Higher-risk actions are separate choices, SAP still decides what the user may do, and teams get limits and audit information for shared use.
More SAP compatibility: testing and fixes now cover older NetWeaver systems, several S/4HANA releases, ABAP Platform 2025, BTP ABAP Environment, and S/4HANA Cloud Public Edition.
Better BTP guidance: the BTP overview, Cloud Foundry guide, user identity guide, updates, rollback, destinations, roles, and multi-system operation are now documented as one path.
Reusable workflows: 22 included skills cover RAP, tests, migrations, Clean Core analysis, transport reviews, system documentation, and more.
More checks before a release: ARC-1 runs automated tests against the code and real SAP systems, checks dependencies and containers, and publishes information about what is included in a release.

For the exact technical list, including fixes for transport state, ABAP object types, BTP token exchange, tracing, and protocol compatibility, use the release notes and the GitHub v1.0.0 release.

Skills for complete SAP tasks

ARC-1 1.0 includes 22 skills. A skill is a reusable workflow for an AI assistant. It gives the assistant a tested way to approach a larger task instead of relying on one large prompt.

The included skills cover creating RAP services and logic, ABAP and CDS tests, analytical models and queries, explaining and documenting existing code, finding slow SQL, Clean Core and S/4HANA migration work, unused-code checks, transport overviews and reviews, and modernizing legacy UI5 applications. There are also helpers to understand a system first, create a local ABAP mirror, and review an AI session. The full skills catalog has the complete list and installation options for Claude Code, GitHub Copilot, Cursor, Codex, and other assistants.

The SEGW-to-RAP skill deserves a special mention. It reads an existing SEGW OData V2 service, including its model and custom code, and guides the move to a modern RAP V4 service. My SEGW-to-RAP post got one of the biggest responses of the whole ARC-1 series. That was a clear signal that many teams are not only interested in creating something new. They also need practical help to modernize the large amount of existing SAP applications.

Extensions for your own SAP APIs

ARC-1 will never include every custom API or company-specific endpoint. Forking the complete server for one internal tool is also difficult to maintain.

The extension framework gives you another option. It lets you add your own tools and reuse the SAP connection, safety checks, and audit path of the ARC-1 instance. This can be useful for an internal service or any API that is not part of the standard ARC-1 tools.

The extension sample shows a simple configuration option and a code option. It also shows the safety limits. An extension cannot give itself more access than the ARC-1 instance already has, and changes still need to be enabled explicitly. Code extensions run inside ARC-1, so they should be reviewed like any other dependency.

LISA is already a useful real example. It provides SAP translation tools as a standalone MCP server and as an ARC-1 extension. This proves both paths can work: build a separate focused service, or attach the capability to an existing ARC-1 deployment.

Reusing the BTP authentication stack

Login and keeping the correct SAP user were some of the hardest parts of ARC-1. Other SAP MCP servers need the same foundations, so this code is now available as the separate @arc-mcp/xsuaa-auth package.

It provides the core pieces for deploying an MCP server to SAP BTP Cloud Foundry: login through XSUAA, reuse of BTP destinations, connections through Cloud Connector, and forwarding the real user to SAP. A project can reuse this setup and keep its own focused SAP API instead of copying the full ARC-1 server.

ARC-1 uses the package itself. LISA and ROSA use it as well, and BW Modeling MCP now uses it for its central SAP BTP Cloud Foundry setup. For me this is an important part of the release. The value of ARC-1 is not only the number of ABAP tools. The deployment and security principles can now help other projects too.

A new home for the project

ARC-1 moved from my personal GitHub account to the arc-mcp organization. There is also a dedicated landing page, full documentation at docs.arc-1-mcp.com, and a live replay demo that works without a SAP system, credentials, or a live LLM.

The organization now contains the main product, reusable components, experiments, and demos that are still active:

arc-1: the main SAP ADT MCP server.
xsuaa-auth: reusable XSUAA, OAuth, and BTP Principal Propagation.
arc-1-extension-sample: examples for custom ARC-1 tools.
adt-ls: a TypeScript SDK for SAP’s headless ADT language server.
arc-1-lsp: an experimental MCP server built on that language-server path.
arc1-adt-abap-mcp-ext: an Eclipse extension adding read-only tools to SAP’s ADT MCP server.
arc-1-abap-cicd-review: an ABAP review workflow with GitHub Actions, abaplint, AI review, and live SAP checks.
arc1-transport-review-poc: a proof of concept for reviewing SAP transports through pull requests.
arc-1-segw-to-rap: the SEGW, RAP, UI5, and Fiori elements modernization demo.
arc-1-mcp.com: the source of the landing page.
live-arc-1: the source of the interactive replay demo.

Not every repository has the same maturity. ARC-1 is the stable core. Some projects are reusable packages, some are beta, and some are intentionally proofs of concept. Keeping them separate makes this more visible and lets each idea develop without making the main server bigger.

Where to start

If you are new to ARC-1, use the quickstart with a development or sandbox system and start read-only. The live demo is useful if you first want to see how the workflows and tool calls look.

For a team deployment, start with the BTP overview. Decide the topology, identity model, destinations, and responsibilities before enabling more capabilities. Principal Propagation should be the normal choice when SAP needs to see the human user.

If you already run ARC-1, follow the update guide and review the release notes. For production, pin a version instead of using latest, keep the first acceptance test read-only, and review the current SAP API policy and your own agreements before enabling data preview or free SQL.

ARC-1, SAP’s MCP server, and the API policy

SAP now also provides its own ABAP MCP server as part of the ABAP Development Tools. I do not see this as an either-or decision.

SAP’s server is the natural choice for a developer who works inside VS Code or Eclipse and wants to reuse the existing IDE connection. ARC-1 has a different focus. It can run as a shared service on BTP, serve different AI clients and team workflows, cover classic and modern ABAP use cases, and give administrators one place for access rules and audit information. Many teams can use both.

The detailed ARC-1 and SAP ABAP MCP Server comparison explains where each option fits, where each one is stronger, and where each one has limits. It is meant as a decision guide, not as a sales comparison.

More important for a wider rollout is the SAP API Policy and architecture guide.

ARC-1 uses the ADT interfaces behind SAP’s ABAP development tools. These interfaces have been used by SAP and third-party developer tools for many years, but the ADT web endpoints are not listed as published APIs in the SAP Business Accelerator Hub. SAP’s current API policy also talks directly about access by generative AI and autonomous agents.

At the same time, SAP has published an architecture for third-party MCP servers. ARC-1 is close to this architecture, especially when it runs on SAP BTP Cloud Foundry with BTP login, destinations, Cloud Connector, the real SAP user identity, traffic limits, and audit logging. This is a good technical fit, but it is not by itself a legal approval for every customer and every landscape.

My recommendation is simple. Start in development or test, start read-only, and keep SAP authorizations in control. Before a broader or production rollout, ask your SAP contact whether your agreement allows third-party tools to use the ADT endpoints in this way. The policy and SAP guidance can change, so check the current documents instead of relying only on this post.

Thank you

ARC-1 1.0 is not the result of one large feature. It is the result of many small reports, tests, discussions, fixes, and reviews.

Thank you to everyone who opened an issue or pull request, tested another SAP release, shared a BTP setup, challenged a security decision, built an extension, tried the documentation, or sent a private message. Even when I could not implement an idea directly, the feedback helped make the project clearer and safer.

Feedback is still greatly appreciated. Open an issue when something does not work or the documentation is unclear. Send a pull request when you have a fix or improvement. A private message is also welcome, especially when you want to share details about a real landscape or raise a security concern.

Version 1.0 is a milestone, not the end. Now there is a stable base, public documentation, a clearer security process, and a growing set of reusable projects around it.

Before You Upgrade S/4HANA: Static UI5 Checks with MCP

Wed, 20 May 2026 23:00:00 +0200

Series note: This post is part of my AI ABAP development series. It reuses the legacy UI5 app from the SEGW to RAP migration demo, but this time the focus is only on the UI5 version upgrade problem.

In the SEGW to RAP post I used a deliberately old freestyle UI5 app as migration material. It runs on SAPUI5 1.84.59 and contains many patterns that were normal in older projects: jQuery.sap.require, global formatters, synchronous bootstrap, Belize theme, older manifest versions, and a few small controller workarounds.

That is a useful demo app because it is close to the kind of thing you find during S/4HANA upgrades. The backend migration is one problem, but the UI5 version jump is another one.

The process should look something like this: First, you identify the old and new UI5 versions. Then you read through the changelogs and What’s New pages to see what has changed. Next check which APIs have been deprecated or which themes have been removed, and search the documentation for possible replacements. Then you apply those findings to the app and start the app to see if the fixes work.
But usually you start the app with the new version and hope for the best and fix things you find there.

That works, but it is a lot of manual context switching. The release notes are broad, the app only uses a small part of UI5, and the important question is not “what changed in UI5?”. The useful question is:

What changed in UI5 that matters for this app?

What Changed

I added a new ui5_version_diff tool to my SAP Docs MCP server in mcp-sap-docs PR #47.

The tool is backed by ui5-lib-diff. A small change in ui5-lib-diff PR #11 now publishes a static JSON API for tools.

The important part is that the MCP server does not send HTTP requests at runtime. During setup it downloads the all-changes.json bundle once. At runtime the tool reads the local bundle and filters it by version range, change type, UI5 library, or query text.

That makes it much more useful for agents. The UI5 Lib Diff app is still great for humans, because you can visually compare versions at ui5-lib-diff.marianzeis.de. But an agent needs structured data it can filter without opening a client-rendered UI route.

The second part is the official UI5 MCP server from SAP. That server can inspect a local UI5 project and run UI5-specific checks.

This is important: these checks run against the app source code in a local checkout, for example the version cloned from your Git server. They are not executed against the deployed app in the SAP system or against a running launchpad tile. The deployed app still needs runtime testing later, but the first evidence can come from the local project before that.

In this run the useful tools were:

get_project_info
get_version_info
run_ui5_linter
run_manifest_validation
optionally get_api_reference and get_guidelines for follow-up details

So the split is clear:

SAP Docs MCP says what changed between UI5 versions.
UI5 MCP says what the local app actually uses and what fails.

That combination is the interesting part.

The Run

For the showcase I used a local clone of the same legacy UI5 app from the arc-1-segw-to-rap repo. I also used the workflow in ui5-versions-upgrade.md.

The prompt was basically:

i want to upgrade the legacy-ui5-app from version
use ui5-versions-upgrade.md to produce a good markdown

The skill tells the agent to first establish the scope, then inspect the project, then cross-check deprecations with the linter and code, then look for fixes and relevant features. It also tells the agent not to dump the full changelog into the report.

For the demo app the report found:

current version: SAPUI5 1.84.59
target version: SAPUI5 1.147.2
resolved diff range in the local bundle: 1.84.56 to 1.147.0
339 versions in range
3,540 features
15,249 fixes
985 deprecations
961 SAPUI5 What’s New entries

That sounds like too much information, and it is. The point of the workflow is to reduce it.

The UI5 linter and manifest validation made the report concrete. It did not just say that some API somewhere is deprecated. It found issues in this app:

jQuery.sap.require and jQuery.sap.declare
global sap.* usage
synchronous bootstrap
missing async component configuration
old sap_belize theme and themelib_sap_belize
sap.m.MessagePage
manifest _version 1.40.0
old minUI5Version
ambiguous XML event handlers
old UI5 Tooling setup

That is exactly the kind of list I want before I start the live browser test. It does not replace testing the deployed app, but it removes a lot of blind work before testers touch the running application.

Narrowing the Changelog

The broad range query is only the starting point. After that the agent used narrower calls:

types=["DEPRECATED"] to focus on migration blockers
types=["FEATURE"] with ui5_library="sap.m" or sap.f
query="jQuery.sap" to inspect relevant deprecations
query="setTimeout" to see if a local workaround matches a framework fix

That last point is the more interesting long-term use case. During upgrades we often carry workarounds forward because nobody knows if the original UI5 bug still exists. With a searchable version diff, an agent can look for a symptom or API and then check whether a fix landed between the old and new version.

It still has to verify the local code. A changelog entry is not proof that a workaround can be deleted. But it gives the agent a much better starting point than asking it to guess from memory.

The generated report is here:

legacy-ui5-app-upgrade.md

The report is not a replacement for a real migration. It is the first step: concrete evidence for what may need to change. For this demo it already produced a useful edit plan: update tooling, switch theme, migrate the manifest, enable async loading, clean module usage, replace deprecated controls, then rerun linter and manifest validation.

The next step can use the same MCP tools again, but now for implementation. You do not have to apply every finding at once. You can ask the agent to fix only the theme and manifest issues, only the jQuery.sap.* usage, or the full list. That is basically the same pattern I showed in the SEGW to RAP post when the legacy freestyle UI5 app was converted into a modern UI5 TypeScript app: inspect first, use UI5-specific tools, implement, then rerun linting, manifest validation, type checks, and browser checks.

If a finding needs more explanation, the same SAP Docs MCP server can still search SAPUI5 documentation and fetch more detail. For API-level replacement details, the UI5 MCP server can also use get_api_reference.

Why I Like This Pattern

The useful shift is that the model is no longer asked to “know UI5 upgrades”. It is given tools that expose the right context:

the version diff tells it what changed
the project info tells it what the app uses
the linter tells it what is actually wrong
the manifest validator tells it what the framework accepts
the docs tools can fill gaps when a finding needs detail

That is a much better workflow than manually reading release notes until you hope you found everything.

It is especially useful for larger version jumps, for example during S/4HANA upgrades where the UI5 version changes a lot. But I think it also helps for smaller minor upgrades. Even then, you want to know if a workaround is still needed, if a deprecation starts to matter, or if a newer UI5 feature lets you simplify code.

The important boundary is still the same: the report is a first pass, not the final migration. You still need to edit, run the app, test the flows, and check the actual behavior. But the first pass can now be app-specific evidence instead of a generic changelog review, and the same tools can then help with the actual changes.

For me that is the real value of MCP in SAP development. Not magic. Better context at the point where the model needs to reason.

References and Links

ABAP Development Automation with ARC-1 and GitHub Workflows

Tue, 12 May 2026 09:00:00 +0200

Series note: This post is part of my AI ABAP development series. In the previous posts I introduced ARC-1, then used it from BTP, Copilot Studio, Joule Studio, and a SEGW to RAP migration.

This post is about GitHub workflows as an ARC-1 development automation surface.

ABAP teams already have strong SAP-side tooling: ATC, Code Inspector, ST22, ADT, and the activated source in the SAP system. GitHub has a different strength: pull requests, review comments, checks, labels, issues, and automation.

The problem is that those worlds usually do not meet cleanly. abapGit can push ABAP source to GitHub, abaplint can run static checks, and Copilot or Claude can review a diff. But without access to the SAP system, the automation only sees text. It cannot run ABAP Unit, call ATC, compare against the activated object, inspect ST22, or verify what the SAP system actually knows.

The underlying idea comes from the Patterns for using LLMs in ABAP development document by Lars Hvam from Heliconia Labs. The relevant pattern is section 2.7, Git / Off-Stack with read-only MCP. ABAP source lives in Git. Pull requests, CI/CD, static analysis, and human review stay in the Git workflow. The MCP server gives the LLM read-only context from the SAP system, but does not let it write directly into the system.

So I created a small sample repository for this pattern: github.com/arc-mcp/arc-1-abap-cicd-review.

This is my ARC-1 implementation of the idea. GitHub is the workflow surface. abapGit connects the repository and the SAP system. ARC-1 is the SAP automation gateway that lets GitHub workflows execute SAP-side checks and gives AI reviewers read-only SAP context through MCP.

What The Sample Shows

The sample repository contains a small ABAP package ZARC1_DEMO in abapGit format. The package is deliberately small. The interesting part is what can be automated around it when GitHub can reach SAP through ARC-1.

It covers three development automation scenarios:

PR checks for ABAP code: abaplint, ABAP Unit, and ATC.
PR review with SAP context: Copilot and Claude can review with live SAP reads instead of only the diff.
Operational follow-up: ARC-1 can check ST22 dumps on a schedule, create GitHub issues for new dumps, and trigger a deeper investigation from a label.

The repo has six small workflow files: pr.yml, sap-tests.yml, copilot-review-trigger.yml, claude-review-trigger.yml, sap-dump-triage.yml, and sap-dump-deep-dive.yml. ARC-1 is the common backend. GitHub Actions is only the automation surface.

Architecture And Setup

The architecture follows the Git / Off-Stack with read-only MCP pattern:

Developer / IDE / LLM
  -> local ABAP files
  -> GitHub repository
  -> pull requests, code reviews, CI/CD
  -> abapGit
  -> SAP system

GitHub Actions / review automation
  -> ARC-1 MCP endpoint on SAP BTP
  -> read-only ADT context from the SAP system

The Git repository is the collaboration surface. It contains source files, pull requests, review comments, labels, and CI/CD checks. That is where the AI can propose changes and where a human keeps the gate.

The SAP system remains the source of truth for activated ABAP source, syntax checks, dumps, package content, and system-specific context. GitHub has the PR diff, but GitHub is not the runtime.

ARC-1 sits between GitHub and SAP. In my setup it runs on SAP BTP Cloud Foundry. GitHub Actions calls the ARC-1 /mcp endpoint over HTTPS with an API key. ARC-1 validates the key profile and then connects to the SAP system through the BTP destination. The technical SAP user is configured in that destination, not in GitHub.

GitHub runners and AI tools do not get SAP credentials. They only get the ARC-1 URL and a scoped API key. The SAP system itself is not exposed to GitHub runners.

The API key used in the demo has a viewer-sql profile. That means read access, SQL/table preview where needed, diagnostics, navigation, and linting. It does not expose write tools like SAPWrite, SAPActivate, SAPManage, SAPTransport, or SAPGit.

That last point matters. I do not want the first version of this pattern to be “AI writes ABAP from a PR comment”. The safer and more useful first version is:

AI can read the real SAP system.
AI can explain what it found.
AI can propose changes in a PR review.
Humans still decide what gets applied.

The setup has five parts.

First, get the ABAP source into GitHub with abapGit. The exact setup depends on the system and repository authentication. The important point is that ABAP objects are available as normal files in GitHub, and approved changes can later be pulled back into SAP through the normal abapGit process.

Second, deploy ARC-1. For this sample I use the BTP Cloud Foundry deployment because it gives GitHub Actions a public HTTPS endpoint while the SAP backend remains behind BTP connectivity. ARC-1 needs a destination to the ABAP system. The technical user is configured there and should only have the permissions needed for the checks you want to run. ARC-1 then adds the API key profile on top.

Third, configure GitHub Actions secrets and variables:

ARC1_URL
ARC1_API_KEY
ANTHROPIC_API_KEY
COPILOT_TRIGGER_PAT

ARC1_URL points to the ARC-1 endpoint. ARC1_API_KEY is used by the SAP test gate and the Claude workflows. ANTHROPIC_API_KEY is needed for Claude Code Action. COPILOT_TRIGGER_PAT is needed for the Copilot trigger workflow because comments posted by the default GITHUB_TOKEN do not trigger @copilot mentions.

Fourth, configure Copilot Coding Agent. In the repository settings, the Copilot Cloud Agent gets an MCP configuration for ARC-1. The important detail is the tool allowlist: Copilot should see the read-side tools it needs for review, not the write-side tools.

Fifth, decide which workflows you actually want. For a first rollout I would start with abaplint, the SAP test gate, and one AI review path. The scheduled dump check is useful because it helps you see new runtime problems before someone reports them manually, but it is a separate operational pattern. You do not need to enable everything on day one.

PR Automation Layers

Layer 1: abaplint

The static layer is intentionally boring.

Every pull request runs abaplint through reviewdog. Findings appear as check annotations, inline comments where GitHub allows it, and a sticky summary comment. The workflow gates only on findings introduced by the PR diff. Existing findings stay visible, but they do not block a PR that did not create them.

If abaplint can catch it, abaplint should catch it. It is fast, deterministic, and basically free apart from GitHub Actions minutes.

In the sample PR, abaplint found existing issues in the class and test class. That is useful, but it did not catch the main semantic issue in the PR: a direct SELECT from MARA added inside a task service method. The code is syntactically valid. The problem is architectural and Clean Core related.

Layer 2: ABAP Unit and ATC

The next layer is still not AI. Here ARC-1 is simply the gateway connector from GitHub Actions into SAP.

sap-tests.yml runs on every PR that touches src/. It parses the abapGit filenames, maps them back to ABAP object types, and then calls ARC-1 directly from Bash. There is no model involved in this part.

For changed classes it runs ABAP Unit through SAPDiagnose with action="unittest". For changed classes, interfaces, programs, and function groups it runs ATC through SAPDiagnose with action="atc". The result is posted as a sticky PR comment, and line-specific ATC findings are posted inline on the Files Changed tab when GitHub can attach them to the diff.

The gate is simple: failing or erroring unit tests fail the job, and P1/P2 ATC findings fail the job. P3 findings are visible but do not block.

The clean demo is PR #20. It adds one more unit test to ZCL_ARC1_TEST_HELPERS. The workflow reports 7 of 7 ABAP Unit tests passing and one non-blocking P3 ATC warning.

There is one important assumption here. The test workflow runs against activated objects in SAP. That matches the normal abapGit loop I use: edit, activate, push. If your team pushes before activation, you need a PR sandbox system or a pre-step that pulls and activates before this workflow runs.

Layer 3: AI review without MCP

GitHub’s built-in Copilot Code Review can be assigned from the PR sidebar. That is already useful. It reads the diff and can catch common problems from the text alone.

In the sample PR #14, Copilot Code Review did catch the direct SELECT from MARA as a Clean Core hotspot. That is a good result.

But this review has an important limitation: it is still a diff-only review. It cannot know whether the object is already activated in SAP. It cannot ask the system for callers. It cannot inspect ST22. It cannot prove that a claim is backed by the current SAP system.

That does not make it useless. It just means it is one layer.

Layer 4: AI review with ARC-1

The MCP-backed review is the more interesting part.

In the repo, applying the copilot:review label posts a canonical @copilot review ... prompt to the PR. Copilot Coding Agent then uses the ARC-1 MCP server configured in the repository settings.

Applying the claude:review label starts anthropics/claude-code-action in GitHub Actions. The workflow writes an MCP config file, allows only selected ARC-1 tools, loads the prompt from claude-review-prompt.md, and asks Claude to post one pull request review.

The prompt is deliberately concrete:

Use 2 to 5 ARC-1 tool calls.
Read the changed ABAP object from SAP.
Check for GitHub to SAP drift.
Only navigate references when the public contract changed.
Do not repeat abaplint or SAP test gate findings.
Post inline comments on changed lines.
Use GitHub suggestion blocks when the fix is concrete.

This makes the review auditable. The model still reasons, but important claims can point back to tool results.

In PR #14, the decisive ARC-1 call was a SAPRead of the activated ZCL_ARC1_TASK_SERVICE~LIST_TASKS method from SAP. Claude then posted the key finding: the MARA block is not only a direct SAP table access, it also changes the meaning of list_tasks. A task service should not silently return no tasks because the material master has no finished product.

It also did the useful drift check:

The activated ZCL_ARC1_TASK_SERVICE~LIST_TASKS in SAP matches the pre-PR source.
The MARA block is not yet activated, as expected for an open PR.
No unexpected drift.

That is the small sentence that justifies the whole architecture. A diff-only reviewer cannot know that. ARC-1 can.

Demo PRs

The main demo is PR #14. It contains one harmless refactoring and one deliberately bad preflight inside ZCL_ARC1_TASK_SERVICE~LIST_TASKS:

select single matnr from mara
  into @data(lv_dummy_matnr)
  where mtart = 'FERT'.
if sy-subrc <> 0.
  return.
endif.

This is deliberately wrong for the demo. It creates a hard dependency from a task service to the MM material master and reads a SAP-standard table directly. If product validation is needed, it should go through a released API or CDS view, and the service should not hide the reason by returning an empty list.

That PR is useful because it shows several review surfaces on the same diff:

abaplint finds static issues, but not the MARA problem.
the SAP test gate adds live ABAP Unit and ATC results for changed objects.
Copilot Code Review sees the diff and flags the MARA access, but cannot verify SAP state.
Copilot Coding Agent with ARC-1 can combine diff review with live SAP reads, syntax, navigation, and release checks.
Claude with ARC-1 posts a focused review with inline comments, suggestion blocks, and the SAP drift check.

The separate SAP test gate example is PR #20: one extra test method, 7 of 7 ABAP Unit tests green, and a single non-blocking P3 ATC finding.

One-click suggestions

Both Copilot and Claude can post GitHub review comments with suggestion blocks. That means the PR shows the same “Apply suggestion” button a human reviewer would get.

This is now verified in PR #14. Copilot Code Review and Claude both suggested deleting the MARA preflight block. Claude’s version adds the SAP-side evidence on top: SAPRead confirmed that this block is not part of the currently activated method, so the review can separate “new in this PR” from “already active in SAP”.

The two screenshots below are from the same lines in PR #14. Copilot shows the diff-only version of the review. Claude shows the same GitHub suggestion UX, but with the SAP-side drift evidence from ARC-1.

The prompt asks for suggestion blocks only when the fix is concrete. A wrong suggestion block is worse than a normal comment because it invites the reviewer to apply it without thinking.

This is not a replacement for a proper feature branch. It is just a good review UX for small, local fixes.

Operations Automation

Autonomous dump triage

The repo also has an operations pattern for staying ahead of runtime issues.

The sap-dump-triage.yml workflow asks ARC-1 for recent ST22 dumps through SAPDiagnose. It can run on a schedule, deduplicates dumps against existing GitHub issues by storing the dump ID in an HTML comment marker, and creates one issue for each new dump with metadata, a short Claude triage, and an urgency label.

For the sample repo, the cron is disabled so the issue list stays stable. In a real setup, I would turn it on so GitHub becomes a lightweight watch list for new dumps instead of waiting until someone reports the same runtime error again. The current examples are visible through the sap:dump label.

This is the part I like most conceptually:

cheap shallow triage for everything
expensive deep investigation only when needed

That is a much better cost model than asking the LLM to deeply inspect every dump forever.

Deep dive on demand

The second stage is the sap-dump-deep-dive.yml workflow. A human applies the dump:investigate label to a dump issue. The workflow extracts the dump ID, reads the full dump through ARC-1, reads the failing ABAP source, and posts one investigation comment.

The best demo is issue #15, an OBJECTS_OBJREF_NOT_ASSIGNED_NO dump in CL_ENH_ADT_ENHO_OBJ_PERSIST.

Claude found a very concrete root cause. In GET_DATA_FROM_TOOL, the first CASE l_enhtooltype block creates r_object_data, but it handles only BAdI and hook enhancement tool types. The dump variables showed I_ENHO_TOOL as CL_ENH_TOOL_WDY, a Web Dynpro enhancement tool. Because that tool type is not handled, r_object_data stays initial. The next dereference at line 30 raises CX_SY_REF_IS_INITIAL.

The interesting detail is that there is a second CASE block later in the same method with a WHEN OTHERS guard, but execution never reaches it because the null dereference happens earlier.

That is the kind of analysis I want from this setup. It used the dump, selected variables, call stack, and source code. It did not just say “probably a null reference”. It explained why the reference was null and where the missing guard belongs.

The deep-dive comment then updates the labels from needs-triage to dump:investigated. So GitHub becomes the lightweight operations board, while SAP remains the source of truth.

How I Would Use This

For a small ABAP team, I would start with this sequence:

Push ABAP source to GitHub with abapGit.
Run abaplint on every PR.
Run ABAP Unit and ATC through ARC-1 on every PR.
Use Copilot Code Review as a cheap, generic first AI review if you already have Copilot.
Add claude:review or copilot:review only when the PR needs deeper SAP context.
Enable dump triage manually first.
Turn on the scheduled dump check once the issue noise level is understood.
Use dump:investigate only for dumps that are recurring, high urgency, or unclear.

This keeps the workflow understandable. Not every PR needs a deep AI review, and not every dump needs full investigation. Static and deterministic checks should do the boring work first.

The label interface is intentionally simple:

copilot:review triggers Copilot Coding Agent with ARC-1.
claude:review triggers Claude Code Action with ARC-1.
sap:dump marks a dump tracker issue.
needs-triage means the shallow workflow created the issue.
dump:investigate triggers the deep-dive workflow.
dump:investigated means the deep dive has already posted its analysis.
urgency:high, urgency:medium, and urgency:low make the issue list sortable.

The labels are the UI. That keeps the pattern easy to teach and easy to extend.

Boundaries And Next Steps

Limitations

Copilot Code Review and Copilot Coding Agent are not the same thing. The sidebar review is useful, but it does not use the MCP server. For MCP context, this repo uses label-triggered workflows.

GitHub-hosted runners must reach the ARC-1 endpoint. That is why BTP Cloud Foundry is a good demo topology. If ARC-1 is only available inside a private network, use self-hosted runners or another controlled network path.

The SAP user behind the BTP destination still matters. Even with a read-only ARC-1 key, the workflow can read what that technical user can read. In a real setup, scope both the SAP user and the ARC-1 API key deliberately.

The SAP test gate runs against activated objects in SAP. That fits the edit, activate, push flow. If your team pushes before activation, use a PR sandbox system or add a controlled pull and activate step before the checks run.

And AI review is still review. The goal is not to replace an ABAP developer. The goal is to catch useful things earlier, with enough evidence that a developer can decide quickly.

What else this pattern can do

Once the plumbing exists, the same pattern can be used for more than PR review.

A scheduled Clean Core audit could read a package through ARC-1, check released API usage, and open GitHub issues. A multi-system setup could expose arc-1-dev, arc-1-qa, and arc-1-prod as separate MCP servers and compare what is active in each system.

The SAP test gate can also grow beyond this small demo. Full ATC variants, Code Inspector checks, transport checks, and package-level baselines can all surface in the same PR interface developers already use.

The next obvious step is the post-merge path. After a PR is merged to main, a GitHub workflow could call ARC-1 with a separate git-scoped key and run an abapGit pull through SAPGit for the package in the SAP system.

SAP -> abapGit -> GitHub -> AI review -> merge -> ARC-1 pull -> SAP

I would keep that write path separate from the review key, gated by branch, labels, or environment approvals. If the pull has conflicts or activation problems, the workflow should report that back and stop.

That is also where the operations loop becomes interesting: detect a dump, investigate it, propose a fix PR, review it, merge it, and pull it back into SAP. The client can change. The governed SAP access layer stays the same.

Takeaway

This is the direction I find practical for ABAP development automation.

Do not start with “AI should write all ABAP”. Start with a safer and more useful question:

Can the development workflow become better if GitHub automation can safely use the actual SAP system?

For me, the answer is clearly yes. Not because the model magically understands ABAP, but because ARC-1 brings missing SAP context into the workflow: activated source, ABAP Unit, ATC, references, dumps, syntax checks, and system-specific evidence.

abapGit gets the code into GitHub. abaplint covers the static layer. ARC-1 runs ABAP Unit and ATC from GitHub Actions, and gives AI a read-only window into SAP. Copilot and Claude become more useful reviewers because they can stop guessing and start checking.

That is the main thread of this sample: GitHub is the automation surface, ARC-1 is the SAP gateway, and humans still decide what gets merged.

References And Links

From SEGW and Legacy UI5 to RAP with ARC-1

Mon, 11 May 2026 09:00:00 +0200

Series note: This post is part of my AI ABAP development series, where I go from AI development in general, to ABAP-specific problems, and then to ARC-1.

In the last posts I introduced ARC-1, explained why I built it, showed the BTP architecture, and then used it from Copilot Studio and Joule Studio. Those posts were mostly about architecture and possible use cases.

This one is different. This is the use case ARC-1 was originally built for: making real SAP development easier.

A lot of SAP customers are still somewhere between old ECC-style custom development and the S/4HANA world they actually want to reach. The uncomfortable part is that “moving to S/4” can easily become a technical lift and shift. The old custom code moves, the old OData services move, the old UI patterns move, and after the migration the landscape is still not really modern. It just runs somewhere newer.

That is not the direction I find interesting. If we already touch those applications, then we should also ask where it makes sense to move them toward RAP, OData V4, Fiori elements, cleaner APIs, and a development model that fits the Clean Core direction much better.

So I built a small but complete demo for that:

a legacy SEGW OData V2 service
a legacy freestyle UI5 JavaScript app
a new RAP OData V4 service
a modern UI5 TypeScript app
a Fiori elements app on top of the RAP service

The full workspace, generated code, ABAP sources, screenshots, and chat logs are published here:

github.com/arc-mcp/arc-1-segw-to-rap

The Starting Point

The demo starts with a small project management application on an S/4HANA 2023 trial system, ABAP Platform 7.58. The legacy backend sits in package ZDEMO_MIG and uses three custom tables: ZDM_PROJECT, ZDM_TASK, and ZDM_TIMEENTRY.

On top of that sits the SEGW service ZDEMO_MIG_PROJECTS_SRV. It exposes ProjectSet, TaskSet, and TimeEntrySet, with navigation from projects to tasks and from tasks to time entries. The one bit of behavior is the ApproveProject function import, which changes the project status.

This is the old service in SAP Gateway Service Builder. You can see the classic SEGW shape directly: entity types, properties, navigation associations, entity sets, and the function import sitting next to the data model.

The old UI is a classic master/detail app. The left side shows projects, the right side shows the selected project with tasks and time entries. It works, but it also contains the kind of patterns many SAP teams know too well: manual OData V2 model creation, global formatters, synchronous bootstrap, path string parsing, jQuery.sap.require, manual function import calls, and UI state that is partly stitched together in controller code.

The backend is similar. The generated MPC class describes the model, and the DPC_EXT class contains the custom logic. For the demo I made the legacy code deliberately rough: manual reads, ignored filters in some places, no authority checks, manual navigation handling, and an ApproveProject function import that updates the project status directly.

That is a good migration target because the interesting question is not “can an AI write a RAP sample from scratch?”. The more useful question is:

Can it inspect the old service, understand the contract, and create a modern replacement that keeps the functional shape?

The Skills

For this run I did not just write one big prompt. I used three ARC-1 skills from the maintained arc-1/skills folder: migrate-segw-to-rap, modernize-ui5-app, and convert-ui5-to-fiori-elements.

The folder is worth looking at beyond this demo. It also contains skills for RAP service generation, ABAP test generation, code explanation, custom-code migration, Clean Core checks, documentation, and system-context setup. The idea is that ARC-1 does not only provide tools, but repeatable workflows around those tools.

The point of these skills is not that they are perfect generic migration products. They are templates for a process.

That distinction matters. The real value is that the skill forces the agent into a structured workflow:

Read the instructions first.
Inspect the old system and source code before designing anything.
Print the extracted model and plan.
Stop for confirmation before writes.
Create the new artifacts.
Activate, publish, lint, typecheck, and smoke test.
Use the feedback from those gates before calling the run done.

This is much closer to how I want agentic SAP development to work. Not “please convert my system” and hope for the best, but a guided workflow with discovery, constraints, acceptance gates, and real SAP system access.

For the run, I used Cursor with Composer-2. I did that intentionally. This was not meant to be a best-case frontier-model demo. It should be closer to what people might actually try in an IDE with a good but not magical model.

That is also why the skills matter so much. A detailed skill moves part of the intelligence out of the model and into the workflow: what to read first, when to stop, which tools to use, which checks must pass, and what the target shape should look like. The model still has to reason, but it does not have to invent the whole process from scratch.

The MCP setup was split by responsibility. ARC-1 handled the SAP system side: object reads, writes, activation, transports, and service binding work. SAP Docs MCP Server gave RAP and CDS documentation context. UI5 MCP Server and SAP Fiori MCP Server were used for the frontend conversion and validation steps.

The net execution time for the three guided runs was below 20 minutes. That does not include the time I spent before the final run building the demo, improving the skills, and learning from earlier failed attempts. But for the final guided process itself, this was comfortably under 20 minutes.

Prompt 1: SEGW to RAP

The first prompt asked the agent to run the migrate-segw-to-rap skill against ZDEMO_MIG_PROJECTS_SRV. The full transcript is in llm-chat-history/prompt-1-segw-to-rap.

The important part is what happened before the agent wrote anything. ARC-1 first probed the system and confirmed the real constraints: ABAP 7.58, RAP availability, transport access, search access, and write access. The agent then tried the obvious generated MPC naming, discovered that this SEGW service used the generated ZCL_ZDEMO_MIG_PROJECTS_* class names, and read the MPC class as the source of the OData model. After that it read the DPC_EXT class, because the interesting behavior was not in the metadata. It was in the custom code, especially the ApproveProject function import.

Only after that discovery step did it print the extracted model and stop for ok:

Project
  key ProjectId
  navigation Tasks

Task
  key TaskId
  foreign key ProjectId
  navigation TimeEntries

TimeEntry
  key EntryId
  foreign keys TaskId, ProjectId

Function import
  ApproveProject(ProjectId) -> Project

After confirmation, ARC-1 created the RAP stack under ABAP_SRC/src/dm. This is where the migration becomes interesting on the ABAP side.

The root interface view ZI_DM_PROJECT selects from ZDM_PROJECT and models tasks as a RAP composition child. The same pattern continues with ZI_DM_TASK and ZI_DM_TIMEENTRY. So the old OData navigation model becomes a RAP business object structure instead of staying as manual navigation handling in DPC_EXT.

The interface behavior definition ZI_DM_PROJECT is managed, uses strict ( 2 ), and enables draft. It maps the nicer RAP field names like ProjectId, StartDate, and EstimatedHours back to the old table fields like project_id, start_date, and estimated_hours. It also defines the project as the lock master and the child entities as dependent by project. The draft tables ZDM_PROJECT_D, ZDM_TASK_D, and ZDM_TIMEENTRY_D are part of that generated target shape.

The projection layer then exposes the service-facing model. ZC_DM_PROJECT is a transactional query projection on the interface view, redirects _Tasks to ZC_DM_TASK, and carries metadata extension support. The projection behavior ZC_DM_PROJECT reuses create, update, delete, draft actions, and the new approve action from the interface behavior.

Finally, the service definition ZUI_DM_PROJECTS exposes the projection entities as Project, Task, and TimeEntry, and the service binding ZUI_DM_PROJECTS_O4 publishes them as OData V4.

The new service is OData V4 and published through the service binding:

/sap/opu/odata4/sap/zui_dm_projects_o4/srvd/sap/zui_dm_projects_o4/0001/

The old ApproveProject function import became a RAP action:

action approve_project result [1] $self;

The behavior implementation no longer does a direct UPDATE ... COMMIT WORK in the old DPC_EXT style. It uses RAP EML in local mode, updates the project status, and lets the RAP runtime handle the transactional context.

The logs also show why this is not just text generation. The agent had to deal with real ABAP Platform 7.58 details: where the provider contract belongs, how draft table fields need to be named, which timestamp annotations are available, and how the projection behavior should reuse the interface behavior. These are exactly the details that make a generated RAP example look easy and a real migration annoying.

That is the first Clean Core angle of the demo. It does not magically make every old custom object clean. But it moves the service shape away from a SEGW/DPC_EXT implementation and toward a RAP business object, CDS projections, behavior definitions, OData V4, draft support, and metadata-driven UI consumption.

For an ECC to S/4HANA journey, this is the kind of direction I would rather see than only lifting old custom services into the new system.

Prompt 2: UI5 JavaScript to UI5 TypeScript

The second prompt converted the legacy freestyle UI5 JavaScript app into a modern UI5 TypeScript app. The transcript is in llm-chat-history/prompt-2-js-to-ts.

Here the agent did not just rewrite files. The skill forced it to understand the old component setup, manifest, controllers, XML views, formatter logic, model setup, bootstrap, package scripts, and UI5 tooling config before writing the new app.

The UI5 MCP Server was the guardrail around that work. Before writing code, the agent used it for TypeScript conversion guidance and general UI5 guidelines. That shaped the target app: a real TypeScript scaffold, @sapui5/types, typed controller events, async loading, manifest-driven models, and no old jQuery.sap.* patterns. It also created the modern UI5 app scaffold and later ran the UI5 linter and manifest validation. Those checks are important because plain TypeScript compilation does not understand UI5-specific conventions, XML event-handler rules, or manifest schema details.

The UI result is mostly relevant here because it proves that the RAP service was usable from a real consumer. The old app talked to /ProjectSet, followed Tasks, and called ApproveProject as an OData V2 function import. The new freestyle app talks to the RAP V4 entity set /Project, follows _Tasks, and calls approve_project as a bound OData V4 operation. The app itself also moved from JavaScript controllers and a manual OData V2 model to TypeScript controllers, manifest-driven OData V4, FlexibleColumnLayout routing, imported formatter modules, and real lint/typecheck gates.

The new app consumes the RAP V4 service directly from its manifest:

"dataSources": {
  "mainService": {
    "uri": "/sap/opu/odata4/sap/zui_dm_projects_o4/srvd/sap/zui_dm_projects_o4/0001/",
    "type": "OData",
    "settings": {
      "odataVersion": "4.0"
    }
  }
}

The action call in the detail controller also changed from the old OData V2 function import style to a bound OData V4 operation:

const operation = model.bindContext(
  "com.sap.gateway.srvd.zui_dm_projects.v0001.approve_project()",
  ctx
);
await operation.invoke("$auto");

The UI is still recognizable, but the app is now using a modern runtime and tooling setup.

This part is important because many real SAP teams cannot immediately replace every freestyle UI5 app with Fiori elements. Sometimes a freestyle app is still the right target. But even then, there is a big difference between old UI5 JavaScript glued to a SEGW V2 service and a modern TypeScript app consuming a RAP V4 service.

The run ended with the important gates green: ESLint, UI5 linter, manifest validation, TypeScript typecheck, and a browser render check.

That is the second lesson from the logs: the model needed tooling feedback. It was not enough to let it generate code once. The loop with UI5 MCP, linting, manifest validation, and browser verification made the result useful.

Prompt 3: Legacy UI5 to Fiori Elements

The third prompt took a different path. Instead of converting the old freestyle app to another freestyle app, it rebuilt the user-facing contract as a Fiori elements V4 list report and object page. The transcript is in llm-chat-history/prompt-3-js-to-fiori-elements.

This is the more interesting Clean Core direction for many S/4HANA projects. A lot of old UI5 code exists because the backend metadata did not carry enough UI intent, or because the old stack made custom frontend code feel like the default. With RAP and Fiori elements, more of the application can move into CDS annotations and behavior.

The agent mined the legacy UI for the actual user contract: the columns from the old master list, search behavior, project header fields from the detail view, task table columns, time entry navigation from a selected task, Approve as a project action, and the status, priority, and date semantics that used to live in the formatter.

Then it moved that contract into RAP UI metadata, mainly through the ZME_DM_PROJECT, ZME_DM_TASK, and ZME_DM_TIMEENTRY metadata extensions. That is where the old UI intent becomes @UI.headerInfo, line items, selection fields, facets, field groups, presentation variants, search metadata, and semantic keys.

The SAP Fiori MCP Server had a different role than the UI5 MCP Server. It did not translate freestyle controller code into another set of controllers. It exposed the Fiori tools workflow for an external OData V4 list report and object page: discover the available generation capabilities, inspect the required generator configuration, and shape the app around a project name, target folder, UI5 version, service URL or metadata file, and main entity Project. In other words, it kept the frontend target inside the standard Fiori elements model instead of letting the conversion drift back into custom page wiring.

That also makes the split of responsibility clearer. ARC-1 and SAP Docs MCP helped create and correct the RAP annotations in the ABAP backend. Fiori MCP helped define and generate the Fiori elements application that consumes those annotations through $metadata.

The result is a Fiori elements list report on the RAP Project entity. The generated app manifest is also in the repo, under modern-fe-app/dm-projects-fe/webapp/manifest.json.

And the object page uses the RAP annotations and navigation model, including general data, audit data, and a tasks table.

This is the third lesson from the logs: Fiori elements migration is not mainly a JavaScript conversion. It is a relocation of intent.

Old freestyle UI5 had the intent spread across controllers, XML views, formatters, routing, and manual binding code. The Fiori elements version moves much of that intent into the RAP service metadata. That is not always the right answer for every app, but when it fits, it is exactly the direction I would prefer for S/4HANA custom apps.

What The Logs Show

I included the Cursor chat exports in the repository because I think the transcript is more useful than a polished final result alone.

The SEGW to RAP run has 140 tool records. That is the most important transcript for this post because it shows ARC-1 reading the legacy service, extracting the model from the generated classes, creating the RAP artifacts, activating them, and publishing the service binding. The UI5 TypeScript run has 142 tool records and is mostly about making the new V4 service usable from a freestyle app. The Fiori elements run has 230 tool records because it had to mine the old UI and move more intent into annotations.

There are a few patterns that stand out.

First, the model needed real SAP context. It did not know the generated class names until ARC-1 searched the system. It did not know the exact service binding shape until ARC-1 read it. It did not know the old ApproveProject behavior until it inspected the DPC_EXT source.

Second, the skills mattered. Without the skills, the model would probably start writing too early. With the skills, it had to read, extract, summarize, stop, then write.

Third, the MCP servers had different jobs. ARC-1 was the SAP system bridge. SAP Docs MCP Server gave release and documentation context. UI5 MCP Server and SAP Fiori MCP Server grounded the frontend work in current UI5 and Fiori conventions.

Why This Is More Than A Conversion Demo

The obvious reading of this demo is “AI converted old code to new code”. That is true, but it is not the main point for me.

There are now companies like Nova Intelligence and Conduct working on SAP custom-code understanding and modernization. I think that is a good signal for the space. My angle here is different: how far can you get with open-source tools, your own AI setup, and MCP servers whose code you can actually inspect?

This kind of setup is not as polished as a full commercial SAP modernization platform. But the tradeoff is interesting. ARC-1 is open source, the SAP Docs MCP server is open source, and the UI5 and Fiori MCP servers are open-source SAP tooling. You can see what the tools do, adapt the skills, run the workflow against your own system, and understand why the agent made a decision. For many teams, that transparency matters as much as the raw automation.

The more important point is that this is the kind of workflow SAP teams need when they want to move away from lift and shift.

In a pure lift-and-shift migration, the old application survives almost unchanged:

SEGW service stays SEGW
DPC_EXT logic stays DPC_EXT logic
UI5 JavaScript stays UI5 JavaScript
OData V2 stays OData V2
custom UI logic stays custom UI logic

That may be necessary in some places. But if you do that everywhere, the new S/4HANA system inherits most of the old custom development model.

In this demo, the target shape is different:

SEGW contract -> RAP business object
OData V2 -> OData V4
DPC_EXT function import -> RAP action
manual UI wiring -> typed UI5 or Fiori elements metadata
frontend-only intent -> CDS annotations where possible

That is much closer to the Clean Core direction. Not because custom code disappears. It does not. But because the custom code is expressed in newer, more structured extension technologies that fit S/4HANA better.

For real projects I would still be careful. A large productive SEGW service can contain much more complex behavior than this demo. It may call BAPIs, use conversion exits, have custom authorization logic, support deep inserts, or depend on UI assumptions that are not visible in the service metadata. You do not solve that with one prompt.

But that is also why ARC-1 matters. It gives the agent a way to inspect the real objects, not only files copied into a prompt. And with good skills, the agent can be forced to build a migration plan before touching the system.

What I Would Take From This

For me the practical takeaway is:

ARC-1 is strongest when the task needs real ABAP system context.
Skills are the right abstraction for repeatable SAP modernization workflows.
MCP servers should be combined by responsibility, not treated as one magic tool.
RAP and Fiori elements are not just “newer tech”, they give the AI a more structured target model.
Clean Core migration is not only about deleting custom code. It is also about moving useful custom functionality into cleaner extension patterns.

The demo is intentionally small, but the pattern is the part I care about. If an agent can read an old SEGW service, understand a legacy UI5 app, create a RAP V4 service, modernize the freestyle UI, and generate a Fiori elements app in one guided run, then this is a useful direction for real SAP modernization work.

Not as an autopilot that blindly rewrites landscapes, but as a controlled development workflow with real SAP context, clear boundaries, and human review.

That is exactly where I want ARC-1 to go.

References & Links

Discuss this post

ARC-1 with Joule Studio: Bringing Real ABAP System Context into Joule

Wed, 06 May 2026 09:00:00 +0200

Series note: This post is part of my AI ABAP development series, where I go from AI development in general, to ABAP-specific problems, and then to ARC-1.

In the previous post, I showed ARC-1 with Microsoft Copilot Studio. The idea was that SAP system context should not be locked inside a local IDE. If ARC-1 runs centrally on SAP BTP, it can also be used from Teams, Microsoft 365 Copilot, SharePoint, Jira, and other places where functional consultants, architects, support teams, and project leads already work.

This post is the SAP-native version of that idea. If Microsoft Copilot Studio is close to the Microsoft workday, then Joule is close to the SAP workday. SAP describes Joule as the unified assistant experience across SAP’s solution portfolio, and Joule Studio as the place to build custom Joule agents with SAP and non-SAP integrations.

So the question is not only: can Joule call another MCP server? The better question is: can the ARC-1 capabilities be brought to the place where SAP users already ask questions?

What Carries Over From Earlier Posts

ARC-1 is a secure ADT MCP server for ABAP systems. It connects AI clients to SAP systems through ABAP Development Tools APIs and exposes this through tools like SAPRead, SAPSearch, SAPWrite, SAPActivate, SAPContext, SAPDiagnose, SAPTransport, and SAPManage.

For this post, the important part is not the full tool list. It is the operating model from the earlier BTP post:

central server instead of every user laptop
safe by default instead of allow all by default
server ceiling + user permission + SAP authorization
audit logging instead of invisible local tool calls

In the BTP post, I described how ARC-1 can run as a central Cloud Foundry application with XSUAA, BTP destinations, Cloud Connector, Principal Propagation, roles, and BTP audit logging. For Joule Studio, I would not create a second SAP access architecture. I would reuse that controlled endpoint.

What ARC-1 Adds To Joule

Joule already has useful SAP context. SAP has Joule for Developers, Joule for Developers, ABAP AI capabilities, and Joule for Consultants. So this is not about pretending Joule cannot help with ABAP at all.

But there is a difference between a useful standard assistant and a tool that can query my actual ABAP system through ADT, read my custom code, inspect dependencies, run diagnostics, check release state, read ATC findings, and create a system-specific proposal.

That workflow is not something I get just by opening standard Joule. If SAP does not expose this level of ABAP system access in Joule today, a custom MCP server can still bring it there. With ARC-1, Joule is no longer limited to general SAP knowledge or predefined product capabilities. It can ask the real ABAP system.

Not because the model became smarter. Because the tool access became better.

That matters beyond pure development. The same ADT-backed context can help architects with Clean Core planning, functional consultants with impact analysis, support teams with dumps and bug analysis, quality leads with ATC reporting, and developers with implementation proposals.

The Architecture I Would Show

SAP’s Architecture Center describes A2A and MCP for interoperability. The important part for this post is the direction: Joule as the user-facing assistant, A2A for agent-to-agent collaboration, and MCP for tool access. SAP also describes an MCP Gateway in SAP Integration Suite as a governed way to expose SAP and non-SAP APIs, integrations, data sources, and external MCP servers as tools for AI agents.

ARC-1 fits that pattern as the ADT development-tooling adapter:

User in Joule
  -> Joule Studio Agent
  -> SAP Integration Suite API Management / future MCP Gateway
  -> ARC-1 on SAP BTP Cloud Foundry
  -> Destination Service + Connectivity Service
  -> SAP Cloud Connector
  -> SAP S/4HANA or ABAP system
  -> ADT development APIs

ARC-1 can fit the architecture pattern SAP describes. Joule is the user-facing AI entry point, Integration Suite is the governed access layer, ARC-1 is the ADT adapter, and the SAP system stays protected behind BTP connectivity and SAP authorizations.

There are still open points. Joule Studio already supports adding MCP servers through BTP destinations, but the documentation also lists restrictions: the destination must be streamable HTTP and MCP servers requiring interactive OAuth user authorization are not supported. SAP also shows MCP hub capabilities on the roadmap, but from what I can see this is still a future SAP Build capability and not the fully available enterprise MCP hub today.

So I would present this as a target architecture and showcase, not as a final productive setup guide yet.

For the showcase, I configured a Joule Studio agent with a small instruction set, Anthropic Claude Sonnet 4 as model, and two MCP servers: ARC-1 for the ABAP system and the SAP Docs MCP Server for official SAP documentation context. I condensed the screenshots here to show only the relevant configuration parts:

Use Cases I Would Show In This Post

I would not repeat all Copilot Studio examples. The Joule post should show scenarios that make sense because the user starts inside the SAP world, not in Teams or SharePoint.

One note before the screenshots: I was not able to change the language in this Joule setup, so the screenshots are in German. I describe the important parts in English below each screenshot.

The first task for the agent is a Clean Core readiness check for one object. It is narrow enough to be understandable and safe enough because it can be read-only:

Check whether ZCL_ARC1_DEMO_CCORE is clean-core ready.
Use the real SAP system, ATC where possible, API release state, and SAP documentation.
Do not change anything. Return risks, evidence, and suggested next steps.

This is a good first agent task because it shows the difference between “Joule explains Clean Core” and “Joule analyzes this class in this SAP system for Clean Core risk”. ARC-1 reads the ABAP source, dependencies, ATC findings, and API_STATE. mcp-sap-docs adds SAP guidance and released API context. Joule returns a short assessment with evidence.

This is the kind of result I mean:

The screenshot is still a rough showcase, but it already shows the value. Joule is not only giving generic Clean Core advice. It can show that the class is not released for the relevant contracts, that it uses USR02 and BUT000, and that there are no ATC findings in this small example. That is a much better starting point for an architect or developer than a general explanation of what Clean Core means.

I also asked a follow-up prompt for a dependency diagram. The result was almost the answer I wanted: not perfect, but useful because it returned a Mermaid diagram and an evidence table instead of only prose. You can open the translated and rendered full Joule reply here.

The second use case is package-level modernization planning. This is where an agent is useful because it needs multiple tool calls, grouping, prioritization, and a bit more reasoning:

Analyze package ZSD_LEGACY for Clean Core and ABAP Cloud risks.
Group the findings and create a modernization backlog.
Do not change code.

The same agent can combine ARC-1 for package content, dependencies, ATC, release state, and where-used information with SAP documentation for official guidance. The output should be a backlog, not a “fixed everything” claim:

Priority 1: direct SAP table usage with released successors
Priority 2: ATC findings with clear fix direction
Priority 3: objects that need architecture discussion
Priority 4: probably dead or low-value code to review later

This screenshot shows another interesting part of Joule. The response is not only a long text answer. Joule created a left-side list with grouped findings and backlog items, and the selected item is shown with details on the right side:

In this run, the package ZSD_LEGACY did not exist. Joule still searched the system and found 28 ZSD* objects that may represent legacy risks. It grouped them into high, medium, and low risk buckets, and then created a modernization backlog. The selected high-risk card shows temporary $TMP package objects, split into service definitions, tables, and message classes. That is not a final assessment, but it is a useful interactive starting point.

These examples have a better through line for this post than repeating the Copilot Studio demos. Copilot Studio is good when the work starts in Microsoft 365. Joule Studio is good when the work starts in SAP, but still needs real ABAP system context.

Why I Use An Agent Here

For this showcase an agent is perfectly fine. The interesting part is not the packaging. The interesting part is that Joule can call ARC-1 and the SAP Docs MCP Server, collect system evidence, and turn that into something useful for the user.

For ARC-1 I would still keep the first Joule Studio agent conservative: one object or one package, read-only by default, no automatic rewrite. I would not start with a big automation story. I would start with analysis, evidence, and a proposal.

And yes, you can also vibe code with this. If write access is enabled for a development or sandbox system, a Joule Studio agent can propose changes and call ARC-1 to apply them. I just do not want this to be the main story here, because the more important point is the architecture: first give Joule controlled access to real ABAP system context, then decide which write actions are safe enough.

Open Points

The SAP API Policy also matters here, but it should not become the whole post. ARC-1 should be positioned as ADT development tooling, not as a generic business-data extraction layer. Clean Core checks, ATC, code inspection, syntax checks, ABAP Unit, activation, and development support are the story. Data extraction is not the story.

This is also why the Joule Studio architecture is interesting. SAP’s architecture guidance describes SAP Integration Suite and API Management as part of a governed pathway for AI agents, including a governance layer like an MCP gateway in front of APIs. That is much closer to the setup in this post than a local MCP server on a developer laptop. It gives the agent a controlled entry point, central configuration, identity, monitoring, and auditability. It does not mean every possible ADT usage is automatically fine, but the architecture shape is much closer to what SAP is describing for API agents.

Why This Matters

Copilot Studio and Joule Studio are different surfaces:

Copilot Studio = close to Teams, Microsoft 365, SharePoint, Excel, Word, Jira
Joule Studio = close to SAP products, SAP Build, Joule agents, SAP users
ARC-1 = governed ABAP system access layer that can serve both

The client can change, but the security model should not. For me that is the main point. ARC-1 should not be locked to Claude, Cursor, Copilot Studio, or Joule Studio. If the company allows it, the same governed ARC-1 endpoint should be usable from different AI clients.

And ARC-1 is open source, which is important to me. If this kind of access layer becomes part of SAP AI architectures, then people should be able to inspect how it works, challenge the security model, test it against real systems, and decide for themselves if it fits their landscape.

Also, this does not have to start with write access. Even read-only mode is already very powerful. Reading code, dependencies, ATC findings, release state, dumps, messages, packages, and where-used information can help architects, consultants, support teams, and developers without the assistant writing a single line of ABAP.

The target picture is not “AI writes ABAP from a chat prompt”. The better target is:

the user asks inside Joule
Joule has access to the right tools
ARC-1 provides real ABAP system context
SAP documentation provides the official direction
Integration Suite provides governance
SAP authorizations still protect the backend
humans approve the risky parts

That is much more interesting than a local MCP demo. It is also much closer to what I think enterprise ABAP agentic development needs.

Discuss this post

References & links

ARC-1 with Copilot Studio: SAP System Context Beyond Developers

Mon, 04 May 2026 09:00:00 +0200

Series note: This post is part of my AI ABAP development series, where I go from AI development in general, to ABAP-specific problems, and then to ARC-1.

In the previous post, I wrote about running ARC-1 on SAP BTP. That was the architecture part: central deployment, XSUAA, destinations, Cloud Connector, Principal Propagation, roles, and auditability.

This post is the next step. If ARC-1 is already deployed centrally on BTP, then it does not have to be used only from developer tools like VS Code, Claude, Cursor, or Eclipse. It can also be used from Microsoft Copilot Studio and then published into Teams or Microsoft 365 Copilot. That changes the audience quite a bit.

For developers, ARC-1 is mainly an ADT MCP gateway for code, packages, activation, transports, diagnostics, and system context. MCP is the protocol that lets an AI client call external tools, and ADT is the API layer behind ABAP Development Tools. But this SAP system access is not only useful for developers. ARC-1 tools can also expose table structures, selected data, messages, transaction metadata, API release state, feature toggles, FLP content, dumps, transport information, and more. Depending on the enabled ARC-1 tools and SAP authorizations, that can become useful for functional consultants, solution architects, testers, security people, and support teams.

The question for this post is: what happens if the SAP system context is not only available inside an IDE?

Why Copilot Studio fits here

Functional consultants usually do not live in a local IDE. They work in Teams, Excel, Word, SharePoint, Jira, SAP GUI, Fiori, and many other tools around the actual system. So if the only AI access pattern is “install an MCP server locally and configure your IDE”, then we miss a large part of the SAP project team.

Copilot Studio fits here because it is already close to where many business users work. An agent can be published into Teams and Microsoft 365 Copilot. It can use SharePoint as a knowledge source. It can use connectors for systems like Jira Cloud, and the same idea also applies to other enterprise sources like Confluence if there is a connector or MCP server for it. I did not use Confluence in this test, but the architecture would be the same. And since Copilot Studio can connect to existing MCP servers, it can also call ARC-1 when the server is deployed to BTP.

That does not mean everyone should get write access to SAP from Teams. Quite the opposite. For this kind of usage I would start read-only and very controlled. But even read-only is already powerful if the agent can combine:

A business specification from SharePoint.
SAP documentation from the separately deployed mcp-sap-docs MCP server.
Real system context from ARC-1.
Tickets or tasks from Jira.
The conversation interface in Teams.

The Architecture Stays The Same

Copilot Studio should not create a second SAP access architecture. It should use the same BTP-deployed ARC-1 endpoint from the previous post.

Copilot Studio / Teams
  -> ARC-1 MCP endpoint on SAP BTP
  -> XSUAA / OAuth
  -> Destination Service
  -> Cloud Connector
  -> SAP ABAP system

This means the security story does not change only because the client changes. ARC-1 still has the server ceiling. XSUAA roles still control what the user can do in ARC-1. If Principal Propagation is active, ARC-1 does not call SAP as one shared technical user. The signed-in user’s identity is propagated to the ABAP backend, so SAP checks the request with that user’s normal SAP authorizations, for example object, package, transport, table, or S_DEVELOP permissions.

In simpler words: Copilot calls ARC-1 over HTTPS, BTP authenticates the user and resolves the SAP destination, and the Cloud Connector forwards the request to the ABAP system. The server ceiling is the maximum ARC-1 capability the admin enabled for this instance, so a user role can never enable more than the server allows.

For Copilot Studio I would be extra conservative with the first setup:

read/search/diagnose only
data preview only for selected users
free SQL only for selected users
writes disabled by default
transport writes disabled

A Copilot Studio agent can be much more accessible to non-developers than an IDE tool, so the safety model matters even more.

Setup

I would keep the setup simple and reuse the BTP deployment from the previous post:

Deploy ARC-1 on BTP with XSUAA, BTP destinations, and ideally Principal Propagation. The detailed steps are in the BTP deployment guide.
Keep ARC-1 read-only first, or at least very restricted with ARC-1 authorization and roles.
In Copilot Studio, add ARC-1 as an existing MCP server with the public HTTPS endpoint from BTP, for example https://arc1-ecc-dev.cfapps.eu10.hana.ondemand.com/mcp.
Use OAuth 2.0 for the MCP server authentication. Copilot Studio supports manual OAuth configuration for MCP servers, and ARC-1 on BTP can use XSUAA for that.
Add SharePoint as a knowledge source, add the SAP documentation MCP server with its public MCP endpoint https://mcp-sap-docs.marianzeis.de/mcp, and then add other enterprise sources only where they make sense.
Publish the agent to Teams or Microsoft 365 Copilot after testing.

The existing MCP server page also documents Streamable transport and the API key or OAuth 2.0 authentication options. For SAP system access I would not start with API keys unless it is a very controlled automation scenario, because OAuth gives a better identity story.

In my test agent I used ARC-1 on BTP, a Jira MCP server, and SAP Docs as tools. For knowledge, I added SharePoint locations for specifications and IT documents, plus a Jira connector. For this showcase I enabled the available read and write tools.

Microsoft’s own MCP Server for Enterprise points in a similar direction for Microsoft Graph: enterprise context should come through governed endpoints, not random local scripts.

SharePoint And SAP Documentation

The most natural non-developer setup is probably SharePoint plus SAP docs plus SAP system context. SharePoint is where many specifications and project documents already live, and Copilot Studio can use SharePoint as a knowledge source while Microsoft authentication keeps the normal document permissions in place.

But SharePoint alone is not enough. A specification can say what should happen, but it often does not know how the SAP system actually works today. This is where ARC-1 comes in. The agent can ask ARC-1 for current ABAP objects, CDS views, table structures, message texts, service bindings, transaction metadata, or selected table data, depending on what is enabled and authorized in the ARC-1 tool and role model.

Then I would add the separately deployed mcp-sap-docs server as the documentation layer, using the public MCP endpoint https://mcp-sap-docs.marianzeis.de/mcp. It can search SAP documentation, ABAP keyword docs, RAP samples, style guides, DSAG guidelines, SAP Community, and also released object information. That gives the agent a much better chance to not only say “this is possible”, but also explain what SAP recommends and where the current system differs.

This combination is more useful than any single source alone:

SharePoint = what the project wants
Jira = what needs to be solved
mcp-sap-docs = what SAP recommends
ARC-1 = what the SAP system actually does

Of these four, ARC-1 is the only one that can read or write actual ABAP in actual SAP. Everything else is orchestration around it.

The Real Use Cases I Tested

I created a few small demo scenarios and tested them in Copilot Studio with ARC-1. The screenshots below are from those conversations.

Use Case 1: Bug Fix From A Jira Ticket

The first scenario is still a developer scenario, but it shows the complete loop very well. The Jira ticket KAN-2 only says that a customer with exactly EUR 1,000,000.00 revenue gets the wrong discount tier. Copilot reads the ticket, searches the SAP system, reads ZARC1_DEMO_DISCOUNT, compares the implementation with the header comment specification, and proposes the one character patch.

Look at KAN-2, propose a patch, but don't apply it yet.

The important part for me is the confirmation step. The agent does not immediately write to SAP. It first shows the root cause and the diff. Only after the follow-up prompt it updates and activates the report.

Open the formatted full answer

This captured run shows both steps: first the patch proposal, then the explicit follow-up to apply and activate it. In a safer setup, the first step alone can already be enough. The developer can copy the suggested diff, review it, test it manually, and keep ARC-1 read-only for that scenario.

Use Case 2: SharePoint Change Request To Impact Analysis

The second use case is more interesting for architects. A short SharePoint memo asks to widen ZARC1_DEMO_AMOUNT_DOM from CURR 13,2 to CURR 23,2. Copilot reads the memo and then uses ARC-1 to walk the dependency chain in SAP.

Read the change request in IT/Clean Core/ and tell me what would break.

The answer is not just “yes, change the domain”. It lists the dependency chain from domain to data element to table to report, then explains the risks: activation order, possible table lock, output length, and the hardcoded report layout.

Open the formatted full answer

This is where a solution architect or functional consultant benefits from SAP system context without needing an IDE. It turns a business change request into a better technical discussion.

Use Case 3: Build A CDS View From A SharePoint Specification

The third use case combines SharePoint, SAP documentation, and ARC-1. The input is a small SharePoint specification for a sales order KPI CDS view. Copilot reads the spec, uses mcp-sap-docs for SAP documentation and CDS conventions, reads the source table from SAP, and then creates and activates the views.

Build the CDS view from IT/Specifications/spec-orders-kpi.md.

What I liked in this example is that the agent had to adapt to the system. The first simple idea did not work because the system did not allow arithmetic expressions directly inside aggregate functions. The final result was a two-layer CDS design: a base view for line revenue and a KPI view for aggregation.

Open the formatted full answer

This is where Copilot Studio becomes more than a chatbot over documents: SharePoint for the requirement, mcp-sap-docs for the SAP pattern, and ARC-1 for the real table and activation.

Use Case 4: Code Quality Report

The fourth scenario is reporting only. The prompt asks Copilot to audit the $TMP ZARC1_DEMO_* ABAP programs and post a quality report. The captured answer shows the generated Markdown report, not the SharePoint write-back step.

Audit our $TMP ZARC1_DEMO_* ABAP programs and post a quality report.

Copilot searches the SAP system, reads the programs, runs both SAP ATC checks and abaplint, and produces a per-program report with the two findings axes scored against an overall Risk column. It also catches things pure linting would not flag on its own: SQL injection in the dump-trigger report, full-table scans in the invoice list, and table-buffer bypass on USR02. The same output could then be written to SharePoint, Word, or another document store depending on the connectors and permissions.

Open the formatted full answer

This is not mainly a coding example. It gives an architect, technical lead, or quality manager a faster first view: which programs are risky, which findings are only style, and which ones would block a promotion.

Use Case 5: Short Dump Diagnosis From A Jira Ticket

The fifth example starts from an intentionally weak Jira ticket. It only says that ZARC1_DEMO_DUMP_RPT short dumped overnight and that ST22 has the dump. This is close to how many real support tickets start.

Investigate KAN-3 and apply a defensive fix.

Copilot reads the Jira ticket, uses ARC-1 to read short dumps, identifies DBSQL_SQL_ERROR, reads the report, explains the root cause, and applies a defensive fix. In this demo it adds validation before a dynamic SELECT FROM (p_table).

Open the formatted full answer

In bug fixing, the analysis is often the biggest part. If the agent can collect the ticket, dump, source code, and related objects, then the developer starts much further ahead.

Use Case 6: Clean Core Readiness Check

The last scenario is about clean core readiness. The prompt is simple:

Is ZCL_ARC1_DEMO_CCORE clean-core ready?

Copilot reads the class through ARC-1 and finds direct selects on USR02 and BUT000. Then it uses two different context sources for the assessment. ARC-1’s API_STATE read capability asks the SAP system for release state and successor information. The SAP documentation source adds the official guidance around clean core, released APIs, ABAP Cloud readiness, and why direct table access to internal SAP tables is problematic. When SAP documentation returned no entry at all for USR02, the agent treated that as “strictly internal, find a released alternative” rather than “unknown, assume fine”, and inferred the right successor anyway. Based on that combined context, Copilot proposes released successor APIs like I_BUSINESSUSERBASIC and I_BUSINESSPARTNER.

Open the formatted full answer

ARC-1 provides the real custom code and the system-specific release state, while SAP documentation provides the official target direction. That makes the result useful for architecture and modernization planning, not only for a developer sitting in an IDE.

Why This Matters

The important change is not that Copilot Studio can call one more tool. The important change is that a centrally deployed ARC-1 endpoint can make SAP system context available in places where more project roles can use it.

Developers still need IDEs, and Copilot Studio does not replace ABAP development tools. But it can become a useful layer for analysis, specification, support, documentation, and architecture work, especially when it combines SAP system context, SAP documentation, SharePoint, Jira, and Microsoft 365 through governed tools and connectors. Without that central architecture, this would again become a local tool story. With BTP, it becomes an enterprise agent story.

Discuss this post

References & links

ARC-1 on SAP BTP: Secure ABAP Agentic Development Beyond the Laptop

Wed, 29 Apr 2026 09:00:00 +0200

Series note: This post is part of my AI ABAP development series, where I go from AI development in general, to ABAP-specific problems, and then to ARC-1.

In the previous post, I introduced ARC-1 as a secure ADT MCP gateway for ABAP systems. The main point was not only that ARC-1 can expose ABAP development functionality to AI clients. The main point was that this access needs a place in the architecture.

This post is about that place. If ARC-1 should not run uncontrolled on every developer laptop, then SAP BTP is the most natural enterprise option for me. Not because BTP makes the problem disappear, but because it already has the pieces you need for this kind of setup: XSUAA, destinations, Cloud Connector, role collections, audit logging, and the normal BTP operating model.

This is not a full setup guide. The exact commands are in the ARC-1 deployment docs, the BTP deployment guide, and the pages for XSUAA, destinations, and Principal Propagation. Here I want to explain the architecture options and what I would look at first.

Why BTP

The problem with agentic ABAP development is not only context. It is controlled context. The AI needs to read real SAP objects, but the company also needs to know who is authenticated, where credentials live, what the effective permission is, and who can later audit what happened.

That is where BTP helps. ARC-1 can run as one central Cloud Foundry application instead of many local MCP servers. The SAP connection can use BTP destinations. On-premise and private cloud systems can be reached through Cloud Connector. Users can authenticate through XSUAA. Role collections can decide who gets read, write, data preview, SQL, transport, git, or admin scopes. If the BTP Audit Log Service is bound, ARC-1 can write audit events into the platform instead of only to a local laptop.

For me this is the real difference. A local setup is good for testing and for special cases, but it is not the architecture I would want for a real ABAP team. A central BTP deployment gives you one managed MCP endpoint per SAP system, one place for policy, and no need to store SAP passwords in every developer client.

The Basic Shape

The architecture still has the same simple shape:

MCP client -> ARC-1 -> SAP system

But on BTP this becomes two authentication hops:

AI client
  -> XSUAA OAuth
  -> ARC-1 on SAP BTP Cloud Foundry
  -> Destination Service
  -> Connectivity Service
  -> Cloud Connector
  -> SAP ABAP system

The first hop is the MCP client talking to ARC-1. A client like Claude, Cursor, VS Code, GitHub Copilot for Eclipse, MCP Inspector, or Copilot Studio calls the ARC-1 /mcp endpoint and authenticates through XSUAA. The second hop is ARC-1 talking to SAP. For that hop, ARC-1 can use a BTP destination with a technical user, a BTP destination with Principal Propagation, or a BTP ABAP Environment service key.

For human developer usage, Principal Propagation is the most interesting option. ARC-1 receives the user token, passes it to the Destination Service, and BTP plus Cloud Connector can propagate the user identity to the backend. Then SAP sees the real user instead of one shared technical account. That is important for authorization and for audit.

ARC-1 uses a dual-destination pattern for this:

SAP_BTP_DESTINATION      = shared BasicAuth destination
SAP_BTP_PP_DESTINATION   = per-user PrincipalPropagation destination
SAP_PP_ENABLED           = true
SAP_XSUAA_AUTH           = true

The BasicAuth destination is used for startup work like feature probing and cache warmup, because there is no user JWT at startup. The PrincipalPropagation destination is used for authenticated per-user requests. In production I would also look at SAP_PP_STRICT=true, because then a Principal Propagation problem fails clearly instead of silently falling back to a shared user.

The Three Gates

The important part is that ARC-1 does not rely on one big switch. A request has to pass three gates:

The server ceiling: what this ARC-1 instance can ever do, configured with environment variables like SAP_ALLOW_WRITES, SAP_ALLOW_FREE_SQL, or SAP_ALLOWED_PACKAGES.
The user permission: what this user can do inside ARC-1, coming from XSUAA role collections, OIDC scopes, or API-key profiles.
The SAP authorization: what the SAP backend user can do, for example through S_DEVELOP, package authorizations, transport authorizations, or ABAP Cloud restrictions.

That means the effective permission is an AND model:

Effective permission = server ceiling AND user permission AND SAP authorization

This is why BTP role collections and ARC-1 safety flags are not the same thing. If the server has SAP_ALLOW_WRITES=false, a user with ARC-1 Developer still cannot write. If SAP_ALLOW_FREE_SQL=false, a user with SQL scope still cannot run freestyle SQL. And even if both ARC-1 layers allow the action, SAP can still reject it.

Deployment Options

The recommended option is the MTA deployment. ARC-1 includes an mta.yaml with the Cloud Foundry app and the required services: XSUAA, Destination Service, and Connectivity Service. This is the most reproducible setup because the application and service bindings are described together, similar to how SAP describes multitarget applications for Cloud Foundry.

The rough commands are:

npm run btp:build
npm run btp:deploy

or combined:

npm run btp:build-deploy

Docker on Cloud Foundry is the second option. That can make sense if a company wants to deploy a pinned image from GHCR or an internal registry. You still need the same BTP services, but you manage more yourself with manifest.yml, cf create-service, cf bind-service, and cf set-env.

A direct Node.js buildpack deployment is also possible, especially if you patch or customize the source and push it directly with cf push. For a stable team setup, I would start with MTA unless there is a concrete reason not to.

BTP ABAP Environment is a separate scenario. There is no Cloud Connector involved. ARC-1 can use a service key and OAuth flow to connect to the ABAP environment. In this case SAP_SYSTEM_TYPE=btp matters, because ARC-1 adapts tool definitions and avoids on-premise-only object types and assumptions.

Configuration That Matters

This is not the full reference, but these are the variables I would explain first:

SAP_TRANSPORT=http-streamable
SAP_XSUAA_AUTH=true

SAP_BTP_DESTINATION=SAP_ECC_DEV
SAP_BTP_PP_DESTINATION=SAP_ECC_DEV_PP
SAP_PP_ENABLED=true
SAP_PP_STRICT=true

SAP_ALLOW_WRITES=false
SAP_ALLOW_DATA_PREVIEW=false
SAP_ALLOW_FREE_SQL=false
SAP_ALLOW_TRANSPORT_WRITES=false
SAP_ALLOW_GIT_WRITES=false
SAP_ALLOWED_PACKAGES='$TMP'

The first group makes ARC-1 a remote MCP server with XSUAA authentication. The second group controls the BTP destination setup and Principal Propagation. The third group is the server ceiling, and I would keep it conservative by default.

For a development system, you may open selected writes:

cf set-env arc1-ecc-dev SAP_ALLOW_WRITES true
cf set-env arc1-ecc-dev SAP_ALLOW_TRANSPORT_WRITES true
cf set-env arc1-ecc-dev SAP_ALLOWED_PACKAGES 'Z*,$TMP'
cf restage arc1-ecc-dev

For production, I would usually keep ARC-1 read-only:

cf set-env arc1-ecc-prod SAP_ALLOW_WRITES false
cf set-env arc1-ecc-prod SAP_ALLOW_FREE_SQL false
cf set-env arc1-ecc-prod SAP_ALLOW_DATA_PREVIEW false
cf restage arc1-ecc-prod

The recommended architecture is like the one-instance-per-SAP-system model. A DEV system can allow selected writes, a PROD system can be read-only, and a BTP ABAP system can have its own endpoint and tool behavior. This keeps policies easier to understand than one large multi-backend gateway.

Roles And Technical Users

ARC-1 ships XSUAA scopes like read, write, data, sql, transports, git, and admin. These are grouped into role collections such as ARC-1 Viewer, ARC-1 Developer, ARC-1 Developer + Data, ARC-1 Developer + SQL, and ARC-1 Admin.

For human developer usage, I would prefer XSUAA plus Principal Propagation. Then ARC-1 knows the MCP user, and SAP can also see the real SAP user. That gives a much better audit story.

But not every use case needs Principal Propagation. For automation, scheduled checks, process agents, or a very controlled BTP Process Automation scenario, a technical user can be fine. The tradeoff just has to be clear: ARC-1 may know which token or client called it, but SAP will see the technical user. With Principal Propagation, SAP sees the real user.

Connecting Clients

Once ARC-1 runs centrally, client configuration should become small. Ideally the developer configures only the MCP server URL, not SAP credentials:

{
  "mcpServers": {
    "arc1-ecc-dev": {
      "url": "https://arc1-ecc-dev.cfapps.eu10.hana.ondemand.com/mcp"
    }
  }
}

Clients with remote MCP and OAuth discovery can follow the XSUAA flow. ARC-1 exposes OAuth metadata and proxies the flow to XSUAA, so this can work for Claude, Cursor, VS Code-style MCP clients, and MCP Inspector.

For Eclipse this becomes more concrete with GitHub Copilot for Eclipse. Eclipse ADT can stay the normal ABAP development environment, while Copilot can use MCP to call the same central ARC-1 endpoint. GitHub also added MCP OAuth support for Copilot in Eclipse, JetBrains, and Xcode, so this fits the BTP/XSUAA endpoint model much better than a local server on every laptop. ARC-1 still does not replace Eclipse. It gives the AI part a controlled SAP access path.

What I Would Verify First

Before I would enable any write access, I would verify the boring things:

curl https://arc1-ecc-dev.cfapps.eu10.hana.ondemand.com/health
curl https://arc1-ecc-dev.cfapps.eu10.hana.ondemand.com/.well-known/oauth-authorization-server

Then I would test a read-only MCP call and check the ARC-1 logs. The logs should show which authentication modes are active, for example XSUAA on the MCP side and Principal Propagation on the SAP side.

Only after that I would enable writes, and only in steps:

read-only -> writes to $TMP -> writes to selected packages -> transport writes

This is less exciting than a demo where the AI writes everything immediately, but it is much closer to how I think enterprise ABAP AI development should be introduced.

Where To Go Deeper

The architecture is the important part first, but the actual setup has many landscape-specific details.

For the concrete steps, I would start with the BTP Cloud Foundry deployment guide, then go through XSUAA setup, BTP destination setup, and Principal Propagation setup depending on the target landscape.

For me the main point stays the same: ARC-1 on BTP is not just a nicer place to host a Node.js app. It is where the MCP server can become part of an enterprise SAP development architecture, with central access, controlled permissions, and a real identity story.

Discuss this post

References & links

Introducing ARC-1: A Secure ADT MCP Server for Enterprise SAP Development

Mon, 27 Apr 2026 09:00:00 +0200

Series note: This post is part of my AI ABAP development series, where I go from AI development in general, to ABAP-specific problems, and then to ARC-1.

In the first post of this series, I wrote about context and how I use AI in development. In the previous post, I then moved that discussion into ABAP and ended more or less with one question: what would an ADT MCP setup need to look like if you take control, identity, and security seriously from the beginning?

This post is my current answer to that question. It is called ARC-1 (ABAP Relay Connector, pronounced arc one [ɑːrk wʌn]), and yes, it is another ADT MCP server. But the important difference is not that it can talk to ADT at all. Other projects already showed very well that this is possible and useful. The difference is the architecture and the focus, which is also why the ARC-1 documentation spends a lot of space on security, authentication, deployment, and operations, not only on the tool list.

Why ARC-1 had to exist

Luckily, the community already did a lot of the hard work before ARC-1. Marcello Urbani’s abap-adt-api gave many TypeScript projects the foundation to work with ADT APIs at all, which are still not really documented in a useful way. Projects like oisee/vibing-steampunk, fr0ster/mcp-abap-adt, and DassianInc/dassian-adt already proved that MCP and ABAP development can work in practice and can be very useful. And Wouter Lemaire’s btp-sap-odata-to-mcp-server was also important for me, because it already showed a BTP-deployed and centrally managed direction much earlier, and Wouter also helped me during the ARC-1 implementation.

So ARC-1 is not me claiming that nobody solved this before. For me it is more this: the others already proved the technical possibility, and ARC-1 is my attempt to close the enterprise gap. That gap is the same one I described in the last post. In ABAP, the hard part is not only getting context into the model. It is that context access, write access, and control are tied very closely together in a real SAP landscape.

That is why I did not want to build just another local developer tool that happens to speak MCP. I wanted to build a secure ADT MCP server with a clearer security concept, more central control, and an architecture that fits better into enterprise SAP environments.

Central instead of local

For me this is probably the biggest architectural difference. Most current MCP ADT setups are still mainly local. The server runs on the developer laptop, gets configured there, stores credentials there, and then talks directly to the SAP system from there.

That is fine for trying things out. It is also fine for fast experimentation. And to be clear, ARC-1 can also run locally. That is useful for tests, local development, and simply trying the server out. But local developer setup is not the main story I care about here. The main story is central deployment.

That means one managed ARC-1 instance per SAP system, with central configuration, central security settings, central logging, and a clear operational owner. That can run on a company server, in Docker, or ideally on SAP BTP Cloud Foundry. The architecture documentation goes into the technical flow in more detail, but I will go much deeper into the BTP side in the next post, because that deserves its own post.

For me BTP is especially interesting here because it lets you reuse things that already exist in many companies anyway: XSUAA, destinations, Cloud Connector, audit services, role assignment, and the usual BTP login flow. Then the developer mostly just needs the MCP URL and the standard login, while admins and authorization teams keep control in the place where they already work.

I also do not think this is only an SAP-specific thought. Salesforce is already moving in a similar direction with hosted MCP servers and Headless 360, where more of the platform is exposed as APIs, MCP tools, or CLI commands. To me that confirms that enterprise MCP is a platform and governance topic, not only a developer convenience topic.

The reason this matters is simple. If the MCP server sits only on the laptop of an individual developer, then the architecture is also controlled there. That is exactly the part I do not find convincing for enterprise usage.

Two auth hops matter

One thing that became very clear while building ARC-1 is that there are really two completely different authentication questions. The first one is who is allowed to talk to the MCP server at all. The second one is as which user the MCP server talks to the SAP system.

That sounds obvious, but many discussions around MCP servers blur those two things together. In ARC-1, these are treated as two separate hops: MCP client -> ARC-1 and ARC-1 -> SAP. This matters because the architecture becomes much clearer after that.

For the first hop, ARC-1 can use things like API keys, OIDC/JWT, or XSUAA OAuth, depending on how and where it is deployed. For the second hop, ARC-1 can talk to SAP with Basic Auth, BTP service keys, or with Principal Propagation, depending on the target landscape.

That split is very important for enterprise usage, because it lets you separate client access control from SAP identity handling instead of hiding both behind one local config file. It also makes it easier to support different use cases. If ARC-1 is used more like a backend connector for an automation, an API key may be totally fine. If real per-user identity matters, then OAuth or XSUAA plus Principal Propagation is the much more interesting setup.

Safe by default, not allow all by default

The next big difference is that ARC-1 starts from the assumption that the default should be restrictive. Out of the box ARC-1 is read-only. It blocks free SQL. It blocks named table preview. Transport reads such as list, get, check, and history remain available, but transport mutations require both writes and transport writes to be explicitly enabled. And even if writing is enabled, writes are still restricted to $TMP unless packages are explicitly allowed.

That last point is important to me. Yes, it makes the first setup a bit less magical. Sometimes you need to configure one more thing. But I prefer that over accidentally giving an AI assistant full write access to transportable packages because one flag was too broad.

ARC-1 also has an action deny list, package restrictions, and safety profiles including viewer, viewer-data, viewer-sql, developer, developer-data, developer-sql, and admin. So there is not only one on or off switch. For SAP development that feels much more realistic to me than a server that starts by allowing everything and then hopes people will restrict it later.

Layered security, not just one switch

This also leads to the next point. For me, security here is not one boolean setting. It is several layers on top of each other.

At the ARC-1 level there is the server safety configuration itself: read-only mode, blocked SQL, package restrictions, the action deny list, and transport gates. Then there is the identity and role layer on top, for example via OIDC or XSUAA scopes and roles. And then there is still the SAP system itself with its own authorization objects and checks.

That means all of these layers have to allow something before it actually happens. If ARC-1 is configured read-only, then even a user with a more powerful role still cannot write. If a user has write scope in ARC-1, but the SAP backend authorization is missing, the write still fails.

That is exactly how I want it. ARC-1 should not replace SAP authorization. It should add another control layer in front of it.

Per-user identity matters

This becomes even more interesting once you look at per-user identity. One of the things I wanted very early is that ARC-1 should not force everything through one shared technical SAP user if that can be avoided.

That is why Principal Propagation is such an important part of the architecture for me. If Principal Propagation is active, the MCP user identity can flow through ARC-1 and into SAP, so that the action runs with the real SAP user and the real SAP authorization of that person. I already tested this and it works.

That is important not only because it is cleaner technically. It is important because it fits much better into audit, compliance, and real enterprise authorization models. I do not want the whole architecture to end in “trust this one service account and hope nobody asks too many questions later”. I want the system to be able to say who actually did what.

Audit logging is part of the feature, not an afterthought

The same applies to audit logging. If AI is allowed to read from or write to a real SAP system, then logging is not some optional extra feature. It is part of the basic architecture.

ARC-1 emits structured audit events and can integrate with the BTP Audit Log Service. That means you can log who called which tool, what happened, and in which request context it happened. Especially on BTP, that gives you a much better compliance story than a local MCP server that mostly lives on one laptop.

For normal hobby tooling this might feel like overkill. For SAP it does not. Especially if the recommended target architecture is BTP, it makes sense to also use the established platform services for logging and identity instead of building a parallel side world around them.

Not locked into one client

This point is also important to me personally. There are already many useful prompt files, local plugins, slash commands, and client-specific workflows around SAP and ABAP. I do not think that is wrong. A lot of that work is useful and practical.

But that is still a different architecture. Very often the logic, the access, and the credentials live mainly on one laptop and inside one AI client. For enterprise usage I want the opposite.

I want one secure ADT MCP server that can be used from many clients. That can be Claude, GitHub Copilot, Copilot Studio, IDEs, or later other MCP clients that also support OAuth. In the best case, that can then be combined with Principal Propagation instead of local SAP credentials.

That flexibility matters, because in many companies the default AI developer tooling will not be Claude Code. It will more likely be GitHub Copilot or other centrally managed tools. And I do not want the SAP side of the architecture to depend on one specific AI client. MCP is useful exactly because it decouples those things.

Testing matters more here than for normal dev tooling

I also want to stress the testing part, because for a project like this it matters a lot.

If an MCP server only works in one perfect demo system, then that is not enough. SAP systems are messy. Different releases behave differently. Different endpoints exist or do not exist. BTP ABAP is different again. And error handling around ADT is not always beautiful.

That is why ARC-1 puts a lot of effort into testing. Right now the project has 3,474 unit tests, a 262-test default integration profile, and a 141-test default E2E profile. The integration and E2E profiles test against live SAP systems, and the E2E tests execute real MCP tool calls against a running ARC-1 server. As a freelancer I obviously do not have access to every possible enterprise landscape, but I do test against real systems. I test against BTP ABAP, the ABAP trial system in Docker, and the older 7.50 trial system.

I also do not test only with one ideal model and one toy example. I try it myself with stronger and weaker models and with workflows that are much closer to reality. That includes things like clean core analysis or creating a full RAP project from nothing, not even a table, up to an activated RAP project you can actually use. A lot of the workflows and feature ideas behind that are also visible in the ARC-1 skills catalog, because those are more or less the kinds of use cases I want to make work reliably.

For me that is also one of the big lessons from working with SAP tooling in general: if you do not test against real systems, you often only test your assumptions.

So yes, this is another ADT MCP server

And that is fine. I do not think ARC-1 needs to exist because every other project is wrong. Quite the opposite. The other projects created the category, pushed the ecosystem forward, and showed there is real interest.

At the same time I think ARC-1 is different enough in architecture and focus that it makes sense right now. It is especially different from the angle of secure defaults, central deployment, layered security, per-user identity, and auditability.

And yes, it now also differentiates itself from SAP’s official approach. SAP first announced the server in its November 4, 2025 post about the next era of ABAP development. Since then, SAP has made the official ABAP MCP server available in both Eclipse and VS Code. I think that is good news.

The current difference is architectural. SAP’s configuration guide describes the ADT MCP server as a local HTTP server hosted by the IDE and protected with a generated bearer token. ARC-1 can also run locally, but the main direction described in this post remains central deployment, BTP integration, enterprise authentication, per-user backend identity, roles, and audit logging.

SAP also says that a possible standalone shipment of the ABAP Language Server and MCP Server is still under discussion. If reusable standalone components become available, ARC-1 should evaluate using that foundation instead of reimplementing more and more HTTP details on the community side. For now, the official local server and a centrally deployed ARC-1 instance are two existing approaches with different deployment and governance models.

The point is not that my server must win. The point is that different architectures serve different needs, and competition is usually good. It helps people choose, it helps ideas spread, and it gives both SAP and community projects feedback from real use. People can decide whether the official local ADT MCP server, a centrally deployed ARC-1 setup, or both fit their landscape.

A note on ADT APIs and SAP’s new API policy

There is one more point worth separating from the architecture discussion. SAP published a new API policy in April 2026. The current SAP API Policy is version 4.2026a. It permits published APIs for their documented use, but says non-published APIs must not be used unless documentation or SAP authorization permits it. It also explicitly restricts API use with generative AI systems that plan, select, or execute sequences of calls outside SAP-endorsed architectures and documented limits. That makes this more than a theoretical support question for SAP customers, partners, and community tools that build on top of SAP development APIs.

For ADT, the publicly available material points to a more nuanced situation. SAP provides an official ADT SDK with JavaDoc, and the ADT download page describes it as a public API to implement or integrate your own tools with SAP’s ABAP IDE. There is also an SAP document about creating and consuming RESTful APIs in ADT. This does not imply that every internal /sap/bc/adt endpoint is covered by the same support boundary, but it does show that parts of the ADT tooling and communication model are documented and intended for integration scenarios.

Since then, SAP has shipped the ABAP Language Server and MCP Server as parts of Eclipse and VS Code, while a standalone shipment remains under discussion. That does not by itself define the support boundary for every endpoint used by third-party tools. ARC-1’s position is therefore deliberately cautious: stay close to documented and discoverable ADT behavior, keep data preview and free SQL off by default, review the SAP policy and the customer’s SAP agreement, and ask SAP before production use. The ARC-1 API Policy and Architecture Alignment page covers that position in more detail.

Why this matters for the next post

In this post I mainly wanted to explain why ARC-1 exists at all and why it looks the way it does.

The next post is where I want to go deeper into the BTP side, because that is where the architecture becomes much more interesting in practice: XSUAA, Destination Service, Cloud Connector, Principal Propagation, and how this can fit into a real enterprise setup instead of just a developer laptop.

Discuss this post

References & links

ABAP and Agentic AI: The Hidden Problem in Real Projects

Wed, 22 Apr 2026 09:00:00 +0200

Series note: This post is part of my AI ABAP development series, where I go from AI development in general, to ABAP-specific problems, and then to ARC-1.

In the first post of this series, I wrote more generally about how I use AI today, why context matters so much, and why I am still not fully convinced by the more maximalist agentic hype.

Here I want to get more concrete. Because SAP development is not one thing, and that matters a lot for AI.

There is a big difference between UI5 or CAP development with AI and ABAP development with AI. If I mix those together, then the whole discussion becomes too vague very quickly.

For me this comes down to three questions:

How does the model get the needed context?
Where does the writing happen?
Who is actually in control of that setup?

I want to answer those questions in this post.

SAP development is not one thing

When people talk about “AI in SAP development”, a lot of very different things get mixed together.

UI5, Fiori, CAP, BTP extensions, ABAP Cloud, ABAP on a shared dev system, Joule in Eclipse, MCP servers, local git workflows, sandbox systems, custom code migration. All of that gets thrown into one big AI bucket.

But these are not the same problem. The reason I want to split this early is simple: some SAP development areas already fit quite naturally into AI assisted workflows, and some really do not.

If I do not separate that clearly, then the discussion becomes too vague very quickly.

Why UI5 and CAP already feel much more natural

For frontend work like UI5, Fiori, CAP, or generally JS and TS based development, AI usage already feels much more normal. The development is usually off stack. You work in local files, use git, open pull requests, run CI/CD pipelines, let tests run, get peer review, and only then move the change further. If AI does something weird, it is annoying, but usually not catastrophic, because there are already good gates in this ideal process.

That is also why GitHub Copilot in VS Code became pretty normal in a lot of companies. If you combine that with good context, for example docs from SAP Help or SAP Docs through MCP, then you can already move quite fast today. I use my own sap-mcp-docs server a lot for exactly that. SAP also moved in that direction with MCP servers for UI5, CAP, and Fiori.

In that environment the three questions above are much easier to answer:

Context comes from local files, documentation, and existing dev tooling.
Writing happens locally, not directly in a shared SAP system.
Control already exists through git, reviews, tests, and pipelines.

So the main question there is often more about workflow quality than about technical possibility.

Why ABAP is structurally harder

In the ABAP world things look different. The two main problems are the architecture and the tooling.

ABAP development is usually on stack. That means if you develop on the dev system, every change is directly applied to that shared system and can affect other developers as well. Even without AI that is already something you have to be careful with. With AI it becomes more sensitive, because a wrong write action is not just a wrong local file edit.

The second problem is tooling. A lot of ABAP developers still use SE80. Eclipse has been there for a long time, but if you were never forced into newer development models like RAP, a lot of people just stayed where they were. And if your main world is still SE80, then there is not really much serious AI support there.

So if I compare UI5 and ABAP, the problem is not only “does the model know ABAP”. The bigger question is in which environment this happens at all, and what happens if the model is wrong.

That is also why I think the SAP Community post The agentic revolution is here, and your ABAP code is the foundation fits quite well here.

The point there is not really that agents replace ABAP. It is more that if agents are going to call into SAP systems, then your ABAP foundation matters even more. Interfaces, CDS views, checks, naming, error handling, package structure, all of that becomes important.

The better and clearer your ABAP foundation is, the more useful and safer the agent layer on top can become, because they use your ABAP code as the foundation for their work.

Model choice still matters, of course. I already wrote two separate posts around ABAP code generation and ABAP understanding, and my practical takeaway is still that strong general models together with better tooling and grounding are currently the better path than hoping one SAP specific model alone solves the problem. But even with a better model, the structural ABAP problem stays the same: on stack writes, shared systems, and weak control do not disappear. Frontier models are just better to handle more complex problems as with complexity comes usually a larger context to handle, and frontier models are usually better at that.

The three questions matter more than the hype

I think this is also why Agentic Engineering Patterns from Simon Willison fits so well here.

What I like there is that “agentic” is not treated like some magical category. It is more a set of working patterns: tools in a loop, tests, boundaries, anti-patterns, habits, and when not to let the loop run too far. For ABAP this matters even more, because the question is not only if an agent can do something, but what kind of loop you actually allow it to run against a real SAP system.

So for every pattern below I want to keep asking the same three questions:

How does the model get context?
Where does writing happen?
Who controls that setup?

Current patterns for AI assisted ABAP development

Lars Hvam wrote a very useful paper on the patterns for using LLMs in ABAP development. You can read more details and see diagrams there.

I like that framing because it avoids the fake discussion of “one right way”. There is not one right way. There are different patterns with different tradeoffs depending on your landsacpe, knowledge, and setup.

1. IDE integrated AI in Eclipse

This is the most obvious option. You stay where you already work and let the built in AI features help with explanations, code suggestions, tests, and smaller implementation tasks. Depending on landscape and setup, that could mean Joule for Developers, GitHub Copilot in Eclipse, or Amazon Q Developer for Eclipse.

Context: Mostly the currently selected SAP object plus what the IDE integration can access or what you add manually.
Writing: Directly to the SAP system.
Control: Mostly on the developer side, not much central boundary around the agent loop itself.

This is easy to adopt as “quick win”, but it does not solve the core architecture problem.

2. VS Code, today mostly with ABAP Remote FS and soon also with SAP’s own extension

This gives a much better AI developer experience because VS Code is simply ahead in that area compared to Eclipse. Today that usually means community tooling like ABAP Remote FS. But SAP’s own ABAP Cloud Extension for VS Code is planned for Q2 2026, so likely around May if that timeline holds. That means ABAP Remote FS is probably more of a bridge than the long term answer, at least for the scenarios SAP will cover first.

The problem stays similar though. If the setup writes back directly through ADT APIs, then the nicer editor experience still does not remove the main risk.

Context: Better local editor experience, but still tied to what the tool can read from the system.
Writing: Still directly to the SAP system.
Control: Still relatively weak if the whole setup sits with the individual developer.

So the nicer developer experience does not remove the main risk.

3. ADT MCP Server

This is where things get really interesting.

With an ADT MCP server the AI does not just see files. It gets structured tools. It can read objects, search code, inspect context, run checks, navigate references, write changes, etc., depending on what the server allows.

This is also currently one of the best ways to solve the context problem.

I already wrote earlier about this direction in Finally: An MCP Server for ABAP, and since then the space has grown a lot. That is also why I keep SAP MCP Servers: The Missing Overview around, because the number of SAP MCP servers and adjacent tools is growing quickly enough that it is easy to lose track.

The AI can say: I have a problem in this class, now get me the class, then maybe read the related table, check another class, search similar code, maybe combine that with SAP documentation from another MCP server like sap-mcp-docs, and build up the context automatically. That is really useful.

Context: Very strong, because tools can gather much richer SAP context such as objects, data, and logs.
Writing: Potentially directly to the SAP system.
Control: Depends entirely on how the MCP server is designed, configured, and deployed.

This is exactly why the MCP path is so interesting and so dangerous at the same time.

It solves a real problem, but it also raises the control question much more sharply. It is also why SAP’s post on Standardizing AI Tool Integration with MCP matters. MCP in SAP is not just some hobby side path anymore. It is becoming part of the real architectural conversation.

4. Sandbox systems

In my opinion this is one of the safest options.

Give the AI a sandbox system that can be isolated, reset, or recreated, and suddenly much more becomes possible without damaging the shared dev system.

Context: Very strong, because the AI can still inspect and work against a real SAP system.
Writing: Direct, but only into an isolated system.
Control: Much better than shared-system direct access, but with infrastructure cost and operational overhead.

This is a very good pattern if you can afford it. The problem is that most teams do not have this luxury.

5. Git or off stack development with abapGit and CI/CD

In many ways this is the cleanest approach.

The AI never writes to the SAP system directly. It writes local files, then git, review, checks, and pipeline steps become the gate.

Context: Depends on what additional read access you give the AI.
Writing: Local first, not directly on the SAP system.
Control: Much stronger, because review and automation become the boundary.

This is how a lot of frontend development already works, and it is much easier to trust.

The problem is that many ABAP teams are simply not there yet. If there is no clear package separation, no git workflow, and no pipeline culture, then introducing this only for AI becomes a bigger transformation project.

6. Hybrid approach

This is the pattern I find currently the most practical long term.

The AI works locally or off stack, but still gets read access to the SAP system through ADT or MCP for context.

That means it can understand the actual system better, but the writing still happens in a gated git flow.

Context: Strong.
Writing: Gated.
Control: Much better than direct write access, while still preserving real system context.

For me this is one of the most promising directions.

Read access already gives a lot of value

One thing I find important here is that AI does not need direct write access to be useful. For many real problems, reading and analysis can already take away maybe 80 percent of the work. If an issue comes in, the first question is usually not “who writes the line of code”, but “where is the actual problem”. If the AI can analyse the system, narrow it down, read code, data and logs, suggest where the bug is, and maybe propose the one line change, then the developer can still do that actual line manually. Or the AI writes the proposed fix and the developer still copy pastes it, reviews it properly, and tests it. That alone is already a lot of support.

And this read access is not only useful for developers who want to code faster. It can also help people working more on architecture, specifications, analysis, testing, and migration. If they can read how the system works, where logic is implemented, how much something is used, or what the dependencies are, then that already helps a lot, for changes, fixes and the transformation from ECC to S/4HANA.

That is also why I do not really buy the simple management idea that you just give everyone Copilot or an Agentic AI coding tool and suddenly everyone codes much faster. That is not the real point.

The bigger question for me is how to help ABAP developers and SAP teams in their daily work with things like:

faster problem analysis
less wasted time searching for the right place
easier access to relevant documentation, logs, and data
faster understanding of old logic
better support while writing specs and tests

An MCP server for documentation, an MCP server for SAP access, and access to more internal documentation can already help a lot here without giving full write access to everything.

What current setups still do not solve

So where is the actual gap today?

For me it is not that AI cannot write ABAP. It can. It is also not that AI has no SAP context at all anymore. That situation is improving a lot through ADT tooling, MCP servers, documentation access, and better models.

The real gap is that context access, write access, and control are tied much more closely together in ABAP than in off stack development, and that becomes an enterprise problem very quickly.

What is often still missing is some combination of proper read-only defaults, operation boundaries, package restrictions, blocking dangerous features like free SQL, per-user identity instead of shared technical access, auditing, and a setup that security, basis, and development can all still trust.

That is also why I am skeptical of setups where powerful ADT MCP servers simply run locally on the laptop of an individual user. If someone can set it up, and usually that is not even that hard, then suddenly you have a very powerful bridge from the model into the SAP system, but without much admin oversight around it. In an enterprise landscape that is not ideal at all.

What an ideal setup would look like

So for me the question is not if agentic ABAP development is possible. It already is.

The more important question is what a setup would need to look like if it should actually work in enterprise reality.

For me that ideal direction is something like this: strong read access to real SAP context, useful structured tools instead of blind file edits, write access that is either gated or at least strongly restricted, central deployment instead of every user doing their own thing locally, clear identity handling, auditability, and enough safety boundaries that basis, security, and development can all live with it.

That does not mean every team needs the exact same architecture. But it does mean the next step cannot just be “give the model more power and hope for the best”.

Why this matters for the next post

The next post is where I want to look at what a more enterprise-ready ADT MCP setup should actually provide if you take those problems seriously from the beginning.

Discuss this post

How I Use AI for Development and Why Context Matters

Mon, 20 Apr 2026 20:00:00 +0200

Series note: This post is part of my AI ABAP development series, where I go from AI development in general, to ABAP-specific problems, and then to ARC-1.

When it comes to AI, I do not really think about magic.

I think more about another colleague helping me out.

Sometimes that means architecture. Sometimes implementation. Sometimes testing, review, CI/CD, or deployment.

But this only works with trust, and trust needs communication.

If I do not know something, I ask. If code looks strange, I ask. If tests fail, I ask.

The less I need to ask, the more likely it is because I already gave enough context up front: architecture, documentation, constraints, examples, and what I actually want. Even then I still review the result.

That is why using AI well is a skill you build over time.

My first larger projects with AI were much less smooth than newer ones. Over time I learned that better context, better tooling, and better guardrails lead to much better results. AI can speed things up a lot, but it does not remove engineering judgement.

My workflow changed over the last year

Last year I was mostly just using ChatGPT directly, before tools like Claude Code became more normal. I asked something, copied the generated code into my project, checked if it runs, copied the error back if it failed, and repeated that loop.

The error message was context. The result of trying it out was context. That manual loop slowly improved the output.

What changed over time was not only the model. More and more the AI can get context itself.

Before I had to spoon feed much more manually. Now tools can search, read docs, inspect files, and in some cases get the needed context on their own. For me that is one of the biggest improvements, because the AI does not only answer, it can first understand more.

That is also why I liked How I write software with LLMs by Stavros. Not because I use exactly the same workflow, but because it shows quite well that this is not only about the model. The workflow around the model matters a lot as well.

Context matters more than people first think

A lot of the time the biggest value is not even that the model writes code for me.

Very often it helps with understanding. It can explain a codebase, compare options, write down a plan, summarize documentation, help with tests and refactoring, or point me to the next thing I should check. For a lot of developers that alone is already useful, without going fully agentic.

In many projects the important information is not only in the source code. It is in documentation, issues, diagrams, product docs, logs, dumps, table data, screenshots, pipeline output, and things people in the team just know. If the model only sees one file, it often gives you an answer that sounds nice but misses the actual problem.

That is why I really liked the post Context is the Difference Between Slop and Shipping. I think the core point is right.

If you do not understand the system first, or if the model does not get the right grounding, then you just get plausible looking nonsense faster. It looks like momentum, but often it is just wrong output with confidence.

One of the first places where I really noticed this was UI5, especially with controls like the UI5 Wizard. I had to explain the API again and again, and without that extra context the output was often just wrong. That was one of the first moments where I noticed more clearly that in SAP development good context is not optional.

Especially in SAP I noticed pretty quickly that you need some kind of grounding. You want to be able to say: use this documentation, use this guideline, use this code reference, trust this as the source of truth and do not just invent something.

It still hallucinates sometimes, that does not fully go away, but it becomes less. Especially weaker models benefit a lot from having the right information at the right time.

Why I care so much about tooling around the model

That is also one reason why last year I started building my own MCP server for context. It can search GitHub repositories, SAP Help, and related sources, so I can bring better grounding into the workflow.

For SAP development especially this helped, because so much is not directly visible in one code file. If the model can pull in SAP documentation, guidelines, and related references, it gets pushed much more into the right direction.

I now almost always have that SAP docs setup with me. At the beginning it felt even more important, because the models were weaker and hallucinations were stronger. Today it is a bit better with the stronger frontier models.

I also noticed this with BTP and Cloud Foundry work. There the models can often already use the CLI and public documentation quite well. So the models are improving.

But the more special something gets, the more hidden it is, or the more SAP specific it is, the more important that extra context becomes again.

That is also why I do not find the current AI discussion fully convincing sometimes. People talk a lot about models, but much less about the system around the model. To me, context and tooling matter more in real projects than benchmark discussions alone.

Model quality still matters, but it is not the whole story

I already wrote two separate blog posts about ABAP LLM benchmark results, one more around code generation and one around understanding.

My takeaway there was that strong general models are currently still the more practical choice for me, and that tooling and grounding are often the bigger lever than hoping for one SAP specific model to solve everything by itself.

What also helps a lot is that my MCP SAP docs setup is not only pure API documentation. There are also style guides, DSAG guidelines, and other recommendations in there. These are often not hard rules, but they still push you in a certain direction. So even if I do not know the exact recommendation by heart, I can ask the model to look for guidelines and it gets nudged more automatically towards a better direction.

And context is not only documentation. If I say change this class, then the context is not just that class. It is also the tables that are used, the other classes that are called, similar implementations, internal guidelines, what this system can even do, and what is already there in working code. That broader context improves quality a lot more than just throwing one file at the model.

I am still skeptical of full agentic hype

There is also a very practical spectrum in how much AI help you even want. You can just ask questions about context. You can ask it to find docs and let you read them. You can use it for analysis and planning. Or you can let it implement things more autonomously. That is not one binary choice. It is more a slider, and depending on the project, the team, and the risk, you move that slider differently.

At the same time I am still not sure that going more agentic automatically makes you faster. Pure AI assistance already helps me a lot. But once it becomes more agentic, other things get harder again. The coding itself is very fast, but then you spend more time on plans, instructions, guardrails, review, and correction.

This also matches quite well with the METR study on experienced open-source developers. What I found interesting there is not some simple “AI bad” takeaway, but more the gap between feeling faster and actually being faster.

If less time goes into typing code, but more time goes into prompting, reviewing, waiting, and correcting, then it can still feel fast while the total time says something else. That matches quite well with what I notice myself.

At the same time I also do not want to overcorrect too much into pure skepticism. The post Eight years of wanting, three months of building with AI is a good counterexample. AI helped a lot there, but the first more maximalist agentic approach also created a messy codebase, and things only got better again with tighter ownership and stronger review. That feels much closer to reality than either extreme.

For me there is still a big difference between strong AI assistance and just letting the agent fully take over. Writing the code is now often the easiest part. I spend more time before coding on research, testing, planning, and architecture. And I spend more time after coding on review, rework, manual testing, and documentation.

It is still faster in my opinion, but the time moved.

Process helps, but process is also overhead

This also fits well to How I teach Claude Code to work my way. What I like there is that the focus is not on one magical prompt, but on process. Explore first, think first, plan first, then execute.

I do not use exactly the same process everywhere, but the general idea fits very well to what I learned myself. If you give the AI a process, it usually follows one. If you do not, it drifts more easily. At the same time, process also creates overhead, so it is only worth it when the task is big enough.

That is also why I often want the model to first find a reference before it gives me a strong answer. Search for the SAP documentation. Find the guideline. Show me a similar implementation. Do not just make something up because it sounds right.

Why this gets harder in SAP

Security is also part of that trust question. How much trust do you put in the llm itself, how much in the model provider, and how much in the tools around it? How much security are you willing to give up to move faster? For toy projects people often accept a lot of risk. In enterprise development that looks very different.

In SAP this matters even more, because so much important context is outside the code itself. The actual code change can be very small, but understanding why you need that change can require docs, config, logs, dumps, table entries, business process context, authorizations, and knowledge about how the landscape is set up.

At the same time SAP is also moving. I was pleasantly surprised when SAP released MCP servers for UI5, CAP, and Fiori.

In that world it already feels much more natural, because a lot of that development is off stack anyway. You work locally, use git, run pipelines, get peer review, and if something goes wrong you can usually revert it. That is much easier territory for AI assisted development.

So the interesting question for me is not if AI can help in SAP development. It already can. The more interesting question is where it helps today, where it becomes risky, and why especially ABAP development is still much harder than frontend or CAP development.

In frontend and CAP development, AI can already fit quite naturally into workflows many teams already have. In ABAP, things look very different.

The next post is where I want to look more concrete at that gap: what is already possible today, which patterns exist, and why enterprise guardrails matter much more there.