Soluções de auditoria podem ser encontradas em todas as linguagens através de frameworks e tutoriais que solucionam um determinado contexto. Assegurar um modelo comum tem sua parcela de dificuldade mas, de modo geral, é possível adquirir muita vantagem nesse ponto.

Um tempo atrás, me deparei com uma situação para auditar tudo o que acontece na camada de persistência, com o objetivo de gerenciar todo o conjunto de modificações de objeto que continham valores monetários. Os gerentes queriam saber a procedência de alteração de uma série de elementos que foram armazenados, inclusive quem os armazenou e qual foi a URL executada para remove-lo. Nesse caso, foi necessário desenvolver uma série de listeners para realizar a leitura de elementos contidos na sessão e armazena-los. Porém, quando se trata de aplicações corporativas, normalmente estão espalhadas em outros servidores, normalmente provendo serviços que outras aplicações acessam. O maior problema disso tudo é que armazenar o histórico de um objeto em uma outra base de dados, normalmente com o auxílio desses serviços (seja EJB, Web Services ou RESt) é um trabalho a mais, gerando um deley desnecessário para a aplicação. Em muitos casos, o armazenamento dos logs no schema utilizado pela aplicação minimizaria consideravelmente o fator tempo utilizado para o complemento da transação .

No mundo Java, o framewok predominante é o Hibernate. É muito difícil projetar um aplicação que não utilize o framework para mapeamento objeto-relacional da linguagem Java. É um excelente framework, na minha opinião, o mais bem sucedido quando se trata de funcionalidades providas por frameworks. A auditoria realizada com esse fremework pode ser feita utilizando listeners e que executam call-backs dispondo de eventos que podem executar ações antes ou depois da persistência de objetos. Ainda assim, a dificuldade e o tempo de desenvolvimento de uma solução mais viável e rápida fica a desejar.  Dessa forma, para preencher a lacuna, utilizaríamos recursos de aspectos do Spring para uma coisa mais elaborada. Manter uma solução como essa, em certos pontos, despadronizada e mal documentada, se tornaria um caos. Normalmente tratativas reais no ambiente onde se desenvolve o software.

Hoje em dia, acompanhado desse framework está o Envers, que é um framework de auditoria nativo do Hibernate, tanto que ele vem junto com o pacote distribuído no site do produto.

Resolvi testar o Envers em uma aplicação piloto para conhecer as funcionalidades de auditoria provida por esse framework. Logo de primeira, fiquei impressionado com a facilidades de integração com o Hibernate. É só incluir a lib e utilizar as anotações. Só isso e nada mais. Porém, o framework tem suas particularidades. Para cada entidade que deseja auditar é necessário incluir uma anotação, seja ela no atributo em questão ou no todo da classe para anotar todos os atributos. Após rodar o projeto, no momento da atualização do schema, será criada a tabela de auditoria como o complemento do nome “AUD”.

 Em objeto de classe que for anotada com @Audited, será gerada uma estrutura semelhando ao desenho acima. As tabelas “AUD” armazenam os atributos da classe que foram anotadas.

Nem sempre o que o framework oferece é o suficiente para executar por completo nossos requisitos de negócio. De acordo com a configuração default, foi oferecido ao desenvolvedor registrar as modificações dos objetos com revisões. Porém, em algumas situações, talvez necessitamos de um conjunto de informações mais rico. Ou melhor, precisamos registrar a data que o objeto foi modificado, por quem e qual o caminho que o usuário percorreu até concluir o conjunto de funcionalidades.

Para isso, será necessário a inclusão de dois elemento para que possam trabalhar em conjunto. A anotação @RevisionEntity e o listener RevisionListener.

A anotação permite escolher uma classe que representará uma entidade que irá conter os atributos a mais necessários para serem armazenados. O listener incluirá de escutar a modificação realizada no objeto e executar um método para executar alguma programação que, na maioria das vezes, seria uma extração de informação de algum objeto que está na sessão ou de um método de armazenamento temporário de objetos. Isso ficaria mais ou menos assim:

