Geração de logs em funcionalidades importantes do sistema de Consignação

1. Objetivo

O presente estudo visa analisar e propor a funcionalidade para geração de logs em funcionalidades importantes do sistema de Consignação.

1.1 JUSTIFICATIVA

Existem atualmente várias funcionalidades que nao são cobertas pela geração de logs e se faz necessária a geração destes registros para devidas auditorias no sistema. É importante ressaltar que o sistema conta com a geração de logs, porém está inativa no atual momento.

1.2 RESULTADOS ESPERADOS

Espera-se que, após este estudo, seja possível identificar os meios para reativar a geração de logs nas funcionalidades existentes e assim estimar os cards necessários para implementação nas demais áreas do sistema.

2. Introdução

O sistema de Consignação necessita que seja reestabelecido o funcionamento da geração de logs para que, além das funcionalidades já cobertas, outras áreas possam contar com uma cobertura de registro de logs.

3. Desenvolvimento - Geração de logs em funcionalidades importantes

3.1 CENÁRIO ATUAL

No atual momento - da redação deste estudo, a geração de logs do sistema de Consignação não apresenta pleno funcionamento.

Existe uma classe chamada LogAuditoria que possui, os campos necessários para a geração dos logs:

@Entity
@Table(name = "LOGAUDITORIA", schema = "dbo",
       catalog = "DB_CONSIGNACAO")
public class LogAuditoria implements Serializable {

    private static final long serialVersionUID = 1L;

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    @Column(name = "ID", nullable = false)
    private Integer id;

    @Column(name = "USUARIO", nullable = false)
    private String usuario;

    @Column(name = "DATAHORA", nullable = false)
    private Timestamp data;

    @Column(name = "EVENTO", nullable = false)
    private String evento;

    @Column(name = "MODULO", nullable = false)
    private String modulo;

    @Column(name = "CONTEUDO", nullable = false)
    private String conteudo;
  
  [...]
  
}

Existindo também uma tabela correspondente na base de dados, chamada LOGAUDITORIA:

A implementação da funcionalidade de geração de logs é realizada pela LogAuditoriaServiceImpl:

@Service("LogAuditoriaService")
@Transactional
public class LogAuditoriaServiceImpl implements LogAuditoriaService {

    @Autowired
    ILogAuditoriaRepository logAuditoriaRepository;
  
  [...]
  
}

As gravações de log são realizadas manualmente através da chamada do método gravaLogAuditoria(args), indicando, para cada operação, uma string contendo a operação que foi realizada. Assim como neste exemplo, a funcionalidade na AverbacaoServico de Edição de uma Averbação  que chama a gravação (linha 9) de Logs para esta ação informando os devidos dados.

// QUITAR / SUSPENDER
        if(operacao.equals("Quitar") || operacao.equals("Suspender")) {
            // Altera o Status
            operacao = operacao.equals("Quitar") ? "Quitada" : "Suspensa";
            averbacaoHistoricoReserva.setDesHistorico("Averbação " + operacao +
                    ": " + entidade.getMotivo());
            repositorio.updateStatus(entidade.getCodAverbacao(),
                                     entidade.getIndStatus());
            logAuditoriaServiceImpl.gravaLogAuditoria(operacao,
                    "AVERBAÇÃO -> GESTÃO ",
                    super.getFuncionarioLogin(),
                    "Cód Averbação: " + entidade.getCodAverbacao() +
                    " , Matricula: " + entidade.getNumMatricula() +
                    " , Motivo: " + entidade.getMotivo() +
                    " , Status: " + entidade.getIndStatus());
        }

Desta forma é possível constatar para cada funcionalidade que se queira registrar os logs devem ser realizadas manualmente, informando todos os dados necessários.

Observações:

Constata-se que será necessário um card específico por operação, já que cada chamada será diferente da outra.

3.2 SOLUÇÃO

Fora solicitado que a geração de logs contenham as seguintes informações (VING-665):

Informações necessárias:
- IP
- DATA e HORA
- CPF do Servidor/CNPJ do funcionário
- String
Ter o registro de toda movimentação, registro de quem fez a baixa de averbações manuais, fechamento, acesso ao sistema, qualquer exclusão, criação de cargo, cadastro de servidor(matricula), e verbas.

Como já mencionado anteriormente, será necessário, na parte do PO do projeto que solicite, para cada operação, um card específico e individual.

3.2.1 Preocupações e soluções 

1. No presente momento a geração de logs não apresenta pleno funcionamento, logo a reabiltaçreabilitação desta funcionalidade será a prioridade.
   
   Este trabalho será realizado juntamente com alguns memnbros da equipe que dava manutenção neste sistema anteriormente.
   
   
2. Devido listagem de informações conter o IP da máquina do usuário, a princípio fora detectado que seria necessário realizar modificações, tanto no front-end, quanto na back-end da aplicação - o que aumentaria a complexidade, o tempo e o volume de alterações no sistema para que seja entregue.
   
   Porém, após a realização de pesquisas e testes no código, foi possível obter o IP da requisição (da máquina do usuário) através do código a seguir. Desta forma estima-se que não será mais necessário realizar alterações no front-end da aplicação, restringindo as alterações apenas ao back-end.
   

   HttpServletRequest request = ((ServletRequestAttributes) RequestContextHolder.currentRequestAttributes()).getRequest();
   String ip = request.getRemoteAddr();

   
   

3.2 IMPLEMENTAÇÃO E HISTÓRIAS DE USUÁRIOS