Projects on Marian Zeis Blog

Testing Joule Work Desktop with Microsoft 365, Local Files, and SAP

Wed, 12 Aug 2026 03:00:00 +0200

You have probably seen Joule Work Desktop on LinkedIn by now. Sebastian Steinhaeuser showed how it prepares him for a customer meeting. Philipp Herzig called it the new SAP GUI, with a smile, and demonstrated a workflow across email, a spreadsheet, a Space, and PowerPoint.

Joule Work Desktop is now available to SAP employees after a test with more than 6,000 colleagues. Selected customers can also use it through the Early Adopter Care program on macOS and Windows.

The idea is simple: one desktop application that can combine local files, Microsoft 365, SAP knowledge, business systems, MCP connectors, and skills. That is much more interesting than another small Joule chat window inside one SAP application.

I already built similar setups with LibreChat and Microsoft Copilot Studio. A native application adds direct access to the files and applications people use every day.

Luckily, I was one of the few people who got access to the application and could test the currently available features. So here is my first hands-on experience with what I am allowed to show.

If you prefer to see the complete flow first, here is the 58-second demo video.

The application starts with Conversations. I can add files and select work sources or an external connector from the composer. Tool calls remain visible, and generated files open in their normal desktop application.

Email and calendar integration

I asked the application to prepare me for a meeting. It found the calendar entry, read related email messages, and created a brief with logistics, open points, risks, and questions. The calendar and email steps remained visible, and the answer included source references. For me, this is more useful than a general inbox summary because the message becomes the start of a task.

Local files, OneDrive, and real documents

I can attach Office documents, structured data, text, and images. Files synchronized through OneDrive are also available, so they can be combined with email, calendar, web research, or an external connector.

For the meeting-preparation example, I attached an existing Word template. The application filled the relevant sections and created a new document instead of giving me text to copy manually.

The files still need review, but reviewing a prepared document is often faster than starting with an empty one.

Spaces are more useful than I expected

SAP calls the generated work areas Spaces. They are persistent views that can be reopened without finding the original conversation. The most useful one in my test was a transport backlog based on data from my SAP system. It shows open and empty transports, their owners, and the biggest requests by object count.

This does not replace a proper application or reporting solution. But not every temporary question needs a new Fiori application, and a Space is more useful than a long chat answer.

Connecting the SAP system

The SAP system integration is what can make Joule Work Desktop more than a general desktop agent.

At the moment, the direct SAP business system integration available to me is for SAP S/4HANA Cloud Public Edition. I do not have such a system. My test system is SAP S/4HANA 2023 on-premise.

I therefore added ARC-1, my open-source ADT MCP server. ARC-1 can run locally or as a remote MCP server with OAuth, for example on SAP BTP Cloud Foundry.

I could then read transports, inspect ABAP objects, analyze custom code, check ATC findings, or compare a specification with what actually exists in the system.

The connector still needs valid authentication, and SAP user authorizations still apply. I would start with a development system and read-only access.

Connectors and one-click skills

Joule Work Desktop supports MCP connectors and skills, so SAP does not have to build every integration and workflow itself. The SAP AI Skills Library contains reusable skills that can be imported into Joule Work Desktop with one click.

The skill page shows the repository, license, trust level, and checks before installation. The SAP Fiori Guidelines skill, for example, can be added through the Add to Joule Work Desktop button.

MCP servers provide tools, while skills describe how the agent should use them and what it should verify. This keeps the application extendable without adding every possible SAP feature to the desktop client.

The open questions are broader SAP system support, connector governance, and pricing. Anything about future announcements or TechEd is still only speculation.

Something is strange

Anyone who already works with Joule Work Desktop may have noticed something by now.

Some details in my video and screenshots do not look exactly like the application SAP installed. The interface is very close, the workflows work, and the features are there, but a few things are just slightly different.

There is a simple reason for that.

I do not have access to Joule Work Desktop.

The screenshots and video in this post do not show an SAP application. They show an application I built myself.

After watching the public demos, I wanted to see how difficult it would be to rebuild the same core idea with open-source components. I spent roughly a day or two vibe coding it with Codex. The result is called Werkbank.

Werkbank is the German word for workbench, a place where different tools come together to get work done.

The current interface follows the public Joule Work Desktop videos closely because I wanted to reproduce the workflows shown there. But there is no internal SAP code behind it, I had no access to a Joule Work Desktop build, and I have no additional product information beyond public posts and videos.

What is actually inside Werkbank

Werkbank is a working MVP, not a static mock or a prerecorded animation. It can hold real streaming conversations, call tools, ask for permissions, and stop a running task. The agent behind it is goose, an open-source AI agent hosted by the Agentic AI Foundation. Werkbank communicates with Goose through the Agent Client Protocol.

The implemented features currently include:

Local active and archived conversations.
Word, PowerPoint, text, CSV, JSON, and image attachments, including files synchronized through OneDrive.
Generated Word and PowerPoint files that can be opened in the normal desktop application.
Persistent Spaces stored as sandboxed HTML views.
Live read-only Microsoft 365 email and calendar access.
Session-scoped MCP connectors, remote MCP OAuth through Goose, and reusable skills selected with /.

The demo uses these features rather than special video fixtures. The meeting brief comes from live calendar and email calls, the Word output is a real file, ARC-1 reads my SAP system, and the transport Space is generated from those results. The shipment-defect workflow uses an attached synthetic CSV file and creates a real Space and PowerPoint presentation.

For SAP, Werkbank uses the same MCP servers I can use from Claude Desktop, Codex, VS Code, LibreChat, or Copilot Studio. ARC-1 connects to the ABAP system. Connector secrets are stored through the operating system’s secure storage instead of being written into the normal configuration.

The project website is getwerkbank.com, and the source is in the public Werkbank repository. Development currently targets macOS, and there is no signed installer yet.

The Werkbank App Store

getwerkbank.com is not only a landing page. Its App Store already works with the desktop application, and I can use it to add both MCP servers and skills to Werkbank.

The small curated catalog currently contains nine entries: three MCP servers and six SAP development skills. I can search it, filter by type, inspect the original source, and then click Add to Werkbank or Add skill.

The website validates the request and opens the local application through a werkbank:// link. Werkbank then shows the connector command and configuration fields, or the skill repository and name. Nothing is installed until I confirm it inside the desktop application. After that, a connector is restarted and becomes available to the conversation, while an installed skill appears in the / picker.

The same flow can be linked from any project README with an Add to Werkbank button. Here is the skill used in the video:

Add the SAP Fiori Guidelines skill to Werkbank

To try it, clone the repository, run npm install, copy .env.example to .env, add the model configuration, and start it with npm run dev.

What this little experiment shows

Werkbank is not a replacement for Joule Work Desktop. It is a small MVP built in roughly two days, with bugs and much narrower workflows. But it is already a usable desktop application: I can chat with it, attach files, connect tools, install skills, and return to earlier conversations and Spaces.

SAP also has to solve the difficult enterprise parts: identity, authorizations, data protection, auditing, deployment, updates, model governance, and reliable operation for many users and systems. A local MVP does not solve these problems just because the demo looks similar. With more time, I could add SSO, authentication against IAS, a release pipeline with signed builds, automatic updates, and more enterprise controls. That was not the main point of this experiment.

But the experiment still shows something useful. The core workflows SAP currently demonstrates are already possible with open-source components:

Read email and calendar context.
Work with local files and OneDrive-synchronized files.
Analyze structured data.
Create persistent dashboards.
Generate real Word and PowerPoint files.
Connect SAP documentation and SAP systems through MCP.
Add reusable skills and new connectors.

Goose is only one possible base. LibreChat can provide a similar experience in the browser. Microsoft Copilot Studio can combine Microsoft 365 connectors and MCP servers. Claude Desktop can also work with local files, connectors, and skills. The individual building blocks already exist.

The real value of Joule Work Desktop will therefore not come only from having these features. It will come from how well SAP connects them to business context, SAP authorizations, supported applications, and real processes. It will also depend on how accessible it is. Are Signavio, LeanIX, or SAP S/4HANA Cloud Public Edition required? Can a customer use it with only on-premise systems? And what will it cost?

For now, I am impressed by the direction. I just could not test the real application yet, so I built the part I wanted to test myself.

Disclosure: Werkbank is an independent open-source project and is not affiliated with or endorsed by SAP. SAP, Joule, ABAP, SAP Fiori, SAP S/4HANA, and other SAP products and services mentioned herein are trademarks or registered trademarks of SAP SE or its affiliates in Germany and other countries.

References and links

Introducing open-rfc: Calling SAP RFC from Node.js Without the SDK

Mon, 10 Aug 2026 09:30:00 +0200

If you ever wanted to call a remote-enabled ABAP function module from JavaScript or Node.js, you probably discovered quite quickly that this is not as easy as it sounds.

There is an RFC protocol. There are remote-enabled function modules. There is an npm package called node-rfc. So you would expect to install the package, add the connection details, and make the call.

But npm install node-rfc was never the complete setup.

You also need the SAP NetWeaver RFC SDK. You need the right authorization to download it from the SAP Support Portal, the correct build for your operating system and architecture, and the current supported patch level. The native libraries must be installed where the runtime can find them. On Linux that usually means configuring SAPNWRFC_HOME and the library search path. If no suitable prebuilt addon exists, you also need the C++ build toolchain, Python, node-gyp, and headers to compile the Node.js addon.

Then this has to work again in Docker, CI/CD, Cloud Foundry, Kyma, or wherever the application is deployed. The SDK cannot simply be bundled into a public npm package because SAP is its distribution channel. Even SAP’s own BTP and Kyma example has to copy the SDK into the buildpack application, rebuild the native module, and configure the library path for runtime.

This is all possible. Many projects have done it successfully for years. But it is quite a lot of setup for what starts as: I only want to call one function module.

A short history of RFC outside ABAP

The SAP NetWeaver RFC SDK is the native C and C++ foundation for RFC clients and servers. Projects such as PyRFC and node-rfc made it usable from Python and Node.js, but both remained language bindings around this separately installed SDK.