A cada modificação realizada o método newRevision é executado, podendo aí utilizar do mecanismo para preencher os campos da entidade auxiliar.

Esses são apenas recursos que considero o mais básico possível que uma aplicação de médio porte pode ter. O Envers possui mais recursos para armazenamento, cujo conteúdo está disponível na documentação do produto.

As consultas são um caso a parte. O Envers utiliza o conceito de revisão, uma ideia bem semelhante ao Subversion, fazendo com que cada modificação realizada no objeto gere uma nova revisão. A revisão é armazenada juntamente com os dados que foram modificados, inclusive o seu tipo de modificação que foi realizada.

A ideia dos tipos de transação são bem claros quando olhamos o dados armazenados. No teste que eu fiz no MySQL podemos ver o campo REVTYPE. Onde é armazenado os tipos de modificações realizadas no objeto:

Um objeto persistente, para o hibernate, é uma entidade que contem relacionamentos com outras entidades que juntos formam uma relação. Em diversas situações, na maioria das vezes no mundo real, essa relação se torna complexa quando existe a necessidade de relação com outras entidades, somado com o numero enorme de dados relacionados. Existem várias formas de obter essas esses dados relacionados, uns que permitem obter todo o conjunto de dados relacionados ao carregar o objeto (eager), outro no momento que a relação é obtida (lazy). Outras alternativas podem ser utilizadas em conjunto, como, as consultas nomeadas atreladas ao carregamento do objeto. Porém, apenas obter a lista de desses informações não é suficiente para a aplicação, fazendo com que o desenvolvedor utiliza consultas mais elaboradas com HQL ou criteria.

A forma como o framework monta as consultas é na maioria das vezes genérica e pouco intuitiva, fazendo com que o desenvolvedor opte por utilizar o SQL nativo, ou portar a consulta para uma Stored Procedure para construir uma consulta mais elaborada. É uma estratégia plausível quando a aplicação necessita de desempenho mas, isso tiraria a principal vantagem do framework; o acesso as relações que são representadas pelo relacionamento entre os objetos. Existe uma maneira muito simples de executar uma consulta SQL mantendo o relacionamento entre os objetos.

Para o framework, os objetos persistentes são de extrema importância. Quando o framework é executado pela primeira vez, ele adiciona uma série de funcionalidade nos objetos persistentes que permite realizar as operações em suas relações. A maneira com que o framework realiza essa tarefa é pela Instrumentação de código. A instrumentação nada mais de uma técnica de incluir alterações do código do programa mesmo após a sua compilação. O conceito pode ser semelhante com Reflexão e AOP, mas existem particularidades que tornam os conceitos bem distintos. Por ser um assunto muito pesquisado e com referencias em abundância, é um assunto para ser tratado outra hora. No hibernate, isso é feito através da lib ASM, que é um extenso conjunto de utilidade que permitem a plicar esse conceito nas classes escritas em linhagem Java.

Bom, para que o framework compreenda que o resultado de uma consulta SQL possa ser vinculado a um objeto é necessário que o retorno corresponda aos atributos do objeto, sendo que o objeto possa ser reconhcido pelo motor de consulta. Ex:


List<ClasseQualquer> planos = new ArrayList<ClasseQualquer>();
String queryStr = queryUtils.findValue(nome_da_query); //obtem a string de consulta
Query query = entityManager.createNativeQuery(queryStr, ClasseQualquer.class);

Obtendo um objeto Query configurado como acima, é possível realizar operações como essas abaixo:


List dados = instanciaObjetoQualquer.getDadosParticulares();

Esse simples macete pode ajudar bastente para obter objetos, que necessitem manter o acesso aos objetos relacionados, através de consultas bem elaboradas e com o desempenho do SQL.

