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

Make OAA run with Spartacus UI Framework in SAP Commerce Cloud versions lower than 2105 – 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 former template based B2C accelerator.

The SAP Commerce Cloud, Integration extension Pack 2108 and higher supports the integration of SAP Retail’s Omnichannel Article Availability and Sourcing (aka OAA) with the Spartacus storefront.

Before 2108 however, OAA is only supported by the B2C Accelerator, not by the Spartacus UI.

Please note:

SAP Commerce Cloud, Integration Extension Pack’s have their own release numbers. An Integration Extension Pack supports a dedicated Commerce Core release, which has its own release number as well.

However, for projects using a Commerce Core release lower than release 2105 there is an easy way to make OAA run with Spartacus on project basis.

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,

Dr. Ingo Woesner
Product Manager
SAP Customer Experience


Problem description

We have noticed that OAA (Omnichannel Article Availability) part in retail integration doesn’t work in an Spartacus / OCC setup with the Integration Extension Pack below 2108.

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.



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.


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.



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:



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

      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.



      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:

      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")


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