Auditoria técnica e funcional • 10 ago 2026

Análise integral do MES e da integração Sankhya

Como o sistema funciona hoje, onde estão as regras que controlam a produção, quais partes são reais ou simuladas e em que ordem corrigir os erros pendentes sem comprometer a operação.

Projeto 51710 MES Manipulação Sankhya como fonte operacional Documento HTML autônomo

01 • Visão de decisão

Resumo executivo

O sistema é um MES híbrido em transição: uma camada real consulta e altera atividades no Sankhya, enquanto grande parte da experiência operacional continua sendo um protótipo em memória. Essa mistura é hoje a principal fonte de risco e de dificuldade para corrigir erros.

10tabelas locais confirmadas no inventário atual

65Server Functions ativas no contexto consultado

6SFs centrais efetivamente chamadas no fluxo atual

3.474entradas no manifesto histórico de migrations

Diagnóstico central O frontend declara modoTeste = true, mas ainda executa operações reais de início, finalização e registro no Sankhya. Portanto, o rótulo “teste” não representa isolamento técnico. Hoje é possível misturar OP real, etapa real e sessão real com reatores, timers, CQ, supervisor, QR e dossiê simulados.

Ação imediata

Segurança e integridade

Rotacionar credenciais materializadas no histórico, impedir identidade forjada, mover o bloqueio de tempo para o backend e revisar a exposição pública de login e OPs.

Ação estrutural

Separar protótipo e produção

Definir uma única fonte de verdade por domínio, desativar fallback fictício em operação real e tornar explícito o que ainda é homologação.

Ação operacional

Controlar concorrência

Adicionar expiração de locks, idempotência, correlação de execução, proteção contra jobs sobrepostos e recuperação de estados parciais.

Ação de governança

Observabilidade e testes

Criar logs por etapa, tela de integração, última atualização real, reconciliação Sankhya × Mitra e testes automatizados das condicionais críticas.

02 • Confiabilidade

Escopo, método e limites

A análise cruza quatro fontes: código do backend, código do frontend, histórico de migrations e inventário operacional retornado pela plataforma. O guia oficial de integração de dados foi usado como checklist de conformidade.

Confirmado

Comportamento diretamente visível no código, no manifesto ou no inventário operacional.

Inferido

Consequência técnica provável, dependente de carga, configuração externa ou estado do Sankhya.

Não validado

Resultado que exige teste controlado no ERP, revisão com Produção/CQ ou acesso operacional específico.

O que foi auditado

Scripts de setup, adição, correção e sincronização no backend.
Server Functions de login, listagem de OPs, fluxo, início, finalização e problemas.
Jornadas de Operador, Auditoria/Supervisor, Qualidade e Cadastros.
Tabelas locais, integrações, jobs, crons, locks, formulários e fluxo de CQ.
Histórico funcional e migrations mais recentes, sem editar migrations aplicadas.
Documentos de escopo, UX, design e tarefas anteriores.

Limite desta entrega Este documento é uma auditoria e um plano. Nenhuma regra de produção, Server Function, tabela ou integração foi alterada. Pelo protocolo obrigatório, correções de integração só devem ser implementadas depois do alinhamento e da aprovação explícita do contrato revisado.

Escopo de banco: “toda a base Sankhya” neste relatório significa o conjunto de tabelas, serviços e relações efetivamente usados pelo projeto. Um catálogo completo de todo o banco Sankhya exigiria acesso ao dicionário integral do ERP e não foi inferido sem evidência.

03 • Estado atual

Arquitetura que existe hoje

Tablet / BrowserReact, sessão local e modo de teste

SDK MitraExecução de SF pública ou autenticada

Server FunctionsSQL, Integration e JavaScript

Integration GatewayConexão sankhya-drexell

SankhyaOP, atividade, processo, formulário e CQ

Quatro camadas reais

1. Interface MES

