(If you prefer video content, please watch the concise video summary of this article below)

In July 2022, Sitecore officially entered the cloud era by announcing the launch of the Sitecore Experience Manager Cloud (XM Cloud) . With this new product, the company moved its main CMS solution to a cloud architecture, promising its customers exceptional digital experiences.

Let’s take a detailed look at Sitecore XM Cloud and discover the advantages that Sitecore clients and users will gain from new features offered by the platform.

Introduction

Sitecore is a leading global provider of solutions and tools for content creation and management, order and digital asset management, marketing campaigns, personalization etc. Sitecore Digital Experience Platform (DXP), powered by data science, analytics, digital marketing technologies, and AI/ML capabilities, allows eCommerce businesses to create advanced digital experiences across multiple channels and industries.

The important thing about Sitecore as a digital experience provider is that they never stop improving, and develop bleeding-edge solutions for their customers to make them succeed in their niche. Sitecore Experience Manager Cloud (XM Cloud) is among such game-changing products. Let’s answer some questions to understand the essence of this modern solution and compile its comprehensive definition.

Sitecore Experience Manager Cloud:

1. What is it? — An advanced CMS.
2. Where is it deployed? — In the cloud.
3. Who can use it? — Developers and marketing specialists.
4. What are the key characteristics? — SaaS, cloud nativeness, agility, the combination of traditional CMS and headless architecture.
5. What can you do with it? — create and manage content, start websites, deliver digital experiences across all channels from a single cloud platform.

Definition: Sitecore Experience Manager (XM) Cloud is a next-generation cloud-native Software-as-a-Service CMS that enables double-quick software development and cloud content management across multiple channels and devices due to its headless architecture.

Note that Sitecore Experience Manager offers a composable approach, which means you can flexibly use its modules. For example, initially, you decide to use the platform only as a CMS, because your budget is limited. But later, you need to add personalization or eCommerce functions. With Sitecore XM Cloud, you can quickly connect these modules like building blocks.

Features of Sitecore Experience Manager Cloud

To get a better understanding of the platform’s capabilities, take a look at the main features it provides.

Cloud Portal. This is a single control center for Sitecore XM products and solutions. Team members with the appropriate access rights can control all the products, perform operations with them and create composable experiences all in one place. In the future, Sitecore is planning to provide access to all the DXP products via Cloud Portal, which will be highly convenient.    

Sitecore Managed Cloud Deployment. Using the Experience Manager Cloud, you don’t need a DevOps engineer, because the deployment is configured automatically during the creation of a new instance in the Cloud Portal.

Headless Services. This is a module with software development kits and APIs for creating decoupled apps and delivering omnichannel experiences.

Headless SXA. Sitecore Experience Accelerator (SXA) is an add-on for Sitecore XM Cloud, allowing developers, designers, and content managers to work on your site simultaneously, thus speeding up development.

Sitecore Next.js SDK. This is a React-based framework with a set of sample applications enabling headless development.

GraphQL. An alternative to REST, GraphQL is the query language for APIs that ensures communication between the server and the client. With GraphQL, you can transfer the necessary data to the application in one request, even if they are located in several sources. This makes GraphQL data extraction technology more convenient and practical.

GitOps support. GitOps is a modern convenient approach in software engineering for cloud-native applications based on DevOps best practices. Sitecore Experience Manager supports GitOps, ensuring automation, transparency and improved team collaboration.

JAMstack support. This frontend architectural approach is based onJavaScript, APIs, and Markup and includes the static site generator (SSG) concept. JAMstack makes it possible to work with a variety of modern frameworks and offers exceptional flexibility due to the support of all deployment scenarios. When deploying a new environment, you can choose Vercel as a host provider that partners with Sitecore and provides SSG.

JSS. Sitecore XM supports the JSS framework, which provides JavaScript packages and allows for developing based on Sitecore data.

Multi-site management. With the new Sitecore product, marketers can translate and localize content easily, deploy Sitecore pages for multiple global regions much quicker, and manage them from a single place.

Pages. A product for visual content editing, which replaces Experience Editor. With Pages, you can manage all your media assets from a single place and distribute various types of content across different channels.

Content Explorer. A tool for editing content fields in the editor view. It allows you to work with content items of all websites within your instance, create new items, and even access content that is not available in Pages.

Components. It is also known as Frontend as a Service (FaaS), a reusable component editor, which allows you to select and manage data sources for components.

Benefits of Sitecore Experience Manager Cloud

Content management with Sitecore XM Cloud has a range of essential benefits for your business.

Fast website performance. The modern cloud architecture combined with the capabilities of headless CMS improve the loading speed of your website pages and the overall site performance calculated by search engines.>

Scalability. The SaaS and composable nature of Sitecore Experience Manager Cloud allows you to easily scale up and down your project depending on business requirements and other factors. You can add modules if your business is growing, or remove some unnecessary tools if you currently don’t use them.

Increased speed to market. Sitecore Experience Manager Cloud streamlines the development process due to flexible deployment scenarios, headless services, component reusability, GitOps support, and other modern tools and approaches. As a result, business owners can bring their products to market much faster.

Automatic updates. Since Experience Manager Cloud is a SaaS platform, all the updates are performed automatically, so you don’t need to constantly plan the updates and spend extra money on it.

Flexible pricing. Sitecore Experience Manager offers flexible payment options, since it uses a composable approach to digital experiences. You don’t pay for the entire system, only for modules you actually use for your business needs.

What Is the Key Difference between Managed Cloud and Experience Manager Cloud?

The main difference between Sitecore Managed Cloud and Sitecore Experience Manager lies in their cloud infrastructure delivery models. Managed Cloud is a PaaS (platform as a service) offering, while XM Cloud is a complete SaaS solution. There are also some other distinctive features:

• Sitecore XM is all about composability, which means it offers cloud headless and API-based solutions.
• Sitecore XM does not have CD environments, so the MVC renderings are no longer supported.
• Sitecore XM provides SPE and SXA modules out of the box.

What Can You Get Through Using Sitecore Experience Manager Cloud?

Experience Manager Cloud gives advantages to all groups of people who are in touch with it:

• Developers gain exceptional freedom in terms of software development. They can choose from a range of frameworks, DevOps tools, APIs, deployment options and third-party integrations.

• Marketers and content editors enjoy intuitive visual tools, the headless architecture and the WYSIWYG authoring experience. They can build amazing web pages and deliver content across multiple channels with no effort. Creating a digital content strategy has become easier than ever before.
• Customers get even more relevant content and personalized experiences.
• Business owners benefit from all the above-mentioned points: a streamlined development process brings the product quicker to the market; well-prepared marketing strategies achieve their goals; the number of loyal customers grows. It all results in additional revenues and profits for the business.

