Migrate to the Commerce SDK
Support for the Retail SDK will end in October 2023. Please use or migrate to the Commerce SDK, which provides several benefits including a simplified development and update experience, and improved performance.
The Commerce software development kit (SDK) and sealed installers simplify the Commerce developer and upgrade experience. The new Commerce SDK minimizes the effort that is involved in upgrades, and helps reduce the time and effort that must be spent on the upgrade process. Additionally, integration with Git, Microsoft Azure DevOps, and Visual Studio Code brings the .NET development experience to the Commerce SDK.
The main difference between the Commerce SDK and the older (legacy) Retail SDK is that extensions can be independently developed and deployed. This process reduces the upgrade and deployment time, and the new sealed installers separate the extension from the base installers. Therefore, the base and extension installers can be independently installed and serviced. You don't need a code merge or combined packaging.
In the Retail SDK, you need the Core POS app projects to develop a Point of Sale (POS) extension, and extensions must use those projects to develop extensions. If multiple independent software vendor (ISV), partner, or customers extensions are involved, they must all be merged to the Core POS app extension project. That project is integrated into one build pipeline to generate the combined package or installers that include the Core POS app and the extension. If the new Microsoft upgrade for POS is available, the extensions must be merged with the Core POS app to generate the combined installers. This process is time consuming, involves development effort, and must be repeated for every upgrade.
The Commerce SDK and sealed installers address the preceding issue by isolating the base app and extensions. Extensions can be independently developed by consuming the packages that are available in a public feed. They don't require any of the Core POS app or core classes from the Commerce runtime (CRT) or Retail Server.
An extension can be developed as an add-in. The new sealed installer framework enables it to be independently developed and deployed. Extensions can create their own headless installers for extension code. Multiple extensions can be installed separately, except Microsoft–hosted Cloud Scale Unit extension packages. In a self-hosted Cloud Scale Unit, multiple extensions can be independently installed and deployed.
The Commerce SDK samples and packages are published on GitHub and in a public feed, for easier consumption. You don't have to access Microsoft Dynamics Lifecycle Services (LCS) to get the latest update. It can take several hours to download the latest update of the SDK through LCS. However, the new approach lets you download the latest SDK or packages in just a few steps. The GitHub repository (repo) is a sample repo. Therefore, you don't have to clone it to create your extension development. All extensions can be developed by consuming the packages from the public feed.
Benefits of the Commerce SDK
The Commerce SDK provides these benefits:
- The update experience is seamless. The core application and extensions can be independently updated without a code merge. You don't have to update extensions to update the core applications. This new process reduces the time that is spent on updates.
- Performance is improved. If extensions are migrated to the Commerce SDK and .NET Standard 2.0, the Cloud Scale Unit can be upgraded to the new ASP.NET Core 3.1, which provides better application programming interface (API) performance.
- Extensions are published to GitHub and a public feed. You can download the SDK within minutes instead of hours.
- The new sealed installers are headless (that is, there is no user interface). Sealed installers work great for mass deployment.
- Separate headless installers for extensions use the new installer framework.
- Packaging and configuration of CRT and Hardware station extensions for Store Commerce Modern POS are automated.
- Build times are improved.
- The developer experience is improved. CSU extensions can be developed by using Visual Studio Code, Git for source code management, and Azure DevOps for build automation.
Comparison of the Commerce and Retail SDKs
|Component||Commerce SDK (new)||Retail SDK (legacy)|
|Samples||Samples are published on GitHub.||Samples are published in the \Sample extension folder in the Retail SDK.|
|Getting the SDK||The SDK is available on GitHub and in a public feed.||The SDK is available on the LCS development virtual machine (VM).|
|Packages or reference libraries||Packages are published to the public feed and can be consumed via NuGet.||Reference libraries and packages that are required for Commerce development are available in the /Pkgs folder in the Retail SDK.|
|Deployable packages||There are separate packages and installers for Cloud and on-premises components. You don't have to update any configuration files for extensions. Configuration files are automatically generated. Packages can be generated by consuming the packages in the public feed. There is no dependency with any samples or projects on GitHub.||There is one combined deployable package. You must update several configuration files to generate that package.|
|Installers||There are separate installers for core applications and extensions. The Commerce SDK uses the new sealed installer framework to generate the installers. It works only with the new sealed installer. Installers can be generated by consuming the packages in the public feed. There is no dependency with any samples or projects on GitHub.||There are combined installers for extensions and core applications. For example, there is one combined Modern POS installer for Core POS and extensions.|
|Build pipeline||Sample YAML files that are available on GitHub can be used to set up the pipeline. However, the Commerce SDK is designed to work with your own Azure DevOps pipeline setup.||The build pipeline is based on the dirs.proj file that is available in the Retail SDK.|
|Updates||To update the extensions, consume the latest package that is available in the public feed.||Updates must be done from LCS. The LCS update process must be followed.|
Overview of the migration steps
Uninstall the Store Commerce app, Hardware Station, and Cloud Scale Unit - Self-hosted that were installed by using the legacy installers. Then install the required application by using the new sealed installers.
Migrate the CRT, API, channel database, proxy, POS, and Hardware Station extensions by using the Commerce SDK.
Most of the code that was written by using the Retail SDK can easily be migrated. You don't have to rewrite it. For example, the CRT extension can be updated by changing the project to NET standard 2.0 and updating the reference package so that it's consumed from the public feed. The API extension can be updated by using new interface and removing the EDMModel extender code, because it's automated in the back end.
Deploy the extensions.
How to migrate
Developer environment changes
The LCS 10.0.21 developer VM doesn't have Visual Studio 2017. Therefore, manually install Visual Studio 2017 and the dependencies as described in the "Prerequisites" section of Retail software development kit (SDK), or set up a local development environment. We recommend that you set up a local development environment. Eventually, Commerce components won't be available on the LCS VM. You can either manually install those components on the LCS developer VM or use your own local development machine.
In the Retail SDK, CRT extensions use the packages or reference libraries from the \Pkgs folder. However, in the Commerce SDK, all the required packages are published to the public feed, and CRT samples are available for reference on GitHub.
Your extension code must use the packages from the public feed instead of the Retail SDK \Pkgs folder, and you must update the project to .NET Standard 2.0. If you followed the best practices, no changes should be required in the core business logic or contracts. The packages in the public feed won't have any services or workflow classes. Your extension must not consume those classes.
Edit your project file, and manually add the package reference or use the NuGet manager to consume the packages, as shown in the following XML example.
<PackageReference Include="Microsoft.Dynamics.Commerce.Sdk.Runtime" Version="$(CommerceSdkPackagesVersion)" />
Packages that are available in the public feed for extensions to consume can be found on GitHub.
Why we made this change to CRT extensions
This new implementation simplifies the upgrade and development process. To download the latest version of the packages, you no longer have to use LCS to upgrade the SDK. That upgrade process can take several hours. Instead, select the latest version in your package management solution (for example, NuGet).
Development of Commerce extensions for CRT is more streamlined and follows the standard best practices for .NET development.
Reference package difference between legacy Retail SDK and Commerce SDK
|Legacy SDK package||Commerce SDK (new)|
|Microsoft.Dynamics.Commerce.Runtime.Services, Microsoft.Dynamics.Commerce.Runtime.TransactionService, Microsoft.Dynamics.Commerce.Runtime.Workflow, Microsoft.Dynamics.Commerce.Runtime.Services.Messages, Microsoft.Dynamics.Commerce.Runtime.Data||Microsoft.Dynamics.Commerce.Sdk.Runtime|
Sample code to migrate the helper classes consumed in legacy SDK to Commerce SDK
|Legacy SDK helper methods||Commerce SDK (Request/Response)|
DataCacheAccessor is internal. Use .NET memory cache or a similar approach.
|PricingEngine||Extensions should not call PricingEngine directly and instead should use CalculatePricesServiceRequest, CalculateDiscountsServiceRequest.|
|PricingDatabaseAccessor||Obsolete since version 10.0.1, use the relevant CRT data requests.|
Retail Server or Headless Commerce API extensions
In older versions of Retail SDK extensions, you must use the packages from the Retail SDK \Pkgs folder and extend from the
CommerceController class to create new API extensions. In the Commerce SDK, an extension uses the packages from the public feed and extends the API controller class from the
IController interface. For more information, see Create a Retail Server extension API (Retail SDK version 10.0.11 and later).
Why we made this change to the API extensions
This change removes the need to create the
EdmModel factory and extender. It was complex for the extensions to add this factory and extender, and to set appropriate attributes. The whole Entity Data Model (EDM) process is now automated, and you don't have to generate a separate offline proxy library. The API extension library can be used directly offline, and the proxy generation process is simplified.
No changes are required in the offline database scripts that are created for extensions. However, you must create a channel database project and include the script in it for packaging. The sample project can be found on GitHub.
Previously, you had to create a separate Modern POS C# proxy library to consume the API and CRT extensions. However, in the new API extension model, you can directly use the Headless Commerce API.
In older versions of Retail SDK extension, you must use the packages from the Retail SDK \Pkgs folder and extend from the
HardwareStationController class to create new Hardware Station extensions. When you use the Commerce SDK, an extension must use the packages from the public feed and extend the Hardware Station controller class by using the
IController interface. For more information, see Integrate the POS with a new hardware device and generate the extension installer.
New sealed installers
You can download the new sealed installers from LCS by going to the Shared Asset Library and selecting Retail Self-service package as the asset type. The legacy installers or the apps (Hardware Station, Cloud Scale Unit - Self-hosted) must be uninstalled before you install the new sealed installers. The Commerce SDK for POS will work only with the sealed installers.
In the Commerce SDK, a few improvements that have been made to the development process for POS extensions will require changes when you migrate existing extensions. The following table summarizes the most important changes. For a complete list of changes and steps to migrate an extension, see Migrate a POS extension to the independent packaging model.
|Removal of POS app code from the SDK||In older versions of the Retail SDK, the POS extension solution contains both Microsoft-developed code and the extensions. In the Commerce SDK, we changed this model. The extension solutions now include only the POS extensions code.||This change simplifies the update process by removing the need for a code merge. It also enables the POS main package to be updated independently from the extension packages. Finally, it enables POS to support multiple extension packages without requiring a code merge.|
|POS API updates||
In addition to the packaging changes, we made two main changes to the POS API:
|The removal of references to the knockout.js library from the POS public contracts enables us to iterate and improve the POS control implementations without the risk of breaking any extensions. This capability is especially important because the upgrade process no longer requires that the POS main package and extensions be recompiled together. Nevertheless, extensions can still use knockout.js. For more information about how to use knockout.js with the Commerce SDK, see Consume external or third party libraries like Knockout.js in POS extensions.|
For information about how to set up the build pipeline for the Commerce SDK, see Set up a build pipeline for the independent-packaging SDK. To simplify the setup, YAML and script files are added as a sample. Additionally, steps for using the certificate from Azure Key Vault and signing the build artifacts are added.
A new packaging type is added to separate the self-service components from the Cloud Scale Unit extensions. The new ScaleUnit package will contain only the Cloud Scale Unit components. You can upload the self-service components to LCS by using the build pipeline. Alternatively, they can be manually uploaded and synced to the back office.
If you use the Retail SDK to generate the package, you must update the Customization.Settings file and the extension configuration files. In the Commerce SDK packaging, all these steps are automated. Therefore, you don't have to include or update the configuration files.
For more information, see Generate a separate package for Commerce Cloud Scale Unit (CSU).
Do I have to migrate?
The Commerce SDK provides several benefits that the Retail SDK doesn't provide, such as a simplified development and update experience, and improved performance. The Retail SDK and installers will be deprecated in October 2023, and all extensions must be migrated before then. After October 2023, the Retail SDK will no longer be released or supported.
When do I have to migrate?
Extensions must be migrated to the new Commerce SDK and new installers by October 2023.