# Fluxo de Dados Suricato REP ## Visão Geral O **Fluxo de Dados do Suricato REP** descreve como o sistema controla, organiza e sincroniza as informações de **empregados, crachás e grupos de REP** entre o banco de dados do **Suricato-REP** e o **ConexREP**. Esse fluxo garante que: * Empregados sejam corretamente **incluídos**, **atualizados** ou **excluídos** nos equipamentos REP; * As informações de crachá, grupo, nome e PIS estejam sempre sincronizadas; * O sistema mantenha rastreabilidade por meio de **logs** e **tabelas de controle**. Ao longo deste documento, são apresentados: * As **tabelas e views envolvidas**; * As **regras de negócio** que determinam inclusão e exclusão; * O **fluxo principal de processamento**; * Os **fluxos específicos de inclusão e exclusão**. ## Regra de Negócio Para que o fluxo de dados do Suricato REP funcione corretamente, as seguintes regras devem ser atendidas: * A **view SURICATO.VHISTORICOCRACHAREP** sempre retorna uma lista **FULL** de empregados. * A validação de inclusão e exclusão depende do cruzamento entre: * `SURICATO.VHISTORICOCRACHAREP` * `SURICATO.TBGRUPOREPEMPREGADO` * A view possui regras internas para retorno considerando: * Número Lógico e Número Físico do crachá; * Crachá Titular e Crachá Provisório. * O processo de **exclusão** é sempre executado **antes** do processo de inclusão. * Registros em processamento não devem ser reprocessados. * Triggers são disparadas automaticamente conforme operações de inclusão, alteração ou exclusão. * Logs são mantidos em banco e em arquivo texto, respeitando o período configurado. * Alterações diretas na base do ConexREP podem gerar listas adicionais de exclusão. ## Tabelas e Views A seguir são descritas as tabelas e views relacionadas ao software **Suricato-REP**. ### SURICATO.VHISTORICOCRACHAREP View do SURICATO que retorna os dados de todos os empregados com seus respectivos grupos de REP. A lista de retorno é sempre **FULL** e deve ser cruzada com a tabela `SURICATO.TBGRUPOREPEMPREGADO`. **IMPORTANTE – Regra de negócio da view:** * Número Lógico e Número Físico; * Crachá Titular e Crachá Provisório. | Campo | Descrição | Origem dos Dados | | -------- | ----------------------------------- | ------------------------------------------------ | | CRACHA | Número Lógico e/ou Físico do Crachá | TbHistoCrach.ICARD e/ou TbCrachFisic.NumeFisi | | NOME | Nome do Empregado | TbPessoa.NomePess | | GRUPOREP | Grupo de REP do empregado | TbAcessColab.GrupoRepID / TbAcessColab.GrupRepId | | PIS | Número do PIS | TbColab.NumePis | ### SURICATO.TBLOGSERVICE Tabela do SURICATO que mantém o log de execução dos processos. Por padrão, o log mantém os últimos **90 dias**, podendo ser configurado no arquivo `suricato-rep.properties` pelo parâmetro `log.clean.days`. | Campo | Descrição | Origem dos Dados | | --------------------- | -------------------------------------------------- | ---------------------------------------------------- | | ID | Identificador Sequencial | Os dados nesta tabela são mantidos pelo Suricato-REP | | NOME | Identificador do Software Fixo: SURICATO-REP | | | INCLUSAO | Data/Hora da inclusão do registro | | | TIPO |

Classificação da Informação | | |
INFO = Informação | | | |
WARN = Atenção | | | |
ERROR = Erro

| | | | CLASSE |

Nome da Classe JAVA
Uso de desenvolvedor

| | | THREAD |

Nome da Thread JAVA
Uso de desenvolvedor