These projects were valuable and gave both ecosystems practical APIs. Their shared problem was the native dependency, followed by the end of maintenance. The last node-rfc release was published in November 2023, followed by PyRFC 3.3.1 in January 2024. In July 2024 SAP published the same announcement for node-rfc and PyRFC: changed priorities meant it could no longer maintain the projects. The bindings used an SDK patch no longer supported by SAP, with no planned update. After ownership could not be transferred to new maintainers, as explained in the final updates for node-rfc and PyRFC, both repositories were eventually archived on May 28, 2026. The node-rfc package on npm is deprecated too.

There are forks, but they keep the same basic architecture. You still need the native SDK, platform-specific binaries, and somebody able to follow SDK changes.

There is also a newer SAP path for CAP. The public @sap/cds-rfc plugin uses @sap-rfc/node-rfc-library for low-level RFC communication. That connector is not available on the standard npm registry. According to the plugin documentation, it is available only for Linux and Windows, and SAP customers need an S-user, an SAP Build Code license, and credentials for SAP’s Repository-Based Shipment Channel. macOS users have to use a container.

So the old open-source binding is archived, while the newer supported connector adds an entitlement, a private registry, and platform-specific deployment requirements. I would expect an easier answer from SAP for such a fundamental integration protocol.

The conversation that started open-rfc

For a long time I was not very concerned about this. Most of my RFC contact is inside ABAP, not outside it. When I had a small Node.js use case, the setup was complicated enough that I simply did not continue. With AI it may be a bit easier to fight through native build errors and deployment files, but the underlying dependencies are still there.

Then the topic came up during the evening events at Code Connect 2026. Even SAP employees were annoyed by the current situation. The discussion was more or less: this should be rewritten without those dependencies, and in the world of AI it cannot be that hard.

I started an AI coding session the same night.

Spoiler: even with AI, it is hard.

I have been working on it since that evening, with AI helping across research, implementation, tests, and review. The deeper I went, the clearer it became that writing something that works once is not the hard part. The hard part is proving that it behaves correctly across SAP releases and also in failures.

Once you go deeper into RFC, a much larger world opens up. The client first has to log on, understand the function module and its parameters, translate JavaScript values into ABAP values, send and receive sometimes large structures and tables, and keep the connection in a safe state when something fails. Timeouts are especially tricky: the application may not know whether SAP already executed the call. Retrying a write automatically could therefore execute it twice.

The good news is that RFC is documented better than I first expected. I used the official SAP NW RFC SDK 7.50 Programming Guide, the current SDK Doxygen documentation, the ABAP Keyword Documentation for the RFC protocol, interfaces, restrictions, and session context, plus SAP’s Network Interface documentation and relevant SAP Notes. The archived node-rfc and PyRFC APIs and tests are also important compatibility references.

I also used OWASP pysap and its documentation as a low-level reference for SAP network protocols. pysap, initially designed and developed by Martin Gallo, is a Python and Scapy packet-crafting and protocol-research toolkit, while open-rfc is an application-facing Node.js RFC client. Thank you to Martin and all pysap contributors for making this research available.

Most importantly, I do not only test against mocks. Because of ARC-1, I already have three ABAP trial systems for SAP NetWeaver 7.50, SAP S/4HANA 2023, and SAP S/4HANA 2025. Development tests run against all three. The formal first-beta support contract is intentionally smaller and qualifies NetWeaver 7.50 and S/4HANA 2023 with the exact packaged artifact.

I keep offline protocol, property, fault, resource, and compatibility tests separate from live SAP evidence. The supported node-rfc facade is exercised against a pinned corpus from the archived project. For a beta release, the same exact tarball must pass as a standalone dependency, as the node-rfc npm alias, and below unchanged @sap/cds-rfc. A green test from some earlier source checkout does not promote a different package.

What the first beta includes

The result is open-rfc, an SDK-free TypeScript and JavaScript RFC client for Node.js. The current beta is open-rfc on npm, licensed under Apache 2.0.

The installed package has zero runtime dependencies. It contains portable JavaScript and TypeScript declarations, with no native addon, no SAP NW RFC SDK, no post-install download, and no runtime framework. It supports ESM and CommonJS and the same package is used in three ways:

directly through the open-rfc API;
as an npm alias for existing node-rfc client and pool consumers; and
as the low-level connector below an unchanged @sap/cds-rfc installation.

The first beta focuses on direct application-server connections with password authentication and classic Unicode RFC. It includes metadata lookup and caching, synchronous function calls, common scalar values, exact decimals, date and time values, binary data, STRING and XSTRING, structures, tables, timeouts, cancellation, reset, bounded connection pooling, and representative commit and rollback paths.

It also includes Client and Pool facades for the common archived node-rfc API and the modern RFCClient and RFCConnection facade expected by SAP’s CAP connector. Unsupported security or serializer options fail before business I/O. A timeout, cancellation, malformed response, or uncertain send retires the physical connection, and open-rfc never automatically replays the call.

The official 0.2.3 release matrix currently qualifies Ubuntu 24.04 x64 with Node.js 22.14 or newer, or Node.js 24. Because the package is portable JavaScript with no native addon, it is expected to work on other Node.js platforms too. macOS, Windows, and other Linux versions are not official release claims yet, so I especially want users to report what they try there.

The 0.x line has no production SLA. Direct classic RFC also has no transport encryption or peer authentication by itself. It belongs on a trusted private network or inside a separately managed protected tunnel, not openly across the internet.

BTP, Cloud Connector, and an ARC-1 extension

open-rfc 0.2.3 also makes it possible to call an on-premise SAP system from BTP Cloud Foundry through SAP Cloud Connector. The documented route uses the BTP Connectivity service and Cloud Connector to reach the SAP system. I tested the exact published package end to end from Cloud Foundry to SAP S/4HANA 2023. This proves the path works, but it has not yet been tested broadly enough to be part of the release’s qualified scope.

I added the same setup to the ARC-1 extension sample. Its Custom_RfcSystemInfo tool calls the read-only RFC_SYSTEM_INFO function, accepts no user input, is off by default, uses a dedicated RFC user, and only returns selected fields. It shows how an ARC-1 extension can add an RFC tool beside ADT and OData without installing the SDK.

My tested setup uses a dedicated technical SAP user. Cloud Connector protects the connection between BTP and the company network. Inside the company network, RFC still needs a trusted network, and the technical user should only be allowed to call the exact function modules needed.

Why beta does not mean almost 1.0

This first beta is not a release candidate for 1.0. RFC has too many paths for that claim.

The default target for 1.0 is intentionally smaller: direct application-server RFC with password authentication, the standalone API, the node-rfc compatibility layer, and unchanged @sap/cds-rfc through the npm override. Before 1.0, this still needs deeper testing of failures, isolation, large values, transactions, pool contention, repeated runs, and long-running use. It also needs a frozen API and support policy, real adopters, operational readiness, and another independent security and correctness review.

Message-server load balancing, SAProuter, WebSocket RFC, and passing individual user identities through Cloud Connector are conditional candidates. They enter 1.0 only if the scope decision includes them and live tests can prove them. Otherwise they remain later work.

Other features are later work, not promises for 1.0: registered RFC server mode and ABAP callbacks, tRFC, qRFC, bgRFC, Throughput APIs, SNC, X.509, non-Unicode and MDMP systems, basXML, and complete SAP NW RFC SDK parity.

I prefer to make this boundary explicit. A package that accepts every option and silently ignores half of them looks compatible until the day it causes a production problem.

The CAP replacement I wanted from the beginning

One especially important goal was a drop-in replacement for @sap-rfc/node-rfc-library below SAP’s @sap/cds-rfc CAP plugin. I do not want to fork or rebuild the CAP layer. SAP’s unchanged package should continue to own RFC imports, destination lookup, Cloud SDK integration, multitenancy, and the CAP lifecycle. open-rfc should replace only the low-level connector.

With npm 11, the application can declare a nested override:

{
  "dependencies": {
    "@sap/cds-rfc": "2.2.1",
    "open-rfc": "0.2.3"
  },
  "overrides": {
    "@sap/cds-rfc": {
      "@sap-rfc/node-rfc-library": "$open-rfc"
    }
  }
}

Your CAP service code stays unchanged. The normal cds import --from rfc flow stays with @sap/cds-rfc, and existing cds.connect.to() calls still go through the SAP plugin. After installation, npm explain @sap-rfc/node-rfc-library shows whether the override resolved to open-rfc.

The dedicated CAP guide explains the full setup, importer boundary, local credentials, destination boundary, transactions, and shutdown behavior. This should make local development and CI/CD much simpler because the application installs an ordinary npm artifact. There is no SDK archive to copy, no native addon to compile, and no extra SAP npm registry credential for this connector.

The qualified beta scope still covers only the direct application-server route with password authentication. An easier installation does not magically qualify every destination and authentication mode, so please read the release status for the exact version you install.

I need your help

Now comes the most important part. I can build a lot and I am willing to put in the work, but I cannot reproduce every SAP system, function module, network route, value shape, and deployment environment alone.

The documentation is also part of the project, not a finished manual that users can only consume. It already covers the quick start, standalone and node-rfc use, CAP, Cloud Connector, configuration, safety, operations, troubleshooting, release status, and the road to 1.0. The sources live in the public docs_page folder. If something is unclear, wrong for your environment, or missing a useful example, please open an issue or improve the page. A clearer explanation or a correction from a real setup can be as valuable as a code change.

The public repository now also contains a broad offline test suite, and its documentation links and examples are checked automatically. The contribution guide explains how to prepare code and documentation changes safely.

Please test the beta with your real use cases, starting with a read-only function on a non-production system. Try the data types your application really uses. Test errors, cancellation, pools, and transactions, not only one successful RFC_PING. If you find a problem, open an issue with the open-rfc version, Node.js version, operating system, SAP release family, route type, function interface shape, and the smallest safe reproducer you can create.

Do not attach credentials, endpoints, system identities, business data, returned tables, raw traces, or packet captures to a public issue. If the problem needs private information, first describe the redacted shape so we can find a safe way to reproduce it.

If you prefer to throw tokens at the problem, do that as well. The repository ships a prompt written for exactly this situation: report an RFC failure. You do not need a checkout of the repository to use it. It has an agent first check whether your case is inside the documented boundary, then reduce the failure to a synthetic reproducer that keeps the real ABAP types and invents everything else, and finally fill in every field of the bug template. The redaction rules are part of the prompt, so an agent following it will not put your system identities, credentials, or business data into a public issue.

