Projeto criado durante um evento da escola online de tecnologia Alura onde todos os alunos receberam um conjunto de informações via Trello e instruções via lives e videos gravados para criarem uma aplicação web tradicional, server-side, com o objetivo de realizar a analize de arquivos CSV de transações financeiras entre bancos e a inserção das informações presentes nele dentro do banco de dados, respeitando algumas regras de negócio e necessidades do cliente final.
A aplicação MVC pode ser acessada por meio do IP
http://34.151.195.83:8090
O acesso pode ser realizado por meio do login padrão:
login: admin@email.com.br
senha: 123999
Nesta primeira semana as tarefas foram referentes a criação do projeto, do banco de dados e do formulário para realização do upload de arquivos CSV. Como em todos os demais desafios a Alura disponibiliza diversos cursos para nos aperfeiçoarmos em diferentes linguagens, tudo dentro da própria plataforma, e também sanarmos algumas duvidas que possamos ter, e nos da total liberdade de escolhermos como iremos trabalhar durante esse projeto, escolhendo linguagens, plataformas, etc.
Abaixo detalhei o que elaborei nesta primeira etapa do projeto:
Para a elaboração do projeto utilizei MySQL com Flyway, permitindo versionamento do banco de dados e controle das querys lanças ao banco de dados dentro da pasta resources/db/migration.
Por questão de prática e até mesmo para treino e aperfeiçoamento escolhi a linguagem JAVA, que é a que tenho maior interesse, assim como o Framework Spring. Junto destes utilizei Thymeleaf e Bootstrap para trabalhar no html e css.
Para realizar o upload dos arquivos a primeira etapa foi a criação do formulário html onde, como descrevi acima, utilizei Bootstrap para a estilização e Thymeleaf para alguns controles de validação e respostas enviadas para o html.
Após a elaboração desta tela, nesta mesma semana, foi solicitada a alteração para exibir também uma listagem das datas das transações presentes nos arquivos csv (cada arquivo deveria conter apenas as tranções de um único dia) que tiveram seus uploads realizados, assim como a data que foram realizados esses uploads.
Por fim foi gerada a tela abaixo:
Nesta etapa do projeto utilizei a criação de apenas um controller e apenas uma url, porém com a disponibilidade de dois métodos, POST e GET, para realizar o upload e a recuperação das informações.
Para o controle das transações criei uma entidade - Transacao - e para o controle das datas de upload criei outra - Importacao - , ficando com duas classes e duas tabelas dentro do banco de dados, e para o controle das regras de negócio e tratamento das informações, convertendo de fato o arquivo CSV para uma instância de Transação, criei uma classe chamada de TransacaoService.
- Criar o banco de dados;
- Criar endpoints para o formulário.
- Realizar validação dos arquivos CSV antes do upload e, se estiverem okay, realizar cadastro no banco de dados;
- Realizar a criação das telas para o upload e verificação dos arquivos que já foram carregados.
Nesta segunda semana as tarefas foram focadas em pontos que são muito exigidos, sejam em aplicações MVC ou APIs REST, que são os de segurança e autenticação. Fomos orientados a criar o CRUD de usuários, assim como as telas de login e de cadastro e também tivemos que alterar nosso banco de dados para adicionar um campo para registrar os usuários responsáveis pelo upload de cada uma das importações realizadas na aplicação. Uma série de regras de negócio foi exigida para a criação do CRUD de usuários:
Regras de negócio:
Apenas 2 informações serão necessárias no cadastro: Nome e Email, sendo ambas obrigatórias
A aplicação deve gerar uma senha aleatória para o usuário, composta de 6 números;
A senha deverá ser enviada para o email do usuário sendo cadastrado;
A senha não deve ser armazenada no banco de dados em texto aberto, devendo ser salvo um hash dela, gerado pelo algoritmo BCrypt;
A aplicação não deve permitir o cadastro de um usuário com o email de outro usuário já cadastrado, devendo exibir uma mensagem de erro caso essa situação ocorra;
A aplicação deve ter um usuário padrão previamente cadastrado, com nome: Admin, email: admin@email.com.br e senha: 123999;
O usuário padrão não pode ser editado e nem excluído da aplicação, tampouco deve ser exibido na lista de usuários cadastrados;
Qualquer usuário tem permissão para listar, cadastrar, alterar e excluir outros usuários;
Um usuário não pode excluir ele próprio da aplicação.
Com usuários criados também tivemos que realizar a alteração da exclusão padrão para uma exclusão lógica de usuários do banco de dados e também criar uma tela para exibir detalhes das importações, mostrando todas as transações que foram registradas dentro daquele arquivo
Para realizar o login utilizei a seguinte tela, com auxilio do Spring Security para implementação de seguranã e também de Thymeleaf para integração do HTML com os controllers como já vinha fazendo:
Caso algum erro seja encontrado com as informações de login a seguinte tela é mostrada:
A tela utilizada para importação de transações ganhou duas novas colunas dentro da tabela de exibição de importações realizadas, uma referente ao usuário que realizou o upload do arquivo e outra para permitir o detalhamento das informações:
Todas as telas ganharam também um navbar para permitir que sejam acessados todos os endpoints da aplicação sem maiores problemas:
Ao se clicar no botão de Detalhar em um dos itens da tabela se é exibido todas as transações do banco de dados:
Para a funcionalidade da imagem acima utilizei a data das transações como PathVariable e a utilizei em meu Repository para pesquisar todas as transações referentes, considerando que um arquivo só poderá realizar uploads de transações de uma mesma data e que, uma vez que uma data tenha o seu arquivo CSV cadastrado ela não pode mais ser utilizada.
Para os usuários utilizei a tela abaixo para a listagem, sendo acessada via navbar:
Permitindo o cadastro de novos usuarios pelo botão Novo
Uma tela semelhante é exibida ao se selecionar a edição de um dos usuários:
E por fim utilizei um modal junto ao botão de excluir para permitir uma confirmação do usuário para exclusão lógica do usuário em questão:
Todas as validações foram feitas com BeanValidation e o usuário admin foi inserido no banco de dados previamente, com senha criptografada e deixado de lado nas listagens de usuário por meio de edição dos repositorys com a anotação @Query.
As alterações no banco de dados foram feitas por meio do Flyway:
Como meus dados de login seriam diferentes do padrão do Spring Security utilizei meu próprio esquema de tabelas e classes necessárias.
- Criar o CRUD de usuários;
- Implementar a autenticação;
- Criar uma tela para permitir o detalhamento de uma importação;
- Registrar quem realizou a importação, alterando o banco de dados para guardar esta informação.
Nas semanas três e quatro fomos expostos a principal tarefa do projeto, a criação da funcionalidade de analise de transações. Para a criação desta funcionalidade fomos orientados como seriam as regras para uma transação, uma conta e uma agência serem consideradas suspeitas, além de como deveriamos desenvolver uma interface visual para permitir que os usuários recebessem as informações e as pudessem utilizar.
Transação Suspeita: Valor da transação maior do que 100.000 reais.
Conta Suspeita: Valor total das transações no mês maior do que 1.000.000 de reais, seja para entradas ou saídas.
Agência Suspeita: Valor total das transaçõs no mês maior do que 1.000.000.000 de reais, seja para entradas ou saídas.
Além desta funcionalidade, recebemos a tarefa de modificar a estrutura do nosso código, permitindo agora que fosse possível também o recebimento de informações via XML, além dos arquivos CSV já aceitos.
Por fim deveriamos realizar o deploy e a documentação da aplicação aqui no GitHub.
O primeiro passo para a elaboração das tarefas desta semana foram a criação da nova tela para a visualização das transações, contas e agências suspeitas, que seguiu o mesmo padrão das telas anteriores, com Bootstrap e Thymeleaf:
Nesta tela já foram inseridas as devidas validações para solicitações com dados inválidos ou ausentes, como demonstrado a seguir:
-
Caso nenhum registro seja encontrado as tabelas apresentarão uma mensagem de "Não existem transações/contas/agências suspeitas para a data selecionada!":
-
Caso não seja selecionado o mês ou o ano uma mensagem de alerta será exibida embaixo da caixa de seleção para informar o usuário da obrigatoriedade dos dados:
E caso seja encontrado algum registro este é exibido na tabela correspondente:
Para alimentação destas tabelas foi criada a classe AnaliseTransacoesService que na realidade apenas chama alguns métodos novos que foram criados da classe TransacaoService para a elaboração do relatório:
Após a criação desta funcionalidade foi alterada a classe TransacaoService para permitir o upload de arquivos XML utilizando a biblioteca Jackson:
Arquivos XML foram organizados de forma que a classe Transacao conter uma classe interna chamada Conta, por este motivo uma classe Conta foi criada e integrada a classe Transacao e, para manter o padrão DTO, foi criada um novo record chamado TransacaoXML para tratar os dados enviados como XML:
Assim como também foram criados Records para o recebimento do ano e mês referente a geração do relatório e para envio dos dados para as tabelas, visando impedir que dados além do necessário fossem enviados:
Por fim foram desenvolvidos testes automatizados que visavam principalmente os endpoints da aplicação, focando em testas as classes Service e na validação dos dados. Foi optado por um teste diretamente nos Controllers por conta do uso da classe BindingResults nas classes Service, exigindo uma solicitação http para serem criados pelo Spring.
Durante a elaboração e execução das tarefas destas duas semanas e geração dos testes automatizados uma série de bugs foram encontrados e resolvidos, tais como:
- Erro ao enviar arquivos com datas ou valores em branco, quebrando a aplicação e levando o usuário a uma página de erro que não explicitava a causa do problema;
- Erro ao gravar um número muito grande de transações de uma só vez, gerando uma demora de até 5 minutos para registro de todas as transações no banco de dados, tempo que foi reduzido para cerca de 10 a 20 segundos;
- Necessidade de um retorno visual para permitir ao usuário entender que os dados estavam sendo processados, o que foi feito com o spinner do Bootstrap;
Também realizei o deploy da aplicação em ambiente cloud no Google Cloud, utilizando uma máquina virtual onde criei o banco de dados e efetuei o upload do arquivo jar, deixando rodando por meio do comando nohup.
Por fim também fiquei bem incomodado com uma segunda aplicação JAVA simples que criei para ser utilizada durante o projeto, algo que está aqui junto com a aplicação MVC que é o "GeradorCSV". Criei esta aplicação para gerar CSVs aleatórios para um dia específico para poder testar manualmente o projeto conforme o desenvolvia, porém, conforme o projeto foi crescendo vi a necessidade de alterar esta aplicação, então a modifiquei para criar também arquivos XML. Abaixo irei deixar um pequeno video demonstrando o seu funcionamento (utilizei o clideo para reduzir o tamanho do vídeo):
geradorcsv-mainjava-2023-04-25-14-48-00_cTfXd3wl.mp4
- Criação da nova tela para analise de transações;
- Geração do relatório de transações, contas e agências suspeitas;
- Alteração do código para aceitar arquivos XML;
- Deploy em cloud;
- Documentação no Github;
- Criação de aplicação java simples para geração de arquivos XML e CSV. [EXTRA!]