Conclusion

The Sitecore Experience Manager Cloud is a true next-generation CMS, offering you a wide range of capabilities for creating powerful SaaS products. With this agile, no compromise platform, you can easily improve your content experience and commerce management, rising it to the next level.

Sitecore is an actively growing platform for developing content management systems (CMSs) and offering personalized digital customer experience. For numerous companies that have their projects based on Sitecore 9.x, the time has come to consider upgrading to Sitecore 10.x. Why and how should you do this? What’s the difference between Sitecore 9 and 10? Read the article to learn the details.

The End of Sitecore 9

The lifecycle of each Sitecore product has its end date, which means the provider will no longer support service packs and updates after this predefined date. It should be noted that there are three phases of customer support for each product version:

• Mainstream support lasts for three years from the initial release
• Extended support lasts for six years from the initial release
• Sustaining support lasts for eight years from the initial release

This way, the mainstream support for Sitecore 9.0 and 9.1 has already ended, and it will end for Sitecore 9.2 and 9.3 on December 31, 2022.

Support phases for Sitecore 9.x

Businesses that have purchased the extended and sustaining support versions, will be maintained for the next few years. However, they may already think about upgrading to Sitecore 10.x versions to benefit from new features they offer.

Sitecore 10: New Features, Benefits, and Upgrades

In August 2020, the release of Sitecore 10 was announced, bringing a wide range of improvements and new features to the benefit of both developers and customers. Let’s look at them.

Out-of-the-Box Containerization

As you know, Sitecore 9.x provided the support for containers, but only with the release of Sitecore 10, this became an out-of-the-box feature. Starting with this version, Sitecore developers can deploy containers using Docker Compose and Azure Kubernetes Service (AKS).

Why is this feature fundamentally important? Because the support for containers ensures:

• a simplified installation process
• flexible and rapid software development and deployment
• a continuous delivery approach
• the reduced consumption of system resources.

Headless Services

In Sitecore 9, developers could create headless JavaScript applications due to the integration of JSS and SXA. Starting with version 10, the Sitecore digital experience platform introduced a software development kit for headless services based on .NET Core.

The headless approach to developing eCommerce solutions is common among businesses nowadays, since it ensures an omnichannel experience, flexibility, scalability and time-efficiency, in addition to creating and managing content. Sitecore 10 allows you to develop powerful eCommerce solutions for multiple channels within a shorter span of time.

Extended Horizon Editor

Content managers opened new horizons with the Sitecore editor named Horizon. It was released in Sitecore 9.3, but a full set of functions became available only in Sitecore 10. Being a next-generation tool, Horizon brings together the best features of Experience Editor and Content Editor, while adding new capabilities:

• A more intuitive and user-friendly interface
• Improved searching
• More editing options due to the extended SXA support
• Multilingual and multi-site support
• Integration with Content Hub, which allows managers to use AI and ML technologies for providing advanced personalization

Serialization with CLI

With the Sitecore 10 upgrade, working with instances has become easier thanks to the Command Line Interface (CLI). It offers the simplified approach to publishing and serializing content items, and any changes are applied automatically to all content touchpoints.

Solr Search Alternative

In Sitecore 9, Azure Search was used as a search engine, and development teams faced certain issues working with it. That’s why, Sitecore 10 replaced Azure Search with Solr.

Personalization for Email Experience Manager

The capabilities of Email Experience Manager were extended in Sitecore 10, thus making email marketing more efficient. Now, you can quickly create emails by choosing from a variety of ready-to-use templates, and organize campaigns based on new rules associated with customer birthdays. This way, you can engage more people and convert them into your clients.

Improved Experience Analytics

Since analytics is one of the key tools for marketers, Sitecore improved it in the 10th version. Specifically, they added the new Audience Filtering capability based on the segmentation rules. Now, you can quickly categorize your audience by segments. Moreover, detailed reports on each segment allow you to clearly see customer demands and develop better marketing campaigns.

Sitecore 10.2

At the moment of writing the article, the latest version is Sitecore 10.2. Let’s briefly look at the Sitecore upgrades and new features coming with this release.

Experience Platform and Experience Manager

Among the new features are:

• xConnect DevEx CLI plugin estimate tool, allowing you to apply filters to contacts and interactions you are going to process.
• Extended xConnect logging, providing you with more information on xConnect functioning.
• List Manager for customizing lists of contacts.

Improvements were made for:

• Plugin purging tool — you can free up database space from unused data.
• Forms — content from the form fields can be exported with the respected structure.
• Robot detection — it can now be disabled.

JavaScript Rendering SDKs (JSS) and Headless Services

New features:

• Rendering MVC applications to HTML and converting MVC apps to JSS are possible due to Headless Services and JSS Next.js.
• JSS Next.js apps compatibility with Horizon.
• JSS Next.js apps can be created without boilerplate content.
• JSS React, Angular, or Vue.js apps can be created based on JSS applications samples, by using the JSS CLI command jss create.

Improvements:

• dataApi is replaced by JSS REST Layout API and JSS REST Dictionary API when developing JSS apps based on React, Angular, and Vue.js.
• URL rewriting can now be configured during the integration of a rendering host with Experience Editor or Horizon.

Developer Tools

New features:

• Items and resource package plugin allows you to extend the possible sources for Sitecore items.
• Indexing plugin automates indexing operations, streamlining the configuration of development environments or production deployments.
• Role serialization allows developers and DevOps engineers to manage roles in their solution by synchronizing them with other developers on the same project and promoting changes to source-controlled roles across Sitecore environments.

Improvements:

• You can now specify what target database you want to publish Sitecore Items to through the DevEx CLI.
• You can now exclude fields from comparison and serialization.

Email Experience Manager

Improvement:

• You can now configure the number of campaigns loaded for lists and searches, and the default sorting of columns for each List page.

Sitecore Experience Accelerator

New feature:

• The Bootstrap 5 grid

Improvements:

• Adding closed captions for YouTube videos and linking directly to public Vimeo videos.
• Using the SXA CLI for upload tasks.
• Using an image selector for some SXA components and configuring complex data sources in the Horizon editor.
• Direct access to field item properties for your i_item in the Scriban template.

Horizon

New feature:

• Content Explorer for finding and organizing content items instead of the content tree.

Improvements:

• Navigating up through the page structure hierarchy.
• Thematic grouping of components.

Analysis and Reporting

New features:

• Experience Optimization allows you to see the results of personalization on individual goal conversions.
• Experience Analytics allows you to export CSV files with data from any list report.

Improvements:

• The Segment column has been added to list reports.
• Sorting of reports by the most relevant metric.

Sitecore Experience Commerce

