Solution layering

Wat is solution layering?

Solution layering is het mechanisme waarmee Power Platform meerdere definities van dezelfde solutioncomponent ordent. De lagen bepalen welke configuratie tijdens runtime zichtbaar en actief is.

Dataverse kent een systeemlaag, managed lagen en één actieve unmanaged laag. Managed updates, patches en pending upgrades kunnen binnen hun solution eveneens verschillende lagen vormen.

De lagen werken per component. Eén app kan dus een formulier met een actieve laag hebben, terwijl een andere tabel alleen de managed basis gebruikt.

De lagenstapel

Onderaan staat de systeemlaag met platformcomponenten en standaardgedrag. Daarboven komen managed solutions in installatievolgorde.

De actieve unmanaged laag staat boven managed lagen. Ze bevat alle rechtstreekse customizations in de omgeving, ook als makers verschillende unmanaged solutioncontainers gebruikten.

Binnen een managed solution vormen base, eventuele patches en een pending upgrade een eigen volgorde. Na Apply upgrade worden relevante lagen tot een nieuwe basis samengebracht.

Top-wins en mergegedrag

Voor veel componenten bepaalt de bovenste laag de runtime-eigenschap. Dit heet top-wins. Een kolomlengte uit een hogere laag overschrijft bijvoorbeeld de waarde uit een lagere laag.

Model-driven apps, forms en sitemaps gebruiken voor bepaalde onderdelen mergegedrag. Elementen uit verschillende lagen kunnen worden gecombineerd in plaats van volledig vervangen.

Merge betekent niet dat iedere combinatie logisch is. Conflicterende aanpassingen kunnen een resultaat geven dat technisch geldig maar functioneel onverwacht is.

Een formulierincident

Een managed basissolution levert een dossierformulier. Een tweede managed solution voegt een tab voor compliance toe. Daarna verbergt een beheerder in productie rechtstreeks een veld.

Die laatste wijziging komt in de actieve laag en staat boven beide managed lagen. Een volgende release wijzigt het veld in de basissolution, maar gebruikers zien de productieaanpassing nog steeds.

De laaginspectie toont welke solution iedere property heeft geïntroduceerd. Het team verwerkt de gewenste wijziging in bronbeheer en verwijdert daarna de actieve laag.

Update, upgrade en uninstall

Een update legt een nieuwe versie over een bestaande managed solution. Een staged upgrade maakt tijdelijk een pending upgrade-laag. Apply upgrade vervangt de oude basis en kan componenten verwijderen die niet meer in de nieuwe versie zitten.

Wanneer een managed solution wordt verwijderd, kan de onderliggende laag opnieuw zichtbaar worden. Dat herstel van ouder gedrag is normaal laaggedrag, maar data en dependencies kunnen uninstall blokkeren of riskant maken.

Plan daarom niet op basis van alleen wat nu bovenaan staat. Begrijp welke componenteigenaar en afhankelijkheden onder de actieve definitie liggen.

Meerdere managed solutions

Een hogere managed solution kan componenten van een lagere publisher uitbreiden wanneer managed properties dat toelaten. Dit ondersteunt basis- en appmodules, maar creëert afhankelijkheden.

Gebruik dezelfde publisher waar componenten één productfamilie vormen en organiseer solutions rond stabiele modules. Te veel kruislingse extensies maken installatievolgorde en upgrades moeilijk te doorgronden.

Controleer dependencies vóór export en test alle ondersteunde installatie- en upgradepaden.

Diagnose met solution layers

Wanneer een release niet het verwachte gedrag toont, controleer eerst of de juiste versie is geïmporteerd en inspecteer daarna de lagen van het betrokken component.

Zoek naar actieve customizations, een hogere managed extensie, een achtergebleven patch of pending upgrade. Vergelijk niet alleen solutionversies; het probleem kan op één property zitten.

Documenteer de oorzaak voordat een laag wordt verwijderd. Een actieve laag kan ongewenst zijn, maar ook een niet-vastgelegde productiecorrectie bevatten.

Ontwerpregels

Houd productie vrij van unmanaged customizations en lever wijzigingen via de ontwikkelbron. Gebruik managed solutions in doelomgevingen.

Beperk solutionafhankelijkheden, gebruik stabiele publishers en oefen update, upgrade en uninstall in een representatieve testomgeving.

Solution layering is geen fout in het platform, maar een compositiemodel. Betrouwbare ALM vraagt dat teams weten welke laag eigenaar is van ieder kritiek component.