Melhores práticas de personalização

Siga estas melhores práticas para evitar problemas de desempenho, usabilidade e capacidade de suporte com o Dynamics 365 Field Service.

Minimizar campos personalizados em formulários

Os personalizadores de sistemas adicionam campos personalizados a formulários de entidades para capturar informações específicas da sua indústria e negócios, para executar processos de negócio e para recolher informações a reportar. No entanto, demasiados campos personalizados num formulário podem causar problemas de desempenho.

Para evitar problemas de desempenho:

• Minimize o número de campos personalizados em todos os formulários. Se a ordem de intervenção for o formulário que mais utiliza na aplicação Field Service, é uma boa ideia começar com esse formulário.
• Minimize o número de campos de tipo de procura e subgrelhas entre campos personalizados.
• Mova os campos personalizados (especialmente pesquisas e subgrelhas) do primeiro separador do formulário para outros separadores do formulário.
• Oculte campos menos utilizados num formulário por predefinição.

Não altere recursos Web, conjuntos de opções, direitos de acesso nem fluxos de trabalho de origem

Não altere ou personalize recursos web, conjuntos de opções ou direitos de acesso ou fluxos de trabalho pronto a utilizar. Caso contrário, pode causar um comportamento não intencional do sistema.

As organizações que personalizam estes componentes poderão não ter de imediato problemas no respetivo ambiente. No entanto, as alterações que a Microsoft disponibiliza para os componentes personalizados fornecidos com o dispositivo não são aplicadas à camada superior desses componentes. Em vez disso, a camada personalizada específica substitui todas as alterações futuras, e essas substituições eventualmente causam erros e comportamentos imprevisíveis.

Não modifique, edite ou elimine campos de data ou estados de sistema

A modificação, edição ou eliminação de campos de datas e estados pode afetar a lógica de negócio e pode causar problemas com as atualizações da solução. Exemplos de campos de data numa ordem de intervenção incluem a Hora de início prometida e a Hora de fim prometida. Exemplos de campos de estado incluem o Estado do sistema da ordem de intervenção e o Estado do sistema do contrato.

Não edite campos de origem nem os remova dos formulários

Os clientes editam campos de origem para acomodar as suas necessidades de negócio. No entanto, a edição de campos de origem pode causar erros, especialmente quando os processos dependem dos valores desses campos.

Para evitar erros:

• Oculte campos não pretendidos num formulário.
• Mova campos não pretendidos para outro separador do formulário.

Por exemplo, os processos do Field Service calculam o valor do campo Hora de Chegada Estimada no registo de Reserva de Recursos Reserváveis para indicar quando é esperado que um trabalhador de primeira linha chegue ao local. Se a sua organização não precisar deste campo, oculte-o no formulário em vez de o remover.

Não edite valores do conjunto de opções (escolha)

A edição de valores de conjuntos de opções de campos de origem pode causar erros, especialmente quando os processos dependem dos valores desses campos ou durante atualizações de versão.

Para evitar erros:

• Edite apenas as etiquetas do conjunto de opções dos campos de origem. Nunca edite os valores do conjunto de opções desses campos.
• Não remova nenhuma escolha do conjunto de opções.
• Não adicione nenhuma escolha ao conjunto de opções.

Por exemplo, a ordem de intervenção do Field Service inclui um campo Estado do Sistema por predefinição. Este campo é um conjunto de opções (do tipo escolha) e tem opções como Não agendado, Agendado, Em curso, Concluído e Cancelado. Cada opção tem uma etiqueta e um valor numérico associado. Os administradores de sistema podem editar as etiquetas de conjuntos de opções (como Não Agendado), mas nunca podem editar o valor numérico que está associado à etiqueta.

Utilizar menos scripts personalizados e seguir as melhores práticas

Os personalizadores de sistemas escrevem scripts, tipicamente, recursos Web JavaScript, para executar lógica de negócio. No entanto, scripts personalizados podem causar problemas de desempenho, erros e complicações durante os upgrades.

Para evitar estes problemas:

• Minimize o número de scripts executados durante o carregamento.
• Não escreva scripts que chamem muitos dados e não escreva vários scripts que chamem os mesmos dados.

As subsecções seguintes descrevem as melhores práticas. Além disso, siga as melhores práticas do script de formulário em Melhores práticas para desenvolver com Dynamics 365 Customer Engagement.

Minimizar o número de pedidos de rede e a quantidade de dados pedidos no evento OnLoad

Quanto maior for o número de pedidos de rede feitos durante um carregamento de formulários, e quanto maior for a quantidade de dados transferidos a partir desses pedidos, mais tempo demorará para um formulário ser carregado. Solicite apenas a quantidade mínima de dados necessários. Além disso, considere colocar em cache os dados quando for possível para evitar pedir dados desnecessariamente durante futuros carregamentos de formulários.

Evite utilizar pedidos de rede síncronos

Os pedidos de rede síncronos podem causar carregamentos de páginas lentos e formulários que não respondem. Opte pela utilização de pedidos assíncronos. As seguintes publicações de blogue fornecem mais exemplos: Carregue rapidamente as suas aplicações condicionadas por modelos, transferindo-se para longe de pedidos síncronos. Além disso, considere utilizar "assíncrono e esperar" em qualquer cenário em que sejam necessárias múltiplas chamadas de rede para a mesma entidade e registo. Mais informações sobre o processamento assíncrono e aguarde.

