¶ [SIEP API Pública] Estudo técnico para otimização do retorno dos plantões para o Portal da Transparência e Prefeitura
| Data de elaboração | 26/08/2024 |
| Responsável pelo estudo | Lucas Henryck Santos Veloso |
| Equipe do estudo | Vingadores |
| Alvo | SIEP API Pública |
| Origem | Objetivo Estratégico: Propor uma solução para otimizar o retorno dos plantões do SIEP para o Portal da Transparência e Prefeitura |
| Observações |
¶ 1. Objetivo
Este estudo tem como finalidade propor uma solução técnica que otimize a busca e o retorno dos plantões para o Portal da Transparência e Prefeitura, visando acelerar o tempo de resposta da API.
¶ 2. Introdução
A API Pública do SIEP fornece dados sobre os plantões criados no sistema para o Portal da Transparência e para a Prefeitura. Ela foi criada como um projeto separado da API interna do SIEP, que é responsável pelas operações de back-end do sistema, mas ambas estão na mesma solução. Os endpoints que retornam os plantões para o Portal e para a Prefeitura foram versionados, consultando diferentes histórias baseados em filtros, realizando integrações com a API de servidores do e-Estado e retornando dados específicos de acordo com a necessidade dos solicitantes.
Na consulta de plantões para o Portal da Transparência, são utilizados diversos filtros relacionados ao plantão e também ao servidor, cujas informações básicas no banco de dados incluem CPF, matrícula e nome. Após a filtragem inicial de plantões, são realizadas duas buscas no e-Estado: uma por matrícula e outra por ID do servidor, para trazer informações do plantonista, sendo a última para obter as ocorrências que estejam em conflito com o plantão. Posteriormente, os objetos de retorno dessa rota são construídos baseado nas propriedades solicitadas. Recentemente, foram adicionados dois novos filtros: o de cargo e o de busca genérica, que filtram informações presentes tanto na base de plantões quanto no e-Estado, como cargo e quantidade de horas semanais do servidor. Como esses filtros validam dados capturados após a consulta ao banco de dados e em outra base por meio de API, a paginação manual torna-se inviável. Essas múltiplas integrações acabam tornando a requisição pesada e, com a falta de paginação, comprometem um tempo de resposta adequado para a requisição.
Na consulta de plantões para a Prefeitura, são utilizados apenas dois filtros (mês e ano) relacionados aos plantões. Após a filtragem dos plantões pelo período, também é feita uma consulta no e-Estado por meio da matrícula para buscar as informações dos plantonistas. É feito uma paginação manual para buscar apenas 10 plantões por vez com a finalidade de acelerar a consulta. O usuário informa a página solicitada e quantidade de dados que estarão presentes na mesma. Logo após, os objetos de retorno são construídos de acordo com as propriedades solicitadas. Contudo, há um problema com a propriedade solicitada de alterações na escala homologada é uma estrutura de histórico que o SIEP não possuía até então e que foi substituida e adaptada pelos dados da tabela de auditoria. Basicamente, essa propriedade seria a informação de todos os servidores que saíram ou entraram na escala após a sua homologação. Esses dados de remoções e adições são armazenados pela auditoria, mas não são adequados para serem visualizadas ou utilizadas por usuários, apenas para o conhecimento dos desenvolvedores. Por ser uma tabela genérica que armazena as manipulações de várias entidades do sistema, é extremamente extensa e só tende a crescer ainda mais em volume de dados. Além disso, as informações são guardadas em formato de texto, o que torna mais lento a busca por algo específico.
¶ 3. Desenvolvimento
¶ 3.1 Melhoria da busca de plantões para Portal da Transparência
O primeiro ponto a ser abordado para viabilizar a paginação mesmo com a filtragem de cargos é a utilização de uma outra rota de servidores, que busca todos de acordo com algum parâmetro específico. Caso o usuário deseje utilizar o filtro de cargo, é obrigatório informar também o departamento ou unidade. Nesse caso, é feita uma busca no e-Estado de todos os servidores alocados no departamento informado, filtrando apenas aqueles que possuem o cargo equivalente ao especificado no parâmetro do endpoint. Após essas validações iniciais, o banco de dados é acessado, mas desta vez apenas os plantões dos servidores presentes na listagem anterior serão retornados. Dessa forma, a filtragem é realizada antes da consulta na base de dados, o que permite limitar a consulta e acelerar o tempo de resposta da requisição.
O segundo ponto refere-se à insustentabilidade do filtro de busca genérica, pelo menos no estado atual. Manter as propriedades «cargo» e «horas semanais» é inviável, pois esses parâmetros dificultam a validação justamente por não serem dados provenientes do banco de dados, exigindo consultas em diferentes bases. Além disso, por serem genéricos, é impossível saber com o que compará-los especificamente, o que compromete uma busca precisa. Atualmente, a validação dos objetos já construídos em memória ocorre ao final da consulta, após todas as integrações e filtragens necessárias. No entanto, isso impede a paginação, já que não se sabe quais plantões podem ser retirados após essa validação. Uma possível solução seria criar um filtro independente para horas semanais, assim como já existe para cargo, deixando a busca genérica apenas para as propriedades nativas do banco.
¶ 3.2 Melhoria da busca de plantões para Prefeitura
A solução encontrada para o problema das alterações nas escalas homologadas que utilizam a auditoria foi a criação de uma nova tabela chamada HistoricoDasEscalas, que armazenará as informações de criação e edição das escalas. Sua estrutura será semelhante à da tabela de auditoria, mas as informações serão baseadas em propriedades específicas para as manipulações, e haverá uma coluna com o ID da escala, o que facilitará a busca da escala específica. As colunas serão: ID da tabela, ID da escala, ação, servidores adicionados, servidores removidos, data de movimentação, CPF, matrícula e nome do usuário. Caso a escala do plantão consultado tenha alguma edição após a homologação, os servidores adicionados ou removidos serão buscados e retornados.
¶ 4. Conclusão
Com essas melhorias, a API Pública do SIEP deve apresentar uma melhoria significativa no tempo e no corpo da resposta, o qual ficará mais bem definido.