Name: Working with Custom URL Matchers in SAP Commerce Cloud Composable Storefront
Uploaded: 2023-11-13
Duration: 344 s
Description: In this video, you will get information about the custom Angular URL matchers in Composable Storefront as well as understand how they work and how you can benefit from using them in your implementation.

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>In this video, you will get information about the custom Angular URL matchers in Composable Storefront as well as understand how they work and how you can benefit from using them in your implementation. </div></div></div></div>

Working with Custom URL Matchers in SAP Commerce Cloud Composable Storefront

Hello everyone. In this video, I’m going to talk about how to control the format of dynamic URLs,  when and why you may require a custom angular URL Matcher,  and how to implement one in composable storefront.   Composable Storefront supports all the CMS Page Types of SAP Commerce Cloud,  such as Product Page, Category Page,  and Content Page.   Each Content Page has its URL  specified via its label attribute,  while a Product page or Category page  is handled differently.   If we examine some content pages  in BackOffice, like faq,  its label attribute is set to “/faq”,  which is the page URL,  and we can verify that its page Type is ContentPage.   Similarly, for cartPage, the label attribute  holds the URL, “/cart”.   Whereas if we examine an instance of ProductPage for example, this one, with an ID of productDetails,  then we see that this instance  does not even have a label attribute. This is because the URL of a  Product Page,  Category Page, or Brand Page  cannot be statically defined.  It depends on a product code  or category code to be part of the URL.    This sort of dynamic URL can be configured  in composable storefront.   Composable Storefront allows you  to configure string patterns  for matching routes to incoming URLs.   For example, this URL (highlighted below)  is defined to have two segments:   The first segment, “product”,  is a static segment that designates this URL as being for a page type of ProductPage.   The second segment, “:productCode”,  is a dynamic parameter.  By default, product and category page URLs require a static segment  to identify page type.    If we open the out-of-the-box storefront  and navigate to any Product Details Page,  then we can see the default URL format.   It has the static segment, product,  the product’s code value,  and the product’s name value.  Let’s say you wanted the URL format  to contain only the product’s code;  we can update the paths array  in product’s route configuration  to include only :productCode.    Now, with this change,  if we try to navigate a browser  to the previous URL (which worked fine a moment ago)  then it returns “page not found”. Now I’ll go back to the homepage and,  from there, open a Product Detail Page.  Now, a productPage’s URL follows  our new format or pattern.   If we check the back-end API calls,  then we see that the browser calls  the CMS page API and passes a page type of Product  and a product code value as a parameter.  The response to this call is the page structure  for productPage.  We can also change the static segment  of a productPage URL.  To do that, just update the paths array  in the product route configuration  and change product to,  let’s say, p, and save our changes.   Again, go back to the homepage and navigate to a productDetails page.    Now we see that the page URL’s static segment  has changed to “p”. Let’s say you want the URL  to consist of only one, combined segment like “:productCode-p".   Then, by default, Composable Storefront  won’t recognize it.   A custom Angular URL matcher  would be required to make this level of customization work.   Before we go into the details  of defining a custom angular URL matcher,  let’s see why we may need such a URL format.   There may be cases that require  a URL segment that combines  both a static and dynamic part  into a single segment in a productPage  or categoryPage URL.   One possibility is for Search Engine Optimization to improve product searchability  and to keep a “pretty” URL.  Or, you may be migrating  from a legacy system  that may require you to preserve  a legacy URL format for SEO and, perhaps, preserve an integration  with a third party legacy system.   To get this “combined” URL format to work,  we need to create a custom Angular URL matcher.    The matcher’s central function  will check the incoming URL  to ensure it has only one segment,  and that the segment ends with “–p”.    If the URL matches these criteria,  then we’ll remove the trailing “–p”  return just the product code.   We also need to add this URL matcher  to the product route configuration.   Let’s add this URL matcher and see if this works.  and we see that it does.   Let’s check if productPage URLs are correctly formatted on homepage.  This productPage URL contains  just productCode  and this URL doesn’t work.   Now, to fix it, we have to add a product Normalizer.  A product normalizer class converts  the backend OCC API response  into a ProductModel to help   us format URLs in the browser.   Add this custom product normalizer class  which defines a new custom property,  customProductCode.   This property’s value is simply the product code  appended with “–p”.  Register this new custom class  as a provider in the AppModule.   Now use this new customProductCode property  in the paths array of the product route configuration.  Let’s check things now, with these new changes. Now, product URLs are correctly formatted, and they work.   Thank you for watching this video.