Creare le patch per semplificare gli aggiornamenti della soluzione

Articolo
03/04/2017

Data di pubblicazione: gennaio 2017

Si applica a: Dynamics 365 (online), Dynamics 365 (on-premises), Dynamics CRM 2016, Dynamics CRM Online

Se hai aggiunto un'entità a una soluzione e hai esportato la soluzione, l'entità e i relativi cespiti vengono esportati nella soluzione. Questi cespiti includono gli attributi, i moduli, le viste, le relazioni, le visualizzazioni e tutti gli altri cespiti presenti nell'entità. L'esportazione di tutti gli oggetti indica che puoi in modo non intenzionale modificare gli oggetti nella distribuzione di destinazione o modificare le dipendenze non intenzionali.

Per risolvere la questione, puoi creare e pubblicare le patch della soluzione contenenti i componenti secondari delle entità anziché pubblicare l'intera entità e tutti i relativi cespiti. La soluzione originale e una o più patch correlate possono essere sottoposte al rollup (merge) in un secondo momento in una versione aggiornata della soluzione che potrà quindi sostituire la soluzione originale nell'organizzazione Microsoft Dynamics 365 di destinazione.

Patch

Puoi applicare le patch alle soluzioni gestite e non gestite e includere solo le modifiche alle entità e ai cespiti di entità correlati. Le patch non includono relazioni o componenti di sistema non personalizzati da cui dipendono perché questi componenti già esistono nell'organizzazione di destinazione della distribuzione. A un certo punto del ciclo di sviluppo, puoi eseguire il rollup di tutte le patch in una nuova versione della soluzione per sostituire la soluzione originale da cui sono state create le patch.

Le patch vengono archiviate nel database Dynamics 365 come record dell'entità Solution. L'attributo non null ParentSolutionId indica che la soluzione è una patch. Le patch possono essere create e gestite tramite le API Web o del servizio organizzazione che sono utili per sviluppare l'automazione, ad esempio uno script di installazione del prodotto. Tuttavia, nell'applicazione Web Dynamics 365 sono disponibili diversi moduli Web che ti consentono di creare e gestire le patch in modo interattivo.

Le patch possono essere create solo da una soluzione padre utilizzando CloneAsPatchRequest o CloneAsPatch Action.
L'elemento padre della patch non può essere una patch.
Le patch possono avere solo una soluzione padre.
La patch crea una dipendenza (a livello di soluzione) sulla relativa soluzione padre.
Puoi installare una patch solo se la soluzione padre è presente.
Non puoi installare la patch a meno che il nome univoco e il numero della versione principale/secondaria della soluzione padre, come identificato da ParentSolutionId, non corrispondano a quelli della soluzione padre installata nell'organizzazione di destinazione.
La versione della patch deve essere lo stesso numero di versione principale e secondaria, ma un numero di rilascio e build superiore al numero di versione della soluzione padre. Il nome visualizzato può essere diverso.
Se una soluzione dispone di patch, le patch successive devono avere un numero di versione numericamente superiore a qualsiasi patch esistente per tale soluzione.
Le patch supportano le stesse operazioni supportate dalle soluzioni, ad esempio l'aggiornamento additivo, ma non la rimozione. Non puoi rimuovere i componenti da una soluzione utilizzando una patch. Per rimuovere i componenti da una soluzione esegui un aggiornamento.
Le patch esportate come gestite devono essere importate all'inizio di una soluzione padre gestita. La regola è che la protezione della patch (gestita o non gestita) deve corrispondere all'elemento padre.
Non utilizzare le patch non gestite per scopi di produzione.
Le patch sono supportate solo nelle organizzazioni Dynamics 365 8.0 o versione successiva.

Gli strumenti SolutionPackager e PackageDeployer di questa versione supportano le patch della soluzione. Vedi la Guida in linea dello strumento per le opzioni della riga di comando correlate alle patch.

Creare una patch

Creare una patch da una soluzione non gestita in un'organizzazione tramite il messaggio CloneAsPatchRequest o CloneAsPatch Action o utilizzando l'applicazione Web. Dopo aver creato la patch, la soluzione originale viene bloccata e non puoi modificarla né esportarla finché vi sono patch dipendenti presenti nell'organizzazione che identificano la soluzione come la soluzione padre. Il controllo delle versioni delle patch è simile al controllo delle versioni della soluzione e viene specificato nel formato seguente: major.minor.build.release. Non puoi apportare modifiche alle versioni principale o secondaria esistenti della soluzione quando crei la patch.

Esportare e importare una patch

Puoi utilizzare le API Web o del servizio organizzazione, l'applicazione Web o lo Strumento Package Deployer per esportare e importare una patch. Le richieste di messaggio del servizio organizzazione pertinenti sono ImportSolutionRequest e ExportSolutionRequest. Le azioni pertinenti per l'API Web sono ImportSolution Action e ExportSolution Action.

Esempi di patch