If you want to go further than reporting, the deep bug workflow picks up from there: root cause before any change, then a test that was seen to fail without the fix, then a focused pull request. External contributors will not have my private live-system evidence, so give the agent only a synthetic reproducer and public information. I can run the necessary SAP checks after the issue is reduced safely.

And of course, contributions are welcome. This project should not become one person’s private RFC implementation with a public repository around it. I want it to become truly open, understandable, testable, and useful for different scenarios.

That takes more work. I am ready to do it, but I need your systems, your use cases, your bug reports, and your review.

Let’s make this work.

References and links

ARC-1 1.0: One Deployment, Multiple SAP Systems

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

ARC-1 1.0 is here.

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.

UI5 Has Entered the Chat: Building Interactive MCP Apps for SAP

Mon, 13 Jul 2026 09:00:00 +0200

AI can appear in a user interface in several ways. It can add a focused feature such as summarization to a traditional application. It can sit next to the application as a copilot. Or the AI conversation itself can become the main interface.

That last case raises an interesting question: if the AI host owns the frame, how can an MCP server provide more than text and JSON?

MCP Apps provide an answer. They let an MCP tool return an interactive web interface that a compatible host renders inside the conversation. For our UI5con session, Mike Zaschka and I explored how this model fits SAP user interfaces and built five samples, starting with plain HTML and ending with an ARC-1 transport review.

This post focuses on the architecture and lessons from those samples. You can read the final presentation or follow the code in the sample repository.

What MCP Apps add to MCP

A normal MCP tool already gives a model a structured way to call backend capabilities. For a small result, a text response is often the best interface. A dedicated UI becomes useful when people need to filter findings, inspect a hierarchy, compare options, or confirm an action with more context.

An MCP App combines a tool result with a web resource:

A tool declares a ui:// resource URI in _meta.ui.resourceUri.
The model calls the tool through the host.
The host reads the referenced resource from the MCP server.
A compatible host renders the returned HTML in a sandboxed iframe.
The host passes the tool result to the app through the MCP Apps bridge.
The app can request supported host operations, including calls to tools on its MCP server.

In our samples, the model selects the tool but does not generate the interface. Each UI is prebuilt application code supplied by the MCP server. Communication between the iframe and host uses the MCP Apps protocol over a postMessage transport.

Host support still differs, so the official client support matrix is more reliable than a static list here.

The minimum HTML sample

The updated presentation explains the server side in three parts: register a UI resource, link it from a tool, and return the tool result. The repository’s plain HTML time sample implements exactly that pattern with two tools and one UI resource.

1. Register the UI resource

The server registers the built HTML under a ui:// URI. RESOURCE_MIME_TYPE from the MCP Apps server package resolves to the HTML profile expected by compatible hosts.

const resourceUri = "ui://html-time/index.html";

registerAppResource(
  server,
  "HTML Time Demo",
  resourceUri,
  {
    title: "HTML Time Demo",
    description: "A minimal MCP App."
  },
  async (uri) => readBuiltAppResource("00-html-time", uri)
);

The sample bundles the browser code and styles into one HTML file for convenient delivery. A single-file bundle is optional, not a protocol requirement. An app can use external assets when its resource metadata declares an appropriate content security policy.

2. Link the resource from a tool

The show_time tool points to that resource in its metadata:

registerAppTool(server, "show_time", {
  title: "Show Time",
  description: "Open the basic MCP Apps time demo.",
  inputSchema: {
    offsetHours: z.number().int().min(-24).max(24).optional()
  },
  _meta: {
    ui: { resourceUri }
  }
}, handler);

The URI must match the registered resource exactly. This association tells an MCP Apps host that the tool has a visual companion.

3. Return text and structured data

The tool calculates a timestamp and returns two representations of the outcome:

return {
  content: [{
    type: "text",
    text: `Current server time: ${isoTime}`
  }],
  structuredContent: {
    isoTime,
    offsetHours,
    formattedTime
  }
};

content gives the model and non-UI clients a concise fallback. structuredContent is the stable data contract the app renders without parsing prose. The complete server implementation is in register.ts.

Run the app inside the host

Inside the iframe, the app connects to the host and listens for the tool result:

const app = new App({
  name: "HTML Time Demo",
  version: "0.1.0"
});

app.addEventListener("toolresult", (result) => {
  renderTime(result.structuredContent as TimePayload);
});

await app.connect();

The interface shows the time and an Add 1 hour button. That button calls a second tool through the bridge:

const result = await app.callServerTool({
  name: "add_hour",
  arguments: {
    isoTime: currentIsoTime,
    hours: 1
  }
});

renderTime(result.structuredContent as TimePayload);

The host routes the request to the server and returns the result to the existing iframe. The app updates without asking the model to generate another interface. See the full browser code in main.ts.

This small example captures the important separation of responsibilities:

The model chooses the initial tool based on the user’s request.
The MCP server executes backend logic and returns text plus structured data.
The host controls whether and how the UI is rendered.
The app renders the data and handles local interaction.
Further tool calls still travel through the host-controlled bridge.

That is the core concept. UI5 changes the presentation layer, not the MCP Apps lifecycle. It also explains why debugging has two layers: a successful tool call does not prove that the UI resource loaded, and a loaded iframe does not prove that its scripts passed the host’s content security policy.

When a tool result should become an app

MCP Apps are useful, but they should not turn every tool call into a miniature application. Text is still the fastest interface for a status, identifier, confirmation, or short explanation. A table in prose may also be enough when the user only needs to read it once.

I would add an app when at least one of these is true:

The user needs to explore or filter a result without repeatedly calling the model.
The structure is easier to understand visually, such as a transport hierarchy or findings grouped by file.
The next action benefits from seeing context first, such as choosing a task after reviewing its objects.
A long-running or multi-step workflow benefits from visible progress and guided decisions.
The interaction has temporary presentation state that does not belong in the conversation.

The UI should stay focused on the result and its immediate actions. It should not recreate the host’s chat controls or hide backend behavior behind ordinary-looking buttons. If an action writes data, changes source files, or releases a transport, its effect should be clear before the request reaches the server.

Because the tool still returns normal content, a host without MCP Apps support can show a useful text result. The interface enhances the tool contract instead of replacing it.

Bringing UI5 into the iframe

An MCP App is a web application, so it can use plain JavaScript or frameworks such as React, Vue, Svelte, or UI5 technologies.

For focused SAP-oriented interfaces, UI5 Web Components are my preferred default. They provide SAP-styled, themeable and accessible controls while remaining based on web standards and usable with different frameworks. In the final sample, the app listens for the host’s light or dark context and maps it to sap_horizon or sap_horizon_dark. An MCP App can use familiar controls without adopting the full SAPUI5 application model.

UI Integration Cards are attractive when the result is naturally a summary, list, or compact dashboard. Their declarative manifests reduce custom rendering code. Our card sample loads the Integration Cards runtime from ui5.sap.com, so its resource declares that domain in its content security policy. An allowlist cannot override a host’s sandbox, however. The repository therefore uses portable Object and List Cards rather than an Analytical Card whose sap.viz runtime may require blocked execution features.

A full SAPUI5 application can also be served as an MCP App, but I would use it selectively. Fiori Elements’ OData-driven page model, routing, and shell integration can be excessive inside a small conversation frame. That is a design tradeoff, not a protocol restriction.

This is not an SAP-specific extension to MCP. It is the normal MCP Apps model combined with UI5. It nevertheless fits the direction described by SAP’s AI-native North Star user experience layer, where users express intent and the system brings relevant information and actions into context.

The distinction between MCP and MCP Apps matters here. Joule Studio documents how to add MCP servers to a Joule agent, using Streamable HTTP endpoints configured through SAP BTP destinations. That allows Joule agents to use server tools, but it does not by itself mean the host renders MCP App resources. At the time of writing, I could not verify documented Joule support for the MCP Apps extension in the official client matrix.

From the minimum sample to SAP workflows

The sample repository contains five steps and a repository-wide learning guide:

Plain HTML time: Demonstrates the tool, resource, result, iframe, and app-triggered tool call with minimal code.
UI5 Web Components project overview: Renders project metadata, libraries, and checks, synchronizes the host’s light or dark theme, and requires no external CSP domains.
UI Integration Cards project overview: Renders the same dataset as declarative Object and List Cards. Its external ui5.sap.com runtime is explicitly declared in the resource CSP.
UI5 lint findings: Opens the UI first, then calls back through the bridge to run the official UI5 MCP server as a child client, with a local ui5lint fallback. Filtering stays local. Ignoring one line, one rule in a file, or a whole file invokes an explicit write tool, after which the app can rerun the linter.
ARC-1 transport review: Provides separate list and detail tools for live, host-orchestrated ARC-1 data. Clearly labelled offline fixtures are included for rehearsals when ARC-1 or SAP is unavailable.

The ARC-1 example introduces an important boundary. The UI belongs to one MCP server, while ARC-1 is another. The app therefore does not secretly call an ARC-1 tool. When someone confirms a release in the UI, the app sends a message to the host asking the agent to continue the workflow. The host can then select the connected ARC-1 tool and apply its normal authorization and confirmation behavior.

My rule of thumb is simple:

Use callServerTool() for a known tool exposed by the server that owns the app.
Send a message to the host when the agent must coordinate another server or decide the next step.
Keep consequential operations visible to the host’s approval model.

Host UX, state, and security

The host owns the frame around an MCP App, which creates a few UX constraints that are easy to miss:

Display mode: an app may request inline, fullscreen, or picture-in-picture, but the host declares which modes it supports and returns the mode it actually selected.
Theme: the host can provide a light or dark preference and optional style variables. The UI5 Web Components sample maps that preference to sap_horizon or sap_horizon_dark and reacts when it changes.
Size: the host can provide fixed or maximum container dimensions. The SDK reports content-size changes automatically by default, but the interface should still be responsive within the space the host grants it.

An app-triggered callServerTool() can update the existing iframe, as the time sample demonstrates. A host may nevertheless recreate the iframe for a new UI-producing call or when its lifecycle requires it. Therefore, filters and selected rows can stay local, while important results belong in structured tool output or the backend. Durable changes, such as adding a linter ignore, belong in the project or backend. Refresh authoritative data after mutations instead of relying on iframe memory.

