Our development team was challenged to create a B2B framework to support complex B2B scenarios using only Oracle solutions - starting with Oracle Commerce Cloud. This article is a preview of the journey and the results that will be shared at CommercePros Insight 19.
Building a B2B Framework to Support Complex B2B Scenarios
The purpose of the project was a proof of concept - could we develop a working model that involved products from multiple vendors, CRM, ERP, and eCommerce? From that, could we then build a generic front end that would support a set of use cases, configurable to work with multiple server-sides upfront.
We’ll know that we’ve seen success if we can build on this stack - for example, a sibling implementation to another vendor, ERP, inventory, or CRM system. The proof of this framework’s success is in how easy it is to extend to other systems.
Starting with a B2B Front End System
In the first iteration, this framework will be the front-end system, built from scratch on Reach technology. On the backend, we're using Oracle Stack that includes Oracle Commerce Cloud, Oracle CPQ (Oracle Configure Price Quote), and PDH (Oracle Product Data Hub) which is a PIM. React Redux is the architecture to connect the different systems and where we’ve written a mapping framework. Currently, it’s completely front end-based.
Native APIs for Systems Communication
Currently, we’re using a native front end and the Oracle systems communicate using native APIs. Oracle provides APIs from each product. For adapters where CPQ can pass data to OCC (and vice versa) we chose to leverage the native Oracle adapters.
Why this configuration?
For this proof of concept, we could have chosen not to use CPQ. However, for complex pricing scenarios, you need a solution with CPQ-like capabilities. We chose it based on our past experience and expertise in CPQ.
Given the short timeline and limited resources for this project, we developed with tools we are very familiar with. We knew that these tools would satisfy the user stories. For example, one use case would include the B2B buy flow. That includes complex pricing configurations (requiring CPQ). For the PDH, the external ERP system would be the system of record, so we will include support for this scenario. Moving forward, we will also develop a use case that supports account management, including profiles and contracts, which OCC B2B supports very nicely.
"B2B presents unique challenges.... For a lot of companies, the ERP will be the king. For some companies, CRM is the king. And then there are some companies for which eCommerce is a king. And to be able to handle all of these scenarios, providing some kind of integration glue, it's exciting. If we can make progress in helping our customers with that, that would be awesome!" -- Igor Abramovich, CTO and Project Architect for the Oracle Stack Showcase
Two Months, Three People, Three Components
In two months, we have leveraged a team of three people to connect three very different components:
- An eCommerce system, a Configure Price Quote system, and a PIM
- A headless front-end built with React
- And connected it to the backend leveraging Redux.
As for the real benefits that we've seen working with these cloud-based rest APIs, it is actually faster to connect these systems.
What We’ve Learned
As Oracle ATG experts, we have been able to compare and contrast working on ATG and OCC. What we’ve found: it's a trade-off. OCC is much easier to use for the common use cases; it’s much more simple to connect. ATG is a complex system on-premise system, there’s a lot of complexity to navigate. For common use cases, OCC is much faster and much easier to integrate. However, for the 5% that does not fit the simple scenario, that’s when we can get creative. In those cases, Object Edge can provide a kind of glue to handle the exceptions to the rules.