Conceptes de solucions

Les solucions són el mecanisme per implementar l'ALM al Power Apps i el Power Automate. En aquest article es descriuen els següents conceptes de la solució clau:

• Dos tipus de solucions
• Components de la solució
• Cicle de vida d'una solució
• Editor de solucions
• Dependències de la solució i dels components d'una solució

Solucions administrades i no administrades

Una solució pot ser administrada o no administrada.

• Es desenvolupen solucions no administrades. Les solucions no administrades s'utilitzen en entorns de desenvolupament mentre feu canvis a l'aplicació. Les solucions no administrades es poden exportar com a no administrades o administrades. S'han de comprovar les versions no administrades exportades de les solucions al sistema del control d'origen. Les solucions no administrades s'han de considerar l'origen d'actius del Microsoft Power Platform. Quan se suprimeix una solució no administrada, només se suprimeix el contenidor de la solució de qualsevol personalització que s'hi inclogui. Totes les personalitzacions no administrades romanen en vigor i pertanyen a la solució per defecte.

• Es despleguen solucions administrades. Les solucions administrades s'implementen en qualsevol entorn que no sigui un entorn de desenvolupament per a aquesta solució. Això inclou els entorns de prova, UAT, SIT i producció. Es pot proporcionar un servei a les solucions administrades independentment de la resta de solucions administrades d'un entorn. En el cas de les pràctiques recomanades de l'ALM, les solucions administrades s'han de generar mitjançant l'exportació d'una solució no administrada com a administrada i s'han de considerar com a artefacte de compilació. De manera addicional:

  • No podeu editar els components directament dins d'una solució administrada. Per editar els components administrats, primer heu d'afegir-los a una solució no administrada.
    • En fer-ho, es crea una dependència entre les personalitzacions no administrades i la solució administrada. Quan hi ha una dependència, la solució administrada no es pot desinstal·lar fins que no suprimiu la dependència.
  • Alguns components administrats no es poden editar. Per comprovar si un component es pot editar, visualitzeu les Propietats administrades.
  • No podeu exportar solucions administrades.
  • Quan se suprimeix (desinstal·la) una solució administrada, totes les personalitzacions i extensions que s'inclouen se suprimeixen.

  Important

  • No podeu importar una solució administrada al mateix entorn que conté la solució no administrada original. Per provar un solució administrada, heu de tenir un entorn separat per importar-la.
  • Quan suprimiu una solució administrada, es perden les dades següents: dades emmagatzemades a les entitats personalitzades que formen part de la solució administrada i dades emmagatzemades en atributs personalitzats que formen part de la solució administrada d'altres entitats que no formen part de la solució administrada.

Els creadors i desenvolupadors treballen en entorns de desenvolupament amb solucions no administrades i, a continuació, les importen a altres entorns descendents, com ara entorns de prova, com a solucions administrades.

Nota

Quan personalitzeu l'entorn de desenvolupament, esteu treballant a la capa no administrada. A continuació, quan exporteu la solució no administrada com a solució administrada per distribuir-la a un altre entorn, la solució administrada s'importa a l'entorn de la capa administrada. Més informació: Capes de solucions

Components de la solució

Un component representa quelcom que podeu personalitzar. Tot el que es pot incloure en una solució és un component. Per visualitzar els components inclosos en una solució, obriu la solució que voleu. Els components s'enumeren a la llista Components.

Nota

• Una solució pot tenir una mida de fins a 95 MB.
• No podeu editar els components directament dins d'una solució administrada.

Per visualitzar una llista de tipus de components que es poden afegir a qualsevol solució, vegeu Opcions de ComponentType.

Alguns components estan incrustats en altres components. Per exemple, una entitat conté formularis, visualitzacions, gràfics, camps, relacions d'entitat, missatges i regles de negocis. Cada un dels components requereix que hi hagi una entitat. Un camp no pot existir fora d'una entitat. Diem que el camp és dependent de l'entitat. En realitat hi ha el doble de tipus de components tal com es mostra a la llista anterior però la majoria estan incrustats en altres components ni estan visibles a l'aplicació.

El propòsit de tenir components és fer un seguiment de les limitacions sobre el que es pot personalitzar amb les propietats administrades i totes les dependències de manera que es pugui exportar, importar i (en solucions administrades) suprimir sense deixar res.

Cicle de vida de la solució

