Gatilhos

Aprenda a usar gatilhos para criar lógica em aplicativos sem escrever código.

Neste artigo, você aprenderá:

• Comandos de gatilho, lógica e comportamento de execução
• Melhores práticas para criar e organizar gatilhos
• Casos de uso comuns

Os gatilhos permitem que você adicione lógica ao seu aplicativo. Você pode usar gatilhos para interagir com dispositivos, enviar alertas, gravar dados, se comunicar com sistemas de back-end e muito mais — tudo isso sem escrever uma única linha de código.

Casos de uso comuns de gatilhos incluem:

• Navegar dentro de um aplicativo: use uma transição para ir para uma etapa diferente.
• Concluir um aplicativo: registre os metadados do aplicativo.
• Executar uma função de conector para acessar um sistema de back-end: use conectores para permitir que o Tulip interaja com sistemas de terceiros e execute uma função de conector por meio de um gatilho.
• Enviar alertas: envie e-mails ou alertas por SMS de um aplicativo para um administrador. Essas mensagens podem incluir imagens, informações de status sobre o processo ou outras informações relevantes.
• Armazenar dados: Armazene dados de entrada de um aplicativo em variáveis ou tabelas.
• Usar um dispositivo: para operadores que utilizam ambas as mãos durante um processo, adicione um gatilho para um evento do dispositivo, como um pedal, para avançar para a próxima etapa.

Como funcionam os gatilhos?

Lógica

Os gatilhos utilizam uma estrutura lógica do tipo “quando, se, então, senão ”:

• quando “o evento é registrado no Tulip”
• então “executar ação” ou “fazer transição”.

Os gatilhos também podem conter lógica condicional:

• quando “evento é registrado no Tulip”
• if “a condição for atendida”
• então “executar ação”
• caso contrário, “executar uma ação diferente”

Saiba mais sobre a lógica condicional dos gatilhos aqui.

Os gatilhos são agrupados por um Trigger Event e consistem em uma ação e condições.

Os gatilhos podem ser simples, como no exemplo abaixo:

Quando um botão for pressionado, passe para a próxima etapa.

Ou então, os gatilhos podem ser mais complexos, como a leitura de um código de barras que consulta um banco de dados back-end para retornar informações do pedido como uma variável.

Quando o leitor de código de barras gera dados na estação atual, uma (executada por meio de uma função de conector) recupera os detalhes do pedido de um banco de dados externo e armazena o valor em uma variável. O gatilho também passa para a próxima etapa.

Tipos de comandos

É possível usar dois tipos de comandos em um gatilho:

1. Ação: uma alteração no aplicativo que não está relacionada à mudança de etapas (por exemplo, exibir uma mensagem de erro, enviar um e-mail, capturar uma captura de tela do aplicativo)
2. Transição: um evento de navegação no próprio aplicativo (por exemplo, ir para a próxima etapa, concluir um aplicativo, cancelar um aplicativo). As transições podem permitir que outros gatilhos sejam acionados (ou seja, iniciados). Por exemplo, você pode criar um gatilho no nível do aplicativo que seja acionado toda vez que o aplicativo for concluído.

Fila de gatilhos

s (por exemplo, clicar em um botão) adicionam Acionadores a uma sequencial de thread único para serem executados no Tulip Player.

A afeta:1. Funções: * As funções são incluídas na Fila de Gatilhos2. Widgets personalizados: * A execução da lógica em um widget personalizado pode afetar a Fila de Gatilhos

Ordem de execução

Os gatilhos são executados em série e em ordem, com base no evento de acionamento ( Trigger Event ) (ou seja, clique em botão, temporizador, seleção de linha de tabela).

Os gatilhos são executados sequencialmente, o que significa que o primeiro gatilho da série deve ser concluído antes que o segundo comece a ser executado. Essa ordem de execução dos gatilhos é conhecida como fila de gatilhos.

A fila de gatilhos é independente de outras tarefas dentro de um aplicativo, como interações com variáveis (por exemplo, entradas de texto, caixas de seleção), widgets personalizados e JavaScript de widgets personalizados.

Como os valores de entrada são usados nos gatilhos?

Os valores de entrada (ou seja, variáveis) são passados por referência aos gatilhos.

Os gatilhos referenciam o valor de entrada de uma variável no momento da execução do gatilho. Se o valor de entrada for alterado antes da execução de um gatilho, o gatilho referenciará o valor mais atualizado.

As variáveis são globais para um aplicativo, o que faz com que possam ser alteradas por outras lógicas no aplicativo.

:

Quando os gatilhos são cancelados?

Os gatilhos na fila de gatilhos são cancelados e, portanto, não serão executados quando:

1. Um gatilho é colocado na fila após uma transição: quandouma transição é executada (por exemplo, “Próximo”, “Concluir aplicativo”, “Ir para a etapa pelo nome”, etc.), quaisquer gatilhos restantes na fila são cancelados.
2. Fechamento forçado do Tulip Player: seum operador fechar o Player à força (ou seja, se um aplicativo não estiver respondendo), quaisquer ações restantes em um gatilho em execução e todos os gatilhos restantes na fila são cancelados.

Tratamento de erros

Erros de gatilho e o cancelamento subsequente ocorrerão nos seguintes cenários:

1. Erro na ação do gatilho
2. Tempo limite do gatilho

Erro na ação do gatilho

Quando uma ação em um gatilho apresenta erro, as ações restantes nesse gatilho são ignoradas/canceladas:

Após um erro, por padrão, quaisquer gatilhos restantes na fila e no evento do gatilho não serão executados para os seguintes gatilhos no nível do aplicativo e da etapa:* Início do aplicativo* Conclusão do aplicativo* Cancelamento do aplicativo* Ao entrar na etapa* Ao sair da etapa

Para todos os outros tipos de gatilhos (por exemplo, “Quando o botão é pressionado”), a opção “Interromper os gatilhos restantes em caso de erro” está desativada por padrão.

Tempo limite do gatilho

Se um gatilho atingir o tempo limite (consulte “Tempos limite dos gatilhos”), todos os gatilhos restantes na fila serão cancelados.

Comportamento técnico

Tempo de execução do gatilho

• Os gatilhos são executados sequencialmente em um único tempo de execução do gatilho. O tempo de execução do gatilho é o período em que um gatilho está sendo executado ativamente no Tulip.
• Os gatilhos nunca são executados em paralelo ou em segundo plano em relação a outros gatilhos. Um novo gatilho não pode começar a ser executado até que o gatilho atual, em execução, seja concluído.
• Os operadores ainda podem interagir com o aplicativo (por exemplo, clicar em botões, interagir com tabelas) enquanto um gatilho está sendo executado. Esses cliques em botões e outros eventos de gatilho adicionarão novos gatilhos à fila de gatilhos.

Tempos limite dos gatilhos — atualizado a partir da LTS15 / r332

O tempo limite padrão do gatilho é de 10 minutos; após esse período, o gatilho e quaisquer ações restantes serão cancelados, e todos os outros gatilhos na fila serão cancelados.

O tempo limite de 10 minutos se aplica ao Trigger Event. Por exemplo, se um clique em um botão tiver 5 gatilhos, todos os 5 gatilhos na fila de gatilhos e suas respectivas ações devem ser executados dentro dos 10 minutos.

Após 30 segundos de execução do gatilho, o aplicativo exibe a seguinte mensagem ao operador:

Após 100 segundos de tempo de execução do gatilho, o aplicativo exibe a seguinte mensagem para o operador:

Após 10 minutos, o gatilho é cancelado e o aplicativo exibe a seguinte mensagem de erro:

Configurações opcionais de tempo limite

Edite as configurações de tempo limite de uma instância por meio dos métodos abaixo:

1. A Tulip pode ativar ou desativar uma configuração que permite aos operadores cancelar manualmente um gatilho de longa duração após os primeiros 100 segundos. Entre em contato com o Suporte da Tulip para ativar esse recurso.

2. O Suporte da Tulip pode diminuir ou aumentar o período de tempo limite. Observe que a Tulip recomenda o período de tempo limite de 10 minutos como ponto de partida, para aumentar a probabilidade de que sua lógica seja executada até o fim. Se um gatilho demorar consistentemente mais do que alguns minutos para ser executado, considere o seguinte:

   • Simplificar a lógica do gatilho para melhorar a experiência do operador e reduzir a probabilidade de falha do gatilho.
   • Se possível, inicie uma automação em segundo plano para descarregar a execução da lógica e evitar o bloqueio do trabalho contínuo do operador.
   • Revise e otimize quaisquer dependências de sistemas de terceiros na lógica do gatilho (por exemplo, funções de conector lentas, API não otimizada utilizada).

Ações de registro na tabela

Criação de registro de tabela

Para a criação de um novo registro de tabela, a prática recomendada é seguir imediatamente a ação “Registro de tabela / Criar registro” com as ações de manipulação de dados correspondentes para preencher as outras colunas do registro de tabela recém-criado.