Improvements:

• Default commerce items as resources files, which improve the upgrade experience by storing default content items outside the database.
• Container deployment improvements
• Merchandisers can use the Business Tools interface to change the order in which to display product images, and have those changes reflected in the Storefront.
• The Commerce Engine and Commerce Engine Connect now support Redis Cluster configuration.
• New caching API samples in Postman let you clear Redis cache stores.

Sitecore 9 vs. Sitecore 10

Reasons Why You Should Upgrade to Sitecore 10

Taking into account the above-described features and capabilities of Sitecore 10.x, we can distinguish four general reasons why you should make the decision to upgrade.

1. Retain the technical support of Sitecore for all of their products you use.
2. Provide your developers with improved tools and new tech capabilities, including .NET Core, containerization, and Kubernetes, to streamline the development process.
3. Empower your marketing team with more efficient tools that will help you increase conversions.
4. Deliver amazing omnichannel experiences to your customers by grasping a better understanding of their needs.

The Migration Algorithm

When you’ve come up to the decision to upgrade from Sitecore 9.x to Sitecore 10.x, you should prepare for the process. The following is a brief algorithm of what steps should be taken.

• First, check the compatibility of your hardware and software with the new Sitecore XP version.
• Starting with the version Sitecore XP 9.3.0, certificates for the Secure Sockets Layer (SSL) are required because communication with the Content Management server occurs over HTTPS. If you don’t have them yet, you should obtain and set up these certificates before upgrading.
• During the upgrading process, it’s important not to break any customizations you’ve done in your system. Therefore, before starting, you should move your custom DLLs and configuration files out of the Sitecore\bin and \app_config folders. You’ll be able to adapt them later according to breaking changes and return to the folders.
• In addition, check that the default config files have not been edited. In case they have some changes, extract them to a custom configuration file and back it up, otherwise you’ll lose them.
• Sitecore Update Center is the tool using which you download, install and manage all the necessary upgrades. This is where you should find the Sitecore 10 upgrade package, download and install it.

• It can also be required to upgrade your existing databases, depending on the Sitecore version you are using now.

Note! If you want to avoid issues with custom elements while upgrading the production system, you should first test the process on a developer or testing system.

Closing Thoughts

Sitecore 10.x is a fully-functional platform that can address all the challenges of modern marketing. Both developers and marketers get innovative tools, which they can use to accelerate processes and achieve better results. Both business owners and digital consumers benefit from the new features offered by the platform.

If you still have doubts regarding the Sitecore upgrading process, get in touch with the experienced Sitecore developers at SaM Solutions for discussion.

Overview

The Sitecore Experience Accelerator has a built-in Asset Optimizer module that is used for optimizing CSS styles and JS scripts. If you want to improve your site performance, you should enable this module in your production environment, and it will cut down the volume of data that needs to be transmitted.

As a Sitecore administrator, you have two options of enabling Asset Optimizer:

• Global enablement for the entire Sitecore instance
• Local enablement for selected sites

According to the best practice, both CSS styles and JS scripts are loaded on the client side with a version prefix to avoid a cache issue when a new delivery occurs. And SXA is not an exception: it applies a timestamp for the optimized assets, as shown below:

<script src="/sitecore/shell/-/media/Base-Themes/SearchTheme/Scripts/optimized-min.js?t=20160908T094830Z"></script> 

Problem

In one project I was involved in, we observed the following issue — the timestamp was not generated for localized sites. All optimized assets contained the empty timestamp parameter, as shown below:

<script src="/sitecore/shell/-/media/Base-Themes/SearchTheme/Scripts/optimized-min.js?t="></script>

This results in the situation when the client browser doesn’t update the cached version of CSS styles and JS scripts after another deployment, since the t parameter is a versioning element.

So, let’s investigate this case.

Solution

The first thing we need to do is to figure out how and where the timestamp is generated. A great idea is to start from the default SXA layout razor page. It’s called SxaLayout.cshtml.

As we can see, to get an asset link, it executes the static GenerateLinks method of the AssetLinksGenerator type

(full name: Sitecore.XA.Foundation.Theming.Bundler.AssetLinksGenerator)

Going deeper, we can find the GetOptimizedItemLink method, which is responsible for the asset link generation. It looks as shown below:

In the return expression, if an optimized script item is both not null and empty, the BuildAssetPath() extension method is executed.

All right, we’ve discovered the place where the timestamp is added. Interesting, it goes from the system’s __Updated template field. Hm, what could be the issue with that? Let’s check this field.

Ok, the __Updated field belongs to the Statistics template that is a part of the Standard Sitecore template. The key thing here is that this field is not shared. It means that if we have a site with no default localization, the optimized assets also should have this language version that is a bit strange — do we really need to have localized assets (CSS and JS)? I am not sure. So, we need to apply a fix to resolve this issue for localized sites.

• First, we need to create our own BuildAssetPath extension method (the same code as above) with one additional line of code inside the if statement:

Item item1 = item.EnsureFallbackVersionIfExist();

This extension method (assembly Sitecore.XA.Foundation.SitecoreExtensions.dll, ItemExtensions.cs) returns an item for a default language (usually English) if there are no language versions. That is what we need for optimized scripts.

• Second, we need to create a new type (inherited from AssetLinksGenerator.cs) with the overridden GetOptimizedItemLink method and a new static GenerateLinks method to hide the base one.
• Third, replace OOTB AssetLinkGenerator by the created one in the SXA layout:

That is it! Now, your localized Sitecore SXA sites have optimized assets with the generated timestamp parameter! Happy coding Sitecorians!

Problem

While working on one of our projects, we needed a mechanism for handling messages between different applications. Sitecore implements this mechanism via the Sitecore Messaging Framework on Azure Service Bus. In this regard, the article by Árvai Mihály helped us a lot.

However, we needed to implement a second-level handler. As it turned out, the method is quite simple but not obvious.

Let’s see how you can do this.

Solution

First of all, you need to create a configuration file.

Here you have to pay attention to the Options section:

• <ErrorQueueAddress>Error</ErrorQueueAddress> — defines the queue to which the message will be sent if its processing fails.
• <MaxDeliveryAttempts>3</MaxDeliveryAttempts> — defines the number of attempts to receive messages by the first-level handler.
• <SecondLevelRetriesEnabled>true</SecondLevelRetriesEnabled> — allows the use of a second-level handler.

In our case, the second-level handler will be called after three unsuccessful attempts to receive a message by the first-level handler.

Now, you should create a contract for messages.

Then, you should create an empty class that will be used by the Rebus library.

The next step is to initialize our ExampleMessageBus with the help of Sitecore Initialize Pipeline.