The iframe sandbox is also not a complete security model. The host controls bridge capabilities, while the server must still validate inputs and authorize tool calls. External scripts and network destinations need to be declared in the MCP App’s UI content security policy. Backend writes should be explicit and should not be disguised as harmless UI interactions.

Our samples use Vite and vite-plugin-singlefile to produce one built index.html for each ui:// resource. This simplifies delivery, although bundling UI5 Web Components increases the artifact size. The repository provides both stdio and Streamable HTTP launchers. These connect the MCP client and server; the app uses the separate iframe bridge.

Try the minimum sample

The repository requires Node.js 22. The exact commands and client configuration live in the minimum sample README. From the repository root:

npm ci
npm run build
npm run start:00

Connect an MCP Apps-compatible HTTP client to http://127.0.0.1:3010/mcp, then ask it to call show_time. The text result should remain useful even in a client that does not render the UI.

For a protocol-level check, start the aggregate server with npm run start and run npm run test:mcpjam in another terminal.

References

Creating an ARC-1 BTP Diagram with Codex and a draw.io Skill

Thu, 09 Jul 2026 09:00:00 +0200

I wanted one practical thing: an editable draw.io diagram for ARC-1 on SAP BTP that looks like it belongs in the SAP Architecture Center.

My first attempts with generic diagram prompts were not really useful. They often had dark backgrounds, icons that were too large, and arrows running through boxes. I wanted something closer to the SAP examples: a white canvas, the right BTP areas and service icons, understandable flows, and an editable draw.io file that I could still correct by hand.

That became marianfoo/btp-drawio-skill, a skill for creating SAP Architecture Center-style .drawio files from plain text.

Where this started

I did not start this from zero. The main source was SAP itself, and there are two related projects that are easy to mix up:

The SAP BTP Solution Diagram Guidelines define how these diagrams should look: levels, areas, colors, icons, connectors, labels, and legends. The complete guideline and editable examples are in SAP/btp-solution-diagrams.
The SAP Architecture Center publishes real reference architectures for topics such as integration, identity, data, AI, and resiliency. Their source, including many editable .drawio files, is in SAP/architecture-center.

The skill bundles selected diagrams and assets from these official sources. This gives the model both parts it needs: the visual rules and real SAP-authored examples.

Two community projects also appeared almost at the same time.

Wouter Lemaire published lemaiwo/btp-drawio-skill on April 17. I took inspiration from its Claude marketplace structure and the idea of bundling the SAP icon XML libraries directly with the skill.

One day later, miyasuta/claude-drawio-btp-diagram appeared. I liked its separation between official guidelines, conventions, and concrete draw.io styles. Its center-alignment rule for straight connectors also became an important detail in my implementation.

I started my repository on April 22 because I needed the ARC-1 diagram. From there I added a larger SAP Architecture Center corpus, template ranking, asset extraction, built-in fallback layouts, validation, scoring, visual comparison, and the nudge loop.

The main lesson stayed simple: do not generate SAP diagrams from scratch when SAP already published the visual language and many real examples.

Before the example, it helps to understand what the skill actually does.

How the skill works

Without the skill, the model starts with an empty canvas and has to invent the layout. With the skill, it first decides what kind of diagram is needed and then looks for the closest SAP example.

SAP defines three diagram levels based on the audience and required detail:

L0 is a business overview. It uses only a few blocks and simple neutral arrows. Technical details are left out.
L1 is a conceptual architecture. It shows named SAP services, the main zones such as BTP and on-premise, and the important flows between them.
L2 is a logical or technical architecture. It adds protocols, identity and trust flows, connector labels, and a legend. The ARC-1 example in this post is an L2 diagram.

The complete workflow looks like this:

Your architecture description
            |
            v
Choose the level and closest SAP example
            |
            v
Copy and adapt the example
            |
            v
Validate -> render -> inspect -> correct
            |
            v
Editable .drawio file and PNG

The repository currently bundles 71 reference templates, 100 SAP BTP service icons, and 448 indexed draw.io assets. Most templates come from the two official SAP repositories above, with a few additional public SAP examples.

Find a starting point. scaffold_diagram.py ranks the templates and copies the closest one. This copy is the scaffold.
Adapt only what changed. The model keeps the SAP layout and uses helpers such as relabel.py, extract_icon.py, and extract_asset.py to change labels and assets.
Use a smaller fallback when needed. If the closest template is much larger than the requested diagram, render_semantic.py can create a smaller layout for a few known patterns while keeping the SAP visual rules.
Check the result and look at it. autofix.py repairs known mechanical problems. validate.py checks colors, fonts, icons, labels, and arrow routing. score_corpus.py compares the result with the SAP examples. Then iterate.py and render_compare.py render the diagram so the model can inspect and correct it.

The important limit is that these checks only understand the file and its visual structure. They do not know if the architecture itself is correct.

The sample use case in Codex

For the sample, I used the exact problem that started this project: a developer in VS Code asks an AI assistant to inspect an ABAP class through ARC-1.

Developer and AI assistant in VS Code
                |
               MCP
                v
ARC-1 on SAP BTP Cloud Foundry
                |
Destination + Connectivity + Cloud Connector
                v
On-premise SAP ABAP system

XSUAA authenticates the client. Destination Service and Connectivity Service route the request through SAP Cloud Connector. Principal Propagation keeps the developer’s identity for the ABAP call.

The diagram should make this complete path understandable for an SAP platform or development team. I used Codex to create it and kept the first result, the correction, and all validation output for the example below.

The skill started as a Claude Code plugin, but the important part is portable. It is a folder with Markdown instructions, SAP templates, local assets, and Python scripts.

For Codex I cloned the repository and pointed an AGENTS.md file at the skill:

git clone https://github.com/marianfoo/btp-drawio-skill.git

For SAP architecture diagrams, use the sap-architecture skill at
<path>/btp-drawio-skill/plugins/sap-architecture/skills/sap-architecture.

Read SKILL.md completely. Always scaffold before editing. Run autofix,
validate, score, render, and inspect the image before finishing.
Never write the draw.io XML from scratch.

Codex reads the project instructions and can call the scripts directly. Python 3.8 or newer and shell access are required. The draw.io desktop app is only needed for PNG, SVG, or PDF export.

For the example I described one focused L2 architecture:

Create an L2 SAP Architecture Center-style diagram.

A developer uses an MCP-capable AI assistant in VS Code to inspect an ABAP
class through ARC-1. ARC-1 runs on SAP BTP Cloud Foundry and exposes /mcp
over Streamable HTTP. The client authenticates through XSUAA. ARC-1 resolves
a PrincipalPropagation destination, uses Connectivity Service and SAP Cloud
Connector, and reads the on-premise SAP ABAP system through ADT REST.

Zones: Developer Workstation, SAP BTP Cloud Foundry,
Customer On-Premise Network.

Output an editable .drawio, PNG, validation and score results,
and the numbered flow narration.

The complete prompt and a sanitized copy of the AGENTS.md used for the run are attached to this post.

Codex worked for 6 minutes and 42 seconds. It read the skill, ran the template selector, created a first pass, validated and rendered it, inspected the image, made one correction, and ran the checks again.

The selector correctly ranked ac_RA0001_E2B_CloudConnector.drawio first. But this SAP reference has 24 cards and a much larger scope. Removing enough cards for my focused ARC-1 flow would remove more than one third of the template.

Codex therefore switched to the skill’s built-in on-prem-connectivity renderer. This was one of the improvements I added: start with the closest SAP example, but do not force a large template into a much smaller use case. The renderer still uses the same SAP palette, dimensions, assets, and validation rules.

The first pass scored 100, but was wrong

This was the first complete diagram:

The validator returned OK, and the reference-free SAP-likeness score was 100.0/100.

That sounds good, but it was still wrong for my use case.

The title was generic. The VS Code flow used HTTPS instead of MCP. The backend connection said OData/REST, although ARC-1 uses the ADT REST API. It also named SAP S/4HANA even though I wanted a generic on-premise SAP ABAP system.

This is the part I find most useful. A score can tell me that the file follows the expected visual rules. It cannot prove that the architecture says the right thing.

Codex inspected the rendered PNG and made one focused correction. It kept the layout and corrected the labels and colors: MCP in teal, XSUAA and Principal Propagation in green, ARC-1 as the purple focus application, and ADT REST for the backend call.

The final result passed validation without errors or warnings. Its SAP-likeness score was 96.7/100, slightly lower than the first pass, but the diagram was now correct for ARC-1. The scorer still reported two vocabulary advisories for OAUTH JWT and mTLS PP. I kept them because they explain the exact identity flow and are already part of the skill’s L2 layout guidance.

While preparing this post, I found one more export problem. The draw.io file did not store the white page background explicitly, and one PNG export came out black. I set the page background to white in both attached .drawio files and exported them again. The validator had accepted the missing value as the default background. This was another useful reminder that I still need to look at the final image.

That is also why I would use a strong reasoning model for this task. The skill removes a lot of guessing, but the model still has to read the workflow, choose between a template and fallback, understand the architecture, inspect an image, and notice when a high-scoring result is semantically wrong. I did not compare several Codex models in this run, so this is not a model benchmark.

The artifacts from the run are available here:

How to prompt it

The skill works best when the prompt describes an architecture, not only a product list. Include:

Level: L0, L1, or L2, based on the audience and required detail.
Audience: business overview, solution architecture, or implementation team.
Zones: client, SAP BTP, SAP cloud applications, on-premise, or third party.
Exact services: this improves SAP icon and asset selection.
Backend systems: for example SAP S/4HANA, ECC, BW/4HANA, or a generic ABAP system.
Identity: IAS, XSUAA, OAuth, SAML, Principal Propagation, trust, and authorization.
Numbered flow steps and protocols such as MCP, HTTPS, ADT REST, OData, A2A, or SAML2/OIDC.
Constraints and exclusions: what must be shown and what should stay out.

A weak prompt is:

Draw ARC-1 with BTP and SAP.

That leaves the model guessing about the level, zones, identity, backend protocol, and even the purpose of the diagram.

The skill is also an authoring assistant, not a one-shot generator. Give visual feedback such as:

