다른 사용자가 보고서를 위해 온라인으로 콘텐츠를 제출한 경우 네트워크를 통해 다양한 사용자(규정 준수, 프로덕션)에게 데스크톱 경고를 보내야 한다는 요구 사항이 있습니다.
현재 우리는 NET SEND를 사용하고 있지만 이는 전달을 보장하지 않으며 클라이언트와 서버 관점 모두에서 신뢰할 수 없는 것으로 판명되었습니다(그리고 Windows의 이후 버전에서는 지원되지 않을 것으로 예상됩니다. 현재 XP를 실행하고 있습니다).
우리는 Jabber 기반 솔루션을 고려하고 있지만 채팅 창을 앞으로 가져오거나 시스템 근처에 임시 '토스트' 메시지를 표시하는 대신 Jabber 클라이언트를 사용하여 NET SEND처럼 화면에 경고 메시지를 표시하는 사람이 있습니까? 쟁반.
우리는 경고 메시지가 지속적이고 사용자가 그것을 봤음을 나타내기만 하면 무시할 수 있어야 합니다. 토스트 스타일 팝업은 제한된 시간 동안만 표시되지 않고 사용자가 다시 닫아야 하는 한 괜찮습니다.
어떤 해결책이 있습니까?
답변1
우리 집에도 비슷한 게 있어요. 우리는 informanything 및 팝업 플러그인과 함께 Miranda IM 클라이언트를 사용합니다.
Notifyanything을 사용하면 클라이언트가 지정된 포트에서 UDP 메시지를 수신할 수 있습니다. 팝업은 사용자 화면 상단의 창에 메시지를 표시하는 역할을 합니다.
우리의 경우 모든 것이 내부 네트워크에 있으므로 UPD 패킷 손실은 걱정할 필요가 없습니다.
다음은 서버에서 사용자에게 udp 메시지를 보내기 위해 실행하는 Python 스크립트의 예입니다.
#!/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)
답변2
나는이 정확한 문제를 발견했습니다. 목표는 확대 경로를 따라 각 경고를 전달하는 것이었습니다. 즉, 지정된 기간 내에 승인되지 않은 경우 목록의 다음 사람에게 경고를 보내는 것입니다. 우리는 Jabber가 최고의 솔루션이라고 판단했지만 제대로 수행하려면 프로토콜을 확장하거나 더 많은 클라이언트를 조사해야 했습니다. (이 프로토콜은 확장에 매우 적합하며 수많은 클라이언트를 사용할 수 있습니다). 이러한 문제는 일부 경고는 승인하고 다른 경고는 승인하지 않는 것이 바람직한 경우가 많았기 때문입니다.
예를 들어. 경고의 최종 경로:
Jabber를 통해 관리자 A에게 보냅니다. 5분 후에는 승인이 없으며 Jabber를 통해 관리자 B에게 전송됩니다. 5분 후에는 확인이 없으며 SMS를 통해 관리자 A에게 전송됩니다. 5분 후에는 승인이 없으며 SMS를 통해 관리자 B에게 전송됩니다. 5분 후에는 승인이 없으며 Jabber를 통해 관리자 A와 B의 관리자에게 전송됩니다. 5분이 지나도 응답이 없으며 관리자 A와 B의 관리자에게 SMS로 전송됩니다. 관리자는 경고를 평가하고 이를 확인하거나 관리자 A 또는 B에게 전화를 겁니다.
문제는 이 프로세스 도중에 두 번째 경고가 생성되면 관리자 A 또는 B가 이를 승인하고 싶지만 첫 번째 경고는 승인하지 않을 수 있다는 것입니다. 예를 들어, 다른 경고를 생성한 별도의 문제로 바쁘거나 컴퓨터 근처에 있지 않은 경우 두 번째 경고는 심각하지 않지만 첫 번째 경고는 컴퓨터 근처에 있는 사람이 처리해야 한다는 점을 알아두세요. 컴퓨터와 에스컬레이션 메커니즘은 적합한 사람을 찾는 가장 효율적인 방법입니다.
Jabber에는 두 가지 유형의 메시지 전달이 있었습니다. (저는 일반 vs 채팅이라고 생각합니다.) 두 가지 유형 중 하나가 메시지에 응답하는 방식을 차별화할 수 있는 가능성이 있습니다. 불행하게도 이를 허용할 수 있는 메시징 유형은 대량의 메시지가 수신될 경우 테스트한 클라이언트에 극도의 불편을 초래했습니다. (또한 이 문제로 인해 테스트가 압도되었기 때문에 응답 대상을 실제로 구별할 수 있는지 테스트하는 사람들이 결정했는지 여부도 확실하지 않습니다.)
탐색적이었고 전체 솔루션을 구현할 시간이 없었기 때문에 문제가 단지 더 나은 클라이언트를 선택하는 것인지 아니면 프로토콜 확장이 필요한 것인지 판단하지 못했습니다. 나는 여전히 Jabber가 경고를 전달하는 가장 좋은 방법이라고 생각합니다. 경고 전달/에스컬레이션 시스템의 경우 경고를 승인한 사람이 경고의 소유권을 가져야 하며, 경고를 승인하지 못한 모든 사람에게 영향이 있어야 합니다. 이는 사람에게 연락하는 가장 좋은 방법, 대기 중인 순환, 경보 홍수의 위험, 현재 순환에서 벗어난 사람이 생성한 경보 문제 및 다음으로 인한 정치적 고려 사항을 이해하는 시스템과 함께 작동해야 합니다. 기존 시스템에 책임이 없는 경우 실수로 책임을 묻는 경고 시스템입니다.
답변3
귀하의 질문(Jabber 관련)에 대한 정확한 답변이 아니라 죄송합니다. 하지만 ReachAlert를 확인해 보시는 것이 좋습니다.
이렇게 하면 사람들이 Jabber 구현을 다른 용도(채팅, 다른 사용자에게 메시지 보내기)에 사용하기로 결정할 수 있으므로 Jabber 구현이 손상되는 것을 막을 수 있습니다.
Net Send에 대해서도 동의합니다. 그것은 사라지고 있으며 스팸으로 남용되었기 때문에 비활성화하는 것이 일반적인 관행입니다.
어떻게 생각하는지, 어떻게 진행되는지 알려주세요 ;-)
답변4
PSI Jabber 클라이언트를 사용했습니다. 소리 알림과 함께 팝업 알림이 있습니다. JAJC jabber 클라이언트도 마찬가지입니다.