ERP 2.50:Functional Documentation/Alerts/pt
| Languages: |
English | Português | Translate this article... |
Contents |
Introdução
Alertas são o meio para o Openbravo ERP informar aos usuários virtualmente sobre qualquer evento que acontece no sistema quando o Administrador definiu uma regra para mostrá-lo.
O fluxo de trabalho para os alertas é o seguinte:
- O Administrador cria regras de alerta, que inclui uma cláusula sql definindo o evento que vai ser monitorado e os receptores dos alertas.
- Um processo em segundo plano está permanentemente verificando se as condições definidas em cada uma das regras de alerta retorna alguma linha, neste caso uma nova instância de alerta será criada para cada uma das linhas retornadas.
Há um planejamento para aumentar as funcionalidades dos alertas com o projeto Alertas Intrusivos.
Componentes
Regras de Alerta
Regras de Alerta são as definições dos alertas, cada instância de alerta é gerada por uma destas regras.
As principais informações que uma regra de alerta contém é:
SQL
Os processos em segundo plano vão executar esta cláusula SQL, para cada linha retornada, uma nova instância de alerta será criada com os valores obtidos.
Ex.: Se queremos saber quais parceiros alcançaram seu limite de crédito, nós teremos que criar um SQL que retorne uma linha para cada um destes parceiros.
Esta cláusula SQL precisa retornar os seguintes campos (que deverão caber nos campos da tabela de Instâncias de Alerta):
- referencekey_id: É o identificador do registro que vai disparar o alerta. Ex.: No exemplo anterior, o campo referencekey_id seria o partner_id. Não é possível haver mais que um instância ativa com o mesmo referencekey para a mesma regra de alerta. Este campo habilita instâncias de alerta navegáveis, pois seria a chave primária do registro que queremos navegar na aba definida (veja abaixo).
- record_id: Este é um identificador amigável. Ex.: no exemplo anterior este registro identificador porderia ser o nome do parceiro de negócios.
- description: Uma descrição para a instância do Alerta.
- isActive: Somente instâncias ativas serão consideradas, então usualmente deveria estar sempre como 'Y'.
- ad_role_id, ad_user_id, m_warehouse_id: Os campos Regra, usuário e armazém podem ser usados como cláusula de filtro.
- ad_org_id, ad_client_id , created, createdBy, updated, updatedBy: Estes campos serão usados para propósitos de auditoria.
Cláusulas de Filtro
Esta cláusula é uma cláusula where que será aplicada a todas as instâncias de alerta existentes, no caso das cláusulas não serem cumpridas os alertas não serão exibidos.
O propósito desta cláusula é ter a capacidade de considerar variáveis de sessão para saber se uma instância de alerta será mostrada ou não. Por exemplo, usando filtros você pode exibir um alerta somente se o usuário fez login para um armazém específico (Ex.: O armazém inserido no campo m_warehouse_id na instância do alerta).
Receptores
Receptores de Alerta determinam quem está habilitado para ver instâncias de alerta.
Receptores estão definidos como papéis e usuários; o atributo papel é obrigatório enquanto o usuário é opcional. Se um usuário é especificado, qualquer usuário acessando a aplicação com o papel verá a instância de alerta da regra de alerta; de outro modo, a instância de alerta é exibida somente para o usuário conectado com o específico papel.
Adicionalmente, é possível marcar se um email será enviado para os receptores toda vez que uma instância de alerta é gerada.
Aba
Esta seção permite especificar uma guia (aba) para usar como alvo de navegação para a instância de alerta. A navegação usará o campo referencekey como chave primária do registro a ser navegado.
Por exemplo, se sua regra de alerta retorna parceiros de negócio com limite de crédito excedido você pode especificar aqui a aba "Parceiro de Negócios" para o receptor de alerta poder navegar diretamente nesta janela, onde o Parceiro de Negócios que dispara a regra é automaticamente recuperado.
Processos em Segundo Plano
Um processo em segundo plano é executado permanentemente para verificar regras de alerta; ele cria novas instâncias de alerta sempre que uma cláusula SQL definida na regra retorna ao memos um registro.
Este processo funciona da seguinte forma:
- Para cada regra de alerta ativa, a cláusula SQL é executada.
- Para cada linha retornada pela consulta, uma nova instância de alerta é criada, caso não haja qualquer instância de alerta ativa para esta regra com o mesmo valor de chave de referência. Se qualquer dos receptores da regra é marcado para receber e-mail, um novo email é enviado com é enviado com todas as novas instâncias de alerta.
- Finalmente, todas as instâncias de alerta para esta regra de alerta, tendo uma chave de referência que não retorne mais nenhuma linha será marcada como inativa.
Instâncias de Alerta
Instâncias de Alerta são os alertas atuais. Eles são os que os usuários finais estão habilitados para ver e gerenciar. Eles são criados por um processo em segundo plano e são dependentes de uma regra de alerta.
Há uma visualização de processo que verifica se qualquer das ativas e não fixas instâncias de alerta tem como receptor o usuário/papel que iniciou uma sessão e se encaixou na cláusula de filtro. Todas as instãncias com estas condições serão contabilizadas e exibidas para o usuário.
Problemas Conhecidos
- Como alertas usam processos em segundo plano e os escreve em um arquivo de log na pasta principal do Tomcat (tomcat/webapps/yourContext/WEB-INF/ por padrão) usuários tomcat precisam ter permissão de escrita nesta pasta, de outro modo nenhuma nova instância de alerta será criada.