To receive messages, you should create a handler and register it. You’ll need the Rebus library to do this.

In the handler, we inherit IMessageHandler <ExampleMessage> and IMessageHandler <IFailed <ExampleMessage>>. The second interface allows us to process messages when the message processing at the first level was unsuccessful. Here you can set a Defer for messages or send a notification that an error has occurred at the first level, or something else.

You should also register IMessageHandler<IFailed<ExampleMessage>> in the configurator.

So it’s done. Now you are able to use the second-level messaging in the Sitecore Service Bus.

P.S. Many thanks to a colleague of mine Mikhail Shishlyannikov who helped me with investigating this topic.

In this article, I’ll explain to you the principles of GitOps, its connection to DevOps, the benefits of managing infrastructure using this approach, and how to put it into practice.

What Is GitOps?

GitOps is a relatively young approach in software engineering. It has emerged on the basis of DevOps best practices, such as continuous integration, continuous deployment, version control, collaboration, etc. The ultimate goal is to automate infrastructure updates, make the process traceable and avoid human error.

Definition: GitOps is a set of practices/an approach to a modern implementation of continuous deployment for cloud-native applications. When we talk about GitOps, we mean not only the deployment of the application source code, but also the deployment of infrastructure using tools that are popular among developers — Git, IaC (Infrastructure as Сode), continuous integration.

The essence: you describe the infrastructure you need for the target environment in a declarative manner and store the descriptions in a special Git repository; the process of making the environment match the described state is automated.

In a nutshell, developers are empowered to perform tasks that were traditionally performed by the Ops. If they want to deploy a new application or update an existing one, they only need to update the repository, and an automated process handles everything else.

The most popular declarative cloud infrastructure today is Kubernetes. GitOps is a perfect operating model for the Kubernetes-based infrastructure and applications development and delivery, as it combines Git with the Kubernetes convergence properties.

It All Starts with Infrastructure as Code (IaC)

For a better understanding of GitOps, we should first explain the Infrastructure as Code (IaC) concept.

Previously, operations engineers had to create infrastructure manually using PowerShell and kubectl scripts. In recent years, the practice of defining infrastructure (as well as configuration, network, security and other components) in code is gaining traction.

Instead of creating a Kubernetes cluster with multiple nodes, you describe everything you need in files, using tools such as Terraform, Ansible, YAML Kubernetes manifest files, etc. This allows you to simplify the reproduction and replication of infrastructure and its components.

There are two options for making it work:

1. A DevOps engineer creates, tests, executes and stores all files locally on the computer.
2. A DevOps engineer creates a Git repository for IaC and stores all these files on Git. This is the preferable option because you get version control for your files, and other team members have access to the code.

However, this second method has serious disadvantages:

• No pull requests. If you or your team members change the code, it is directly committed to the main branch.
• No code review. Consequently, nobody can collaborate on the changes and review the code.
• No automated testing. If you’ve committed files with errors, you’ll only find out once you applied them to the environment, because no automated tests are running to check the changes.
• No traceability. Each team member tests their changes manually in the development environment and then applies the changes manually in the staging and production environment. They access the Kubernetes cluster or cloud-platform infrastructure from the local computer and execute Terraform or Ansible commands. Hence, it’s hard to trace the history of changes and find out who applied a particular feature, which is critical if errors are found.

As you can see, IaC is a convenient method of infrastructure management, though it still needs improvements. This is where the GitOps concept comes into play. It aims to ensure the treatment of Infrastructure as Code in the same way as the application code, i.e. by combining a Git repository with a full DevOps pipeline (CI/CD).

How Is GitOps Different from DevOps?

Looking at their names, it’s obvious that the two are interconnected. The definition from Wikipedia says that DevOps is a set of practices that combines software development (Dev) and IT operations (Ops) with the aim to shorten the systems development life cycle and provide continuous delivery with high software quality.

GitOps is a logical continuation of the ideas that were incorporated in DevOps. In particular, GitOps is the evolution of the Infrastructure as Code concept, which itself originated in the DevOps environment.

GitOps has bridged the gap between existing DevOps practices, which were designed to address system administration challenges, and the specific needs of distributed cloud-hosted applications.

As a separate practice, GitOps may be included in a set of DevOps practices; precisely, it aims at closer interaction with developers. Since Git is already being used for software development, engaging Git in operations not only involves DevOps techniques but also harnesses the power of version control.

How GitOps Works

As mentioned, the workflow of GitOps is based on the integration of the IaC system and the CI/CD pipeline. Let’s look at the GitOps operating mechanism.

1. First, a separate Git repository for the IaC project is created.

2. If you need to make changes to the code, you create a pull request.

3. A CI pipeline ensures the validation of config files and runs automated tests.

4. After automated testing, any team member can review commits and approve the pull request.

5. Finally, approved updates are merged into the main branch through a CD pipeline and are then deployed to the Kubernetes environment. In other words, this is where new versioned artifacts of the infrastructure are prepared.

Thus, infrastructure code changes go through the same stages as application code changes. As a result, all changes are reviewed and tested before being applied in any environment, which significantly reduces the risk of breaking something.

6. The convergence mechanism ensures that updates made in the repository are applied to the Kubernetes cluster: the Kubernetes orchestrator compares properties of the cluster with updates in Git and applies them to the cluster until the observed state is identical to the configuration files in the repository. This mechanism is applicable to any Kubernetes resource.

GitOps Principles

1. Declarative description of systems. The definition and configuration of systems are described as source code (e.g., YAML Kubernetes manifests). The code is stored and automatically versioned in a Git repository, which serves as the only source of truth. This approach makes it easy to roll out and roll back system changes.

2. Setting and versioning of the system’s desired state and configuration in Git. By storing and versioning the desired state of systems in Git, you have the ability to easily roll out and roll back changes in systems and applications. You can also use Git’s security mechanisms to control ownership of the code and verify its authenticity.

3. Automatic application of approved changes. Using Git pull requests, you can easily control how changes are applied to configurations in the repository. For example, you can give them to other team members for verification or run through CI tests, etc. To commit configuration changes, users only need the appropriate permissions in the Git repository where these configurations are stored.

4. Eliminating the problem of uncontrolled drift of configurations. When the desired state of the system is stored in the Git repository, you only need to add software that would control that the current state of the system corresponds to its desired state. If there are inconsistencies, the software should either fix them or warn about the drift of configurations.

How Is GitOps Put into Practice?

In systems working with GitOps, there is usually:

• a separate Git repository for infrastructure
• a separate Git repository for the application code
• the CI/CD pipeline.

The infrastructure repository is the only place in the system where the infrastructure configuration code is stored. This code manages configuration, creation, updating, and possibly deletion. This repository is the heart of IaC and the source of truth about what the infrastructure should be and what should work in it. When they want to make updates, developers upload files with code that acts as deployment instructions to this repository.

