How do I connect an online store to SAP Business One?

Service Layer is the usual route today. Products, stock and prices pass through a middleware layer to the store and are cached there; orders from the store are queued and created in Business One as sales orders through Service Layer, so tax calculation, numbering and validation still follow Business One's own rules.

What is the difference between Service Layer and the DI API?

Service Layer is an OData-based REST interface that works over HTTP and JSON, so it is platform independent and suits web, mobile and cloud apps. The DI API is a COM-based interface that runs on Windows and is mainly used by desktop add-ons and services on the same network as the SAP server. New web and mobile integrations usually go with Service Layer.

Can we write directly to the SAP database?

It is technically possible but should not be done. SAP does not support direct database writes; they bypass business logic, create inconsistent records and put your support coverage at risk. Use official interfaces such as Service Layer, OData, BAPI or IDoc for writes, and check that even read-only database access is covered by your licence.

Do we need an SAP partner for the integration?

Working with your existing SAP partner or in-house SAP team is the sensible route for the technical user, authorisations, activating services, any ABAP development and licensing questions. BernSoftware is not an SAP partner; we build the ecommerce, B2B portal, mobile and CRM applications and the integration layer that connects them to SAP.

We plan to move from ECC to S/4HANA. Should we integrate now?

You can, as long as the channels connect through a middleware layer rather than straight to SAP. Then the store, portal or mobile app stays the same during the migration, and only the SAP-facing side of the middleware is adapted to S/4HANA. Some field mappings will still need a second look, because S/4HANA changes parts of the data model, for example by bringing customers and suppliers together under the business partner.

How to Integrate SAP: A Guide to Business One and S/4HANA

SAP integration means sharing product, stock, price, customer and order data between SAP and the systems around it, such as an online store, a B2B dealer portal, a field sales app or a CRM, in a way that is automatic, controlled and traceable. The catch is that SAP is not one product. SAP Business One, which many small and mid-sized companies run, and SAP S/4HANA or ECC, which larger and more complex organisations run, expose very different interfaces. This guide walks through how to integrate SAP step by step: which interface fits which SAP product, which data flows in which direction, when to sync in real time and when in batches, how to test, and who does what in the project.

Start with which SAP you run

"Let's integrate with SAP" can describe very different projects depending on the product, the release and how it is deployed, so it is the first thing we pin down in a discovery call.

SAP product	Typical user	Main integration interfaces
SAP Business One	Small and mid-sized companies	Service Layer, DI API, Integration Framework (B1if)
SAP S/4HANA (on-premise or private cloud)	Large companies and groups	OData and SOAP APIs, BAPI/RFC, IDoc
SAP S/4HANA Cloud Public Edition	Companies running standard processes in the cloud	APIs released by SAP, mostly OData and SOAP; business events
SAP ECC	Installations not yet on S/4HANA	BAPI/RFC, IDoc, SOAP services, OData through SAP Gateway

What is actually switched on in your system depends on the release, the licence and the SAP-side configuration. On S/4HANA Cloud Public Edition, for example, external systems connect through communication scenarios and communication arrangements rather than calling any function they like, as they could on-premise. That is why we always confirm the interface choice with your SAP partner or in-house SAP team.

SAP Business One integration: Service Layer and DI API

The SAP Business One Service Layer is a REST interface built on the OData protocol. It reads and creates business objects such as orders, business partners, items and incoming payments over HTTP with JSON, and it reaches user-defined fields and tables as well. Because it is platform independent and scales behind a load balancer, it is the default choice today for ecommerce, B2B and mobile integrations. As with the DI API, documents go through Business One's own business logic, so tax calculation, document numbering and validation all happen in SAP.

Service Layer is session based. Reusing a session instead of logging in on every request, and grouping requests with $batch where it makes sense, keeps the load on the SAP server down. Service Layer has long been part of HANA installations and arrived on SQL Server in more recent releases, so check what your version offers.

The DI API is an older, COM-based interface that runs on Windows. It suits desktop add-ons and services running on the same local network as the SAP server; for web and mobile channels, Service Layer is usually the better fit. The bundled Integration Framework (B1if) mostly comes into play for EDI and SAP-to-SAP flows.

On the database side the rule is simple: SAP does not support writing directly to the Business One database. An order inserted straight into the tables skips SAP's stock and balance logic and puts your support coverage at risk. Reading through a read-only user and views can work for reporting, but on HANA in particular, confirm first that this is allowed under your database licence.

