Open-Source 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

ARC-1 1.0: One Deployment, Multiple SAP Systems

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

ARC-1 1.0 is here.

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

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

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

What version 1.0 means

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

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

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

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

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

This release was built through feedback

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

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

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

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

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

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

One ARC-1 instance, multiple SAP systems

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

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

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

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

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

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

The biggest changes in short

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

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

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

Skills for complete SAP tasks

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

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

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

Extensions for your own SAP APIs

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

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

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

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

Reusing the BTP authentication stack

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

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

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

A new home for the project

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

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

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

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

Where to start

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

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

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

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

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

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

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

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

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

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

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

Thank you

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

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

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

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