If the state of the infrastructure differs from the state described in the repository, GitOps, as a tool, must bring the target state of the system to the state described in the repository.

The application code repository is the basic project code.

The third component of the system, the CI/CD pipeline, should be somehow connected with repositories to know when to run tests and deploy.

For this purpose, there are two deployment strategies in GitOps.

1. Push-Based Deployments

A push-based deployment strategy is essentially a classic CI/CD implementation using tools such as Azure DevOps, GitHub Actions, Jenkins, GitLab, and so on.

We can see how it works by looking at Sitecore as an example. We have the source code of our Sitecore instance in the Git repository. In the same repository, we also store Kubernetes YAML files (infrastructure) necessary for deploying the application. As soon as the application code changes (Git Push), a pipeline build is triggered. It builds the container images, pushes these images to the Container Registry and deploys updated Kubernetes infrastructure manifests.

Note: There is a certain practice whereby the infrastructure code (YAMLs) is placed in a separate environment repository (see the scheme below). This approach is a little more complicated since it’s necessary to implement the update of the environment repository during the build of the pipeline.

Using the Push approach has some pros and cons.

Pros

• The Git repository and assembly pipeline define security.
• Secret management is easier because secrets can be used in pipelines and stored in Git using encryption.
• You’re not tied to a specific tool — you can use any type.
• Container version updates can be initiated by the assembly pipeline.

Cons

• Data for accessing the cluster is stored in the assembly system.
• Updating the deployment containers is still easier in the pull process.
• High dependency on the CD system (pipelines are written for a specific tool, and if the team decides to use another tool, they will have to migrate numerous pipelines).
• The degree of security is still lower than in the pull process.
• More monitoring is required.

2. Pull-Based Deployments

With a pull-based approach, the same concepts are used as with the push-based approach. The difference is that an operator is added to perform the role of a pipeline.

An operator (agent) is installed in the environment (e.g., Kubernetes cluster) and pulls changes from the repository itself. The operator regularly checks the state of the infrastructure code in the repository, comparing it to the current state in the environment. If a difference in the repository is detected, the agent pulls and applies changes in the environment to get it from the actual to the desired state. Moreover, it monitors the image registry for any new versions of images.

Unlike a push-based process that updates the environment only when the repository is updated, a pull-based deployment can find changes even if they aren’t described in the repository. An operator will send you a notification if it can’t apply the requested changes to the environment. This means there is a greater degree of transparency.

Tools working with the pull-based model are Flux and Argo. They run inside the Kubernetes cluster and transfer updates from the repository to the cluster. The Kubernetes API server accepts declarative descriptions of updates and manipulates the objects in the cluster (e.g., namespaces, pods, events, ConfigMaps) in order to achieve the desired state as described in the Git.

Pros

• Nobody can change the cluster from the outside.
• You can scan Docker Registry for new versions and, if found, update the repository and deployment.
• Pull tools can be distributed across various namespaces with different Git repositories and access rights. This makes it possible to use a multi-tenant model.
• Secrets can be stored encrypted in Git and extracted inside the cluster.
• There is no dependency on the CD pipeline because deployments take place inside the cluster.

Cons 

• It’s more difficult to manage deployment secrets from Helm charts.
• You are tied to pull operating tools, which limits configuration opportunities in the cluster.

Benefits of Using GitOps

• Automation — when configuring infrastructure, manual tasks are eliminated, saving a lot of time.
• Transparency — the process allows you to easily trace all the changes made to the code due to time stamps, commit IDs and all the information about committers.
• Collaboration — since everyone in the team can collaborate on the code and review updates, the result is always of high quality.
• Fast and frequent deliveries — teams can deliver updates faster and more frequently due to the automation process; it may take from several hours to several minutes.
• Easy rollback — due to version control, you can easily roll back your environment to any previous state; this is highly important if applied changes break something and the cluster doesn’t work.
• Security — the code review opportunity, automated testing and version control make deployment more secure.
• Self-documenting deployment — there is no need for architects or tech leads to keep the infrastructure documentation separately: everything is stored in Git, so there is always an up-to-date version. In addition, this approach enables fast onboarding of new developers to the project.

GitOps Challenges

The greatest challenge is the initial configuration of the process. As soon as everything is set up, the system will run like clockwork.

You may face another issue — the engagement of all team members in this process. Working with GitOps may seem boring and time-consuming to those developers who are used to making quick changes manually. That’s why you should take time to explain GitOps benefits and convince your teammates to follow the new process and write down every change diligently.

GitOps Example

The following is an example of using GitOps from my practical experience.

In one Sitecore project, the client identified a performance issue in the live site (content delivery, using Sitecore terminology). The Dev team looked into the GitOps repository that held infrastructure configuration and figured out all major Sitecore deployments (CM, CD, Identity) configured (via nodeSelector settings) to run pods on the same Kubernetes Node at a time when the cluster had another empty Node.

The Dev team decided to rebalance the pods to run CD separately from CM and Identity.

• A developer opened up a new pull request to apply appropriate nodeSelector settings to the CD YAML configuration.
• That pull request was reviewed and approved by the Dev team and merged into the repository.
• The merge kicked off a GitOps pipeline, which triggered the GitOps operator (Pull strategy).
• The operator detected that the CD configuration had changed. It confirmed with the systems orchestration tool that this did not match what was live on the cluster.
• The operator alerted the orchestration system to update the CD configuration.
• The orchestrator handled the rest and automatically deployed the newly configured CD.
• The Dev team confirmed that the CD pod was running on another Node and the performance issue was gone.

Conclusion

GitOps is an incredibly powerful automated operating model for managing modern cloud-native solutions and infrastructure. Unlike the IaC concept that deals with disintegrated local machines, GitOps ensures centralized storage of files on a remote server backed up by DevOps best practices.

Though initially focused on Kubernetes cluster management, GitOps can be applicable to other non-Kubernetes systems, bringing numerous benefits to them. If you need to improve the communication in your team, ensure the transparency and reliability of the system, I highly recommend you consider GitOps for infrastructure management.

As we know, the Sitecore license file is passed to the container as an environment variable (called Sitecore_License) in the encoded string form. In Kubernetes, we usually put this encoded value into a secret file; for instance:

We store and manage all Sitecore K8S specifications in source control, and the secrets are no exception. For security reasons, keeping secrets in source control is bad practice. In a project I was involved in, we used the Azure DevOps variable group to define all secrets.

Unfortunately, the Sitecore License secret is too big to be kept as an Azure DevOps variable. It says: “Length of variable `SITECORE_LICENSE` is invalid. It must be between 0 and 4096 characters.”