Se houver outras ações entre a ação “Registro de tabela / Criar” e as ações para preencher as demais colunas, a geração desse registro de tabela será exibida como eventos separados no widget de histórico de registros.

Criação de registro de tabela – a partir da LTS15 / r332

A partir da versão LTS15, as ações sequenciais de tabela “Registro de tabela / Criar registro” e “Manipulação de dados / Armazenar” serão agrupadas para o mesmo registro. Isso significa que as ações “Criar” e “Manipulação de dados” em um gatilho são executadas em uma única transação.

As ações “Criar Registro ” e “Manipulação de Dados / Armazenar” não serão agrupadas em uma única transação se houver qualquer outra ação entre elas (por exemplo, manipulações de dados em variáveis ou outros registros de tabela, funções de conector etc.).

Nos gatilhos de exemplo a seguir, a ação “Criar Registro” e as ações “Manipulação de Dados / Armazenar” serão agrupadas e ou todas serão bem-sucedidas ou todas falharão. Se todas as ações falharem, elas serão repetidas juntas com tentativas resilientes.

Exemplo 1: Criação sequencial e manipulações de dados no mesmo registro da tabela. Essas açõesseriam todas bem-sucedidas ou todas falhariam no LTS15, mas não nas versões anteriores ao LTS12.

Exemplo 2: Criação sequencial e manipulações de dados no mesmo registro da tabela, seguidas por uma ação de função de conector. As ações de criação de registro da tabela e de manipulação de dados, por si só, seriam agrupadas no LTS15. A ação de função de conector poderia falhar, independentemente do sucesso das ações da tabela.

No gatilho a seguir, as ações “Manipulação de Dados” e “Armazenar” estão ocorrendo para dois registros de tabela diferentes e, portanto, as ações não serão agrupadas em uma única transação.

Exemplo 3: “Registro da Tabela / Criar” e “Manipulação de Dados / Armazenar” no mesmo registro da tabela, separadas por outra ação de “Manipulação de Dados”.Essasações não serão agrupadas em uma única transação.

No gatilho a seguir, as ações “Registro da tabela” e “Manipulação de dados / Armazenar” não serão agrupadas porque os metadados do registro da tabela criado na ação anterior estão sendo usados como entrada de dados para a ação “Manipulação de dados / Armazenar”.

Exemplo 4: Criar e atualizar lendo dados de si mesmo. Essas ações não serão agrupadas em uma única transação.

Ao usar uma agregação em uma ação de atualização de tabela agrupada, o valor da agregação é obtido antes que a atualização ocorra. O valor da agregação não refletirá a atualização do registro da tabela agrupada.

Exemplo 5: Criação e atualização com agregações Essasações serão agrupadas, e o valor da agregação é obtido antes que a ação de criação ocorra.

Atualização de registro de tabela

Ações sequenciais de manipulação de dados no mesmo registro da tabela são agrupadas para serem executadas em uma única solicitação de rede, de modo que todas ocorram juntas

Ações de acionamento envolvendo registros de tabela são agrupadas com base em seu tipo de ação e ordem. Ações de armazenamento que possuem o mesmo local de armazenamento são agrupadas em uma única solicitação de rede. Já ações como “Carregar registro” ou “Criar registro” são tratadas como transações individuais.

Para obter o melhor desempenho, recomendamos agrupar as atualizações no mesmo registro – ou seja, não separar as atualizações no mesmo registro de outras ações relacionadas à tabela ou aos dados.

Exemplo 1: Atualizações sequenciais no mesmo registro. Essasações serão agrupadas em uma única transação:

Exemplo 2: Atualizações no mesmo registro separadas por outras ações. Essas ações não serão agrupadas, pois os registros da mesma tabela não são sequenciais:

No gatilho a seguir, as ações de manipulação de dados/armazenamento estão ocorrendo para dois registros diferentes da tabela e, portanto, as ações não serão agrupadas em uma única transação.

Exemplo 3: Atualizações em dois registros diferentes. Essas ações não serão agrupadas em uma única transação.

Ao usar uma agregação em uma ação de atualização agrupada de tabela, o valor da agregação é calculado antes da atualização ocorrer. O valor da agregação não refletirá a atualização do registro da tabela agrupada.

Exemplo 4: Atualizações que incluem agregações Essasações serão agrupadas, o que significa que o valor da agregação é calculado antes da atualização ocorrer.

Repetições de gatilhos (ações de tabela) — novidade a partir do LTS15 / r332

Os gatilhos apenas repetem tentativas de ações de tabela (por exemplo, gravações de dados em tabelas, atualizações de dados em tabelas, interações com tabelas etc.).