Uma única página React muito extensa concentra fila, execução, auditoria, supervisor, qualidade, cadastros, mocks, estados e chamadas remotas.

2. Orquestração Mitra

SFs executam consultas SQL locais, chamadas via Integration e lógica JavaScript para encadear operações Sankhya.

3. Persistência local

Espelhos parciais do Sankhya, locks e problemas de OP. O inventário atual não contém todas as tabelas do protótipo descritas no setup original.

4. ERP Sankhya

Fonte oficial para OPs, atividades, processos, formulários, executante e ciclo/amostra de CQ. Também recebe escritas operacionais.

Três modelos coexistentes

Modelo	Exemplo	Estado	Problema
Online em tempo real	SFs 95, 97, 98, 99 e login 113	Ativo	Dependência direta do ERP e baixa tolerância a falhas parciais.
Espelho local periódico	TPRCWC e atividades de OP	Parcial	Jobs sem cursor robusto, mutex ou observabilidade completa.
Protótipo local	Reator, QR, timers, CQ/LIMS, supervisor e dossiê	Misturado	Dados simulados convivem com ações reais na mesma experiência.

04 • Cérebro de informação

Dados, tabelas e integrações

O Sankhya representa a fonte operacional dominante. O banco local Mitra funciona como apoio, cache parcial e controle de concorrência, mas ainda não constitui uma réplica completa nem um modelo transacional integral do MES.

Tabelas locais confirmadas no inventário

Grupo	Tabelas	Finalidade	Observação
Sistema	`INT_USER`	Usuários nativos da plataforma	Não deve ser substituída por tabela customizada.
Concorrência	`OP_ETAPA_EXECUCAO_LOCK`	Reserva de atividade por usuário	Sem TTL ou expiração automática.
Desvios	`PROBLEMAS_OP`	Registro de problemas operacionais	Identidade enviada pelo cliente.
Produtos	`PRODUTOS_SANKHYA`	Espelho parcial da TGFPRO	Estratégia de ausentes/deletados não está consolidada.
Processo	`TPRIPROC_SANKHYA`, `TPRIATV_SANKHYA`, `TPREFX_SANKHYA`, `TPRPRC_SANKHYA`	Instância, atividade, elemento e processo	Espelhos locais coexistem com consultas online.
Formulários	`TPRFRME_SANKHYA`, `TPRFORM_SANKHYA`	Vínculos e definição de formulários	Histórico registra cargas incompletas por timeout.

Principais tabelas Sankhya consultadas

Ordem e processo

TPRIPROC, TPRIPA, TPRPRC, TGFPRO

Atividade e fluxo

TPRIATV, TPREFX, TPRATV, TPRWCP, TPRCWC

Formulários

Tabelas de formulário/campos resolvidas dinamicamente por NOMETAB e NOMECAMPO.

Qualidade

TPRICCQ, TPRACCQ, TGFRAM e serviços de Controle de Qualidade.

Usuário

TSIUSU para resolver o código do executante.

Serviços

DbExplorerSP, OperacaoProducaoSP, CRUDServiceProvider e ControleQualidadeSP.

Server Functions que sustentam a jornada real

ID	Nome	Tipo	Papel	Exposição
95	`listarOpsAceitasSankhya`	JavaScript	Fila de OPs elegíveis	Pública
97	`listarFluxoProcessoOpSankhya`	Integration	Etapa aberta e campos de formulário	Autenticada
98	`iniciarFluxoEtapaOpSankhya`	JavaScript	Aceitar, atribuir e iniciar atividade	Autenticada
99	`finalizarFluxoEtapaOpSankhya`	JavaScript	Formulário, CQ e finalização	Autenticada
112	`registrarProblemaOp`	JavaScript	Registrar desvio local	Autenticada
113	`validarLoginSankhya`	JavaScript	Autenticar no ERP e devolver sessão	Pública
100/101	Jobs de atividades e TPRCWC	JavaScript	Sincronizações a cada 5 minutos	Cron
103	`listarOrdensProducaoInicializadasApiMes`	Integration	Consulta à API MES Tractworld	Integração paralela

