Leaders from Object Edge will be presenting the Pre-Conference session as well as several breakout sessions at CommercePros Insight 19 in Austin, Texas, August 26-28. One of the sessions will focus on a recent project our development team tackled to create a B2B framework to support complex B2B scenarios using Oracle Commerce Cloud and other Oracle only solutions. The goal for such an exercise are: increase interoperability, harmonize stack, minimize procurement challenges, and leverage inbuilt connectivity between products.
Can you briefly describe what it is that you're doing and what's the purpose of it?
This project is really a POC of sorts. A deliverable would be working model given some assumptions. But the goal of the project is to build a B2B framework to support complex B2B scenarios. And the use case scenarios will involve products from multiple disciplines of software systems such as, CRM, ERP, eCommerce. Those are basically three types of key areas. And we would build a generic front-end to support specific use cases, which would be configurable to work with multiple server-sides up front.
Is the goal to show how these different systems can work together? Could you describe a little bit more what systems you're actually connecting?
In the first iteration, it will be the front-end system, which we're going to build from scratch that's based on React technology. On the backend, we're going to use Oracle Stack and it includes OCC B2B eCommerce suite, CPQ and PDH.
Could you explain the architecture and how you're connecting all these different systems?
We're using React Redux and have written a mapping framework to work with from React and is currently completely front-end based.
How are the Oracle systems communicating with one another?
They're communicating using native APIs. Although we do have a mapping framework that we have used on one of the projects which we may utilize as well for a more general solution, currently, we use a native front-end.
So overall we're leveraging native Oracle adapters to connect these four really different components, a headless front-end and built with React, connecting to the backend leveraging Redux, and we've got these three systems, a commerce system, a Configure Price Quote system, and a PIM.
Can you explain why you chose these three systems? Are they the most common systems that you need while launching a B2B commerce site or was there another reason why you chose these three?
For this POC we could have skipped CPQ, but for a scenario comprising of of of complex scenarios such as what we’re trying to accomplish, you need something like CPQ. And we had previous experience in CPQ and have some expertise in that as well. And actually, the same thing with the other tools because to build something in a short period of time, you need some level of familiarity. Right? So those are the tools we've used and actually, you know, we are happy with them.
Could you give some examples of the user stories that this POC will encompass?
There's a classic B2C type scenario that is essentially the buy flow. In the B2B scenario, it's very similar to B2C in this sense except for the pricing. You may have complex pricing configurations. So CPQ would be required for configuring complex products. And in terms of the PDH, unlike B2C where oftentimes your eCommerce server is the system of record, in this case, the ERP system will be the system of record for all product information.
So we definitely need to support the scenario where we get the catalog from an external ERP system. That's basically it for the demo. Going forward, we would also want one of the use cases to also support account management, which includes the organization’s profiles and contracts. Which OCC B2B supports very nicely.
I would imagine that a big reason a lot of B2B companies that want to go on this journey, decide to use a PIM because the ERP system that they're leveraging does not support the capabilities of managing proper taxonomies, category hierarchies, and all the different attributes (like descriptions for content).
This makes sense because historically B2B companies that have sold through physical channels haven't needed to have all that rich content for their products; images, for example, and so they're putting it into a PIM.
Would you ever see a scenario where people wouldn't need a PIM if they're doing eCommerce for the first time? Or are there some reasons why people would still take a catalog from an ERP?
Well, a lot of times it's mostly because they already have it. It's a legacy scenario. If you're building from scratch, I can see that probably you may not need it, but since most already have a system of record, it's easier just to try and use the ERP (though not my recommendation). I think in the typical B2B scenario, you would need to support that integration [to an ERP].
How many different flows are you supporting in your POC?
Six major flows.
So an example of a flow would be a buy flow. For instance: log in, adding to cart, and checking out are that flow, right?
Correct. And then there is a flow, for example, to create an account or edit user or change organization profiles.
From pure development timeframe, how long will the POC take from beginning to end with three developers?
Two months. To build the React front-end, connect it to OCC connect it to CPQ, connect it to PDH. We are also building it in a way which is extendible, not a one-off thing.
Overall, what do you hope to accomplish with this POC? What are you hoping to show or prove or showcase with building out this demo so quickly?
I think that the proof that this is successful or not will really be when we build on top of it. When we try to add another, for example, sibling implementation to another vendor or another ERP or another inventory or some other system. And if we integrate, for example, a CRM system with this.
So ultimately, the proof of how successful it is depends on how easy it is to extend to other systems. Our goal is to add those buy flows.
Could you talk to the hardcore computer scientists about if there are any real benefits that you've seen working with these cloud-based rest APIs? And compare and contrast working on ATG to some of these cloud-based systems like OCC.
It's a trade-off. Obviously, it's much easier for the common use cases. It's much more simple to connect. And ATG is a complex system. If you use it as an on-prem system, there’s a lot of complexity there. So for common cases, there is no comparison. It's much faster and much easier to integrate. The devil is usually is in the details, right. So it's 5% that does not fit your scenario.
Then in some cases, you need to provide kind of glue to handle those exceptions. At least for a mid-size market when the volume is not as high and you don't need that much custom tuning at least 3DG. For other things, CRM for example, there are fantastic cloud-based systems that there's nothing like this existed 15 years ago.
What about the challenges? Any challenges that you experienced in this two month POC and connecting these systems?
It has been pretty smooth. Partly because we have done similar integrations in the past. So on the server-side, that has been smooth. Of course, the challenge is to make it configurable so that for new scenarios, for new vendors, for example, you would not need any programming involved. That's always the tricky part. To make it plug-and-play in a true sense. So you configure, let non-technical users do the connections and all that. And it's one of the scenarios that work in 95% of the cases. It's that five percent that always gives you a headache.
Are there any closing comments you'd like to make? Describe where you think this technology is going. How companies that are going down this path for the first time can best leverage these types of POCs or thought-leadership that companies like Object Edge are providing.
I think it's exciting where this is going. B2B presents unique challenges that B2C does not have to deal with. There is a rich legacy ecosystem. And for a lot of companies, the ERP will be the king. There are some companies for which, CRM is the king. And then there might be 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!