SAP Business Network For Logistics – Carrier Side Integration – API vs EDI
SAP Business Network for Logistics (BN4L) provides capabilities of freight tendering, subcontracting, settlement, tracking and dock appointment scheduling by connecting business partners in the network. By joining the network, a carrier can connect and transact with any shipper on the network. BN4L comes by default with a web portal that our carriers can use to transact with shippers they are collaborating with. Of course, this often means they have to do the “swivel seat” style of integration, meaning manually copying the data from our portal and pasting it into their own systems…not very fun to be sure but not horrible if you only have a small number of transactions. Most carriers I have met would rather get away from this method of “integration” once the transaction numbers start to increase. BN4L provides two options for building integrations – API and EDI. Both have their pros and cons as you will soon read.
- Performance – nothing can beat the speed of a system-to-system API integration. Transactions can flow back and forth between shipper and carrier in a matter of seconds.
- Functional Coverage – Most functionality in the web portal is also supported with APIs with a couple of exceptions. Invoice Disputes and Dock Appointment Scheduling are only available in the web portal. New processes to the industry like quotes/spot bids and external planning are only available for integration with APIs.
- Development Skills Required – APIs require some development and/or robust middleware to implement. On top of that, your own systems must be API enabled to build the integrations. To our SAP customers this might sound trivial, but many carriers are working on older systems that don’t support the latest integration possibilities.
- Takes Time to Implement – building an API integration can take time and requires close collaboration with a shipper who can send test data. A middleware solution can help ease some of this burden, and should be considered, but it will still take time to build a robust API integration. Why does it take a long time? For one, the payloads are large and somewhat complex, it’s not enough to be an API developer, you need to also understand the data and the business process.
- Standards Based – EDI has been around for a long time and is how logistics integrations have operated for decades. There is tons of knowledge in the industry around EDI and even older carrier systems support it. ANSI has defined the North American standard for EDI and after that they helped define the UN/EDIFACT standard used in much of the rest of the world.
- Relatively Easy to Implement – because it is so well known and based on standards it is easier to implement than API. Every carrier I have worked with to date has EDI experts employeed.
- Performance – BN4L EDI uses SFTP and batch jobs to build the integration, and due to this it is much slower than API. What API can do in seconds EDI can do in minutes to hours.
- Functional Coverage – BN4L currently only supports EDI for Road tendering (FTL & LTL – 204, 990, 214, 210 & 997). There is no support for quotes (AKA Spot Bids) with EDI for Road as this process wasn’t around when EDI standards were defined. Ocean booking EDI support will be rolled out slowly this year starting with the 300 in the March 2023 release. Air booking support is planned but not yet on the roadmap.
Above shows our Freight Order APIs and EDI support for Road FTL / LTL.
Things Shippers Should Know and Consider
- Not all carriers can build an API integration even if they wanted to, they just aren’t there yet. EDI is the best many of them can do.
- Most carriers can’t support API integration for quotes/spot bids and will have to use the web portal to respond to these. There are some exceptions – but only the most technically sophisticated carriers can support this.
- The LTL industry by and large will not build API integrations, they will only do EDI. Maybe this will change in the future as API standards for LTL are being worked on.
Things Carriers Should Know and Consider
- EDI is a great place to start for integration, but you should start thinking about how to take the next step to support API integration.
- The speed and functionality over API integration can be a differentiator. New processes that like quotes and external planning are only available for integration over API, and if you don’t invest and move forward you could be left behind. Look at the FinTech industry did to banking, the same thing is already starting to happen with CarrierTech. Make sure to invest in your technology as it truly is the new battle ground for carriers.
- Consider joining a standards body that is defining industry API standards…these will only come about if those with deep industry knowledge make it happen.
When it comes to shipper/carrier integrations EDI has dominated for decades and continues to be the most used integration in the industry, and BN4L will continue to grow its support for it. That said, there is no doubt that a well built API integration can be a differentiator in that it can perform orders of magnitude faster, and newer innovative processes like quotes/spot bids and external planning are only supported for integration over API. Carriers who wisely invest in a technology platform that can integrate over APIs can now and into the future will certainly have advantages over those who can only do EDI.
Great Article Jeff!
Really great insights and experience. Great to see that both API and EDI are available.
Great info, Jeff.