Compartilhar via


Conceitos de solução

As soluções são o mecanismo para implementar o geranciamento do ciclo de vida do aplicativo (ALM) em Power Apps e Power Automate. Este artigo descreve os seguintes conceitos principais de solução:

  • Dois tipos de soluções
  • Componentes da solução
  • Ciclo de vida de uma solução
  • Fornecedor de soluções
  • Dependências de solução e componente de solução

Soluções gerenciadas e não gerenciadas

Uma solução é gerenciada ou não gerenciada.

  • Soluções não gerenciadas são desenvolvidas. As soluções não gerenciadas são usadas em ambientes de desenvolvimento enquanto você faz alterações em seu aplicativo. As soluções não gerenciadas podem ser exportadas como não gerenciadas ou gerenciadas. Versões não gerenciadas exportadas de suas soluções devem ser verificadas em seu sistema de controle de origem. Soluções não gerenciadas devem ser consideradas sua fonte de ativos do Microsoft Power Platform. Quando uma solução não gerenciada é excluída, apenas o contêiner da solução com todas as personalizações incluídas nela é excluído. Todas as personalizações não gerenciadas permanecem em vigor e pertencem à solução padrão.

  • Soluções gerenciadas são implantadas. As soluções gerenciadas são implantadas para qualquer ambiente que não seja um ambiente de desenvolvimento para essa solução. Isso inclui ambientes de teste, UAT, SIT e produção. As soluções gerenciadas podem ser atendidas independentemente de outras soluções gerenciadas em um ambiente. Como prática recomendada do ALM, as soluções gerenciadas devem ser geradas exportando uma solução não gerenciada como gerenciada e consideradas um artefato de compilação. Além disso:

    • Não é possível editar componentes diretamente em uma solução gerenciada. Para editar componentes gerenciados, primeiro adicione-os a uma solução não gerenciada.
      • Quando você faz isso, você cria uma dependência entre as personalizações não gerenciadas e a solução gerenciada. Quando há uma dependência, a solução gerenciada não pode ser desinstalada até que você remova a dependência.
    • Alguns componentes gerenciados não podem ser editados. Para verificar se um componente pode ser editado, consulte as Propriedades gerenciadas.
    • Você não pode exportar uma solução gerenciada.
    • Quando uma solução gerenciada é excluída (desinstalada), todas as personalizações e extensões incluídas nela são removidas.

    Importante

    • Não é possível importar uma solução gerenciada para o mesmo ambiente que contém a solução não gerenciada de origem. Para testar uma solução gerenciada, é necessário ter um ambiente separado no qual importá-la.
    • Quando você exclui uma solução gerenciada, os seguintes dados são perdidos: dados armazenados em entidades personalizadas que fazem parte da solução gerenciada e os dados armazenados em atributos personalizados que fazem parte da solução gerenciada em outras entidades que não fazem parte da solução gerenciada.

Criadores e desenvolvedores trabalham em ambientes de desenvolvimento usando soluções não gerenciadas e depois importam para outros ambientes downstream, como teste, como soluções gerenciadas.

Distribuir uma solução em ambientes de desenvolvimento para teste.

Observação

Quando você personaliza no ambiente de desenvolvimento, está trabalhando na camada não gerenciada. Em seguida, quando você exporta a solução não gerenciada como uma solução gerenciada para distribuir para outro ambiente, a solução gerenciada é importada para o ambiente na camada gerenciada. Mais informações: Camadas da solução

Componentes da solução

Um componente representa algo que você pode personalizar. Qualquer item que possa ser incluído em uma solução é um componente. Para exibir os componentes incluídos em uma solução, abra a solução desejada. Os componentes estão listados na lista Componentes.

Componentes na solução.

Observação

  • A solução pode ser de até 95 MB.
  • Não é possível editar componentes diretamente em uma solução gerenciada.

Para exigir uma lista de tipos de componentes que podem ser adicionados a qualquer solução, consulte Opções ComponentType.

Alguns componentes são aninhados em outros componentes. Por exemplo, uma entidade contém formulários, exibições, gráficos, campos, relacionamentos de entidades, mensagens e regras de negócios. Para existir, cada um desses componentes exige uma entidade. Um campo não pode existir fora de uma entidade. Dizemos que o campo depende da entidade. There são o dobro de tipos de componentes mostrados na lista anterior, mas a maioria deles está aninhada dentro de outros componentes e não é visível no aplicativo.

A finalidade de ter componentes é controlar as limitações do que pode ser personalizado usando as propriedades gerenciadas e todas as dependências para que ele possa ser exportado, importado e (em soluções gerenciadas) excluído sem deixar nada para atrás.

