Share
ReportI am attempting to do a series of forum posts that speaks to the architecture, capabilities and limitations of Dynamics 365 e-commerce rendering so the community can make the best decisions while implementing solutions on top of the platform.
I feel the best place to kick start this conversation is to start with high-level architecture of Dynamics 365 e-commerce. Our online document is a great resource to check out. In this post, I will cover the different components of the rendering engine, their roles and responsibilities.
When it comes to e-commerce rendering engine, there are two services behind the scenes – Commerce Online Platform and Node services.
Commerce Online Platform
Commerce Online Platform (or just Rendering platform) is an ASP.Net & C# based service that is responsible for doing the initial processing of the user requests. When a user makes a request on the browser, the request will get routed to the Commerce Online Platform service via CDN & Traffic manager.
Commerce online platform is responsible for several things in processing the requests
- It is responsible for both C1 and C2 authentication flows. For C1 (customers of Microsoft), this refers to the preview scenarios and for C2 (end users using the e-commerce websites), this refers to the B2C/B2B login scenarios.
- It is responsible for resolving an incoming URL (ex: https://www.adventure-works.com/adventure-works/apparel/women/coats/68719481858.c) and determining
- The site in Site builder the URL maps to
- Channel and locale we need to use (based on channel setup in site builder) to render the page
- Resolve the URL and map to a that’s configured in Site builder and hydrate the data from CMS
- Once the URL is resolved and the corresponding CMS objects are identified, this layer is responsible for resolving all those dependencies (page, page fragments etc.) and building a single JSON object (what we often refer as Page object) that is then sent to the Node layer as an input. You can see this when you add the query string ?item=nodeserviceproxy:true to any page. It will emit the JSON which is an internal contract between the Commerce Online Platform layer and the Node layer. This is the response used to build page mocks for local development as well.
- Experimentation and targeting rules in site builder are configured at a module level. When Commerce Online Platform builds the page object, it will evaluate the experimentation and targeting rules to determine which to choose and determine the content for the final rendered page.
- It does geo detection (if the feature is turned on in Site builder) and takes a user to appropriate channel depending on where the request originated from
It then posts this Page object to the Node service and gets back the HTML that is in turn returned to the caller.
Commerce Online Platform does not support any customizations. This service is fully built and managed by Microsoft. This service gets deployed every week. It can take 2-3 weeks for a change that is checked in to make its way to our Production environment. All the environments will get those changes automatically. We leverage our internal flighting services heavily in this layer, that gives us ability to turn on some flows in select environments or roll out changes incrementally on customer environments.
Node Service
Node service layer is often referred to as Nodejs layer, Partner app or Node container. As the name indicates, this service runs on Node.js and renders the React.js modules server side to build the HTML response. It uses online SDK as the runtime and is pretty much the same service that developers run in their local environments to build and test customizations. The Node.js service is responsible for converting the page object provided by Commerce Online Platform into HTML that is finally sent back to the browser.
The request flow in Node service does the following
- The module definition (both out of the box modules and customized modules) tells us what data actions to execute prior to loading the module. We first h.
- Render the react modules server side with the data and the configuration inputs.
- Build HTML base page based on module hierarchy and return the HTML output along with the
Note: Since we support rendering modules both server side and client side, we need to make sure the data used for rendering the module server side is available on the client side as well. So this gets sent down the wire as ___initialData___ and React will hydrate the HTML back to react components client side using this ___initialData___, this in turn lets React execute the lifecycle hooks client side. It’s important to note that, if the data contracts on server side are not optimized, it can bloat the ___initialData___ object . This will affect your site performance and LCP, I will cover this topic in detail in a future post.
This layer hosts all customer customizations and is isolated from the rest of the services that need to be inside a trust boundary. These customizations include
- Custom Modules
- Custom Data actions
- Themes – Themes can contain extensions on out of box modules, data actions, css etc.
- Connector – currently we support connectors for Experimentation providers, 3rd party segmentation providers, Geo connectors to resolve Ip2Geo.
Partner app development starts from our github repository. Developers can execute “yarn msdyn365 pack” command to create a package that can then be deployed to their environment via LCS. More information can be found here.
Please feel free to ask your questions here and i will try and answer them. I intend to cover more topics in coming weeks and if anyone have a topic you prefer to discuss here, please do let me know.
All responses (
Answers (
291,269
