Notificações são atualmente uma das melhores maneiras de interagir com os usuários. Seu uso vem se popularizando principalmente em sites e apps mobile, que utilizam push notifications para informar o usuário sobre algum acontecimento.

Uma das formas mais comuns de implementação desse tipo de recurso é o uso de rotinas que ficam varrendo tabelas para saber se existe alguma informação nova. O problema dessa abordagem é o custo computacional, pois novas requisições ao banco de dados são feitas com muita frequência. O Firebird, no entanto, possui um recurso chamado POST_EVENT que, em conjunto com o componente TFDEventAlerter da biblioteca FireDAC no Delphi, permite enviar notificações para a aplicação quando algum evento é disparado no banco de dados.

Push Notifications

Push Notifications são comumente encontradas em aplicações mobile e web e têm o propósito de enviar alertas aos usuários quando algum evento ocorre. Nesse formato, ao invés do cliente solicitar o conteúdo ao servidor por meio de requisições, é o servidor que envia uma notificação para o cliente, daí o nome "push", do inglês "empurrar".

Imagine, por exemplo, que sua aplicação precisa informar o usuário sobre uma nova nota fiscal que foi cadastrada, uma venda realizada ou a revisão de um conteúdo que ele aguardava. Ao utilizarmos notificações o usuário não precisará buscar por essas informações, pois elas chegarão até ele automaticamente.

Firebird e o POST_EVENT

POST_EVENT é um recurso do Firebird que permite notificar os clientes sobre mudanças de dados nos registros do banco. Sua implementação é bem simples, bastando adicionar a instrução POST_EVENT no trigger do evento desejado. Por exemplo, se desejar enviar um alerta para os usuários sempre que um registro for inserido em uma tabela, basta adicionar um trigger para o evento AFTER INSERT com o comando POST_EVENT ‘<NomeDoEvento>’ . Na Listagem 1 pode ser visto um exemplo de implementação de um trigger para a operação de INSERT.

Atente-se aqui ao nome do evento, pois ele será importante para que se possa determinar, na aplicação cliente, quais serão os eventos que o usuário irá monitorar.

Listagem 1. Instrução de criação de trigger no after insert

        CREATE TRIGGER ClienteAdicionado FOR Cliente
        ACTIVE AFTER INSERT POSITION 0
        AS
        BEGIN
        POST_EVENT 'Cliente_Cadastrado';
        END
        
  • Linha 1: criamos o trigger ClienteAdicionado para a tabela Cliente;
  • Linha 2: definimos que o trigger será disparado após a inserção de um novo registro (AFTER INSERT);
  • Linha 5: executamos a função POST_EVENT, passando um identificador (nome do evento) como parâmetro.

Monitorando eventos no Delphi

Para monitorar os eventos disparados pelo banco no Delphi, crie uma conexão com o Firebird em seu projeto, caso não exista, e adicione o componente TFDEventAlerter, ligando-o ao componente de conexão. Cada evento que se deseja monitorar deve ser adicionado a uma lista de monitoramento, que está disponível na propriedade Names do TFDEventAlerter. Neste exemplo temos apenas o exemplo Cliente_Cadastrado, que é o identificador do evento enviado pelo trigger visto anteriormente.

Em seguida, adicione um método para tratar o evento OnAlert do TFDEventAlert. OnAlert será disparado sempre que um evento cujo nome esteja na lista de Names do componente for disparado. Para saber qual evento está sendo recebido, utilize o parâmetro AEventName, como pode ser visto na Listagem 2. Isso permitirá executar ações específicas, a partir de condições, que definirão como deverá ocorrer a interação com o usuário para aquele evento específico.

Listagem 2. Testando o evento recebido no Delphi

 procedure TForm1.FDEventAlerterAlert(ASender: TFDCustomEventAlerter;
  const AEventName: String; const AArgument: Variant); 
 Begin
 	If (AEventName = 'Cliente_Cadastrado') then 
 		Begin
			//<Executa tratamento para novo cliente cadastrado>
			ShowMessage('Um novo cliente foi cadastrado');
  		End
 End; 

Limitações

Ao disparar um evento, o Firebird o envia para todos os clientes conectados. Assim, caberá a cada um avaliar se deve tratar ou não a mensagem recebida. Esse comportamento pode dificultar, em parte, a forma como as notificações são enviadas e recebidas, pois será preciso adicionar ao comando POST_EVENT argumentos que identifiquem o cliente a quem se destina a notificação.

Outra limitação que deve ser considerada é que, caso as notificações sejam enviadas enquanto o cliente estiver desconectado, elas serão perdidas. Para superar essa limitação, uma tabela de eventos poderia ser utilizada de forma auxiliar, armazenando informações sobre os eventos disparados. À aplicação cliente, por sua vez, caberá alterar o registro da tabela sempre que uma notificação for lida. Assim, caso o usuário acesse o sistema e algum registro não esteja marcado como “lido”, ele poderá ser notificado sobre as mensagens pendentes.