Oplossingsconcepten

Oplossingen zijn het mechanisme voor het implementeren van Application Lifecycle Management (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 die erin zijn opgenomen, verwijderd. Alle onbeheerde aanpassingen blijven van kracht en maken deel uit van dezelfde standaardoplossing.

• Er worden beheerde oplossingen 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 95 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 componenten als in de voorgaande lijst, maar de meeste ervan zijn genest in andere componenten en 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:

• Maak auteur en exporteer onbeheerde oplossingen.

• Update Maak updates voor een beheerde oplossing die worden geïmplementeerd naar de bovenliggend beheerde oplossing. U kunt geen onderdelen verwijderen met een update.

• Upgrade Importeer de oplossing als een upgrade naar een bestaande beheerde oplossing, waarmee ongebruikte componenten worden verwijderd en upgradelogica wordt geïmplementeerd. Upgrades bestaan uit het samenvoegen van alle patches voor de oplossing tot een nieuwe versie van de oplossing. Bij upgrades van oplossingen worden componenten verwijderd die al bestonden, maar niet langer zijn opgenomen in de geüpgradede versie. 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 bovenliggend beheerde oplossing,, zoals het toevoegen of bewerken van componenten 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 het eigendom van een onderdeel van de ene oplossing naar de andere te verplaatsen 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. Vanwege deze beperking is het het beste om één enkele uitgever te definiëren, zodat u het lagenmodel later voor alle 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:

• Maak een oplossingsuitgever-prefix
• Wijzig een oplossingsuitgever-voorvoegsel

Afhankelijkheden van oplossingen

Vanwege de manier waarop beheerde oplossingen zijn opgebouwd, kunnen sommige beheerde oplossingen afhankelijk zijn van oplossingsonderdelen in andere beheerde oplossingen. Sommige oplossingenuitgevers maken hier gebruik van om modulaire oplossingen te bouwen. Mogelijk moet u eerst een "basis" beheerde oplossing installeren en vervolgens kunt u een tweede beheerde oplossing installeren waarmee u de componenten in de basis beheerde oplossing verder kunt aanpassen. 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 melding dat de oplossing vereist dat er eerst een andere oplossing wordt geïnstalleerd. Vanwege de afhankelijkheden kunt u de basisoplossing niet verwijderen zolang er nog 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
Creëer en beheer omgevingen in de Power Platform Beheercentrum