Sitecore Experience Commerce Architecture

Editor's Notes

• #2: Hello and welcome to the first Watercooler of 2019. Today we’re going to be covering Sitecore Experience Commerce Architecture.
• #3: But before we start, who am I…… Tech Evangelist – APJ Commerce Evangelist – Global Sitecore since 2006
• #4: Before I get into it, how many here have worked with Sitecore Experience Commerce? So this will be a technical session, and we’re going to be covering *CLICK* So lets jump straight in!
• #5: We’re going to start by looking into the server architecture, the different instances that you’ll need to deploy to stand up an instance of SXC.
• #6: So we’re going to use PaaS as our example, and the first things we get are Resource group using to hold all of our resources Redis cache used to store the user sessions Azure Search to hold all of the indexes Application Insights for monitoring and log storage But before we talk about XC we first wasn’t to look at whats its built on top of, and that starts with XM & XP *CLICK* <<Talk through XM instances>> *CLICK* <<Talk through XP instances>> *CLICK* <<Talk through XC instances>> *CLICK* So today we’re not going to talk anymore about the XM or XP instances and purely focus on the XC resources, so lets take a look at each of these in detail.
• #7: So lets take a look at each of these elements *CLICK* <<Explain DBs>> *CLICK* <<Explain Application Roles>> *CLICK* <<Explain indexes>> Now in the session we’re mostly going to focus on the application roles as that’s where the majority of the functionality for XC exists……
• #8: So first of all I just want to touch on two of the roles we showed The Commerce Business Tools Merchandisers edit their data Fully customisable from C# Super lightweight Identity Server Precursor to the Identity Server that you’ve seen in XP 9.1 But lets take a look at the engine where most of the XC functionality exists…
• #9: So the Sitecore Commerce Engine is a brand new .NET Core application, it can actually be run as a console application which is a nice workflow compared to the full .NET Framework web instances It uses OData for communication with the Sitecore Platform, and much like xConnect secures all of that communication over HTTPS through the use of certificates. Finally, I’m not sure how many of you have heard about the Sitecore Host that was announced at Symposium, but this is the common application framework that all of our future microservices will be based on, and the Commerce Engine is built on an early version of that. DEMO DEBUGGING
• #10: So lets start to talk about the 4 Engine roles that we had in our architecture diagram earlier. Now the thing the understand here is that these are all the same codebase – slight config differences but for all intents and purposes they are the same. They’re just separated for scaling and isolation of responsibilities. *CLICK* <<Describe engine roles and click through features>> <<Show debugging>>
• #11: So lets take a look at why you would want to separate the responsibility of the engines like this. Here is a very simple representation of how they work. They advantage to having this split is……. <<Talk about high authoring sites>> <<Talk about high traffic sites>>
• #12: Lets take a look at what happens when a merchandiser is managing the catalog *CLICK* Merchandiser logs into BizFX site User credentials are validated using the Identity Server instance The Identity Server checks the entered credentials against data stored in the ASPNET membership tables in the Sitecore Core DB *CLICK* The BizFX tools then call the Authoring Role to populate UI Merchandiser navigates to the MerchandisingDashboard, and a Call is made to the Authoring Role to get the Catalog Data from SharedEnvironments DB A SellableItem is selected and it’s details are again retrieved from the SharedEnvironments DB *CLICK* The Merchandiser updates the SellableItems details as required then hits “Save” A Call is made to the Authoring Role and the updated SellableItem is persisted into the SharedEnvironments DB Finally an EntityIndex entity is persisted to SharedEnvironments DB to which will queue an update of Catalog Items Scope Index to be performed by a Minion
• #13: When a Shopper is viewing one or more sellable Items on the site *CLICK* User hits the SxA Storefront page containing catalog data (e.g. Product Listing or Detail page) Rendering details are loaded from the Sitecore Web database Rendering uses the sitecore_web_index to get details of the SellableItems *CLICK* Index documents are converted into Sitecore Items The commerce data provider calls through to the Shops Role Shops Role Commerce Engine retrieves SellableItem Entities from the CatalogEntities Table in the SharedEnvironments Database Price of item is calculated using data from the PricingEntities Table again in the SharedEnvironments DB The found SellableItems are returned back to CD instance Data is rendered and returned to the browser
• #14: So that covers the standard data flows for the checkout process, but for a load scenario, what architecture elements would be affects by sites which handle large amounts of orders? *CLICK* Sites with large amount of order being places will see load being placed on the following entities SxA Storefront CD instance Shops Role SharedEnvironments DB Minions Role Order Scope index It is recommended to scale these entities to match the load as required.
• #15: So that’s given a good overview of the Server Architecture, any questions on the server side of things? Ok, then lets dive into the application architecture, here were going to cover the Commerce Engine, SxA Storefront & Service communication
• #16: So lets take a look into the commerce engine first, we covered how it interacts with the other systems in the architecture and how it scales, but now we’re going to look into how the code itself is structured inside of it.
• #17: So you might have heard that the Commerce Engine is built on a plugin based architecture, and I really like this diagram as I think it’sis a pretty good way to visualize this *CLICK* Here you have your core functionality, in XC9’s case this is the core commerce framework. *CLICK* Then built onto that are your plugins, each one is an individual piece of functionality, completely self contained and leveraging the functionality & extensibility exposed by the core framework. Single Responsibility Principal Open Closed Principal
• #18: And this plugin architecture gives you real flexibility over what functionality you have enabled in a system. Here you can see some plugins that would make up a typical storefront. But say you just deal with digital goods <<Talk about Steam>> Remove Inventory & Fulfillment *CLICK* Conversely say you want to add a new feature, like say a Product Compare, well you can do that as well. <<Talk about footprint size>>
• #19: Code first Composition not inheritance <<CLICK Through each of the elements>>
• #20: So that’s the engine, now lets take a look at the storefront side.
• #21: SXA Storefront has been build on top of the Sitecore Experience Accelerator. But what is SXA? It is a toolkit that allows you to build websites with limited to no CMS development efforts. And it enables different work streams like UX, visual design and development to run in parallel accelerating the delivery time.
• #22: SXA Storefront adds 40 specific commerce components on top of the default SXA components that you can use to add commerce functionality to your site In addition to the components it comes with three sample themes that can be used to “style” the storefront
• #23: The components are ordered by category types Account Cart Catalog Checkout Orders Shared
• #24: Ok so they sound great, but how does all of this communicate with each other?
• #25: Well here we’re going to look a the Product Compare feature. *CLICK* Here’s the engine plugin <<Talk to image>> *CLICK* Here’s the storefront functionality <<Talk to image>> *CLICK* But how does the storefront talk to the engine?
• #26: We’ll we’ve introduced a ServiceProxy to enable this *CLICK* <<Talk to code-gen shim>> *CLICK* <<Talk to ServiceProject image>> So if you have a feature with code in both the engine & storefront, which is very common, you end up using the workflow here. Do they have to handle certs themselves?
• #27: The EngineConnectUtility handles certificate based communitcation for you? Here we’re building up an OData query to be run against the engine <<Talk through code lines>>
• #28: And of course how can we forget Helix. Plugins very modular, split code between storefront & engine Common Closure responsiblity. RFC open, We need your comments, explain common closure should apply to engine as well
• #29: So any questions about the Application side of things before we move on? Ok, so lets take a look at some of the tooling / extensions & samples that are available to you.
• #30: <<Talk to Andews templates>>
• #31: <<Talk to Kaz’s extensions>> Open Issues – Contributing to OSS is looked on favourably at MVP review time!
• #32: Similar to ShowConfig but interactive!
• #33: Sample solution for XC I don’t like separation of XC / XP – great example of flexibility in Helix
• #34: Shameless self plug…. Product Compare we saw earlier, plus others
• #35: So I just wanted to finish up covering where we are with the product today, and where we’re going to be in the near future….
• #36: Only a revision release but included a few new features Static Bundles - Represented in both Engine & Storefront Javascript moved into Theme, more closely matching standard SxA – makes multi tenancy JS a possibility SxA 1.8 Custom views per components Greyscale Support for SolrCloud Improved catalog import time by 80% Reduced cold load time in paas > 80% Reduced indexing time by 50%
• #37: Improved documentation Updated 3rd party library versions .NET 4.7.1/OData, Sitecore Identity, SIF2.0, Solr7.2.1, SXA1.8.1 Corrective content, hotfix roll-up Alignment with XP 9.1 Enables you to build on top of Cortex functionality Enables UT for mobile applications
• #38: Questions?