Ausências relevantes no inventário atual Não foram identificados JDBC externo, Data Loaders ou Tabelas Online. O acesso principal ao Sankhya ocorre pelo gateway de integração. Isso favorece tempo real, mas aumenta a dependência da API, do limite do DbExplorer e da disponibilidade do ERP.

05 • Operação

Fluxos ponta a ponta

Fluxo de login atual

CredenciaisUsuário e senha Sankhya no browser

SF 113 públicaValida no ERP

SessãoRetorna sessionId

LocalStorageSalva usuário, sessão e horário

MESLibera rota principal

Ponto frágil: a sessão não tem expiração local efetiva e a autenticação Sankhya não cria, por si só, uma sessão Mitra consistente após recarregar a página.

Fluxo da fila de OPs

Carregar telaInicializa OPs fictícias

SF 95Consulta até 50 OPs no Sankhya

SucessoSubstitui mocks por OPs reais

Falha/vazioMantém fallback fictício

OperadorSeleciona card ou QR

Ponto frágil: erro de integração pode parecer operação normal porque a tela continua com dados simulados.

Fluxo de início da atividade

Frontend carrega a etapa aberta pela SF 97.
Envia IDIATV, identificadores da OP, usuário e sessão Sankhya à SF 98.
Backend resolve CODUSU em TSIUSU.
Verifica o executante atual na TPRIATV.
Adquire lock local por atividade.
Aceita a atividade no Sankhya.
Grava executante e inicia a atividade.
Atualiza novamente o executante.

Falha parcial possívelSe o aceite funcionar e o início falhar, o lock local pode ser removido, mas a atividade já pode ter sido assumida no Sankhya.

Fluxo de finalização

Frontend valida respostas obrigatórias.
SF 99 verifica usuário e lock.
Se houver formulário, monta inserção dinâmica pela tabela/campos retornados.
Se a descrição contiver “AMOSTRA CQ”, inicia o fluxo de CQ.
Localiza ou cria amostra, vincula ao ciclo e aprova automaticamente.
Finaliza a atividade no Sankhya.
Grava o executante final e encerra o lock.
Frontend recarrega o fluxo e escolhe a próxima atividade aberta.

Não há transação distribuídaFormulário, CQ, amostra, finalização e lock podem terminar em estados diferentes. Retries não possuem uma chave de idempotência ponta a ponta.

Fluxo de sincronização periódica

TPRCWC

Full scan paginado a cada cinco minutos, upsert local e marcação de ausentes por lote. Tem melhor tratamento de deletados, mas não possui mutex para impedir sobreposição.

Atividades de OP

Reconsulta o histórico das OPs já conhecidas a cada cinco minutos. O loop ocorre dentro de uma única SF JavaScript e não usa cursor incremental persistido.

06 • Regras do cérebro

Mapa das principais condicionais

As condicionais estão espalhadas entre SQL Sankhya, SFs JavaScript e estado React. Essa distribuição explica por que algumas correções funcionam em uma tela e podem ser contornadas por outra.