One solution is to store the license secret in the Azure key-vault. But I would like to introduce another solution — Kubernetes Persistent Volumes (volumes defined and created as part of the pod lifecycle only exist until you delete the pod).

Source: Microsoft  

Kubernetes supports different types of volumes and one of them is Azure File persistent volume. This means we can create the Azure File Share, put the Sitecore license file into and mount it as a Kubernetes volume. The following algorithm shows how to do that:

Step 1. Create a resource group (sugbelarus1 in my sample).

Step 2. Create a storage account (sugbelarus in my sample).

Step 3. Create the Azure File Share (license in my sample).

Step 4. Get the storage account key.

All these steps could be completed via Azure CLI.

# Change these four parameters as needed for your own environment
AKS_PERS_STORAGE_ACCOUNT_NAME=sugbelarus
AKS_PERS_RESOURCE_GROUP=sugbelarus1
AKS_PERS_LOCATION=eastus
AKS_PERS_SHARE_NAME=license

# Create a resource group
az group create --name $AKS_PERS_RESOURCE_GROUP --location $AKS_PERS_LOCATION 

# Create a storage account
az storage account create -n $AKS_PERS_STORAGE_ACCOUNT_NAME -g $AKS_PERS_RESOURCE_GROUP -l $AKS_PERS_LOCATION --sku Standard_LRS 

# Export the connection string as an environment variable, this is used when creating the Azure file share
export AZURE_STORAGE_CONNECTION_STRING=$(az storage account show-connection-string -n $AKS_PERS_STORAGE_ACCOUNT_NAME -g $AKS_PERS_RESOURCE_GROUP -o tsv) 

# Create the file share
az storage share create -n $AKS_PERS_SHARE_NAME --connection-string $AZURE_STORAGE_CONNECTION_STRING 

# Get storage account key
STORAGE_KEY=$(az storage account keys list --resource-group $AKS_PERS_RESOURCE_GROUP --account-name $AKS_PERS_STORAGE_ACCOUNT_NAME --query "[0].value" -o tsv) 

# Echo storage account name and key
echo Storage account name: $AKS_PERS_STORAGE_ACCOUNT_NAME
echo Storage account key: $STORAGE_KEY

Step 5. Upload the Sitecore license file.

Step 6. Create a Kubernetes secret.

Kubernetes needs credentials to access the file share created in the previous steps:

kubectl create secret generic azure-secret
--from-literal=azurestorageaccountname=$AKS_PERS_STORAGE_ACCOUNT_NAME
--from-literal=azurestorageaccountkey=$STORAGE_KEY

Run the kubectl get secrets command to validate if a new secret was created.

You can also validate via Visual Studio Code using the Kubernetes extension.

Step 7. Configure the volume in the container specification; for instance, cm.yaml file.

• Define the volumeMounts section:

• Define the Volume section.

• Define the SITECORE_LICENSE_LOCATION environment variable (from Sitecore 9.X you can use this variable to configure the license location).

Step 8. Deploy updated specification (kubectl apply command) and exec the updated pod.

kubectl exec --stdin --tty cm-854986576d-l2cls

Where cm-797498f98d-lj6bz – pod name (run kubectl get pods command to get the name)

Make sure you can find the license file where you mounted it.

That’s it for today! Happy voluming, everyone!

In this article, I want to share my experience of implementing this feature in practice.

Problem

I was involved in one project based on Sitecore 9.3 Managed Cloud and SolrCloud, where we built a custom search index to crawl products every 12 hours. That was a huge one (with more than 3 million products at the time of this writing) and the entire rebuild took 8–10 hours.

In Sitecore, there is a mechanism for switching between active and rebuild indexes in order to avoid downtime in search functionality on the website. We, therefore, configured the Switch On Rebuild feature for this custom index so that the rebuilding process doesn’t affect the active index used on the live site.

As for continuous delivery, we used the blue-green deployment approach so as to have zero production downtime.

After each deployment, we triggered a full rebuild of our custom index and occasionally faced the problem of having the active index running instead of the rebuilt one.

For instance, before deployment, we have the following alias statuses in SOLR cloud:

• active collection — product_index_rebuild (in SolrCloud it maps through aliases)
• rebuild collection — product_index (in SolrCloud it maps through aliases)

Main alias (active index) — product_index_rebuild collection (In SolrCloud, search core is called collection)

This means that the next time we trigger the index, it should be product_index. But we see quite the opposite in practice: the active index is running, the live site is broken, and data search is unavailable.

What Is the Cause of the Problem?

Sitecore has a property store where it stores some major facts about search indexes, such as when the index was last updated. And if the index has the Switch on Rebuild functionality, it stores information on which collection is Active and which is Rebuild. It happens inside the SwapAfterRebuild method (Class: SwitchOnRebuildSolrCloudSearchIndex, Assembly:  Sitecore.ContentSearch.SolrProvider) where the PreserveAliasesCollections is called.

All the data is located in the Properties table (core database):

As you can see, this table has three columns. Key and Value columns are of main interest to us.

The Key column comprises the following parts:

• CORE — just the core prefix (core aka collection in SolrCloud)
• PRODUCT_INDEX — the name of the index
• RD50***B1F27 — server Machine Name. The machine where the CM instance is hosted as PaaS
• MC-EDD***501-CM__6554 – WEBSITE_IIS_SITE_NAME
• SOLR_ACTIVE_COLLECTION — the active collection in SOLR
• REBUILD_COLLECTION — the collection that will be rebuilt next

The IndexDatabasePropertyStore (Assembly: Sitecore.ContentSearch) type implements this interface. Below you can see the implementation of the Set method with its dependencies:

In the Property table, you can find more than one pair because Azure can change the Machine Name for any reason.

How do you validate the current Machine Name and WEBSITE_IIS_SITE_NAME? In the Azure portal, navigate to CM AppService and run Advanced Tools (aka KUDU):

Click the Environment tab where you can observe all major metadata about this App Service. For instance, you can find the Machine Name, WEBSITE_IIS_SITE_NAME:

And what happens when we run the blue-green deployment?

When the deployment completes, a new deployment slot becomes available. This slot is another App Service that has its own Machine Name and WEBSITE_IIS_SITE_NAME; for instance:

In the scope of Active/Rebuild collections stored in the Property table, Sitecore does not synchronize slots between each other. What does that mean for us? It means we could end up with a situation in which the status of both active/rebuilt collections is different.

Example

Let’s assume the current Machine Name is A. But we also have machine B that will be swapped when the blue-green deployment occurs. Machine B has Active Collection — product_index_rebuild, Rebuild Collection — product_index. When we trigger the deployment, machine A looks like this:

