¶ Estudo Sobre os Scripts Utilizados Para o Fechamento da Folha de Pagamento.
| Data de elaboração | 23/08/2023 |
| Responsável pelo estudo | Ádrian Rabelo Mendes (Assessor), Diego Gonçalves de Almeida (Assessor), Jônatas Legal (Técnico em Tecnologia da Informação e Comunicação) (Assessor), Rodrigo Stefano Sales Nascimento (Assessor) |
| Equipe do estudo | CAOS |
| Alvo | Sistema Governa |
| Origem | Scripts SQL utilizados pela SEGEP para o fechamento da folha de pagamento. |
| Objetivo | Para verificar a possibilidade de implementação e execução automatizada desses scripts SQL em funcionalidades do Governa após processamento da folha de pagamento. |
Glossário
API - Application Programming Interface (em português Interface de Programação de Aplicação)
HTTP - Hypertext Transfer Protocol (em português Protocolo de Transferência de Hipertexto)
HTML - Hypertext Markup Language (em português Linguagem de Marcação de Hipertexto)
SQL - Structured Query Language (em português Linguagem de Consulta Estruturada)
REST - Representational State Transfer (em português Transferência de Estado Representacional)
URL - Uniform Resource Locator (em português Localizador Padrão de Recursos)
¶ 1. Introdução
Atualmente, o cálculo da folha de pagamento ocorre mensalmente através do sistema Governa. No entanto, há algumas verificações que precisam ocorrer antes do fechamento completo da folha. Essas verificações são realizadas manualmente pela equipe de usuários da SEGEP responsáveis pela folha de pagamento do estado. Verificações estas realizadas através de scripts SQL diretamente no banco de dados do Governa.
¶ 1.1 Problema
A execução de scripts no banco de dados, ao invés de funcionalidades na aplicação, não é somente oneroso ao usuário no cumprimento das suas atividades, devido ao trabalho manual e exaustivo. É oneroso também a integridade do próprio banco de dados. Há ainda a possibilidade de brechas de segurança, risco de violação a LGPD, entre outras situações, consequentes do acesso aos dados não estarem restritos apenas à aplicação. Estes scripts estão listados a seguir:
- ANTES DA ANÁLISE verificando valor da verba 85 que não esta na financeiro mensal
- ANTES DA ANÁLISE verificando abono sem salvar na financeiro_mensal
- ANTES DA ANALISE verificando diferença de consignação
- sp_gerar_auxilio_saude - GERAR APENAS NA PREVIA
- verificar servidores sem verba de vencimento
- verificando saldo negativo
- verificando servidores admitidos 06112018 prevcom
- verificando lotações novas
- verificando afastamentos IPERON em servidor não IPERON
- Checar Afastamento Salario Maternidade Errado
- checando FGTS
- verifica servidores sem vencimento no mês
- VERIFICANDO SERVIDORES COM INSALUBRIDADE E PERICULOSIDADE
- verificando hora extra errada
- Altera verba 709 763 para 303 de quem está na TABSAL PCIVIL
- checando gozo com varias datas de pagamento para mesmo período aquisitivo
- checando quem tem averbação duplicada
- Checando Recebimento Cumulativo das Verbas 165. 2013 e 2015
- Checar SEJUS com verba de adicional noturno errado 719
- Checar SEJUS com verba de adicional noturno errado. 783
- Checar SEJUS com verba de adicional noturno errado. 785
- corrigindo saldo negativo indevido
- Deletando Verbas Indevidas no Detran
- Deletar Auxilio Transporte de Federais
- Deletar férias de servidores afastados aguardando aposentadoria com data de pagamento maior igual ao mês corrente
- Deletar vale transporte para quem está afastado aguardando aposentadoria
- Deletar verbas variáveis para quem está afastado aguardando aposentadoria
- Exclusão de conflito de verbas 709 com 363 303
- Lançando reposição de GAE para servidores da saúde com faltas
- REL. SERVIDORES FEDERAIS A DISPOSIÇÃO DO ESTADO COM INSS
- relação de quem tem a verba 727,1727 com a tabela da SESAU 0020.0728182022-18
- Verifica Duplicidade de Auxilio Saúde
- Verifica GAD Valores Errados
- Verifica Piso do Magistério em Cargos não Professores Exclui a Verba
- Verifica Piso do Magistério em Cargos não Professores Fecha a Verba
- Verifica Plantões Errados da SESAU
- Verifica Servidores não IPERON com Afastamento IPERON
- verificando averbação suspensa com desconto
- Verificando Cedido sem CDSFG
- verificando diferença de consignação
- verificando diferença entra verba 2051 e 2043
- verificando duplicidade de auxilio COVID
- verificando inativos com afastamento
- verificando inativos com auxilio saúde
- verificando inativos com férias
- verificando lançamento de verba de consignação na verba eventual
- verificando licença premio com data de pagamento
- verificando PM e BM em classificação errada
- Verificando quem tem somente auxilio transporte, auxilio saúde, complemento salario mínimo e outros
- VERIFICANDO SERVIDORES COM INSALUBRIDADE E PERICULOSIDADE
- Verificar Averbações em Servidores em Cargo para Pagamento
- VERIFICAR COM ABONO PERMANECIA E CDS
- Verificar GAD Médicos em não médicos
- verificar maternidade INSS sem salvar valor no campo maternidade INSS na financeiro base
- VERIFICAR PAGAMENTO EM DUPLICIDADE DE PERICULOSIDADE
- VERIFICAR SERVIDORES COM FG E CDS COM GAE E HORA EXTRA
- verificar verba exclusão BB
Os detalhes deles podem ser visualizados no Anexo I.
¶ 1.2 Proposta de Solução
Para resolver o problema, propõe-se automatizar a execução desses scripts pela aplicação, implementando suas regras de negócio e restringindo seu controle exclusivamente à aplicação.
¶ 2. Referencial Teórico
Este capítulo introduz a base teórica deste estudo. São brevemente descritos conceitos de comunicação entre softwares com APIs. Também algumas premissas de arquitetura de software, especificamente da arquitetura monolítica que forma a base estrutural do Governa, e da arquitetura de microsserviços na qual poderá ser implementada a automação dos scripts. Por fim, também são apresentadas as ferramentas e tecnologias que podem ser utilizadas no desenvolvimento dessa solução.
¶ 2.1 API
No contexto de APIs, a interface pode ser pensada como um contrato de serviço entre duas aplicações. Esse contrato define como APIs se comunicam e a documentação delas contém informações sobre como os desenvolvedores devem estruturar essa comunicação usando requisições e respostas. Já a aplicação refere-se a qualquer software com uma função distinta.
A arquitetura da API geralmente é explicada em termos de cliente e servidor. A aplicação que envia a solicitação é chamada de cliente e a aplicação que envia a resposta é chamada de servidor.
Há uma diversidade de maneiras pelas quais as APIs podem funcionar, mas vale destacar APIs REST. Essas são as APIs mais populares e flexíveis encontradas na Web atualmente. O cliente envia solicitações ao servidor como dados. O servidor usa essa entrada do cliente para iniciar funções internas e retorna os dados de saída ao cliente.
A principal característica da API REST é a ausência de estado. A ausência de estado significa que os servidores não salvam dados do cliente entre as solicitações. As solicitações do cliente ao servidor são semelhantes aos URLs digitadas no navegador para visitar um site. A resposta do servidor corresponde a dados simples, sem a renderização gráfica típica de uma página da Web.
¶ 2.2 Arquitetura de Software
A arquitetura de software especifica como um sistema deve ser organizado e estruturado, compreendendo o conjunto de componentes do sistema, suas relações entre si, relacionamento com outros softwares e os princípios que regem sua evolução. A arquitetura destaca uma série de decisões de projeto e fornece mecanismos para considerar os benefícios de estruturas alternativas do sistema.
Vários estilos de arquitetura encontram-se à disposição dos engenheiros de software que podem ser aplicadas à uma arquitetura específica para um software valendo destacar microsserviços e arquitetura monolítica em termos de desenvolvimento web.
¶ 2.2.1 Arquitetura Monolítica
Uma aplicação web típica é executada em um computador remoto, denominado servidor, cuja interface de usuário é acessada por meio de um navegador (browser) no computador cliente. A aplicação é dita ser monolítica (ou monólito), quando toda a sua lógica é executada em uma única máquina, compartilhando memória, arquivos e recursos de processamento.
Apesar das principais linguagens de desenvolvimento de aplicações oferecerem abstrações para fragmentar a complexidade dos sistemas em módulos, ainda são projetadas para a criação de um único executável, no qual toda a modularização utilizada é executada numa mesma máquina compartilhando seus recursos.
Uma aplicação em arquitetura monolítica típica pode ser representada pela Figura 1 a seguir, onde todas as suas funções estão implementadas e são executadas em um único processo.
É este único executável lógico que manipula solicitações HTTP, executa lógicas de negócio, recupera e atualiza dados do banco de dados, e constrói visualizações HTML a serem enviadas ao navegador.
¶ 2.2.2 Arquitetura de Microsserviços
O termo «Arquitetura de Microsserviços» surgiu nos últimos anos para descrever uma maneira particular de projetar aplicativos de software como suítes de serviços independentemente implantáveis. Trata-se de uma abordagem para o desenvolvimento de aplicações através da decomposição de suas funcionalidades em serviços discretos, cada um executando em seu próprio processo e se comunicando com mecanismos leves, tal como uma API de recursos HTTP.
A proposta da arquitetura de microsserviços é possibilitar o desenvolvimento de aplicações de maneira mais flexível, escaláveis e com manutenção mais simples em relação às aplicações em arquiteturas monolíticas. Como a aplicação é criada com pequenos serviços independentes, cada serviço pode funcionar ou falhar individualmente sem comprometer os demais. A Figura 2 representa um esquema de uma aplicação em arquitetura de microsserviços.
Um serviço é desenvolvido para solucionar um problema específico e pode ser implantado, atualizado e escalado de forma independente, mantendo sua disponibilidade e funcionamento. Como os processos da aplicação são executados como serviços que se comunicam por meio de APIs, estes não necessitam ser desenvolvidas em uma linguagem de programação específica.
¶ 2.3 Spring Framework
O Spring é um framework que facilita a criação de aplicativos corporativos. Fornece tudo o que o desenvolvedor necessita para adotar a linguagem de programação Java em um ambiente corporativo, e com a flexibilidade de criar muitas tipos de arquiteturas dependendo das necessidades de um aplicativo. É de código aberto e possui uma comunidade amplamente ativa que fornece feedback contínuo com base em uma gama diversificada de casos de uso do mundo real.
O Spring é dividido em módulos. Os aplicativos podem escolher quais módulos precisam. No centro estão os módulos do contêiner principal, incluindo um modelo de configuração e um mecanismo de injeção de dependência. Além disso, fornece suporte para diferentes arquiteturas de aplicativos, incluindo mensagens, dados transacionais e persistência e web.
¶ 3. Possível Solução
Embora o Governa seja um sistema monolítico, não há impedimento para uma abordagem híbrida utilizando microsserviços para processamentos específicos, como é o caso da execução dos scripts. Um microsserviço possibilitará a automação destes de forma independente do Governa, permitido que sejam executados de diversas formas distintas e em qualquer momento oportuno. Vale ressaltar a facilidade de manutenção dessa solução, devido ao desacoplamento e a tecnologia mais atualizada. E ainda, a desoneração dos recursos já escassos do Governa, devido as execuções de cálculos pesados.
¶ 3.1 Microsserviço de Fechamento da Folha
Como visto anteriormente, os scripts realizam uma série de verificações nas tabelas do governa após o cálculo da folha de pagamento, visando corrigir eventuais erros.
Para o desenvolvimento dessa solução, pode-se construir um microsserviço simples utilizando Spring REST a fim de fornecer uma interface para troca de informações entre o Governa e o microsserviço. Também é possível utilizar um serviço de mensageria para empilhar requisições a fim de manter a disponibilidade integral dessa comunicação. Essa relação pode ser vislumbrada na Figura 3 a seguir:
Na maioria dos aspectos, este seria um típico aplicativo Spring Boot simples. No entanto, a complexidade de implementação estará na conversão dos scripts em funcionalidades, devido as suas particularidades, e por fim incrementando todas as regras de negócio dos scripts na aplicação.
¶ 4. Conclusão
Após uma breve análise dos scripts, observou-se uma premissa geral. Caso as consultas não retornem resultados significa que os dados estão corretos; havendo retorno, os registros devem sofrer alterações ou exclusão. No mínimo, as duas histórias a seguir serão necessárias para dar início aos trabalhos.
| História | O quê: Implementar, no Governa, funcionalidade para chamada à API externa. Por quê: Para possibilitar a comunicação entre o Governa e o microsserviço. |
| Regras e Validações | — |
| Pontuação | 8 |
| História | O quê: Criar projeto do microsserviço, configurar e adicionar ao gitlab da SETIC. Por quê: Para desenvolvimento, manutenção e versionamento do código-fonte |
| Regras e Validações | Configurar como API com Spring Framework em Java. Configurar versionamento e ambientes de Development, Staging e Production na esteira do gitlab. |
| Pontuação | 8 |
Essas histórias possibilitarão que o Governa realize chamadas à APIs e ao início do desenvolvimento do microsserviço. Ainda será necessária a criação de uma história para cada script, visto que cada um possui suas particularidades e precisam ser compreendidos para correta implementação.
¶ 5. Referências
Visão geral de API :: Amazon AWS
SOMMERVILLE, I. Engenharia de Software. 9ª edição. São Paulo: Pearson. 2011.
PRESSMAN, R. S. Engenharia de Software uma abordagem profissional. 8ª edição. São Paulo: AMGH, 2016.
FOWLER, M; LEWIS, J. Microservices. martinfowler.com; 2014.
Visão geral do Spring Framework :: Spring Framework
¶ ANEXO I
Scripts SQL utilizados pela SEGEP para fechamento da folha de pagamento. Os scripts seguintes (itens 1, 2, 3 e 4) são executados na ordem em que se apresentam uma única vez.