Runtime

Eventos de sistema

RT.FAQ-11221
A T2 tem 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


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.

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 que possamos "escutar" a ocorrência de um determinado evento, temos que 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 temos que fazer um registro nos 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 "Preferencias de runtime" registradas diretamente abaixo do sistema usando um nome global no lugar do nome da propriedade.

Opção 1:
Criar uma preferencia com nome qualquer + .EVENT_LISTENER e no conteúdo incluir linhas com o nome dos eventos + ":" + o nome do elemento a ser notificado. Ex:
Preferenciia APPREF.CAPTURA_LOGIN.EVENT_LISTENER
Valor: 
RT.PRE_LOGIN : APPREF.PEDIDOS
RT.PRE_LOGOUT: APPREF.PEDIDOS

Opção 2 (depreciado):
Criar uma preferencia com o nome global da entidade + .EVENT_LISTENER e no valor, incluir os eventos que devem ser ouvidos. Ex:
Preferencia 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 preferencia do tipo .LIMIT seja alterada! Isso poderia ser 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("ronnie@prd.inf.br",
                "ronnie@prd.inf.br",
                "Preferencia " + 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 preferencia não será gravada.

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.
Veja a documentação desta preferencia para maiores detalhes.