Oplossingsconcepten

Oplossingen zijn het mechanisme voor het implementeren van ALM in Power Apps en Power Automate. Dit artikel beschrijft de volgende belangrijke oplossingsconcepten:

• Twee typen oplossingen
• Onderdelen van oplossing
• De levenscyclus van een oplossing
• Oplossingsuitgever
• Afhankelijkheden van oplossing en oplossingsonderdelen

Beheerde en onbeheerde oplossingen

Een oplossing is beheerd of onbeheerd.

• Er worden Onbeheerde oplossingen ontwikkeld. Onbeheerde oplossingen worden gebruikt in ontwikkelomgevingen terwijl u wijzigingen aanbrengt in uw toepassing. Onbeheerde oplossingen kunnen worden geëxporteerd als een onbeheerd of beheerd. Geëxporteerde onbeheerde versies van uw oplossingen moeten worden ingecheckt in uw bronbeheersysteem. Onbeheerde oplossingen moeten worden beschouwd als uw bron voor Microsoft Power Platform-assets. Wanneer een onbeheerde oplossing wordt verwijderd, wordt alleen de oplossingscontainer met eventuele aanpassingen verwijderd. Alle onbeheerde aanpassingen blijven van kracht en maken deel uit van dezelfde standaardoplossing.

• Beheerde oplossingen worden geïmplementeerd. Beheerde oplossingen worden geïmplementeerd in elke omgeving die geen ontwikkelomgeving is voor die oplossing. Dit omvat test-, UAT-, SIT- en productieomgevingen. Beheerde oplossingen kunnen onafhankelijk van andere beheerde oplossingen in een omgeving worden onderhouden. De aanbevolen ALM-procedure is om beheerde oplossingen te genereren door een onbeheerde oplossing te exporteren als beheerd en deze te beschouwen als een build-artefact. En verder:

  • U kunt de onderdelen niet rechtstreeks in een beheerde oplossing bewerken. Als u beheerde onderdelen wilt bewerken, voegt u deze eerst toe aan een onbeheerde oplossing.
    • Als u dit doet, maakt u een afhankelijkheid tussen uw onbeheerde aanpassingen en de beheerde oplossing. Als er een afhankelijkheid bestaat, kan de beheerde oplossing pas worden verwijderd als u de afhankelijkheid verwijdert.
  • Sommige beheerde onderdelen kunnen niet worden bewerkt. Als u wilt controleren of een onderdeel kan worden bewerkt, geeft u de Beheerde eigenschappen weer.
  • U kunt een beheerde oplossing niet exporteren.
  • Wanneer een beheerde oplossing wordt verwijderd (als de installatie ongedaan wordt gemaakt), worden alle aanpassingen en uitbreidingen van de oplossing verwijderd.

  Belangrijk

  • U kunt een beheerde oplossing niet importeren in dezelfde omgeving als die waarin de oorspronkelijke onbeheerde oplossing is opgeslagen. Als u een beheerde oplossing wilt testen, moet u een afzonderlijke omgeving maken en de oplossing hierin importeren.
  • De volgende gegevens gaan verloren wanneer u een beheerde oplossing verwijdert: gegevens die zijn opgeslagen in aangepaste entiteiten die deel uitmaken van de beheerde oplossing en gegevens die zijn opgeslagen in aangepaste kenmerken die deel uitmaken van de beheerde oplossing voor andere entiteiten die geen deel uitmaken van de beheerde oplossing.

Makers en ontwikkelaars werken in ontwikkelomgevingen met onbeheerde oplossingen en importeren deze vervolgens in andere downstreamomgevingen, zoals test, als beheerde oplossingen.

Notitie

Wanneer u aanpassingen maakt in de ontwikkelomgeving, werkt u in de onbeheerde laag. Wanneer u vervolgens de onbeheerde oplossing exporteert als beheerde oplossing voor distributie naar een andere omgeving, wordt de beheerde oplossing geïmporteerd in de omgeving in de beheerde laag. Meer informatie: Oplossingslagen

Onderdelen van oplossing

Een onderdeel is iets dat u mogelijk kunt aanpassen. Alles wat in een oplossing kan worden opgenomen, is een onderdeel. Open de gewenste oplossing om de onderdelen in een oplossing te bekijken. De componenten worden vermeld in de lijst Componenten.

Notitie

• Een oplossing kan maximaal 32 MB groot zijn.
• U kunt de onderdelen niet rechtstreeks in een beheerde oplossing bewerken.

Voor een lijst met componenttypen die aan elke oplossing kunnen worden toegevoegd, zie ComponentType-opties.

Sommige onderdelen zijn genest in andere onderdelen. Een entiteit bevat bijvoorbeeld formulieren, weergaven, grafieken, velden, entiteitsrelaties, berichten en bedrijfsregels. Elk van die onderdelen vereist een entiteit om te bestaan. Een veld kan niet buiten een entiteit bestaan. We zeggen dat het veld afhankelijk is van de entiteit. Er zijn twee keer zoveel typen onderdelen als er worden weergegeven in de lijst hierboven, maar de meeste zijn in andere onderdelen genest en zijn niet zichtbaar in de toepassing.

Het doel van onderdelen is het bijhouden van eventuele beperkingen of wat kan worden aangepast met beheerde eigenschappen en alle afhankelijkheden, zodat het kan worden geëxporteerd, geïmporteerd en (in beheerde oplossingen) verwijderd zonder iets achter te laten.

De levenscyclus van oplossingen

Oplossingen ondersteunen de volgende acties die de levenscyclusprocessen van toepassingen ondersteunen:

