Maak patches om oplossingupdates te vereenvoudigen

Artikel
03/04/2017

Gepubliceerd: januari 2017

Is van toepassing op: Dynamics 365 (online), Dynamics 365 (on-premises), Dynamics CRM 2016, Dynamics CRM Online

Wanneer een entiteit aan een oplossing wordt toegevoegd en die oplossing wordt geëxporteerd, worden de entiteit en alle bijbehorende activa geëxporteerd in die oplossing. Onder deze actival vallen kenmerken, formulieren, weergaven, relaties, visualisaties en alle andere activa die met de entiteit zijn verpakt. Het exporteren van alle objecten betekent dat u objecten op de doelinstallatie per ongeluk kunt wijzigen, of onbedoelde afhankelijkheden kunt overbrengen.

Om dit probleem op te lossen, kunt u oplossingpatches maken en publiceren die subcomponenten van entiteiten bevatten in plaats van de hele entiteit en al zijn activa te publiceren. De oorspronkelijke oplossing en een of meer gerelateerde patches kunnen later in een bijgewerkte versie van de oplossing worden samengevoegd, die vervolgens de oorspronkelijke oplossing kan vervangen in de Microsoft Dynamics 365-doelorganisatie.

Patches

U kunt patches toepassen op beheerde of onbeheerde oplossingen en alleen wijzigingen aan entiteiten en gerelateerde entiteitactiva toevoegen. Patches bevatten geen niet-aangepaste systeemonderdelen of relaties waarvan het afhankelijk is, omdat deze onderdelen al bestaan in de doelorganisatie. Op een bepaald moment in uw ontwikkelingscyclus kunt u alle patches samenvoegen tot een nieuwe oplossingsversie om de oorspronkelijke oplossing te vervangen op basis waarvan de patches zijn gemaakt.

Patches worden opgeslagen in de Dynamics 365-database als Solution-entiteitsrecords. Een niet-null ParentSolutionId-kenmerk geeft aan dat de oplossing een patch is. Patches kunnen door de organisatieservice of web-API´s worden gemaakt en beheerd, die handig zijn voor automatisering, zoals een productinstallatiescript. De Dynamics 365-webtoepassing biedt echter verschillende webformulieren waarmee u interactief patches kunt maken en beheren.

Patches kunnen alleen vanuit een bovenliggende oplossing worden gemaakt met CloneAsPatchRequest of CloneAsPatch Action.
Het bovenliggende item mag geen patch zijn.
Patches mogen maar één bovenliggende oplossing hebben.
Een patch creëert een afhankelijkheid (op het oplossingniveau) van de bovenliggende oplossing.
U kunt een patch alleen installeren als de bovenliggende oplossing aanwezig is.
U kunt geen patch installeren, tenzij de unieke naam en het primaire/secundaire versienummer van de bovenliggende oplossing, zoals geïdentificeerd door ParentSolutionId, niet overeenkomen met die van de bovenliggende oplossing die in de doelorganisatie is geïnstalleerd.
Een patchversie moet hetzelfde primaire en secundaire nummer hebben, maar een hogere build- en versienummer dan de bovenliggende oplossing. Weergavenaam kan afwijken.
Als een oplossing patches heeft, moeten de volgende patches een hoger versienummer hebben dan alle bestaande patches voor die oplossing.
Patches ondersteunen dezelfde bewerkingen als oplossingen, zoals bijkomende updates, maar geen verwijderingen. U kunt geen onderdelen uit een oplossing verwijderen met een patch. Als u onderdelen wilt verwijderen uit een oplossing, voert u een upgrade uit.
Patches die als beheerde items zijn geëxporteerd, moeten boven op de bovenliggende beheerde oplossing worden geïmporteerd. De regel is dat de patchbeveiliging (beheerd of onbeheerd) moet overeenkomen met die van het bovenliggende element.
Gebruik geen onbeheerde patches voor productiedoeleinden.
Patches worden alleen ondersteund in Dynamics 365-organisaties van versie 8.0 of hoger.

De hulpprogramma´s SolutionPackager en PackageDeployer in deze versie ondersteunen oplossingpatches. Raadpleeg de online Help van het hulpprogramma voor opdrachtregelopties die aan patches zijn gerelateerd.

Patch maken

Maak een patch vanuit een onbeheerde oplossing in een organisatie met het bericht CloneAsPatchRequest of CloneAsPatch Action, of met de webtoepassing. Zodra u de patch hebt gemaakt, wordt de oorspronkelijke oplossing vergrendeld en kunt u deze niet meer wijzigen of exporteren zolang er in de organisatie afhankelijke patches zijn die de oplossing identificeren als bovenliggende oplossing. Versiebeheer voor patches is vergelijkbaar met oplossingsversiebeheer en heeft de volgende indeling: primair.secundair.build.versie. U kunt geen wijzigingen aan de bestaande primaire of secundaire oplossingversies aanbrengen als u een patch maakt.

Een patch importeren en exporteren

U kunt de organisatieservice of web-Api's, de webtoepassing of Hulpmiddel Pakketimplementatie gebruiken om een patch te exporteren en te importeren. De relevante berichtaanvragen van de organisatieservice zijn ImportSolutionRequest en ExportSolutionRequest. De relevante acties voor de Web API zijn ImportSolution Action en ExportSolution Action.

Voorbeelden van patches

