Application Programming Interfaces, also known as API, play a critical role in the way we interact with technology nowadays. In this article, I demystify API using SAP products as an example.
As mentioned above, API stands for Application Programming Interface, where Interface is the key word.
In the context of an ERP like SAP, data is structured and stored in a database. This data is then isolated and protected by different layers of security, with everything wrapped by multiple lines of code enforcing the respect of a particular data model.
To interact with this data, special tools (modules, functions, classes) are programmed to allow specific actions on this data model, in read or write mode. These tools are commonly known as APIs. Most new generation applications and ERPs have APIs to facilitate communication with internal data.
The rest of this blog will focus on SAP APIs. In order to better understand the role of APIs in a computer ecosystem let's start by understanding where they come from.
Whoever knows SAP well enough will know about BAPIs, but maybe not their exact identity.
The word BAPI is not a coincidence (BAPI = Business API) a term specific to SAP with very specific attributes:
SAP offers some libraries (connectors) for different programming languages (VB, Java) allowing custom systems to connect to SAP to achieve different actions. A lot of old custom systems and Apps still use these tools today.
With the integration of a web server in SAP's application layer, it's now possible to communicate using HTTP(S) protocol. This communication method will quickly replace RFC as the protocol of choice to automatically integrate systems. Ultimately, this will allow the emergence of web services, protocols used to communicate between devices.
The SOAP format under HTTP makes it relatively simple for systems to communicate, with data being transferred in XML format.
We now regularly find examples of interfaces between SAP systems (ECC or S/4) and multiple external partners to automate critical business processes (ex: vendor invoice transfer, shipping data, delivery labels, etc.). These partners usually charge a fee for these services (APIs) based on volume of calls.
As a real-life example, our development team have consumed several times, in SAP ECC and SAP S/4HANA, SOAP APIs produced by Canada Post to generate labels used to ship orders or tracking numbers which we store in the SAP document.
A member of my team has also recently participated in multiple projects in which we must interact, with SOAP calls, between SAP S/4 HANA and their own product Concur (or an alternative, Trindocs) to transfer vendor data and their invoices.
A few years later, a new style surfaces, REST, based on a data modeling concept and the methods to interact with these data. We're talking about a style here, or an approach, instead of a Protocol. No new technology is used, existing rules of the web are respected, but the payload is lighter (no WSDL) compared to SOAP. Best practices are usually to restrict ourselves to very precise actions on a clearly defined object. Usually transferred as JSON (lighter than XML) under HTML, this new style will gain a lot of popularity with the web community, including most new mobile app.
Google Trends, from 2004 to 2016, general interest in the subject:
In 2007, Microsoft developed a new Open Source protocol named OData, standardizing and simplifying the production and consumption of REST APIs. The format shares similarities with JDBC and ODBC APIs but applies mostly to object data models instead of being limited to relational databases.
SAP will adopt the OData protocol, which will become the tool of choice for data transfers between its new front end Fiori and the application layer.
Many companies will stand out by focusing on their APIs offer, which will become even more popular than their original product or service. APIs web traffic, now automated from machine to machine, will overtake regular user traffic.
We've all shared some interesting news or other articles on our Facebook wall or Instagram profile. Just recently, I was pleasantly surprised to connect to my "Revenue Canada" account (which I don't know) using my personal bank account (which I know very well). Some video games will even, transparently, use third party storage APIs to save a player's progress and preferences. These interactions are made by APIs.
Human interaction is being eclipsed by more and more applications (including mobile) communicating with each other by REST APIs, creating some sort of social network for machines.
To consoliate and facilitate searching for all sorts of APIs for different cloud products, SAP launched its API Business Hub. Here's an example of a search for APIs in the purchasing domain, and their different formats:
SAP's Cloud Platform (SCP) puts at developers' disposal a service called API Management. Here we can expose our own API, create products (API combinations), add security or other required limitations, track consumption, evaluate statistics and errors, etc.
Using the integration with the WebIDE, we can even create Fiori apps based on a template and embed in our app a call to one of these APIs.
I have personally spent many hours over the years looking for details on different actions of an API, following the sometimes very thin and scattered documentation found all over the Internet. The quality and format of information found today is a clear improvement.
With this sort of gathering and homogenization of information as well as the automatic generation of pieces of code, it has never been easier to develop professional and integration applications.
It is certain that these tools and their integration will not stop evolving, so it's important to stay informed. Contact us for more information!