Determinar quando configurar ou quando codificar
Como desenvolvedor, você deve abordar os aplicativos no Microsoft Power Platform tendo em mente que escrever código para obter a funcionalidade desejada do aplicativo de negócios deve ser considerado uma exceção às abordagens sem código e com pouco código. No entanto, áreas de qualidade como capacidade de manutenção, capacidade de atualização, estabilidade e desempenho também devem ser consideradas ao determinar qual é a melhor abordagem para um cenário específico.
É importante aprender o que o Microsoft Power Platform pronto para uso pode fazer, pois você não quer criar algo que ele já faz e só precisa ser configurado. Isso também se aplica à funcionalidade implementada nos aplicativos do Dynamics 365 disponíveis. Por exemplo, os cálculos de faturas usando listas de preços variáveis com várias moedas são complexos, mas são bem implementados e já consagrados no Dynamics 365 Sales. Se essa funcionalidade for necessária, você deverá considerar o uso de funcionalidades internas do Dynamics 365 Sales em vez de implementar seu próprio mecanismo de cálculo.
Você também deve reconhecer que o Microsoft Power Platform geralmente implementa algo de uma maneira particular que beneficia a plataforma. Isso poderá ser diferente se você estiver acostumado a fazê-lo no código de aplicativo personalizado. Não é incomum que desenvolvedores iniciantes na criação de soluções Microsoft Power Platform tentem personalizar a plataforma da maneira que costumavam criar aplicativos personalizados anteriormente. Isso deve ser evitado sempre que possível, e você deve tentar tirar proveito do que a plataforma faz bem, em vez de tentar alterá-la para o que você está acostumado a fazer. Por exemplo, no passado, você pode ter implementado a segurança em nível de coluna usando código personalizado. No entanto, isso não é necessário no Dataverse, em que a segurança em nível de coluna é um recurso pronto para uso e simplesmente precisa ser configurado.
Regras de negócios versus script de cliente
A vantagem das regras de negócios é que elas são fáceis de entender e implementar para alguém que não é desenvolvedor e podem ser incluídas como parte de uma solução Dataverse para implantação na produção. Nas organizações em que habilidades de desenvolvedor não estão facilmente disponíveis e o gerenciamento do ciclo de vida do aplicativo não é implementado, as regras de negócios seriam uma maneira preferencial de implementar a lógica, mesmo se algumas soluções alternativas fossem necessárias; por exemplo, campos calculados intermediários contendo os valores a serem verificados em uma regra.
No entanto, em algum ponto, as regras de negócios não podem implementar os requisitos de negócios ou, talvez, a complexidade das regras faça com que os desenvolvedores prefiram escrever a lógica no script do cliente. Um cenário pode ser se há lógica aninhada complexa "if/then/else" que seria obtida de maneira melhor em uma instrução switch ou uma sequência simples de blocos if. Outro exemplo é quando você lida com valores dinâmicos que não são facilmente acessíveis por uma regra de negócios. Por exemplo, notificações de formulário e filtragem de valores de escolha não estão disponíveis por meio de regras de negócios.
Fluxos de trabalho/fluxos do Power Automate versus plug-ins
O Dataverse oferece vários métodos para implementar a lógica a fim de responder a eventos no sistema, em particular às alterações de dados, como criar, atualizar e excluir nas linhas de dados. Os requisitos de negócios podem ser satisfeitos por soluções sem código usando fluxos de trabalho e o Power Automate e estendendo o Dataverse usando código do lado do servidor (plug-ins) ou do lado do cliente (script).
Você pode avaliar as opções usando uma abordagem semelhante à usada na discussão sobre regras de negócios versus script do cliente: avalie os requisitos de negócios e os recursos da organização para implementá-los. Também existem algumas diferenças fundamentais nas funcionalidades. A tabela a seguir pode ajudá-lo a determinar quando pode ser melhor usar cada uma das abordagens.
| Capacidade | Fluxo do Power Automate | Fluxo de trabalho | Plug-in |
|---|---|---|---|
| Síncrono ou Assíncrono | Assíncrono | Ambos (os fluxos do Power Automate são recomendados em vez dos fluxos de trabalho assíncronos) | Qualquer um |
| Acessar Dados Externos | Sim, usando conectores | Não | Sim, usando APIs; algumas restrições de segurança |
| Manutenção | Criadores | Usuários de Negócios | Desenvolvedores |
| Pode Ser Executado Como | Usuário atual ou proprietário do fluxo | Usuário atual ou proprietário do fluxo de trabalho | Qualquer usuário licenciado, sistema ou usuário atual |
| Pode Ser Executado sob Demanda | Sim | Sim | Não |
| Pode Aninhar Processos Filho | Sim | Sim | Sim |
| Estágio de Execução | Depois | Antes/Depois | Antes/Depois |
| Gatilhos | Criar, Alterar Coluna, Excluir, Sob Demanda, Agendado | Criar, Alterar Coluna, Excluir, Sob Demanda | Criar, Alterar Coluna, Excluir outras mensagens, inclusive mensagens personalizadas |
O Microsoft Power Platform evolui continuamente e, como desenvolvedor, você deve estar ciente dos recursos novos e futuros. Por exemplo, se sua solução exigisse configurações ou valores de configuração personalizados, anteriormente você teria que usar tabelas personalizadas para armazenar esses valores e usar código personalizado ou ferramentas da plataforma para implantar os dados. A nova adição de variáveis de ambiente simplificou essa tarefa e a reduziu a declarar as variáveis, incluí-las como parte das soluções e definir os valores, tudo sem código.
Power Apps Component Framework (PCF)
Por muitos anos, os recursos da Web em HTML costumavam ser um mecanismo de extensibilidade confiável para o lado do cliente em aplicativos baseados em modelos. Um dos pontos fracos dessa abordagem era a pouca reutilização desses elementos monolíticos e não extensíveis. Agora, os recursos da Web em HTML foram substituídos por controles do PCF.
O PCF permite que os desenvolvedores criem componentes reutilizáveis que podem ser usados pelos criadores em vez dos controles padrão. Esse é um bom exemplo de quando os avanços nos recursos da plataforma permitem que as empresas concentrem seus esforços de desenvolvimento na criação de uma infraestrutura sólida e na capacitação de criadores de aplicativos.
Sistemas externos
A comunicação com sistemas externos é um recurso comum das implementações de solução. Desde tarefas simples, como enviar uma mensagem SMS ou atualizar taxas de câmbio, até cenários complexos de sincronização de dados, esse costumava ser um domínio exclusivo dos desenvolvedores. As implementações usavam plug-ins, publicação de eventos por meio de pontos de extremidade de serviço e webhooks.
No entanto, com a adoção do Power Automate com suas centenas de conectores, agora as interações com sistemas externos podem ser implementadas por criadores de aplicativos sem o uso de código.
No entanto, isso não significa que a função do desenvolvedor seja redundante. Existem muitos cenários complexos ou de alto desempenho em que o código é necessário. Além disso, agora os desenvolvedores podem concentrar seus esforços na criação de serviços e conectores personalizados enquanto delegam os blocos de construção aos criadores.
Portais versus sites personalizados
O Power Pages fornece inúmeras funcionalidades prontas para uso e permitem que os criadores criem sites robustos e os estendam conforme necessário. Os desenvolvedores geralmente auxiliam em tarefas de portal mais complexas, como layouts de página sofisticados (usando a linguagem de modelagem liquid) ou estendendo a funcionalidade do site de front-end usando JavaScript.
Para cenários altamente especializados, você pode decidir criar um portal personalizado completo usando o ASP.NET ou tecnologias semelhantes. Essa abordagem não é incomum, mas requer desenvolvedores altamente qualificados para implementá-la. Novamente, a decisão costuma ser um meio-termo entre uma implementação padrão sem código, mas funcionalidade generalizada e uso controlado de recursos do desenvolvedor para fornecer recursos especializados.
A decisão sobre quando usar código não é simples. Você precisa levar muitos fatores em consideração: de quais habilidades e recursos dispõe, o grau de amadurecimento de sua organização quanto ao gerenciamento do ciclo de vida de aplicativos, a complexidade dos requisitos etc. Frequentemente, os requisitos precisam ser avaliados caso a caso, pois uma pequena alteração nas restrições de negócios pode simplificar a solução e reduzi-la de um projeto de desenvolvimento complexo a um exercício de configuração simples.
O conhecimento sólido e atualizado e a compreensão dos recursos da plataforma são essenciais para que cada desenvolvedor possa tomar decisões racionais e de bom senso sobre quando usar código e quando adaptar o sistema para que ele possa ser personalizado e configurado pelos criadores e usuários de negócios.