SAP Business One Integration: Basics

SAP Business One is a powerful and scalable business management system which assimilates many core business functions in a company. Providing managers with access to critical real-time data, it was designed to enable you to make quicker and weighed decisions.

To begin with, we divided the types of SAP integration (we also call them “forward” and “backward”) according to the tasks they are supposed to solve. There can be the following scenarios of high-level integration:

  • Data replication. Depends on whether there is a subset of tables in the SAP B1 database, which is used as a master database, or the external databases store the copy of these data.
  • Data synchronization. In this case you need to answer the question: are the data synced all the time or just occasionally?

As for the implementation challenges and additional expenses, they arise after you start dealing with business logic and big data volumes. Thus, it all depends on which data replication scenario there is and how frequently the data is synced.

Now let’s get to the very mechanisms of integration starting from standard solutions that come with SAP B1 SDK:

The trick is that these solutions don’t work right out-of-the-box as you may want them to.

So, in order to better understand the key differences between them and find out which ones exactly will be the most crucial to consider we need to look into the main technical aspects starting from Data Interface.

SAP Business One DI-API

DI-API exposes an interface to the SAP Business One objects by which it is possible to read, browse, create, update and delete objects in a SAP Business One database, plus carry out a set of some advanced metadata and XML operations. DI-API internally handles communication with the underlying SAP Business One database, ensures full data validation, and automatically populates default field values based upon the business rules of SAP Business One.

In fact by using the DI-API the external system not only accesses the SAP Business One database but activates all the business logic underlying SAP Business One itself, ensuring coherence of the data in the SAP Business One database itself against the SAP Business One business logic. Accessing directly the SAP Business One DB in write operations — e.g. with an ODBC connection — is against the programming guidelines of SAP Business One SDK as it can introduce inconsistencies in the system data.

DI-API is implemented as a DLL based on Microsoft COM. It can be easily used with any COM or .NET — compliant development environment including Microsoft Visual Studio or Visual Studio .NET. One can also be adjusted to Ruby on Rails using a simple Savon-based layer to implement SOAP protocol interpreter and XML generation.

The DI-API acts in fact for the external system as a COM-based faсade encapsulating and hiding many internal services (pic. 1) providing:

  • access to the database and metadata functions (Data Manager)
  • advanced XML functionality (Schema Generator)
  • and finally the whole SAP Business One business logic (OBServer)

Note that DI-API is a mono-direction and synchronous interface. Data integration requires also asynchronous interfaces to receive notifications of creation, deletion and update of objects in the SAP Business One DB.

SAP Business One DI Server

DI Server provides a SOAP interface to SAP Business One. The set of operations allowed by this interface is a subset of the methods exported by DI-API. Basically, it allows the CRUD operations on the objects exposed by DI-API (Create, Read, Update and Delete) with one limitation: Metadata functions are not exposed by DI Server. Using DI-API it is possible to change the structure of your data by adding, updating or removing user tables, user fields and user objects. These operations are not exported by DI Server.

The DI Server can group several operations in a single transaction (batch) though batch processing is also available in API.

The main advantage of the DI Server over the DI API is that it supports a wider range of client technologies, and allows the use of COM, CORBA, or TCP/IP to interface with SAP Business One using XML. It can be considered as a SOAP wrapper around the internal SAP Business One data services as opposed of DI-API as a COM-wrapper.

Here you can see the DI Server architecture itself:

Custom Backward Integration

In backward integration we build a service on the SAP side. It addresses to your API and grabs all the necessary data by request.

Say we need to implement backward integration in an E-Commerce project. The main steps will be as follows:

  • Make the access to the database on the app side open, so that SAP could easily take whatever data it needs.
  • Create a normalized table, that includes required names of SAP data types and SAP standards. Located in Ruby on Rails application database, the table will have a read/write access for SAP requests.
  • Then create a callback, which processes a received order and puts it into the table.
  • After the user confirms the order, it is parsed into the SAP format.
  • Next create a rake task, which parses the data, that is already in the database — if any — (because the integration may be done not from scratch).
  • Normalize the SAP format to provide the full integration.
  • They import the data (orders) into the SAP database.
  • After that they sent a response to the web application and the status of each item in the table changes (migration is either true/false).

Thus, in the first case the app connects with SAP, and in the second — it is SAP that connects with the database. The latter requires building an API on our side.

You may think, that there is no way the whole process can be so simple. And it’s true. In terms of development, forward integration requires more time to implement both on the SAP side, which is DI API or DI Server configuration (depending on a particular solution), and on the web app side (building background workers and other features). Backward integration is mostly all about development on the SAP side meaning it will require a SAP developer on the client side while the web app side may require only minor changes (database table adaptation according to the SAP data types and structure).

Integration with Mobile Clients (iOS and Android)

SAP integration with both iOS and Android apps is also not a new thing to JetRuby developers. Among other things we implement there is an additional layer allowing for converting into JSON format that is worth mentioning. Such integration requires engagement of additional services and resources to preprocess frequently used data output, e.g. Elasticsearch for quick search and output.

Writing and calculations occur asynchronously in the background threads through special Ruby or GoLang based adapters, if calculations take more than 10 seconds for one client.

Summing up

With SAP B1 there is no need to have several sophisticated systems and applications in order to manage data. By automating manual processes, this solution reduces the factor of human error, which enables your business to operate way more efficient.
For us there is hardly any challenge in implementing SAP integration — no matter which one you would like to have. We can do both.

Sources: and the experience of JetRuby E-Comerce development department.

Show your support

Clapping shows how much you appreciated JetRuby Agency’s story.