Continuing on from our last blog post that saw us answering three of the top frequently asked questions of VL, we present you with three more great FAQs in our part 2 edition!:
- How do I know if my EDI system sucks?
- What are APIs? And,
- How do APIs work?
See the great answers to these questions below!
Q: How do I know if my EDI System sucks?
Here are some tell-tale signs that you should be looking into upgrading your EDI system:
- Your EDI Software only does EDI and runs on a Win 2000 or older PC.
- You use a dial-up modem to communicate to your VAN. What?
- You have no integration to your in-house applications.
- To send outbound invoices and ASNs, someone manually enters all the data into a screen in the software.
- To do EDI someone has to sit and manually invoke the communications and wait for the data to come in and be processed.
- EDI is a full-time job for one or more employees.
- Errors in manually entered data cause charge backs and compliance charges which you can’t fight.
- You are too afraid to upgrade the PC that the EDI system is on because EDI might no longer work and you are not sure you have a backup or the original disks to reinstall.
- You can’t handle any ANSI X12 standard after 4020 – this means your system is well over a decade old and all it can do is EDI.
- You are looking to do custom development on your EDI translator. This is a complicated and expensive route to try and take.
- You have multiple EDI solutions because you bought what you trading partner or testing partner recommended.
- You have an EDI solution bolted on to your ERP package, or any other plug-and-play solution. EDI is not plug-and-play.
- Your translator is so old you installed it using floppy disks. Oh my.
Ultimately the older your system is, the more it hinders your business.
If your EDI system runs on a computer that gets errors like these, it’s probably time to upgrade.
Q: What are APIs?
In the 1990s and 2000s, complex retail supply chains depended on EDI to transact electronic data between themselves and their supply chain partners. Typically partners transacted orders, invoices, and shipment notices in non-real time. EDI was store and forward technology.
Then along came the internet and APIs. As web applications proliferated, the standard of conversing between applications was the API. So what is an API? The computer definition of an API is Application Programming Interface. Think of them as interfaces that allow you to access data in systems in real time. The applications can be on-premise or in the cloud, or both. APIs and the connections between them are the plumbing of the internet of things.
APIs can typically be divided into two categories – public and private. Public facing APIs expose data to the outside world. Private APIs expose data to a protected inside world. APIs are the EDI of the 21st century and beyond.
Q: How do APIs Work?
Well APIs typically have a number of components which make up the API. The first is communications; the second is security and finally the payload, which is the actual data.
So let’s look at the two communications approaches that are widely used today; SOAP and REST. No we are not going to wash up before going to bed. SOAP is the granddaddy of API communication protocols and is defined as Simple Object Access Protocol. It is one piece in the web services stack and is usually paired with application layer protocols like HTTP and SMTP. The other application layers provide the security. The payload is XML. The current SOAP definitions by W3C were last updated in 2007 so some would say SOAP is getting a little long in the tooth.
This brings us to REST. REST stands for Representational State Transfer. What? OK its not that complicated. The concept behind REST is that it uses simpler mechanisms to communicate rather than using more complex mechanisms like SOAP and RPC (Remote Procedure Calls). RESTful applications use HTTP to post, delete and read data. There are four HTTP methods used in REST; GET, POST, PUT and DELETE. Since REST is not a standard there is pretty much anything that can be done with REST. Some have even postulated that the Internet is the largest REST application in the world.
So what is the difference between the two? First is the payload. The SOAP payload is XML whereas the REST payload is XML or JSON or both. JSON is a lighter weight more compact message protocol. The second is the simplicity of the communications layer.
Understanding the nature of the API gives you a clear indication as to the complexity of the integration. Today the API world is moving more and more to REST-based approaches with the flexibility of an XML or JSON payload.
These three questions and the three from our last blog post represent just the top 6 commonly asked questions VL has received over the past 20+ years we’ve been in business. If you are looking for more information on the three questions we answered here, you can read this blog post and this blog post.
Do you have your own questions that you’d like to see VL answer in our blog? You can submit your question in the comments area below, or through any of our Social Media properties.
Want to receive automatic updates when VL posts a new blog?