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.
Saiba mais sobre a biblioteca FireDAC no Delphi
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.
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.
Saiba mais sobre triggers no Firebird
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.
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.
