Toda automação do Curator nasce de um modelo REFRAMEWORK. É o modelo que decide como o robô organiza o trabalho: uma planilha lida linha por linha, ou uma fila que vários PCs podem dividir. Você escolhe o modelo ao criar a automação; depois, o Agente preenche o que o robô faz em cada etapa. Esta página é para quem desenha o processo. Não precisa saber programar.
Comece pelo que você quer fazerQuando você cria uma automação (botão “Criar automação”, na aba “Automação”), o assistente de novo projeto tem um passo chamado “Modelo”. A tela pede:
Na tela “Escolha o modelo REFRAMEWORK: Automação simples, Dispatcher, Performer ou Disperformer.”
Os quatro cartões, com o texto que aparece na tela:
“Coleta os dados e enfileira os itens para os Performers processarem.”
Escolha quando: os casos vêm de uma ou mais fontes (Excel/CSV, API REST, banco de dados, web) e outro projeto vai trabalhar neles.
“Consome a fila do Curator e processa os itens, podendo rodar vários em paralelo.”
Escolha quando: a fila já existe e você quer trabalhar os itens, em um PC ou em vários ao mesmo tempo.
“Enfileira e processa os itens no mesmo projeto, sem precisar de um par.”
Escolha quando: você quer as vantagens da fila, com o andamento de cada caso na aba “Filas”, mas com um projeto só.
“Processa as linhas da planilha, sem usar fila.”
Escolha quando: os casos estão numa planilha e um robô dá conta do volume.
| Se o seu caso é este… | Escolha |
|---|---|
| Os casos estão numa planilha e um PC dá conta do volume. | Automação simples |
| Você quer os casos numa fila, com o andamento de cada um na aba “Filas”, sem manter dois projetos. | Disperformer |
| Os casos vêm de Excel/CSV, API REST, banco de dados ou web, e a coleta roda no próprio horário. | Dispatcher + Performer |
| O volume é grande e você quer vários PCs trabalhando ao mesmo tempo. | Dispatcher + vários Performers |
| Outro projeto já enche a fila e falta quem trabalhe os itens. | Performer |
Na tela “Processa as linhas da planilha, sem usar fila.”
É o modelo mais direto. Cada linha da planilha é um caso. O robô pega a próxima linha, faz o trabalho daquele caso, anota o resultado e segue para a linha seguinte, até a planilha acabar. É o mesmo ciclo comum dos outros modelos. A diferença é que o “próximo caso” vem da planilha, não de uma fila.
Como não usa fila, não há fila para criar e nada desta automação aparece na aba “Filas”. Você acompanha a execução como qualquer outra: em “Resultados da Última Execução”, na própria aba “Automação”, e na aba “Execuções”.
Os outros três modelos usam uma fila do Curator: uma lista central de casos. Pense nela como uma esteira. Cada caso é uma ficha (um item da fila), com identificação, dados, status e histórico. Sobre essa esteira existem três papéis. Não são três tecnologias diferentes. São três jeitos de usar a mesma lista.
| Modelo na tela | Em português claro |
|---|---|
| Dispatcher (alimenta fila do Curator) |
Monta a pilha de fichas. Não lança nada no sistema de destino. |
| Performer (consome fila do Curator) |
Pega a próxima ficha, resolve o caso e devolve a ficha com o resultado. Vários podem trabalhar ao mesmo tempo. |
| Disperformer (alimenta e consome fila) |
Faz as duas coisas no mesmo projeto: primeiro monta a pilha, depois resolve ficha por ficha. |
REFRAMEWORK é o esqueleto que os quatro modelos seguem. Em vez de um script corrido, o robô passa por etapas fixas, sempre na mesma ordem, e trata um caso de cada vez. Numa automação aberta, as etapas aparecem no quadro “Fluxo do Projeto” da aba “Automação”, como no print abaixo.
Como ler o quadro:
O que cada etapa faz, em palavras simples, está logo abaixo, em O ciclo comum.
No passo “Modelo”, cada modelo mostra o próprio diagrama. O do Dispatcher (é o que aparece no print de Os quatro modelos) tem etapas com nomes próprios:
Início (agendado / cron) começa num horário: combina com um gatilho por horário
Carrega o Config.xlsx, valida o QueueName (o nome da fila) e se autentica no Curator.
Coleta os dados e monta a lista de itens. As fontes do diagrama:
Coloca os itens na fila de uma vez (inserção em lote), com status = new. Se o lote não entrar, tenta item a item.
Calcula as métricas (enfileirados e falhas) e envia o e-mail de relatório.
Fim
“Tolerância a erro: se um nó falha, process_error é registrado. Finalize SEMPRE executa.” Em palavras simples: se uma etapa der erro, o erro fica registrado e o fechamento roda do mesmo jeito. As métricas e o e-mail de relatório saem mesmo num dia ruim.
Na mesma tela, a descrição do Dispatcher resume o que ele traz do REFRAMEWORK base: “Mesma robustez do REFRAMEWORK base: retry isolado por item, BusinessRuleException vs SystemException, relatório local de auditoria. Playwright opcional via EnableBrowser em Config.xlsx.” Traduzindo:
EnableBrowser está ativada no Config.xlsx.
Por baixo dos nomes em inglês, o ciclo é simples: ligar, pegar o próximo caso, trabalhar só aquele, anotar o resultado e voltar a pegar. Quando não há mais caso, encerrar. Cada passo é uma etapa do “Fluxo do Projeto”:
| Passo | Etapa na tela | O que faz |
|---|---|---|
| Ligar | Initialization |
Lê a configuração e prepara o que o robô usa: a fila e o navegador, se precisar. |
| Pegar | GetTransactionData |
Descobre o próximo caso deste robô: uma linha da planilha (Automação simples) ou uma ficha da fila (Performer). |
| Trabalhar | ProcessTransaction |
Faz o trabalho daquele caso, e só dele. |
| Anotar | SetTransactionStatus |
Registra sucesso, falha de regra ou falha técnica e decide se tenta de novo. Depois volta a “Pegar”. |
| Encerrar | EndProcess |
Quando não há mais caso, fecha o que abriu. |
No Dispatcher, o mesmo ciclo aparece com outros nomes: InitDispatcher é o “Ligar”, BuildItems é o “Pegar” (ele coleta todos os casos), EnqueueItems é o “Trabalhar” (o trabalho dele é enfileirar) e Finalize é o “Encerrar”.
A pergunta prática é: se eu repetir agora, com os mesmos dados, tem chance de dar certo? Se não, é falha de negócio (BusinessRuleException): o robô não fica tentando. Se sim, é falha técnica (SystemException): pode tentar de novo, com limite. O detalhe está em Filas.
Dispatcher e Performer não se falam direto. Eles se encontram na ficha, o item da fila. Por isso precisam concordar sobre o que vai escrito nela: o acordo da ficha.
PED-88421. Não use “linha 2”.
InitDispatcher carrega o Config.xlsx e valida o QueueName, o nome da fila, antes de começar.
Na tela “Dispatcher (alimenta fila do Curator) · Coleta os dados e enfileira os itens para os Performers processarem.”
A pergunta dele: quais casos precisam entrar na fila agora? Ele não faz o cadastro no ERP, não baixa a nota até o fim, não confirma o protocolo. Ele prepara o trabalho.
O diagrama do modelo cita quatro fontes de casos. Na prática:
Pelas etapas: InitDispatcher prepara, BuildItems coleta e filtra, EnqueueItems coloca tudo na fila de uma vez e Finalize fecha com as métricas e o e-mail de relatório (veja o diagrama). Quando a origem acaba, ele encerra; não fica rodando sem parar. O normal é dar a partida num horário: crie um gatilho por horário, por exemplo todo dia no começo do expediente.
Analogia. É quem monta a pilha de processos na mesa. Não despacha cada processo no sistema.
Na tela “Performer (consome fila do Curator) · Consome a fila do Curator e processa os itens, podendo rodar vários em paralelo.”
A pergunta dele: qual é o próximo item que posso processar com segurança? Ele não lê a planilha de origem; só vê a fila. Pega o próximo item, reserva (outro PC não pega o mesmo), faz o trabalho e avisa a fila: sucesso, falha de regra ou falha técnica. Fila vazia: encerra.
Quando ligar. O par natural do Performer é o gatilho por fila: os novos itens de uma fila iniciam a automação, sem você adivinhar um horário. Os estados da ficha (Novo, Em processamento, Sucesso, Falha) estão em Filas.
Uma fila pode ter vários Performers ao mesmo tempo. Você não precisa de três filas para ter três PCs. O Curator entrega fichas diferentes para cada um, como um painel de senhas com três atendentes.
Analogia. É quem pega a próxima ficha da pilha, resolve aquele processo no sistema, devolve a ficha carimbada e pega a seguinte.
Na tela “Disperformer (alimenta e consome fila) · Enfileira e processa os itens no mesmo projeto, sem precisar de um par.”
Em uma frase: uma única automação que, em cada execução, primeiro coloca os casos na fila (por exemplo, as linhas de uma planilha) e depois consome essa mesma fila, como um Performer. Não são dois robôs. É um projeto, uma pasta, o mesmo nome de fila e duas fases na mesma execução.
Fase 1 (uma vez por execução). Lê os casos, monta as fichas e coloca todas na fila. Isso não é o lançamento no sistema: é só a passagem da origem para a pilha.
Fase 2. Igual ao Performer: pega o próximo da fila, trabalha, anota, próximo. Quando a fila esvazia, encerra.
Analogia. É a mesma pessoa que, de manhã, separa todas as fichas na pilha e, em seguida, ela mesma despacha ficha por ficha. Não chama um colega para a segunda metade.
| Automação simples | Dispatcher | Performer | Disperformer | |
|---|---|---|---|---|
| Pergunta | Qual é a próxima linha? | O que entra na fila agora? | Qual o próximo caso seguro? | As duas, nesta ordem, na mesma execução |
| De onde vem o caso | Linhas da planilha | Excel/CSV, API REST, banco de dados, web | Item que já está na fila | Primeiro a origem; depois a fila |
| Para onde vai | Sistema de negócio | Fila do Curator | Sistema de negócio | Origem → fila → sistema |
| Usa fila | Não | Alimenta | Consome | Alimenta e consome |
| Precisa de par | Não | Sim: Performer(s) | Sim: quem alimente a fila | Não |
| Em paralelo | Um robô só | Um costuma bastar | Vários na mesma fila | Uma automação só |
| Gatilho típico | Por horário | Por horário | Por fila (ou por horário) | Por horário (uma execução faz as duas fases) |
A ordem importa. Primeiro a fila (se o modelo usar uma), depois o projeto, depois o trabalho. Tudo aponta para o mesmo nome de fila.
pedidos-entrada, não fila1. A Automação simples pula este passo. Mais em Criar uma fila.
Config.xlsx. O agente usa o modelo que você escolher, pela sua chave de API (veja o quadro abaixo). Mais em Agente (chat de IA).
Cada execução de teste pelo “▶ Executar” aparece na aba “Execuções”, com a origem “Manual”. Quando o gatilho der a partida, a origem passa a ser “Gatilho”.
Na aba “Filas”, cada fila mostra “Itens”, “Pendentes”, “Sucessos”, “Falhas”, “Abandonados” e o “Intervalo médio”. Com esses números e a aba “Execuções”, cinco perguntas bastam para saber se a operação está saudável:
Se os pendentes crescem e os PCs estão livres, rode mais Performers. Se as falhas se repetem com o mesmo texto, pare o lote e corrija a origem: não peça uma nova tentativa em massa no escuro. Com o Curador ligado, confira também “O que ele já fez”, na janela dele, e os e-mails que ele manda quando assume.