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.
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
SAP SE
****************************
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.
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.
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):
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.
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
SAP SE
****************************
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.
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.
- SAP Managed Tags:
3 Comments
| User | Count |
|---|---|
| 4 | |
| 3 | |
| 2 | |
| 2 | |
| 2 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 |