Regra	Onde decide	Condição atual	Risco	Correção recomendada
OP entra na fila	SF 95 / SQL Sankhya	Processo ativo, instanciado, etapa aberta, exclusões e heurística de CQ	Limite de 50 e regra de reprovação heurística	Paginar e formalizar estados de negócio por códigos.
Separação Química	SF 95	Exclusão por texto da descrição	Renomeação ou acento quebra a regra	Usar ID/tipo estável.
Etapa atual	Frontend + SF 97	Primeira atividade aberta retornada	Atividades finalizadas somem e progresso fica incoerente	Retornar histórico e status ou calcular progresso no backend.
Quem pode iniciar	SF 98 + lock	Executante atual e lock por `IDIATV`	Usuário vem do cliente e lock não expira	Derivar identidade da sessão e adicionar lease/TTL.
Tempo mínimo	Frontend	Relógio do browser compara início e tempo da atividade	Bypass pela Auditoria ou chamada direta	Validar na SF 99 usando horário do servidor/Sankhya.
Formulário obrigatório	Frontend + SF 99 + Sankhya	Todos os campos retornados devem ter valor	Campos de tabelas distintas podem ser agrupados incorretamente	Agrupar por `NOMETAB` e validar schema permitido.
AMOSTRA CQ	Frontend e SF 99	Descrição contém texto específico	Aciona aprovação automática e encerra fluxo	Usar configuração estrutural e decisão formal da Qualidade.
Supervisor	Frontend	Clique simples ou texto literal `SUPERVISOR`	Sem autenticação ou segregação de função	Perfis reais e autorização server-side.
Qualidade	Frontend mock / SF CQ	Tela acessível a qualquer autenticado; parte local	Aprovação sem segregação e comportamento ambíguo	Perfil CQ, trilha de auditoria e contrato CQ/LIMS.
Fallback de integração	Frontend	Falha mantém dados mock	Operação fictícia pode parecer real	Fail closed em produção e ambiente de homologação separado.
Registro de problema	SF 112	Identidade e campos enviados pelo browser	Rastreabilidade fraca e possível 403 em business	SF SQL, usuário derivado do contexto e evidência persistida.

Princípio de correção Toda regra que protege integridade, segurança, tempo, sequência, identidade ou qualidade deve existir no backend. O frontend pode antecipar a validação para melhorar a UX, mas não pode ser a única barreira.

07 • Gap de implementação

Planejado versus realizado

Capacidade prevista	Documentação	Implementação observada	Gap
Integração em tempo real	Sankhya como fonte oficial	OP, atividade, formulário e CQ parcialmente reais	Parcial Há mistura com mock.
Perfis Operador/Supervisor/CQ/PCP	Segregação por responsabilidade	Navegação acessível sem guard de perfil	Ausente
Compatibilidade de reator	Bloqueio sistêmico	Predominantemente mock/local	Não produtivo
Bipagem e lote	Validar lote real e CQ no Sankhya	Catálogo QR hardcoded e logs voláteis	Protótipo
Tempo mínimo	Impedir conclusão antecipada	Bloqueio no frontend, contornável	Inseguro
CQ/LIMS	Gate entre Produção e Qualidade	Cenários locais + aprovação automática em caso específico	Ambíguo
Dossiê digital	PDF auditável e não editável	Estado React, perdido no reload	Ausente
Observabilidade	Dashboard de falhas e retry	Logs parciais de dois jobs	Insuficiente
Offline	Ponto em aberto	Sem estratégia robusta	Decisão pendente
Agente de negócio	Avaliar para Supervisor/CQ/PCP	Não configurado	Fase futura

Documentos históricos desatualizados Há trechos afirmando que nada grava no Sankhya, mas o código atual executa início e finalização reais. Antes de continuar o desenvolvimento, a documentação funcional deve ser atualizada para refletir a realidade operacional.

Correção: revisar necessidade pública, limitar tentativas, auditar acessos e reduzir dados retornados.

Alto

R-11

Perfis operacionais inexistentes na interface

Qualquer autenticado pode acessar Supervisor, Qualidade, Auditoria e Cadastros.

Correção: perfis reais, guards de rota e autorização repetida no backend.

Médio

R-12

Observabilidade incompleta

Não há tela central, tempos por etapa, correlação ou última atualização real.

Correção: LOG_IMPORTACOES, monitoramento, alertas e reconciliação por entidade.

09 • Backlog técnico

Erros pendentes identificados

