Monitor: investigar tentativas e conferir saídas

Objetivo e modelo

Monitor acompanha tentativas de execução e seus resultados. Sua unidade principal é a execução, não a definição salva de um Workflow. Duas tentativas podem usar entradas, parâmetros e dependências publicadas diferentes; compare identificadores e contexto registrado.

Sucesso é o resultado informado pelo motor. A aceitação funcional também exige conferir contagem, esquema, valores e o arquivo ou tabela corretos. Uma falha na entrega da notificação não é automaticamente uma falha de transformação.

Acesso e visualizações

Você precisa de permissão para consultar execuções do tenant ativo. Executar, cancelar, terminar, recuperar e administrar histórico podem exigir autorizações adicionais. Confira cada ação em vez de ampliar o papel de leitura para resolver um problema de visualização.

List, Gantt e Notifications separam registros operacionais, relações temporais e entregas de notificações. List e Gantt compartilham os filtros superiores. History pode expressar uma janela em minutes, hours ou days: confira a unidade antes de interpretar uma lista vazia.

Notifications tem tabela e paginação próprias; uma entrega não representa outra execução do Workflow. Em telas pequenas, tabelas largas podem exigir rolagem horizontal interna.

Investigar uma tentativa

1. Filtre por objeto, estado e horário aproximado. Confirme identificador e data da tentativa.
2. Abra os detalhes ou Operational log quando disponível.
3. Examine dependências e localize a primeira tarefa com erro relevante. Relacione-a ao Mapping, à Session e ao worker efetivos.
4. Revise entradas e parâmetros registrados para a tentativa. Não deduza esses valores apenas do rascunho aberto hoje.
5. Para trabalhos em espera, examine workers elegíveis, slots e predecessores antes de solicitar outra cópia.
6. Confira o destino antes de cancelar, terminar, recuperar ou repetir. Atualize o estado e leia a confirmação específica.
7. Guarde identificador, horário, tarefa e mensagem sem dados sensíveis para suporte; exclua segredos e registros de clientes.

Download e estado incerto

Uma tentativa de Mapping concluída com sucesso e saída armazenada pode oferecer Download output, conforme o acesso. Baixe o artefato daquela tentativa. Uma escrita em banco ou API não produz necessariamente um arquivo para download. Compare o arquivo retornado, não outro arquivo antigo de mesmo nome.

Um timeout do cliente não comprova cancelamento. Consulte a mesma tentativa antes de repetir. Se o estado mudar enquanto uma confirmação estiver aberta, atualize a evidência antes de agir. A janela de History é um filtro, não uma política de retenção.

Exemplo: falha controlada e tentativa corrigida

Use um Workflow sintético pequeno com saída exclusiva. Primeiro configure um caminho de origem inexistente na Session de teste. Espere uma falha final com erro identificável de arquivo ausente e nenhuma saída válida dessa tentativa.

Restaure o vínculo correto, execute uma nova tentativa autorizada e compare os identificadores. Espere sucesso final e saída com cabeçalho, linhas, valores e ordem conhecidos. Separe os arquivos para que uma saída residual não pareça ser o resultado corrigido.

Para recuperação por checkpoint, confirme primeiro estado persistido utilizável e compatível, além do comportamento do destino. Escolher recuperar não desfaz uma escrita externa parcial. Repetir uma carga append pode duplicar registros.

Diagnóstico e manutenção

Uma tentativa pendente pode aguardar capacidade, worker elegível ou dependências. Consulte Configuration e Workers; diferencie agente Offline, VM desligada e provedor Unavailable. Não gere execuções duplicadas porque uma atualização da tabela demorou.

A limpeza do histórico é uma manutenção separada, com alcance e confirmação próprios. Não cancela trabalhos ativos nem substitui uma política de retenção. Confira bloqueios, preserve evidências da ocorrência e não exclua registros para ocultar uma falha ainda não investigada.

Próximas leituras

Overview resume a atividade; Monitor fornece evidências por tentativa. Correções persistentes pertencem a Mappings, Sessions ou Workflows e seguem seu ciclo de publicação. Para problemas não resolvidos, use o suporte da Cloudata com evidências sem dados sensíveis.