For small- and medium-sized businesses seeking an ERP solution to connect inventory, finance & accounting, HR, and other core processes, SAP Business One is often the answer.
Given its in-app BI capabilities, on-prem and cloud deployment options, and connectivity to the broader SAP HANA platform, integration to this app is a common product roadmap request from SaaS customers. Read on to learn more about the intricacies you’ll need to keep in mind when working with the native SAP Business One API.
The native API for Business One (SAP B1) offers multiple connection mechanisms and protocols: all calls to the system require connectivity to the DI (data interface) API, which is SOAP, or to the REST Service layer (only applicable if you’re on HANA.) Note that the DI API enables users to complete single transactions/object calls at one time. This API is exposed as an SDK and uses SOAP and XML methods.
Of course, working with rigid SOAP protocols is more painful than building integrations to REST APIs. Users of the SAP Business One Element (robust API connection resource) that we built get to forgo SOAP complexities, as we convert the API to REST, which goes to a .net connector to simplify the integration process.
SAP Business One also offers a DI server (for additional cost), which supports multi-threading and bulk data operations.
SAP B1 uses a custom authentication framework. The DI API requires login app credentials (username and password), SAP B1 company database name, server name, and database type (e.g. SQL 2018). The DI server also needs the server name (aka the license key), company database name, and type.
What About Bulk?
If you need to enable bulk functionality from SAP Business One, you’ll need access to the DI server. It’s not available simply from the data interface API, which has vastly different object models from the server.
However, there are some limitations to the bulk offered at the DI server - if you’re integrating to the native endpoint, you’ll need to build queues as a workaround for enabling bulk functions.
Each object in the DI API for SAP Business One combines multiple database tables on the back-end (sometimes as many as ten), and you can query with any field. In some cases, you are to query with the API field name, whereas other scenarios necessitate the database field name. Unfortunately, there’s a huge amount of nuance in the field names, making the query process tricky. For our SAP Business One Element, we implemented an SQL query object called ‘DoQuery’ that simplifies the process.
There isn’t any documentation online for the SAP Business One API, but you can find the SDK. With this, you’ll need some expertise (whether from building prior SAP integrations, reading through the SDK information, or consulting with an SAP B1 expert) to build an effective integration.
The version management capabilities available in the native API are more dependent on the Business One version you install rather than the API version, as the API component is made available upon installation. For example, at least one recent version supports SQL Server (MSFT) and HANA (SAP), but the payloads vary greatly.
There’s no native eventing feature in the SAP Business One API. Instead, you need to write stored procedures directly in the database, where you can generate a trigger and automated action. Our SAP Business One Element is feature-loaded with eventing functionality (polling or webhooks) so you can easily configure your notification and trigger cadence.
There you have it - the generic considerations you’ll need to remember when building an SAP Business One integration. But it doesn’t have to be so complex - request a free trial to use our Business One Element and see how we can help you create robust, usable integrations faster and easier.