Objetivo
Aplicar o recurso de Embedded Audit Trail no banco de dados do sistema Protheus.
Definição da Regra de Negócio
O Embedded Audit Trail é um recurso de auditoria de banco de dados (Audit Trail) desenvolvido para o sistema Protheus. Suas premissas são:
- Alto desempenho
- Facilidade de instalação e configuração
- Simplicidade de operação
- Segurança
Para que o recurso seja ativado, deve-se escolher a abrangência de seu funcionamento sobre a instalação do sistema Protheus.
Por abrangência entendem-se as entidades em que o Audit Trail auditará:
- Grupo de empresas
- Tabelas
- Campos
Essa configuração é efetuada pela rotina do Aplicador. Através de um mecanismo de exceção e regra, o administrador poderá facilmente escolher as entidades que deseja auditar, ou ao contrário, as entidades que não deseja editar. Essa característica facilita o cadastramento por diminuir a quantidade de regras que é necessário informar.
Existem três níveis de configuração:
- Nível superior: nesse nível são informados os grupos de empresas
- Nível intermediário: nesse nível são informadas as tabelas.
- Nível inferior: nesse nível são informados os campos.
Cada nível de configuração possui, além da entidade informada, o escopo e a operação de aplicação.
O escopo de aplicação possui os tipos básicos REGRA e EXCEÇÃO. Quando um item possui o escopo "regra", a auditoria será aplicada a ele.
O escopo de um nível não pode ser igual ao escopo do nível acima ou abaixo, quando na mesma área de abrangência. Exemplo: foi definido um item no nível superior com o escopo REGRA para o grupo de empresas 01. No nível intermediário, vinculado ao grupo 01, foi definido o item com escopo REGRA para a tabela SA1. Trata-se de uma incoerência, pois ao definirmos que vamos auditar o grupo de empresas 01, significa que todas as tabelas e campos estão incluídos. Logo, não é preciso nem correto informar o nível intermediário.
Por outro lado, se for desejado auditar todas as tabelas, exceto a tabela de prefixo SA1, deve-se incluir um item do nível intermediário para SA1 com o escopo EXCEÇÃO.
Em relação ao nível inferior, o mesmo ocorre. O item (campo) apontado no nível inferior deve possuir escopo diferente do informado no nível intermediário, caso este campo pertença à tabela informada neste nível. Se for usado o exemplo acima, onde foi usado o escopo REGRA para o grupo 01, escopo EXCEÇÃO para a tabela SA1, pode-se informar um item REGRA para o campo A1_COD, por exemplo.
Além do escopo, deve-se informar qual a operação de banco de dados que se deseja auditar. As operações básicas de banco de dados são três: INCLUSÃO, ALTERAÇÃO e EXCLUSÃO.
No campo operação, existem sete opções que cobrem todas as combinações entre as três operações. São elas:
1=Inclusão
2=Alteração
3=Exclusão
4=Inclusão e Alteração
5=Inclusão e Exclusão
6=Alteração e Exclusão
7=Inclusão, Alteração e Exclusão
As operações acima devem ser informadas apenas quando o escopo for REGRA. Quando o escopo for diferente de REGRA, não faz sentido informar uma operação, pois nada será auditado. Nesse caso deverá ser informada a operação "0=Não se aplica".
Observação: quanto menor a abrangência de entidades que se deseja auditar (tabelas e campos) e quanto menos operações desejadas (incluir, alterar ou excluir), menor será o impacto sobre o desempenho do sistema após a aplicação do Embedded Audit Trail. Uma análise cuidadosa do que é necessário auditar resultará em um desempenho melhor do produto.
Não recomendamos a auditoria de todos os campos para operação de inclusão em tabelas de movimentos, principalmente das tabelas que possuem grande quantidade de campos. Como a operação de inclusão registra todos os campos sujeitos à auditoria, o impacto na performance pode ser significativo.
Para a garantia de integridade, caso seja inserido um registro no início de uma transação (BEGIN TRANSACTION) e for solicitado o número do registro ( RECNO() ), o DBACCESS fará a inclusão do registro marcado como excluído (DELETADO) e recuperará (RECUPERADO) em seguida, esse é um comportamento esperado da ferramenta, não se tratando de um erro.
Remoção auditoria
A definição de um grupo de empresas como Exceção sem nenhum outro atributo de Regra para as tabelas e para os campos implica na remoção da auditoria para a empresa.
Uma vez definido uma empresa para auditora, para a remoção da auditoria dessa empresa deve-se alterar a configuração da empresa para Exceção e remover qualquer referencia de tabela(s) para essa empresa.
Coluna "Campos Inseridos"
A coluna campos inseridos indica como a auditoria de inclusão se comportará com os campos que não sofreram alterações.
Quando informado "1=Todos os campos" todos os campos indicados para tabela serão auditados não importando com o valor do conteúdo registrado na tabela.
Quando informado "2=Valores preenchidos" apenas campos que são inseridos com os seus diferentes de vazio e 0 serão auditados.
Exemplo:
Uma tabela onde possuam os campos CODIGO, NOME, VALOR. Em uma inclusão onde seja informado apenas o campo CODIGO e a auditoria esteja configurado para a TABELA toda e o campo "Campos inseridos" esteja como 2, apenas o campo CODIGO será auditado, pois o campo NOME como padrão é um texto vazio e o campo VALOR é um número com o valor 0.
Tempo de histórico mantido
É possível habilitar a limpeza das tabelas auditadas por período determinado pela coluna "Tempo de histórico mantido", sendo "0=Sempre manter" até "4=Doze meses".
Será executado uma vez por dia a rotina em job no momento do primeiro acesso ao sistema no dia. Todos os registros das tabelas de log que estiverem no período inferior ao informado no campo serão eliminados.
Exemplo:
Um registro de log da tabela TESTE que foi registrado a 12 meses atrás. Caso seja ativado o parâmetro para manter os o histórico dos últimos 3 meses (campo "Tempo de histórico mantido", sendo "3=Três meses" ), ao acessar o sistema no dia seguinte o registro será eliminado.
Coluna "Campos deletados"
Na auditoria de exclusão é possível selecionar se todos os campos do registro excluído que devem ser auditados, selecionado na coluna "Campos deletados" com o valor "1=Todos os campos" ou apenas os campos que foram selecionados para a tabela com a coluna "Campos deletados" com o valor "2=Apenas selecionados"
O escopo "LIGAÇÃO"
O escopo LIGAÇÃO é um tipo especial existente apenas no nível intermediário (tabelas). Ele existe para contemplar a seguinte situação: possuímos um escopo no nível de empresas, não desejamos alterar o escopo no nível tabelas, mas desejamos um escopo diferente no nível de campos.
Nesse caso, deve existir um item no nível de tabelas para conectar os dois níveis.
Considere o seguinte exemplo: Deseja-se auditar apenas um campo do grupo de empresas 01. Vamos escolher o campo A1_RISCO (risco do cliente, tabela SA1).
- Começaremos cadastrando o nível empresas. Colocaremos o grupo de empresas 01 e o escopo EXCEÇÃO, pois o desejo é não auditar informação alguma.
- Posteriormente cadastraremos o nível de tabelas. Precisamos lançar a tabela SA1, pois o campo que vamos auditar pertence a esta tabela. Se informarmos EXCEÇÃO, violaremos a regra de não ter duplicidade de escopos entre níveis. Se informarmos REGRA, auditaremos todos os campos da tabela (o que não desejamos). A solução é informar o escopo LIGAÇÃO, pois o que queremos é apenas uma ponte para o nível de campos.
- No nível de campos, informaremos o campo A1_RISCO utilizando o escopo REGRA.
Regras de integridade
- Não é possível repetir o escopo entre níveis em registros vinculados.
- Não é permitido informar atributos (grupos de empresas, tabelas e campos) repetidos em um mesmo nível.
Casos de Uso
Caso exemplo:
Deseja-se auditar todas as tabelas grupo de empresas 01, para todas as operações, exceto as tabelas SCJ, SCK, SC5 e SC6 (orçamento e pedidos de vendas).
No entanto deseja-se auditar os campos C5_VEND1, C5_COMIS1, C5_VEND2, C5_COMIS2 (vendedor e comissão do primeiro e segundo vendedores do pedido de vendas), também para todas as operações.
Para tanto, deve-se informar:
- No nível de empresas, o grupo de empresas '01' com o escopo REGRA e operação "incluir, alterar e excluir".
- No nível de tabelas, as tabelas SCJ, SCK, SC5 e SC6 com o escopo EXCEÇÃO e operação "não se aplica"
- No nível de campos, os campos C5_VEND1, C5_COMIS1, C5_VEND2, C5_COMIS2 com o escopo REGRA e operação "incluir, alterar e excluir".
Após a confirmação, o Audit Trail aplicará a regra informada no banco de dados. As tabelas que já existem no banco de dados já terão a regra aplicada neste momento. As tabelas que ainda não existem, quando criadas (mesmo que sob demanda), também utilizarão como base a regra cadastrada.
Melhoria na aplicação de triggers
Para a aplicação em massa foi utilizada a chamada de RPC com 10 threads ativas. Com isso, a aplicação das triggers não é mais interrompida caso alguma tabela não possa ser aplicada.
Tela de erro de aplicação
Melhoria: Passa a ser exibida tela de erro com a exibição da tabela e qual erro provocado no momento da aplicação.
Ao clicar 2 vezes na linha do erro, é exibido em detalhes: