Workflows: coordenar tarefas, versões e execuções

Objetivo e modelo

Um Workflow coordena tarefas, dependências e decisões. A Session associa o Mapping ao contexto de execução; o Workflow determina como essas Sessions são combinadas. O canvas mostra tarefas Start, Session, Decision, Timer e End e suas conexões.

As dependências publicadas têm versão. Uma tarefa Session referencia sua Session e sessionVersion, que por sua vez referencia uma versão de Mapping. Alterar um rascunho anterior não muda silenciosamente uma definição de execução já publicada.

Pré-requisitos

Prepare uma Session publicada e aceita, capacidade elegível e compatível, localização autorizada de laboratório e saída exclusiva. Consulta, edição, publicação, execução e administração de agendamentos exigem suas próprias permissões. Siga a validação de nomes e evite nomes de objetos produtivos nos testes.

Criar e testar um Workflow mínimo

1. Abra Workflows, crie um Workflow de laboratório e informe nome, Domain, Folder e escopo autorizado de compartilhamento.
2. Adicione uma tarefa Session entre Start e End. No inspetor, escolha a definição publicada em Reusable session e confira a versão referenciada.
3. Conecte Start → Session → End arrastando de cada porta de saída até a próxima entrada. Adicionar uma tarefa não a conecta automaticamente.
4. Revise overrides declarados e dependências. Com várias entradas, joinPolicy=any ou all controla o encontro de dependências, não a posição visual.
5. Use Auto arrange workflow e Fit workflow para examinar o grafo. Esses controles ajustam a apresentação, não os dados.
6. Selecione Validate, corrija problemas, use Save draft e Publish. Publicar estabelece a versão aceita sem executá-la.
7. Selecione Run. Se houver configuração de entrada, confira o modo oferecido para cada origem e forneça a entrada autorizada de laboratório. Um arquivo anexado ao chat do DovaAI não é uma entrada de execução.
8. Encontre a tentativa no Monitor e compare tarefas e saída com o resultado esperado.

Temporizadores e decisões complementares

Para uma espera controlada, insira Timer antes da Session e informe 5 em Delay (seconds). O campo aceita 1–604800 segundos. Timer atrasa essa tentativa; não cria um agendamento recorrente.

Em Decision, configure True branch expression (JSON). Declare a variável de Workflow runMode, tipo string, padrão full e valores permitidos full e sample. Esta condição compara seu valor:

{"ref":"variables.runMode","op":"eq","value":"full"}

Conecte as portas True e False a destinos explícitos. False representa a alternativa complementar; repetir a condição True não constitui um teste válido dos dois caminhos. Use a linguagem JSON documentada, não SQL ou scripts arbitrários.

Conferir tarefas e dados

O exemplo mínimo lê registros sintéticos name,amount e grava os campos previstos. Espere uma execução de Session no caminho escolhido e confira a saída independentemente. Registre o identificador da tentativa, versões de Session/Mapping e overrides fornecidos. Um override da tentativa não é uma edição persistente da Session.

Para Decision, teste cada valor de entrada com saídas separadas e confira a ramificação. Uma ramificação ignorada difere de uma tarefa com falha. O laboratório de clientes descreve outro exemplo histórico com 1.000 entradas, 667 saídas esperadas e definições para estudo; esta página não exige uma cópia privada do código.

Agendar após a aceitação manual

Configuration → Workflow Scheduler administra agendamentos reutilizáveis. Crie um agendamento autorizado, confira calendário, timezone e estado habilitado e associe-o ao Workflow publicado correto. A zona do agendador difere da preferência de apresentação de datas em Profile.

Valide primeiro uma execução manual. Depois confira a próxima hora prevista e, separadamente, a tentativa real correspondente. Um agendamento habilitado registra uma intenção futura, não uma execução concluída. Desabilite agendamentos temporários ao terminar.

Validação e recuperação

O validador aceita 2–100 nós e 1–300 links, rejeita ciclos, identificadores repetidos e dependências inválidas e exige caminhos válidos e alcançáveis. Para tarefas em espera, confira predecessores, elegibilidade do worker, slots e exclusões. Para falhas, investigue o primeiro erro relevante no Monitor.

Quando uma Session ou um Mapping mudar, examine os avisos de dependência antes de republicar os consumidores deliberadamente. Retomar um checkpoint depende de estado persistido compatível; não equivale a uma transação sobre todos os destinos externos. Verifique o risco de duplicação antes de repetir ou reutilizar uma entrada armazenada.

Próximas leituras

Consulte Sessions para vínculos e recuperação, Workers para capacidade, Monitor para evidências e a referência de expressões para condições compatíveis.