Prioridade	Erro ou fragilidade	Efeito observado/provável	Validação necessária
P0	Regex numérica materializada como `/^\d+$/`	Usuário numérico não segue o caminho esperado	Teste unitário da resolução de usuário.
P0	Bypass do cronômetro na Auditoria	Finalização antes do tempo mínimo	Teste direto na SF e pelas duas telas.
P0	Fallback mock após falha do Sankhya	Operador pode atuar sobre dados fictícios	Simular indisponibilidade da integração.
P0	Token/segredo no histórico	Credencial comprometida por persistência	Rotação e varredura de todos os artefatos.
P1	Consulta de fluxo retorna apenas atividades abertas	Progresso tende a 0% enquanto há etapa e 100% no fim	OP real com múltiplas etapas concluídas.
P1	Limite fixo TOP 50	OPs elegíveis podem desaparecer da fila	Base com mais de 50 OPs.
P1	Lock sem expiração	Atividade pode ficar bloqueada indefinidamente	Fechar browser após iniciar e tentar retomar.
P1	Respostas fora de ordem no frontend	Fluxo de OP A pode sobrescrever OP B	Troca rápida de OP com rede lenta.
P1	Formulário usa a primeira `NOMETAB`	Campos de tabelas diferentes podem ser inseridos juntos	Etapa com múltiplos grupos/tabelas.
P1	`MAX + 1` para IDs	Colisão em finalizações concorrentes	Teste simultâneo controlado.
P1	Jobs sem cursor incremental	Carga crescente e timeout	Medição por volume e plano de execução.
P2	Script `fix-ops-aceitas-public.mjs` obsoleto	Reexecutar pode remover correções atuais	Bloquear/arquivar script sem executá-lo.
P2	Correção de login fora do manifesto	Rebuild por migrations pode regredir	Comparar SF ativa com baseline reproduzível.
P2	172 SQLs fora do manifesto	Histórico concorrente difícil de reproduzir	Inventário de aplicação por ambiente.
P2	Metadados e idioma do frontend incorretos	Título/favicon/lang de template	Inspeção do build final.
P2	Sem suíte automatizada	Regressões nas regras críticas	Adicionar testes de unidade, contrato e E2E.
P2	Árvore npm com 9 vulnerabilidades altas	Risco em dependências transitivas do frontend	Executar `npm audit`, avaliar impacto e atualizar com teste de regressão; não usar correção automática sem revisão.
P2	Projeto marcado como Sankhya mantém login customizado	Fluxo pode conflitar com o auto-login esperado da plataforma	Confirmar arquitetura de autenticação oficial antes de remover ou manter a tela.

10 • Sequenciamento seguro

Plano de correção por etapas

A ordem abaixo reduz primeiro o risco de segurança e corrupção, depois estabiliza o motor, e somente então completa funcionalidades.

Etapa 0 — Congelamento controlado e backup lógico

Mapear SFs ativas, exportar códigos, registrar IDs, crons e integrações; impedir execução acidental de scripts obsoletos. Nenhuma operação destrutiva.

Etapa 1 — Segurança urgente

Rotacionar segredo exposto, remover token materializado, revisar SFs públicas, aplicar rate limit/auditoria e eliminar sessão em URL quando tecnicamente possível.

Etapa 2 — Regras invioláveis no backend

Tempo mínimo, identidade, sequência, permissão, validação de IDs e decisão de CQ passam a ser garantidos server-side.

Etapa 3 — Idempotência e concorrência

Lease de lock, chave de idempotência, estado por operação, saga/compensação, retry seguro e prevenção de cliques/chamadas duplicadas.

Etapa 4 — Separar produção de homologação

Remover fallback mock em produção, deixar mocks em modo isolado e rotulado, e definir fonte oficial de cada dado.

Etapa 5 — Pipeline Sankhya robusto

Cursor incremental, estratégia de deletados, batching, mutex de job, checagem de burstLimit, paginação estável e reconciliação.

Etapa 6 — Observabilidade