“The icons overlap the text. Use the normal SAP icon size.”
“The MCP flow should be teal.”
“Cloud Connector belongs in the on-premise network.”
“The backend call is ADT REST, not OData.”

Specific feedback maps to a concrete edit. “Make it better” usually does not.

Where it works and where it stops

It works best for a focused L1 or L2 diagram with explicit zones and flows, especially when a reference from the same architecture family exists.

Sometimes no close template exists. Then another model retry does not solve the problem. The skill can use a deterministic fallback for a few known patterns, but other diagrams still need manual draw.io work or another reference template.

The validator also cannot prove semantic correctness. The Codex run above showed that clearly. A diagram can be valid, visually SAP-like, and still use the wrong protocol or product name.

For me, the value is not a perfect architecture from one sentence. The value is a much better editable first draft, a repeatable way to check it, and a clear loop for the last correction.

A Clearer View of Your SAP Integrations Under the New API Policy

Tue, 02 Jun 2026 09:00:00 +0200

In April, SAP published a new API Policy (v.4.2026a). If you run SAP integrations of any kind, like middleware, custom extensions, analytics pipelines, RPA, or anything with “AI agent” in the name, you have probably already had the uncomfortable conversation. Are we still allowed to do that, and can we safely start the next project this way?

The honest answer is that nobody can fully answer that for you. That is the real problem.

When DSAG reacted to the policy, the loudest complaint was not the rules. It was the lack of clarity. Chairman Jens Hungershausen put it simply: “The question is which interfaces are used in the partner solutions.” Board member Michael Bloch called the undefined contractual status of the SAP Business Accelerator Hub “unacceptable” (CIO). SAP says existing integrations are not affected, but it has not written that down in a way customers can rely on. Analysts went further. Forrester told CIOs to push back.

That missing pre-project clarity is exactly the gap I built this for: a practical evidence workflow that helps you look at one real interface or automation approach at a time before you invest more time in it. It is not a replacement for SAP, not legal advice, and not a magic compliance stamp.

I have been following this closely. I am one of the consultants quoted in The Register on the AI clause. But commentary only goes so far. So I built something practical instead. It gives you an evidence-based view of your own interfaces against the policy, with sources and a confidence level.

It does not give you a verdict. That is on purpose. Here is why, and how it works.

Why nobody can give you a clean yes or no

The policy is only two pages, but it is broad. You may use Published APIs, the ones listed on the SAP Business Accelerator Hub or named in product documentation, for their Documented Use. It then restricts non-published or internal APIs (§1.2), specific and general controls like rate limits and bulk-extraction preconditions (§2), and the clause everyone worries about, §2.2.2: interaction with autonomous or generative AI that plans, selects, or executes sequences of API calls, plus large-scale extraction, unless you go through an SAP-endorsed pathway. At Sapphire 2026, SAP CTO Philipp Herzig spoke to the direction. The policy is about routing agentic access through governed, reliable pathways.

But here is the part that matters for a tool. In its own FAQ, SAP was asked the exact question customers and partners now care about: will there be a binding decision matrix or concrete examples that let them assess, before starting a project, whether an integration or automation approach is compliant and future-proof? SAP said no (FAQ Q49). Only SAP, your contract, or SAP support can give a binding answer for your landscape.

So any tool that prints “COMPLIANT” or “NOT COMPLIANT” would lie to you. The best you can honestly do is well-sourced, confidence-rated evidence, plus the right questions for SAP. That is what I aimed for, and it turns out to be more useful than a fake verdict.

What I built

The project has two parts: the skill itself, plus a monorepo for the SAP MCP servers it depends on.

The skill is sap-api-policy-evidence. You install it in Claude Code, Cursor, or Codex with npx skills. It does the reasoning. It frames your scenario into facts, classifies it against the policy clauses, gathers evidence, and writes the assessment.

The skill reads its evidence from five SAP MCP servers. Three of them I put into one npm-workspaces monorepo, sap-mcp-servers, with a shared SAP login module: the Business Accelerator Hub server (is this a Published API?), SAP Notes (is it explicitly not permitted?), and the Road Map Explorer (future plans only, never current permission).

The other two are separate servers I already had. One is my SAP Docs MCP server, for SAP Help and the Architecture Center, including released-object status and endorsed pathways. It also has a hosted URL, so you do not have to run it yourself. The other is ARC-1, my ADT MCP server, used read-only here for checks against a live SAP system.

The skill does the thinking. The MCP servers bring the evidence. You can wire up all of them for the best picture, or just a few. If a source is missing, the skill says so and lowers its confidence.

What an assessment contains

Every result has the same shape, so you can compare them and file them.

A fixed assessment label: Likely aligned, Likely not aligned, Needs SAP confirmation, or Not assessable from provided facts.
One confidence level: high, medium, or low. It only reaches high when strong sources back the finding, like API Hub and an authenticated SAP Notes session.
An evidence table that lists every source, what it said, how authoritative it is, and when it was retrieved.
Residual risk, the missing facts that would most improve confidence, and questions for SAP.
A disclaimer at the top and the bottom that this is not legal advice. This is not boilerplate. It is the main idea.

Four examples

1. The ODP-RFC pipeline you should check before June 9. Extracting BW/4HANA data into a lake or warehouse over ODP-RFC through a third-party tool is the classic case. It is also urgent, because the enforcement patch lands on June 9, 2026, based on SAP Note 3255746. Here is the short version of a real run, with the full report in the repo:

**Assessment:** Likely not aligned
**Confidence:** high
**Date:** 2026-06-02

Why: ODP-RFC for customer or third-party access to ABAP systems that contain
PI_BASIS, SAP BW, or SAP BW/4HANA (on-premise or private cloud) is prohibited
per SAP Note 3255746. SAP Note 3439624 ships a self-assessment tool, and a
June 2026 security patch blocks unpermitted calls. The API Hub returned no
published artifact for ODP-RFC or RODPS_REPL.

Endorsed alternatives: SAP Business Data Cloud with Delta Sharing (including
BDC Connect for Snowflake), ODP-OData, or SLT where licensed.

Questions for SAP: confirm the migration target for this data scope, and the
deadline relative to the June 2026 blocking patch.

That is more useful than “not allowed”. It cites the Note, points to SAP’s own self-assessment, names real alternatives, and gives you the questions to ask.

2. A third-party AI agent reaching into SAP. This is the §2.2.2 worry. It is the clause that touches tools like Agentforce, Copilot, ServiceNow, Workday Illuminate, and Celonis. The skill does not flag every agent as forbidden. A read-only developer assistant is fine. A deterministic RPA bot is out of scope (FAQ Q40). But an autonomous agent that plans business-API call sequences through a custom gateway lands on Likely not aligned, and the report points to the endorsed pathway, like the MCP Gateway on SAP Integration Suite, or Joule with the Agent Gateway. Here is the short version of a real run, with the full report in the repo:

**Assessment:** Likely not aligned
**Confidence:** high
**Date:** 2026-06-02

Why: API_SALES_ORDER_SRV itself is published and active, but an autonomous
third-party AI agent that plans and executes read and create calls through a
custom-only MCP gateway triggers the agentic-AI control in section 2.2.2(a).
No SAP-endorsed path or written authorization was provided.

Endorsed path: expose the API through the MCP Gateway on SAP Integration Suite,
or A2A with Joule and the Agent Gateway, instead of a custom gateway.

The point is the nuance, not a blanket yes or no.

3. “Which of these are we even allowed to use?” This is the DSAG complaint turned into a workflow. You give the skill a list of interfaces, for example API_SALES_ORDER_SRV, RFC_READ_TABLE, SD_SALESDOCUMENT_CREATE, ODP-RFC, and I_SalesDocument. It returns one timestamped table: status per interface, the evidence behind it, the documented alternative, and which rows still need a full assessment. Here is the short version of a real run, with the full report in the repo:

**Assessment:** Likely not aligned   **Confidence:** high
Portfolio: 1 prohibited, 1 discouraged, 1 not-found, 2 released or published.

ODP-RFC              Prohibited    SAP Note 3255746
RFC_READ_TABLE       Discouraged   SAP Note 382318 (not a released API)
SD_SALESDOCUMENT_*   Not found     no released or published evidence
API_SALES_ORDER_SRV  Published     SAP Business Accelerator Hub
I_SalesDocument      Released (A)  released-object data, Clean Core A

There is no SAP-published master list, so this is the closest thing you can build yourself. It is clearly marked as evidence captured on a date, not an SAP-approved allowlist.

4. The same API, but a normal integration. This is the positive case, and a good contrast to example 2. We sync about 500 sales orders per day from Salesforce into S/4HANA Cloud using Boomi, calling the standard Sales Order OData API (API_SALES_ORDER_SRV) with OAuth 2.0. It is the same API as in example 2, but a deterministic middleware flow instead of an autonomous AI agent. Here is the short version of a real run, with the full report in the repo:

**Assessment:** Likely aligned
**Confidence:** medium
**Date:** 2026-06-02

Why: API_SALES_ORDER_SRV is active and published on the SAP Business
Accelerator Hub for S/4HANA Cloud (OData V2, OAuth 2.0, not deprecated). The
~500 orders/day is bounded operational use, not bulk extraction, and there is
no AI agent planning the calls. So the SAP-facing API and the usage pattern
both look documented.

Confidence is medium, not high, because tenant-specific rate limits, the
communication arrangement, and quotas are not visible in public sources. SAP
or tenant operations would confirm those and move it to high.

The contrast is the point. Example 2 and this one call the exact same Sales Order API. The assessment changes because the usage pattern is different, not the API. That is the whole idea of the policy. The question is the API surface and how you use it, not the tool.

The real value: evidence you can take to SAP

This is the part I care about most. It is also why a non-definitive tool beats a fake-confident one.

SAP’s own enforcement posture is dialogue first, not penalties. For existing integrations, SAP says it wants to make contact before it throttles anything (FAQ Q11, Q19). So the conversation is coming. The only question is whether you walk into it prepared or guessing.

An evidence report changes your position.

