Diretrizes gerais para Workflow Studio fluxos, subfluxos e ações

Visão geral do Workflow Studio

Integre a criação, a configuração e o monitoramento de fluxos de trabalho em uma experiência de página única. Consolide playbooks, fluxos, ações, tabelas de decisão e integrações em um ambiente de design.

Desenvolvimento de aplicações

Ao projetar uma ação ou um fluxo, use estas diretrizes gerais.

Use recursos de desenvolvimento de aplicações padrão Now Platform para criar, gerenciar, proteger e implantar conteúdo Workflow Studio. 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 as permissões da aplicação para compartilhar ou restringir o acesso aos dados da aplicação.
Conceda aos desenvolvedores de aplicações acesso a Workflow Studio.
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 demorarem 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.

Impedir lógica de negócios conflitante ou duplicada

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

Revise a documentação de fluxos, subfluxose ações, se necessário.

Determine se o fluxo precisa de um gatilho ou 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 que a entrada para fluxos. Se você precisar de 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 para seus 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. A adição de funções de fluxo também concede acesso a dados adicionais que um fluxo iniciado pelo usuário normalmente 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 de fluxo

A lógica de fluxo ou os gatilhos baseados em programação ajudam a otimizar o desempenho de seus fluxos. Não use o método gs.sleep() para aguardar em um fluxo. O método gs.sleep() evita 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ção Aguardar 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 para o 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 1.000 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, cujo 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 o envio em lotes menores.
Para importações em massa, considere as importações simultâneas.

Use QuickAPI para execuções mais rápidas (alternativa de regra de negócio)

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 coletar uma saída grande

Usar uma carga grande imediatamente após sua 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 a instância e as etapas do servidor MID em um fluxo pode levar a atrasos no processamento. Para minimizar o risco de atrasos, limite a alternância entre a instância e o MID a apenas uma vez.

Incluir registros sys_complex_object gerados pelo fluxo em conjuntos de atualizações

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 conjuntos de atualizações manualmente, 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 necessidades de negócio, 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 criar um subfluxo que não tenha um gatilho. Use o 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 de executar o fluxo inesperadamente.

Evite implantar fluxos de versão mais recentes em instâncias em versões mais antigas

Workflow Studio não é compatível com a implantação de fluxos de versão mais recentes em instâncias em execução em versões anteriores.

Perigo:

O modelo de dados de fluxo pode mudar entre versões, o que pode impedir a execução de fluxos mais recentes ou produzir resultados inesperados ao executar em instâncias de versão anterior. Faça upgrade de suas instâncias para que estejam nas mesmas versões de lançamento antes de implantá-las.

Desativar a emissão de relatórios de fluxo na produção

Minimize a quantidade de memória necessária para executar fluxos desabilitando a Emissão de relatórios de fluxo. O relatório de fluxo armazena informações de configuração e tempo de execução para a página Detalhes da 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, a emissão de relatórios de fluxo está desabilitada 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 a emissão de relatórios está desativada.

Reduza a quantidade de memória consumida em fluxos com loop aninhado

Quando a emissão de relatórios estiver ativada, defina com.snc.process_flow.reporting.iteration.lastn com um valor de "1" para reduzir os valores das 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 a fluxos também se aplicam a subfluxos.

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

Determine se o fluxo precisa de um gatilho ou 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 que a entrada para fluxos. Se você precisar de 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 a cada chamada. 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 especificado pela propriedade do sistema sn_flow_designer.max_actions, mas limite 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 em vez de usar subfluxos paralelos

Use subfluxos paralelos se houver saídas inter-relacionadas ou se alguma ação precisar ser realizada quando todas estiverem disponíveis. Caso contrário, é 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, com 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 do IntegrationHub.

Evite o limite de 10 itens no processo de manipulação de erros

Em vez de forçar o processo de tratamento de erros para caber dentro de um limite de 10 itens, chame 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 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 que a entrada para fluxos. Se você precisar de entrada de variável para iniciar um fluxo, crie um subfluxo.
Adicionar 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, pausar e aguardar para retomar o fluxo até que uma condição de registro específica seja aplicada. Em vez de criar um fluxo que começa com uma ação Aguardar condição, redesenhe 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 evitar que os fluxos substituam um ao outro, crie condições exclusivas para cada fluxo em execução na mesma tabela. Se houver vários fluxos na mesma tabela e o mesmo filtro, não haverá 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 para 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 ou tabela inteira, em vez de a um registro individual.
Substitua os gatilhos de registro nas tabelas do Catálogo de serviços pelos gatilhos da aplicação 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.

Use 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 esperem indefinidamente especificando condições de interrupção de fluxo com Finalizar lógica de fluxo 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 incidentes em que o incidente relacionado está encerrado.
Restringir 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 para outro registro, pois esses campos realmente pertencem ao registro relacionado. Evite criar condições de espera que dependem de variáveis de catálogo.