Logs por entidade e etapa, monitor de integração, última atualização real, alertas, execução correlacionada e tela de diagnóstico.

Etapa 7 — Perfis e jornadas

Operador, Supervisor, Qualidade, PCP e Admin com autorização real; simplificação de MesPage em módulos testáveis.

Etapa 8 — Funcionalidades ainda mock

Reator, lote, bipagem, CQ/LIMS, dossiê, apontamento e desvios são integrados um domínio por vez, após contrato aprovado.

Etapa 9 — Homologação e rollout

Testes paralelos com Sankhya, reconciliação, treinamento, plano de rollback e ativação progressiva por grupo.

Ordem sugerida para os primeiros ciclos

Ciclo 1

Conter risco

Credenciais, tempo, identidade, público, locks e scripts regressivos.

Ciclo 2

Estabilizar fluxo

Idempotência, progresso, formulários, erros estruturados e concorrência do frontend.

Ciclo 3

Evoluir produto

Perfis, observabilidade, domínios reais hoje mockados e performance.

11 • Checkpoint obrigatório

Contrato de integração revisado — rascunho

Este contrato consolida o que já foi descoberto e destaca as decisões que precisam ser confirmadas antes de alterar a integração.

Item	Estado proposto	Decisão pendente
Fonte	Sankhya via Integration Gateway	Confirmar versão/configuração e responsáveis técnicos.
Modelo	Misto: online para operação, local para apoio/monitoramento	Definir quais entidades devem ser materializadas.
OP e atividades	Online, com paginação e proteção contra indisponibilidade	Delay máximo aceitável e comportamento offline.
Cadastros e recursos	Cache local incremental	Cursor, frequência e estratégia de ausentes.
CQ/LIMS	Contrato separado, sem aprovação por texto	Quem decide e qual status oficial libera produção.
Deletados	Soft delete por entidade quando aplicável	Política formal para OP, processo, atividade, produto e formulário.
Frequência	Incremental conforme SLA; full refresh em janela segura	SLA e janela de baixo uso.
Atomicidade	Upsert idempotente; shadow para full refresh	Escolha por entidade.
Concorrência	Mutex por job + lease por atividade	Tempo de expiração e regra de retomada.
Monitoramento	Logs por etapa, alertas e última atualização	Destinatários e retenção.
Reconciliação	Contagens, chaves, nulos e somatórios	Tolerância de divergência por domínio.

Perguntas de decisão para o negócio

O modo de produção deve falhar fechado quando o Sankhya estiver indisponível ou haverá operação offline?
A etapa “AMOSTRA CQ” deve realmente aprovar a amostra automaticamente? Quem homologou essa regra?
Qual status/código oficial identifica reprovação e retorno ao operador, sem inferência por descrição?
Qual é o SLA de atualização para OPs, atividades, produtos, recursos e formulários?
Como cada entidade deve tratar exclusões ou inativações na origem?
Qual tempo torna um lock abandonado e quem pode assumir a atividade?
Quais funções são permitidas para Operador, Supervisor, Qualidade, PCP e Admin?
Quais dados do protótipo devem virar produção primeiro: reator, bipagem/lote, CQ, dossiê ou apontamento?
Qual equipe recebe alertas de falha e quem possui autoridade para reprocessar?
A API MES Tractworld continuará coexistindo com o Sankhya? Qual é a fonte de verdade em caso de divergência?

Checkpoint A implementação das correções de integração deve começar somente depois de o responsável confirmar este contrato, incluindo modelo, SLA, deletados, CQ, concorrência, permissões e estratégia de monitoramento.

12 • Qualidade de entrega

Plano de testes e critérios de aceite

Testes de contrato

Formato de cada resposta Sankhya.
Campos obrigatórios e tipos.
Erros e sessões expiradas.
Limite e burstLimit.

Testes de regra

Tempo mínimo no backend.
Usuário da sessão versus executante.
Sequência e formulário obrigatório.
Estados CQ e retorno ao operador.