SAP S/4HANA and ECC integration: OData, BAPI/RFC and IDoc

On S/4HANA and ECC several SAP integration methods sit side by side, and there is no single right interface; each data flow gets its own decision.

OData and SOAP APIs

S/4HANA offers released APIs for sales orders, business partners, products, stock and much more, documented on the SAP Business Accelerator Hub (formerly the SAP API Business Hub). SAP releases these APIs to stay stable across upgrades, which makes them the first choice under a clean core approach, where you extend SAP without modifying it, and the most natural fit for web and mobile apps.

BAPI and RFC

BAPIs are functions defined for SAP business objects that can be called remotely over RFC. They are one of the most widely used integration routes on ECC and are still available on S/4HANA on-premise and private cloud. A sales order can be created through a BAPI, and price and availability can be checked with a simulation call before anything is saved. RFC calls usually run through libraries such as the SAP Java Connector (JCo) or the .NET Connector (NCo), or through middleware.

IDoc

IDocs are SAP's format for asynchronous document exchange. Orders, deliveries, invoices and master data changes can be sent out or received as IDocs. They work well for high-volume batch flows that do not need an immediate answer, and SAP tracks the status of every IDoc so failed ones can be reprocessed. On their own, though, they are the wrong tool for a web checkout that has to answer the customer right away.

SAP BTP Integration Suite and middleware

SAP BTP Integration Suite, with Cloud Integration, API Management and event components, is SAP's cloud integration platform. If your company already uses it, mapping and routing can live there, with the Cloud Connector reaching on-premise SAP systems. Older landscapes use SAP PI/PO for a similar job. These platforms move messages between systems; the caching, offline support and channel-specific logic that a store, portal or mobile app needs usually stays in the app's own backend or a separate middleware layer. The two complement each other rather than compete.

Which data flows which way in an SAP integration?

List every flow before choosing interfaces. A typical SAP integration looks like this:

Data	Direction	Notes
Product and material master	SAP → channel	Web descriptions and images are usually kept separately
Prices and discount conditions	SAP → channel	Price lists, or a simulation before ordering
Stock and availability	SAP → channel	Frequent sync, live check at critical moments
Customers, balances and credit limits	SAP → channel	Essential for B2B and field sales
Sales orders	Channel → SAP	Through a queue, with a key that prevents duplicates
New prospects	Channel → SAP	Become customer records after approval
Payments and return requests	Channel → SAP	In field sales and B2B scenarios
Order status, deliveries and invoices	SAP → channel	Status updates for customers and reps

The guiding principle is that SAP holds the commercial record. Rather than issuing invoices separately from the store, create them in SAP and send the e-invoice (e-Fatura or e-Arşiv in Turkey) through the e-invoicing setup connected to your SAP, so the records stay in one place. Our e-invoice integration guide covers how to choose between e-Fatura and e-Arşiv and how the private integrator connection works.

Real time or batch?

Pushing everything in real time is unnecessary and loads the SAP server. In practice we combine three patterns:

Scheduled batch sync: data that changes rarely, such as products, price lists and customer master data, syncs on a schedule and pulls only the records that changed (delta sync).
Event-driven sync: orders and payments are queued the moment they are created and passed to SAP in order; if SAP is unreachable nothing is lost and the record is retried.
On-demand queries: critical values, such as stock right before checkout or the credit limit before a B2B order, are read live from SAP.

What to avoid is a website that calls SAP on every page view. The catalogue and prices should be served from a cache, with SAP called only when it really matters.

Integration scenarios by channel

SAP ecommerce integration

Products and stock flow from SAP to the store, and orders flow back as sales orders. In B2C the payment is taken on the site through a bank's or payment provider's virtual POS with 3D Secure, and SAP receives the paid order with its payment reference and amount. Card details do not go to SAP. Product descriptions, images and SEO content belong in the site's own content management, not in SAP's product master data. Orders from marketplaces such as Trendyol or Hepsiburada can reach SAP through the same queue. Our ecommerce development page explains how we build the store side.

SAP B2B integration and dealer portals

In B2B, most of the work is in pricing and customer accounts. Each dealer must see their own prices, discounts, balance and credit limit, and that data has to match SAP or dealers stop trusting the portal. We cover the portal side on our B2B ordering portal page and in our B2B ordering portal guide.