You know your own exposure before SAP does. You can inventory your interfaces and classify them now, instead of finding out which ones matter when a pipe breaks.
You can have a specific conversation. “Here is interface X, here is its API Hub status on this date, here is the relevant Note, here is our usage pattern and volume, please confirm.” That is a very different meeting than “we think we are probably fine.”
You can push back where the evidence is on your side. If something is a Published API used within Documented Use, you have the sourced proof in hand. That helps when a partner solution or your own extension gets questioned.
You can escalate the real gaps. Where no documented API exists, the report says so and points you to the SAP Customer Influence portal, instead of quietly relying on an undocumented interface.

It also works next to SAP’s own tools, not against them. SAP Note 3439624 self-assesses ODP-RFC. The ABAP Test Cockpit Cloud Readiness Check finds non-released dependencies. The skill goes wider. It can cover any interface, the policy reasoning around it, and the endorsed alternative, and it gives you something you can put in front of your account team.

It knows its limits

That honesty is built in, not just promised. The skill sends legal, commercial, and roadmap questions to SAP instead of guessing. It lowers its confidence when strong sources are not connected. It never asks for or stores credentials or business data. ARC-1 stays read-only. If you ask for a plain yes or no, you get the disclaimer, not a number. I tested all of this across 22 evaluation scenarios that cover every branch of the policy, including cases built to make it over-flag or under-flag.

Try it

npx skills add marianfoo/sap-api-policy-skill --skill sap-api-policy-evidence

Then wire up the MCP servers. Most run with npx -y, SAP Docs has a hosted URL, and the three authenticated servers share one SAP login. The full setup, including auth, MFA, and the single-login flow, is in MCP_SETUP.md. The SAP API Hub and an authenticated SAP Notes session are what unlock high-confidence assessments. With fewer servers it still works, and it tells you what was missing.

One honest warning before you start: this is not a simple setup, and some of the servers read SAP sites through a browser login, not through official public APIs. The SAP Notes and Business Accelerator Hub servers work this way. So use them at your own risk, and check first that this is fine for you and your organization.

Then ask in plain language, for example: “Is it OK under the API policy to extract our BW/4HANA data into Snowflake nightly via ODP-RFC?” Then read the evidence.

Open source, and honest about what it is

Both repos are public and use permissive licenses. The skill is MIT, the servers are Apache-2.0. The servers are published to npm with build provenance, and you can self-host everything if you need data residency. Issues and contributions are welcome.

To be honest, I would rather not need this at all. If SAP gave clear guidance on which interfaces are affected, we would not be left in this state of uncertainty. Until that changes, this is the best I have found. At least it gathers the sources for you, automatically and in one place, so you can decide from there.

You still cannot get a binding compliance verdict from a tool, and you should be careful with anyone who promises one. But you can replace hallway guesswork with current, sourced evidence and a clear list of what to confirm with SAP. Getting that clarity across your whole landscape, in minutes, is the real win. It is also a much stronger position to argue from.

Sources

SAP API Policy v.4.2026a (PDF): the policy itself, plus the FAQ it references.
SAP Note 3255746: data integration without ODP-RFC: the ODP-RFC prohibition and the June 9, 2026 enforcement date, with SAP Note 3439624 as the self-assessment tool.
CIO: DSAG criticizes SAP’s new API policy: the transparency and “which interfaces are affected?” concerns.
The Register: AI clause in new SAP API policy provokes lock-in concern: §2.2.2, lock-in, and SAP’s response.
Forrester: SAP is attempting to become the gatekeeper of enterprise AI, CIOs should push back: the analyst pushback.
diginomica: Sapphire 2026, SAP CTO Philipp Herzig on the API policy changes: SAP’s framing.

Project: sap-api-policy-evidence skill · sap-mcp-servers (MCP servers) · npx skills CLI

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

SAP’s ABAP-1 Loses Every ABAP Benchmark, Even “Explaining”

Tue, 03 Mar 2026 22:00:00 +0100

Previous post (code generation benchmark): Benchmarking LLMs for ABAP

Live benchmark results (old + new): abap-llm-benchmark.marianzeis.de

In my first evaluation (based on the TH Köln benchmark paper), I extended the original setup with additional models and focused on a very concrete question: how well can LLMs generate ABAP code that actually compiles and passes ABAP Unit tests?

I also tested SAP’s model ABAP-1, and it performed very poorly for code generation. To be fair: SAP also states this in the documentation. ABAP-1 is primarily meant for explaining ABAP code not for reliably generating full working implementations.

So I built a second test that targets exactly that: understanding and explaining ABAP.

The “Understanding” test

In the “Understanding” benchmark, the model gets existing ABAP code plus the corresponding ABAP Unit tests (so this is not a generation task). From that, it must extract concrete facts as structured JSON, for example:

which classes and methods are relevant
expected behavior and validations
inputs and outputs

The JSON output is then scored automatically against a reference, so we can measure in a reproducible way how well a model understands ABAP code and describes it correctly. This works without running SAP or ADT.

Here is the key result as a chart (cumulative success across feedback rounds):

What this says about ABAP-1

As expected, ABAP-1 is clearly better in this “Understanding” setup than in code generation. But it still does not keep up with current general-purpose models.

Even the current Anthropic Haiku model (optimized for speed and cost) beats ABAP-1 on this benchmark.

That makes the practical conclusion pretty simple: for almost any ABAP use case, ABAP-1 is not a good default choice. It is priced closer to premium models, but does not deliver premium results. So the “maybe it is cheaper” argument also does not hold.

New models

After the first post, people asked for more models to be added. I’m tracking those requests as GitHub issues here: LLM-Benchmark-ABAP-Code-Generation issues

I added the following models:

DeepSeek Reasoner
Mistral Large 2512
GPT-5.3 Codex
Claude Haiku 4.5
Gemini 3.1 Flash Preview

To put the “new models” into context, here is the updated code generation overview (this is the original benchmark: generate ABAP, then iterate with compiler/test feedback up to 5 rounds). The plot already includes the new lineup:

GPT-5.3 Codex produced very strong results and even beat Opus 4.5 on some metrics. My guess is: if we compare against Opus 4.6, the gap will likely be small (or they might end up roughly equal).

Depending on the metric, Opus 4.5 is still excellent: it has the highest first-try success rate (Round 0) and the best AUC across all feedback rounds.

Unfortunately, Mistral’s current “best” model performed worse than I expected and does not look like a great choice for ABAP.

For price/performance, DeepSeek Reasoner is the clear winner in this lineup.

Using the public list prices (at the time of writing), Codex is at around $1.75 per 1M input tokens, while DeepSeek Reasoner is at $0.28 per 1M input tokens (more than 6x cheaper). The bigger difference is output: DeepSeek output is $0.42 per 1M tokens, while Codex output is around $14.00 per 1M tokens (about 33x).

Gemini 3.1 Flash Preview

Gemini 3.1 Flash Preview also surprised me with strong results. It is cheap and in my runs it was even slightly ahead of GPT-5.3 Codex, while being significantly cheaper.

At the time of writing, Gemini Flash was roughly $0.50 per 1M input tokens and $3.00 per 1M output tokens, which is a big difference compared to Codex pricing.

Unfortunately, I could not test Gemini 3.1 Pro: the rate limit was effectively capped at ~25 requests per minute and I repeatedly hit 503 errors (“system overloaded”). With several thousand requests, that made a full benchmark run impractical. My guess is that Gemini 3.1 Pro would be similar to, or better than, GPT-5.3 Codex, but Flash already delivered very good results.

Why Haiku 4.5 did so badly here

Haiku 4.5 failed systematically because it kept using CDS-style type notation like abap.char(20) in classic ABAP implementations (syntax errors). Worse, misleading parser error messages made it hard for the model to identify the real root cause, so it did not correct itself even across multiple feedback rounds.

A practical takeaway

For me, this is now a pretty solid baseline to decide which models are worth considering for ABAP, and which ones are not, depending on whether you care more about API calls (cost) or daily development (quality + speed).

One important reminder: these models acted only on what they already “know”. Results can be improved a lot with tooling and better context, for example:

ABAP MCP Server for ABAP best practices and keyword documentation: marianfoo/abap-mcp-server
abaplint for static checks and fast feedback loops: abaplint.org

With that kind of tooling and feedback loop, you can generate very good ABAP code even if you “only” use a strong general model.

And yes, my conclusion from the first post still stands: I would not recommend ABAP-1. If SAP wants better outcomes, I think the bigger lever is not “yet another model”, but better tools and better integration so frontier models (OpenAI, Anthropic, Google) can reliably produce correct ABAP in real-world projects.

You can still suggest models I have not tested yet, but benchmarks like this are not cheap. For now I will pause adding more models unless there is a very strong reason to do another run.

References & links

TH Köln paper: Benchmarking Large Language Models for ABAP Code Generation
Previous post (code generation benchmark): Benchmarking LLMs for ABAP
Live results website: abap-llm-benchmark.marianzeis.de
Original benchmark repo (TH Köln): timkoehne/LLM-Benchmark-ABAP-Code-Generation
Dataset (prompts + ABAP Unit tests): dataset folder
Benchmark repo (my fork with updates): marianfoo/LLM-Benchmark-ABAP-Code-Generation
Model requests / discussion: GitHub issues
SAP ABAP-1 documentation: SAP ABAP-1
ABAP Cloud Developer Trial (Docker image used by the benchmark): SAP-docs/abap-platform-trial-image
Batch APIs (used for running large benchmarks cheaper): OpenAI Batch API, Anthropic batch processing
Pricing references:
- OpenAI: API pricing
- DeepSeek: Pricing (official docs)
- Google Gemini: generative AI pricing
- Anthropic: Claude API pricing

Benchmarking LLMs for ABAP: Why ABAP-1 Isn't a Code Generator (Yet)

Mon, 09 Feb 2026 09:30:00 +0100

Live benchmark results: abap-llm-benchmark.marianzeis.de

In a lot of SAP webcasts and webinars, especially around AI, the question comes up very early: which model are you using, and which one do you recommend?

For CAP and UI5 the answer is usually pretty simple: use the current best model from Anthropic. If you add good context via MCP servers from the community or SAP, you are basically fine. There is just a lot of public knowledge available, and most of it is in JavaScript/TypeScript, which LLMs handle extremely well.

With ABAP it’s different.

ABAP is not the framework, it’s the language. And compared to JavaScript/TypeScript, far less ABAP knowledge and code is publicly accessible, so models simply know much less about it.