Ciclo de vida da solução

As soluções permitem as ações a seguir que ajudam a oferecer suporte aos processos do ciclo de vida do aplicativo:

  • Crie autor e exporte soluções não gerenciadas.

  • Atualizar Criar atualizações para um solução gerenciada que são implantadas no pai solução gerenciada. Não é possível excluir componentes com uma atualização.

  • Atualização Importe a solução como uma atualização para um solução gerenciada existente, que remove componentes não utilizados e implementa a lógica de atualização. Os upgrades envolvem o acúmulo (mesclagem) de todos os patches dessa solução em uma nova versão da solução. As atualizações da solução excluem componentes que existiam, mas não estão mais incluídos na versão atualizada. Você pode optar por fazer upgrade imediatamente ou preparar o upgrade para poder executar algumas ações adicionais antes de concluir o upgrade.

  • Patch Um patch contém apenas as alterações para um pai solução gerenciada,, como adicionar ou editar componentes e ativos. Use patches ao fazer pequenas atualizações (semelhante a um hotfix). Quando os patches são importados, eles são sobrepostos no topo da solução primária. Não é possível excluir componentes com um patch.

Fornecedor de soluções

Todo aplicativo e outros componentes da solução, como entidades que você cria ou qualquer personalização que você faz, fazem parte de uma solução. Como toda solução tem um fornecedor, você deve criar seu próprio fornecedor, em vez de usar o padrão. Você especifica o fornecedor quando cria uma solução.

Nota

Mesmo se você não usar uma solução personalizada, estará trabalhando em soluções que são conhecidas como a Solução Padrão do Common Data Service e as soluções Padrão. Mais Informações: Solução Padrão e Solução Padrão do Common Data Service

O editor de uma solução em que um componente é criado é considerado o proprietário desse componente. O proprietário de um componente controla quais alterações outros editores de soluções que incluem esse componente podem fazer ou estão impedidos de fazer. É possível mover a propriedade de um componente de uma solução para outra no mesmo fornecedor, mas não entre os fornecedores. Depois de introduzir um editor para um componente em uma solução gerenciada, não é possível alterar o editor do componente. Devido a essa restrição, é melhor definir um único editor para que você possa alterar o modelo de camadas entre as soluções posteriormente.

O fornecedor de soluções especifica quem desenvolveu o aplicativo. Por isso, você deve criar um nome de fornecedor de soluções que seja significativo.

Prefixo de fornecedor de soluções

Um fornecedor de soluções tem um prefixo. O prefixo do fornecedor é um mecanismo para ajudar a evitar colisões de nomenclatura. Isso permite que soluções de diferentes fornecedores sejam instaladas em um ambiente com poucos conflitos. Por exemplo, a solução Contoso exibida aqui inclui um prefixo de fornecedor de soluções de contoso.

Exemplo de prefixo do fornecedor de soluções.

Observação

Quando você altera um prefixo do fornecedor de soluções, deve fazê-lo antes de criar aplicativos ou itens de metadados, porque não é possível alterar os nomes dos itens de metadados após a criação.

Para obter mais informações:

Dependências de solução

Por causa do modo como as soluções gerenciadas são sobrepostas, algumas soluções gerenciadas podem depender de componentes da solução em outras soluções gerenciadas. Alguns editores de soluções aproveitam isso para criar soluções modulares. Talvez seja necessário instalar um solução gerenciada "base" primeiro e depois instalar um segundo solução gerenciada que personalizará ainda mais os componentes no solução gerenciada base. A segunda solução gerenciada depende dos componentes de solução que fazem parte da primeira solução.

O sistema controla essas dependências entre soluções. Se você tentar instalar uma solução que exige uma solução base que não esteja instalada, não poderá instalar a solução. Você receberá uma mensagem informando que a solução requer que outra solução seja instalada primeiro. Da mesma forma, devido às dependências, você não pode desinstalar a solução base enquanto uma solução que depende dela ainda estiver instalada. É necessário desinstalar a solução dependente antes de desinstalar a solução base. Mais informações: Removendo dependências

Dependências de componentes de solução

Um componente da solução representa algo que você pode personalizar. Em uma solução, só é possível incluir um componente da solução, e alguns componentes dependem de outros componentes. Por exemplo, o campo do site e o relatório de resumo da conta dependem da entidade da conta. Mais informações: Rastreamento de dependências para componentes de solução

Consulte também

Camadas de solução
Crie e gerencie ambientes no Power Platform centro de administração