Temos a necessidade de enviar alertas de desktop para vários usuários (conformidade, produção) em uma rede quando outros usuários enviarem conteúdo on-line para um relatório.
No momento estamos usando o NET SEND, mas ele não tem garantia de entrega e não se mostrou confiável tanto do ponto de vista do cliente quanto do servidor (e suponho que não terá suporte em versões posteriores do Windows; atualmente estamos executando o XP).
Estamos considerando uma solução baseada em Jabber, mas alguém já usou um cliente Jabber para exibir mensagens de alerta na tela como o NET SEND faz, em vez de apenas trazer uma janela de bate-papo para a frente ou exibir uma mensagem temporária de 'brinde' perto do sistema bandeja.
Precisamos que a mensagem de alerta seja persistente e apenas descartada pelo usuário, indicando que ele a viu. Pop-ups do tipo brinde seriam adequados, desde que não fossem apenas por um tempo limitado e novamente tivessem que ser descartados pelo usuário.
Alguma solução?
Responder1
Temos algo semelhante em casa. Usamos o cliente Miranda IM com os plugins notifyanything e popup.
Notifyanything permite que o cliente receba mensagens udp em uma porta especificada. Popup faz exatamente isso, exibe a mensagem na janela na parte superior da tela do usuário.
No nosso caso, tudo está na rede interna, portanto a perda de pacotes UPD não é uma preocupação.
Aqui está um exemplo do script python que executamos para enviar mensagens udp dos servidores para os usuários:
#!/usr/bin/python
import socket, sys
hosts = (
('10.0.0.1', 15000),
('10.0.0.2', 15000),
('10.0.0.3', 15000),
)
def send(txt):
s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
for h,p in hosts:
s.sendto(txt, 0, (h,p))
del s
if len(sys.argv) > 1:
s = "\n".join(sys.argv[-2:])
send(s)
Responder2
Me deparei com esse problema exato. O objetivo era entregar cada alerta ao longo de um caminho de escalonamento – enviando o alerta para a próxima pessoa na lista caso não fosse confirmado em um determinado período de tempo. Determinamos que o Jabber era a melhor solução, mas para fazer certo teríamos que estender o protocolo ou investigar mais clientes. (O protocolo se presta muito bem à extensão e existem inúmeros clientes disponíveis). Esse problema ocorreu porque frequentemente era desejável reconhecer alguns alertas, mas não outros.
Por exemplo. O caminho final de um alerta:
Envie para o administrador A via Jabber. Nenhuma confirmação após 5 minutos, enviada ao administrador B via Jabber. Nenhuma confirmação após 5 minutos, enviada ao administrador A via SMS. Nenhuma confirmação após 5 minutos, enviada ao administrador B via SMS. Nenhuma confirmação após 5 minutos, enviada ao gerente dos administradores A e B via Jabber. Nenhuma confirmação após 5 minutos, enviada ao gerente dos administradores A e B via SMS. O gerente avalia o alerta, confirma-o ou liga para o administrador A ou B.
O problema é que se um segundo alerta for gerado no meio deste processo, o administrador A ou B pode desejar reconhecê-lo, mas não reconhecer o primeiro alerta. Por exemplo, se eles estiverem ocupados com um problema separado que gerou o outro alerta, ou se não estiverem perto de um computador, saiba que o segundo alerta não é sério, mas que o primeiro alerta precisa ser tratado por alguém próximo a um computador. computador e o mecanismo de escalonamento são a maneira mais eficiente de encontrar a pessoa certa.
Havia dois tipos de entrega de mensagens no Jabber. (Acredito que seja chamado de normal vs chat) É possível que um dos dois tipos tenha permitido uma diferenciação na qual a mensagem foi respondida. Infelizmente, o tipo de mensagem que poderia ter permitido isso causou extrema inconveniência aos clientes que testamos caso uma grande quantidade de mensagens fosse recebida. (Também não tenho certeza se as pessoas que testaram determinaram se era realmente possível diferenciar o que estava sendo respondido, devido a esse problema sobrecarregar os testes).
Como era exploratório e não tivemos tempo de implementar uma solução completa, não determinamos se o problema era apenas escolher um cliente melhor ou se eram necessárias extensões do protocolo. Ainda acho que o Jabber é o melhor método para entregar alertas. Para qualquer sistema de entrega/escalamento de alerta, uma pessoa que reconhece um alerta deve assumir a responsabilidade pelo alerta, e deve haver repercussões para todos que não reconhecem um alerta. Isto tem que funcionar com o sistema compreendendo a melhor maneira de entrar em contato com uma pessoa, um rodízio de plantão, o risco de inundações de alertas, a emissão de alertas criados por uma pessoa que está atualmente fora do rodízio e quaisquer considerações políticas causadas por um sistema de alerta que acidentalmente cria responsabilidade se o sistema existente não tiver nenhuma.
Responder3
Lamento que esta não seja uma resposta exata à sua pergunta (sobre o Jabber), mas você pode querer verificar o ReachAlert.
Isso impediria as pessoas de corromperem sua implementação do jabber, pois poderiam decidir usá-lo para outra coisa (bate-papo, envio de mensagens para outros usuários).
Também concordo com o net send. Ele está desaparecendo e é uma prática comum desativá-lo, pois foi usado para spam.
Deixe-me saber o que você pensa e como foi ;-)
Responder4
Usei o cliente jabber PSI. Possui notificações pop-up junto com notificações sonoras. O mesmo vale para o cliente jabber JAJC.