Análise para integração do consumo das informações do Consignação no Portal do servidor (Sistema Consignação)
| Data de elaboração | 16/08/2023 |
|---|---|
| Responsável pelo estudo |
|
| Equipe do estudo |
|
| Alvo | Portal do Servidor |
| Origem |
Implementação: Análise para integração do consumo das informações do Consignação no Portal do servidor |
| Objetivo |
Levantar as formas de integração para consumo das informações do consignação pelo portal do servidor |
| Documentação correlata | |
| Observações | O presente estudo pretende também pretende levantar as Historias dos Cards para a Sprint |
1. Objetivo
O Presente estudo objetiva levantar as formas de integração para consumo das informações do consignação pelo portal do servidor.
1.1 JUSTIFICATIVA
O portal do servidor foi criado para facilitar o acesso a várias informações por meio de integrações com diferentes sistemas. Um exemplo disso é o sistema de consignação, que contém informações importantes para o servidor. Para garantir que essas informações sejam exibidas de forma segura, a integração entre o sistema consignação e o portal do servidor deve ser configurada para acessá-las de maneira confiável.
1.2 RESULTADOS ESPERADOS
Espera-se que após a conclusão desse estudo seja possível mostrar como será possível a forma que o portal do servidor acessará as informações do sistema consignação.
2. Introdução
Em um esforço contínuo para melhorar a eficiência e a experiência do usuário, a integração entre tecnologias diferentes desempenha um papel fundamental. No caso em questão, a sinergia entre um portal do servidor construído em .NET e uma API Java Spring Boot oferece uma solução robusta para acessar informações cruciais sobre empréstimos consignados.
Benefícios da Integração:
- Acesso a Dados Atualizados: O portal do servidor pode solicitar informações atualizadas diretamente da API, garantindo que os detalhes de empréstimos consignados estejam sempre precisos.
-
Segurança Reforçada: A integração é projetada para manter altos padrões de segurança. As políticas de autenticação e autorização garantem que apenas usuários autorizados tenham acesso aos dados sensíveis.
-
Aprimoramento da Experiência do Usuário: A integração transparente permite que os usuários acessem informações de empréstimos consignados sem a necessidade de alternar entre diferentes sistemas.
3. Desenvolvimento
3.1 CENÁRIO ATUAL
AtualmenteEm um cenário digital cada vez mais interconectado, a funcionalidadesegurança da informação tornou-se um aspecto crítico para qualquer aplicação. Uma das maneiras fundamentais de quitaçproteger recursos e dados é por meio de autenticação automáticarobusta apresentaem problemasAPIs. O Java Spring Boot, um framework de completude,desenvolvimento permanecendorápido algumaspara averbaçaplicações ativasJava, mesmooferece comferramentas poderosas para implementar diversos métodos de autenticação, proporcionando um ambiente seguro para acesso aos endpoints.
O Portal do Servidor .NET:
O portal do servidor, construído na plataforma .NET, proporciona aos funcionários e colaboradores um acesso centralizado a uma variedade de serviços e informações. Com uma interface intuitiva e recursos personalizados, o valorportal restantetorna a pagarnavegação zerado.e a interação mais convenientes, otimizando os processos internos.
A API Java Spring Boot:
Do outro lado, a API Java Spring Boot é a força motriz que facilita o acesso seguro e eficiente às informações de empréstimos consignados do servidor. Baseada na robusta estrutura do Spring Boot, a API oferece a capacidade de expor dados relevantes por meio de endpoints bem definidos. Isso permite que o portal do servidor recupere os detalhes dos empréstimos consignados de maneira rápida e confiável.
3.2 SOLUÇÕESÃO PROPOSTASPROPOSTA
DevidoFoi aorealizado altoum nívelteste de complexidade encontrada na funcionalidade de quitação automática, é possível estimar que uma alternativa mais rápida e que representa menos riscos a integridade geral do código fonte, seria a de desenvolver funcionalidades complementares à quitação automática.
A primeira trata-se de uma tela nova no sistema com um relatório, que informa o usuário se a quitação foi bem sucedida ou não. Este relatório trará todas as parcelas indevidamente ativas.
A segunda funcionalidade trará um botão na mesma tela anteriormente criada, que executa um script de atualização do status das parcelas que não foram devidamente quitadas.
3.2.1 Relatório de Averbações Ainda Não Quitadas
Atualmente os dados são obtidos via script direto em banco de dados, utilizando o seguinte script:
SELECT DISTINCT
a.COD_AVERBACAO,
a.VLR_PARCELA,
a.VLR_PAGO,
a.VLR_A_PAGAR,
a.MES_REFERENCIA,
a.ANO_REFERENCIA,
QTD_PARCELA,
a.IND_STATUS,
a.NUM_MATRICULA,
a.DAT_CRIACAO,
a.DAT_ALTERACAO,
a.COD_VERBA
FROM
AVERBACAO a
JOIN CORRESPONDENTE c ON
c.COD_CORRESPONDENTE = a.COD_CORRESPONDENTE
JOIN AVERBACAO_DESCONTO ad ON
ad.COD_AVERBACAO = a.COD_AVERBACAO
JOIN VERBA v on
v.COD_VERBA = a.COD_VERBA
join TIPO_VERBA tv on
tv.COD_TIPO_VERBA = v.COD_TIPO_VERBA
WHERE
a.VLR_A_PAGAR = 0
AND a.IND_STATUS = 'ATV'
and v.COD_TIPO_VERBA = 1
;Com base neste script é possível se obter todas as parcelas que ainda estão incorretamente ativas, logo é possível criar uma tela com esta filtragem para que - após executado o processo de quitação, o usuário com maior permissão de acesso possa constatar via sistema se o processo está certo ou não, o que eliminará a necessidade de intervenção manual da SETIC na elaboração deste relatório.
3.2.2 Funcionalidade de Atualização de Status das Parcelas
A partir do relatório gerado pelo sistema, será possível desenvolver uma nova funcionalidade que complementará a quitação. Esta funcionalidade utilizará a filtragem criada para atualizar o status das averbações que não foram devidademente atualizadas com a quitação automática. Estima-se que esta funcionalidade complementar não trará problemas a estabilidade do sistema como um todo e então entregará o resultado necessário para o momento em questão, no qual o sistema passa por uma série de problemas relacionados a integridade de dados e segurança.
Atualmente a SETIC conta com o apoio da CAGD para a atualização manual dos dados em banco de dados, então uma breve colaboraçintegração entre ao CODEportal edo aservidor CAGDque será necessáriadescrito para o desenvolvimento desta funcionalidade.abaixo:
3.2 HISTÓRIAS DE USUÁRIO
Para aplicar a solução acima será necessário as seguintes histórias de usuários:
| O que? | Pontos | Regras | Produto |
| Criar tela com relatório de parcelas relatório de servidores cujo as averbações com o valor a pagar = 0 e quantidade de parcelas = 0 com tipo de empréstimo = 1, a partir de script de filtragem existente. | 8 |
Permitir apenas usuários administradores acessarem esta tela. |
Consignação |
| Criar botão na tela de relatório, que acione uma funcionalidade de corrigir o status das averbações com o valor a pagar = 0 e quantidade de parcelas = 0 com tipo de empréstimo = 1. | 8 |
Permitir apenas usuários administradores acessarem esta tela. |
Consignação |
| Salvar log com informações sobre quem realizou a ação de corrigir status das averbações. | 5 |
Salvar logs com todas as informações pertinentes ao usuário. Salvar informações de quais foram as averbações afetadas. |
Consignação |
3.3 POSSÍVEIS IMPEDIMENTOS
É possível que existam alguns problemas relacionados a tecnologia utilizada na criação do sistema, ou a falta de disponibilidade da CAGD para colaboração com a CODE no desenvolvimento destas funcionalidades.
4. Conclusão
Conclui-se que a entrega destas funcionalidades complementares à quitação automática trarão benefícios ao sistema e a todos os servidores que fazem empréstimo consignado.