Considerações de design para o Flow Designer

  • Versão de lançamento: Washingtondc
  • Atualizado 1 de fev. de 2024
  • 36 min. de leitura
  • Crie, execute, solucione problemas e monitore seus fluxos com mais eficiência. Use essas diretrizes para otimizar o desempenho de seus fluxos.

    Desenvolvimento de aplicações

    Ao projetar uma ação ou um fluxo, use essas considerações de design como guia.

    Use recursos de desenvolvimento de aplicações padrão Now Platform para criar, gerenciar, proteger e implantar conteúdo Flow Designer. Os designers de fluxo e ação normalmente executam as seguintes tarefas de desenvolvimento de aplicações:
    • Crie uma aplicação personalizada para armazenar fluxos e ações.
    • Defina permissões de aplicação para compartilhar ou restringir o acesso aos dados da aplicação.
    • Conceda aos desenvolvedores de aplicações acesso a Flow Designer.
    • Publique aplicações personalizadas no repositório de aplicações para implantar fluxos e ações em outras instâncias.

    Fluxos

    Os fluxos devem ser coleções de trabalho curtas, modulares e reutilizáveis. Se eles levarem mais de uma hora para serem executados, provavelmente serão muito longos e poderão ser mais eficientes.

    Todas as diretrizes gerais que se aplicam a fluxos também se aplicam a subfluxos.

    Evitar lógica de negócios conflitante ou duplicada

    As automações podem ser criadas com o Flow Designer, regras de negócios, fluxos de trabalho e o Hub de integração. Antes de começar a usar Flow Designer , certifique-se de entender como as automações Now Platform existentes funcionam. Desative as automações antes de substituí-las por Flow Designer fluxos e ações. Consulte o Visão geral da arquitetura para saber como Flow Designer funciona no Now Platform.

    Revise a documentação de Fluxos, Subfluxose Ações, se necessário.

    Determine se o fluxo precisa de um gatilho ou de uma entrada variável
    Os fluxos sempre são executados quando suas condições de gatilho são atendidas e os gatilhos sempre fornecem os mesmos dados como entrada para fluxos. Se você precisar de uma entrada de variável para iniciar um fluxo, crie um subfluxo.
    Reutilizar lógica de negócios
    Crie um conjunto de operações reutilizáveis como um subfluxo que pode ser usado em vários fluxos.
    Conceder funções de fluxo para acessar dados protegidos por função e preservar as informações do usuário
    As funções de fluxo ajudam a manter as permissões dos fluxos simples. Use funções de fluxo para preservar as informações do usuário e conceder acesso aos dados, em vez de executar um fluxo como o usuário do sistema. Adicionar funções de fluxo também dá acesso a dados adicionais que um fluxo iniciado pelo usuário geralmente não tem. As funções concedidas se aplicam somente ao fluxo. Eles não se aplicam ao usuário que iniciou o fluxo.
    Use a lógica de fluxo ou um gatilho baseado em programação para controlar o tempo do fluxo
    A lógica de fluxo ou os gatilhos baseados em programação ajudam a otimizar o desempenho dos fluxos. Não use o método gs.sleep() para aguardar em um fluxo. O método gs.sleep() impede que o thread execute outro trabalho. Para executar um fluxo em um horário específico, use um gatilho baseado em programação. Para pausar um fluxo por uma duração específica, use a lógica de fluxo de condiçãoAguardar uma duração ou aguardar.
    Evitar dependências
    Ramificações paralelas que dependem uma da outra paralisam um fluxo quando uma ramificação precisa aguardar a saída de outra ramificação. Em vez de criar ramificações paralelas em um fluxo, chame um subfluxo e retorne os resultados ao fluxo principal.
    Contadores de loop de escopo

    Os loops de script não têm um número máximo de iterações, portanto, os loops são executados infinitamente quando não há uma condição de saída válida.

    Para garantir que haja uma condição de saída válida, contadores de loop de escopo em scripts em linha ou em etapas de script em uma ação. Adicionar var a para (i=0; i< comprimento; i + +) :para (var i = 0; i < comprimento; i + +)

    Limitar para cada e Fazer até loops para 1000 iterações
    Iterações com 1000 ou mais loops podem levar a problemas de memória por ter que armazenar detalhes de execução e registros de contexto.
    • Defina o máximo de registros em Pesquisar registros.
    • Evite alterar a propriedade sn_flow_designer.max_iterations, que tem como padrão 1000.
    • Para loops aninhados, cada loop tem seu próprio número máximo de iterações.
    • Para grandes quantidades de processamento de dados, considere agrupar em lotes menores.
    • Para importações em massa, considere as importações simultâneas.
    Usar QuickAPI para execuções mais rápidas (alternativa de regra de negócios)
    • As execuçõesde QuickAPI são muito mais rápidas, mas há menos capacidade de depuração.
    • As execuções de QuickAPI em primeiro plano são executadas na sessão do usuário como o usuário que chamou o fluxo.
    • As execuções de QuickAPI em segundo plano são executadas em um thread em segundo plano e na sessão do usuário do "sistema".
    Usar loops Fazer até em vez de chamar fluxos deles próprios
    A recursão direta em que um fluxo chama a si mesmo não é permitida e há erros. Recursão indireta em que o fluxo A chama o fluxo B, que chama o fluxo A é permitido até três vezes. Em vez de chamar um fluxo recursivamente, use a lógica de fluxo Fazer até para continuar trabalhando em registros até que uma determinada condição seja atendida.
    Executar fluxos em segundo plano
    A execução de fluxos em segundo plano permite que threads de IU sejam liberados em vez de pausar a sessão do usuário até que a execução do fluxo seja concluída. Por padrão, os fluxos são executados de forma assíncrona em segundo plano. A execução de fluxos em segundo plano permite que os usuários continuem trabalhando na IU enquanto o fluxo é executado.
    Evite a lógica de fluxo que aguarda após a coleta de uma saída grande
    Usar uma carga grande imediatamente após a recuperação pode ajudar a evitar problemas de memória. Em vez de armazenar uma carga grande na memória, adicione ações para processar a carga. Quanto mais cedo você processar uma carga recuperada, mais cedo o sistema poderá liberar memória para processar outras ações.
    Minimizar salternando entre ambientes
    Alternar constantemente entre as etapas instância e MID Server em um fluxo pode levar a atrasos no processamento. Para minimizar o risco de atrasos, limite a alternância entre instância e MID a apenas uma vez.
    Incluir registros sys_complex_object gerados pelo fluxo em conjuntos para atualização
    A ausência de esquemas de dados complexos pode causar problemas de execução. Certifique-se de incluir registros sys_complex_object gerados pelo fluxo em conjuntos de atualizações. Em vez de criar manualmente conjuntos de atualizações, considere transferir fluxos de uma instância para outra usando o repositório de aplicações.
    Fluxos de chamada de um script quando você precisar de um gatilho personalizado
    Se nenhum dos gatilhos existentes atender às suas necessidades de negócios, você poderá criar um script para iniciar um fluxo quando suas condições de gatilho personalizadas forem atendidas. Em vez de criar um fluxo com um gatilho desnecessário, considere a criação de um subfluxo, que não tem um gatilho. Use seu script para fornecer as entradas de subfluxo necessárias somente quando as condições do script forem atendidas. Chamar um subfluxo em vez de um fluxo evita a possibilidade de as condições do gatilho de fluxo serem atendidas e executar o fluxo inesperadamente.
    Evite implantar fluxos de versão mais recentes em instâncias em versões mais antigas
    Flow Designer não é compatível com a implantação de fluxos para instâncias em execução em versões anteriores. Às vezes, o modelo de dados do fluxo muda entre as versões, o que pode impedir a execução do fluxo ou produzir resultados inesperados.
    Desativar o relatório de fluxo na produção
    Minimize a quantidade de memória necessária para executar fluxos desabilitando o relatório de fluxo. O relatório de fluxo armazena informações de configuração e tempo de execução para a página Detalhes de execução. Esses relatórios são bons para solução de problemas, mas exigem que uma grande quantidade de dados seja mantida na memória e no banco de dados. Por padrão, o relatório de fluxo está desabilitado e o sistema só gera detalhes de execução quando você testa manualmente um fluxo ou ação. Em vez disso, você pode usar arquivos de log, que ainda estão disponíveis quando o relatório está desativado.
    Reduza a quantidade de memória consumida em fluxos com loop aninhado
    Quando o relatório estiver ativado, defina com.snc.process_flow.reporting.iteration.lastn como um valor de "1" para reduzir as quantidades de memória que as iterações de loop anteriores consomem. Quanto mais iterações você relatar, mais memória será necessária.

    Subfluxos

    As diretrizes gerais que se aplicam aos fluxos também se aplicam aos subfluxos.

    Os motivos para usar um subfluxo em vez de um fluxo incluem o seguinte:

    Determine se o fluxo precisa de um gatilho ou de uma entrada variável
    Os fluxos sempre são executados quando suas condições de gatilho são atendidas. Os gatilhos sempre fornecem os mesmos dados como entrada para fluxos. Se você precisar de uma entrada de variável para iniciar um fluxo, crie um subfluxo.
    Reutilizar lógica de negócios
    Crie um conjunto de operações reutilizáveis como um subfluxo que pode ser usado em vários fluxos.
    Configure diferentes valores de entrada para cada chamada
    Configure os valores de entrada de um subfluxo de forma diferente cada vez que você chamá-lo. Por exemplo, projete um subfluxo para aceitar diferentes tipos de registro como uma execução de entrada. Reutilize este subfluxo de registro genérico em vez de gravar um fluxo específico para cada tipo de registro.
    Melhorar o desempenho e a legibilidade de fluxos grandes

    Use subfluxos quando um fluxo exceder 25 ações. 50 é o número máximo de ações especificadas pela propriedade do sistema sn_flow_designer.max_actions, mas limita um fluxo a 25 ações para obter o melhor desempenho.

    Passar entradas e saídas com subfluxos
    Chame subfluxos se quiser passar entradas e saídas. Use subfluxos se quiser especificar as entradas disponíveis para um subfluxo quando ele iniciar ou se quiser especificar as saídas disponíveis para o fluxo primário após o término de um subfluxo.
    Acionar vários fluxos em um único evento versus usar subfluxos paralelos
    • Use subfluxos paralelos se houver saídas inter-relacionadas ou se alguma ação precisar ser tomada quando todas estiverem disponíveis. Caso contrário, será mais simples acionar vários fluxos.
    • Para configurar subfluxos paralelos, inicie cada subfluxo sem aguardar e use a condição aguardar para aguardar que cada subfluxo seja terminal (concluído, erro, cancelado)
    Use fluxos dinâmicos se você tiver vários subfluxos com funcionalidade semelhante
    Os fluxos dinâmicos permitem compartimentar seus processos aplicando um modelo para lidar com as entradas de vários subfluxos semelhantes. A compartimentalização permite distinguir entre subfluxos que executam funções semelhantes, como subfluxos para spokes IntegrationHub.
    Evite o limite de 10 itens no processo de tratamento de erros
    Em vez de forçar seu processo de tratamento de erros a se ajustar a um limite de 10 itens, chame os subfluxos, que podem conter muito mais itens. Você também pode usar as saídas de subfluxo para acionar a automação em outros fluxos.
    Executar ações corretivas
    Em vez de recriar a mesma sequência de ações em vários fluxos, crie subfluxos reutilizáveis para corrigir erros nos dados de registro. Quando um erro de fluxo deixar os dados de registro em um estado indesejado, use subfluxos para corrigir esses registros. Você pode usar o manipulador de erros para identificar esses dados de registro como uma saída de subfluxo.

    Gatilhos

    Siga estas diretrizes gerais ao criar gatilhos de registro.

    Determine se o fluxo precisa de um gatilho ou de uma entrada variável
    Os fluxos sempre são executados quando suas condições de gatilho são atendidas. Os gatilhos sempre fornecem os mesmos dados como entrada para fluxos. Se você precisar de uma entrada de variável para iniciar um fluxo, crie um subfluxo.
    Adicione condições para especificar quais valores de registro iniciam seu fluxo
    Iniciar um fluxo somente quando necessário consome menos recursos do sistema do que iniciar um fluxo, pausá-lo e aguardar para retomar o fluxo até que uma condição de registro específica se aplique. Em vez de criar um fluxo que começa com uma ação Aguardar condição, reprojete o fluxo para incluir a condição de espera como parte do gatilho de registro.
    Criar condições exclusivas para gatilhos de registro na mesma tabela
    Para impedir que os fluxos substituam um ao outro, crie condições exclusivas para cada fluxo em execução na mesma tabela. Se vários fluxos na mesma tabela o mesmo filtro, não há como saber a ordem na qual os fluxos são executados. O uso de condições também ajuda a otimizar o desempenho do fluxo, retornando um conjunto menor e mais preciso de registros.
    Ignorar registros adicionados ou atualizados por conjuntos de importação e atualização
    Os gatilhos de registro ignoram os registros adicionados ou atualizados aplicando um conjunto de atualizações ou importando um arquivo XML. Essas operações se aplicam à aplicação inteira ou à tabela em vez de a um registro individual.
    Substituir gatilhos de registro em tabelas do Catálogo de serviços por gatilhos de aplicação do Catálogo de serviços
    O Flow Designer não exibe mais tabelas do Catálogo de serviços como opções para gatilhos de registro. Em vez disso, crie fluxos que usam o tipo de gatilho da aplicação Catálogo de serviços.

    Condições de espera

    Siga estas diretrizes gerais ao criar fluxos que aguardam uma condição.

    Usar gatilhos de registro em vez de condições de espera para iniciar fluxos
    Se você quiser que um fluxo seja executado somente quando determinadas condições de registro forem atendidas, crie um fluxo com um gatilho de registro em vez de iniciar e pausar um fluxo. Um fluxo de espera consome mais recursos do sistema do que um gatilho de fluxo.
    Cancelar fluxos cujas condições de reinício nunca podem ocorrer
    Evite que os fluxos aguardem indefinidamente especificando condições de parada de fluxo com Lógica de fluxo de término de fluxo. Para liberar recursos do sistema, você também pode cancelar qualquer fluxo cujas condições de reinício nunca possam ser atendidas. Por exemplo, cancele fluxos que aguardam atualizações de registro de incidente em que o incidente relacionado está fechado.
    Restringir as condições de espera aos campos presentes na tabela atual
    A ação Aguardar condição só pode monitorar mudanças nos campos da tabela à qual o registro pertence. A ação não pode detectar mudanças em campos em registros relacionados ou variáveis de catálogo. Por exemplo, se uma ação aguardar mudanças em um registro de incidente, ela não poderá detectar mudanças em um registro relacionado, como um item do catálogo ou registro de tarefa de mudança. Evite criar condições de espera que façam referência com pontos a outro registro, pois esses campos realmente pertencem ao registro relacionado. Evite criar condições de espera que dependem de variáveis do catálogo.

    Fluxos com fases

    Siga estas diretrizes gerais ao criar fluxos com fases.
    Evite definir fases que dependem de uma lógica de fluxo Para cada
    O Flow Designer impede que você adicione fases em um bloco Para cada. Você só pode adicionar fases antes ou depois de um bloco Para cada.
    Evite ter vários fluxos com fases na mesma tabela
    Um campo de fase sempre exibe as informações de fase fornecidas pelo último fluxo a ser executado em uma tabela ou registro. Se vários fluxos forem executados nos mesmos registros, as fases definidas em um fluxo poderão, em teoria, substituir as fases de outro fluxo. Para evitar que vários fluxos substituam as fases um do outro, defina condições de gatilho exclusivas para cada fluxo.
    Evite atualizar os campos de fase
    Se você gerencia fases com um fluxo, evite atualizar diretamente os campos de fase com ações, regras de negócios, chamadas de script ou fluxos de trabalho. Atualizar manualmente o valor de um campo de fase pode produzir resultados inesperados ou indesejados.
    Certifique-se de que cada fluxo em uma tabela tenha condições de gatilho exclusivas
    Adicionar condições de gatilho exclusivas a cada fluxo garante que os fluxos sejam executados somente sob essas condições e evita que as fases de um fluxo substituam as fases de outro fluxo. Especificar condições exclusivas do gatilho facilita a solução de problemas de fluxos, limitando o número de execuções de fluxo que podem produzir mudanças de registro.
    Usar fases de erro para se comunicar com o usuário
    O estado de erro de fluxo não afeta a execução do fluxo. Um fluxo continua em execução mesmo se atingir um estágio de erro. Use um bloco de lógica de fluxo condicional para definir a fase de erro e comunicar ao usuário que o estado da fase atual é Erro. Por exemplo, se uma aprovação não for aprovada dentro do limite necessário, convém comunicar um erro ao usuário.
    Use a fase de erro para parar o processamento de um fluxo
    Use um bloco de lógica de fluxo condicional para identificar quando um fluxo entra na fase de erro. Use a lógica de fluxo para parar de processar o fluxo ou executar algum tipo de ação de correção. Por exemplo, você pode querer mudar o estado do registro ou a atribuição quando um fluxo atinge um estado de erro.

    Faça o seguinte na lógica de fluxo paralelo

    Evite criar dependências de dados entre caminhos
    Como um fluxo pode executar caminhos em qualquer ordem, evite criar dependências de dados entre caminhos separados. Por exemplo, não tenha um caminho que crie um registro e outro que atualize o mesmo registro. O caminho do registro de atualização pode ser executado antes do caminho do registro de criação.
    Não compartilhar dados entre caminhos
    Flow Designer impede que você arraste cápsulas de dados entre os caminhos porque o sistema não pode determinar qual caminho terminará primeiro para fornecer o valor de saída.

    Lógica de fluxos dinâmicos

    Use fluxos dinâmicos se você tiver vários subfluxos com funcionalidade semelhante
    Os fluxos dinâmicos permitem compartimentar seus processos aplicando um modelo para lidar com as entradas de vários subfluxos semelhantes. A compartimentalização permite distinguir entre subfluxos que executam funções semelhantes, como subfluxos para spokes IntegrationHub.
    Certifique-se de que as entradas de subfluxo chamadas dinamicamente correspondam às entradas de fluxo do modelo
    O sistema gera um erro e o fluxo principal não pode ser executado corretamente quando as entradas de um fluxo dinâmico e do modelo de fluxo não coincidem.
    Usar o contexto correto ao obter saídas de fluxo
    Um registro de contexto identifica exclusivamente a execução do fluxo. Se você executar um fluxo dinâmico várias vezes, haverá vários registros de contexto para escolher. Quando você usar o fluxo dinâmico várias vezes em um fluxo, certifique-se de escolher o registro de contexto correto da execução correta sempre que obter saídas de fluxo.

    Cápsulas de dados de Password2

    Siga estas diretrizes ao projetar fluxos que contenham dados de senha (criptografados bidirecionalmente).
    Atribua valores usando cápsulas de dados de Senha (criptografada bidirecionalmente).
    Você só pode atribuir um valor a uma variável password2 selecionando uma cápsula de dados de password2 existente. Não há suporte para a seleção de valores de outros tipos de campo. Flow Designer apresenta uma mensagem de aviso quando tipos de cápsula de dados inválidos são selecionados.

    A mensagem de aviso exibida ao arrastar uma cápsula de dados que não seja password2 para um campo password2.

    Nota:
    Você não pode inserir manualmente valores de Senha (criptografada bidirecionalmente).
    Usar variáveis de Senha (criptografada bidirecionalmente) somente para tipos de campo válidos
    Flow Designer impede a seleção de cápsulas de dados Password2 como o valor para tipos de campo inválidos. O sistema apresenta uma mensagem de aviso quando o campo é de um tipo incompatível.

    O aviso mostrado ao arrastar um campo password2 para um campo não permitido.

    Flow Designer permite que somente cápsulas de dados Password2 sejam arrastadas para os seguintes tipos de campo:
    • Campos de corpo de e-mail
    • Campos HTML
    • Campos de senha 2
    • Variáveis de entrada do PowerShell
    • Campos REST
      • Variáveis
      • Corpo da carga REST
      • Parâmetros de consulta
      • Cabeçalhos
      • Valores de formulário REST de várias partes
      • Valores codificados por URL de formulário
    • Campos SOAP
      • Cabeçalhos
      • Envelope
    Nota:
    você não pode usar variáveis de Senha (criptografada bidirecionalmente) como condições

    O Flow Designer executa uma verificação de validação quando um usuário salva, publica ou testa ações e fluxos. Esta verificação mostra que um alerta para quaisquer cápsulas de dados descartados em tipos de campo restritos e impede a execução da ação ou do fluxo. Atualize a ação ou o fluxo para remover a cápsula de dados inválida e tente a ação novamente.

    Configurar módulos de criptografia para descriptografia
    Somente usuários com acesso válido ao módulo de criptografia podem descriptografar e exibir o conteúdo das variáveis password2. Para especificar o algoritmo de criptografia e quais funções podem acessar dados criptografados, consulte Criptografia Password2 com KMF .

    Ações do Temporizador de Percentual de ANS

    Siga estas diretrizes gerais ao criar fluxos que contenham ações do Temporizador de porcentagem de Acordo de nível de serviço (ANS).

    Adicionar ações do Temporizador de Percentual de ANS somente a fluxos com um gatilho de Tarefa de ANS
    Uma ação do Temporizador de Percentual de ANS só pode ser executada quando o fluxo inicia a partir de um gatilho de Tarefa de ANS. Você não pode ativar um subfluxo que contém uma ação do Temporizador de Percentual de ANS.
    Criar lógica de fluxo condicional para valores de status esperados
    Use o valor do campo Status como uma condição para a lógica de fluxo. Crie lógica de fluxo para valores de Status esperados, como Concluído, Reparare Ignorado. Por exemplo, adicione um bloco de lógica de fluxo If para enviar uma notificação quando o Temporizador de porcentagem de ANS tiver um status Concluído.
    Atribua a cada ação do Temporizador de Percentual de ANS um valor percentual cumulativo exclusivo de Aguardar
    Cada ação do Temporizador de Percentual de ANS calcula sua própria Data/Hora de Término Programada usando seu valor de porcentagem Aguardar. Se você criar várias ações do Temporizador de Percentual de ANS, forneça a cada ação seu próprio valor percentual cumulativo Aguardar. Por exemplo, crie três ações separadas com diferentes valores de porcentagem de conclusão, como 25%, 50% e 75% concluídos. Definir todas as três ações com o mesmo valor de porcentagem concluída, como 25%, faz com que os temporizadores sejam concluídos ao mesmo tempo.
    Copiar fluxos existentes para fazer personalizações
    Reduza o tempo de desenvolvimento copiando os fluxos de SLA padrão e personalizando as cópias com sua própria lógica. Selecione um fluxo personalizado a ser executado a partir da definição do ANS. Consulte Criar uma definição do ANS .

    Entradas dinâmicas

    Considerar entradas dinâmicas para integrações de terceiros
    As entradas dinâmicas permitem criar fluxos que buscam dados dinamicamente de fontes externas. Em integrações de terceiros, as entradas dinâmicas podem fornecer valores de dados que pertencem a um endpoint específico. Para obter mais informações sobre como configurar integrações de terceiros com Flow Designer, consulte IntegrationHub.
    Esteja ciente do tempo necessário para recuperar grandes quantidades de dados
    Por padrão, as entradas dinâmicas têm até 300 segundos para coletar dados antes que o tempo limite seja atingido. Se sua ação de coleta de dados precisar de mais tempo para coletar dados, defina a propriedade do sistema sn_flow_designer.sync_action_execution_timeout_in_seconds com um valor mais alto. No entanto, não use valores de tempo limite longos para fluxos interativos em que um usuário final deve inserir ou selecionar um valor.
    Esteja ciente dos erros de script
    Como todas as ações de coleta de dados usam uma etapa de script, podem ocorrer erros de script. Ao usar scripts para gerar variáveis JSON para suas entradas dinâmicas, você pode encontrar erros que impedem as entradas de receber os valores JSON de que precisam. Quando ocorre um erro de script de entrada dinâmica, a seguinte mensagem de aviso pode ser exibida.
    Figura 1. Mensagem exibida para erro de script
    Mensagem de erro de ação dinâmica
    Limitar as entradas do tipo de entradas dinâmicas a 40 valores de entrada
    Uma entrada do tipo de entradas dinâmicas só pode renderizar um determinado número de entradas antes que o objeto JSON se torne grande demais para ser armazenado na memória. Limitar as entradas dinâmicas a 40 valores de entrada minimiza as chances de ficar sem memória e de experimentar comportamentos inesperados, como erros de renderização ou truncamento de dados.
    Limitar a saída JSON a 5.000 itens de matriz para modelos dinâmicos e opções dinâmicas
    As entradas de escolha dinâmica e modelo dinâmico podem exibir até 5.000 itens de matriz. Uma opção dinâmica só pode exibir até 5.000 opções de lista de seleção e um modelo dinâmico só pode exibir até 5.000 valores de modelo de campo. Se sua ação de coleta de dados coletar dados para um modelo dinâmico ou uma opção dinâmica, restrinja o número máximo de itens de matriz que ela retorna para 5.000. O limite de 5.000 itens de matriz evita que a instância tenha problemas de desempenho ao renderizar as opções ou os valores de campo.

    Saídas dinâmicas

    Usar saídas dinâmicas para integrações de terceiros
    Use saídas dinâmicas para introspecção e busque dados de sistemas externos durante o design de fluxo. Por exemplo, você pode especificar endpoints de serviço ou ações de chamada que interagem com APIs de endpoint específicas. Para obter mais informações sobre como configurar integrações de terceiros com Flow Designer, consulte IntegrationHub.
    Observe o tempo necessário para recuperar grandes quantidades de dados
    Por padrão, as saídas dinâmicas têm até 300 segundos para coletar dados antes que o sistema as interrompa. Se sua ação de coleta de dados precisar de mais tempo para coletar dados, defina a propriedade do sistema sn_flow_designer.sync_action_execution_timeout_in_seconds com um valor maior. Evite valores de tempo limite longos para fluxos interativos em que um usuário final espera inserir ou selecionar um valor.
    Esteja ciente dos erros de script
    Como todas as ações de coleta de dados usam uma etapa de script, podem ocorrer erros de script. Revise todos os scripts usados para gerar variáveis JSON porque os erros de script podem impedir que as saídas recebam os valores JSON de que precisam. Quando ocorre um erro de script de saída dinâmica, a seguinte mensagem de aviso pode ser exibida.
    Figura 2. Mensagem exibida para erro de script
    Mensagem de erro de ação dinâmica

    Listar.[Tabela] dados

    Adicionar um qualificador de referência para filtrar registros de lista
    Filtre os registros que a variável de lista exibe como opções válidas adicionando um qualificador de referência. O qualificador de referência atua como um filtro de lista necessário e faz com que a variável da lista exiba somente registros que correspondam às condições do qualificador de referência. Por exemplo, para exibir somente registros de incidentes ativos, adicione a condição do qualificador de referência [Active][is][true].
    Evite selecionar registros padrão para ações destinadas à ServiceNow Store
    Evite selecionar registros padrão para uma lista, a menos que você saiba que todas as instâncias têm acesso aos registros selecionados. Os desenvolvedores do spoke normalmente não têm acesso aos dados dos clientes que instalam sua ação personalizada. Se você quiser publicar uma ação personalizada na ServiceNow Store, talvez precise fornecer registros padrão como dados de demonstração.
    Usar Variáveis de lista na lógica de fluxo Para cada
    Você pode usar uma variável Lista para especificar os registros a serem processados na lógica de fluxo Para cada. A lógica de fluxo Para cada ignora qualquer sem registro sys_id presente nos dados. Por exemplo, se a variável Lista contiver um endereço de e-mail, a lógica de fluxo o ignorará.

    Regras de aprovação

    Forneça um valor padrão
    Crie ou selecione uma regra de aprovação como um valor padrão.

    Funções de transformação

    Aplicar funções de transformação a tipos válidos de cápsulas de dados para a entrada
    Certifique-se de verificar o tipo de cápsula de dados para a entrada antes de aplicar uma função de transformação. Aplicar uma função de transformação a um tipo de cápsula de dados inválido faz com que o sistema ignore a transformação. Também ocorrerá um erro se as funções de transformação produzirem resultados que o sistema não possa analisar. Por exemplo, ao transformar uma cadeia de caracteres em uma data, o sistema emitirá um erro se a transformação não produzir uma data válida.
    Confirmar funções de transformação aplicadas para várias entradas com a mesma cápsula de dados
    Uma função de transformação cria um novo valor no tempo de execução para uma entrada específica e não muda a cápsula de dados original. Se você usar a mesma cápsula de dados em várias ações ou etapas, as funções de transformação deverão ser aplicadas a cada entrada individualt.
    Exibir valores transformados finais nos detalhes de execução do fluxo
    Somente o valor transformado final, e não o valor de cada transformação aplicada, aparece nos detalhes de execução do fluxo.
    Teste as funções de transformação para verificar se elas produzem os resultados esperados
    Certifique-se de que suas funções de transformação produzam os valores de tempo de execução esperados para as cápsulas de dados. Para obter mais informações, consulte Testar um fluxo e Testar uma ação.

    Scripts em linha

    Siga estas diretrizes gerais para criar scripts em linha [] reutilizáveis e mantidos .

    Gravar script em linha para lógica pequena não reutilizável
    Use o formato de script em linha ou modifique os dados para entradas e casos de uso específicos. Para lógica reutilizável, crie uma ação ou subfluxo.
    Analisar as funções de transformação disponíveis
    Flow Designer fornece uma lista de funções de transformação padrão para conversões de dados e operações de formatação. Em vez de escrever e manter uma solução de script personalizada, selecione uma função de transformação existente, se houver uma disponível.
    Inclusões de script de chamada do script em linha
    Chame uma inclusão de script do seu script em linha para reduzir a quantidade de código que você grava e também para manter o código comum em um único local. Use o construtor de classe para chamar sua inclusão de script. Para obter mais informações sobre como criar uma inclusão de script, consulte Script includes.
    var si = new MyScriptInclude();
    si.functionOne();
    Crie ações personalizadas ou subfluxos para código reutilizável em vez de script em linha
    Crie ações ou subfluxos personalizados para lógica de dados reutilizável ou complexa, como mudança do tipo de dados de origem. Você também pode fornecer ações personalizadas ou subfluxos para designers de fluxo que não se sintam à vontade com o código.
    Evite duplicar a funcionalidade de ação e fluxo
    Evite escrever scripts em linha que dupliquem a ação e a funcionalidade de fluxo. Por exemplo, em vez de escrever um script em linha para executar operações de registro, use as ações de linha de base de criação e atualização de registro.
    Evitar mudanças de tipo de dados
    Evite erros de tempo de execução verificando se o script em linha fornece informações no mesmo tipo de dados que a entrada ou a saída espera.
    Crie variáveis declarando-as com a palavra-chave var
    Use a palavra-chave var para declarar variáveis para que elas permaneçam dentro do escopo JavaScript apropriado. Quando você cria uma variável atribuindo um valor a ela, o JavaScript pode anexá-la ao objeto global, o que pode fazer com que os valores de variável persistam fora do escopo local e causem erros.
    Processar saídas de registros com a lógica de fluxo Para cada e o objeto de dados de fluxo
    O script em linha só pode acessar a saída de registros de uma ação Pesquisar registros da lógica de fluxo Para cada. Adicione uma ação Pesquisar registros ao fluxo para gerar a saída de registros. Adicione uma lógica de fluxo Para cada ao fluxo para processar cada registro na saída de registros. Crie uma referência de script em linha para a lógica de fluxo Para cada usando os objetos fd_data e item. Por exemplo, esta referência pressupõe que a lógica de fluxo Para cada é o segundo item no contorno do fluxo fd_data._2__for_each.item.
    Use sugestões de digitação antecipada para gerar referências a dados de fluxo e ação.
    Crie referências para dados de fluxo e ação usando o objeto fd_data. O editor de script exibe sugestões de digitação antecipada para dados de fluxo e ação existentes quando você digita fd_data. Selecione uma sugestão para criar referências para dados de fluxo e ação.
    Nota:
    Consulte os dados de registro em uma lógica de fluxo Para cada usando o objeto do item.
    Contadores de loop de escopo

    Os loops de script não têm um número máximo de iterações, portanto, os loops são executados infinitamente quando não há uma condição de saída válida.

    Para garantir que haja uma condição de saída válida, use contadores de loop de escopo em scripts em linha ou em etapas de script em uma ação. Adicionar var apara (i=0; i< comprimento; i+ +) e obter para (var i=0; i< comprimento; i + +)

    Dados complexos

    Siga estas diretrizes gerais para criar estruturas de dados reutilizáveis e que podem ser mantidas.

    Minimize o número de níveis secundários na hierarquia
    Quanto mais níveis secundários uma estrutura de dados tiver, mais difícil será exibir e selecionar uma variável de dados na hierarquia. Embora você possa criar estruturas de dados com qualquer número de níveis secundários, fica difícil navegar e entender estruturas de dados com mais de sete níveis secundários. Para obter a melhor experiência do usuário, evite criar estruturas de dados que tenham tantos níveis secundários que precisem rolar horizontalmente para vê-los e preenchê-los.
    Crie um objeto separado para cada tipo de dados de registro
    A maioria dos dados Flow Designer são dados de registro, sejam de uma instância ou de um sistema externo. Este método de design garante que você saiba o que o objeto contém e de onde os dados vieram.
    Recriar estruturas de dados de registro
    Ao criar objetos que recebem ou transmitem dados de registro, revise as entradas do dicionário do banco de dados para esses registros e crie estruturas de dados de objeto correspondentes. Por exemplo, suponha que você queira que um objeto contenha dados das tabelas Incidente e Item de configuração. Você pode criar um elemento de cadeia de caracteres para o campo Descrição resumida na tabela Incidente e uma matriz de elemento de cadeia de caracteres para o campo Classe na tabela [ Item de configuração.
    Criar objetos para combinar diferentes tipos de registros
    Se você precisar de informações de vários tipos de registros, crie um objeto que contenha todas as informações necessárias. Você pode usar o objeto para formatar ou analisar dados em Flow Designer.

    Script com dados complexos

    Lembre-se dessas diretrizes gerais ao criar scripts com dados complexos.

    Use entradas de cadeia de caracteres para converter dados complexos em uma cadeia de caracteres JSON
    Quando você mapeia dados complexos para uma entrada de cadeia de caracteres, Flow Designer os converte automaticamente em uma cadeia de caracteres JSON. Em vez de escrever um script, você pode adicionar uma entrada de cadeia de caracteres a uma etapa REST e mapeá-la para dados complexos de uma ação ou etapa anterior.
    Salve seus objetos como modelos
    Salve seus objetos como modelos para poder reutilizá-los em outras ações, fluxos e etapas de script.
    Criar variáveis de entrada de script para acessar dados anteriores
    Crie uma variável de entrada de script para todos os dados que você deseja acessar a partir da entrada da ação ou de uma etapa anterior. Mapeie a variável de entrada do script para a cápsula de dados de entrada ou de etapa. Por exemplo, mapeie a variável de entrada do script para uma lista de registros de usuário que você pesquisou em uma etapa anterior.
    Criar uma variável de saída de script para armazenar dados complexos
    Crie uma variável de saída de script para armazenar todos os dados complexos que seu script criar. As variáveis de saída do script devem corresponder aos valores definidos no script. Por exemplo, crie uma matriz de contatos de objetos para armazenar vários objetos de contato. Salve o objeto de contato como modelo para reutilizá-lo.
    Mapear a saída da ação para a variável de saída do script
    Quando você quiser que uma ação personalizada gere dados complexos, adicione uma saída de ação e mapeie-a para a cápsula de dados para sua variável de saída da etapa de script. Por exemplo, crie uma matriz de contatos e carregue o modelo de objeto de contato que você salvou anteriormente. Mapeie a saída da ação para a matriz de contatos produzida pela etapa de script.

    Flow Designer e separação de domínio

    Siga estas diretrizes gerais ao usar a separação de domínio com Flow Designer.

    Certifique-se de que os fluxos, as ações e os subfluxos do locatário sejam executados corretamente para os domínios
    Como os locatários não podem substituir o conteúdo Flow Designer, um administrador de provedor de serviço (SP) do domínio TOP deve criá-los e gerenciá-los para garantir que sejam executados corretamente para os domínios. Embora você possa criar fluxos específicos de domínio, os usuários que trabalham em domínios superiores na hierarquia podem acionar vários fluxos de domínio secundário. Por exemplo, um usuário que trabalha no domínio TOP pode acionar fluxos em domínios secundários, como ACME e INITECH.
    Nota:
    Os autores de fluxo podem ver somente o conteúdo Flow Designer disponível do domínio atual e de todos os domínios primários na hierarquia. Flow Designer não exibe o conteúdo visível de domínios "contém".
    Forneça um nome exclusivo para cada fluxo, ação e subfluxo
    Como todos os domínios compartilham o conteúdo Flow Designer, faça com que um administrador de SP no domínio TOP nomeie exclusivamente cada fluxo, ação e subfluxo. Isso garante que um fluxo destinado a um domínio não duplique o nome de um fluxo em outro domínio. Por exemplo, adicione o domínio ao nome do fluxo, como Validar incidentes - TOP, Validar incidentes - ACMEe Validar incidentes - INITECH.
    Certifique-se de que os fluxos e as ações contenham somente artefatos dos domínios atuais ou primários
    Flow Designer impede a ativação de qualquer fluxo que contenha artefatos indisponíveis para os domínios atuais ou primários. Por exemplo, se você criar um fluxo específico de domínio que pertença ao domínio ACME, ele não poderá conter ações ou subfluxos pertencentes ao domínio semelhante INITECH.
    Editar conteúdo Flow Designer no domínio ao qual ele pertence
    Embora os usuários em um domínio primário possam ver fluxos, ações e subfluxos em um domínio secundário, eles devem editá-los no domínio ao qual pertencem. Por exemplo, um administrador no domínio TOP pode ver fluxos do domínio ACME, mas deve alternar para o domínio ACME para editá-lo.

    Implantação

    Evite implantar fluxos de versão mais recentes em instâncias em versões mais antigas
    Flow Designer não é compatível com a implantação de fluxos para instâncias em execução em versões anteriores. Às vezes, o modelo de dados do fluxo muda entre as versões, o que pode impedir a execução do fluxo ou produzir resultados inesperados.

    Tratamento de erros de fluxo

    Siga estas diretrizes para obter os benefícios oferecidos pelo tratamento de erros de fluxo.

    Evite adicionar itens de tratamento de erros à seção principal do fluxo
    Um fluxo normalmente para de ser executado quando uma ação ou subfluxo retorna um erro na seção principal. Um fluxo interrompido não pode executar nenhuma ação ou subfluxos após o ponto em que retornou um erro. Adicionar ações de tratamento de erros e subfluxos à seção Manipulador de erros garante que eles sejam executados quando houver um erro.
    Capturar informações de status de erro
    O objeto Status do erro contém informações sobre a ação que produziu um erro. Você pode usar essas informações para identificar a causa do erro, bem como registrar os dados que podem precisar de correção.
    Suprimir mensagens de erro de subfluxo
    Você pode habilitar o Manipulador de erros para um subfluxo para impedir que seus erros sejam propagados em cascata para um fluxo primário. Deixar a seção do Manipulador de erros de subfluxo vazia garante que ela sempre gere o estado Concluído (erro detectado).
    Usar subfluxos para evitar o limite de 10 itens
    Em vez de forçar seu processo de tratamento de erros a se ajustar a um limite de 10 itens, chame os subfluxos, que podem conter muito mais itens. Você também pode usar as saídas de subfluxo para acionar a automação em outros fluxos.
    Usar subfluxos para executar ações corretivas
    Em vez de recriar a mesma sequência de ações em vários fluxos, crie subfluxos reutilizáveis para corrigir erros nos dados de registro. Quando um erro de fluxo deixar os dados de registro em um estado indesejado, use subfluxos para corrigir esses registros. Você pode usar o manipulador de erros para identificar esses dados de registro como uma saída de subfluxo.

    Avaliação de erro de ação

    Siga estas diretrizes para obter os benefícios oferecidos pela avaliação de erro de ação.

    Permita que somente etapas independentes continuem a execução
    Permita que uma etapa continue em execução se ela não retornar os dados necessários para uma etapa posterior. Se uma etapa fornecer dados necessários para etapas posteriores, você saberá que as etapas posteriores não podem ser executadas com sucesso.
    Evite mais de 10 condições de erro
    Embora não haja limite para o número de condições de erro que você pode criar, cada condição de erro requer avaliação. Quanto mais condições de erro sua ação tiver para avaliar, mais lenta será a execução da ação.
    Identificar falhas de etapa específicas
    Você pode usar o Status da etapa para identificar quando uma etapa específica falha. Identificar uma etapa específica pode ser útil quando sua ação contém várias instâncias do mesmo tipo de etapa. Você também pode identificar uma etapa específica para que um manipulador de erros de fluxo possa tomar as ações corretivas apropriadas para a falha.
    Colocar condições de erro específicas antes de condições de erro gerais
    A avaliação de erros é interrompida quando a ação encontra uma condição de erro correspondente. Colocar condições gerais de erro primeiro pode impedir que a ação corresponda a condições de erro específicas.
    Usar rótulos de condição de erro descritivos
    Identifique uma condição de erro sem precisar editá-la. Por padrão, você só pode ver as condições de erro ao editá-las.

    Administrador de fluxo

    Desativar o relatório de fluxo na produção
    Minimize a quantidade de memória necessária para executar fluxos desabilitando o relatório de fluxo. O relatório de fluxo armazena informações de configuração e tempo de execução para a página Detalhes de execução. Esses relatórios são bons para solução de problemas, mas exigem que uma grande quantidade de dados seja mantida na memória e no banco de dados. Por padrão, o relatório de fluxo está desabilitado e o sistema só gera detalhes de execução quando você testa manualmente um fluxo ou ação. Em vez disso, você pode usar arquivos de log, que ainda estão disponíveis quando o relatório está desativado.
    Reduza a quantidade de memória consumida em fluxos com loop aninhado
    Quando o relatório estiver ativado, defina com.snc.process_flow.reporting.iteration.lastn como um valor de "1" para reduzir as quantidades de memória que as iterações de loop anteriores consomem. Quanto mais iterações você relatar, mais memória será necessária.
    Exibir valores transformados finais nos detalhes de execução do fluxo
    Somente o valor transformado final aparece nos detalhes de execução do fluxoe não o valor de cada transformação aplicada.

    Prioridade de fluxo

    Siga estas considerações de design ao definir a prioridade de fluxo.

    Evite definir todos os fluxos para serem executados com alta prioridade
    Use uma combinação de prioridades em vez de definir todos os fluxos com prioridade alta. Os threads de trabalho usam a prioridade relativa entre os fluxos para selecionar o trabalho. Se todos os fluxos forem executados com prioridade alta, não haverá fluxos de prioridade mais baixa para aguardar.
    Evite definir prioridade de fluxo para fluxos que precisam ser pausados
    Mantenha os fluxos que precisam ser pausados na prioridade média padrão, já que um fluxo que é pausado perde seu valor de prioridade ao retomar a execução.
    Usar prioridade alta para fluxos críticos para os negócios
    Limite a prioridade alta a fluxos que tenham alto valor comercial, sejam executados raramente e tenham um tempo de execução curto. Evite definir fluxos de alto volume como alta prioridade, pois isso limita o número de threads de trabalho disponíveis para executar outros fluxos. Um fluxo de alta prioridade de longa execução também pode reduzir os threads de trabalho disponíveis para executar outros fluxos.
    Usar prioridade baixa para fluxos de alto volume
    Execute fluxos de alto volume em baixa prioridade para que outros fluxos sensíveis ao tempo possam ser executados primeiro. Fluxos de baixa prioridade não devem ser sensíveis ao tempo.
    Usar prioridade média para fluxos sensíveis ao tempo
    Use a prioridade de fluxo padrão quando um fluxo tiver alguma urgência de tempo quando comparado a outros fluxos.