Marian Zeis Blog

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/marianfoo/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/marianfoo/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. It does not expose transport actions unless those are 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 operation allowlists and denylists, package restrictions, and safety profiles like viewer, viewer-sql, or developer. 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, operation filters, 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 more than 1,300 unit tests, plus integration tests and E2E tests that execute real MCP tool calls against live SAP systems. 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 may also differentiate itself from the future official SAP approach depending on how that evolves. As of SAP’s November 4, 2025 announcement about the next era of ABAP development, SAP plans an official ABAP MCP server for Q2 2026 together with the ABAP language server and related SDK pieces in VS Code. I think that is good news.

Actually, that is also the point where building yet another ADT MCP server becomes harder to justify long term. If SAP publishes the language server and SDK in a reusable way, then the right move would be to reuse the same foundation that the official SAP MCP server and Eclipse tooling use instead of reimplementing more and more HTTP details on the community side.

If SAP ends up shipping a server with a similar architectural direction, broad system coverage, and the same kind of enterprise features, then there may eventually be no strong reason for ARC-1 to continue. For me that would still be a win.

The point is not that my server must win. The point is that there is clearly a gap today, the community is filling it, and competition is usually good. It helps people choose, it helps ideas spread, and ideally it also helps SAP learn from what the community already built. Until then, people can decide on their own if ARC-1 is useful for them.

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, and some practical implications still need clarification, especially 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.

This is also relevant to what SAP wrote in the discussion around the new ABAP Development Tools for VS Code. SAP described the ABAP language server as something like an “ADT SDK 2.0” and mentioned plans to release it as a standalone component after the first VS Code extension release. A standalone release could make the support boundaries clearer for community tools, CLIs, MCP servers, and other integrations. Until more detailed guidance is available, the main point is to track SAP’s policy and documentation closely and adjust implementations when specific activities are clarified as unsupported or not permitted.

Why this matters for the next post

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

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

Discuss this post

References & links

ABAP and Agentic AI: The Hidden Problem in Real Projects

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

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

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

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

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

For me this comes down to three questions:

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

I want to answer those questions in this post.

SAP development is not one thing

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

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

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

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

Why UI5 and CAP already feel much more natural

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

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

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

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

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

Why ABAP is structurally harder

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

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

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

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

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

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

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

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

The three questions matter more than the hype

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

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

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

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

Current patterns for AI assisted ABAP development

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

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

1. IDE integrated AI in Eclipse

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

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

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

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

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

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

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

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

3. ADT MCP Server

This is where things get really interesting.

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

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

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

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

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

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

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

4. Sandbox systems

In my opinion this is one of the safest options.

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

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

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

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

In many ways this is the cleanest approach.

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

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

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

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

6. Hybrid approach

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

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

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

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

For me this is one of the most promising directions.

Read access already gives a lot of value

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

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

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

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

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

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

What current setups still do not solve

So where is the actual gap today?

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

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

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

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

What an ideal setup would look like

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

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

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

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

Why this matters for the next post

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

Discuss this post

How I Use AI for Development and Why Context Matters

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

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

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

I think more about another colleague helping me out.

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

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

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

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

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

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

My workflow changed over the last year

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

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

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

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

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

Context matters more than people first think

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

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

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

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

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

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

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

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

Why I care so much about tooling around the model

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

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

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

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

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

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

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

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

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

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

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

I am still skeptical of full agentic hype

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

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

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

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

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

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

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

Process helps, but process is also overhead

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

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

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

Why this gets harder in SAP

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

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

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

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

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

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

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

Discuss this post

References & links

SAP Fiori Elements Feature Map: What Is Available in Each SAPUI5 Version

Wed, 11 Mar 2026 20:55:00 +0100

If you work with SAP Fiori Elements, you have probably run into this problem before:
it is hard to see in which UI5 version a specific feature was introduced.

Bjorn Schulz already built a strong matrix for ABAP: ABAP Feature Matrix.
For Fiori Elements and RAP/CAP, there was no comparable matrix yet.

So I created an Influence request to close this gap:
influence.sap.com/sap/ino/#idea/351729

The new Developer Portal would be a great home for a matrix like this but so far, there still is no official version.
The closest alternative is the SAP Fiori Elements Feature Map in the SAPUI5 documentation.

The challenge is that SAPUI5 docs are published per version, so you mostly see a point-in-time view.
You do not get a clear cross-version overview showing when a feature first appeared.

That is why I decided to fetch the feature map for each version and compare when a feature first appears.
The result is the feature map below, updated automatically whenever new versions are released.

You can filter by features, floorplans, and versions, and sort by the key columns.
The data is taken directly from the official feature list.

Since the feature map in the SAPUI5 documentation has not been clearly managed, there are sometimes discrepancies.
You can see this more clearly in the feature matrix markdown.

Download the data: JSON · CSV · Adoption (Markdown) · Matrix (Markdown)

SAP Fiori Elements Feature Map

Data updated: -

SAP MCP Servers: The Missing Overview

Thu, 05 Mar 2026 09:00:00 +0100

If you are searching for SAP MCP Servers (Model Context Protocol), you quickly run into the same problem:

Which SAP MCP servers exist (official and community), and what other SAP AI tooling should you know about?

That is why I like this new repo:

marianfoo/sap-ai-mcp-servers: SAP MCP Servers and SAP AI Skills list

It is a curated list of SAP MCP servers, SAP AI skills, and adjacent developer tools. The README is structured as tables so you can scan by category, compare licenses, and see what is actively maintained.

What you will find inside

Official SAP MCP servers: for example SAP Fiori, CAP, UI5, and MDK.
Community SAP MCP servers: docs, ABAP and ADT, integration, Datasphere, OData, SAP GUI, HANA.
Skills and adjacent tools: skill repos plus “helper” tooling (plugins, samples, IDE integrations) that often matters just as much as the server itself.

Why this matters for SAP AI

If you are building an AI assistant for SAP development, MCP servers are the “connectors” that let your agent reliably pull context from documentation and systems. Having a single overview makes it much easier to choose the right building blocks.

How to contribute

If you know a project that belongs there, you can add it by opening an issue using the “Add new entry” template in the repo.

If you build anything SAP plus MCP related, this is the list I would want to keep open in a browser tab.

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

Building an Enterprise-Ready SAP AI Agent with Open Source

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

There is currently a huge hype around the new MCP (Model Context Protocol) servers. I’ve built one for SAP Docs, and there are excellent community projects like the ADT API MCP Server.

These tools are fantastic for individual developers. You install them, connect them to your IDE or a local LLM, and suddenly your AI assistant knows about SAP.

Architecture overview (in one picture)

Before diving into the details, here is the high-level architecture I’m aiming for:

The idea is simple: users talk to LibreChat (the UI + orchestrator). LibreChat calls an LLM (local inside the company network, or a trusted cloud model) and enriches answers via MCP servers. Those MCP servers connect to your knowledge sources (SAP docs, your SAP system via a read-only ADT connection, and internal SharePoint) without turning this into an “AI tool with write access to prod”.

But here is the problem: For a common SAP consultant, architect, or developer in a corporate environment, this setup is often a nightmare.

Complexity: Setting up a local LLM, configuring MCP, and dealing maybe with Docker isn’t everyone’s cup of tea.
Security: This is the big one. The default ADT MCP server, for example, is powerful, it allows reading and writing to the SAP system. No security department in their right mind would allow a “random” AI tool to have write access to the entire development system without strict governance.
Governance: Companies need to know where the data is going. Is it staying in Europe? Is it training the model?

This is not mainly a “developer toy”. The biggest value is for everyone who needs to understand what is going on in an SAP system: consultants, architects, project leads, support, and developers who are new to a system.