Sure, you can help with extra context and tooling, but if you want this to work well, the model should already have a solid ABAP base. A good foundation makes it much easier to build on top.

So how do you figure out which models are actually best for ABAP? Anthropic, Google, OpenAI, or maybe ABAP-1 from SAP?

Luckily, TH Köln recently published a paper that answers exactly this question: Benchmarking Large Language Models for ABAP Code Generation.

The benchmark

The paper builds a benchmark so different LLMs can be compared fairly for ABAP code generation.

It includes 180 tasks (HumanEval adapted to ABAP plus a set of ABAP/SAP practical scenarios). The flow is fully automated: the model generates ABAP code, the code is created and activated in a fixed SAP environment (ABAP Cloud Developer Trial image documentation), and then ABAP Unit tests run against it.

If syntax checks or tests fail, the model gets the error messages as feedback and can try again for up to 5 rounds. In the end, it’s not about whether the code “looks plausible”, but whether it actually passes the tests (and how quickly it gets there).

The nice part: the authors published everything.

Original code: LLM-Benchmark-ABAP-Code-Generation
Dataset (prompts, unit tests, expected classes): dataset folder
My updated benchmark repo (additional models, speed-ups, plots, data, webpage): marianfoo/LLM-Benchmark-ABAP-Code-Generation

Updating the benchmark

One small problem: the evaluation in the paper is from mid-2025 (for example using GPT-5 and Claude Sonnet 4). The model landscape moves fast, and now we already have things like GPT-5.3 and Claude Opus 4.6.

So I wanted a way to update the results and include additional models that are relevant for ABAP.

I built on the original benchmark and added runs for additional models, so I can compare them against the original GPT-5 and Sonnet numbers:

Anthropic Claude Opus 4.5 (4.6 will be next)
OpenAI GPT-5.2
SAP ABAP-1

I also made a few changes to speed up execution:

For OpenAI and Anthropic I used the vendor batch APIs like in the original code (OpenAI Batch API, Anthropic batch processing). GPT-5.2 Codex was not available via batch for me yet, but that model will be next.
ABAP-1 has no batch API, so I implemented a parallel execution with multiple threads.
I also parallelized the execution on the ABAP Trial system itself to reduce overall runtime. I’m happy I have a well-equipped MacBook, but during the runs RAM usage and fan speed were definitely not idle.
Since there is a lot of Python code and I don’t know Python well enough, all the coding was done with AI help.

The next step is a small website with an overview of the current results and an easy model comparison.

You can find the current results here: abap-llm-benchmark.marianzeis.de

So what is the best model for ABAP?

Not too surprising: the best results came from GPT-5 and Claude Opus 4.5, with a small edge for Opus.

To make it more concrete, here are the cumulative success rates from my current comparison (Round 0 = first attempt, Round 5 = after up to 5 feedback iterations with compiler/test errors):

Model	Round 0	Round 5
Claude Opus 4.5	31.61%	78.72%
GPT-5	19.28%	77.11%
GPT-5.2	16.33%	64.00%
SAP ABAP-1	10.67%	19.89%

Here is the same as a chart:

Cost (rough numbers)

One more thing people ask quickly: cost.

For my run, I ended up at about $20.26 for GPT-5.2, $39.76 for Claude Opus 4.5 (8,973,159 tokens), and EUR 98.80 for ABAP-1 (17,983,990 tokens).

To be fair: for OpenAI and Anthropic I used batch processing, so these numbers are already discounted (batch is usually cheaper, sometimes roughly half compared to the regular API). ABAP-1 has no batch API, so there is no discount like that.

Why was ABAP-1 so much more expensive? The benchmark is iterative: when activation or ABAP Unit tests fail, you send the error back to the model and try again. Since ABAP-1 produced errors much more often, many prompts did not get “finished” early and had to be sent again and again, which drives up tokens and cost.

What I find interesting here is not only the final number, but also how the models behave across the feedback loops.

Why is GPT-5.2 worse than GPT-5 (in this benchmark)?

I can’t prove the exact reason (this is a black box), but based on the patterns in the benchmark it looks like GPT-5 is simply better at using compiler feedback to dig itself out of ABAP syntax and declaration issues.

GPT-5.2 still does fine, but compared to GPT-5 it is:

less consistent across reruns (about 41% of prompts solved 10/10 vs about 59% for GPT-5)
less likely to recover from certain ABAP-specific errors within a few feedback rounds

My best guess is that GPT-5.2 is tuned differently (for example more general, faster, cheaper, or optimized for other coding workflows), and that does not translate 1:1 to “generate a full ABAP class that compiles and passes ABAP Unit tests”. Maybe when using the codex model, the results are better.

Claude Opus 4.5

Opus starts very strong in Round 0. That usually means less back and forth for basic ABAP class structure and syntax, and more time spent on the actual logic.

In practice, this is what you want: you want to reach the unit test stage quickly, because that feedback is much more actionable than “your code does not activate”.

SAP ABAP-1

ABAP-1 is clearly not competitive for code generation in this benchmark, and it also benefits much less from the feedback loops.

This matches what SAP writes in the docs: ABAP-1 is mainly meant to explain ABAP code, while generation is experimental. For me, ABAP-1 is still useful as an “ABAP explainer”, but if you want to generate correct ABAP code fast, you still want a strong general model plus good tooling and feedback loops.

What this means in practice

This matters most when you work with APIs and actually build things. If you only call APIs, the model choice matters more. If you actively develop, it matters a bit less because we can add a lot of context and feedback loops.

When developing ABAP, we can provide much more context (for example via my ABAP MCP server), catch syntax errors early, run tools like abaplint, and then feed that back into the LLM to improve the code, basically like in TypeScript. That usually gets you to pretty good ABAP code that also follows your rules.

Depending on cost, I’ll try to keep this up to date with newer models. If you have a model you want to see in the comparison, just open an issue in the benchmark repo: GitHub issues.

Big thanks to Stephan Wallraven, Tim Köhne, Hartmut Westenberger, and Andreas Moser for creating the foundation with their benchmark and paper.

Network Request & Response Copier: An OData-Friendly DevTools Request Viewer

Thu, 05 Feb 2026 09:30:00 +0100

AI assistants already help a lot, but they work best when you can give them good context. In web apps, the most important context is usually the real traffic between frontend and backend: request URLs, payloads, and responses.

When debugging, I want to copy that information quickly and completely. And since I mostly work with UI5 and OData, I usually need the full URL plus request and response body. In Chrome DevTools that often means a lot of manuall copy pasting, and if you need more than one request, it gets annoying fast.

So I did the obvious thing: I built a small Chrome DevTools extension with AI help that solves this problem for me. Yes, I could also use MCP tooling or an automated browser to extract network data, but for day-to-day debugging I care about speed and I usually know exactly which requests matter.

After using it locally for a while, I decided to publish my first extension in the Chrome Web Store.

Install it here: Chrome Web Store

Update (2026-02-10): Also available in the Microsoft Edge Add-ons store.

Source code: GitHub

The solution

Network Request & Response Copier adds a dedicated panel to DevTools that shows network entries in a clean, sortable list.

Left panel: sortable request list with filters, a payload preview, and pinning
Right panel: request payload (top) and response body (bottom)
Copy buttons: copy the selected entry, all filtered entries, or all pinned entries

And the part that matters most for my work: it makes OData traffic much easier to work with, especially $batch requests.

Key features

Copy in one click: Copy the selected entry with Ctrl/Cmd+C, or export all filtered or pinned entries. Output includes method, URL, payload, and response in one readable block.
OData $batch parsing: Splits multipart $batch into per-operation blocks and shows a quick “what’s inside” preview in the list (for example: PATCH MockConfig | GET Users).
Better OData overview: Keeps long $select and $filter URLs readable and shows request and response side-by-side, which makes sharing context (and debugging) much faster.
WebSocket included: Captures sent and received messages and shows them alongside HTTP entries.
DevTools-like workflow: Sort, search, filter by method, resize panes, pin important calls.
Stays fast: 500-entry cap, throttled UI updates, cached parsing.

How it works (short version)

Runs as a DevTools panel, so it only exists while DevTools is open.
Collects HTTP traffic via chrome.devtools.network.onRequestFinished (HAR entries).
Detects and parses $batch payloads to show a per-operation overview.
Captures WebSocket messages by instrumenting WebSocket in the inspected page.
Copies to clipboard with fallbacks that work in the DevTools environment.

You’re welcome to use it and let me know what you think, try it out suggest changes!

Finally: An MCP Server for ABAP

Wed, 04 Feb 2026 09:30:00 +0100

Finally, there is an MCP server for ABAP.

You can use it directly in Eclipse via https://mcp-abap.marianzeis.de/mcp.

Setup instructions are here: Eclipse configuration (GitHub Copilot)

Why a community ABAP MCP server?

SAP has announced an MCP server for ABAP, so why create a community one?

The trigger for me was the release of Agent Mode in GitHub Copilot for ADT, which finally makes it possible to edit ABAP code by Copilot.

LLM models are already really good, but ABAP knowledge is still a recurring problem. So I wanted an MCP server that is actually tailored for ABAP.

For that, I took my existing MCP server for SAP docs, removed documentation that is irrelevant for ABAP, and added ABAP-specific sources like Official ABAP Keyword Documentation, DSAG ABAP Development Guidelines and ABAP Style Guide.

I also tweaked the MCP tools so that search automatically looks beyond local docs and includes SAP Community posts and SAP Help, then returns the best results. And since GitHub Copilot in Eclipse is not exactly the fastest, getting to relevant context quicker makes a real difference.

Here is what it looks like in Eclipse:

Why Eclipse matters (right now)

GitHub Copilot for Eclipse is especially important right now because (currently) Joule for Developers in Eclipse is not available for S/4HANA on-premise systems. For many ABAP developers in Eclipse, Copilot is the only practical way to use LLMs today.

Sure, there is also VS Code, and SAP will support it in the near future. But let’s be honest: not every ABAP developer is even on Eclipse yet. And the “average developer” is not going to switch to VS Code now, and probably not anytime soon either.

So this means: right now, every ABAP developer, no matter which system, can use LLMs in Eclipse and also access ABAP-specific knowledge.

