Histórico da Página
...
Especificação de Requisitos
...
Projeto: Versão 12 – M12_FRM
...
Requisito: Embedded Audit Trail
...
Sub-Requisito: Aplicador
...
Tarefa: 02.05.02
...
País: All
...
Data Especificação: 15/01/2013
Objetivo
Rotinas Envolvidas |
|
| |
Rotina | Tipo de Operação | Opção de Menu |
|
CFGA710 | Inclusão | Protheus11>Configurador>Ambiente>Embed.Audit Trail |
|
Objetivo
Aplicar o recurso de Embedded Audit Trail no banco de dados do sistema Protheus.
Definição da Regra de Negócio
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
Âncora _GoBack _GoBack - 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 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.
O escopo "LIGAÇÃO"
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.
Protótipo de Tela
...
Regras de integridade
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.
...
o do Processo
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.
- Diagrama – Atividades
...
- Diagrama de Classes
...
- Diagrama de Entidade e Relacionamento
...
- Diagrama de Sequencia
...
Tabela: | XA4 | Descrição | Regras do aplicador |
Campo | Tipo |
| Tamanho |
|
|
| Descrição |
|
|
|
|
|
| Int. | Dec. |
|
| Resumida |
| Completa |
|
XA4_ITEM | C |
| 4 | 0 |
|
| Item |
| Item do grupo de empresas |
|
XA4_IDTAB | C |
| 4 | 0 |
|
| Item |
| Item da regra por tabela |
|
XA4_IDFLD | C |
| 4 | 0 |
|
| Item |
| Item da regra por campo |
|
XA4_ACCESS | C |
| 1 | 0 |
|
| Escopo |
| Escopo do item |
|
XA4_EMP | C | 2 |
|
| 0 | Empresa |
| Grupo de empresas |
| |
XA4_TABLE | C |
| 3 | 0 |
|
| Tabela |
| Tabela do item |
|
XA4_FIELD | C |
| 10 | 0 |
|
| Campo |
| Campo do item |
|
XA4_OPER | C |
| 1 | 0 |
|
| Operação |
| Operação |
|
...
Índices
...
...
...
Ordem
...
Chave
...
Nickname
...
1
...