EDI brings great help in optimizing cost, time, efficiency and safety in your data exchange projects. Nonetheless, you might wonder if it is integrated with SAP or another ERP system. Is it necessary to implement EDI when API works as well? Let’s break it down and make your integration process go as smoothly as possible.
If you decide to digitize data exchange processes in your business, there are two main directions you can choose: traditional electronic data interchange integration via communication channels or an application programming interface. Both models have pros and cons, and taking a certain approach depends on your particular needs. Various circumstances might determine what is best for you company – but making a final decision requires knowing what stands behind your options.
What are EDI integration and different protocols?
EDI integration is the process of introducing comprehensive EDI workflow between business partners, and it has been used for about… half a century. There are some very important questions you need to answer before deciding on the communication channel this kind of integration involves:
With what business partners are you exchanging documents via EDI?
For which IT system it is necessary to send, receive and process EDI data (ERP, WMS, or other)?
Web-based systems or mobile applications – between what will you exchange information?
What kind of messages or documents will be exchanged between you and your business partners?
In what EDI formats do your messages need to be?
Which technologies will you use to exchange data?
When you have gathered this information, you’re ready to move to the next stage, which is establishing a protocol connection. In most cases, you choose between the most popular ones: AS2, X.400, SFTP, FTPS, and OFTP. What are the markers that distinguish them from one another?
AS2 – well-known for security
AS2 might be the most popular method for data (particularly EDI data) exchange because of its security and reliability. It involves the client’s computer and a server connected point to point through the web. AS2 creates an envelope for the EDI data, and sends information with the use of digital certificates and encryption – which it requires on both sides. What is unique to this particular protocol is that it sends a message delivery notification that functions as a confirmation of receipt.
There are many examples of successful EDI integration via AS2 on the global market. Such companies as Walmart, Amazon, Target, Lowe’s, Bath & Beyond and many others have already proved they can optimize costs and run near real-time EDI communication with AS2 EDI.
X.400 – “email on steroids”
X.400 is not a new solution and is often called “email on steroids”. The addressing is highly structured and started as an alternative to a commonly used SMTP (Simple Mail Transfer Protocol). Nowadays, X.400 is a common choice – but only in the EDI environment.
X.400 establishes a mailbox analogous to an email for the client and the EDI provider. What is required here is the X.400 address and application. It is possible to get statuses for sending, receiving and delivering a message. What might be relevant here is that data exchange via the X.400 channel involves additional costs for the EDI provider, so there are two options to consider: avoid connecting via X.400 at all or passing this cost on to the client.
FTP, SFTP, FTPS and OFTP – many shades of file transfer protocol
FTP, or file transfer protocol, is a standard network protocol for transferring computer files between a client and a server. FTP is built on client server model architecture and uses control and data connections. Its users authenticate themselves with a username and a password. What differentiates FTP from X.400 is the fact that it generates no statuses besides the internal ones for setting messages of the FTP folder.
Meanwhile, FTPS (meaning FTP over SSL/TLS) is the file transfer protocol secure option, because it uses secure encryption. The data transported between the client and the server are protected by a session-specific key (TLS handshake) that encrypts all messages.
FTPS allows the user to authenticate the sender’s server identity by running a couple of certificate checks. The server authenticates the client with the use of its username and password, and does it over a fully secure channel.
Moving to other types of channels, SFTP (meaning FTP over SSH) stands for secure file transfer protocol. It requires communication between the client and server to be 100% secured. Hence, SFTP makes it much easier for IT administrators to ensure security best practices within a company by applying a standard to all file transfers.
OFTP means ODETTE file transfer protocol, and it is used for EDI. The first version of this channel was created about 40 years ago. OFTP is especially popular across the automotive industry in Europe. The second version, OFTP2, can work directly – point to point, or indirectly – via a VAN (value-added network). OFTP2 can not only make and receive calls, but also exchange files in both directions – it works in push or pull mode.
What’s more, OFTP2 is able to encrypt and digitally sign a message with data, as well as request signed receipts. At the same time, it also offers efficient data compression. However, there is one condition – all of these are available while using OFTP2 over TCP/IP, X.25/ISDN, or native X.25. If you use it over a TCP/IP network (for example the Internet), higher session-level security is possible only by using OFTP 2 over TLS (transport layer security).
Web Services
A different kind of channel is Web Services, and it connects two devices: client and server. First, the client uses Web Services to send a standard XML message via the Internet in HTTP. Second, they wait for a real-time XML response that comes from the server. It doesn’t require any more effort than establishing other channels mentioned above. Having in mind that all messages are in XML format, this is an efficient way for electronic data exchange, even more so as you are not limited by one system or application.
These are the basics of the traditional EDI. Now it’s time to understand what an API is, and how it works.
What does it mean to “introduce an API”, and how does it influence the data exchange?
API is an abbreviation for application programming interface, which is a software intermediary allowing two applications to communicate. It was developed as a bridge for applications to enable them reaching data and interacting with external operating systems or software. This means that API sends a user response to a system and the other way round – the system’s response to a user.
However, standardization is a real challenge here. It is difficult to integrate various APIs. To solve this problem, many different standards have been developed over the years, two of which are the major ones are commonly applied. These are SOAP and REST.
SOAP API
SOAP, simple object access protocol, is a standard communication protocol that enables processes that use different operating systems to communicate by HTTP and XML. SOAP-based APIs aim to create, update, recover, and delete accounts, passwords or custom objects.
SOAP offers over 20 different kinds of calls that allow API developers to maintain accounts, perform searches and do other things. Thus, it can be used with all languages which support web services.
These APIs take advantage of HTTP and XML, which are already functioning. This makes it easy for developers to manipulate web services and get responses with no worries about languages or platforms.
REST API
REST, representational state transfer, is a standard for designing APIs where CRUD (CREATE, READ, UPDATE, DELETE) refer to POST, GET, PUT and DELETE actions. REST does not require WDSL or UDDI, but is based on several rules, as follows:
It has a uniform interface for communication between client and server, which means:
The interface is based on resources – each resource has its own unique URI, but the way it is represented can be different and is always independent of the resource.The manipulation of resources is carried out through representation – after receiving it from the server, the client is allowed to modify or delete the resource.The server responses to the client are self-describing – all server responses contain material on how to do it.There are relationships between resources, and the client should be able to navigate between them using hypermedia, a nonlinear medium of information.It defines an evident separation between server and client logic, so that modifying one does not impact the other
The server should not store data about the client .API should always support caching – it is available for read operations but not recommended for data modification actions
The client sending a query should get an answer from the server that is being queried. This should be done without knowing what is happening “deeper(Optionally,) it should be possible to send code that can be executed on the client side (in many cases JavaScript)
Onboarding EDI vs. API: confronting each other on the data exchange battlefield
In data exchange projects via APIs, you access software allowing you to communicate with business partners in real time. A connection between different systems is established, but it
does not require any user action. Besides real-time connection, API enables constant access to the inventory, and the possibility to send updated data. Its performance depends on the removal of the time required to request and send data.
This means that if you introduce an API, you need to be prepared for the situation when new data formats will not always be supported. Companies introducing APIs often face problems when adding new partners, which requires changes to their ERP systems. As a result, no standard information may be contained in this API to exchange data – which generates a major issue for cost-effectiveness.
Another question arises: do your partners need be connected with their own APIs? There is basically no data standard – neither implemented nor recommended – in the process of creating an API. Here comes another cost driver related to switching to multiple partners via API communication. If an API is not set correctly, even sending a simple document might require taking additional action.
The last thing is that API is not always able to cover the entire supply chain communication process. When your network is developing, the growing number of business partners translates into more systems to combine.
So, combining different APIs and making them compatible or able to communicate requires more resources such as time and money. For this reason, it is difficult to recommend the use of APIs in the majority of data exchange projects.
Meanwhile, integration with EDI has a number of advantages when compared with an API. The first one is the standardized document transfer. Here, there is no need to worry about new data formats that are not always covered by your API. Adding new business partners is simple and requires choosing a communication channel, adding details for that partner’s identification, and… that’s about it. Classic EDI does not involve changes in the ERP systems of business partners – they are originally designed to be connected via protocols described in the previous paragraphs.
Additionally, classic EDI is not only secure (thanks to data encryption and certificates), but it is also simple, having many data standards (such as UN/EDIFACT, ANSI ASC X12, TRADACOMS, VDA, and UBL). The implementation phase is also much less sophisticated, involving no invalid details, formats or fields to be filled out. The protocols ensure the delivery of the sent data by generating easily checkable statuses. What’s more, EDI uses only one method to communicate with your service provider, and one mapping set for each transaction. Although EDI might be a little slower than API, the difference is only a couple of seconds. Last but not least, EDI allows exchange of high data volume – even thousands of documents.
Conclusions: and the Oscar goes to…
API is an advanced tool that opens multiple possibilities. However, when it comes to data exchange and integration of business partners, it has too many catches to be considered the best option. EDI has been commonly used for many years now, and not without reason. It is still the most efficient and universal system for these purposes. Although IT services and solutions are being dynamically developed, data exchange understood as business-related documents and information, is, and will be in the nearest future, dominated by classic EDI (and it is important to remember that it is also available as web EDI).
