Btp on Marian Zeis Blog

ARC-1 1.0: One Deployment, Multiple SAP Systems

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

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

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

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

What version 1.0 means

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

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

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

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

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

This release was built through feedback

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

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

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

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

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

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

One ARC-1 instance, multiple SAP systems

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

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

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

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

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

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

The biggest changes in short

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

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

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

Skills for complete SAP tasks

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

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

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

Extensions for your own SAP APIs

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

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

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

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

Reusing the BTP authentication stack

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

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

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

A new home for the project

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

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

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

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

Where to start

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

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

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

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

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

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

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

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

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

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

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

Thank you

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

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

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

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

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.

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.

Btp on Marian Zeis Blog

ARC-1 1.0: One Deployment, Multiple SAP Systems

What version 1.0 means

This release was built through feedback

One ARC-1 instance, multiple SAP systems

The biggest changes in short

Skills for complete SAP tasks

Extensions for your own SAP APIs

Reusing the BTP authentication stack

A new home for the project

Where to start

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

Thank you

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

Where this started

How the skill works

The sample use case in Codex

The first pass scored 100, but was wrong

How to prompt it

Where it works and where it stops

Links

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

What Carries Over From Earlier Posts

What ARC-1 Adds To Joule

The Architecture I Would Show

Use Cases I Would Show In This Post

Why I Use An Agent Here

Open Points

Why This Matters

Discuss this post

References & links

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

Why Copilot Studio fits here

The Architecture Stays The Same

Setup

SharePoint And SAP Documentation

The Real Use Cases I Tested

Use Case 1: Bug Fix From A Jira Ticket

Use Case 2: SharePoint Change Request To Impact Analysis

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

Use Case 4: Code Quality Report

Use Case 5: Short Dump Diagnosis From A Jira Ticket

Use Case 6: Clean Core Readiness Check

Why This Matters

Discuss this post

References & links

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

Why BTP

The Basic Shape

The Three Gates

Deployment Options

Configuration That Matters

Roles And Technical Users

Connecting Clients

What I Would Verify First

Where To Go Deeper

Discuss this post

References & links

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

Why ARC-1 had to exist

Central instead of local

Two auth hops matter

Safe by default, not allow all by default

Layered security, not just one switch

Per-user identity matters

Audit logging is part of the feature, not an afterthought

Not locked into one client

Testing matters more here than for normal dev tooling

So yes, this is another ADT MCP server

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

Why this matters for the next post

Discuss this post

References & links