Testes de concorrência

Dois operadores na mesma atividade.
Duplo clique e retry.
Job sobreposto.
Expiração e retomada de lock.

Testes de resiliência

Gateway indisponível.
Falha depois de aceite/formulário/CQ.
Reload e sessão expirada.
Resposta lenta e fora de ordem.

Critérios mínimos antes de produção

Nenhum segredo presente no bundle, código de SF ou nova migration.
Finalização antecipada bloqueada também em chamada direta ao backend.
Identidade do executante derivada de contexto confiável.
Nenhum dado mock aparece em modo de produção.
Retries de início/fim são idempotentes e auditáveis.
Locks expiram e podem ser recuperados por procedimento autorizado.
Perfis impedem acesso indevido a Supervisor, CQ e Cadastros.
Fila de OPs é paginada e não perde registros acima de 50.
Logs mostram execução, etapa, duração, erro e correlação.
Reconciliação entre Sankhya e Mitra aprovada pelo responsável de negócio.

13 • Rastreabilidade

Evidências principais

Referências usadas para permitir que a equipe localize rapidamente a origem de cada conclusão. Os números de linha correspondem ao snapshot auditado.

Mapa de SFs e modo de testefrontend/src/pages/MesPage.tsx:11-83frontend/src/pages/MesPage.tsx:941-944

Chamadas reais Sankhyafrontend/src/pages/MesPage.tsx:753-805frontend/src/pages/MesPage.tsx:2714-2798

Bypass de tempofrontend/src/pages/MesPage.tsx:3882-3921frontend/src/pages/MesPage.tsx:4760-4763

Login e sessãofrontend/src/pages/LoginPage.tsx:20-50frontend/src/lib/mitra-auth.ts:44-65

Fluxo backend Sankhyabackend/add-sankhya-fluxo-op.mjs:132-190backend/add-sankhya-fluxo-op.mjs:697-742

Lock e concorrênciabackend/add-sankhya-fluxo-op.mjs:788-897backend/add-sankhya-fluxo-op.mjs:1007-1020

Consulta da filabackend/add-sankhya-ops-aceitas.mjs:25-165

Jobs de sincronizaçãobackend/add-sankhya-atividades-op-job.mjs:136-233backend/add-sankhya-tprcwc-job.mjs:159-199

Escopo originalfeaturesearquitetura.md:62-72featuresearquitetura.md:130-145

Últimas migrations funcionaisbackend/migrations/3469-update-sf-listaropsaceitassankhya.sqlbackend/migrations/3473-update-sf-iniciarfluxoetapaopsankhya.sqlbackend/migrations/3474-update-sf-finalizarfluxoetapaopsankhya.sql

Tratamento de segredos A auditoria identificou material sensível em artefatos históricos, mas nenhum valor é reproduzido neste relatório. A equipe deve tratar o segredo como comprometido e executar rotação controlada.

14 • Leitura comum

Glossário rápido

Termo	Significado neste sistema
MES	Sistema de execução da manufatura que guia e registra a produção.
OP	Ordem de Produção originada no Sankhya.
SF	Server Function executada pela plataforma Mitra.
Integration	Conexão segura usada pelas SFs para chamar o Sankhya ou outra API.
DbExplorer	Serviço Sankhya usado para consultas SQL via API.
Cursor	Marca que permite buscar apenas registros novos ou alterados.
Upsert	Inserção que atualiza um registro quando sua chave já existe.
Idempotência	Capacidade de repetir uma operação sem duplicar efeitos.
Lock/lease	Reserva temporária que impede dois usuários de executar a mesma atividade.
Saga	Controle de uma operação em várias etapas, com estado e compensações.
Shadow table	Tabela paralela usada para preparar uma carga completa antes da troca atômica.
Fail closed	Quando a integração falha, o sistema bloqueia a operação em vez de assumir dados fictícios.