Administração do sistema

Eventos de sistema

RT.FAQ-11221
A T2 possui um gerenciador de eventos que monitora a ocorrência de um grande número de eventos.
O grande objetivo do gerenciador de eventos é de notificar todos os elementos interessados de que um determinado evento ocorreu, permitindo que se dispare outros procedimentos (que não fazem parte do set padrão de regras para aquele evento) ou até que impeça que aquela operação seja executada. A notificação dos elementos é realizada através do disparo de um procedimento previamente programado. Este procedimento recebe a identificação do evento e o objeto que está originando-o.
Este processo poderá interagir com o objeto original e até mesmo publicar uma exceção impedindo que a ação que está gerando o evento seja completada.

Cada evento que ocorre no sistema tem um nome de identificação compatível com o nome global no Telescope.

Eventos de entidades

Todas as operações das entidades geram eventos de PRE e POS.
O nome do evento será formado pelo nome global da entidade seguido de PRE/POS e do nome da operação.
Exemplos:
Neste caso, o objeto do evento é a própria entidade que está fazendo a operação.

Replicação

Logo após a execução de um DML de uma tabela específica, o sistema notifica a execução com um evento de POS_REPLICATE no formato:
O objeto enviado no evento é da classe br.​com.​telescope.​replicator.DmlLog

Eventos de bloco

Todas as operações do bloco geram vários eventos de PRE e POS.
O nome do evento será formado pelo nome global da entidade seguido de PRE/POS e do nome da operação.
Exemplos:
Neste caso, o objeto do evento é o bloco que está fazendo a operação.

Módulos de blocos

O evento PRE_DISPLAY dos blocos também pode ser chamado por event-listener.
Neste caso, o objeto do evento é o módulo. 
MEU_TESTE.EVENT_LISTENER = EMPEST.MOD_EMPR.PRE_DISPLAY:REMOVER_GUIA

Código: 
if (...condicao...) {
    ctx.getEvent().getObject().removeGuide("ESTAB");
}

Operações de login

Toda a vez que um usuário faz um login ou logou no sistema, os seguintes eventos são registrados.

O objeto relacionado com este evento é o objeto User.

Envio de e-mails


Em ambos os casos, o objeto anexado ao avento é do tipo 
br.com.telescope.util.MailSender

No caso do erro, pode-se recuperar a exceção através do método getException() do MailSender.

Para gerar um LOG dos e-mails enviados, basta criar a preferencia abaixo:
Preferência: 
RTLOG.EVENT_LISTENER
Valor: 
RT.SMTP.SEND_MAIL_SUCCESS_EVENT : RTLOG.LOGS
RT.SMTP.SEND_MAIL_EXCEPTION_EVENT : RTLOG.LOGS

Operações de chat

Toda vez que alguém envia uma mensagem de chat, o seguinte evento é gerado:

Operações de sessão (ainda não implementado)

Toda vez que alguém se conecta ao sistema (mesmo sem fazer login). Ou quando a sessão é expirada.

O objeto relacionado com este evento é o objeto Session (da T2).

Operações do servidor (ainda não implementado)



O objeto relacionado com este evento é nulo.

Implementação de Listeners

Para "escutar" a ocorrência de um determinado evento, é preciso implementar um EVENT_LISTENER. A forma mais fácil de se criar um EVENT_LISTENER no Telescope é criando um método publico chamado NOTIFY em uma entidade. Este método deve receber dois parâmetros: 
notify ( String evento, Object objeto )

Registro de Listeners para os eventos

Para que o gerenciador de eventos saiba quais os listeners que devem ser notificados em um determinado evento é preciso definir os parâmetros de configuração do sistema.

O gerenciador de eventos "lê" todos os parâmetros de configuração procurando por parâmetros que encerrem com ".EVENT_LISTENER". Cada parâmetro de configuração pode registrar um ou mais listeners em um ou mais eventos.

Em breve, este registro poderá ser registrado no Telescope de forma "controlada" na guia de eventos do sistema. Por enquanto ele deve ser realizado através de "Preferências de runtime" registradas diretamente abaixo do sistema usando um nome global no lugar do nome da propriedade.

Opção 1

Criar uma preferência com nome qualquer + .EVENT_LISTENER e no conteúdo incluir linhas com o nome dos eventos + ":" + o nome do elemento a ser notificado. Ex:
Preferência APPREF.CAPTURA_LOGIN.EVENT_LISTENER
Valor: 
RT.PRE_LOGIN : APPREF.PEDIDOS
RT.PRE_LOGOUT: APPREF.PEDIDOS