Evite incluir bibliotecas desnecessárias de recurso Web de Javascript

Quanto mais scripts adicionar a um formulário, mais tempo demora a transferi-los. Normalmente, os scripts são colocados em cache no seu browser depois de serem carregados pela primeira vez. No entanto, o desempenho na primeira vez que um formulário é visualizado geralmente cria uma impressão significativa.

Evite carregar todos os scripts no evento Onload

Se tiver um código que só suporta eventos OnChange para colunas ou só o evento OnSave, certifique-se de que define a biblioteca de scripts com o processador de eventos para os eventos em vez de evento de OnLoad. Desta forma, é possível adiar o carregamento dessas bibliotecas e o desempenho aumenta quando o formulário é carregado.

Utilize separadores fechados para adiar o carregamento de recursos Web

Recursos Web ou componentes de iFrame incluídos nas secções num separador expansível não são carregados se o separador estiver fechado. São carregados apenas quando o separador é expandido. Quando o estado do separador muda, o evento TabStateChange ocorre. Um código que é necessário para suportar recursos Web ou iFrames nos separadores fechados pode utilizar processadores de eventos para eventos do TabStateChange e reduzir o código que poderá de outro modo ocorrer no evento de OnLoad.

Evitar duplicar pedidos de rede no código do lado do cliente

Pedidos de rede múltiplos ou duplicados podem fazer com que o browser Web estagne e afete o tempo de carregamento do formulário. A redução do número de pedidos pode melhorar o desempenho. Uma alternativa é consolidar pedidos de rede e colocar em cache o valor dos pedidos. Além disso, considere pedidos de rede assíncronos, como foi mencionado anteriormente.

Evite utilizar chamadas específicas de funções e de utilizador do sistema se as informações relevantes estiverem disponíveis em APIs XRM

Utilize APIs XRM para evitar pedidos de rede para obter informações sobre o privilégio do utilizador. Saiba mais sobre como fazer a transição de pedidos síncronos. Além disso, evite chamadas de utilizador do sistema se as informações de APIs XRM satisfizerem os seus requisitos.

Definir opções de visibilidade predefinida

No evento de OnLoad, evite utilizar scripts de formulários que ocultam elementos de formulário. Em vez disso, para elementos de formulário que poderão estar ocultos, defina opções de visibilidade predefinida de forma a que os elementos estejam ocultos por predefinição quando o formulário for carregado. Em seguida, utilize scripts no evento OnLoad para mostrar os elementos de formulário que pretende que estejam visíveis.

Saiba mais nos seguintes recursos:

• Estruturar formulários para desempenho em aplicações condicionadas por modelo
• Personalizações não suportadas

Executar o verificador de soluções nos seus scripts

O verificador de soluções do Power Apps é uma ferramenta útil da Microsoft que verifica soluções do Power Apps para problemas e recomenda melhores práticas. Estes problemas incluem problemas com JavaScript, HTML, Plug-ins e atividades de fluxo de trabalho personalizadas.

Saiba mais nos seguintes recursos:

• Melhorar o desempenho, a estabilidade e a fiabilidade dos componentes com o verificador de soluções
• Como executar e usar o verificador de soluções do Power Apps
• Verificador de Soluções do Dataverse

Utilizar fluxos de trabalho assíncronos em vez de síncronos

Os personalizadores de sistema frequentemente escrevem fluxos de trabalho síncronos para executar a lógica de negócio em tempo real que é executada quando os dados são alterados no Field Service. No entanto, executar fluxos de trabalho de forma síncrona diminui o desempenho. Para evitar problemas de desempenho, execute fluxos de trabalho de forma assíncrona.

Ativar processos de origem do Field Service e o Agendamento de Recursos

O Field Service e o Agendamento de Recursos incluem muitos processos que executam a lógica de negócio necessária. Processos desativados podem levar a erros. Para evitar problemas, certifique-se de que todos os processos do Field Service e o Agendamento de Recursos estão em estado ativo. Para identificar se os processos estão em estado desativado, execute o Hub de Estado de Funcionamento da Solução do Field Service regularmente.

Executar o Hub de Estado de Funcionamento da Solução para detetar problemas

O Hub de Estado de Funcionamento da Solução ajuda a obter uma imagem melhor do estado do seu ambiente e detetar problemas com o ambiente do Dynamics 365. A configuração de um ambiente pode mudar ao longo do tempo através de operações do sistema natural. O Hub de Estado de Funcionamento da Solução executa regras dentro de uma instância para validar a configuração do ambiente. Algumas das regras são específicas do Field Service e é possível executá-las a pedido quando encontrar um problema. Algumas regras são acionadas automaticamente quando o Field Service é instalado ou atualizado.

Para monitorizar o estado de funcionamento do seu ambiente execute o conjunto de regras do Hub de Estado de Funcionamento da Solução regularmente.

Considerações sobre o desempenho da aplicação móvel

A personalização da aplicação móvel pode afetar o desempenho. Saiba mais em Considerações sobre o desempenho ao personalizar a aplicação móvel.