For ABAP developers specifically, the best enterprise-ready setup today is often GitHub Copilot in ADT because Agent Mode is available and you can add ABAP-specific knowledge through my ABAP MCP Server. But this IDE setup still has a gap: it does not give a complete overview of the system and it cannot reliably retrieve additional classes, programs, and related objects on demand to build the full context for an answer. Neverthless, it is a great tool for many ABAP developers to query the system and get a complete context for an answer. As you can see in the sample workflow below, it is possible to use the MCP servers to build the full context for an answer and just copy-paste the code into Eclipse.

The Enterprise Struggle

I recently saw a discussion that perfectly illustrates this struggle. Companies are desperately searching for “Enterprise Ready” AI usage, but they are hitting walls.

Some are trying manual workarounds, such as exporting their entire codebase to SharePoint for Microsoft Copilot to index. This often involves flattening package hierarchies to bypass navigation limits and manually creating README.md or cross-reference files to provide context, all while battling hallucinations where the AI fails to find existing transactions due to indexing errors.

Then there is SAP Joule. SAP’s own AI assistant is available for consultants, but it is quite limited in what it can do. It doesn’t connect to your custom codebase, can’t search your internal SharePoint documentation, and has no way to follow references across ABAP objects the way an MCP-based agent can. It is a nice chatbot for general SAP questions, but it is far from a tool that understands your system.

This also matches the broader picture. In the DSAG Investment Report 2026, most respondents who already run AI use cases do so with non-SAP solutions, not SAP’s AI offerings.

On the other end of the spectrum, you have high-end commercial solutions like Nova Intelligence. They do exactly what you want: they read the SAP system directly, understand the context, and are enterprise-ready. But they are also really expensive.

The “Middle Ground”: A Secure, Open Source Alternative

So, is there nothing in between? Do you have to choose between a hacking-together-files-on-SharePoint workaround and a six-figure enterprise contract?

No. I want to show you that there is a “Middle Ground.”

You can build a secure, enterprise-grade setup using Open Source tools. Think of it as building your own internal “SAP Copilot” that runs entirely under your control.

This setup allows you to:

Search your SAP System (Reports, Classes, Tables)
Search SAP Documentation (Help, GitHub, SAP Community)
Use your internal SharePoint (Specs, Docs)
Keep it Secure (Read-Only access, Authentication via Entra ID)

The Stack

I used LibreChat as the UI and Orchestrator to showcase what is possible. It’s an open-source web interface that looks and feels like ChatGPT but gives full control.

Client: LibreChat (supports Entra ID, SharePoint, and MCP out of the box).
Knowledge Source 1: SAP Docs MCP Server (for public documentation).
Knowledge Source 2: ADT MCP Server (for your SAP System).
LLM: A local LLM via Ollama.

Step 1: Security First (The ADT Connection)

The biggest concern is the SAP connection. I did not want the AI to write code or change things autonomously.

The ADT MCP Server has a specific mode for this. I configured it to be Read-Only.

Furthermore, I connected it using a Technical User in SAP that has only display authorizations. This ensures that even if the AI wanted to (or was tricked to), it effectively cannot change anything in the system. It can only “look”, just like a developer using SE80 in display mode.

Step 2: The Setup

The entire setup can be containerized with Docker. This means you can run it on a secure server within your company network. No requests need to leave your intranet if you use a local model, or they only go to your trusted Azure OpenAI instance.

Here is the high-level concept:

Deploy LibreChat: Configure it with your company’s Entra ID (Azure AD). This means users log in with their standard company Microsoft accounts. No separate user management needed.
Connect SharePoint: LibreChat has native SharePoint support. Connect it to your project’s documentation libraries.
Connect MCP Servers: Add the SAP Docs and ADT MCP servers to the configuration.

Why this works better

Context is Key: Unlike the SharePoint export method, the ADT MCP server understands the structure of ABAP. If you ask about a class, it knows to look for the definition and implementation. It doesn’t rely on a flat list of text files.
Data Privacy: If you use a local model (like Llama 3) or a private Azure instance, your code never trains a public model.
User Experience: Developers get a chat interface they are used to (like ChatGPT), but it has “superpowers” to look up SAP notes and internal code.

Sample Workflow: Understanding What Is Going On in Your System

This is the day-to-day use case for consultants, architects, support, and anyone onboarding onto an SAP landscape.

The Request: Someone asks: “Tell me what BAPI_DISPUTE_CREATE is doing in my SAP system. Use SAP docs and my system source code.”

The Process: The agent uses SAP Docs MCP to understand the standard context (what the BAPI is meant to do), then uses the ADT MCP server to find the function module in the actual system, pull the source and function group, and summarize what happens step by step.

Sample Workflow: Implementing a RAP Action

Instead of just answering simple questions, the agent can plan and implement features.

The Request: A developer uploads a PDF specification and asks: “Please suggest what to change in my SAP System as specified in the Specification…”

The Process:

System Research (ADT MCP): The Agent autonomously explores the system. It executes SearchObject and GetSource to find the relevant Business Object (ZI_FOOTBALL_CLUBS), the Behavior Definition, and the Projection view.
Impact Analysis: It identifies that a new action UpdateFoundedYear is needed and lists the exact objects that need to be created or changed (BDEF, Class, Projection, Metadata).
Best Practice Lookup (SAP Docs MCP): When asked for the implementation code, the agent searches SAP Help Portal for “Non-factory action” and “Action input parameter” to ensure the code follows best practices.
Code Generation: It generates the complete ABAP implementation for the ZCL_FOOTBALL_CLUBS class, including error handling (FAILED/REPORTED) and EML statements.

This turns the agent into a true pair programmer that understands your specific system architecture.

Not Just for LibreChat and Local Models

I used LibreChat and Ollama because they are free and open source, which makes them perfect for a showcase. But the beauty of this architecture is its flexibility.

Want better models? You can swap Ollama for Azure OpenAI, Anthropic, or Mistral in seconds. LibreChat supports them out of the box. I even benchmarked different models for ABAP recently: Benchmarking LLMs for ABAP.

Want to use Microsoft Copilot? Since MCP is an open standard, you aren’t tied to LibreChat. You can host these MCP servers as simple HTTP services and connect them to other clients, including Microsoft Copilot or other agent platforms that support the protocol. The MCP servers are just “infrastructure”, the client is interchangeable.

Want more data sources? There are MCP servers for GitHub, Jira, Confluence, and many more. You can “dock” them onto your agent just like we did with the SAP Docs server.

Want to extend it? You can add more MCP servers, create custom tools, or even build your own agents with specialized knowledge. The possibilities are endless.

Conclusion

You don’t need to wait for a perfect, expensive enterprise product to start using AI securely with SAP. With Open Source tools like LibreChat and the ecosystem of MCP servers, you can build a solution that is secure, compliant, and incredibly powerful.

It requires a bit of setup (Docker, Entra ID), but the payoff is a tool that actually understands your SAP system, without compromising on security.

If you are interested in the technical details, check out my Setup Guide in the GitHub repository marianfoo/llm-client-sap-system-integration-sharepoint.

References & Resources

Setup Guide & Repository: marianfoo/llm-client-sap-system-integration-sharepoint
SAP Docs MCP Server: marianfoo/mcp-sap-docs
ABAP MCP Server (for Copilot in ADT): marianfoo/abap-mcp-server
ADT MCP Server (vibing-steampunk): oisee/vibing-steampunk
LibreChat: librechat.ai
DSAG Investment Report 2026 (AI usage): Companies are investing more selectively, AI is becoming established
Benchmarking LLMs for ABAP: My Benchmark Post
MCP Protocol: modelcontextprotocol.io

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

Extract your SAP Community blog posts with a simple Node.js script

Tue, 20 Jan 2026 06:00:00 +0100

I wanted to have a local archive of my SAP Community blog posts for my own reference and to have a better overview of my content.
Also I tried writing posts locally in Markdown first and then converting them to HTML. Mixed experience so far.
Currently this is in a private repository and it fetches the latest posts from SAP Community daily if there are any new ones.

I at least wanted to share my script so others can use it too.

As I’m currently just too lazy to create a proper repository for this, I will just share the script here.

