Every distributor eventually needs SAP Business One to talk to something else: an ordering portal, a sales app, a warehouse device, a carrier, a payment provider. How that connection is built decides whether it is still working in five years or whether it breaks quietly after the next upgrade. This article explains the options in plain terms and how we choose between them.
The interfaces SAP Business One provides
SAP Business One exposes several supported ways in. Anything else, in particular writing directly to the database, is unsupported and a reliable source of corrupted data.
DI API
The Data Interface API is the original programmatic interface. It is a COM library installed with the SAP Business One client, and it gives code access to business objects: business partners, items, documents, journal entries and so on. When you create a sales order through the DI API, SAP Business One applies the same validation and posting logic as the user interface.
Strengths: complete coverage of business objects, mature, well documented. Weaknesses: it is Windows-only, it runs in-process and holds a connection, and it is slow for bulk operations. It is still the right choice for many add-ons and for environments that already depend on it.
Service Layer
The Service Layer is a REST interface built on the OData protocol. It runs as a service on the server and speaks HTTP and JSON, which means web applications, mobile apps and integration services on any platform can use it without installing SAP Business One client software. It was introduced for SAP HANA installations and has been available for Microsoft SQL Server installations in recent versions of SAP Business One 10.
Strengths: platform independent, stateless, scales better under concurrent load, natural fit for web and mobile. Weaknesses: a small number of operations still have no Service Layer equivalent, and some older add-ons expect the DI API.
For new work, the Service Layer is our default.
UI API
The UI API lets an add-on live inside the SAP Business One client: adding menus, screens and fields, reacting to what the user does. It is for extending the desktop experience, not for system-to-system integration.
The integration framework
SAP Business One ships with an integration framework. It handles scenarios such as intercompany, some integrations between SAP Business One companies, and connections to certain third-party platforms. For bespoke integrations we usually find purpose-built middleware simpler to operate and easier to monitor, but the framework has its place, and we use it where it fits.
Read-only database access
Reporting, feeds and dashboards can read directly from the SQL Server or HANA database. Reading is fine. Writing is not. Business logic, numbering, postings and audit history all live in the application layer, and writes that bypass it produce data SAP Business One cannot explain.
Real time or scheduled
The second decision is timing.
Real time means the integration calls SAP Business One the moment something happens: a customer places an order on the portal and a sales order exists in SAP Business One a second later. Use it when the answer matters immediately. Stock availability for a customer about to order. Credit status for a rep about to commit. Order creation, so nothing is lost if a device is dropped.
Scheduled means a job runs on a timer and moves data in batches. Use it when freshness does not change the decision. Catalog and pricing updates to a portal every few minutes. Sales history to a reporting database each night. Scheduled jobs are cheaper to run, easier to retry and kinder to the ERP under load.
Most integrations are a mix. A B2B portal might receive catalog and price updates on a schedule, check stock in real time and create orders in real time.
Why we put a middleware layer in between
A direct, point-to-point connection between two systems is quick to build. It is also the hardest thing to live with. When either system changes, the connection breaks, and nobody finds out until a customer calls.
We build a middleware layer between SAP Business One and the outside world. It does a few unglamorous things that matter a great deal:
- Logs every transaction with what was sent, what came back and when.
- Retries failures with sensible back-off, and stops retrying when something is genuinely wrong.
- Alerts a person when a sync fails, rather than failing silently.
- Transforms data in one place, so field mappings live in one documented location.
- Isolates change, so replacing a storefront or a carrier means changing one connector, not everything that touched it.
The layer also gives your team a screen: what moved, what did not, and why. Integrations that nobody can see into are integrations that nobody trusts.
The data contract
Before code, we write down the contract between the systems:
- Ownership. Which system is the source of truth for each record. Items and prices are owned by SAP Business One. Web content for a product is owned by the portal. Customer addresses can go either way, and that decision has to be explicit.
- Triggers. What event moves data, and in which direction.
- Conflicts. What happens when both systems changed the same record.
- Failure. What the user sees, what the log records and who is alerted when a call fails.
- Identity. How records are matched across systems, and what happens when a match is missing.
A one-page document covering these five points prevents most of the arguments that otherwise happen after go-live.
Surviving upgrades
Integrations built on supported interfaces, the DI API and the Service Layer, carry across SAP Business One upgrades with at most minor changes. Integrations that write to tables directly, rely on undocumented behaviour or hard-code version-specific details do not. Before we upgrade a client's environment we run the integrations against the new version in a test system, and we keep a runbook so anyone on the team can do the same.
In practice
Our B2B eCommerce, sales rep, inventory counting and label printing solutions are all built this way: supported interfaces, a middleware layer, a documented contract. The same approach applies to one-off integrations with carriers, payment providers and customers' own systems. If you have a connection that is causing trouble, or one you need to build, talk to us and we will explain what we would do.