Name: Using CMS Data in SAP Commerce Cloud Composable Storefront
Uploaded: 2023-11-27
Duration: 442 s
Description: This video presents how Composable Storefront fetches CMS data from SAP Commerce Cloud, how page structure and rendering works in Composable Storefront and how you can configure a custom component.

Share feedback

<p>Planned maintenance of Practice Systems</p>

Planned maintenance of Practice Systems

Why create an SAP account?

Enhance your learning experience

SAP Learning

Subscribe now

Learn more

Live Sessions

Hands-on Practice

Certification

My Learning

Ready to start learning?

<div><div><div><div>This video presents how Composable Storefront fetches CMS data from SAP Commerce Cloud, how page structure and rendering works in Composable Storefront and how you can configure a custom component.</div></div></div></div>

Using CMS Data in SAP Commerce Cloud Composable Storefront

Hello everyone. In this video, I'm going to talk about how Composable Storefront is CMS-driven, how Composable Storefront fetches CMS data from Commerce Cloud, how page structure and rendering  works in Composable Storefront, and finally how you can configure a custom component.  SAP Commerce Cloud's headless and composable storefront   provides the head for SAP Commerce Cloud. Although composable storefront is a decoupled JavaScript storefront,  it is CMS-driven. CMS sites, base stores, content catalogs,  and product catalogs are maintained in SAP Commerce Cloud. SAP Commerce Cloud has OCC, CMS, and Authentication APIs. SAP Commerce Cloud provides the SmartEdit tool  which allows a content manager to maintain CMS content. This is the same CMS content such as page and component layouts  later fetched by Composable Storefront through the CMS APIs.  If you open the out-of-the-box Composable Storefront and have installed the Electronic Sample Data and Spartacus Sample Data extensions, then you will see that the Spartacus Electronics site opens by default, with BaseSite,  language and currency embedded in the URL as path parameters.  In Spartacus, the Electronics Site CMS item specifies the default language, URL and coded parameters, the content catalog,  and is linked to a base store.  The base store, in turn, specifies the default currency and is linked to the Product Catalog. When you initiate a request via a URL,  Composable Storefront calls the BaseSite API to fetch the BaseSite details.  The BaseSite API returns the base site object containing the associated stored details. If we examine the response for the electronics-spa base site,  we see that it specifies the default language,  base store,  default currency,  URL encoding attributes, and URL patterns.  Composable Storefront checks the current URL against all of the CMS site URL patterns to determine the matching site.  The site electronic-spa has localhost:4200   as one of its URL patterns which matches the URL of the current request.  Language and currency are set to the current values of the CMS site.  Furthermore, the language and currency information will be passed in subsequent API calls to fetch the related CMS data.  By default, no context information is defined in spartacus-configuration.module. Automatic Multi-Site Configuration is the default  and Composable Storefront automatically determines site context based on the BaseSite metadata in the API response. Composable Storefront allows you to customize the site context data  as per your requirements. For example, if you don't want currency in the URL, then you can remove currency  from the URL encoded parameters in Backoffice. When you reload the browser, currency no longer appears in the URL.  SmartEdit is the tool for managing CMS content in Commerce Cloud. In SmartEdit, we can see all pages for the Spartacus Electronics site. If we search for home page, then the result shows that this is the page ID and this is the page template.  Open this page for edit and we can see several options for editing the page.  We have ways of examining the page structure and content slots for a page.  You can also see the components linked to these content slots.  You can create a new component and assign it to a content slot,  or you can modify the attributes of an existing component. The page structure and components details are saved in Commerce Cloud,  while Composable Storefront fetches the same through CMS APIs.  For example, you can modify the homepage banner  by replacing its displayed image. These changes will be reflected on the UI.  HTML and styling for each component is done in Composable Storefront, whereas configurable data is maintained in Commerce Cloud.  Open Composable Storefront in a browser,  then select the Developer Tools networking tab to view API interactions. After Composable Storefront interacts with the BaseSite API,  it follows up with the CMS page API, during which the site context details are included as part of the CMS API calls. You can see all of the details about a content slot  and its related components in the API response.  A component's details are fetched through the component API via the component's UID.  The CMS provides the page structure, but it does not provide a clear layout definition.  The page structure only provides an ordered list of components per slot,  but the slots themselves do not have meta information on how they should be rendered in the layout.  Now we have seen how Composable Storefront fetches CMS data from Commerce Cloud. Let's see how the page structure is mapped and the page is rendered.  The storefront's main.ts file bootstraps the app module,  and the app module bootstraps  the AppComponent. We add this out-of-the-box cx-storefront selector  to the AppComponent.  If we check the HTML markup generated for the cx-storefront selector component, we notice the header section containing cx-page-layout elements,  a main section and a footer section.  To provide layout information to the view,  Composable Storefront uses a LayoutConfig configuration object to render the page slots in a specified order.  The cx-page-layout selector fetches all slots and their rendering order  and passes this information to the cx-page-slot selector.  cx-page-slot then renders all components attached to that content slot, so that the HTML of each individual component, such as banner, category, and link, is rendered. A component type is mapped to a component class.  For example, the CategoryNavigationComponent type,  which is returned in the page API response,  is mapped to the CategoryNavigationComponent class defined in Composable Storefront.  To configure a custom component, you can create a new component module  or reuse an existing one and then map the CMS Component to an Angular Component.