What you need

You need Node.js 18+ (Node 22 works as well). The script uses the built-in fetch() API, so you do not need extra dependencies.

The idea

The workflow is intentionally simple and mirrors a common “ETL” pattern.

First, fetch the posts and store the raw API response as JSON.

Second, generate local HTML files (one file per post). The SAP Community API already returns the post body as HTML, so the script wraps that into a minimal HTML document and adds a few metadata fields into the <head>.

Third, scan those HTML files for <img src="..."> references and download the images. This makes the archive usable offline and helps when you want to copy content into another system later.

This also makes it possible to just open the HTML files in a browser and read the posts offline, including the pictures.

A minimal script (test mode)

Save the following file as blogpost/extract-posts-generate-html-download-images.js.

If you prefer, you can also download the script directly from this post: /downloads/extract-posts-generate-html-download-images.js

Before you run it, change USER_ID to your own SAP Community numeric user ID. For testing, the script uses LIMIT = 10, so you don’t accidentally pull thousands of posts while you are still experimenting.

Please be API-friendly: keep LIMIT small while testing, and don’t run the script in a tight loop.

Expand the section below to see the full script.

extract-posts-generate-html-download-images.js

/**
 * SAP Community: extract your posts (test mode) and archive locally.
 *
 * This single script intentionally combines three steps into one file:
 *   1) fetch posts from the SAP Community Search API
 *   2) generate local HTML files from the response (one file per post)
 *   3) download images referenced by those HTML files
 *
 * Why keep it in one file?
 * - It’s easier to explain in a short blog post.
 * - Readers can copy/paste one script, change USER_ID, run it, and inspect output.
 *
 * IMPORTANT:
 * - This is a "demo/testing" version. The query uses LIMIT 10 on purpose.
 * - The SAP Community API can be rate-limited. Keep limits small while experimenting.
 *
 * Requirements:
 * - Node.js 18+ (Node 22 also works). This script relies on the built-in global fetch().
 *
 * Usage:
 *   node blogpost/extract-posts-generate-html-download-images.js
 *
 * Output folders created inside blogpost/:
 * - blogpost/output/user_<USER_ID>_messages_limit10.json   (raw API response)
 * - blogpost/posts/                                       (generated HTML posts)
 * - blogpost/images/<postId>/                             (downloaded images)
 */

const fs = require('fs');
const fsp = require('fs').promises;
const path = require('path');
const https = require('https');
const http = require('http');
const crypto = require('crypto');

// --- Configuration (change these for your own account) -----------------------

// Your SAP Community numeric user id (not your username).
// In Marian’s repo this is 61; replace with your own.
const USER_ID = 61;

// Keep this small while testing. For a real archive you’d increase it.
// If you hit server-side errors (e.g., HTTP 413), you’ll need batching.
const LIMIT = 10;

// SAP Community Search API endpoint used by this repo.
const API_BASE_URL = 'https://community.sap.com/api/2.0/search';

// Small delay between image downloads (be respectful).
const IMAGE_DOWNLOAD_DELAY_MS = 200;

// --- Paths (everything is local to this folder to keep it self-contained) ----

const ROOT_DIR = __dirname; // blogpost/
const OUTPUT_DIR = path.join(ROOT_DIR, 'output');
const POSTS_DIR = path.join(ROOT_DIR, 'posts');
const IMAGES_DIR = path.join(ROOT_DIR, 'images');

// --- Step 1: Fetch posts -----------------------------------------------------

/**
 * Fetch top-level posts for a user and store the raw response as JSON.
 *
 * Why store the raw response?
 * - It’s your "source of truth" archive.
 * - It makes debugging easier: you can inspect what the API returned.
 * - It decouples fetching from the downstream steps (HTML generation, downloads).
 */
async function fetchPostsAsJson({ userId, limit }) {
  await fsp.mkdir(OUTPUT_DIR, { recursive: true });

  // depth=0 = top-level posts (not replies/comments)
  // Keep selected fields small to reduce payload; body is still the largest part.
  // For a larger export, consider fetching IDs first, then bodies in batches (IN (...)).
  const query = `select id,subject,post_time,depth,body from messages where author.id='${userId}' and depth=0 order by post_time desc limit ${limit}`;
  const url = `${API_BASE_URL}?q=${encodeURIComponent(query)}`;

  console.log(`\n[1/3] Fetching posts from SAP Community API...`);
  console.log(`      USER_ID=${userId}, LIMIT=${limit}`);
  console.log(`      Query: ${query}`);

  const response = await fetch(url);
  if (!response.ok) {
    const body = await response.text().catch(() => '');
    throw new Error(`API request failed: HTTP ${response.status}\n${body}`);
  }

  const json = await response.json();
  const items = json?.data?.items ?? [];

  const outFile = path.join(OUTPUT_DIR, `user_${userId}_messages_limit${limit}.json`);
  await fsp.writeFile(outFile, JSON.stringify(json, null, 2), 'utf8');

  console.log(`      Saved raw response to: ${outFile}`);
  console.log(`      Posts returned: ${items.length}`);

  return { outFile, items };
}

// --- Step 2: Generate HTML files --------------------------------------------

/**
 * Generate one HTML file per post.
 *
 * Why generate HTML at all?
 * - It’s the easiest format to open in any browser.
 * - It enables simple image extraction by scanning <img src="..."> tags.
 *
 * Note:
 * - SAP Community post bodies already contain HTML. We keep it as-is and wrap it
 *   into a minimal HTML document with metadata in <head>.
 */
async function generateHtmlFiles({ posts }) {
  await fsp.mkdir(POSTS_DIR, { recursive: true });

  console.log(`\n[2/3] Generating local HTML files...`);

  let written = 0;
  for (const post of posts) {
    if (!post?.id || !post?.body) continue;

    const postDate = safeDate(post.post_time);
    const dateStr = postDate ? postDate.toISOString().slice(0, 10) : 'unknown-date';

    const cleanSubject = safeSlug(post.subject || 'sap-community-post').slice(0, 40);
    const filename = `${dateStr}-${post.id}-${cleanSubject}.html`;
    const filepath = path.join(POSTS_DIR, filename);

    const html = buildHtmlDocument({
      title: post.subject || 'SAP Community Post',
      meta: {
        'post-id': String(post.id),
        'author-id': String(USER_ID),
        'post-time': post.post_time || '',
        depth: String(post.depth ?? ''),
        subject: post.subject || '',
      },
      bodyHtml: post.body,
    });

    await fsp.writeFile(filepath, html, 'utf8');
    written++;
    console.log(`      Wrote: ${filename}`);
  }

  console.log(`      HTML files written: ${written}`);
  console.log(`      Output folder: ${POSTS_DIR}`);
}

