BabelPartSDK

BabelPart Enterprise Integration Overview

The Neumonics BabelPart SDK and suite of plugins provide a means of connecting selling systems (traditionally Warehouse Distributors or Manufacturers in the Automotive Vertical) to one or more buying systems for the purpose of conducting electronic commerce.

At The Core…

A BabelPart Integration consists of a 3 components

  • A copy of the BabelPart SDK residing either customer premise or in the Neumonics Cloud
  • A BabelPart Selling System Connector connecting the BabelPartSDK Sellers warehouse system
  • 1 or more Buying System Plugins providing order flow through the BabelPartSDK

The BabelPartSDK, Selling System Connectors and Buying System Plugins are licensed by Neumonics to the Seller on a per server. Associated monthly support and licensing fees assure that all plugins are kept current to the provider’s latest specifications.

What exactly is a plugin…

Plugins are BabelPart components that translate various methods of buying and selling Automotive parts into common BabelPart objects so that different buying and selling systems can be connected.

Seller PluginBuyer Plugin
Generally speaking a Seller (Warehouse Distributor/Manufacturer) will have a single Selling System. For example SAP system such as S/4HANA Epicor Vision system Custom AS400 solution. Even with out of the box solutions, customization may be required to handle such things as Order Routing Freight Calculation Order HistoryMost Seller license include more than 1 Buyer Plugin. For example, a seller may do business with buyers using a variety of systems including NexPart E-Commerce partner using IPO eBay JMS system using BabelPartXML Each of these plugins are built and maintained by Neumonics to the supplier’s latest specifications

What is currently available ….

Currently, Neumonics offers connectivity with the most popular buying protocols and specifications.

The diagram below shows all of the currently licensed Buyer and Seller plugins offered by Neumonics

BabelPartSDK interactions with Buyers occur in 3 ways

Buyer sends requests to a BabelPartSDK Buyer PluginA Neumonics Gateway Product must initiate communication with Buying System APIBuyer deposits a batch file to be processed at a scheduled interval
The Buying system connects to the BabelPartSDK Buyer Plugin. This is similar to a user making a request from a web browser to a web server. The BabelPartSDK instance can reside either customer premise or in the Neumonics Cloud.The second interaction is more complicated. These occur when the buying forces the seller to reach out to their systems for E-Commerce related data. For these relationships, a Neumonics Software as a Service solution resides in the Neumonics cloud making scheduled requests to the Buying Systems API. Those requests are then translated into BabelPartXML and sent to the BabelPartXML plugin on the Seller’s BabelPartSDK integration. Amazon and eBay are common examples of this interaction.The third scenario is a remnant of early forms of batch E-Commerce. Systems may use protocols such as FTP or AS2 to drop files for scheduled processing. These types of orders are handled through Neumonics Async Order Processor Software as a Service solution hosted in the Neumonics cloud. The Async Order Processor converts the orders into BabelPartXML orders and forwards them to the BabelPartXML plugin on the Seller’s BabelPartSDK integration. Transnet and CSV are common examples of this type of transaction.

What surprises can be expected…

Although Neumonics strives to make Buyer and Seller interactions as simple as possible, nothing is ever as straight forward as it seems. The following table outlines common challenges that cannot be addressed by the Buyer or Seller Plugins

  • Buying System may require information not directly available by the Seller System
    For Example
    • Selling system cannot provide order history
    • Selling system does not allow Buyer to select warehouses
    • Selling system cannot route orders to closest warehouse
  • Selling System may utilize 3rd party components not native to Seller System Plugin
    For Example
    • Selling system uses a third party shipping solution
    • Selling system uses a third party pricing tool
    • Anticipated inventory, movement codes, and line translation stored offline in spreadsheets
  • Buying Systems may require scheduled data exports
    For Example
    • Amazon and eBay both require a number of custom inventory pricing and inventory feeds. Although the Neumonics Amazon and eBay Gateway solutions can post these files, the data must be made available by the Seller System in a usable format and timely manner
    • E-Commerce partners may require daily full and hourly incremental feeds to keep their websites current. Although BabelPartXML Buying Partners can read the standard BabelPart Inventory Feed, the data must be made available by the Seller System in a usable format and timely manner
  • Compatibility issues with Open Protocols used by Buyer Systems
    For Example
    • IPO (Internet Parts Ordering) doesn’t natively support Buyer branch selection so Buyer System have made their own adaptations to support it
    • IPO (Internet Parts Ordering) has a variety of locations to store an order number. Buyer System use different fields to denote a transaction, order, and confirmation number
    • EDI implemented by Buyers rarely store the part number and line code in a similar manner
    • EDI requirements for Buyers differ greatly. Some do or do not require 855, 856, or 997 documents.

What’s Next ….

Once a decision has been made to move forward the Seller needs to make a few decisions. These decision will determine how much, if any customization needs to be made at the Seller Connector level by Neumonics or at the Seller System by either the Seller or in collaboration with Neumonics.

A good jumping off point would be to determine what Buying systems require connectivity and what limitations the Seller System has.

© 2024 ·

Neumonics