Compartir por


Conceptos das solucións

As solucións son o mecanismo para implementar a xestión do ciclo de vida das aplicacións (ALM) en Power Apps e Power Automate. Este artigo describe os seguintes conceptos clave de solucións:

  • Dous tipos de solucións
  • Compoñentes da solución
  • Ciclo de vida dunha solución
  • Publicador de solucións
  • Solución e dependencias do compoñente da solución

Solucións xestionadas e non xestionadas

Unha solución pode ser xestionada ou non xestionada.

  • Desenvólvense solucións non xestionadas . As solucións non xestionadas utilízanse nos contornos de desenvolvemento mentres realizas cambios na túa aplicación. As solucións non administradas poden exportarse como xestionadas ou non xestionadas. As versións non xestionadas exportadas das súas solucións deben ser revisadas no seu sistema de control de orixe. Debe considerarse ás solucións non xestionadas a súa fonte de activos de Microsoft Power Platform. Cando se elimina unha solución non xestionada, só se elimina o contenedor de solucións das personalizacións incluídas nela. Todas as personalizacións non administradas permanecen en vigor e pertencen á solución predeterminada.

  • Implíganse solucións xestionadas . As solucións xestionadas implícanse en calquera ambiente que non sexa un ambiente de desenvolvemento para esa solución. Isto inclúe ambientes de proba, UAT, SIT e produción. As solucións xestionadas poden ser atendidas de forma independente doutras solucións xestionadas nun ambiente. Como práctica recomendada de ALM, as solucións xestionadas deberían xerarse exportando unha solución non xestionada como xestionada e considerada como artefacto de creación. Ademais:

    • Non pode editar directamente os compoñentes dunha solución xestionada. Para editar compoñentes xestionados, primeiro engádaos a unha solución non xestionada.
      • Cando fai isto, crea unha dependencia entre as súas personalizacións non xestionadas e a solución administrada. Cando existe unha dependencia, o solución administrada non se pode desinstalar ata que se elimine a dependencia.
    • Algúns compoñentes xestionados non se poden editar. Para verificar se un compoñente se pode editar, consulte as Propiedades xestionadas.
    • Non pode exportar unha solución administrada.
    • Cando se elimina (desinstala) unha solución administrada, elimínanse todas as personalizacións e extensións incluídas.

    Importante

    • Non pode importar unha solución administrada no mesmo ambiente que contén a solución non xestionada orixinaria. Para probar unha solución administrada, necesita un ambiente independente á que importala.
    • Cando elimine unha solución administrada, perderanse os seguintes datos: datos almacenados en entidades personalizadas que forman parte da solución administrada e datos almacenados en atributos personalizados que forman parte da solución administrada noutras entidades que non forman parte da solución administrada.

Os creadores e programadores traballan en ambientes de desenvolvemento empregando solucións non xestionadas para logo importalas a outros ambientes descendentes (como os de proba) como solucións administradas.

Distribuír unha solución desde os entornos de desenvolvemento ata os de proba.

Nota

Cando personaliza no ambiente de desenvolvemento, está a traballar na capa non xestionada. A continuación, cando exporta a solución non xestionada como solución administrada para distribuír a outro ambiente, o solución administrada importarase ao ambiente na capa xestionada. Máis información: Capas da solución

Compoñentes da solución

Un compoñente representa algo que potencialmente pode personalizar. Todo aquilo que poden ser incluídos nunha solución é un compoñente. Para ver os compoñentes incluídos nunha solución, abra a solución que desexe. Os compoñentes figuran na lista Compoñentes.

Compoñentes en solución.

Nota

  • Unha solución pode ter un tamaño de ata 95 MB.
  • Non pode editar directamente os compoñentes dunha solución xestionada.

Para ver unha lista de tipos de compoñentes que se poden engadir a calquera solución, consulte Opcións de ComponentType.

Algúns compoñentes están aniñados noutros compoñentes. Por exemplo, unha entidade contén formularios, visualizacións, gráficas, campos, relacións entre entidades, mensaxes e regras de negocio. Todos os compoñentes require que existe unha entidade. Un campo non existe fóra dunha entidade. Nós dicimos que o campo depende da entidade. Hai o dobre de tipos de compoñentes que os mostrados na lista anterior, pero a maioría deles están aniñados noutros compoñentes e non son visibles na aplicación.

A finalidade de ter compoñentes é rastrexar as limitacións do que se pode personalizar utilizando Propiedades xestionadas e todas as dependencias para que se poidan exportar, importar e (en solucións xestionadas) eliminar sen deixar rastro.

