Cap on Marian Zeis Blog

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

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

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

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

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

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

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

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

A short history of RFC outside ABAP

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

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

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

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

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

The conversation that started open-rfc

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

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

I started an AI coding session the same night.

Spoiler: even with AI, it is hard.

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

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

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

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

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

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

What the first beta includes

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

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

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

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

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

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

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

BTP, Cloud Connector, and an ARC-1 extension

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

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

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

Why beta does not mean almost 1.0

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

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

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

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

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

The CAP replacement I wanted from the beginning

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

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

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

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

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

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

I need your help

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

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

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

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

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

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

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

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

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

Let’s make this work.

References and links

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

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.