Criar formulário e lógica de negócios

  • Versão de lançamento: Washingtondc
  • Atualizado 1 de fev. de 2024
  • 2 min. de leitura
  • A próxima etapa no design de uma aplicação é criar a lógica. A lógica inclui a lógica de formulário (o que as pessoas podem e não podem ver/usar em um formulário) e a lógica de negócios (regras que regem o que acontece com os dados quando eles são inseridos).

    Scripts e modificações

    Antes de escrever qualquer código, esteja ciente do impacto nas atualizações e na adoção de novos recursos da ServiceNow. Deve-se ter cuidado especial ao modificar artefatos e processos de linha de base.

    Considere o seguinte antes de criar scripts:

    • Avalie o requisito. A lógica é crítica para o funcionamento do app?
    • Determine se a ServiceNow pode ser configurada para atender ao requisito sem código.
    • Aproveite opções, como Flow Designer, Virtual Agent e Políticas de IU para aproveitar os recursos da plataforma sem escrever código.
    • Abordagens de lógica com pouco código e sem código são mais fáceis de depurar e atualizar.

    Exemplos de quando o script é apropriado:

    • Como criar ações do Flow Designer
    • Criando uma Scripted REST API
    • Criação de lógica para aplicações com escopo em Inclusões de script
    • Personalizando e criando widgets para o Portal de serviços

    Avalie o requisito de negócios e considere uma rota sem código antes de usar uma solução com script.

    Esteja ciente dos aprimoramentos da ServiceNow. Por exemplo, na versão orlando, as conversas do Virtual Agent têm mais opções sem código do que London. Leia as notas de versão e outras publicações. Obtenha a certificação e mantenha-se atualizado com suas certificações.

    Para entender melhor quando personalizar, revise o Playbook de sucesso do Innovate at Scale na Central de sucesso do cliente.

    Modificando o comportamento padrão

    No passado, uma das estratégias usadas era copiar o artefato para atualizar e desativar o original. A abordagem de copiar/desativar não é mais recomendada devido aos seguintes problemas:

    • Os desenvolvedores não podem saber se um artefato desativado foi atualizado sem pesquisa.
    • Dois arquivos, o original e a cópia, precisam ser mantidos. A manutenção dobra sempre que uma personalização é feita.
    • Com cada versão, o registro personalizado se torna mais antigo.
      • Os clientes não recebem as melhorias incluídas em uma nova versão.
      • Uma nova versão pode contar com o registro original que está sendo atualizado.
      • Os desenvolvedores podem fazer mais mudanças para compensar a inatividade do registro original.

    Um script em que somente o sinalizador Ativo é alterado será atualizado, mas o script não aparecerá na lista ignorada. Com a estratégia de copiar e desativar, um desenvolvedor tem menos visibilidade das personalizações e não pode avaliar ou reverter facilmente para a versão de linha de base.

    Em vez de copiar e desativar o artefato original, edite o artefato diretamente. O Mecanismo de upgrade da ServiceNow adicionará a versão mais recente ao histórico de versões e informará que o artefato foi ignorado. Os desenvolvedores podem ver que uma nova versão está disponível com o upgrade.