Conceptos de soluciones

Las soluciones son el mecanismo para implementar ALM en Power Apps y Power Automate. Este artículo describe los siguientes conceptos clave de solución:

• Dos tipos de soluciones
• Componentes de la solución
• El ciclo de vida de una solución
• Editor de soluciones
• Solución y dependencias de los componentes de la solución

Soluciones administradas y no administradas

Una solución es administrada o no administrada.

• Se desarrollan soluciones administradas. Las soluciones no administradas se utilizan en entornos de desarrollo mientras se realizan cambios en la aplicación. Las soluciones no administradas se pueden exportar como no administradas o administradas. Las versiones no administradas exportadas de sus soluciones deben registrarse en su sistema de control de código fuente. Las soluciones no administradas deben considerarse su fuente de activos de Microsoft Power Platform. Cuando se elimina una solución no administrada, solo se elimina el contenedor de la solución de cualquier personalización incluida en ella. Todas las personalizaciones no administradas permanecen vigentes y pertenecen a la solución predeterminada.

• Las soluciones administradas se implementan. Las soluciones administradas se implementan en cualquier entorno que no sea un entorno de desarrollo para esa solución. Esto incluye los entornos de pruebas, de pruebas de aceptación de usuario (UAT), SIT y de producción. Las soluciones administradas se pueden reparar independientemente de otras soluciones administradas en un entorno. Como práctica recomendada de ALM, las soluciones administradas deben generarse exportando una solución no administrada como administrada y considerada un artefacto de compilación. Además:

  • No puede editar directamente componentes en una solución administrada. Para editar componentes administrados, primero agréguelos a una solución no administrada.
    • Al hacerlo, se crea una dependencia entre las personalizaciones no administradas y la solución administrada. Cuando exista una dependencia, la solución administrada no se puede desinstalar hasta que quite la dependencia.
  • Algunos componentes administrados no se pueden editar. Para verificar si un componente se puede editar, vea la Propiedades gestionadas.
  • No puede exportar una solución administrada.
  • Cuando se elimina una solución administrada (desinstalada), todas las personalizaciones y extensiones incluidas con ella se quitan.

  Importante

  • No puede importar una solución administrada en el mismo entorno que contiene la solución no administrada original. Para probar una solución administrada, es necesario un entorno independiente para importarla.
  • Cuando elimina una solución administrada, se pierden los siguientes datos: datos almacenados en las entidades personalizadas que forman parte de la solución administrada y datos almacenados en atributos personalizados que forman parte de la solución administrada en otras entidades que no forman parte de la solución administrada.

Los fabricantes y desarrolladores trabajan en entornos de desarrollo utilizando soluciones no administradas, luego las importan a otros entornos posteriores (por ejemplo, el de pruebas) como soluciones administradas.

Nota

Cuando se personaliza en el entorno de desarrollo, se está trabajando en la capa no administrada. Luego, cuando exporta la solución no administrada como solución administrada para distribuirla a otro entorno, el solución administrada se importa al entorno en la capa administrada. Más información: Capas de solución

Componentes de la solución

Un componente representa algo que puede personalizar. Todo lo que se puede incluir en una solución es un componente. Para ver los componentes incluidos en una solución, abra la solución que desee. Los componentes se enumeran en la lista Componentes.

Nota

• Una solución puede tener hasta 32 MB de tamaño.
• No puede editar directamente componentes en una solución administrada.

Para ver una lista de los tipos de componentes que se pueden agregar a cualquier solución, vea Opciones de tipo de componente .

Algunos componentes se anidan en otros componentes. Por ejemplo, una entidad contiene formularios, vistas, gráficos, campos, relaciones de entidad, mensajes y reglas de negocio. Cada uno de los componentes necesita que exista una entidad. Un campo no puede existir fuera de una entidad. Decimos que el campo depende de la entidad. Existe el doble de tipos de componentes que se muestra en la lista anterior, pero la mayoría de ellos no se anidan en otros componentes y no son visibles en la aplicación.

El objetivo de tener componentes es mantener un seguimiento de las limitaciones sobre lo que se puede personalizar mediante propiedades administradas y todas las dependencias para que se pueda exportar, importar y (en las soluciones administradas) eliminar sin dejar nada atrás.

Ciclo de vida de una solución