Alem das funcionalidades do contexto de persistência também podemos contar com as funcionalidades extras que foram desenvolvidas pelo time de desenvolvimento, hoje pertencente a JBoss. Estou falando do pacote hibernate-tools.jar, contido no plugin feito para o eclipse, com o intuito de auxiliar no processo de configuração, mapeamento, importação de schemas e mecanismo de interpretação e execução de HQL. O link para download do plugin encontra-se aqui.

Tive a necessidade de fazer com que todo o schema fosse exportado para o banco de dados ao executar uma simples task do Ant. Funcionalidade que facilitaria muito a vida da equipe ao modificar o mapeamento das entidades do projeto, sendo apenas necessário executar a task para exportar as modificações para o SGBD. Para isso, desenvolvi uma task personalizada para solucionar esse problema. A task funcionava bem, mas chegou um ponto que não nos atendia. Portanto, vi que uma boa alternativa seria utilizar as tasks do hibernate-tools.

O pacote hibernate-tools.jar contem um conjunto de tasks que permitem a execução de procedimentos básicos de persistência através de simples tasks do Ant. As tasks são variadas, portanto é possível utiliza-las para; exportar schemas, gerar os inserts do mapeamento em um arquivo .sql, gerar os hbm.xml (se não tiver utilizando anotações) entre outras coisas. Mais um detalhe: o pacote hibernate-tools.jar é completamente independente do plugin.

A configuração para utilizar as tasks a princípio é simples, porém levei um tempo para acertar, já que meu projeto estava mal configurado e gastei muito tempo para descobrir o problema. Vou levar em conta que o seu projeto está devidamente configurado e fazendo todas as operações básicas (insert, update e delete) no banco de dados.

Para uma simples exportação do schema para o banco de dados, a primeira coisa que você deve fazer é adicionar o pacote hibernate-tools.jar no classpath do projeto. Após isso é necessário incluir uma referencia a classe que representa a task. Nesse caso, assim como está abaixo:

<taskdef name="hibernatetool" classname="org.hibernate.tool.ant.HibernateToolTask" classpathref="path.lib" />

Após isso, é necessário incluir um target que fará todo o trabalho sujo. Nessa target deve conter, dentro do <hibernatetool>, no mínimo as tasks <annotationconfiguration/> e <hbm2ddl/> para fazer o processo de configuração e a exportação de todas as configurações de mapeamento incluídas nas classes. Vamos ver o detalhe abaixo:


<target name="generate" depends="compile">
<hibernatetool destdir="${dir.build}/generated">
<classpath>
<path location="${dir.out.classes}"></path>
</classpath>
<annotationconfiguration propertyfile="${dir.out.classes}/hibernate.properties"  configurationfile="${dir.out.classes}/hibernate.cfg.xml" />
<hbm2ddl drop="true" create="true" export="true" outputfilename="../schema.sql" delimiter=";" format="true" />
<hbm2dao />
</hibernatetool>
</target>

Reparem que é necessário ter os .class incluídos no <classpath/> como descrito acima, pois é daí que vem todo o mapeamento dos objetos. A propriedade <annotationconfiguration/> representa as configurações do seu SGBD (hibernate.properties) e das classes persistentes (hibernate.cfg.xml). Claro que o arquivo cfg.xml pode conter as configurações do SGBD mas eu achei melhor separá-los.

A task <hbm2dll/> é o elemento principal do processo de exportação do schema. Nela é possível definir se, ao exportar o schema, irá dropar as tabelas existentes e criar uma nova estrutura e além do mais irá criar um arquivo .sql contendo tudo o que foi feito no banco.

Adicionei a task <hbm2dao/> apenas para mostrar o DAO gerado conforme as entidades geradas. Acredito que isso seja útil para os projetos que não utilizam o suporte aos DAOs do Hibernate do Spring.

Bom pessoal, esse foi um processo que me atendeu perfeitamente nos projetos que desenvolvo, portanto, segue a dica para os leitores. Chega de ficar mexendo nas propriedades hibernate.hbm2ddl.auto create-drop e escrever tarks personalizadas para essa tarefa.

[]s