Disparo da esteira e filtro de entrada

Como uma execução começa

Quatro caminhos: alguém aperta Executar, chega a hora marcada, um serviço conectado avisa que algo aconteceu, ou um sistema de fora chama pela API.

Filtro de entrada: nem todo evento merece uma execução

Um serviço conectado avisa muito mais do que interessa. O filtro de entrada é um conjunto de regras avaliado antes de a execução existir — evento que não passa simplesmente não vira trabalho, e não custa nada.

Quatro coisas que valem saber:

1. Vale só para o que dispara sozinho. Apertar Executar sempre roda, e chamada de fora também: o filtro é sobre o que o gatilho entrega, não sobre a decisão de uma pessoa nem sobre um sistema que pediu explicitamente.
2. O que o serviço conectado já fazia continua valendo — evento repetido, avisos em rajada e disputa entre entregas continuam sendo tratados antes, como sempre foram.
3. Na dúvida, a execução acontece. Se o próprio filtro falhar, o evento passa. Engolir um disparo legítimo por um problema nosso é pior que rodar uma vez a mais.
4. Todo descarte fica registrado, com o motivo já preenchido com os valores daquele evento — e a tela mostra quantos disparos o filtro cortou nas últimas 24 horas. Sem isso o filtro seria caixa-preta: ninguém descobriria que uma regra mal escrita está cortando evento legítimo. O registro fica por 30 dias.

O ponto 4 vale como regra geral: todo mecanismo que descarta em silêncio precisa de um lugar que mostre o descarte.

Os campos que a esteira aprende do gatilho

Um evento traz dezenas de campos internos do serviço para você usar dois. Depois do primeiro disparo, o editor passa a oferecer campo por campo, com o valor do último disparo como dica — você escolhe da lista em vez de adivinhar o nome.

Campo cujo nome a esteira não conseguiria usar não é oferecido. É coerência entre o que a tela promete e o que a execução entrega.

Um interruptor para parar tudo

Existe um bloqueio geral que impede qualquer execução de começar — manual, agendada, por evento ou por ferramenta. Ele é um só, e isso é o ponto: um interruptor por caminho de disparo deixaria alguma porta aberta justamente no dia do incidente.

Disparo por sistema de fora

O quarto caminho: um sistema seu chama a esteira pela API pública, autenticado por chave da organização.

O disparo é sempre assíncrono, e não por limitação: uma esteira encadeia vários trabalhos de agente e pode levar horas. Quem chama recebe o identificador na hora e acompanha de duas formas — consultando o progresso quando quiser, ou registrando um endereço para ser avisado no fim.

Quatro coisas que não são óbvias por analogia com o botão da tela:

• O filtro de entrada não vale aqui. Ele existe para gatilho agendado e evento de serviço conectado. Chamada de fora entra sempre.
• Informação que a esteira esperava do gatilho chega vazia, sem erro. Se uma etapa cita algo que só um gatilho preencheria, aquilo vira vazio em silêncio — e a resposta do disparo lista o que faltou, para você descobrir na hora e não pelo resultado estranho três etapas depois. A mesma lista aparece na tela da esteira, ao lado do que a chamada de fato preenche.
• Repetir a mesma chamada não duplica a execução. Mandando a mesma chave de identificação, você recebe de volta a execução que já existe, com o estado atual dela — inclusive se ela tiver falhado. Não é uma resposta fixa: é o estado real, para você não ficar esperando por algo que já terminou mal.
• Chave restrita a certos agentes não dispara esteira que use outro agente. A restrição vale para a esteira inteira, e não só para a primeira etapa.

O que dá para fazer, e onde

Limites relacionados: cinco execuções ativas por esteira e dez gatilhos habilitados por esteira.