Fluxos ou subfluxos com fases

Siga estas diretrizes gerais ao criar fluxos ou subfluxos com fases.

Evite definir fases que dependem de uma lógica de fluxo "Para cada": O Flow Designer evita que você adicione fases em um bloco Para cada. Você só pode adicionar fases antes ou depois de um bloco Para cada.
Evite criar fases para os mesmos registros em diferentes fluxos ou subfluxos: Um campo de fase sempre exibe as informações de fase fornecidas pelo último fluxo ou subfluxo a ser executado no registro de uma tabela. Se vários fluxos ou subfluxos forem executados nos mesmos registros, as fases definidas em um fluxo ou subfluxo poderão, em princípio, substituir as fases de outro fluxo ou subfluxo. Para evitar que vários fluxos ou subfluxos substituam as fases um do outro, defina um gatilho exclusivo ou condições de início para cada fluxo ou subfluxo.
Evite atualizar campos de fase de fora de um fluxo ou subfluxo: Se você gerenciar fases com um fluxo ou subfluxo, evite atualizar diretamente os campos de fase do registro de fora do fluxo ou subfluxo. 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. A especificação de condições de gatilho exclusivas 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 uma fase 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 interromper 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 interromper o processamento do fluxo ou realizar algum tipo de ação de correção. Por exemplo, você pode mudar o estado ou a atribuição do registro 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 tem um caminho que cria um registro e outro que atualiza o mesmo registro. O caminho do registro de atualização pode ser executado antes do caminho do registro de criação.
Não compartilhe dados entre caminhos: Workflow Studio evita que você arraste cápsulas de dados entre caminhos porque o sistema não pode determinar qual caminho será concluído 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 do 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.
Use 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 na execução correta sempre que obter saídas de fluxo.

Cápsulas de dados do Password2

Siga estas diretrizes gerais ao projetar fluxos que contenham dados de senha (criptografada bidirecional).

Atribua valores usando as cápsulas de dados de senha (criptografada bidirecional) existentes.

Você só pode atribuir um valor a uma variável password2 selecionando uma cápsula de dados password2 existente. Não há suporte para a seleção de valores de outros tipos de campo. Workflow Studio 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 bidirecional).

Usar variáveis de senha (criptografada bidirecional) somente para tipos de campo válidos

Workflow Studio O impede a seleção de cápsulas de dados do 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.

Workflow Studio só permite que as cápsulas de dados do Password2 sejam arrastadas para os seguintes tipos de campo:

Campos do corpo do 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 do formulário de várias partes REST
- Valores codificados por URL de formulário
Campos SOAP
- Cabeçalhos
- Envelope

Nota:

você não pode usar variáveis de senha (criptografada bidirecional) 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 restrito 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álidos e tente novamente a ação.

Configurar módulos de criptografia para descriptografia

Somente usuários com um 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 porcentagem de ANS

Siga estas diretrizes gerais ao criar fluxos que contêm ações do Temporizador de percentual do 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 começa 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 condição para a lógica de fluxo. Crie lógica de fluxo para valores de status esperados, como Concluído, Reparoe Ignorado. Por exemplo, adicione um bloco de lógica de fluxo If para enviar uma notificação quando o Temporizador de percentual de ANS tiver um status Concluído.
Atribua a cada ação do Temporizador de Percentual de ANS um valor cumulativo exclusivo de Aguardar porcentagem: Cada ação do Temporizador de Percentual de ANS calcula sua própria Data/Hora de Término Programada usando seu valor percentual Aguardar. Se você criar várias ações do Temporizador de Percentual de ANS, atribua a cada ação seu próprio valor cumulativo exclusivo de Aguardar porcentagem. Por exemplo, crie três ações separadas com diferentes valores de porcentagem concluída, como 25%, 50% e 75% concluído. 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 ANS 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 Workflow Studio, 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 se esgote. Se a 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
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 muito grande para ser armazenado na memória. Limitar suas entradas dinâmicas a 40 valores de entrada minimiza as chances de você ficar sem memória e enfrentar comportamentos inesperados, como erros de renderização ou truncamento de dados.
Limitar a saída JSON a 5000 itens de matriz para modelos dinâmicos e escolhas 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 a 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 retornados para 5000. 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 buscar 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 Workflow Studio, 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 a 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 necessários. 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

Dados de List.[Tabela]

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 de lista exiba somente os registros que correspondem à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 de 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 da entrada antes de aplicar uma função de transformação. A aplicação de 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.
Testar 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 linhareutilizáveis e sustentáveis.

Escrever 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.

Revisar funções de transformação disponíveis

Workflow Studio 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 a partir do script em linha

Chame uma inclusão de script a partir do 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 ou subfluxos personalizados para código reutilizável em vez de script em linha

