Skip to Content
Technical Articles
Author's profile photo Ingo Woesner

Make OAA run with Spartacus UI Framework – A How-to Guide

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 the 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.

 

 

 

Assigned tags

      3 Comments
      You must be Logged on to comment or reply to a post.
      Author's profile photo Stephen Hallinan
      Stephen Hallinan

      how might it be possible without modifying code ?

      Author's profile photo Ingo Woesner
      Ingo Woesner
      Blog Post Author

      Hi Stephen,

      this is the only way as of now. I trust OAA support will hopefully be provided with one of the upcoming releases.

      Ingo

       

      Author's profile photo Markus Perndorfer
      Markus Perndorfer

      Never patch or modify any platform code, including commercewebservices.

      Modifying platform code is universally considered bad practice and will hurt the project in the medium to long term.

      The clean way to achieve the same result is to inject a custom checkout facade that calls the relevant method(s) before the regular processing.

      If you follow Composition-over-Inheritance (you should!), it would look something like this:

      SourcingCheckoutFacade.java

      public class SourcingCheckoutFacade implements CheckoutFacade {
          private final CheckoutFacade standardImplementation
      
          ...
      
          public boolean setPaymentDetails(final String paymentInfoId) {
              if (doSourcingForSessionCart()) {
                  return standardImplementation.setPaymentDetails(paymentInfoId)
              } else {
                  throw new NoCheckoutCartException("sourcing unsuccessful")
              }
          }
          
          ..
      }

      sourcingextension-spring.xml

      <alias name="sourcingCheckoutFacade" alias="checkoutFacade"/>
      <bean id="sourcingCheckoutFacade" class="com.custom.SourcingCheckoutFacade">
          <constructor-arg ref="defaultCheckoutFacade" />
      </bean>