Dear Retail community,

Many retailers are implementing SAP Commerce Cloud along with the new Spartacus UX java script-based Framework, which offers huge advantages over the “old” template based B2C accelerator.

However, the integration of SAP Retail’s Omnichannel Article Availability and Sourcing (aka OAA) is not yet supported by the Spartacus storefront, only by the B2C Accelerator.

For projects who want to benefit from OAA along with Spartacus, there is an easy way to make it run on project basis, see below.

This developer guide was recently created out of a customer project. Please note SAP cannot provide any kind of support for this procedure.  

Best regards,

Ingo

Dr. Ingo Woesner
Product Manager
SAP Customer Experience
SAP SE

****************************

Problem description

We have noticed that OAA (Omnichannel Article Availability) part in retail integration doesn’t work in an Spartacus / OCC setup.

From a frontend perspective, everything works without noticing that no OAA calls are performed, but, once the order is placed, the business process which fires is failing due to errors related to missing fields.

This is the exception you’ll get.

RCA

At this point you may think the problem is in the order process, but it’s not. The order process is correctly trying to retrieve the sapSource model. The issue arises because during checkout process in the fronted, this field was not correctly set, but why? Why the sourcing results are not persisted? Continue reading to know why.

Digging into the code, you’ll notice that persisting sourcing results is done several times in the checkout process. The method responsible is doSourcingForSessionCart

Calls to this method are performed in different steps, all using some validators:

Those validators are defined in the sapoaaaddon extension, and this addon of course will be part of your extension set.

But, and here comes the key part, those validators are never used when you are using a Spartacus / OCC setup.

Why?

If you look into the spring files and java code, you’ll see that those validators are used by one façade extending defaultAcceleratorCheckoutFacade:

But when using the OCC layer, the acceleratorCheckoutFacade is not used. This façade is designed only for legacy accelerators.

So basically, what is happening here is that no OAA calls are performed during the checkout process as the code injection to do sync calls to the OAA backend are not present. And obviously if not calls are fired, no results are persisted.

Solution

The solution is quite simple. As you can imagine, the way to solve it is to find the right place in the different OCC calls to inject those calls to the OAA backend.

The simplest way (could be you find better ones) is to customize a couple of controllers and some methods inside them to perform the same calls that are done in the sapoaaadon validators. Please, consider that the place where you need to perform those changes may be different based on your own extensions and customizations.

As an example, we would like to call the OAA backend when setting payment details. So for this, we should customize the BaseCommerceController. setPaymentDetailsInternal from:

To  

We have identified 4 different methods where this change needs to be done (All in BaseCommerceController class):

• setPaymentDetailsInternal
• setCartDeliveryAddressInternal
• setCartDeliveryModeInternal
• addPaymentDetailsInternal

As said before, be aware that depending on your implementation and OCC calls this may differ, but he way to solve it will be the same as explained above.

Once those changes are deployed, OAA calls are performed in the same way as with the accelerator façade and results are persisted, so the order process will proceed with no errors.