Competition is good, so I published the ABAP MCP server as open source. That way, we have something to compare once SAP releases their own ABAP MCP server. And it also gives us a useful alternative to Joule for Developers.

Uwe Fetzer already tested the new ABAP MCP server and confirmed it works better than the SAP MCP Docs server: saptodon.org post

Try it out and let me know what you think! You can use either the deployed version on my server or run it locally with Node or Docker.

Update (2026-02-05)

Since publishing, I added two new capabilities:

Software Heroes as an online search source: The search tool can now also pull relevant content from Software Heroes (including German and English results).
New abap_feature_matrix tool: You can query the ABAP Feature Matrix to quickly check feature availability across releases and ABAP Cloud, also provided by Björn Schulz.

Huge thanks to Björn Schulz for offering his APIs and making these integrations possible.

More info about the tools and sources is in the GitHub Repo README: https://github.com/marianfoo/abap-mcp-server#available-tools

Animalist in German: I Had to Build This

Mon, 02 Feb 2026 09:30:00 +0100

I found Vivian Rose’s little web game “List Animals Until Failure” through a Hacker News thread (HN discussion) and immediately got hooked.

Then I typed my first few animals… and realized my English animal vocabulary is not exactly perfect. So I did the only sensible thing and made a German version.

The UI text is mostly translated with AI help (as all the other code). The part that actually took time was getting the animal names.

What the game is

It’s simple: you type animal names until you fail. If you repeat something, or you try to sneak in a too-broad term after a more specific one (and vice versa), the game calls you out.

The magic is that it feels instant because when you load the app you also load the complete animal list.

Where the animal list comes from

Vivian explains the original approach in her write-up (blog post): the game is powered by Wikidata + Wikipedia, and it ships a big offline lookup table so gameplay needs no network calls.

At a high level, the original project:

mines Wikidata entities representing taxons and builds a parent/child tree
uses Wikipedia article titles + redirects (and some extra heuristics like disambiguation pages) to decide what inputs should count as “the same animal term”
has a bunch of hand-tuning for edge cases

For the German version, I took a pragmatic route:

keep the same Q-IDs and taxonomy structure from the original dataset
fetch German names for those Q-IDs from Wikidata in batches
write out the German lookup tables that the game uses at runtime

I ended up with a few small Python helpers: one to fetch the German names from Wikidata, one to re-try missing entries, and one to add common singular forms (so “hai” works even if the canonical title is “haie”).

Credits

This exists because Vivian Rose built something genuinely fun and also wrote about it:

Original game: List Animals Until Failure
Original repo: Roachbones/animalist
Original write-up: blog post

And here’s my German adaptation again:

German version: animalist-de.marianzeis.de
Repo: marianfoo/animalist_de

Supercharged Local Open Source Joule for Consultants: Search Your Data & Code

Wed, 29 Oct 2025 09:30:00 +0100

This post is a mirrored copy of my LinkedIn article, kept here so it remains searchable and independent from external platforms. You can still find the original on LinkedIn: LinkedIn Pulse article.

Joule for Consultants costs 250 € and mainly searches SAP Help, SAP Community and SAP for Me (Notes). That is useful, but it stops where real projects start: your own systems, codebase and sensitive data. Even though public assistants like ChatGPT and Claude can already reach SAP Help and SAP Community, the real gap is internal/authenticated data and code.

For this case I created a LibreChat fork that includes and auto-starts SAP MCP servers (Docs, Notes, S/4 OData and ABAP ADT) via Docker. So the MCP Server are local inside your Docker and no external MCP Server is used. LibreChat is an open‑source local chat UI with MCP support and built‑in Ollama integration, and it also supports many other model providers. You get a private assistant that can read official docs, inspect code and data from your systems without sending customer context to third‑party clouds. The fork’s documentation is here: sap‑mcp‑docs.

Running the assistant locally means the client, tools and, if you choose, the model stay on your machine (LibreChat supports Ollama), so you avoid pasting sensitive context into public chats. By adding S/4 OData and ABAP ADT, you bring real metadata, code and data into the loop.

Which MCP servers are used here?

The SAP Docs MCP provides unified search and fetch across SAPUI5/OpenUI5, CAP, ABAP keyword docs, SAP Help and SAP Community. The SAP Notes MCP is for searching and fetching SAP Notes when you have an error, OSS number or concrete symptom; it requires an S‑User certificate (Passport). The ABAP ADT MCP reads ABAP sources, DDIC structures and tables content via ADT APIs so you never paste code into chat and still get precise context. The S/4 OData MCP discovers services and exposes safe CRUD tools so your assistant can read and write via approved APIs.

How this works in practice

In my example I used o4‑mini from OpenAI, but LibreChat supports many model providers including OpenAI, Anthropic, Google, Azure AI Foundry and even SAP AI Core (not tested by me). The key point: you can also use a local model via Ollama. Depending on your use case, a local model is smart enough to call the right tools and MCP servers. I also use an ABAP Cloud Developer Trial instance connected via the S/4 OData and ADT MCP servers.

SAP Notes lookup + ABAP table verification

This first example flow combines the SAP Notes MCP and ABAP ADT MCP. First the assistant searches and fetches a specific SAP Note (sap_note_search, sap_note_get), then verifies the relevant DDIC table and fields via ADT. This confirms the symptom and the fix steps before proposing a safe, auditable corrective action (for example, an OData action). This is the pattern for many “error → note → verify → fix” tasks.

Service metadata + ValueList guidance

The assistant uses the S/4 MCP to discover the Football service and inspect entity schema (search-sap-services, discover-service-entities, get-entity-schema). It then pivots to the SAP Docs MCP to sap_help_search and sap_help_get the ValueList documentation and shows exactly where to add annotations. This marries live service metadata with the official docs so consultants can implement confidently, then validate in a Fiori app.

CDS view Value Help research

For CDS‑centric cases, the assistant focuses on SAP Docs MCP to collect the canonical examples for Common.ValueList and relevant ABAP/CDS annotations. If needed, ABAP ADT MCP can retrieve the current CDS definition (GetStructure/GetInclude) to compare the as‑is state and generate the minimal edit plan.

Other options and clients

There are other options and clients to use these MCP servers. If you prefer the Microsoft ecosystem, Visual Studio Code’s GitHub Copilot Chat supports MCP servers so you can connect the same SAP MCP endpoints there, as described in the VS Code Copilot Chat MCP guide. This is a simpler setup compared to the LibreChat fork. For a more governed setup you can use Copilot Studio together with the hosted S/4 OData MCP server from Nessi NV and the SAP Docs MCP Server.

I talked about these MCP servers and showed a live example of Copilot Studio and other LLM clients at SAP Inside Track Munich 2025. The recording is here: SAP Inside Track Munich 2025.

You can also build your own LLM client and use the MCP servers directly. I tried a quick PoC with the current libraries and tools. It worked, but turning it into a production‑ready assistant with robust MCP support is non‑trivial; I would not recommend rolling your own for production. The PoC is here: Custom LLM Client.

Getting started

To run this on your own machine, clone the repository, configure the .env and librechat.yaml files and start the Docker container. The docs are in this folder and the setup guide is here: MCP_SETUP_GUIDE.md.

Minimal path (see guides for details):

# Clone and configure
git clone https://github.com/marianfoo/local-llm-client-for-sap-consultants-librechat
cd local-llm-client-for-sap-consultants-librechat
cp .env.example .env
cp librechat.example.yaml librechat.yaml

# Configure the .env and librechat.yaml files

# Start in Docker
docker compose up -d

Security: running AI and MCP locally

Because the client, MCP server and (optionally) the model run on your machine, prompts, retrieved docs and tool results stay inside your environment. When you do connect to external sources, do it intentionally and stick to trusted endpoints. Operationally keep it simple and start read-only by default and enable write tools only when you require it. The short version: a local, open-source stack is the safer option here; unlike cloud assistants, your information never leaves your machine unless you choose to send it.

Conclusion

With MCP servers, LLM clients become smarter and more useful in real projects. LLMs simply cannot know everything, especially internal context that lives on enterprise networks and changes quickly. Because the Model Context Protocol is still relatively new in the enterprise, treat adoption with care and integrate it securely. Keeping information on your own machine and using open-source libraries lets you see exactly what runs and how.

SAP clearly wants to position Joule for Consultants as a unique product; today it still lags behind community projects for these use cases. At TechEd next week we’ll see whether community MCP servers are embraced and whether SAP’s own products improve enough to justify the price.

References

Custom LLM Client PoC: https://github.com/marianfoo/custom-llm-client
SAP Inside Track Munich 2025 session: https://www.youtube.com/watch?v=vTZCeaxsOwU
SAP partner listing (S/4 integration via OAuth): https://www.sap.com/products/artificial-intelligence/partners/nessi-nv-ai-data-enabler.html?countryCode=US
MCP clients overview (Claude Desktop etc.): https://modelcontextprotocol.io/clients/
Copilot Studio: https://adoption.microsoft.com/ai-agents/copilot-studio/
VS Code Copilot Chat MCP docs: https://code.visualstudio.com/docs/copilot/chat/mcp-servers
CAP MCP server (official): https://github.com/cap-js/mcp-server
CAP MCP plugin (community): https://github.com/gavdilabs/cap-mcp-plugin
S/4 OData MCP: https://github.com/lemaiwo/btp-sap-odata-to-mcp-server
ABAP ADT MCP: https://github.com/mario-andreschak/mcp-abap-adt
SAP Notes MCP: https://github.com/marianfoo/mcp-sap-notes
SAP Docs MCP: https://github.com/marianfoo/mcp-sap-docs
LibreChat Ollama guide: https://www.librechat.ai/blog/2024-03-02_ollama#getting-started-with-ollama
LibreChat model providers: https://www.librechat.ai/docs/configuration/pre_configured_ai
LibreChat website: https://www.librechat.ai/
LibreChat fork setup guide: https://github.com/marianfoo/local-llm-client-for-sap-consultants-librechat/blob/main/sap-mcp-docs/MCP_SETUP_GUIDE.md
LibreChat fork docs folder: https://github.com/marianfoo/local-llm-client-for-sap-consultants-librechat/tree/main/sap-mcp-docs
LibreChat fork (SAP consultants, with MCP servers): https://github.com/marianfoo/local-llm-client-for-sap-consultants-librechat