Crie ações ou subfluxos personalizados para lógica de dados reutilizáveis ou complexos, como alterar o 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 funcionalidade de ação e fluxo

Evite escrever scripts em linha que duplicam a funcionalidade de ação e 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 registro de criação e atualização.

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 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 de Para cada lógica de fluxo. 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 na descrição do fluxo fd_data._2__for_each.item.

Use sugestões autocompletáveis 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 autocompletáveis 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 de 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 de fácil manutenção.

Minimizar 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, torna-se 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 você precise rolar horizontalmente para vê-los e preenchê-los.
Crie um objeto separado para cada tipo de dados de registro: A maioria dos dados Workflow Studio 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 vêm.
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 cadeias 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 Workflow Studio.

Scripts 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, Workflow Studio 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.
Salvar seus objetos como modelos: Salve seus objetos como modelos para que você possa 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 de 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 objetos de contatos para armazenar vários objetos de contato. Salve o objeto de contato como um modelo para que você possa 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 da variável de saída da etapa 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 Domain Separation

Siga estas diretrizes gerais ao usar o Domain Separation com Workflow Studio.

Certifique-se de que os fluxos, ações e subfluxos de locatário sejam executados corretamente para os domínios: Como os locatários não podem substituir o conteúdo Workflow Studio, um administrador de provedor de serviço (SP) do domínio TOP deve criá-los e gerenciá-los para garantir que sejam executados corretamente nos 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 Workflow Studio conteúdo disponível de seu domínio atual e todos os domínios primários na hierarquia. Workflow Studio 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 conteúdo Workflow Studio, 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 fluxos e ações contenham somente artefatos de domínios atuais ou primários: Workflow Studio 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 pertence ao domínio ACME, ele não poderá conter ações ou subfluxos pertencentes ao domínio irmão INITECH.
Editar conteúdo Workflow Studio no domínio ao qual ele pertence: Os usuários em um domínio primário não podem ver fluxos, ações e subfluxos em um domínio secundário. Eles devem mudar para o domínio ao qual pertencem para serem editados. Por exemplo, um administrador no domínio TOP não pode ver fluxos do domínio ACME. O administrador deve alternar para o domínio ACME para vê-los e editá-los.

Implantação

Evite implantar fluxos de versão mais recentes em instâncias em versões mais antigas: Workflow Studio não é compatível com a implantação de fluxos de versão mais recentes em instâncias em execução em versões anteriores.
Perigo:
O modelo de dados de fluxo pode mudar entre versões, o que pode impedir a execução de fluxos mais recentes ou produzir resultados inesperados ao executar em instâncias de versão anterior. Faça upgrade de suas instâncias para que estejam nas mesmas versões de lançamento antes de implantá-las.

Manipulação de erros de fluxo

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

Evite adicionar itens de manipulação 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 subfluxo após o ponto em que retornou um erro. Adicionar ações de manipulação 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 de 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 Manipulador de erros de subfluxo vazia garante que ela sempre gere o estado Concluído (erro detectado).
Use subfluxos para evitar o limite de 10 itens: Em vez de forçar o processo de tratamento de erros para caber dentro de um limite de 10 itens, chame 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 gerais para obter os benefícios oferecidos pela avaliação de erro de ação.

Permitir 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 os dados necessários para etapas posteriores, você saberá que as etapas posteriores não poderão 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 executar 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 erro é interrompida quando a ação encontra uma condição de erro correspondente. Colocar as condições de erro gerais em primeiro lugar 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 a emissão de relatórios de fluxo na produção: Minimize a quantidade de memória necessária para executar fluxos desabilitando a Emissão de relatórios de fluxo. O relatório de fluxo armazena informações de configuração e tempo de execução para a página Detalhes da 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, a emissão de relatórios de fluxo está desabilitada 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 a emissão de relatórios está desativada.
Reduza a quantidade de memória consumida em fluxos com loop aninhado: Quando a emissão de relatórios estiver ativada, defina com.snc.process_flow.reporting.iteration.lastn com um valor de "1" para reduzir os valores das 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 alta prioridade. Os threads de trabalhador usam a prioridade relativa entre fluxos para selecionar o trabalho. Se todos os fluxos forem executados com alta prioridade, não haverá fluxos de prioridade mais baixa para aguardar.
Evite definir a 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 pausa perde seu valor de prioridade quando retoma a execução.
Usar alta prioridade para fluxos críticos para os negócios: Limite a alta prioridade a fluxos que têm alto valor comercial, são executados raramente e têm um tempo de execução curto. Evite definir fluxos de alto volume como alta prioridade, pois isso limita o número de threads de trabalhador disponíveis para executar outros fluxos. Um fluxo de alta prioridade de execução longa também pode reduzir os threads de trabalhador disponíveis para executar outros fluxos.
Usar baixa prioridade 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 em comparação com outros fluxos.