Finding solutions for EDI B2B communication

Let’s take a look at one organization that is facing these issues and how they were able to find a solution.

This business is a large international manufacturer and the problems they were facing are very typical of organizations that use EDI. They had legacy systems, tightly tied to their ERP, that was being used for B2B EDI but supported only a limited number of message standards. It was controlled and gated by central IT teams, so any time changes were needed, a request had to be made to the central IT team and then the project had to be added to the IT project backlog. Because of all of the increasing demands, not just into the EDI messaging systems but across a widening portfolio of initiatives, central IT was becoming increasingly a bottleneck for bringing on new partners, or even making changes to configurations for existing partners. Something needed to happen to streamline the EDI solutions for B2B communication.

The problems worsened to the point that it took more than six months to onboard a new partner. Not only did the delays become a real business pain point, it actually put the go-live date of important business initiatives like new product launches or expanding into new geographical markets at risk. This organization needed to find new solutions for EDI B2B functions like decreasing partner onboarding time and having some of their business analysts in the Line of Business teams to be able to drive some of the partner onboarding tasks, particularly configuration around how partner messages were validated and particularly mapped into other standards. This was a task that the line of business IT teams felt they could handle within their groups and wanted to have the opportunity to do so without having to send the request into central IT.

In order to create an EDI B2B solution that could accommodate the agility that this business needed, they decided to employ an API-led connectivity approach. To understand why this approach was so effective for this business, let’s consider why it's so difficult to onboard new trading partners using EDI.

Organizations have typically solved this problem in terms of thinking about building out the logic to receive and validate and transfer messages as well as what to do with the downstream data in an isolated fashion. For each trading partner a business works with, the EDI messages for onboarding have to be redone each time. A manufacturer, for example, might work with a number of retail partners who are sending in purchase orders and invoices and to whom they want to send purchase orders in return. As this manufacturer expands the number of trading partners, the work that needs to be done to process these messages to work with the downstream requests has to be completed over and over and over again. This has to be done for each business process, which is slow and cumbersome. And, as the number of trading partners has expanded, as well as the number of channels has expanded,  the cost of duplicating the work to onboard partners has increased exponentially. This is what causes the delays in partner onboarding.

An API-led connectivity approach to B2B EDI, however, works on the principle of reuse. API-led connectivity is a platform approach to integration, rather than a point-to-point approach, which separates out the actual message processing concern from the business processing. What we've seen is by separating these concerns, efficiencies can be found in terms of how messages are mapped and then secondly how the underlying data is processed at a business level.

• Experience API layer: Different experience APIs by channel, perhaps e-commerce, or SaaS application, or data interface
• Orchestration API layer: Different process APIs by business process e.g. executing a purchase order, checking inventory level
• Data Access API layer: Different data access APIs to wrap key key systems of record

The architectural benefits of this approach are: a decoupled architecture that abstracts away complexity and a more agile response to change. All of your channels are able to reuse the same process logic, so as you onboard new partners, you only need to manage the logic of receiving messages and the purchase order processing logic is already baked in, thus allowing you to move quicker.

Here’s how it works in an EDI B2B scenario. A set of services might receive EDI messages. There is some processing logic that is specific to the message type and then there's some message processing is specific to the partner itself. There is also some partner specific work that needs to be captured. It is completely separate from the downstream business process logic. As you receive your 850 and you're working with your purchase orders, you are receiving your 810s, you are working with the invoice, how you think about the downstream processing that is extracted and separated.

The idea is to have a single set of flows that can be reused across trading partners, abstracting away the pure partner-specific aspects which, for most organizations, are specific to the mappings of the messages themselves. As you add trading partners, the only incremental work that is now required is that trading partner specific processing as it pertains to message mapping. That means once these foundational elements are in place, the actual act of bringing on trading partners is greatly reduced. Because you've distilled partner specific message mapping in most parts, that's how you can delegate or bring in other teams to drive that work rather than having it being gated through central IT.

It’s this approach that has allowed MuleSoft's customers to significantly reduce trading partner onboarding time. This approach to B2B EDI solutions will allow organizations to deliver on their key strategic business initiatives more quickly and close the IT delivery gap.

Take a look at more resources to learn how an API-led approach to connectivity can help your business create B2B EDI solutions.