Nos casos onde existem vários eventos que disparam a mesma operação, existe a alternativa de incluir uma linha para a ação seguida de várias linhas com todos os eventos que devem dispará-las: 
: APPREF.PEDIDOS
RT.PRE_LOGIN 
RT.PRE_LOGOUT

Opção 2 (depreciado)

Criar uma preferência com o nome global da entidade + .EVENT_LISTENER e no valor incluir os eventos que devem ser ouvidos. Ex:
Preferência APPREF.PEDIDOS.EVENT_LISTENER
Valor: 
RTPREF.PREFERENCIAS.POS_UPDATE
RTPREF.PREFERENCIAS.POS_INSERT
RTPREF.PREFERENCIAS.POS_DELETE

Eventos customizados por script

Também é possível criar scripts para serem executados em determinados eventos. Isso pode ser especialmente útil para implementar algumas customizações específicas de clientes. Para isso, basta criar um script (Groovy, por exemplo) e configurar o evento para disparar este script.

Digamos, por exemplo, que um cliente queira ser notificado por e-mail toda vez que uma preferência do tipo .LIMIT seja alterada! Isso pode ser configurado da seguinte forma:

1) Criar um script Groovy utilizando a interface CAD_OPERACOES_CUSTOM com um nome qualquer ("ROTINA_CUSTOM", por exemplo) e com o seguinte script: 
pref = ctx.getEvent().getObject();

if (pref.valueOfPreferencia().endsWith(".LIMIT") && pref.isValorModified()) {
   ctx.sendMail("suporte@prd.inf.br",
                "suporte@prd.inf.br",
                "Preferência " + pref.valueOfPreferencia() + " alterada!",
                "VALOR ALTERADO DE:\n" + pref.oldValor() + "\nPARA:\n" + pref.valueOfValor()
               );
}

2) Configurar um listener indicando que o evento RTPREF.PREFERENCIAS.POS_UPDATE dispare o script acima. Isso deve ser feito criando um parâmetro de configuração. O nome do parâmetro pode ser qualquer um, mas PRECISA terminar com ".EVENT_LISTENER". O valor do parâmetro deverá ser: 
RTPREF.PREFERENCIAS.POS_UPDATE : ROTINA_CUSTOM

3) Por questões óbvias de performance, os scripts configurados como EventListeners, são mantidos em memória. Isso significa que alterar o script na interface CAD_OPERACOES_CUSTOM não terá efeito até que o gerenciador de eventos seja reconfigurado. Isso pode ser feito das seguintes formas: 
EventManager.getInstance().init();

Atenção
A execução do evento faz parte da transação. Isso significa que qualquer erro que ocorra nos EventListeners irá fazer com que a transação seja abortada.
No exemplo acima, por exemplo, se ocorrer um erro no envio do e-mail a transação será interrompida e a preferência não será gravada.

Eventos customizados por script para interfaces

Segue os mesmos passos do exemplo acima, porém o valor da preferência deve ser como, p.ex.: 
CIDADE.CAD_CIDADES.VIEW.POS_DISPLAY : ROTINA_CUSTOM

Para incluir eventos de ON_ACTIONS (botões) segue o mesmo exemplo: 
CIDADE.CAD_CIDADES.VIEW.ON_ACTION : ALGUMA AÇÃO

Para maiores detalhes em como incluir ações customizadas, ver Ações customizadas disparadas a partir de blocos de interface.

Geração de LOGs na execução dos eventos

Para configurar a geração de LOGs do sistema, deve-se configurar a preferência RT.LOG.LISTENER_EVENTS.
Ver a documentação desta preferência para maiores detalhes.

Uso do SqlScriptEngine em eventos

Exemplo: Não permitir cadastrar uma preferência cujo nome seja menor que 5 caracteres. 
error 'Não pode cadastrar preferência 000'
where '${ctx.getEvent().getObject().valueOfPreferencia()}' = '000';

Mensagens de advertência

Caso o event-listener esteja configurado de forma a chamar um método que não existe, o sistema irá gerar uma mensagem de advertência semelhante com a mensagem abaixo:
Atenção
O listener RTPREF.PREFERENCIAS.POS_UPDATE : ROTINA_CUSTOM configurado na preferência ABC.EVENT_LISTENER é inválido e foi ignorado!
É possível suprimir esta mensagem alterando a preferência ABC.EVENT_LISTENER.SUPPRESS_WARNINGS para "S".

Isso pode ocorrer em casos como, por exemplo, no caso de bases replicadas com versões diferentes onde o método do listener existe apenas em uma das versões.

Monitoramento

Para identificar quais eventos estão sendo ouvidos no sistema, pode-se utilizar a interface CFG_EVENT_MANAGER.


Ver também: