Category: Dynamics 365

While doing some R&D for an upcoming XrmToolbox plugin I was curious about how Microsoft itself gathers metadata about solution components related to dependent solutions, unmanaged changes and the “mysterious” Active Solution. I had some closer look on some inner mechanics of Dynamics 365 apps and decided to simply write down my observations. Why this should be of interest for you or me? Well, like in many fields, when collaboration is the modus operandi (=multiple people working on the same subject), at some point it starts to becomes hard to maintain control and confidence of changes. To have a clear and definitive picture about what changed how and when, would therefore make life easier in these contexts.

In the context of CDS, assuming that one might keep 100% control of changes, will sooner or later turn out as naive thinking. Back in the good ol’ on-premise days, this assumption could proof correct for several years, but for most Dynamics 365 customers, this era is over. The online-only platform as we have it with CDS/D365 does and hopefully will evolve, innovate and thus change at a high pace and the reasons for these change will constantly increase. Active system development and customization by partners and customers alike being only one of it. Just have a look at the Solution History area in the system settings, and you will quickly realize how many things (patches, updates asf.) are taking place behind the curtains without users or administrators noticing most of it. With new first-party product addons by Microsoft or 3rd-party through AppSource, this change frequency will even increase further. Some of the more obvious signs that a platform patch/update was installed in the background, are f.e. standard entity forms being modified or even random regression bugs being introduced with a newer version. Those impacts are typically impossible to foresee and thus cannot be regression tested *before* in an automated way. Unfortunately I encountered event cases where customers reported issues in productive environments and only after raising a MS support ticket it turned out as a platform issue or similar. But this would lead to a different topic, about which btw. Jason Lattimer did write about almost exactly one year ago (the referred package is no longer available as of today).

So, instead of trying desperately to keep control of any changes, I started to realistically assess what is and will continue to be under my control as system architect and developer, and what not. My first insights: it needs a special kind of spiritual attitude in order to stay relaxed, what I call “hope competence”: optimistic confidence in the success of Microsoft’s platform and product updates and releases in general. 😁 My second (and admittedly more serious) insight: I need a way to continously observe and track (unmanaged) changes to any solution and solution component relevant for any given CDS/D365 solution I going to maintain. Such a clarity would give back transparency and thus confidence, and also give back a certain degree of control, because by knowing What did change How and When, we are able to react accordingly if needed. In the long term, I would expect similar capabilities to be added to the Solution Checker solution, which is actually kind of a rule checker engine running predefined rule sets periodically.

Trust is good, but control is even better — let’s do an short excourse on what possibibilites we have to identify and trace changes to solution components (like Entities, Forms, Views, Webresources, Workflows asf.) we have in our systems:

• Solution Layers (Entity “msdyn_componentlayers”)
• Dependency nodes (Entity “dependencynode”)
• Internal-only organization message “RetrieveSolutionMetadataForComponent”

Solution Layers (Supported)

Not so long ago, Microsoft introduced a feature called Solution layers to the CDS system standard without much fanfare. Technically, it’s a read-only virtual entity msdyn_componentlayers which just holds a handful of attributes and which must be queried by stating a component id as well as its type in order to yield some actual data. From a UI perspective, the only touchpoint to this addition is a small button labelled “Solution layers” (or “Lösungsebenen” in german) inserted to the toolbar of the legacy solution editor window.

This, ladies and gentlemen, is literally the tip of the iceberg. For this feature, professional system customizers and developers have been waiting since the early days of Dynamics CRM. It’s nothing more than *the* decent, highly specialized and at the same time dead simple way to

1. discover and identify (even unmanaged) customizations of any solution component across all solutions referencing it (called Solution Layers)
2. analyze customizations/changes introduced by any solution and compare between different solutions
3. last, but not least, be able to revert any unmanaged change from the Active solution

For me personally, as well as probably for most professional system architects/customizers/devs/yourrolehere who have a XRM/CRM background ranging back into earlier on-premise CRM days, the third aspect is probably the most inspiring one. When you had to clean up unmanaged changes in systems adhering to managed-only solution deployment strategies, you probably had to come up with obscure MSSQL DB manipulations or preparation of holding solutions, uninstalling, reinstalling asf. … you know the pain and will be probably more than happy about this feature addition. During a recent talk to some Microsoft support engineeres, they chimed in that even they themself are happy about having an easy analysis tool like things at hand now.

Dependency nodes (Supported)

Found in assembly Microsoft.Dynamics.PowerAppsChecker.Plugins.dll (Method WebResourceModel.GetModifiedWebResources(...) ) where it is used to quickly determine if certain webresources have been modified and thus also are referenced by solutions other than the predefined ones.

I already saw the dependencynode entity in the system metadata several times, but didn’t think about it much, until now. As the name implies, it is kind of abstract data structure that is used to build up an graph structure for tracking dependencies between solution components like Entities, Attributes, Views, asf.. This system entity is read-only and assumably for internal purposes only, given the fact that there is no publicly available information oder documentation about it other than the formal entity reference in Microsoft documentation (google for it). Given the nature and purpose of this data, I guess that these records are created by the CDS platform in the background when performing solution imports/exports or any other related activity, so that dependencynode records in the end act as materialized dependencies with a focus on inter-solution dependencies (as opposed to the more component focussed dependency entity).

Data-wise it looks like this:

Value	Label
0	None
1	Solution Internal
2	Published
4	Unpublished

Flattened records, building up an abstract graph structure

Internal org-message “RetrieveSolutionMetadataForComponent” (Unsupported)

Found in assembly Microsoft.Dynamics.SalesHealth.Plugins.dll (Method SolutionRepository.GetSolutionIdsFromSolutionLayers(...) ) where it is used to quickly determine if certain managed forms have been customized and thus also are referenced by the Active solution.

This organization message yields list of metadata about solutions which carry changes to the originally requested solution component and thus reference it in some way. The result looks quite similar as when fetching msdyn_componentlayers records, albeit data-wise its pretty reduced. But that’s ok, what we have here is kind of simplified and concise intent to just get a list of any solution holding changes to a given solution component. For example, this data can be used then to easily determine if a given solution component was modified, by checking if the Active Solution (which has always the same GUID) is contained in the list of solutions contained in the message reesponse.

However, what I cannot tell yet is, if the order in which the solutions are contained in response EntityCollection corresponds to their installation dates and thus their layering order in the system. Let’s have another look at it.

Hands on

Come on, I know why you came over to my blog. 😋 Here we go:

Summary

All the methods shown in this article have one thing in common: they