Recently several of 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 is a sneak peek!
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.
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.
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.
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.
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
In two months, we have leveraged a team of three people to connect three very different components:
As for the real benefits that we've seen working with these cloud-based rest APIs, it is actually faster to connect these systems.
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.