Nella tabella seguente sono elencati i dettagli di un esempio di patch. Nota che in questo esempio, la soluzione e le patch vengono importate nell'ordine numerico e sono additive, in modo coerente con l'importazione di una soluzione in generale.

Nome della patch	Descrizione
SolutionA, versione 1.0 (non gestita)	Contiene entityA con 6 campi.
SolutionA, versione 1.0.1.0 (non gestita)	Contiene entityA con 6 campi (3 aggiornati) e aggiunge entityB con 10 campi.
SolutionA, versione 1.0.2.0 (non gestita)	Contiene entityC con 10 campi.

Il processo di importazione è indicato di seguito.

Lo sviluppatore o l'addetto alla personalizzazione importa prima la soluzione di base (SolutionA 1.0) nell'organizzazione. Il risultato è entityA con 6 campi nell'organizzazione.
Successivamente, viene importata la patch SolutionA 1.0.1.0. L'organizzazione ora contiene entityA con 6 campi (3 sono stati aggiornati) ed entityB con 10 campi.
Infine viene importata la patch SolutionA 1.0.2.0. L'organizzazione ora contiene entityA con 6 campi (3 sono stati aggiornati), entityB con 10 campi ed entityC con 10 campi.

Un altro esempio di patch

Esamina un altro esempio di patch con i dettagli elencati nella tabella seguente.

Nome della patch	Descrizione
SolutionA, versione 1.0 (non gestito, soluzione di base)	Contiene l'entità Account in cui la lunghezza del campo di numero account è regolata tra 20 e 30 caratteri.
SolutionB, versione 2.0 (non gestito, fornitore diverso)	Contiene l'entità Account in cui la lunghezza del campo di numero account è regolata a 50 caratteri.
SolutionA, versione 1.0.1.0 (non gestita, patch)	Contiene un aggiornamento per l'entità Account in cui la lunghezza del campo di numero account è regolata a 35 caratteri.

Il processo di importazione è indicato di seguito:

Lo sviluppatore o l'addetto alla personalizzazione importa prima la soluzione di base (SolutionA 1.0) nell'organizzazione. Il risultato è un'entità Account con un campo di numero account di 30 caratteri.
Viene importato SolutionB. L'organizzazione ora contiene un'entità Account con un campo di numero account di 50 caratteri.
Viene importata la patch SolutionA 1.0.1.0. L'organizzazione ancora contiene un'entità Account con un campo di numero account di 50 caratteri, come applicato da SolutionB.
Viene disinstallato SolutionB. L'organizzazione ora contiene un'entità Account con un campo di numero account di 35 caratteri, come applicato dalla patch SolutionA 1.0.1.0.

Eliminare una patch

Puoi eliminare una patch o una soluzione (padre) di base tramite DeleteRequest o, per l'API Web, puoi utilizzare il metodo HTTP DELETE. Il processo di eliminazione è diverso per una soluzione gestita o non gestita che ha una o più patch presenti nell'organizzazione.

Per una soluzione non gestita, è necessario disinstallare prima tutte le patch della soluzione di base, nell'ordine di versione inverso rispetto a quello in cui sono state create, prima di disinstallare la soluzione di base.

Per una soluzione gestita, disinstalli semplicemente la soluzione di base. Il sistema Dynamics 365 automaticamente disinstalla le patch nell'ordine di versione inverso prima di disinstallare la soluzione di base. Puoi anche disinstallare una sola patch.

Aggiornare una soluzione

L'aggiornamento di una soluzione include il rollup (merge) di tutte le patch della soluzione in una nuova versione della soluzione. Successivamente, la soluzione viene sbloccata e può nuovamente essere modificata (solo soluzione non gestita) o esportata. Per una soluzione gestita, non sono consentite altre modifiche della soluzione ad eccezione della creazione di patch dalla soluzione appena aggiornata. Per eseguire il rollup delle patch in una soluzione non gestita, usa CloneAsSolutionRequest o CloneAsSolution Action. La clonazione di una soluzione crea una nuova versione della soluzione non gestita, integrando tutte le relative patch, con un numero di versione principale.secondaria più elevato, lo stesso nome univoco e un nome visualizzato.

Per una soluzione gestita le cose vengono gestite in modo leggermente diverso. Innanzitutto esegui la clonazione della soluzione non gestita (A), integrando tutte le relative patch e quindi esportandola come soluzione gestita (B). Nell'organizzazione di destinazione che contiene la versione gestita della soluzione (A) e relative patch, importi la soluzione gestita (B) e quindi esegui DeleteAndPromoteRequest o DeleteAndPromote Action per sostituire la soluzione gestita (A) e le relative patch con la soluzione gestita aggiornata (B) che ha il numero di versione più alto.

Vedere anche

TechNet: Utilizzare soluzioni segmentate e patch per semplificare gli aggiornamenti della soluzione
Pianificare per lo sviluppo di soluzioni
Comprimere e distribuire estensioni con soluzioni
Metodi e messaggi dell'entità Soluzione
Gestire soluzioni gestite
Registrare l'app con AppSource

Microsoft Dynamics 365

Condividi tramite