Connecting SAP Business One: Service Layer, OData and RFC Middleware Compared

SAP Business One is the backbone for finance, warehousing and sales in many mid-sized companies. As soon as this ERP system needs to be connected to other tools such as a CRM, an online shop or a reporting dashboard, a fundamental architecture question arises: via the REST-based Service Layer with OData or via classic RFC middleware. This decision has a direct impact on project effort, maintainability and ultimately on the cost of automation, which is why it should be made cleanly at the start of every SAP B1 integration project.

In this article we compare both approaches, show how n8n sits in between as the automation layer, and what you need to pay attention to regarding authentication, error handling and scaling. As of: July 2026.

Service Layer vs. RFC Middleware: the fundamental conflict

SAP Business One offers two fundamentally different ways to access data from the outside:

• Service Layer: A modern, RESTful web API that accepts HTTP requests and returns data in JSON format. It follows the OData protocol and is specifically designed for integration with modern cloud and automation tools.
• RFC (Remote Function Call): The older, SAP-proprietary protocol through which classic SAP systems communicate. For access from an automation tool like n8n, you absolutely need a middleware layer here, for example a Node.js service with an RFC library or an integration platform like SAP Cloud Integration that translates the RFC calls into an HTTP interface.

The decisive difference for your project: the Service Layer already speaks the language that n8n understands natively, namely HTTP and JSON. With RFC you additionally need a standalone middleware component that must be developed, hosted and maintained separately. This increases the initial effort and the number of moving parts in the system, but can be worthwhile if you already have an existing SAP integration landscape with RFC building blocks or need functions that the Service Layer does not cover.

The Service Layer approach with n8n

For the majority of automation projects, the Service Layer is the more pragmatic starting point. The HTTP Request Node is, according to the n8n documentation, "one of the most versatile nodes in n8n" and allows you to send "HTTP requests to query data from any app or service with a REST API". That is exactly what is needed for the Service Layer, since there is no dedicated SAP B1 node in n8n and you model the connection yourself via HTTP calls.

Steps of a typical connection

• Login: An HTTP Request node sends a POST to the Service Layer login endpoint (usually `https://<server>:<port>/b1s/v1/Login`) with CompanyDB, UserName and Password in the body.
• Session cookie: The response contains a `B1SESSION` cookie, which you cache in n8n, for example via a Set node or static data storage, and send along in the header with all subsequent requests.
• OData queries: Subsequent HTTP Request nodes access entities such as `Orders`, `BusinessPartners` or `Items`. OData query parameters such as `$select`, `$filter`, `$orderby` and `$top` reduce the amount of data to exactly what the workflow needs, instead of loading complete datasets and only filtering them in n8n.
• Session timeout: Service Layer sessions expire after a certain period of inactivity. A robust workflow checks the status code of the response and automatically renews the session if needed, instead of simply aborting on a 401 error.

Mapping authentication cleanly

Because there is no ready-made n8n credential for the Service Layer, you work with the generic authentication options of the HTTP Request node. According to the HTTP Request credentials documentation among others "Basic auth, Custom auth, Digest auth, Header auth, OAuth1 API, OAuth2 API, Query auth" are available for this. For the classic login cookie flow of the Service Layer, a combination of an initial login request and a downstream header auth credential, into which you dynamically enter the session cookie, is usually sufficient. Important for production environments: if the Service Layer runs with a self-signed or internal certificate, you can, according to the documentation, send "an SSL certificate with your HTTP request" by storing the CA bundle, certificate and private key as a dedicated credential, instead of disabling SSL checks across the board.

The RFC middleware approach

In larger SAP landscapes, or when functions are needed that are not covered by the Service Layer, such as certain legacy processes or function modules deeply embedded in the business logic, there is no way around RFC. Since n8n does not speak RFC natively, you need a middleware layer in between:

• A custom Node.js or Python service with an RFC library translates incoming HTTP requests into RFC calls against the SAP system and returns the response as JSON.
• n8n then addresses this service quite normally via the HTTP Request node, just like any other REST API.
• Alternatively, an existing integration platform (for example SAP Cloud Integration) takes over this translation, and n8n becomes the orchestration layer that controls triggers, error handling and the connection to third-party systems.

This approach means more development effort at the start, because the middleware itself has to be built, tested and operated. In return, you get access to function modules that simply do not exist in the Service Layer, and you can continue to use existing SAP authorization concepts at the RFC level. For projects with a high integration value, this is often the point where a clean architecture decision pays off financially, because an incorrectly chosen connection has to be expensively retrofitted later.

Keeping an eye on error handling and operations

An SAP connection that only works in the ideal case is not sufficient for productive use. Build fixed checkpoints into every workflow:

• Session renewal: Detect expired sessions by the status code and automatically renew the login instead of letting the workflow fail.
• Retry logic: Network problems or brief unavailability of the Service Layer should be caught with a limited retry with wait time, not with a single attempt.
• Error logging: A separate error path in the workflow that logs failed requests and notifies if needed prevents data errors from moving unnoticed into downstream systems.

If the data volume grows, for example with several parallel integrations or high-frequency synchronizations, it is worth taking a look at the productive operation of n8n itself. For self-hosted installations, the documentation describes the queue mode, in which a main instance receives triggers and several worker processes take over the actual executions. This separates the processing load from time-critical trigger reception and makes the automation more stable when many SAP workflows run at the same time.

Which approach fits your project

For most mid-market connections, whether mirroring order data into a CRM, reporting stock levels to an online shop, or preparing invoice data for a reporting tool, the Service Layer is the more direct and lower-maintenance path. It requires no additional middleware, speaks standard HTTP and can be fully modeled via the HTTP Request node in n8n. The RFC middleware variant remains reserved for projects where the Service Layer is functionally insufficient or where an existing RFC integration layer is already in place and is to continue being used.

In both cases you retain control over your data and the process: n8n runs either in your own infrastructure or in an environment of your choice, and every step of the SAP connection remains visible and adjustable as a workflow, instead of disappearing into an opaque black box. If you are unsure which approach is right for your SAP Business One landscape, it is worthwhile to conduct a joint assessment together before development begins.

Frequently asked questions

Do I need a special SAP B1 node in n8n for the Service Layer approach?

No. n8n does not offer a dedicated SAP Business One node, but that is not necessary either. The Service Layer is a regular REST API with OData support, which you model entirely via the HTTP Request node, including login, session management and the actual data queries.

When is RFC middleware worthwhile despite the higher effort?

RFC middleware is worthwhile if you depend on function modules that the Service Layer does not cover, or if an existing RFC integration landscape already exists that is to continue being used. For new, lean integration projects, the Service Layer is generally the more efficient starting point.

How do I deal with expiring Service Layer sessions?

The Service Layer resets sessions after a certain period of inactivity. A robust n8n workflow checks the status code of every response, automatically detects an expired login and triggers a new login request before the actual data retrieval is repeated, instead of letting the entire workflow fail.

Can I store SSL certificates for internal SAP servers in n8n?

Yes. According to the n8n documentation, an SSL certificate, consisting of a CA bundle, certificate and private key, can be set up as its own credential and linked to the HTTP Request node. This is the cleaner solution compared to disabling SSL verification across the board, especially with internally signed SAP certificates.

What happens with high data volume and many parallel SAP synchronizations?

As the volume grows, queue mode is recommended for self-hosted n8n installations. In this mode, a main instance receives triggers while several worker processes take over the actual workflow executions. This keeps the automation stable and performant even with several SAP integrations running simultaneously.