Engineer's Guide to CDS
Hi, I'm your fellow neighbor CDS Engineer's Guide and I'll help you to overcome any obstacles on the way. Be sure to start with this page where you can find the main concepts of solution driven development (declarative programming) on the Power Platform.
Solutions are referred to '.zip' packages which are used to move customizations between environments. It's the essential element of the Power Platform.
Common Data Service is the same thing for the Power Platform as the invisible hand for the market. You don't really see it, but it makes everything work.
It's making sure, that your stored data are accessible through all the apps, that all the business processes are applied on your data no matter what interface. It's the glue that unifies all the components.
Common Data Model is a standard and extensible collection of schemas (entities, attributes, relationships) that represents business concepts and activities with well-defined semantics, to facilitate data interoperability. GitHub repository.
Dynamics 365 is branding for first-party applications by Microsoft. Dynamics 365 for Sales, Service and Talent are also using CDS on the background. There are also other Dynamics 365 products but not all of them are built above the CDS yet.
This is probably the most important component, since it's hosting the infrastructure for CDS. But since it's completely managed by Microsoft (CDS is Software-as-a-Service) you can't really access these resources. Anyways, you should know that there is something like Azure behind the curtains.
Not to mention that almost all of extensions are going to use Azure or at least Azure Active Directory at some point.
ALM stands for Application Lifecycle Management. SLM stands for Solution Lifecycle Management - that's more common label for Power Platform since we are making 'solutions'.
There's no possibility to deliver quality product without SLM, that's the reason why this engineer's guide even exists, because you - developers/customizers - need to know how to work with it.
Independent Software Vendor is someone with CDS product ready to be deployed to multiple customers. There's big difference between usual Microsoft Partner who's trying to rip off customers for every cent, because they aren't able to create value, and ISV who has finished product which will help the customer grow.
Microsoft knows this and he's trying to eliminate bad Microsoft Partners and support ISVs. NETWORG is a great example - TALXIS is product, that we are able to support in time thanks to SLM.
Solution Framework was introduced in Dynamics CRM 2011 (v5.0) and it enabled ISVs to deliver their CDS solutions as a complete app package. It evolved through the years and it offers proper SLM if 'used right'. This guide should teach you what 'used right' means.
All supported customizations can be included in a package and be exported or imported out of or into the environment. This package is called 'solution'. Solution can be exported only from 'active layer' (more on that in solution layering) in two forms - unmanaged and managed.
An unmanaged solution is one that is still under development or isn’t intended to be distributed. It's strictly forbidden to deploy an unmanaged solution to non-development environment.
Managed solutions are installed on top of the system solution and can modify any customizable solution components or add new solution components.
As long as a managed solution enables customization of its solution components, other managed solutions can be installed on top of it and modify any customizable solution components that it provides. So managed solutions can be layered on top of each other.
Managed solutions are meant for distributing. You could almost say that unmanaged solutions are like debug configuration and managed ones are like release configuration.
You need to perfectly understand the solution layering before you start developing something. It's making solutions extensible. That's why we can deploy default TALXIS to every customer and then customize the components through other solutions.
The system solution represents the solution components defined within Common Data Service. Without any managed solutions or customizations, the system solution defines the default application behavior. These are managed solutions installed by Microsoft.
All unmanaged customizations (solutions) are in one layer - active layer. This is the main difference in comparison with managed solutions. If you import managed solution, it exists in separate layer. Actually one layer per component of the managed solution.
All unmanaged customizations can be viewed in default solution.
The ultimate behavior of an instance of Common Data Service for a specific organization is the culmination of the system solution, any managed solutions, and any unmanaged customizations.
User does not see the layers, he or she only consumes this last layer.
Look at the SiteMap component on the picture of the solution layering above. As you can see there are three solutions customizing it. But what's presented to the user in application behavior?
Here comes conflict resolution at hand with its two strategies merge and top wins.
User interface components (command bar, ribbons, forms, and site map) are merged. This means that the solution components are re-calculated from the lowest level to the highest so that the organization’s unmanaged customizations are the last to be applied.
For all other solution components any conflict is calculated in favor of the customization that is applied last. For managed solutions this usually means that the last solution installed is applied. However, there is a special case when an update to a managed solution is installed (imported) - option to maintain customizations.
You should be able to understand the solution concept and solution layering. Main source used for creating this page was Microsoft Docs.
-
Solution Lifecycle Management for CDS
- This document is going deeper with the concepts I'm introducing in this development guide