Field sales and CRM

Field reps often work where the connection is weak, so the mobile app runs offline from a local copy of the data on the device and sends orders to SAP through the middleware once it reconnects. BernSFA handles routes, visits, mobile orders and collections, and is built to integrate with Logo, Mikro, Netsis or SAP. On the CRM side, BernCRM is built on BernSFA's customer and sales core and works from the same data.

Master data quality

Many SAP integration problems come from the data rather than the interface. Before go-live, review:

Duplicate customers: several business partner records for the same company send orders to the wrong account.
Units of measure: the base unit may be pieces while the sales unit is a case; the channel has to order in an agreed unit.
Sales area and organisational data: on S/4HANA and ECC an order needs the right sales organisation, distribution channel and division.
Tax and pricing conditions: VAT codes and discount rules should come from SAP rather than being rebuilt in the channel.
Warehouses, plants and storage locations: whether it is Business One warehouses or S/4HANA and ECC plants and storage locations, agree in advance which stock each channel can show.

Give every piece of data an owner: SAP owns products and prices, the website owns web content and the CRM owns visit notes.

Your SAP partner and the integration team

Two sides work together on an SAP integration: your SAP partner or in-house SAP team, who look after SAP itself, and the integration team, who build the software around it. Drawing the line early speeds everything up. We are not an SAP partner. We are the team that builds the store, the dealer portal, the mobile app and the integration layer in between. A typical split looks like this:

Task	SAP partner or SAP team	Integration team
Technical user and authorisations in SAP	Sets up	Specifies what is needed
Service Layer, OData service or IDoc settings	Activates and configures	Uses and tests
Custom development inside SAP (ABAP, user-defined fields)	Builds	Defines the requirement
Middleware, queues and monitoring dashboard	Reviews	Builds and runs
Store, portal, mobile app, CRM	Kept informed	Designs and builds
Field mapping and test scenarios	Jointly	Jointly

Licensing belongs in this conversation too. External systems connecting to SAP and creating documents in it can be subject to licence terms, so clarify where your own contract stands with your SAP account manager or partner.

Testing without touching the live system

Business One projects test against a copy of the company database; S/4HANA and ECC landscapes usually have separate development and quality systems. A copy of the live company holds real customer data, so restrict access to the test environment and mask personal data where needed, which also matters under Turkey's data protection law (KVKK). The test plan should cover at least:

End-to-end flows: from an order on the site to an invoice in SAP.
Negative cases: credit limit exceeded, item out of stock, blocked customer, missing mandatory field.
Outages: the queue holds and retries while SAP is down, and no order is created twice.
Load: busy periods such as campaign launches and month end.
Reconciliation: comparing channel orders with SAP documents for a given period.

Common SAP integration pitfalls

Writing directly to the SAP database.
Rebuilding SAP's pricing logic in the web app, where the two drift apart over time.
Integrating through a user with broad rights instead of a technical user with only the authorisations it needs.
Logging in to Service Layer on every request, which is slow and puts needless load on the SAP server.
Leaving errors in an email inbox instead of a dashboard where failed records are visible and can be resent.
Going live with every flow at once instead of starting with products, stock and orders.
Writing custom ABAP on S/4HANA when a released API already exists, which makes upgrades harder.

For a general comparison of API, direct database and middleware approaches, see our article on ERP integration methods.

How to integrate SAP, step by step

Map the current state: SAP product, release, deployment, available interfaces and the channels to connect.
Write the data flow table: direction, frequency and source of truth for each item.
Choose interfaces with the SAP side: Service Layer, OData, BAPI or IDoc for each flow.
Map fields and clean master data: codes, units, tax and organisational data.
Keep the first phase narrow: products, stock and orders, verified end to end on the test system.
Pilot, then go live: start with a limited group of customers or dealers, with monitoring on from day one.
Decide who owns support: someone must look after the integration through SAP upgrades and new requirements.

BernSoftware builds ecommerce sites, B2B portals, field sales and CRM apps for companies running SAP Business One or S/4HANA, along with the integration layer that connects them to SAP, and we plan the SAP-side configuration together with your existing partner or SAP team. See our SAP integration and ERP integration pages, outline your needs in the project planner or get in touch. After a discovery call we share a clear timeline and a transparent quote.