Composable Storefront provides a flexible and customizable checkout feature that allows businesses to tailor their online checkout process to meet their specific needs, improving user satisfaction and potentially increasing sales. This includes the ability to add, remove, or modify steps in the checkout process, as well as customize the layout, content, and functionality of each step.
In this post, i will give you a step-by-step demonstration about how to customize multi-step checkout process by adding a new step. Before we dive into the implementation details, it's necessary to understand current checkout flow internal mechanism.
The default checkout implementation includes two parts: on the one hand, Composable Storefront is responsible for providing view and redirecting logic; on the other hand, Sap Commerce Cloud will implement concrete processing logic, define basic page layout and content for each checkout step. So we will talk about checkout mechanism from two aspects:
As user access the checkout flow from either other components (such as checkout button in the shopping cart page) or specific checkout flow step (such as back or continue button in delivery mode page):
if the route path is checkout, CheckoutGuard will be invoked, which will redirect the checkout access to the first step of checkout flow by CheckoutStepService. This is just the reason why all outer link to checkout flow will use this general checkout route.
otherwise, CheckoutStepService.next() or CheckoutStepService.back() method will be invoked to load the next or previous page for current checkout step, internally, CheckoutStepService needs two configurations and delegates RoutingService to load related page.
RoutesConfig is responsible for setting the relationship between the route path and related page. Since each page in checkout flow is content page, related contract must be followed, i.e., the path must match the page label in corresponding CMS page based on Composable Storefront Routing Mechanism,
CheckoutConfig will be used to define the order of the steps and schematics page for each page
Once Sap Commerce Cloud returns page meta data, related view for specific checkout step will be rendered by Composable Storefront
Apparently, the core for checkout feature in Composable Storefront includes CheckoutStepService, CheckoutConfig and RoutesConfig.
Each checkout step page is based on the same page template 'MultiStepCheckoutSummaryPageTemplate', most of the content of each page is the same, just as illustrated by the following diagram:
Each checkout step page includes two parts: BodyContent slot and SideContent slot
SideContent slot contains just one component: Checkout OrderSummary Component, which is used to provide basic order information
BodyContent includes several components
Checkout Progress Component, Checkout Progress Mobile Top Component and Checkout Progress Mobile Bottom Component are used to indicate current step in the whole checkout flow.
Specific component for current step, which is used to show main content for current step.
Furthermore, Sap Commerce Cloud also defines master data, related controller, facades and services in order to support checkout feature
CartModel and OrderModel is the master data for checkout feature, which contains all meta info about current order, such as delivery mode, delivery address, payment info, etc.
a list of related OCC controller, facades and services, which follows the classic invocation flow in Sap Commerce Cloud. For example, during delivery mode step in checkout flow, CartDeliveryModesController will receive request from Composable Storefront, then it will delegate the request to DefaultCheckoutFacade, which will finally invoke DefaultCommerceCheckoutService to set delivery model to current cart.
From the above analysis, it's easy to see that the following work are necessary in order to customize a new step in checkout flow:
Define new route for new step
Define the order of this new step in CheckoutConfig
Create a new Angular component to provide view for the new created step
Create related CMS page and CMS component
Modify SAP Commerce type system to support configuration for new created step if necessary, i.e. extending current CartModel and OrderModel with new attributes
Develop new OCC controller/facade, extend CommerceCheckoutService to apply configuration for new created step.
In the following section, I will demonstrate how to add a new step "Additional Option" in the checkout flow, for simplicity, we will assume that the new step will not do any configuration in the CartModel and OrderModel, in other words, we need not any work for step 5 & 6.
provideConfig({
routing: {
routes: {
checkoutAdditionalOption: {
paths: ['checkout/additional-option']
}
},
},
}),
provideConfig({
checkout: {
steps: [
{
id: 'deliveryAddress',
name: 'checkoutProgress.deliveryAddress',
routeName: 'checkoutDeliveryAddress',
type: [CheckoutStepType.DELIVERY_ADDRESS],
},
{
id: 'deliveryMode',
name: 'checkoutProgress.deliveryMode',
routeName: 'checkoutDeliveryMode',
type: [CheckoutStepType.DELIVERY_MODE],
},
{
id: 'additionalOption',
name: 'checkoutProgress.additionalOption',
routeName: 'checkoutAdditionalOption',
type: [],
},
{
id: 'paymentDetails',
name: 'checkoutProgress.paymentDetails',
routeName: 'checkoutPaymentDetails',
type: [CheckoutStepType.PAYMENT_DETAILS],
},
{
id: 'reviewOrder',
name: 'checkoutProgress.reviewOrder',
routeName: 'checkoutReviewOrder',
type: [CheckoutStepType.REVIEW_ORDER],
},
]
},
}),
Apparently, 'additionalOption' step is after 'deliveryMode' step and before 'paymentDetails' step.
....
@Component({
selector: 'cx-additional-option',
templateUrl: './checkout-additional-option.component.html',
styleUrl: './checkout-additional-option.component.scss'
})
export class CheckoutAdditionalOptionComponent {
backBtnText = this.checkoutStepService.getBackBntText(this.activatedRoute);
constructor(
protected activatedRoute: ActivatedRoute,
protected checkoutStepService: CheckoutStepService,
) {}
next(): void {
this.checkoutStepService.next(this.activatedRoute);
}
back(): void {
this.checkoutStepService.back(this.activatedRoute);
}
}
The most important methods we need to implement is next() and back() method, which will invoke CheckoutStepService to drive to next or back step of the whole checkout flow.
<input role="radio" type="radio"/>
<h3>Is your order to be packaged?</h3>
<div class="row cx-checkout-btns">
<div class="col-md-12 col-lg-6">
<button class="btn btn-block btn-secondary" (click)="back()">
{{ backBtnText | cxTranslate }}
</button>
</div>
<div class="col-md-12 col-lg-6">
<button
class="btn btn-block btn-primary"
(click)="next()"
>
{{ 'common.continue' | cxTranslate }}
</button>
</div>
</div>
In addition to the specific UI elements for current step, we also need to define Back and Continue button, which will delegate to back() and next() method in checkout-additional-option.component.ts once on clicking.
We need to provide a meaningful localized message for new created step 'addtionalOption', which is shown in Checkout Progress Component
....
export const translationCheckout = {
en: {
checkout:{
checkoutProgress:{
additionalOption: "Product Package",
}
}
}
};
....
provideConfig(<I18nConfig>{
i18n: {
resources: translationCheckout,
},
}),
....
For this new defined Angular Component, there is also a corresponding CMS component, after all, checkout flow is CMS driven.
Please note, every major CMS component for each default checkout step page is of type CMSFlexComponent, it means this CMS component is only used as a placeholder and corresponding angular component doesn't any data from CMS.
I will also follow the same philosophy, i.e. the related CMS Component is also of type CMSFlexComponent, which flexType will be used to setup the mapping. suppose the flexType is CheckoutAdditionalOption, so the mapping is defined as follows:
provideConfig(<CmsConfig>{
cmsComponents: {
CheckoutAdditionalOption: {
component: CheckoutAdditionalOptionComponent,
guards: [CheckoutAuthGuard, CartNotEmptyGuard],
},
},
}),
Here, we will use CheckoutAuthGuard and CartNotEmptyGuard to make sure this new step can be enabled only only user has logged in and his/her shopping cart is not empty.
In the next step, we will create a CMSFlexComponent instance and set its flex type to CheckoutAdditionalOption.
Finally create related CMS page and component in Sap Commerce Cloud, we can do it in Backoffice.
It's time to verify our work, first startup Sap Commerce Server and Composable Storefront respectively, then register a new user, add some products in the shopping cart, then go to checkout flow:
As I click Back button, it will go to delivery mode step, as i click Continue button, it will go to Payment step, it can work now!
In this post, i analyze the basic mechanism of SAP Composable Storefront checkout feature, then give a step-by-step demonstration about how to customize it by adding a new step. In the real project, there are other ways to customize checkout feature, such as change the order of checkout flow, enable express checkout, etc., for concrete information, you can refer to extending checkout page.
Hopefully this post can help you a little in Composable Storefront study.
If you have any questions or comments, feel free to add it, :-).
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
6 | |
4 | |
2 | |
2 | |
2 | |
1 | |
1 | |
1 | |
1 | |
1 |