Les solucions admeten les accions següents que ajuden a donar suport als processos de cicle de vida de l'aplicació:

• Creació Creeu i exporteu solucions no administrades.

• Actualització Creeu actualitzacions d'una solució administrada que s'implementen a la solució administrada principal. No podeu suprimir els components amb una actualització.

• Actualització Importeu la solució com a actualització d'una solució administrada existent, que suprimeix els components sense utilitzar i implementa la lògica d'actualització. Les actualitzacions impliquen consolidació (combinació) de tots els pedaços a la solució en una nova versió de la solució. Les actualitzacions de la solució suprimiran els components que existien però ja no s'inclouen a la versió actualitzada. Podeu actualitzar immediatament o implementar l'actualització per fases de manera que pugueu fer algunes accions addicionals abans de completar l'actualització.

• Pedaç Cada pedaç només conté els canvis de la solució administrada principal, com ara l'addició o l'edició de components i actius. Utilitzeu els pedaços en fer petites actualitzacions (com amb una revisió). Quan s'importen els pedaços, s'afegeixen per capes sobre la solució principal. No podeu suprimir els components amb un pedaç.

Editor de solucions

Cada aplicació i altres components de la solució, com ara les entitats que creeu o qualsevol personalització, formen part d'una solució. Com que cada solució té un editor, heu de crear-ne un de propi en comptes d'utilitzar l'editor per defecte. Heu d'especificar l'editor quan creeu una solució.

Nota

Encara que no utilitzeu una solució personalitzada, treballareu en solucions que es coneixen com a Solució per defecte del Common Data Service i Per defecte. Més informació: Solució per defecte i Solució per defecte del Common Data Service

L'editor d'una solució en la qual es crea un component és considerat el propietari d'aquest component. El propietari d'un component controla els canvis que altres editors de solucions, incloent-hi el component, poden fer o no. És possible transferir la propietat d'un component d'una solució a una altra del mateix editor, però no entre editors. Un cop hàgiu introduït un editor per a un component en una solució administrada, no podeu canviar l'editor per al component. Per aquesta raó, és millor definir un sol editor per tal de canviar el model de capes en totes les solucions més endavant.

L'editor de solucions especifica qui ha desenvolupat l'aplicació. Per aquesta raó, heu de crear un nom d'editor de solucions que tingui sentit.

Prefix de l'editor de solucions

Un editor de solucions inclou un prefix. El prefix de l'editor és un mecanisme que us ajudarà a evitar conflictes de noms. Això permet que es puguin instal·lar solucions de diferents editors en un entorn amb pocs conflictes. Per exemple, la solució Contoso que es mostra aquí inclou el prefix de l'editor de solucions contoso.

Nota

Quan canvieu un prefix de l'editor de solucions, ho heu de fer abans de crear les aplicacions o els elements de metadades nous perquè no podeu canviar els noms dels elements de metadades després de crear-los.

Més informació:

• Crear un prefix d'editor de solucions
• Canviar el prefix de l'editor de solucions

Dependències de la solució

A causa de la manera en què les solucions administrades estan layered, algunes solucions administrades poden dependre de components de la solució en altres solucions administrades. Alguns editors de solucions aprofitaran això per crear solucions modulars. Potser haureu d'instal·lar abans una solució administrada "base" i instal·lat després una segona solució administrada que personalitzi més els components a la solució administrada base. La segona solució administrada depèn dels components de la solució que formen part de la primera solució.

El sistema fa un seguiment d'aquestes dependències entre solucions. Si proveu d'instal·lar una solució que requereixi una solució base que no està instal·lada, no podreu instal·lar la solució. Obtindreu un missatge que indica que la solució requereix instal·lar abans una altra solució. De la mateixa manera, a causa de les dependències, no podeu desinstal·lar la solució base mentre hi hagi instal·lada una solució que en depèn. Heu de desinstal·lar la solució dependent abans de desinstal·lar la solució base. Més informació: Suprimir dependències

Dependències dels components d'una solució

Un component de la solució representa quelcom que podeu personalitzar. Tot el que es pot incloure en una solució és un component de la solució i alguns components depenen d'altres components. Per exemple, el camp lloc web i l'informe resum del compte depenen de l'entitat compte. Més informació: Seguiment de dependències dels components de la solució

Consulteu també

Capes de solucions
Crear i administrar entorns al Centre d'administració del Power Platform