Las soluciones admiten las siguientes acciones que ayudan a respaldar los procesos del ciclo de vida de las aplicaciones:

• Crear: crear y exportar soluciones no administradas

• Actualizar: crear actualizaciones para una solución administrada que se implementan en la solución administrada principal. No puede eliminar componentes con una actualización.

• Mejorar: importar la solución como una actualización a una solución administrada existente, que elimina los componentes no utilizados e implementa la lógica de actualización. Las mejoras implican consolidar (combinar) todas las revisiones para la solución en una nueva versión de la solución. Las actualizaciones de la solución eliminarán los componentes que existían pero que ya no se incluyen en la versión actualizada. Puede optar por actualizar de inmediato o por etapas para poder realizar algunas acciones adicionales antes de completar la actualización.

• Aplicar parches: un parche solo contiene los cambios en la solución administrada primaria, como agregar o editar componentes y activos. Use parches cuando realice pequeñas actualizaciones (similar a una revisión). Cuando se importan revisiones, se colocan en capas sobre la solución principal. No puede eliminar componentes con un parche.

Editor de soluciones

Cada aplicación y otros componentes de la solución, como las entidades que crea o cualquier personalización que realice, forman parte de una solución. Debido a que cada solución tiene un editor, debe crear su propio editor en lugar de usar el predeterminado. Usted especifica el editor al crear una solución.

Nota

Incluso si no utiliza una solución personalizada, trabajará en soluciones conocidas, como la Solución predeterminada de Common Data Service y las soluciones Predeterminadas. Más información: Solución predeterminada y solución predeterminada de Common Data Service

El editor de una solución en la que se crea un componente se considera el propietario de ese componente. El propietario de un componente controla los cambios que otros editores de soluciones, incluido ese componente, pueden hacer o restringir. Es posible mover la propiedad de un componente de una solución a otra dentro del mismo editor, pero no entre editores. Una vez que introduzca un editor para un componente en una solución administrada, no podrá cambiar el editor para el componente. Debido a esto, es mejor definir un editor único para poder cambiar el modelo de capas en las soluciones más adelante.

El editor de soluciones especifica quién desarrolló la aplicación. Por esta razón, debe crear un nombre editor de soluciones que sea significativo.

Prefijo del editor de soluciones

Un editor de soluciones incluye un prefijo. El prefijo del editor es un mecanismo para ayudar a evitar colisiones de nombres. Esto permite instalar soluciones de diferentes editores en un entorno con pocos conflictos. Por ejemplo, la solución de Contoso que se muestra aquí incluye un prefijo editor de soluciones de contoso.

Nota

Cuando cambie un prefijo editor de soluciones, debe hacerlo antes de crear nuevas aplicaciones o elementos de metadatos porque no puede cambiar los nombres de los elementos de metadatos después de que se hayan creado.

Más información:

• Crear un prefijo del editor de soluciones
• Cambiar un prefijo del editor de soluciones

Dependencias de soluciones

Debido al modo en que las soluciones administradas se estructuran, algunas soluciones administradas pueden ser dependientes de los componentes de la solución en otras soluciones administradas. Algunos editores de soluciones aprovecharán esta característica para crear soluciones modulares. Es posible que tenga que instalar una solución administrada "base" primero y luego puede instalar una segunda solución administrada que personalice aún más los componentes de la solución administrada base. La segunda solución administrada depende de los componentes de la solución que forman parte de la primera solución.

El sistema sigue estas dependencias entre las soluciones. Si intenta instalar una solución que requiere una solución base que no está instalada, no podrá instalar la solución. Recibirá un mensaje que indica que la solución requiere que se instale otra solución primero. De forma similar, debido a las dependencias, no puede desinstalar la solución base mientras una solución que depende de esta aún está instalada. Es necesario desinstalar la solución dependiente antes de desinstalar la solución base. Más información Quitar dependencias

Dependencias de los componentes de solución

Un componente de la solución representa algo que puede personalizar. Todo lo que se puede incluir en una solución es un componente de la solución y algunos componentes dependen de otros componentes. Por ejemplo, el campo del sitio web y el informe resumido de la cuenta dependen de la entidad de la cuenta. Más información: Seguimiento de las dependencias de los componentes de la solución

Vea también

Capas de soluciones
Crear y administrar entornos en el centro de administración de Power Platform