function buildHtmlDocument({ title, meta, bodyHtml }) {
  const escapeAttr = (s) => String(s).replace(/"/g, '&quot;');
  const metaTags = Object.entries(meta || {})
    .map(([k, v]) => `    <meta name="${escapeAttr(k)}" content="${escapeAttr(v)}">`)
    .join('\n');

  return `<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>${escapeAttr(title)}</title>
${metaTags}
</head>
<body>
${bodyHtml}
</body>
</html>
`;
}

function safeDate(value) {
  const d = new Date(value);
  // NaN check: invalid date produces NaN time
  return Number.isFinite(d.getTime()) ? d : null;
}

function safeSlug(value) {
  return String(value)
    .replace(/^Re:\s*/i, '')
    .replace(/[<>:"/\\|?*]/g, '') // invalid filename characters
    .trim()
    .replace(/\s+/g, '-')
    .toLowerCase();
}

// --- Step 3: Download images -------------------------------------------------

/**
 * Scan each generated HTML file for <img src="..."> and download the images.
 *
 * Why download images?
 * - When you archive HTML locally, images often point to remote URLs.
 * - A local copy is useful for offline reading and for further processing.
 *
 * Notes:
 * - This is a lightweight HTML scan using regex (good enough for a blog post).
 * - Some posts may use SAP Community-specific tags or lazy-loading patterns.
 *   If an image is missed, you can refine the regex or parse with a DOM library.
 */
async function downloadImagesFromGeneratedHtml() {
  await fsp.mkdir(IMAGES_DIR, { recursive: true });

  console.log(`\n[3/3] Downloading images referenced by the generated HTML...`);

  const files = await fsp.readdir(POSTS_DIR).catch(() => []);
  const htmlFiles = files.filter((f) => f.endsWith('.html'));

  if (htmlFiles.length === 0) {
    console.log(`      No HTML files found in ${POSTS_DIR} (skipping image download).`);
    return;
  }

  let totalFound = 0;
  let downloaded = 0;
  let skipped = 0;

  for (const htmlFile of htmlFiles) {
    // Filename format: YYYY-MM-DD-ID-subject.html
    const match = htmlFile.match(/^\d{4}-\d{2}-\d{2}-(\d+)-/);
    const postId = match?.[1] || 'unknown-post';

    const htmlPath = path.join(POSTS_DIR, htmlFile);
    const html = await fsp.readFile(htmlPath, 'utf8');

    const imageUrls = extractImgSrcUrls(html);
    if (imageUrls.length === 0) continue;

    totalFound += imageUrls.length;

    const postDir = path.join(IMAGES_DIR, postId);
    await fsp.mkdir(postDir, { recursive: true });

    console.log(`      ${htmlFile}: found ${imageUrls.length} <img> URLs`);

    for (const imageUrl of imageUrls) {
      try {
        const filename = chooseImageFilename(imageUrl);
        const fullPath = path.join(postDir, filename);

        if (await exists(fullPath)) {
          skipped++;
          continue;
        }

        await downloadToFile(imageUrl, fullPath);
        downloaded++;

        // Be polite to the server.
        await sleep(IMAGE_DOWNLOAD_DELAY_MS);
      } catch (e) {
        // For a blog post, it’s fine to keep going on individual failures.
        console.log(`        Failed: ${imageUrl} (${e.message})`);
      }
    }
  }

  console.log(`\n      Image download summary:`);
  console.log(`      - <img> URLs found: ${totalFound}`);
  console.log(`      - downloaded: ${downloaded}`);
  console.log(`      - skipped (already present): ${skipped}`);
  console.log(`      Images folder: ${IMAGES_DIR}`);
}

function extractImgSrcUrls(html) {
  // Matches: <img ... src="..." ...> and <IMG ... SRC='...' ...>
  const imageRegex = /<img[^>]*\ssrc\s*=\s*["']([^"']+)["'][^>]*>/gi;
  const matches = [...html.matchAll(imageRegex)];
  return matches.map((m) => m[1]).filter(Boolean);
}

function chooseImageFilename(url) {
  // Try to keep recognizable filenames for SAP Community images, else create a stable hash.
  // SAP Community often uses URLs like: .../image-id/<id>/...
  const idMatch = String(url).match(/image-id\/([^\/?#]+)/i);
  if (idMatch?.[1]) return `${idMatch[1]}.jpg`;

  try {
    const u = new URL(url);
    const base = path.basename(u.pathname).split('?')[0];
    if (base && base.includes('.')) return base;
  } catch {
    // Not a valid absolute URL, fall through to hash.
  }

  const hash = crypto.createHash('sha1').update(String(url)).digest('hex').slice(0, 12);
  return `image_${hash}.jpg`;
}

async function downloadToFile(url, filepath) {
  // Use the URL protocol to decide between https/http.
  const protocol = String(url).startsWith('https:') ? https : http;

  await new Promise((resolve, reject) => {
    const req = protocol.get(url, (res) => {
      // Follow basic redirects.
      if (res.statusCode === 301 || res.statusCode === 302) {
        const next = res.headers.location;
        if (!next) return reject(new Error(`Redirect without location header: ${url}`));
        res.resume();
        return downloadToFile(next, filepath).then(resolve).catch(reject);
      }

      if (res.statusCode !== 200) {
        res.resume();
        return reject(new Error(`HTTP ${res.statusCode}`));
      }

      const out = fs.createWriteStream(filepath);
      res.pipe(out);
      out.on('finish', () => out.close(resolve));
      out.on('error', reject);
    });

    req.on('error', reject);
    req.setTimeout(30000, () => {
      req.destroy();
      reject(new Error('Download timeout'));
    });
  });
}

async function exists(p) {
  try {
    await fsp.access(p);
    return true;
  } catch {
    return false;
  }
}

function sleep(ms) {
  return new Promise((r) => setTimeout(r, ms));
}

// --- Main pipeline -----------------------------------------------------------

async function main() {
  // Step 1: Fetch
  const { items } = await fetchPostsAsJson({ userId: USER_ID, limit: LIMIT });

  // Step 2: Generate HTML
  await generateHtmlFiles({ posts: items });

  // Step 3: Download images
  await downloadImagesFromGeneratedHtml();

  console.log(`\nDone.`);
  console.log(`You can now inspect:`);
  console.log(`- Raw JSON: ${OUTPUT_DIR}`);
  console.log(`- HTML posts: ${POSTS_DIR}`);
  console.log(`- Images: ${IMAGES_DIR}`);
}

main().catch((e) => {
  console.error(`\nScript failed: ${e.message}`);
  process.exitCode = 1;
});

Run it with:

node blogpost/extract-posts-generate-html-download-images.js

After it finishes, you’ll find three folders under blogpost/: output/ for the raw JSON, posts/ for the generated HTML files, and images/ for downloaded images grouped by post ID.

Example resulting folder structure

If you have a repo like sap-community-blog-posts and put the script into a blogpost/ folder, it can look like this afterwards:

/sap-community-blog-posts/
└── blogpost/
    ├── extract-posts-generate-html-download-images.js
    ├── output/
    │   └── user_61_messages_limit10.json
    ├── posts/
    │   ├── 2026-02-19-1234567-my-first-post.html
    │   ├── 2026-02-10-1234500-another-post.html
    │   └── 2026-01-05-1234000-some-topic.html
    └── images/
        ├── 1234567/
        │   ├── 4c2f1f6e-aaaa-bbbb-cccc-1234567890ab.jpg
        │   └── image_6f2c0a1b3d4e.jpg
        └── 1234500/
            └── image_1a2b3c4d5e6f.jpg

Notes and limitations

The script queries depth = 0 to fetch only top-level posts, not comments or replies. It also does not limit to blog posts, so you will get other types of posts as well (Q&A, etc.).

Distributed Microservices with GitHub Pages and RSS Feeds

Mon, 19 Jan 2026 10:00:00 +0100

I was recently asked how my UI5 Versions Bot on Bluesky works. So I want to simply explain how it works and how I use an RSS feed as a small “microservice” so I can base other services on this data.

How the ui5-lib-diff project works

The ui5-lib-diff project pulls data from official UI5 sources (SAPUI5/OpenUI5) and turns it into structured change data. That data is then used to generate an RSS feed entry for each patch update in both SAPUI5 and OpenUI5.

It runs a small GitHub workflow that runs every two hours, fetches library data and change logs, parses and consolidates the results, and then creates the RSS XML files (rss_feed_SAPUI5.xml, rss_feed_OpenUI5.xml). A scheduled GitHub Actions workflow builds the UI5 app and publishes everything to the docs branch so it can be served via GitHub Pages. There’s also a static page at https://ui5-lib-diff.marianzeis.de/ for browsing without using the RSS feeds and for creating diffs between versions.

So basically this is a small “microservice” that fetches data from the official UI5 sources and publishes it to an RSS feed. Now I’m able to use this data in other services — for example, in a Bluesky bot.

I also created a GitHub repo for multiple Bluesky bots (like a UI5 Version Bot and an SCN Bot): https://github.com/marianfoo/bluesky-bots/tree/main/packages/blueskybotui5version

How the Bluesky UI5 version bot works

The Bluesky bot (see packages/blueskybotui5version) is an example consumer of the RSS “microservice”.

Instead of scraping webpages, it periodically fetches the two RSS feeds from the UI5 microservice:

For each RSS item (for example “Version 1.143.0 Changes”), it extracts the version number and checks if it already posted about it. The bot persists that state in a local posted_versions.json file so it won’t repost the same version after a restart.

When it finds a new version, it creates a Bluesky post that links back to the “What’s new” comparison on https://ui5-lib-diff.marianzeis.de/ and also adds the corresponding documentation link (SAPUI5: https://ui5.sap.com/<version>/#/, OpenUI5: https://sdk.openui5.org/<version>/#/). The bot uses the official version.json endpoints to determine the previous available version for comparisons, and it rate-limits posting to avoid spamming.

The bot itself does not run on GitHub but on my own private Hetzner server.

So RSS feeds are a great way to create a microservice that can be used by other services. To be fair, the kind of data you can put in an RSS feed is pretty limited but it’s perfectly valid for my use case.

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

Engagement in Free-Fall: Why SAP Community Blogs Struggle to Be Seen

Tue, 13 May 2025 09:30:00 +0200

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.

Back in April 2024 I opened this little series with From Open Exchange to Corporate Monologue, followed in August by SAP Community in Decline and, just before Christmas, the GPT-assisted look at question quality.

Twelve months, two platform releases and several batch-downloads later it is time for round four - this time with a split focus:

Who is writing the blog posts today?
Does anybody still read them?

“Nothing has changed” was my gut feeling - and the long-range chart confirms it. Since the second half of 2023 the SAP share hovers stubbornly between 60% and 70%; no new record highs, but also no real retreat.

Share and absolute numbers of all blog posts, 2003-05 to 2025-05

Does the plateau invalidate my earlier alarm?

Not really. The community never bounced back to the sub-40% employee share we enjoyed a decade ago - the status-quo is simply frozen at a two-thirds “corporate voice”.

Assumption check: My earlier claim of “no further change” holds for percentages, but the green bars (absolute SAP posts) are still inching up. The non-SAP bars are mostly flat. So the balance only stays constant because both lines move in parallel.

2 | Tech-Blog Boards - A Very Different Story

Drill down to the two technology boards (technology-blog-sap, technology-blog-members) and you get a much livelier picture.

Figure 2 - Share and absolute numbers in the tech blogs, entire history

Figure 3 - Same data, last 12 months

Key observations:

Member posts are growing - up by ~25% year-on-year.
SAP posts are shrinking - down by ~15% in the same period (especially 2025-01 to 2025-03).

Assumption: The main reason for this change is the lower number of SAP blog posts. One possible explanation is that the personal target number of blog posts required to achieve a possible bonus has been reached. This also explains the high number of SAP blog posts in December.

There was also an increase in blog posts from non-SAP members and new members of the SAP community (see next point).

3 | Who Are Those Members? - Rank Distribution

Figure 4 - Experienced vs. inexperienced share in the tech blogs, last 12 months

The green bars (Participant+) show a drop to barely 40% in February before recovering to the mid-40s. Net-net the fresh content boom is fuelled primarily by new contributors.

Additional assumption: A steady inflow of first-time authors is great - if their pieces are curated and converted into repeat contributions. Otherwise we risk a “drive-by blogging” pattern that never matures (see next point about views).

4 | Views - The Elephant in the Room

When SAP switched the platform to Khoros I planned to ignore the view counter - until the time-series smacked me in the face:

Figure 5 - Mean and median views and engagement quality

The trajectory is crystal-clear:

Sharp decline since 2020, long before the migration.
Mean > median: a few viral posts keep the average alive; the typical post is doing much worse.

Are the counters reliable?

I have already written that I do not consider the view parameters to be reliable. However, I cannot ignore this chart because the trend is quite clear. I trust the trend because it reflects my personal feeling.

I strongly suspect that the curve is not so extreme in real numbers, but only SAP itself can answer this question with its own analytics data.

But if you look at the number of posts here, there is no downward trend. This confirms my impression that a lot of blog posts are written by non-SAP members and that SAP employees are encouraged to write blog posts.

This combination automatically leads to a decline in quality and therefore in engagement, which confirms my impression that blog posts that are really worth reading are becoming rarer.

6 | What Could SAP (and We) Do?

This is a difficult question to answer because there is no simple answer. Platform migration is only part of the answer, because engagement was already declining before that, but it definitely plays a big role.

If you look at the latest ‘What’s New’ post from the SAP community, the bug fixes are ones that shouldn’t have been there in the first place and are just minor cosmetic changes. It doesn’t change the big picture. And now, years after the migration, I don’t see any quick changes and we have to deal with the current situation.

As a community, there’s nothing we can do about it, because you can’t build a community of this size overnight. There are legal requirements that can’t be met with a small team.

Björn Schulz is doing a great job with his website and excellent content: https://software-heroes.com/

As Twitter is dying and Bluesky can’t take its place, the only alternative so far is (unfortunately) LinkedIn. There’s a lot of (at best) bad content there, but also a lot of untruths, and it’s also flooded with AI content.

At the moment, my optimism about the SAP community has faded a bit. If anyone has any suggestions on how to reunite the community, I’m all ears!

Has the Quality of SAP Community Questions Gotten Worse? A Data-Driven Perspective

Wed, 18 Dec 2024 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.

The SAP Community is and will remain the central point of entry for all issues and discussions relating to SAP.

Over the past few years (and since the migration at the beginning of the year) I have had a feeling that the quality of questions in the technology area (the area I follow most closely) has gradually declined.

I wanted to see if I could somehow verify or disprove this feeling.

This blog post describes my approach and the results.

Methodology

The analysis was based on historical question data, including:

Question metadata (timestamps, authors, conversation details)
Quality scores (rated by GPT-4o, ranging from 1 to 10)
Additional metrics, such as the number of messages per conversation and whether the question was solved

Since the prices for tokens at OpenAI have fallen, I have simply decided to analyse the questions from the last six years in the technology section with an LLM.

To do this, I downloaded all the questions and packed them into a prompt that looks like this:

You are an expert who will rate the quality of a question from an online forum. The quality of a question depends on:
- How well the user describes the problem
- How much contextual detail is given
- How well-formatted the question is (images, code formatting, clarity)
- Length (but not too long just for fluff)
- Overall clarity

Please return a single integer between 0 and 10 (no text, no explanation), where 10 means it's an extremely well-asked, clear question with all necessary details, and 0 means it's very poor, unclear, and low quality.

Thanks to the Batch API from OpenAI, we got another 50% discount for the prompt and paid $6.82 for the analysis of approximately 200,000 questions.

Data was processed using Python, and visualizations were created using Matplotlib and Seaborn.

Key Findings

1. Monthly Quality Scores: Trends Over Time

The chart shows a notable dip in average quality around 2018-2019, followed by a gradual recovery. Interestingly, the quality scores have stabilized since 2020, with improvements starting end of 2023.

Insight: The dip could coincide with community policy changes, increased user activity, or other external factors. A deeper look into this period might reveal actionable insights.

2. Monthly Question Volume

The number of questions peaked between 2019 and 2021, followed by a steady decline. The recent decline might reflect a shift in community activity or a move to alternative platforms for technical discussions.

Insight: High activity in earlier years might have diluted quality, as seen in the overlapping periods of low scores and high question counts.

3. Quality Score Heatmap

The heatmap visualizes average quality scores by year and month. It confirms the dip in 2018 and highlights gradual improvements over time. Notably, 2024 have seen some of the highest average scores.

Insight: Certain months, such as mid-2018, had consistently lower scores. Investigating these periods could help address specific quality issues.

4. Messages in Conversations vs. Quality

The scatterplot shows no strong correlation between the number of messages in a conversation and the question’s quality score. However, higher-quality questions tend to lead to slightly longer discussions.

Insight: High-quality questions often attract deeper engagement, which benefits the community overall.

5. Combined Trends: Questions and Quality

Overlaying question volume and quality scores highlights the inverse relationship: as the number of questions surged, quality declined. This pattern reversed as activity decreased.

Insight: Moderating activity levels and encouraging thoughtful participation could help sustain or improve quality.

Conclusions

What the Data Tells Us

I can’t explain the dip in 2018 to myself, and I don’t have the time to investigate it further.

But at least the LLM rates that the quality has not dropped. That means there have always been very good and very bad questions. The average of the questions was always the same.

According to the LLM, the quality in 2024 even increased while the number of questions decreased, which did not feel like my experience.

What do you think about these insights? Are there specific periods or trends that resonate with your experience in the SAP Community?

More stats

Here is a snippet of the data results:

https://gist.githubusercontent.com/marianfoo/9512f43ec4c536189906d35e6e023605/raw/c1a4ed715f7c56b348f0915820b7e5a4cffecebd/gistfile1.txt

Quality Score Distribution:

quality_score
1.0        42
2.0      2661
3.0     11843
4.0     37171
5.0     34140
6.0     54559
7.0     45242
8.0     30511
9.0      1278
10.0        2

Here are the two 10 rated questions:

Monthly Statistics (all months):

 mean    std  min  max  count
year_month                               
2018-01     5.758  1.468  1.0  9.0   1430
2018-02     5.789  1.513  1.0  8.0    696
2018-03     5.866  1.431  2.0  9.0    666
2018-04     5.231  1.549  2.0  9.0    571
2018-05     5.287  1.478  2.0  8.0    550
2018-06     5.293  1.423  2.0  9.0    752
2018-07     5.221  1.441  2.0  8.0   1948
2018-08     5.325  1.512  2.0  9.0   1802
2018-09     5.301  1.507  2.0  9.0   1738
2018-10     5.262  1.483  2.0  9.0   1971
2018-11     5.659  1.495  2.0  9.0   1884
2018-12     5.761  1.489  2.0  9.0   1437
2019-01     5.731  1.465  2.0  9.0   1888
2019-02     5.821  1.473  2.0  9.0   1773
2019-03     5.754  1.433  2.0  9.0   3024
2019-04     5.794  1.475  2.0  9.0   3599
2019-05     5.781  1.492  2.0  9.0   3558
2019-06     5.746  1.453  2.0  9.0   3451
2019-07     5.860  1.462  2.0  9.0   3579
2019-08     5.803  1.468  1.0  9.0   3460
2019-09     5.760  1.500  2.0  9.0   3423
2019-10     5.725  1.481  2.0  9.0   3660
2019-11     5.777  1.492  1.0  9.0   3461
2019-12     5.755  1.523  1.0  9.0   2946
2020-01     5.773  1.497  2.0  9.0   3814
2020-02     5.669  1.514  2.0  9.0   3732
2020-03     5.830  1.495  2.0  9.0   3579
2020-04     5.823  1.470  2.0  9.0   3972
2020-05     5.822  1.474  2.0  9.0   3855
2020-06     5.770  1.430  2.0  9.0   4121
2020-07     5.816  1.459  2.0  9.0   4208
2020-08     5.761  1.494  2.0  9.0   3540
2020-09     5.775  1.479  2.0  9.0   3894
2020-10     5.843  1.489  2.0  9.0   3519
2020-11     5.858  1.495  2.0  9.0   3286
2020-12     5.746  1.513  1.0  9.0   3097
2021-01     5.866  1.515  1.0  9.0   3429
2021-02     5.872  1.514  2.0  9.0   3657
2021-03     5.849  1.492  2.0  9.0   3934
2021-04     5.953  1.513  1.0  9.0   3422
2021-05     5.798  1.544  2.0  9.0   3338
2021-06     5.801  1.535  2.0  9.0   3695
2021-07     5.855  1.544  1.0  9.0         3320
2021-08     5.838  1.514  2.0  9.0         3215
2021-09     5.879  1.518  2.0  9.0         3082
2021-10     5.805  1.492  2.0  9.0         3004
2021-11     5.802  1.510  2.0  9.0         2908
2021-12     5.800  1.536  2.0  9.0         2737
2022-01     5.827  1.479  1.0  9.0         3170
2022-02     5.913  1.485  2.0  9.0         3063
2022-03     5.875  1.494  2.0  9.0         3373
2022-04     5.766  1.534  2.0  9.0         3022
2022-05     5.757  1.511  2.0  9.0         3094
2022-06     5.816  1.503  2.0  9.0         3284
2022-07     5.715  1.560  2.0  9.0         2842
2022-08     5.800  1.510  2.0  9.0         3013
2022-09     5.859  1.507  2.0  9.0         3124
2022-10     5.765  1.566  1.0  9.0         3096
2022-11     5.937  1.498  1.0  9.0         3320
2022-12     5.748  1.571  1.0  9.0         2484
2023-01     5.851  1.543  2.0  9.0         3080
2023-02     5.728  1.579  1.0  9.0         3447
2023-03     5.707  1.558  1.0  9.0         3546
2023-04     5.761  1.594  2.0  9.0         2874
2023-05     5.719  1.530  2.0  9.0         2985
2023-06     5.772  1.575  1.0  9.0         1642
2023-07     5.846  1.585  2.0  9.0         1711
2023-08     5.763  1.566  1.0  9.0         1805
2023-09     5.813  1.560  1.0  9.0         1529
2023-10     5.894  1.564  2.0  9.0         1523
2023-11     5.871  1.576  1.0  9.0         1624
2023-12     5.871  1.534  2.0  9.0         1237
2024-01     5.910  1.502  1.0   9.0    964
2024-02     5.877  1.627  2.0   9.0   1448
2024-03     5.887  1.644  1.0   9.0   2409
2024-04     5.986  1.589  2.0   9.0   2035
2024-05     6.088  1.595  1.0  10.0   1144
2024-06     6.097  1.572  1.0   9.0   1096
2024-07     5.961  1.693  2.0   9.0   1241
2024-08     6.137  1.595  1.0  10.0   1227
2024-09     6.090  1.639  2.0   9.0   1305
2024-10     6.077  1.587  1.0   9.0   1283
2024-11     6.092  1.624  2.0   9.0   1148
2024-12     6.097  1.719  2.0   9.0    636

SAP Community in Decline: Engagement Continues to Fall with Little Investment

Mon, 05 Aug 2024 09:30:00 +0200

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.

Half a year after the major migration, it’s time to publish the latest figures and uncover any hidden insights in the data.

So, what’s new? The trend from the past few months (or even years) has continued. More significant members of the community are moving away from Twitter, which was once a vital medium of exchange (and where I got my start).

Even on the SAP Community site, good posts from non-SAP employees are rare. I wanted to link to a good blog post, but since they are not sorted by publication date, I couldn’t find it. However, there are quite a few LLM-generated posts: The Future of Application Lifecycle Management in SAP After 2027

Meanwhile, some community members are trying to bridge the gap by offering their own search: Software Heroes - SAP Technology Blog It’s disappointing that SAP hasn’t addressed this issue after six months.

After six months, there’s an update with some fixes, but the results are underwhelming: Update about Enhancements to SAP Community

Views are displayed again for blog posts (though their accuracy is questionable), replies are automatically expanded, notifications have slightly more information, you can see if you’ve created a post or question, and a rotating carousel has been added to the homepage. These are the highlights of the update after six months.

SAP has clearly invested neither time nor money into the main page of the SAP Community to retain and attract users. This will have consequences that will be evident in the following evaluations.

Here is the update of the latest major graphic. The absolute number of blog posts in green (SAP) and red (non-SAP) and the percentage in blue (SAP) and yellow (non-SAP).

Blog Posts

Share in percent and absolute of SAP and Non-SAP Blog Post over time

For better representation, here is the development over the last twelve months. Both metrics are moving in the wrong direction. The number of blog posts is falling, mainly due to the decline in non-SAP blog posts, which automatically increases the share of SAP blog posts to 70%.

Share in percent and absolute of SAP and Non-SAP Blog Post over the last 12 months

Question and Answers

In addition to blog posts, the exchange of questions and answers is crucial. This is where community members help each other, and unfortunately, SAP has been too inactive here in recent years. On the other hand, many individuals have contributed significantly and well. It is not surprising that the same trend observed with blog posts is occurring here.

Here is a look at the entire timeline of the last few years in the Q&A section. Overall, there is an increase that has remained steady, with SAP making a very small contribution. As above, the chart shows the absolute figures in green (SAP) and red (non-SAP) and the relative figures as a percentage in blue (SAP) and yellow (non-SAP).

Share in percent and absolute of SAP and Non-SAP Q&A Post over time

It gets more interesting when you look at the last seven years. The greater participation of SAP employees in the discourse is encouraging, as seen from the large absolute figures and the increasing relative share. However, it is clear that there has been a drop from around 4,000 posts per month to around 2,500 posts per month in 2024.

Share in percent and absolute of SAP and Non-SAP Q&A Post over the last 12 months

I suspected such a decline, but I didn’t expect it to be so sharp. Personally, I haven’t answered any questions since the migration because I haven’t found a good way to filter and sort as I could with the old platform.

User Activity

Fortunately, there is also a way to read user activity. While this is just a snapshot and not a development, it still provides good insight. As always, the figures should be taken with a pinch of salt, but they still provide an insight into user activity.

Graphic Metric for User Participation

Logins: Two SAP employees have never logged in. 60% of users have never logged in.

Minutes Online: 75% of users have no minutes online. This metric likely came later, hence the discrepancy.

Posts: 70% of users have never made a post (including Q&A, blog posts, etc.). It’s amazing that 30% of users have written a post, totaling over 236,000.

Private Messages: Interestingly, this statistic still exists. It’s not surprising that only 2,723 users (0.32% of total users) use this feature.

Full data is at the end of the post

Views

Since the last update, views on blog posts are displayed again. I did a small sample to see how reliable these views are. Here is a small overview of the results: Total number of views:

10.04.2024: 2,615,955,557

03.06.2024: 3,318,366,233

02.08.2024: 4,062,134,925

That’s a sharp increase in just four months. Let’s see how the views of blog posts behave. One post that gained the most views is this one: List of Object Types SAP Business One.

It received 480,408 views within two months. While it’s an important post with a good overview, that’s much more than the second post with the most views gained: ABAP 7.40 Quick Reference

This one gained 47,892 views in the same time. How can this be explained? I suspect an automatic fetch. But why repeatedly, when the post does not change as seen in the history: Post History

Or why does this question have more than 5 million views? SAP Crystal Reports Developer Version for Microsoft Visual Studio Updates

I wouldn’t put much faith in these view numbers, even though most of them are probably correct, use them as a reference point.

Conclusion

Now what? What I observe is the widespread use of LinkedIn articles (which I use a lot too). I often shared SAP Community blog posts on LinkedIn and received more feedback there. Why not write directly on LinkedIn, also because the UX is very good? Social media diversification is definitely progressing, and the SAP Community page should actually be the bedrock.

For me personally, the exchange on Twitter is still the most important, as there are still many active people, including SAP employees. LinkedIn is more important for a broader exchange, even if gems are rarer, but the audience is definitely larger. After that, there’s a long gap, and then Mastodon, unfortunately.

I don’t see any increased investment from SAP for the SAP Community page. This is why it is increasingly becoming a marketing tool for SAP in terms of blog posts and is being used less and less.

In which direction do you see the SAP community heading? Where will the discourse take place? Could something be done for the community?

You can comment your reason why are you not using the SAP Community site anymore? Is it the lack of content? The missing functions? Universal ID?

Here is the full data of user metrics:

Statistics for metrics_logins:
  Overall:
    Average: 6.35
    Total: 5,156,904.00
  Sap_employees:
    Average: 21.25
    Total: 678,326.00
  Non_sap_employees:
    Average: 5.74
    Total: 4,478,578.00

Statistics for metrics_minutes_online:
  Overall:
    Average: 124.68
    Total: 101,224,309.00
  Sap_employees:
    Average: 875.17
    Total: 27,930,276.00
  Non_sap_employees:
    Average: 93.97
    Total: 73,294,033.00

Statistics for metrics_posts:
  Overall:
    Average: 7.07
    Total: 5,743,538.00
  Sap_employees:
    Average: 22.22
    Total: 709,070.00
  Non_sap_employees:
    Average: 6.45
    Total: 5,034,468.00

Statistics for metrics_private_messages_received:
  Overall:
    Average: 0.03
    Total: 22,019.00
  Sap_employees:
    Average: 0.15
    Total: 4,685.00
  Non_sap_employees:
    Average: 0.02
    Total: 17,334.00

Statistics for metrics_private_messages_sent:
  Overall:
    Average: 0.01
    Total: 6,533.00
  Sap_employees:
    Average: 0.06
    Total: 1,785.00
  Non_sap_employees:
    Average: 0.01
    Total: 4,748.00

Statistics for metrics_page_views:
  Overall:
    Average: 14.54
    Total: 11,801,736.00
  Sap_employees:
    Average: 81.73
    Total: 2,608,425.00
  Non_sap_employees:
    Average: 11.79
    Total: 9,193,311.00

Additional statistics for metrics_logins:
  Total users: 811,878
  Users with metrics_logins == 0:
    Overall: 486,940
    SAP Employees: 2 (0.00%)
    Non-SAP Employees: 486,938 (59.98%)
  Users with metrics_logins > 0:
    Overall: 324,938
    SAP Employees: 31,912 (3.93%)
    Non-SAP Employees: 293,026 (36.09%)

Additional statistics for metrics_minutes_online:
  Total users: 811,878
  Users with metrics_minutes_online == 0:
    Overall: 619,061
    SAP Employees: 7,700 (0.95%)
    Non-SAP Employees: 611,361 (75.30%)
  Users with metrics_minutes_online > 0:
    Overall: 192,817
    SAP Employees: 24,214 (2.98%)
    Non-SAP Employees: 168,603 (20.77%)

Additional statistics for metrics_posts:
  Total users: 811,878
  Users with metrics_posts == 0:
    Overall: 574,782
    SAP Employees: 17,342 (2.14%)
    Non-SAP Employees: 557,440 (68.66%)
  Users with metrics_posts > 0:
    Overall: 237,096
    SAP Employees: 14,572 (1.79%)
    Non-SAP Employees: 222,524 (27.41%)

Additional statistics for metrics_private_messages_received:
  Total users: 811,878
  Users with metrics_private_messages_received == 0:
    Overall: 810,309
    SAP Employees: 31,608 (3.89%)
    Non-SAP Employees: 778,701 (95.91%)
  Users with metrics_private_messages_received > 0:
    Overall: 1,569
    SAP Employees: 306 (0.04%)
    Non-SAP Employees: 1,263 (0.16%)

Additional statistics for metrics_private_messages_sent:
  Total users: 811,878
  Users with metrics_private_messages_sent == 0:
    Overall: 809,155
    SAP Employees: 31,481 (3.88%)
    Non-SAP Employees: 777,674 (95.79%)
  Users with metrics_private_messages_sent > 0:
    Overall: 2,723
    SAP Employees: 433 (0.05%)
    Non-SAP Employees: 2,290 (0.28%)

Additional statistics for metrics_page_views:
  Total users: 811,878
  Users with metrics_page_views == 0:
    Overall: 550,345
    SAP Employees: 40 (0.00%)
    Non-SAP Employees: 550,305 (67.78%)
  Users with metrics_page_views > 0:
    Overall: 261,533
    SAP Employees: 31,874 (3.93%)

From Open Exchange to Corporate Monologue: The Transformation of SAP’s Community

Sun, 07 Apr 2024 09:30:00 +0200

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.

The SAP community has had to overcome many challenges recently. The central exchange, especially for developers, Twitter has become an increasingly toxic platform and many long-time members have stopped using it or have switched to alternatives. Twitter was also one of my first ports of call and helped me a lot. There are still some, but it’s getting noticeably less.

Most important was the change of platform for the SAP Community Network for Q&A and blog posts. They now use Khoros, which has fundamentally changed a lot of things. There are still a lot of criticisms of the platform. However, as with so many changes, this one is particularly difficult.

If the company switches from SAP GUI to Fiori, then ideally this is accompanied by support and training and you have time to get used to it. In the SAP Community Network, non-SAP users are usually active in their free time to answer questions or write helpful blog posts. If fundamental things change here, you have to invest your valuable time to adapt your own workflow. If the change is too big, these valuable members may no longer be active.

The valuable blog posts from the community become rarer and marketing posts from SAP become more frequent.

Thanks to Khoros’ API, I can now support this feeling with data.

I analyzed 150,000 blog posts dating back to 2005 and the status of over 720,000 users.

First, the percentage of blog posts written by SAP employees.

The graph clearly shows that the proportion has risen sharply, especially in recent years towards SAP blog posts.

Share of SAP vs. non-SAP blog posts over time (share and absolute numbers)

About 10 years ago, less than a third of blog posts were written by SAP employees. Today, two-thirds of blog posts are written by SAP employees.

Especially in the last year, this distribution has shifted strongly towards SAP.

Here is a detailed overview of the last 12 months.

Share of SAP vs. non-SAP blog posts over the last 12 months

The sad peak was reached when over 70 percent of all blog posts in February 2024 were written by SAP employees.

Proportion of blog posts from non-SAP by experience

Another point I have noticed is that it feels like fewer and fewer veteran non-SAP employees are publishing blog posts.

Thanks to the rankings that have been introduced, it is also possible to investigate this.

The more active a community member was, the higher the rank. Jerry has explained this in this blog post: Let the gamification begin

There are the following rankings for non-SAP employees:

Member, Newcomer, Discoverer, Explorer, Participant, Active Participant, Contributor, Active Contributor, Collaborator, Active Collaborator, Advocate

I have classified Member, Newcomer, Discoverer, Explorer as inexperienced and all others as experienced.

Even if the rank does not necessarily say anything about the quality of the blog post, there is a strong causality according to my observations.

Share of blog posts by experience over time

Here, too, we have seen a significant decline in “Experienced” blog posts over the years since 2014.

Share of blog posts by experience in the last 12 months

Also in the last 12 months, less than a third of blog posts came from community members with the rank Participant or higher.

This analysis confirms the feeling in the SAP community as a whole. Even if SAP cannot be blamed for everything, the large proportion of support must come from SAP. A strong community benefits all sides and has a very good ROI.

The community is more important than ever, especially in today’s world where you have to be happy for every person who works with SAP after their studies.

SAP can only be successful with a strong community!

Update: I removed the blog posts written by former_member and updated the graphics. In total 153.655 posts. There are 421.213 members where the login name starts with former_member.

Welcome to My Blog

Mon, 27 Dec 1999 10:00:00 +0100

Hello World! 🚀

Welcome to my new blog! I’m excited to finally have a space where I can share my thoughts, experiences, and learnings from my journey as an Independent UI5/ABAP Developer.

What to Expect

On this blog, I’ll be writing about:

UI5 Development - Tips, tricks, and best practices for building modern SAP Fiori applications
ABAP Programming - Backend development insights and patterns
Open Source - Updates on my open source projects and contributions
SAP Ecosystem - General thoughts about the SAP development landscape
Developer Tools - Useful tools and workflows that make development easier

Why a Blog?

As developers, we learn so much every day - from solving tricky bugs to discovering new patterns and approaches. I’ve always found that writing things down helps me understand them better, and sharing knowledge with the community is something I’m passionate about.

The Tech Stack

This blog is built with:

Hugo - A fast and flexible static site generator
PaperMod - A clean, fast, and feature-rich Hugo theme
GitHub Pages - Free, reliable hosting
GitHub Actions - Automated deployment on every push

The entire blog is open source on GitHub, so feel free to check out how it’s built!

Stay Tuned

I’m looking forward to sharing more content with you. If you have any topics you’d like me to write about, feel free to reach out on GitHub.

See you in the next post! 👋

Mon, 01 Jan 0001 00:00:00 +0000

Ich habe mal ein Bild von unseren Hühnern auf Bluesky geteilt und seit dem bin ich schon ein paar mal darauf angesprochen worden.
Deswegen wollte ich hier aufschreiben wir wir zu den Hühner gekommen sind und welche Probleme man damit haben kann.

Ich bin in einem kleinen Dorf aufgewachsen und war in den letzen 15 jahren viel unterwegs in der Welt. Es war immer schon der Plan wieder zurückzukommen, am liebsten mit einem Haus mit viel Grund und Platz.
Im Jahr 2024 hatten wir ein Haus gefunden, haben es gekauft und sind eingezogen.
Der große Plan ist “viele Tiere” aber natürlich müssen wir auch Zeit und Platz dafür haben. Dafür sind Hühner eigentlich am besten geeignet den diese sind pflegeleicht. Außerdem haben wir ein kleines Nebenhaus das von früheren Besitzern für Papagieen genutzt wurde. Also perfekt geeignet mit nur minmalen Umbauten.

Deswegen haben wir im Haus ein kleinen Stall gebaut und draußen mit einer großen (eher etwas zu großen) Volaire für den Auslauf mussten wir nichts ändern.
Innerhalb nur zwei Tagen war der Stall dann auch schon feretig und einzugsbereit. Nester fürs Eier legen, Stangen für Schlafen, einen Wasserspender für innen und Leitern um rauszukommen (Papageiegen können gut fliegen deswegen ist der Ausgang so hcoh.) Für etwas abwechslung haben wir vier verschieden Hühnerrassen gekauft und alles haben dann auch gleich einen Namen bekommen:

Hedwig (weiß, Sussex)
Bella (schwarz, Maran)
Hermine (braun, Legehybrid)
Sperber (weiß grau gesperbert, Amrock) es ist ein Sperber also heißt sie Sperber

About Me

Mon, 01 Jan 0001 00:00:00 +0000

Hi, I’m Marian Zeis 👋

I’m an Independent UI5/ABAP Developer and SAP Consultant based in Bavaria, Germany. I run my own consulting business, IT Consulting Marian Zeis, helping companies build modern SAP solutions.

What I Do

🔧 UI5 Development - Building modern, responsive SAP Fiori applications
💻 ABAP Development - Backend development and system integration
🚀 SAP Consulting - Helping businesses leverage SAP technologies effectively
🌐 Open Source - Contributing to the SAP developer community

Open Source & Community

I’m passionate about open source and actively contribute to projects that help the SAP developer community. You can find my work on GitHub, where I maintain various UI5-related tools and libraries.

Get in Touch

🌐 Website: zeis.de
💻 GitHub: @marianfoo

This blog is where I share my experiences, learnings, and insights about UI5, ABAP, SAP development, and technology in general.

Impressum

Mon, 01 Jan 0001 00:00:00 +0000

Impressum

Angaben gemäß § 5 TMG

IT Consulting Marian Zeis
Inhaber: Marian Zeis
Hünleinshaus 1
95336 Mainleus
Deutschland

Kontakt

Telefon: +49 152 07 57 44 95
E-Mail: marian@zeis.de

Umsatzsteuer-ID

Umsatzsteuer-Identifikationsnummer gemäß § 27 a UStG:
DE 353 926 927

Verantwortlich für den Inhalt nach § 18 Abs. 2 MStV

Marian Zeis, Anschrift wie oben

Quelle für die Impressums-Vorlage: e-recht24.de (angepasst)

Search

Mon, 01 Jan 0001 00:00:00 +0000