Dentro dos 10 minutos de tempo de execução do gatilho, se uma única ação de tabela falhar, ela será repetida por até 2 minutos. Se a ação não for executada após 2 minutos, quaisquer ações e gatilhos restantes na fila do gatilho serão cancelados.

Para um gatilho resiliente à rede, certifique-se de que as ações do gatilho incluam apenas interações com tabelas e atualizações de dados. Consulte Ações de registros de tabela para obter orientações sobre ações de tabela resilientes.

As tentativas de reexecução de ações do gatilho não duplicarão o resultado caso a ação seja executada acidentalmente duas vezes. Isso garante que uma ação de tabela não grave múltiplos exemplares dos mesmos dados.

Limites e tempos limite

Tipos de gatilhos

Existem três tipos de gatilhos:

Gatilhos no nível do aplicativo

Você pode aplicar gatilhos no nível do aplicativo aos seguintes eventos:

• Início do aplicativo
• Conclusão do aplicativo
• Aplicativo cancelado

Acesse os gatilhos no nível do aplicativo na guia “Aplicativo”.

Saiba mais sobre gatilhos no nível do aplicativo aqui.

Gatilhos no nível da etapa

Você pode aplicar gatilhos no nível da etapa aos seguintes eventos:

• Em intervalos regulares de tempo (“disparos por tempo”)
• Quando há uma entrada de uma máquina ou dispositivo (“máquinas e dispositivos”)
• Quando a etapa é aberta
• Quando a etapa é fechada

Acesse os gatilhos no nível do passo na guia “Passo”.

Saiba mais sobre os gatilhos no nível do passo disponíveis aqui

Gatilhos de widget

Os gatilhos de widget são ativados quando um botão é pressionado. Pode haver vários gatilhos de botão em uma etapa que são acionados quando o respectivo botão é pressionado por um operador no Tulip Player.

Selecione o widget desejado e, em seguida, acesse os gatilhos de widget na guia “Widget”.

Saiba mais sobre os gatilhos de widget aqui.

Criar um gatilho

1. No , clique em + na seção Gatilhos. O editor de gatilhos será aberto.
2. Dê um nome ao seu gatilho para identificar sua função no aplicativo. Você também pode incluir uma descrição para fornecer mais detalhes.

Práticas recomendadas

• Configure os gatilhos para lidar com erros. Os gatilhosdevem ser configurados para continuar ou parar em caso de erro. Um gatilho pode apresentar erro devido a entradas inválidas, um erro de execução ou uma falha na função do conector ou na tentativa de gravação na tabela.
• Quando um gatilho é configurado para continuar, o gatilho que apresentou erro será interrompido, mas o próximo gatilho seguirá em frente
• Quando um gatilho é configurado para parar, os outros gatilhos no “Evento de Gatilho” serão cancelados.

• Evite ter gatilhos de longa duração em uma etapa com widgets interativos. Os widgetsmudam visualmente de estado imediatamente após a interação. Embora o operador veja a ação ocorrer imediatamente no widget, a lógica pode ser executada com um leve atraso devido a uma rede lenta ou a um conector de longa duração.
• Treine os operadores para esperar após clicar em uma transição (por exemplo, “Próxima etapa”). Em uma etapa, os gatilhos enfileirados após uma transição não serão executados. Se um operador interagir com um widget que possua uma transição, ele permanecerá na etapa até que a transição seja executada. Por exemplo, se o operador clicar em “Próxima etapa” e, em seguida, acionar outro gatilho enquanto espera, o gatilho restante após a transição não será executado.
• Execute conectores de longa duração e atualizações de dados em etapas separadas. Interaçõescom dados confidenciais não devem ser realizadas na mesma etapa que a lógica de conectores de longa duração. Caso um operador interaja com a etapa após clicar em um gatilho ou transição de longa duração, há o risco de que dados críticos não sejam armazenados.
• Certifique-se de que as variáveis tenham uma única entrada para cada etapa. As variáveisnão devem ser compartilhadas com lógicas de entrada concorrentes (ou seja, vários botões em um aplicativo atualizando a mesma variável) para evitar condições de corrida. Por exemplo, um gatilho captura o valor atual de uma variável. Se o valor da variável mudar antes que o gatilho o capture, os dados estarão incorretos.

Leitura complementar

• Lista de ações de gatilhos e transições
• Lógica condicional de gatilhos
• Melhores práticas para aplicativos de alto desempenho

{{snippet.Você encontrou o que estava procurando?}}