B2B integration can be intimidating to those who are not familiar with the technology. There are many different standards and lots of intimidating jargon. We will do our best to explain the basics of B2B integration technologies in Plain English. The purpose of B2B integration is to take information out of your business applications and quickly route it into the applications of your business partners (customers, suppliers, banks, logistics providers).
Four basic steps are required to accomplish this.
The purpose of B2B integration is to take information out of your business applications and quickly route it into the applications of your business partners. The first step is to extract the data you want to send to your business partner from the “source system.” However, before we explain how that works, let’s discuss what we mean by source system. For example, a manufacturing company might want to extract a purchase order from its ERP application (the source). A financial institution might want to extract a securities trade from its order management system (the source). A retailer might want to extract a list of recent sales transactions from its point of sale (POS) system (the source).
Each company runs its business using a unique set of software applications. In the manufacturing industry, for example, companies typically use ERP applications to power most of their business operations—human resources, finance, procurement and order fulfillment. But there are many different publishers of ERP software. Oracle, SAP, Infor, Microsoft and Sage are among the most popular.
In the retail sector, many of the same ERP applications are also popular, but the functionality is different. Retailer ERP applications from Oracle, SAP or JDA need to support store operations, merchandising, demand planning, accounting and warehouse management.
In the services sector many specialized application vendors exist for each industry. For example, a financial institution might use SAP or Oracle for its human resources, finance and procurement, but specialized applications from Metavante, S1 or Charles River to support its various product offerings.
Increasingly companies in all industries are using Software as a Service (SaaS) applications running in the cloud. In addition to (or as an alternative to) the traditional enterprise applications listed above, your company may also be using Salesforce.com for customer relationship management; Workday for human resources; NetSuite for finance and accounting; or Concur for expense management.
Now to the important part—how can we get the data out of these applications to send it to business partners?
Each application vendor, whether it offers traditional software or cloud services, offers different ways to extract and insert data. SaaS vendors typically offer an API (application programming interface) that reads, writes or updates database fields tied to their applications. The larger ERP vendors each offer their own middleware applications with their software suites. Examples include SAP’s Process Integrator and Oracle’s Fusion. These types of middleware packages make it easy to send data back and forth to the ERP applications.
Not every software application vendor offers sophisticated APIs or specialized middleware. But almost every vendor does offer a utility to extract data or insert it in bulk—to or from a file system.
So before you can decide on the best way to extract data from your source application(s), you will need to research the options offered by your application vendor(s). Then you will need to connect your B2B integration technology to these source applications through an API, middleware or another utility. However, there is still more work to do before the data can be transmitted to your business partner.
Data can be packaged into different formats. Some formats are standardized so they can be used in applications written by different software vendors. Other formats are proprietary, only to be used by applications from a single vendor. Each business application stores data in its own proprietary format. Step 2 of the process is to convert the data from the proprietary format of the source application into an industry standard.
There are many different standards, but EDI and XML are the two most popular for B2B integration. Industry standards provide a common language that enables all business partners within a particular sector to communicate easily. Have you ever emailed a digital photo to a friend or family member? If so, chances are they were able to view the photograph on their computer without any problem. Reason being, the formats used for digital photographs—GIF, JPEG and TIFF (just to name a few)—are highly standardized. But not all types of data are as standardized as photos.
Have you ever created a file on a Mac and tried to transfer it to a PC? Were you able to open the file? And was it properly formatted? This has become less of a challenge recently as desktop software vendors have moved towards standardized formats. Ten years ago, it was a big problem. And it is still a big problem in the world of business interactions.
To solve these interoperability problems, the technology industry created B2B standards. EDI, created in the 1970s, was the first widely used standard for B2B. XML, introduced in the late 1990s, is another alternative that is steadily gaining adoption. The idea behind the standards is that all companies in a particular industry can share information electronically using a common language. Data from an Oracle ERP system can be extracted in its native format then converted to XML. The XML message can then be transmitted to a community of business partners that each understand XML. Each individual company can convert the XML into the format of its business application—perhaps Microsoft Dynamics.
Although we have been using the terms EDI and XML in the singular form above, there are actually a great number of different standards based upon these two technologies. Originally, different EDI standards were used in each country (US, Germany, France, UK, Japan), but over the years the industry has converged on two primary formats—ANSI X.12 (popular in North America) and EDIFACT (popular in Asia and Europe).The XML standards introduced later were designed for global use, but often within a particular industry. There is RosettaNet for the high tech sector, CIDX for chemicals, SPEC2000 for aerospace, GUSI for consumer products and so on.
Which standard should you choose? Well, actually you may not have a choice. Chances are that your customers will tell you which standards they prefer. You must “map” the data fields from your business application into the corresponding fields of the industry standard (e.g., EDI, XML) that you choose. Each time a message is sent to or received from your customer it will be “translated” into the appropriate format.
The good news is that you can tell your vendors which standard you prefer. And they will have to perform the necessary mapping and translation to do business with you.
Now that the payload is in the appropriate format, you are ready for Step 3—transmission of the data to your business partner.
There are many different Internet protocols that are able to transmit messages (payloads) between companies. The available protocols offer a range of choices to meet different performance and security needs. One way to think about the different options is to compare them to the options offered by the postal service for sending a piece of physical mail. You could send a postcard, which is very inexpensive but offers no privacy, as anyone who encounters it can read the contents. You could enclose the contents in an envelope. But envelopes can be easily opened by anyone handling them. Furthermore the envelope could be accidentally misrouted to the wrong address. Would you put a check for $10,000 in a plain envelope and send it via the postal service? If the contents of your letter were sensitive or critical you might want to receive delivery confirmation. The confirmation might be passive in the form of being able to track the location on a website. Or, the confirmation might be more active, such as a proof of delivery that is sent to you.
Some contents are too large to stuff in an envelope. Instead, a box might be required. If the contents were valuable you might want to secure the interior with special packaging. Furthermore, you might want to insure the package, which would provide financial compensation if it was damaged, lost or stolen.
A long list of network protocols such as AS1, AS2, AS3, AS4, FTP, FTP/S, S/FTP, OFTP, HTTPS, MQ and EBICS are available to support B2B integration. Each of these offers a different combination of security, performance and reliability to appeal to different users.AS1, for example, is a protocol based upon the SMTP (Simple Mail Transport Protocol) that is used for email transmissions. AS1 enables users to take an EDI or XML document and stuff it into an email before sending it across the Internet. AS2, is another protocol that is based upon HTTP (Hyper-Text Transfer Protocol). HTTP is the protocol used to transmit website content such as HTML and images between the browser on your computer and the web server hosted in a remote data center. AS2 enables users to take an EDI or XML document and stuff it into a web page format before sending it across the Internet.
Which transport protocol should you choose? Again, much as with the payload you may not have a choice. Your customers may dictate which protocol (e.g., AS2, FTP) you must use to send data. To accomplish this you will need to ensure that the B2B integration technology you are using supports the transport protocols your customers wish to communicate in.
Again, the good news is that you can tell your vendors exactly which transport protocol they must communicate in.
The final step in the B2B integration process is for your business partner to receive and process the data you send to them.
Big companies can receive EDI or XML messages via AS2, FTP or MQ. Once received, your business partners can convert the messages into the proprietary format of their own business application. Smaller companies are generally not equipped to accept EDI or XML messages. Instead, the smaller organizations prefer that the data be posted onto a web page or sent via an email. These methods allow the smaller company to easily digest the data and feed it into their own internal systems.
Your larger business partners most likely have sophisticated IT systems that include B2B integration capabilities. Therefore, these larger organizations should be well prepared to connect and exchange using a variety of network protocols (AS2, FTP, MQ) and payload formats (EDI, XML).
Connectivity to these partners should be relatively easy. You do not need to be too concerned with which applications your partners are running. They will handle the details of translating the data into their preferred format and inserting the information into their applications. Once you agree upon an approach with these partners you will simply need to perform some basic testing to ensure everything is working correctly.
You may have many smaller business partners as well. These smaller organizations often lack the budget, resources and expertise necessary to implement B2B integration technologies. They are not equipped to send or receive messages in EDI and XML transmitted over AS2, FTP or MQ. As a result, a different approach is required for these smaller companies.
The most popular way to get data to and from small businesses is via a web portal. Instead of sending the data via AS2, FTP or MQ, the information is captured and posted to a secure website. Your business partner can login to create and send or receive and download electronic messages from you. By using this approach, small companies do not need to purchase and manage B2B integration software.
A number of other approaches are available for sharing information with small companies. Technology exists to convert EDI and XML messages into faxes and emails. A growing number of technologies are able to integrate with small business accounting packages such as QuickBooks, Sage or Peachtree. A button can be added to the accounting package that allows a user to download all of their purchase orders or upload all of their invoices. B2B integration technologies are utilized in the background, but the process is transparent to the user.
Before you can move forward with any of the four steps above to exchange data with your business partners, you need to purchase the appropriate B2B integration technology. The B2B technology will collect data from source applications, translate the data into standardized payload formats and then send the documents to the business partner using the appropriate transport protocol.
Historically, companies would license B2B integration software to run in their corporate data centers. However, as cloud computing has become more popular, an increasing number of organizations are utilizing hosted integration services for B2B. The basic features of B2B integration are similar whether you choose to manage software in-house or utilize cloud services.
In this section we will refer to the technology—whether it is software or cloud-based—as a B2B integration platform.
Transport Protocols—Integration platforms typically come with a library of communications adapters that support all the popular Internet transport protocols—AS2, FTP, MQ and others. Of course, it is important to ensure that the platform you are choosing supports all the transport protocols that your customers and vendors require.
Application Integration—Integration platforms also include adapters to import and export data from popular enterprise applications such as SAP, Oracle, Infor and Microsoft Dynamics. As SaaS applications have become more popular, libraries of adapters for Salesforce.com, NetSuite, Workday and other cloud services have become available. Of course, the list of adapters that you will require will vary based upon the applications you use.
Mapping and Translation—A critical component of an integration platform is the translation server. The translator converts documents from one format to another. For example, an SAP iDoc can be converted into RosettaNet XML. An ANSI X.12 EDI transaction could be converted into a Microsoft Excel spreadsheet. Before the translation can occur, the data fields of the source and target must be “mapped” to one another. Mapping software allows you to visualize the data fields and create the relationships between the two documents.
Tracking and Reporting—If you are sending hundreds or thousands of messages a day to various business partners, it is critical that you be able to track the status of each. Reporting features of integration platforms will ensure that you can identify which messages transmitted, which are in process, and which failed due to errors.
Additional Features—B2B integration platforms can come with a wide variety of additional options, some of which may be appropriate for your needs. For example, you may want encryption capabilities to protect sensitive financial data during transmission. You may want compression capabilities to enable big files can be sent faster. You may want data validation capabilities that can apply business rules to the information you are sending to identify any errors.
Ready to get started?