Ciclo de vida da solución

As solucións admiten as seguintes accións que axudan a compatibilizar os procesos do ciclo de vida das aplicacións:

  • Crear: Crear e exportar solucións non xestionadas.

  • Actualizar: Crear actualizacións dunha solución administrada que se aplican á solución administrada principal. Non pode eliminar compoñentes cunha actualización.

  • Actualización: Importar a solución como unha actualización a unha solución administrada existente, que elimina compoñentes non empregados e implementa a lóxica de actualización. As melloras implican agrupar (fusionar) todos os parches da solución nunha nova versión da solución. As actualizacións da solución eliminan compoñentes que existían pero que xa non están incluídos na versión actualizada. Pode optar por actualizar inmediatamente ou realizar a actualización por fases para que poida facer algunhas accións adicionais antes de completar a actualización.

  • Parche: Un parche contén só as modificacións da solución administrada primaria, como por exemplo engadir ou editar compoñentes e activos. Use parches ao realizar pequenas actualizacións (semellante a unha corrección rápida). Cando os parches se importan, colócanse enriba da solución primaria. Non pode eliminar compoñentes cun parche.

Publicador de solucións

Todas as aplicacións e outros compoñentes da solución, como as entidades que crea ou calquera personalización que realice, forman parte dunha solución. Dado que cada solución ten un publicador, debería crear o seu propio publicador en lugar de usar o predeterminado. Especifique o publicador cando cree unha solución.

Nota

Mesmo se non usa unha solución personalizada, estará traballando en solucións que se coñecen como Solución predefinida de Common Data Service e solucións Predefinidas. Máis información: Solución predefinida e solución predefinida de Common Data Service

O editor dunha solución onde se crea un compoñente considérase o propietario dese compoñente. O propietario dun compoñente controla que cambios se lle permiten ou impiden facer a outros editores de solucións, incluído ese compoñente. É posible mover a propiedade dun compoñente dunha solución a outra dentro do mesmo publicador, pero non a través de publicador. Unha vez que introduza un editor para un compoñente nun solución administrada, non pode cambiar o editor do compoñente. Debido a esta restrición, é mellor definir un único editor para poder cambiar o modelo de capas entre as solucións máis tarde.

O publicador de solucións especifica quen desenvolveu a aplicación. Por este motivo, debe crear un nome publicador de solucións que teña sentido.

Prefixo do publicador de solucións

Un publicador de solucións inclúe un prefixo. O prefixo do publicador é un mecanismo que axuda a evitar problemas cos nomes. Isto permite que solucións de diferentes publicadores se instalen nun ambiente con poucos conflitos. Por exemplo, a solución Contoso que se mostra aquí inclúe un prefixo de publicador de solucións de contoso.

Exemplo de prefixo publicador de solucións.

Nota

Cando cambie un prefixo do publicador de solucións, debe facelo antes de crear aplicacións ou elementos de metadatos novos porque non pode cambiar os nomes dos elementos de metadatos despois de que se creasen.

Máis información:

Dependencias da solución

Debido a forma en que solucións xestionadas son superpostas, algunhas solucións xestionadas poden ser dependentes dos compoñentes de solución noutras solucións xestionadas. Algúns editores de solucións aproveitan isto para crear solucións modulares. Pode que necesites instalar primeiro un solución administrada "base" e despois podes instalar un segundo solución administrada que personalizará aínda máis os compoñentes na base solución administrada. Da segunda solución xestionada depende dos compoñentes da solución que son parte da solución primeira.

O sistema rastrexa estas dependencias entre solucións. Se tenta instalar unha solución que require unha solución base que non está instalada, non será capaz de instalar a solución. Recibirás unha mensaxe que indica que a solución require que se instale outra solución primeiro. Do mesmo xeito, debido ás dependencias, non pode desinstalar a solución base mentres aínda estea instalada unha solución que depende dela. Debe desinstalar a solución dependente antes de poder desinstalar a solución base. Máis información: Eliminación de dependencias

Dependencias do compoñente da solución

Un compoñente da solución representa algo que potencialmente pode personalizar. Todo o que se pode incluír nunha solución é un compoñente de solución e algúns compoñentes dependen doutros compoñentes. Por exemplo, o campo do sitio web e o informe de resumo da conta dependen da entidade da conta. Máis información: Rastrexamento de dependencias para compoñentes da solución

Consulte tamén

Capas da solución
Crear e xestionar ambientes no centro de administración de Power Platform