Voltar para o blog
Dados & BI5 min de leitura

SLA no Fluig: como medir fila e execução por SQL

Como medir SLA no Fluig por atividade, separando tempo de fila e de execução com as tabelas de movimentação, e o que tratar para o número ser confiável.

Saber que um processo do Fluig demora não ajuda muito. A pergunta útil é: em qual atividade ele para, e se está parado porque alguém está trabalhando ou porque ninguém assumiu. A resposta está nas tabelas de movimentação do próprio Fluig.

Este guia mostra o método que usamos para montar um painel de gargalo. Se o conceito é novo para você, comece por gargalo de processo.

As tabelas que importam

Para medir tempo, você não precisa das tabelas de formulário, que costumam ser as mais pesadas. Bastam quatro tabelas de movimentação:

  • PROCES_WORKFLOW: uma linha por solicitação, com processo, versão e data de início.
  • HISTOR_PROCES: os movimentos e a atividade de cada um.
  • TAR_PROCES: as tarefas, com responsável e datas de atribuição.
  • ESTADO_PROCES: a definição das atividades, com nome, tipo e prazo.

Por não tocar nas tabelas de formulário, esse tipo de consulta tende a ser leve o bastante para rodar sem cache.

Como separar fila de execução

A chave é a coluna de responsável da TAR_PROCES:

  • Se a tarefa está com um pool, com matrícula começando por Pool:, ela está na fila: aguarda alguém assumir.
  • Se está com System:Auto, também conta como espera do sistema.
  • Se está com a matrícula de uma pessoa, conta como execução.

A duração vem de ASSIGN_START_DATE e ASSIGN_END_DATE. Em tarefas ainda abertas, use a data atual como fim.

Vale uma ressalva: "execução" significa que a tarefa estava com a pessoa, não que ela estava trabalhando nisso o tempo todo. Quando a tarefa vai direto para alguém, sem pool, a espera aparece como execução. Para o gestor, isso também é informação: mostra que vale olhar a fila de cada pessoa.

A consulta

O exemplo abaixo é para SQL Server. Ele agrega o tempo por atividade em um período:

WITH TEMPOS AS (
    SELECT
        pw.NUM_PROCES,
        ep.NOM_ESTADO AS ATIVIDADE,
        MAX(ep.NUM_HRS_PRAZ) AS PRAZO_SEG,
        SUM(CASE WHEN t.CD_MATRICULA LIKE 'Pool:%' OR t.CD_MATRICULA = 'System:Auto'
                 THEN DATEDIFF(SECOND, t.ASSIGN_START_DATE, ISNULL(t.ASSIGN_END_DATE, GETDATE()))
                 ELSE 0 END) AS SEG_FILA,
        SUM(CASE WHEN t.CD_MATRICULA LIKE 'Pool:%' OR t.CD_MATRICULA = 'System:Auto'
                 THEN 0
                 ELSE DATEDIFF(SECOND, t.ASSIGN_START_DATE, ISNULL(t.ASSIGN_END_DATE, GETDATE()))
                 END) AS SEG_EXEC
    FROM PROCES_WORKFLOW pw WITH (NOLOCK)
    JOIN HISTOR_PROCES h WITH (NOLOCK)
      ON h.NUM_PROCES = pw.NUM_PROCES
    JOIN ESTADO_PROCES ep WITH (NOLOCK)
      ON ep.COD_DEF_PROCES = pw.COD_DEF_PROCES
     AND ep.NUM_VERS = pw.NUM_VERS
     AND ep.NUM_SEQ = h.NUM_SEQ_ESTADO
     AND ep.COD_EMPRESA = pw.COD_EMPRESA
    JOIN TAR_PROCES t WITH (NOLOCK)
      ON t.COD_EMPRESA = pw.COD_EMPRESA
     AND t.NUM_PROCES = h.NUM_PROCES
     AND t.NUM_SEQ_MOVTO = h.NUM_SEQ_MOVTO
    WHERE pw.COD_DEF_PROCES = 'SEU_PROCESSO'
      AND pw.START_DATE >= '2026-01-01'
      AND pw.START_DATE <  '2026-07-01'
      AND t.ASSIGN_START_DATE IS NOT NULL
      AND ep.IDI_TIP_ESTADO NOT IN (3, 4, 6)
    GROUP BY pw.NUM_PROCES, ep.NOM_ESTADO
)
SELECT
    ATIVIDADE,
    COUNT(*) AS SOLICITACOES,
    AVG(SEG_FILA) / 3600.0 AS MEDIA_FILA_H,
    AVG(SEG_EXEC) / 3600.0 AS MEDIA_EXEC_H,
    MAX(PRAZO_SEG) / 3600.0 AS PRAZO_H
