In this post we will be discussing commerce architecture and components as briefly and as clearly as possible. It’s been around for quite some time. I got a chance to look into it some 2 years back when I worked on newer Retail SDK.Almost forgot the details ,so compiling it here for future references
At the very center of things is the commerce scale unit that’s the headless commerce. It could be self-hosted or cloud-hosted. it further has three components
- Commerce data sync libraries (Consumer APIs)
- Channel database(transactional DB for one or more channels)
- Commerce Runtime(contains the core commerce business logic)
The headless commerce is an API-driven framework.These commerce APIs of the headless commerce are used in back-office operations and in-store, within the call center, and in e-commerce. These APIs provide a complete omnichannel solution.
Then this design provides a Unified data through out-of-the-box integration’s with Microsoft Dataverse and Azure Data Lake Storage
That’s pretty much completes the top components diagram.
Now a bit on the In-store topology
This diagram is quite self-explanatory. It clearly defines what kind of topology should be used in what circumstances. The selection is mostly based on the internet connectivity and in-store connectivity. when to use MPOS vs CPOS, when to use cloud scale unit vs store scale unit.
Then we have store commerce app deployment options
A bit on commerce SDK
A FinOps dev machine could be configured for POS side development. Alternatively, a separate VM could be used. Follow below link for the setup
https://learn.microsoft.com/en-us/dynamics365/commerce/dev-itpro/install-csu-dev-env
Below tables provide information about the components in the Commerce SDK that can be customized for different scenarios
| Scenario | Extend the Store Commerce app for user experience (UX) changes, client logic, workflows, and simple validations. |
|---|---|
| Commerce SDK reference | Store Commerce app samples |
| Scenario | Extend CRT to add or change business logic (for example, logic for calculating tax, prices, or discounts). |
|---|---|
| Commerce SDK reference | CRT samples |
| Scenario | Create a Headless Commerce API extension to expose new Commerce APIs to the client. |
|---|---|
| Commerce SDK reference | Retail Server samples |
| Scenario | A TypeScript proxy is required if new Headless Commerce API extensions must be consumed in the POS or E-Commerce clients. |
|---|---|
| Commerce SDK reference | CommerceProxyGenerator |
| Scenario | A Hardware station is required to add or change logic that is related to peripherals. |
|---|---|
| Commerce SDK reference | srcHardwareStationSample samples |
| Scenario | Integrate the POS with a new payment connector. |
|---|---|
| Commerce SDK reference | srcHardwareStationSamplePaymentDevices |