In de volgende tabel vindt u informatie over een voorbeeld van een patch. Houd er rekening mee dat in dit voorbeeld de oplossing en patches in numerieke volgorde worden geïmporteerd en dat ze iets toevoegen (en niet verwijderen), wat altijd hoort te gelden voor te importeren oplossingen.

Patchnaam	Beschrijving
SolutionA, versie 1.0 (onbeheerd)	Bevat entityA met 6 velden.
SolutionA, versie 1.0.1.0 (onbeheerd)	Bevat entityA met 6 velden (3 bijgewerkt) en voegt entityB toe met 10 velden.
SolutionA, versie 1.0.2.0 (onbeheerd)	Bevat entityC met 10 velden.

Het importproces gaat als volgt.

De ontwikkelaar of systeemaanpasser importeert eerst de basisoplossing (SolutionA 1.0 )in de organisatie. Het resultaat is entityA met 6 velden in de organisatie.
Vervolgens wordt SolutionA-patch 1.0.1.0 geïmporteerd. De organisatie bevat nu entityA met 6 velden (3 bijgewerkt) en entityB met 10 velden.
Ten slotte wordt SolutionA-patch 1.0.2.0 geïmporteerd. De organisatie bevat nu entityA met 6 velden (3 bijgewerkt), entityB met 10 velden en entityC met 10 velden.

Nog een voorbeeld

Laten we nog een voorbeeld van een patch bekijken, waarbij de gegevens in de volgende tabel worden vermeld.

Patchnaam	Beschrijving
SolutionA, versie 1.0 (onbeheerd, basisoplossing)	Bevat de Account-entiteit, waarbij de lengte van het accountnummerveld wordt gewijzigd van 20 in 30 tekens.
SolutionB, versie 2.0 (onbeheerd, andere leverancier)	Bevat de Account-entiteit, waarbij de lengte van het accountnummerveld wordt gewijzigd in 50 tekens.
SolutionA, versie 1.0.1.0 (onbeheerd, patch)	Bevat een update voor de Account-entiteit, waarbij de lengte van het accountnummerveld wordt gewijzigd in 35 tekens.

Het importproces gaat als volgt:

De ontwikkelaar of systeemaanpasser importeert eerst de basisoplossing (SolutionA 1.0 )in de organisatie. Het resultaat is een Account-entiteit met een accountnummerveld van 30 tekens.
SolutionB is geïmporteerd. De organisatie bevat nu een Account-entiteit met een accountnummerveld van 50 tekens.
SolutionA-patch 1.0.1.0 is geïmporteerd. De organisatie bevat nog steeds een Account-entiteit met een accountnummerveld van 50 tekens, zoals toegepast door SolutionB.
SolutionB is verwijderd. De organisatie bevat nu een Account-entiteit met een accountnummerveld van 35 tekens, zoals toegepast door de SolutionA 1.0.1.0-patch.

Een patch verwijderen

U kunt een patch of (bovenliggende) basisoplossing verwijderen met DeleteRequest of, in het geval van de Web API, de HTTP DELETE-methode. Het verwijderingsproces verschilt voor een beheerde of een onbeheerde oplossing met een of meer bestaande patches in de organisatie.

Voor een onbeheerde oplossing moet u alle patches voor de basisoplossing eerst verwijderen in omgekeerde volgorde als waarin ze zijn gemaakt, voordat u de basisoplossing verwijdert.

Bij een beheerde oplossing verwijdert u de basisoplossing gewoon. Het Dynamics 365-systeem verwijdert de patches automatisch in omgekeerde versievolgorde voordat de basisoplossing wordt verwijderd. U kunt ook maar één patch verwijderen.

Oplossing bijwerken

Het bijwerken van een oplossing bestaat uit het samenvoegen van alle patches voor die oplossing tot een nieuwe versie van de oplossing. Vervolgens wordt die oplossing ontgrendeld en kan deze weer worden gewijzigd (geldt alleen voor een onbeheerde oplossing) of geëxporteerd. Bij een beheerde oplossing kunt u niet nog verdere aanpassingen van de oplossing aanbrengen, behalve patches vanuit de zojuist bijgewerkte oplossing. Als u patches wilt samenvoegen tot een onbeheerde oplossing, gebruikt u CloneAsSolutionRequest of CloneAsSolution Action. Door een beheerde oplossing te klonen, maakt u een nieuwe versie van de onbeheerde oplossing waarin alle patches zijn samengevoegd, met een hoger primair.secundair versienummer, dezelfde unieke naam en een weergavenaam.

Bij een beheerde oplossing gaat dit net even anders. U kloont eerst de onbeheerde oplossing (A), waarbij alle patches worden samengevoegd, en exporteert deze vervolgens als beheerde oplossing (B). In de doelorganisatie die de beheerde versie van oplossing (A) en de bijbehorende patches bevat, importeert u beheerde oplossing (B) en voert u vervolgens DeleteAndPromoteRequest of DeleteAndPromote Action uit om beheerde oplossing (A) en de bijbehorende patches te vervangen door de geüpgradede beheerde oplossing (b) die een hoger versienummer heeft.

Zie ook

TechNet: Gesegmenteerde oplossingen en patches gebruiken om oplossingsupdates te vereenvoudigen
Plan voor oplossingontwikkeling
Uitbreidingen inpakken en verdelen met oplossingen
Berichten en methoden van de entiteit Solution
Beheerde oplossingen onderhouden
Uw app registreren bij AppSource

Microsoft Dynamics 365

Delen via