• Active Collection — product_index
• Rebuild Collection — product_index_rebuild

Consequently, on the live site, the product_index is active. After the deployment, machine B is active, and when we trigger the index, the product_index is run; this is an issue because another index needs to be run.

Solution

This issue can be resolved as follows:

1. After the blue-green deployment, run SQL script to compare Active/Rebuild collections between deployment slots:
2. If #1 resynchronized, update records for the active deployment slot (machine). It’s also possible to delete these two records.

You can automate these steps by writing a script and executing it in the scope of the Content Delivery pipeline.

Note: the ContentSearch.Solr.EnforceAliasCreation setting (part of the SwitchOnRebuildSolrCloudSearchIndex class) should be False. If this setting is True, Sitecore creates aliases every time the CM instance is reset.

I hope you will find my experience useful. That’s it for today.

Problem

In our Sitecore project, we built a custom product index containing more than two million documents. This index has a custom crawler with complex logic, which includes reading thousands of JSON files and calling different APIs (e.g product ingestion, third-party data storage).

To implement the search functionality, we used the SOLR Cloud topology (from the SearchStax vendor) with the Switch On Rebuild feature (Zero downtime rebuild).

There is a custom automation process that triggers the index every night out of work hours. It takes about six hours, give or take, to process two million documents.

Once, when the index contained 500,000–600,000 documents, we got the following SOLR timeout connection exception:

