Name: Working with Runtime Configuration Initializers in SAP Commerce Cloud Composable Storefront
Uploaded: 2024-1-8
Duration: 495 s
Description: In this video, you will learn what Runtime Configuration Initializers are, and how they can be utilized with SAP Commerce Cloud, Composable Storefront.

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>In this video, you will learn what Runtime Configuration Initializers are, and how they can be utilized with SAP Commerce Cloud, Composable Storefront.</div></div>

Working with Runtime Configuration Initializers in SAP Commerce Cloud Composable Storefront

Hello everyone. In this video, we will be  discussing runtime configuration initializers.  So, what are configuration initializers?  By default, global configuration properties  for Composable storefront are configured  using the “provideConfig” mechanism.  These properties are set during application  startup, and they do not change  once the application is running.  There might be certain scenarios where certain  configuration data might be required  during the application initialization phase.  For example, properties related to setting up  the site context like URL parameters,  base site information, and currency.  These properties are expected to be loaded  before application startup.  Configuration initializers are used for loading  such application-critical configuration properties  asynchronously, before application startup.  In Angular, an app initializer is a mechanism  that allows us to execute code  or perform certain tasks  before the application is fully bootstrapped.  And these configuration initializers are an extension of these app initializers that load configuration data.  This approach also allows configuration data  to be loaded or fetched dynamically  using backend OCC APIs.  Now let  us look at the difference between  Config Initializers and the provideConfig  mechanism by examining some examples.  Config Initializers are used to load configuration  data before the application starts.  Configuration data that are required to provide  or override configurations  to specific components, services, etc., can use provideConfig.   App initializers, too, can use  provideConfig-loaded configurations.   They are generally available at compile-time,  therefore are thought-of as static.  Initializing the site context using  SiteContextConfigInitializer and the internationalization (i18n) context using I18nConfigInitializer  before  the application starts are prime examples of  when to use a Config Initializer.  CMSConfig, which provides mapping  of backend CMS components to angular  components, is one of the many  examples of when to use provideConfig.  SiteContextConfig and I18nConfig properties  can also be configured at build time  using provideConfig, as can be seen here.  Now, let us take a high-level look at  the flow of one of the configuration initializers  for a better understanding.  The source code we will be referring to  is of version 6.3 of Configurable Storefront.  For better understanding, the entire Config  object has been logged into the browser  console as can be seen here.  First, let us examine how Config initializers  are added to App initializers.  In the source code, there is a module named  as ConfigInitializerModule.  Here, it can be seen how  the ConfigInitializer factory function  is provided to the App Initializer.  This ConfigInitializer factory will eventually  create instances of config initializers  configured in various modules.  For example, site context configuration info, like basesite, currency, url parameters, etc., are required before application startup so that the components can be rendered based on this information.  SiteContextConfigInitializer is the initializer that  takes care of setting these values at runtime by fetching the details from the backend, if needed, using OCC API calls.  It is present in SiteContextModule  in the source code.  As can be seen in the configuration,  initSiteContextConfig is the factory function that initializes this initializer and the initializer and the SiteContextConfig object are injected,  as dependencies, into the factory function.  In the factory method, it can be seen that, the config initializer for site context  is initialized only if the static site config  provided via provideConfig is empty.  That is, only when the static site context  parameters in Spartacus configuration module  are not configured, this initializer makes a  backend OCC API call to retrieve the base site  and the corresponding context parameters.  Scope basically defines the part of the Config  object that will be affected by this initializer.   In this case, context is the scope of  configuration that will be affected by the  retrieved base sites from the backend API call.  This flow diagram depicts the flow of the config  initializers which we had seen so far,  starting from App initializer until resolving the config where config initializers are  instantiated using factory functions.  This is an example of a configuration initializer  where the site context can be dynamically  configured prior to application startup.  There might be use cases where the initialized  config value from a config initializer  might be required for evaluation by  another configuration initializer.   This is like a chained configuration,  where one config is needed for evaluating and  setting another config at runtime.  Since configuration values in config initializers  are loaded asynchronously, to fetch a value set  by a config initializer from another, there needs to be a mechanism to identify whether or not  that specific scope of the initializer is stable –  in other words, whether the initialization  is still in process or has been completed.  For example, as you can see in this flow  diagram, for setting up the internationalization(i18n) context, the base-site-related context is required for fetching the fallback language as base sites  generally hold the list of languages supported  and its corresponding fallback languages.  The backend OCC URL, referred-to here,  is the config that is needed for invoking  the backend API calls  to retrieve the context parameters.  This site context is populated by  SiteContextConfigInitializer and the config set  by the initializer is needed for setting-up  the internationalization context.  To determine whether the scope of  SiteContextConfigInitializer is stable,  therefore completed processing (as it is  asynchronous), the getStable() method  of ConfigurationInitiaiizerService  is generally used.   If the scope is passed to this getStable()  method - in our case, the context part of the configuration – it returns the stable  config value of the scope which can then be  used for evaluating the fallback-language- related initialization value.  Similarly, the stable i18n config is retrieved  and used for evaluation in the subsequent app  initializer, I18nextInitializer, which provides  additional context for translations.  This is an example of a chained config  initializer flow available by default in Composable Storefront. Similarly, based on business requirements,  application-critical config data  can be set during app initialization using these  config initializer techniques.  All that is needed for instantiation  is to register the initializer in  CONFIG_INITIALIZER, with its corresponding  dependencies and factory methods.  This concludes our “Runtime Configuration Initializers” video.   There is detailed documentation about this  topic in SAP Help Portal.   Do take a look, and happy learning!