True integration vs. middleware
For manufacturers in search of an enterprise-class e-commerce platform, one question looms large: how is e-commerce going to interact with your ERP system? Specifically, you need to determine how e-commerce is going to modify your ERP data, and how your ERP data is going to display in e-commerce.
Believe it or not, when it comes to answering this question, there are only two broad buckets:
- Direct real-time integration (like Corevist Commerce)—Only 2 systems total: ERP and e-commerce.
- Middleware solution—3 systems total: ERP, middleware, and e-commerce.
In the case of middleware, there are two important sub-classes depending on when the data moves between e-commerce and the ERP.
- Middleware solution
- Real-time middleware solution
- Batch update middleware solution
The question of e-commerce architecture isn’t something you can save for the end of the discovery process. Rather, you should be fully informed on what each type of solution offers before you start evaluating e-commerce solutions. That way, you can choose the solution architecture that meets the needs of your customers.
Here’s a side-by-side comparison of batch update middleware, real-time middleware, and direct real-time integration like Corevist Commerce.
Understanding the infographic
Display accurate data from SAP?
Accurate contract pricing is fairly simple to maintain in all 3 types of solutions. However, when it comes to quantity-scaled pricing, the business rules get more complicated. In a middleware architecture, those pricing rules will need to be rebuilt in the middleware solution. Since we can’t say whether all middleware solutions provide this functionality (or provide it with reasonable reliability at a reasonable cost), we’ve given it a Y/N.
Everything else in this category depends on a real-time integration to SAP. Since it doesn’t read SAP in real time, batch-based middleware can’t provide real-time inventory, customer credit standing, order status, or error messages from SAP.
Real-time middleware can provide it—with a caveat: because there’s a 3rd system in play (the middleware solution), that’s one more place where things can go wrong.
Direct real-time integration like Corevist Commerce queries SAP in real time. There is no middleware; rather, SAP data is displayed directly in e-commerce. That means when a customer logs in and views pricing, inventory, account credit status, and more, they’re looking at live data loaded straight from SAP.
Write accurate data to SAP?
Here’s one area where batch-update middleware can’t really deliver. Obviously, this type of solution can’t post orders to SAP in real time or check for order errors. That means every order a customer places can contain errors which won’t come to your team’s attention until the batch update runs. This isn’t a significant problem for small operations, but it doesn’t scale up well because it requires manual intervention from Customer Service Reps to correct those errors.
You might think real-time middleware eliminates this issue. However, real-time middleware also can’t guarantee 100% error-free order posting. Since business rules must be maintained in 2 places (ERP and middleware), there’s a greater chance of something breaking and the 3 systems being unable to communicate. In that case, it doesn’t make much difference whether your middleware solution is real-time or batch.
Direct real-time integration like Corevist overcomes these issues. Because Corevist Commerce plugs directly into SAP, it queries SAP in real time for order errors. If SAP returns any errors, Corevist displays those in e-commerce so the user can fix them. In fact, Corevist Commerce won’t allow an order with errors to post to SAP. With those SAP error messages, the user is empowered to fix their order and then place it.
Static SAP business rules enforced in e-commerce?
Here’s one area where all 3 solution architectures mostly deliver. We say “mostly” because there is a caveat: since these business rules have to be rebuilt in both kinds of middleware, any change to those business rules in SAP requires the same changes to be maintained in the middleware solution. Since middleware is a duplicate system, it means duplicate work, managing one set of business rules in two places. Before embarking down the middleware path, you should determine if that double maintenance is feasible for your IT department.
Does the solution prevent communication errors?
Here’s the fundamental flaw in any middleware architecture. With a 3rd system sitting between ERP and e-commerce, all kinds of errors become possible which simply don’t happen in a direct, real-time integration like Corevist.
Does the solution prevent business errors?
In addition to communication errors, middleware architecture also makes business errors possible. With business rules maintained in two places (middleware and the ERP), there’s a greater likelihood of the systems not agreeing when you update SKU attributes in the ERP.
Moving forward: FREE case study
If you’re wondering what direct, real-time e-commerce integration looks like, download this FREE case study on Mannington Mills. This leading manufacturer of flooring materials launched Corevist Commerce with real-time SAP integration and saw 150% sales growth in the digital channel.
FREE Case study: 150% Sales Growth with Rich Content
Talk to us