Exception: SolrNet.Exceptions.SolrConnectionException
Message: The operation has timed out
Source: SolrNet
   at SolrNet.Impl.SolrConnection.PostStream(String relativeUrl, String contentType, Stream content, IEnumerable`1 parameters)
   at SolrNet.Impl.SolrConnection.Post(String relativeUrl, String s)
   at SolrNet.Impl.LowLevelSolrServer.SendAndParseHeader(ISolrCommand cmd)
   at Sitecore.ContentSearch.SolrProvider.SwitchOnRebuildSolrSearchIndex.PerformRebuild(Boolean resetIndex, Boolean optimizeOnComplete, IndexingOptions indexingOptions, CancellationToken cancellationToken)
   at Sitecore.ContentSearch.SolrProvider.SolrSearchIndex.Rebuild(Boolean resetIndex, Boolean optimizeOnComplete)

This happened when the rebuild process had been completed and Sitecore sent a request to SOLR to optimize the index.

Source: Sitecore.ContentSearch.SolrProvider.SwitchOnRebuildSolrSearchIndex.PerformRebuild(Boolean resetIndex, Boolean optimizeOnComplete, IndexingOptions indexingOptions, CancellationToken cancellationToken)

Sitecore enthusiasts have already discussed this issue.

Solution

To resolve this issue, we had to increase the ConnectionTimeout value. We changed it to 60,000, equalling 10 minutes. And it worked!

But our index was growing fast, and when it exceeded 2 million documents, we got the SOLR timeout issue again.

We increased that parameter to 120,000 (20 minutes), then to 360,000 (1 hour), but that didn’t help. We had to discover the source of the problem and resolve it.

Let’s take a look at how the official SOLR documentation describes optimization:

As you can see, optimization may improve the query performance when the index has become fragmented by many updates.

In our case, we had a daily full rebuild process, which means that we had a fresh index every day. And, as noted in the SOLR documentation, we did not need to optimize it:

Optimizing is not recommended unless it can be performed regularly as it may lead to a significantly larger portion of the index consisting of deleted documents than would normally be the case.

To avoid the optimization process, you can develop your own type of index inherited from the one you used before.

In our case, it was the SwitchOnRebuildSolrCloudSearchIndex (we used index swapping due to the zero downtime).

Then, you need to override the Rebuild() method: call the base method by setting the false value for the optimizeOnComplete parameter. This means that Sitecore will not trigger the Optimize command to SOLR:

public class NotOptimizedSwitchOnRebuildSolrCloudSearchIndex :
        SwitchOnRebuildSolrCloudSearchIndex,
        ISolrCloudIndex,
        ISearchIndex,
        IDisposable
    {
        public NotOptimizedSwitchOnRebuildSolrCloudSearchIndex(
            string name,
            string mainalias,
            string rebuildalias,
            string activecollection,
            string rebuildcollection,
            ISolrOperationsFactory solrOperationsFactory,
            IIndexPropertyStore propertyStore) : base(
            name,
            mainalias,
            rebuildalias,
            activecollection,
            rebuildcollection,
            solrOperationsFactory,
            propertyStore)
        {
        }

        public NotOptimizedSwitchOnRebuildSolrCloudSearchIndex(
            string name,
            string mainalias,
            string rebuildalias,
            string activecollection,
            string rebuildcollection,
            IIndexPropertyStore propertyStore) : base(
            name,
            mainalias,
            rebuildalias,
            activecollection,
            rebuildcollection,
            propertyStore)
        {
        }

        public NotOptimizedSwitchOnRebuildSolrCloudSearchIndex(
            string name,
            string mainalias,
            string rebuildalias,
            string activecollection,
            string rebuildcollection,
            IIndexPropertyStore propertyStore,
            ISolrProviderContextFactory providerContextFactory,
            string @group) : base(
            name,
            mainalias,
            rebuildalias,
            activecollection,
            rebuildcollection,
            propertyStore,
            providerContextFactory,
            @group)
        {
        }

        public override void Rebuild()
        {
            Rebuild(true, false);
        }
    }

Then, insert the created type into the index config:

And that should do the trick! Happy coding, dear Sitecorian. See you next time.

P.S. Thanks to my colleague Vadim Birkos for brainstorming this issue.

The Problem

Our client needed a possibility to create reusable macrocomponents from a bunch of microcomponents and use them across pages and sites included in one JSS tenant.

Let’s assume we have the following list of JSS components (microcomponents):

• Section — a root component
• Grid Component
• Rich Text Component
• Image Component.

And we want to build a macrocomponet using these microcomponents as follows:

• Put a Grid with two columns in a Section placeholder.
• Put an Image Component in the Left Column.
• Put a Rich Text Component in the Right Column.

In Sitecore SXA, there is an out-of-the-box Snippet component to cover such cases.

Since our project was a combination of Sitecore SXA and JSS, we couldn’t use the SXA’s Snippet component. We had to develop a custom one.

Solution

The following idea came up to my mind.

1. Create a simple JSS Component (aka Snippet) with a snippet-content placeholder inside.
2. Create a new JSS Layout specifically to build a Snippet component structure separately.
3. Put the Snippet Component (built in step 1) on the main JSS Layout (used for content pages). Select the Snippet Item created separately using the JSS Layout in step 2 as a data source.
4. At runtime during the rendering process, check if the rendered item contains a Snippet Component somewhere. If YES — get a Snippet DataSouce, render it and put the rendered result in the snippet-content placeholder.

Implementation

1. The first step is quite simple. In our project, we used the Sitecore First approach mode to build JSS components.

In Sitecore, create a Snippet JSON Rendering:

As for the DataSource, create a Snippet Item template inherited from:

* Base App Route template (Path: /sitecore/templates/Foundation/JSS Experience Accelerator/Multisite/Base App Route)

* Global Datasource Behavior template (Path: /sitecore/templates/Foundation/Experience Accelerator/Local Datasources/Global Datasource Behavior)

In the created Snippet rendering, put a data source link referenced to the Snippet Item template.

Then, create a Snippet JSS Component with a placeholder:

import React from 'react';
import { isExperienceEditorActive, Placeholder, Image } from '@sitecore-jss/sitecore-jss-react';

const SnippetComponent = (props) => {

  if (!props.fields) {

      return <h1 className="alarm">Datasource isn't set.<h1>;
    }
    return (
      <h1 className="alarm">
        Data is not provided. Contact administrators, please.
      </h1>
    );
  }

 return(
     <>
        <Placeholder name="snippet-content" rendering={props.rendering} />
      </>
);
}
export default SnippetComponent;

2. Create an additional Layout that will allow you to configure the Snippet data source separately.

In Sitecore, create a new JSS Snippet Layout (just a copy of the existing one) with only one placeholder (in my case snippet-content):

In JSS, add the following piece of code to the Layout.js file:

import React from 'react';
import { Placeholder, VisitorIdentification,withSitecoreContext } from '@sitecore-jss/sitecore-jss-react';
import Helmet from 'react-helmet';

import './assets/app.css';

const Layout = ({ route, context }) => {

return (<React.Fragment>
<Helmet>
<title>
{(route.fields route.fields["Page Title"] route.fields["Page Title"].value) || route.displayName }
</title>
</Helmet>

<VisitorIdentification />

<Placeholder name="jss-top" rendering={route} />
<section className="site-wrapper">
<Placeholder name="jss-main" rendering={route} />
</section>
<Placeholder name="jss-footer" rendering={route} />

{context.pageEditing <Placeholder name="snippet-content" rendering={route} />}

</React.Fragment>
)};

export default Layout;

In step 1, we created the Snippet Item inherited from the Base App Route JSS Experience Accelerator template. It means we can use this item as a content page. Make sure the Snippet Item is referenced now to the Snippet Layout we created above.

3. Find the demonstration below in the How To Use section.

4. After some investigations, I found out that the main entry point where it is possible to inject our custom code is the Render virtual method in LayoutService class (implementation of the ILayoutService Interface, Sitecore.LayoutService.dll).

So, to achieve our goal, we need to develop a custom Layout Service inherited from default Sitecore LayoutService and override the Render method to add a logic to find and render Snippets with its data source added on a page:

public class CustomLayoutService : LayoutService
{
public CustomLayoutService(
IPlaceholderRenderingService placeholderService,
ILayoutServiceContext serviceContext) : base(placeholderService, serviceContext)
{
}

public override RenderedItem Render(
Item item,
IRenderingConfiguration renderingConfiguration,
RenderOptions renderOptions = null)
{
return CustomRenderedItem(item, renderingConfiguration, renderOptions: renderOptions);
}

You can find the CustomRenderedItem method implementation here.
To inject the CustomLayoutService instead of the default one, we need to register the following dependencies:

public class RegisterDependencies : IServicesConfigurator
{
public void Configure(IServiceCollection serviceCollection)
{
serviceCollection.AddSingleton <IConfiguration, Configuration>();
serviceCollection.AddSingleton <IFieldRenderer, FieldRenderer>();
serviceCollection.AddSingleton <ISerializerService, SerializerService>();
serviceCollection.AddSingleton <IRenderJsonRenderingPipeline, RenderJsonRenderingPipeline>();
serviceCollection.AddSingleton <IGetFieldSerializerPipeline, GetFieldSerializerPipeline>();
serviceCollection.AddSingleton <IPlaceholderRenderingService, PlaceholderRenderingService>();
serviceCollection.AddSingleton <ILayoutServiceContext, PipelineLayoutServiceContext>();
serviceCollection.AddSingleton <IGetLayoutServiceContextPipeline, GetLayoutServiceContextPipeline>();
serviceCollection.AddSingleton <ILayoutService, CustomLayoutService>();
}
}

and apply the following patch:

<configuration xmlns:patch="http://www.sitecore.net/xmlconfig/" xmlns:role="http://www.sitecore.net/xmlconfig/role/">
        <sitecore>
                <services>
                        <configurator type="Sitecore.LayoutService.RegisterDependencies, Sitecore.LayoutService">
                                <patch:attribute name="type">JssSnippet.Configurators.RegisterDependencies, JssSnippet</patch:attribute>
                        </configurator>
                </services>
        </sitecore>
</configuration>

How To Use

1. Create a Snippet item under Data folder of your SXA JSS Site (/sitecore/content/[JSS Tenant]/[JSS Site]/Data/Snippets/Demo/Snippet):

2. Open created Snippet Item in Experience Editor to add microcomponents there:

3. Add JSS Components you would like to use as a snippet then. For instance, in my case, I am going to add the Section component, then Grid component, then Column component (2), then Image component (left column), then RTE component (right column):

Section:

Grid with two Columns:

The image in the Left Column:

Rich Text in the Right Column:

Ok, now we have our Snippet data source with components inside:

4. Now, it is time to add the Snippet to a site page. Open a content page in Experience Editor and add the Snippet Component in any placeholder you need:

And here is the result — we’ve got a Snippet component with Microcomponents inside.

5. Let’s put the same snippet on the Top placeholder on the same page.

And now we have a reusable feature — two Snippets on the page.

Let’s check the presentation details for this page.

6. There is also one feature in the SXA’s Snippet, such as Global Data Source Behavior. Our custom Snippet item also has this approach (inherited from the SXA template — /sitecore/templates/Foundation/Experience Accelerator/Local Datasources/Global Datasource Behavior)

7. Probably, you have the following questions:
* Is it possible to Edit components that are inside the snippet directly on a content page? — Yes, it is.
* Is it possible to Put another snippet to an already created one? — Yes, it is. As of now, there is only one restriction — you are not able to put the same Snippet inside.
* Do the Sitecore Personalization Rules work with Snippets? — Yes, they do.
* Can I contribute to it? — Sure, just make a fork and help me improve it.

That’s all for today. You can find the implementation in my GitHub.

Feel free to contribute.

Happy coding, Sitecorians!