FROM TEMPOS
GROUP BY ATIVIDADE
ORDER BY MEDIA_FILA_H DESC;

Use como ponto de partida e valide no seu ambiente. O esquema pode variar entre versões, e cada banco tem sua sintaxe. Em MySQL, por exemplo, não existem WITH (NOLOCK) nem ISNULL desse jeito, e DATEDIFF(SECOND, ...) vira TIMESTAMPDIFF.

Os detalhes que mudam o resultado

Retrabalho se soma por solicitação. Quando uma atividade aparece várias vezes, como depois de uma devolução, some tudo dentro da solicitação e só depois tire a média entre solicitações. É o que o GROUP BY interno faz. O número de vezes que uma atividade se repete é, em si, um bom indicador.

Gateways e fins não são trabalho. Na base que analisamos, os tipos 3, 4 e 6 em IDI_TIP_ESTADO correspondiam a aprovação, junção e fim. Confira os códigos da sua base antes de excluir.

O prazo está em segundos. Apesar do nome, NUM_HRS_PRAZ estava em segundos no ambiente que medimos. Divida por 3600.

Prazo zero não é estouro. Atividades sem prazo configurado têm valor 0. Mostre "sem prazo definido", em vez de comparar com zero.

Atividades paralelas não se somam. Em um fluxo com fork e join, duas atividades correm ao mesmo tempo. Mostre as duas, mas não some para calcular o total do processo.

O máximo engana. Solicitações esquecidas geram máximos de meses. Use mediana e percentil 90 como referência e trate o máximo como alerta. Em SQL Server, PERCENTILE_CONT ajuda.

Exclua testes. Solicitações de teste distorcem processos com pouco volume.

Do SQL ao painel

Um formato simples funciona bem:

  1. Um dataset customizado com JDBC recebe processo e período como filtros e executa a consulta.
  2. Uma widget mostra os indicadores, com gráfico de fila e execução por atividade e tabela com os estouros.

Dois cuidados de segurança: o dataset deve aceitar apenas parâmetros tratados, nunca uma SQL vinda da tela, e use uma conexão somente leitura. Veja SQL injection em dataset do Fluig.

Atenção também ao formato em que a widget envia as constraints: em um painel desse tipo, o dataset lia só um formato e sempre devolvia todos os dados. O detalhe está no guia de dataset.

O que fazer com o número

Quando o painel fica pronto, a conversa muda. Em um dos processos que analisamos, a medição antiga olhava só a execução, e o atraso estava nas passagens entre etapas. O gestor passou a atacar o gargalo certo, não a produtividade das pessoas.

Antes de mudar qualquer coisa, valide alguns casos com quem conhece o processo. E apresente fila e execução juntas, porque nenhuma das duas sozinha conta a história toda. Para escolher o que exibir, leia dashboards que gestores realmente usam.

Perguntas frequentes

Em qual tabela do Fluig ficam os tempos das tarefas?

Na TAR_PROCES, nas colunas ASSIGN_START_DATE e ASSIGN_END_DATE.

Posso consultar o banco do Fluig diretamente?

Para leitura, sim, se a sua política permitir e sem impactar o ambiente. Não grave nas tabelas nativas por SQL. Elas não são uma API, e a estrutura pode mudar em atualizações.

Como saber o tempo em fila de uma atividade?

Some a duração das tarefas que estavam com um pool ou com System:Auto, relacionando TAR_PROCES e HISTOR_PROCES pelo número do movimento.

Se você quer esse painel sem construí-lo do zero, a MyQube faz dashboards conectados ao Fluig e ao Protheus. Vamos conversar.

Sua operação ainda depende de planilhas e retrabalho?

Agende uma conversa gratuita e receba um diagnóstico inicial dos seus gargalos operacionais.

Falar com a MyQube

Ou conheça nosso serviço de Dashboards Fluig e Protheus