| | | MENSAGEM | Mensagem de usuário | | | UUID | Identificador único do processo | | ### TELESSVR.REPGRPF Tabela do CONEXREP que retorna os dados de todos os crachás com seus respectivos grupos de REP. | Campo | Descrição | Origem dos Dados | | ----- | ----------------------------------- | ---------------- | | IFUNC | Número Lógico e/ou Físico do Crachá | Suricato-REP | | GRUPO | Grupo de REP | Suricato-REP | Triggers disparadas: * `TRGREPGRP_I` * `TRGREPGRP_U` * `TRGREPGRP_D` ### TELESSVR.REPEMPR002 Tabela do CONEXREP que retorna os dados dos empregados. | Campo | Descrição | Origem dos Dados | | ----- | ----------------------------------- | ---------------- | | IFUNC | Número Lógico e/ou Físico do Crachá | Suricato-REP | | PIS | Número do PIS | Suricato-REP | | NOME | Nome do Empregado | Suricato-REP | Triggers: * `TRGREPFUN_I` * `TRGREPFUN_U` * `TRGREPFUN_D` ### SURICATO.TBGRUPOREPEMPREGADO Tabela de controle do SURICATO que mantém o relacionamento entre empregados e grupos de REP já processados. | Campo | Descrição | Origem dos Dados | | ---------- | ------------------------- | ---------------- | | CRACHA | Número Lógico e/ou Físico | Suricato-REP | | GRUPOREPID | Código do Grupo de REP | Suricato-REP | | NOME | Nome do Empregado | Suricato-REP | | PIS | Número do PIS | Suricato-REP | ### TELESSVR.REPNAUTO000 Tabela de controle para manter empregados versus grupo de REP. **Status do registro:** * `3` → Registro para Incluir * `8` → Registro para Excluir | Campo | Descrição | | --------- | ----------------------------------- | | IFUNC | Número Lógico e/ou Físico do Crachá | | GRUPO | Código do Grupo de REP | | STATUS | Status do Registro | | DATA\_INS | Data de Inclusão | ### Tabelas de Automação (Inclusão e Exclusão) #### TELESSVR.REPAUTO001 Tabela CONEXREP de controle do processo de **INCLUSÃO do REP**. O campo **STATUS** informa o estado do registro: * `x` → Onononono * `y` → Onononono | Campo | Descrição | | ---------- | -------------------- | | END\_IP | Número TCP/IP do REP | | DATA\_LOAD | Data/Hora da Carga | | STATUS | Status do Registro | #### TELESSVR.REPAUTO011 Tabela CONEXREP de controle do processo de **INCLUSÃO do Crachá versus REP**. O campo **STATUS** informa o estado do registro: * `x` → Onononono * `y` → Onononono | Campo | Descrição | | ------- | ----------------------------------- | | IFUNC | Número Lógico e/ou Físico do Crachá | | END\_IP | Número TCP/IP do REP | | STATUS | Status do Registro | #### TELESSVR.REPAUTO002 Tabela CONEXREP de controle do processo de **EXCLUSÃO do REP**. O campo **STATUS** informa o estado do registro: * `x` → Onononono * `y` → Onononono | Campo | Descrição | | ---------- | -------------------- | | END\_IP | Número TCP/IP do REP | | DATA\_LOAD | Data/Hora da Carga | | STATUS | Status do Registro | #### TELESSVR.REPAUTO012 Tabela CONEXREP de controle do processo de **EXCLUSÃO do Crachá versus REP**. O campo **STATUS** informa o estado do registro: * `x` → Onononono * `y` → Onononono | Campo | Descrição | | ------- | ----------------------------------- | | IFUNC | Número Lógico e/ou Físico do Crachá | | END\_IP | Número TCP/IP do REP | | STATUS | Status do Registro | ### Log do Sistema O log é mantido de duas formas: * **Banco de Dados:** tabela `TbLogService` (padrão: 90 dias); * **Arquivo TXT:** localizado no diretório de log do sistema. ## Fluxo Principal No fluxo principal são criadas as **listas de inclusão e exclusão de empregados**.\ A imagem a seguir demonstra o processo de geração dessas listas.

Lista de Inclusão de Empregado

A **lista de inclusão** é composta por todos os empregados retornados pela view **`vHistoricoCrachaRep`** que **não estejam presentes** na tabela **`TbGrupoRepEmpregado`**. Esses registros representam empregados que ainda **não foram sincronizados** com os grupos de REP no ConexREP.

Lista de Exclusão de Empregado

A **lista de exclusão** é composta por todos os empregados mantidos na tabela **`TbGrupoRepEmpregado`** que **não estejam presentes** na view **`vHistoricoCrachaRep`**. Esses registros representam empregados que **não devem mais permanecer** associados aos grupos de REP.

Lista Adicional de Exclusão de Empregado