• Maken Maak en exporteer onbeheerde oplossingen.

• Updaten Maak updates van een beheerde oplossing die worden geïmplementeerd naar de bovenliggende beheerde oplossing. U kunt geen onderdelen verwijderen met een update.

• Upgraden Importeer de oplossing als een upgrade naar een bestaande beheerde oplossing, die ongebruikte onderdelen verwijdert en upgradelogica implementeert. Upgrades bestaan uit het samenvoegen van alle patches voor de oplossing tot een nieuwe versie van de oplossing. Oplossingenupgrades verwijderen onderdelen die bestonden, maar niet meer in de upgradeversie zijn opgenomen. U kunt ervoor kiezen onmiddellijk te upgraden of de upgrade te faseren, zodat u enkele aanvullende acties kunt uitvoeren voordat u de upgrade voltooit.

• Patch Een patch bevat alleen de wijzigingen voor een bovenliggende beheerde oplossing, zoals het toevoegen of bewerken van onderdelen en assets. Gebruik patches bij het maken van kleine updates (vergelijkbaar met een hotfix). Wanneer patches worden geïmporteerd, worden ze in een laag boven op de bovenliggende oplossing geïmplementeerd. U kunt geen onderdelen verwijderen met een patch.

Oplossingsuitgever

Elke app en andere oplossingsonderdelen zoals entiteiten die u maakt of elke aanpassing die u maakt, maakt deel uit van een oplossing. Omdat elke oplossing een uitgever heeft, moet u uw eigen uitgever maken in plaats van de standaard te gebruiken. Als u een oplossing maakt, geeft u de uitgever aan.

Notitie

Zelfs als u geen aangepaste oplossing gebruikt, werkt u in oplossingen die bekend staan als de Common Data Service-standaardoplossing en de standaardoplossingen. Meer informatie: Standaardoplossing en Common Data Service-standaardoplossing

De uitgever van een oplossing waar een onderdeel wordt gemaakt, wordt beschouwd als de eigenaar van dat onderdeel. De eigenaar van een onderdeel bepaalt welke wijzigingen andere uitgevers van oplossingen inclusief dat onderdeel mogen maken of mogen beperken. Het is mogelijk om het eigendom van een onderdeel van de ene oplossing naar de andere over te brengen binnen dezelfde uitgever, maar niet tussen uitgevers. Zodra u een uitgever voor een onderdeel in een beheerde oplossing introduceert, kunt u de uitgever voor het onderdeel niet meer wijzigen. Daarom is het het best om één uitgever te definiëren, zodat u het gelaagdheidsmodel later voor verschillende oplossingen kunt wijzigen.

De oplossingsuitgever geeft aan wie de app heeft ontwikkeld. Om deze reden moet u een oplossingsuitgevernaam maken die zinvol is.

Voorvoegsel oplossingsuitgever

Een oplossingsuitgever bevat een voorvoegsel. Het voorvoegsel van de uitgever is een mechanisme om te voorkomen dat dezelfde namen worden gemaakt. Hierdoor kunnen oplossingen van verschillende uitgevers met weinig conflicten in een omgeving worden geïnstalleerd. De Contoso-oplossing die hier wordt weergegeven, bevat bijvoorbeeld de oplossingsuitgever-voorvoegsel contoso.

Notitie

Wanneer u een oplossingsuitgever-voorvoegsel wijzigt, moet u dit doen voordat u nieuwe apps of metagegevensitems maakt, omdat u de namen van metagegevensitems niet kunt wijzigen nadat ze zijn gemaakt.

Meer informatie:

• Een voorvoegsel voor een oplossingsuitgever maken
• Het voorvoegsel van een oplossingsuitgever wijzigen

Afhankelijkheden van oplossingen

Vanwege de manier waarop beheerde oplossingen zijn opgebouwd, kunnen sommige beheerde oplossingen afhankelijk zijn van oplossingsonderdelen in andere beheerde oplossingen. Sommige oplossingsuitgevers maken hiervan gebruik om oplossingen te bouwen die modulair zijn. U moet misschien eerst een beheerde "basisoplossing" installeren. Daarna kunt u een tweede beheerde oplossing installeren die de onderdelen in de beheerde basisoplossing verder aanpast. De tweede beheerde oplossing is afhankelijk van oplossingsonderdelen die deel uitmaken van de eerste oplossing.

Het systeem houdt deze afhankelijkheden tussen oplossingen bij. Als u een oplossing probeert te installeren die een basisoplossing vereist die niet is geïnstalleerd, kunt u de oplossing niet installeren. U krijgt een bericht waarin wordt aangegeven dat er een andere oplossing nodig is voordat de oplossing kan worden geïnstalleerd. Vanwege de afhankelijkheden kunt u de basisoplossing ook niet deïnstalleren terwijl er een oplossing is geïnstalleerd die ervan afhankelijk is. U moet de afhankelijke oplossing deïnstalleren voordat u de basisoplossing kunt verwijderen. Meer informatie: Afhankelijkheden verwijderen

Afhankelijkheden van oplossingsonderdelen

Een oplossingsonderdeel is iets dat u kunt mogelijk aanpassen. Alles wat in een oplossing kan worden opgenomen, is een oplossingsonderdeel en sommige onderdelen zijn afhankelijk van andere onderdelen. Het websiteveld en het accountoverzichtsrapport zijn bijvoorbeeld beide afhankelijk van de accountentiteit. Meer informatie: Afhankelijkheden traceren voor oplossingsonderdelen

Zie ook

Oplossingslagen
Omgevingen maken en beheren in het Power Platform-beheercentrum