A pandemic as a driver of innovation
Paperless communication between customers, suppliers, manufacturers and freight forwarders was an early driver for the establishment of data communication processes and standards, such as Fortras, ODETTE or EDIFACT.
Due to the continuously advancing digitalization of business processes, driven not least by the Covid 19 pandemic, global supply bottlenecks or container shortages, the pressure for ever closer interlinking of systems along the supply chain continues to increase. The aim of this is, among other things, the resulting competitive advantages. For example, tenders for transport orders can be transmitted and processed fully automatically on a corresponding platform. This gives all parties involved in transportation a decisive advantage in terms of speed, flexibility and transparency.
The establishment of completely contactless processes along the supply chain, also significantly influenced by the Covid 19 pandemic, has driven the need for paperless transitions between systems and processes at a pace that could not have been foreseen. Flexible, rapidly adaptable and integrable systems that can easily adapt to changes in business processes are a key competitive factor here.
EDI is dead, long live EDI!
For a long time, Electronic Data Interchange (EDI) was the established method for mapping business processes across system boundaries. Standards such as SWIFT and EDIFACT are widespread and have become indispensable for communication between large companies or banks. EDI itself is nothing more than a collective term for different procedures and standards for data exchange between companies and organizations.
EDI relies on standardized data exchange formats and protocols that must be adhered to by all participants. The advantage of standardization, namely a precisely specified and standardized protocol, has also become the disadvantage: Due to the different requirements of industries and countries, a multitude of versions and variations of the standards are now in circulation. Especially in international data exchange, different, country- and industry-specific standards are often used.
Also, the protocols and formats used are often very complex, which often results in high expenses during the implementation of EDI projects. Especially for small and medium-sized companies, it therefore becomes difficult to establish communication with larger partners via EDI.
Another disadvantage of EDI is that data exchange is usually handled in a batch process. This means that business transactions are collected and then transmitted in a batch. This means that processing data in real time or close to real time using EDI is not possible, or only possible to a very limited extent.
The data of the EDI standards are very strongly structured and standardized. On the one hand, this has the advantage that the data format is uniform and there are often already turnkey implementations. On the other hand, the standardized formats often prove to be inflexible and make adaptations to business processes difficult and lengthy. Nevertheless, standards such as ODETTE or EDIFACT are very widespread today and large providers such as SAP now offer appropriate adapters and converters for their system worlds in order to be able to exchange data between EDI and newer methods such as IDoc- or API-based systems.
Microservices and API - the beginning of a wonderful friendship
Several profound paradigm shifts have taken place in the IT world in recent years that have had a strong impact on how IT systems can communicate and exchange data. In all these changes, the basic principles of flexibility, agility and elasticity are always at the center. This means that companies want to use their IT to respond faster and more flexibly to changes in the market and thus in their business model. IT should not be a stumbling block and cost driver, but should support the changes in the company to the greatest possible extent.
The foundation for this flexibility of IT systems is best described by the three paradigms microservices, cloud computing and API first. The departure from monolithic architectures to individual services that map a specific part of a complex business process makes it possible to adapt these in any form to a new business process, to exchange them, to make them available to other companies or to use them by other companies.
Business processes can thus be mapped and flexibly changed on the basis of individual modules using firmly defined interfaces, the APIs. This means that a partner can use a single business process without having to integrate a complete application.
"L'API c'est moi" - or why code revolves around the API.
With the advent of the new paradigms in IT, especially microservices, service-oriented architecture (SOA) and cloud computing, the focus is shifting towards API-centric architectures, also referred to as “API first”. Simply put, this means that when developing a service, the API, i.e. the interface with which this service is used, is designed first and the functionality behind it is always oriented to this API. This is to ensure that the interfaces are stable at all times and offer the highest possible value for the respective users of the API.
Modern APIs are based on the so-called REpresentational State Transfer (REST) principle. The underlying principle is the HTTP protocol, which is the basis of data traffic on the Internet today and is therefore widely used. The messages themselves are represented in a format defined by the operator of the API using JSON or XML. This is certainly the biggest difference to EDI. While EDI provides clearly standardized messages per business transaction, the user of an API has to integrate them into his system in each case. However, the REST approach meets this challenge by applying a simple, clear principle based on widely used, open and secure standards.
More business, more API: APIs and the Cloud
The use of APIs and microservices in cloud computing now offers a high degree of scalability and elasticity. Seasonal influences or abrupt events can change the volume of business transactions on a planned basis or at very short notice. For example, an online retailer can anticipate when a new model of a popular cell phone will be available, or an automobile manufacturer when it will launch a campaign for a new model in a particular market. So they can also foresee when to expect an increase in API traffic. On the other hand, surely no one could have foreseen how quickly and comprehensively a virus could shift consumer behavior toward online commerce, with all the implications for the supply chains behind it.
In order to continue to serve these peaks or plateaus in demand in a performant and stable manner, it used to be necessary to provide additional hardware, “tins” to run the application and thus be able to ensure the increased volume of requests while maintaining the availability of the application.
With the advent of cloud platforms and the associated elasticity of applications, it is now possible to be able to respond to such changes in the usage profile of a service at short notice, without the lengthy process of hardware procurement and the associated capital commitment: After all, when the Christmas business is over, you still have the extra newly acquired hardware in the data center.
APIs once more play a decisive role here. The API is defined as the end point of an application and is monitored accordingly by the cloud platform (API monitoring, API management). If the platform now detects that the API reaches certain threshold values, for example a defined expected response time is exceeded or the number of requests per minute reaches a certain threshold value, additional hardware can be activated automatically and the service that requires more performance can be boosted.
If the defined threshold values are undershot again, the scaling then runs in the opposite direction. In this way, the application remains elastic at all times without permanently increasing the costs of operation. By coupling the individual services via an API, it is even possible to move only parts of an application to the cloud or to integrate the services of a provider in the cloud into one’s own business processes.
The Dancing on Many Weddings - the Technical Integration of Heterogeneous Process Partners
A modern, cloud-based logistics platform makes its services available to a large number of different partners in a business process. The range of partners involved in these processes covers almost every size of company: from large manufacturing companies to international logistics service providers and small forwarding companies to end customers. The IT systems involved are therefore just as heterogeneous. From company-wide SAP installations, to ERP solution providers such as Oracle, Sage or Microsoft, to the small family business with a self-developed logistics solution or Excel spreadsheets, the entire IT spectrum is available.
In order to be able to integrate as many partners as possible into one platform, the chosen form of integration must be as easy to implement and scalable as possible. As mentioned above, EDI represents an almost insurmountable hurdle for small and medium-sized companies. The necessary investments in the implementation and operation of an EDI connection are probably not feasible for most companies of this size.
A connection via API, on the other hand, is a manageable, easy-to-implement effort. There is no need to operate a dedicated platform, as most applications today already offer the ability to integrate REST-based APIs. In the simplest case, an API can be served by a simple standalone client.
The biggest challenge in API integration is usually the so-called mapping of the data of a business process to the target format of the API provided. In most cases, this format is nowadays JSON, an easily understandable and applicable data format. But XML also plays a decisive role here, not least SAP relies on this standard with IDoc. Regardless of the data format, APIs should be well documented and contain descriptions of the methods used and the data format.
But how does such an API integration work from a technical point of view? Since HTTP is an established communication protocol, proven methods and standards can already be used here, which we will briefly outline below:
Security - Authentication, Authorization and Encryption
Of course, it must always be ensured that only authenticated partners can use an API, and that communication between systems cannot be manipulated and remains confidential. For this purpose, there are proven methods for authentication and authorization with OAuth, OpenID and JSON Web Token (JWT).
As an example, the client of an API must authenticate itself to the target system using credentials and then receives a JWT back. This JWT is then sent along with the call to the corresponding API method and evaluated by the target system. The JWTs contain information about both the authentication of the client and the authorizations that this client has (authorization). As a rule, the tokens have a defined validity, for example five minutes, after which the token becomes invalid and a new token must be created before the next request to the API. This ensures that the authorization of the user can be checked again and again.
To ensure the confidentiality and integrity of a connection between two systems, HTTPS is used as a common and reliable standard. This guarantees that the communication between the partners is encrypted and cannot be manipulated by a third party.
Resources and methods - RESTful APIs
A REST based API uses the methods defined in the HTTP protocol such as POST (create), GET (read), PUT (modify) and DELETE (delete) a resource. A resource in this context is a specific business object to which the method should refer. For example, such business objects could be freight orders, purchase orders, invoices, customers, or vendors.
For example, a REST API for an account might provide the following operations:
- GET https://somecompany.com/accounts /a341422 to retrieve account information for account a341422.
- POST https://somecompany.com/accounts /m865532 to create an account with the number m865532.
The actual information about the business object is then transmitted in the so-called body or payload of the message.
Mapping - JSON /XML
JSON uses a simple, easy-to-read form of representing structured data. It is modeled after the JavaScript programming language and can be easily created and processed.
For example, an address in JSON notation may have the following notation:
“address” : {
“name” : “Leogistics GmbH”,
“city” : “Hamburg”,
“country” : “DE”,
“street” : “Borselstraße”,
“streetNumber” : “26”,
“zip” : “22765”
}
The same information would be represented in XML like this:
<ADDRESS>
<NAME>Leogistics GmbH</NAME>
<CITY>Hamburg</CITY>
<COUNTRY>EN</COUNTRY>
…
</ADDRESS>
The challenge in the integration is now to define a suitable conversion of the data from the client system to the respective required format of the API – the so-called mapping.
Direct Connection or Middleware
Cloud, Microservices and API - Why APIs are the Future
Cloud computing is now much more than a buzzword in IT. More and more companies are transforming their IT in the direction of the cloud, as this is where the necessary flexibility, elasticity and efficiency are available to enable IT to be used as a competitive advantage.
The combination of API, microservices and cloud makes it possible to react quickly and efficiently to changes in business processes and to be able to integrate partners into the processes.
The API, i.e. the interfaces, is of particular importance here: it represents the central point via which the individual services, partners and companies can communicate with each other. The use of modern, REST-based APIs enables communication across company boundaries, in real time. Onboarding times for new partners can be reduced to a minimum through the use of well-documented APIs, established protocols and supporting middleware components.
We are here for You!
API First not only represents a modern approach to software development, but is also THE paradigm of the future for process and system integration across company, industry and national boundaries. Have we sparked your interest in modern data exchange methods around APIs? At leogistics, we have extensive expertise in this area and in integrating applications with a wide variety of upstream and downstream systems. Do you have any questions? Just contact us at blog@leogistics.com.
Marc Gutekunst
Senior Solution Architect Digital Supply Chain
The RF Framework Is Dead – Long Live The RF Framework
4 variants of production integration with SAP S/4HANA EWM – which one is right for you?
SAP S/4HANA 2020 FPS01: Many New Features in Stock
Do you want to know if a feasibility study brings cost transparency?