Pode ocorrer uma situação em que a carga de dados seja realizada **diretamente na base de dados do ConexReP**, por exemplo, para testes de cenário. Nessa situação, será gerada uma **lista adicional de exclusão**, composta por todos os empregados que: * Estiverem na tabela **`REPGRPF`**; * **Não** estiverem na tabela **`TbGrupoRepEmpregado`**; * **Não** estiverem na view **`vHistoricoCrachaRep`**. ## Fluxo de Exclusão O processo de exclusão é **sempre executado primeiro**. Para fins de desenvolvimento, este fluxo utiliza a thread **`WorkerThreadDelete`**. **Parâmetro**\ Registro do tipo **`TbGrupoRepEmpregado`** **Fluxo** * Verificar se existe o registro na tabela **`REPGRPF`** (Crachá, Grupo). * A pesquisa é realizada considerando formatação de **3 e 5 dígitos**. * Se o registro for encontrado: * Apagar o registro na **`REPGRPF`**. **Trigger: `TRGREPGRP_D`** * Apagar o registro na **`TbGrupoRepEmpregado`**. * Pesquisar se existe o registro na tabela **`REPNAUTO000`**. * Se o registro **não for encontrado**, inserir na **`REPNAUTO000`** com **STATUS = 8** (Excluir). * Se o registro for encontrado e o **STATUS for 3 ou 0**, atualizar o **STATUS para 8** (Excluir). * Executar o mesmo procedimento para **Biometria**. ## Fluxo de Inclusão Para fins de desenvolvimento, este fluxo utiliza a thread **`WorkerThreadAdd`**. **Parâmetro**\ Registro do tipo **`TbGrupoRepEmpregado`** **Fluxo** * Verificar se existe registro na **`REPNAUTO`** com **STATUS <> 0**. * Se existir, significa que o registro está em processamento. * Nesse caso, **não continuar** o processamento e seguir para o próximo registro. * Verificar se o registro existe na **lista de exclusão**: * Se **SIM**, trata-se de uma **alteração**: * Se houver mudança de grupo, executar a thread **`WorkerThreadDelete`**. * Se houver mudança de nome ou PIS, executar a thread **`WorkerThreadUpdate`**. * Se **NÃO**, trata-se de uma **nova inclusão**: * Executar a thread **`WorkerThreadInsert`**. ### Fluxo de Inclusão – WorkerThreadUpdate **Parâmetro**\ Registro do tipo **`TbGrupoRepEmpregado`** **Fluxo** * Verificar se existe registro na **`REPGRPF`** pelo Crachá e Grupo. * Se **não existir**, inserir na **`REPGRPF`**. Trigger: **`TRGREPGRP_I`** * Verificar se existe o registro na **`REPEMPR002`**: * Se **não existir**, inserir na **`REPEMPR002`**. Trigger: **`TRGREPFUN_I]`** * Se existir, atualizar na **`REPEMPR002`**. Trigger: **`TRGREPFUN_U`** * Atualizar o registro na **`TbGrupoRepEmpregado`**. Executar Trigger **`TRGREPFUN_I`**: * `TELESSVR.Auxtrg_repFunc` → insere na **`REPNAUTO000`** com **STATUS = 3** * `TELESSVR.Auxtrg_repDig` → insere na **`REPNDIGAUTO000`** com **STATUS = 3** Executar novamente Trigger **`TRGREPFUN_U`:** * `TELESSVR.Auxtrg_repFunc` → insere na **`REPNAUTO000`** com **STATUS = 3** ### Fluxo de Inclusão – WorkerThreadInsert **Parâmetro**\ Registro do tipo **`TbGrupoRepEmpregado`** **Fluxo** * Verificar se existe registro na **`REPGRPF`** pelo Crachá e Grupo. * Se **não existir**, inserir na **`REPGRPF`**. Trigger: **`TRGREPGRP_I`** * Verificar se existe o registro na **`REPEMPR002`**: * Se **não existir**, inserir na **`REPEMPR002`**. Trigger: **`TRGREPFUN_I`** * Se existir, atualizar na **`REPEMPR002`**. Trigger: **`TRGREPFUN_U`** * Inserir o registro na **`TbGrupoRepEmpregado`**. Executar Trigger **`TRGREPFUN_I`:** * `TELESSVR.Auxtrg_repFunc` → insere na **`REPNAUTO000`** com **STATUS = 3** * `TELESSVR.Auxtrg_repDig` → insere na **`REPNDIGAUTO000`** com **STATUS = 3** * Executar novamente Trigger **`TRGREPFUN_U`**: * `TELESSVR.Auxtrg_repFunc` → insere na **`REPNAUTO000`** com **STATUS = 3** ## Guia Rápido de Uso Resumo do fluxo principal: * A view `VHISTORICOCRACHAREP` retorna todos os empregados; * O sistema compara os dados com `TBGRUPOREPEMPREGADO`; * São geradas listas de: * Inclusão; * Exclusão; * Exclusão adicional; * O processo de exclusão é executado primeiro; * Em seguida, o sistema executa inclusão ou atualização conforme o cenário; * Triggers e tabelas de automação controlam o envio aos REPs; * Logs registram todo o processo. ## Glossário * **Trigger**: Procedimento automático executado no banco de dados após uma operação. * **Thread**: Processo de execução paralelo utilizado pelo sistema. ## FAQ – Perguntas Frequentes
O que acontece se um empregado existir no banco do ConexREP, mas não no Suricato? Será incluído na lista adicional de exclusão e removido do REP.
Por que o processo de exclusão é executado primeiro? Para evitar inconsistências e garantir que registros inválidos sejam removidos antes de novas inclusões.
O que acontece se um registro já estiver em processamento? O sistema ignora esse registro e segue para o próximo.
Alterações de nome ou PIS geram exclusão? Não. Nesse caso, é executado o fluxo de atualização.
O log pode ser mantido por mais de 90 dias? Sim, ajustando o parâmetro `log.clean.days` no arquivo `suricato-rep.properties`.
--- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://software-telematica-com.gitbook.io/suricato-docs/central-tecnica/instalacao-e-configuracao-de-servicos-do-suricato/instalacao-e-configuracao-do-suricato-rep/fluxo-de-dados-suricato-rep.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.