他のユーザーがレポートのコンテンツをオンラインで送信したときに、ネットワーク全体のさまざまなユーザー (コンプライアンス、プロダクション) にデスクトップ アラートを送信する必要があります。
現在、NET SEND を使用していますが、配信の保証はなく、クライアントとサーバーの両方の観点から信頼性が低いことが判明しています (また、Windows の今後のバージョンではサポートされないと思われます。現在、XP を実行しています)。
私たちは Jabber ベースのソリューションを検討していますが、チャット ウィンドウを前面に表示したり、システム トレイの近くに一時的な「トースト」メッセージを表示したりするのではなく、NET SEND のように Jabber クライアントを使用して画面に警告メッセージをポップアップ表示したことがある人はいますか。
警告メッセージは永続的に表示され、ユーザーがそれを見たことを示すためにユーザーによってのみ閉じられる必要があります。トースト スタイルのポップアップは、限られた時間だけ表示され、ユーザーが再度閉じる必要がない限り、問題ありません。
解決策はありますか?
答え1
社内にも似たようなものがあります。notifyanything および popup プラグインを備えた Miranda IM クライアントを使用しています。
Notificationanything を使用すると、クライアントは指定されたポートで UDP メッセージを受信できます。Popup はまさにそれを実行し、ユーザーの画面の上部にあるウィンドウにメッセージを表示します。
私たちの場合、すべてが内部ネットワーク上にあるため、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 に電話をかけます。
問題は、このプロセスの途中で 2 番目のアラートが生成された場合、管理者 A または B はそれを確認し、最初のアラートを確認しない可能性があることです。たとえば、管理者 A または B が別のアラートを生成した別の問題で忙しい場合や、コンピューターの近くにいない場合は、2 番目のアラートは深刻ではないが、最初のアラートはコンピューターの近くにいる誰かが処理する必要があり、エスカレーション メカニズムが適切な担当者を見つける最も効率的な方法であることがわかります。
Jabber には 2 種類のメッセージ配信がありました。(通常とチャットと呼ばれていたと思います) 2 種類のうちの 1 つでは、どのメッセージに応答するかを区別できる可能性があります。残念ながら、これを可能にする可能性のあるメッセージング タイプでは、大量のメッセージが受信された場合、テストしたクライアントに非常に不便が生じました。(また、この問題がテストを圧倒したため、テスト担当者が応答されているものを実際に区別できるかどうかを判断したかどうかはわかりません)。
これは調査段階であり、完全なソリューションを実装する時間がなかったため、問題が単により良いクライアントを選択することなのか、プロトコルの拡張が必要なのかは判断できませんでした。私は今でも、アラートを配信するには Jabber が最適な方法だと考えています。アラート配信/エスカレーション システムでは、アラートを確認した人がアラートの所有権を持ち、アラートを確認できなかったすべての人に影響があるべきです。これは、人に連絡する最適な方法、オンコール ローテーション、アラート フラッドのリスク、現在ローテーションから外れている人が作成したアラートの問題、および既存のシステムに説明責任がない場合に誤って説明責任を生み出すアラート システムによって生じる政治的配慮をシステムが理解していることと連携して機能する必要があります。
答え3
これはあなたの質問（Jabber について）に対する正確な答えではありませんが、ReachAlert をチェックしてみるとよいかもしれません。
これにより、他の目的（チャット、他のユーザーへのメッセージの送信）で Jabber を使用することを決定できるため、Jabber 実装が破損するのを防ぐことができます。
私もネット送信については同意します。ネット送信は廃止されつつあり、スパム送信に悪用されたため無効にするのが一般的です。
感想や結果を教えてください ;-)
答え4
PSI ジャバー クライアントを使用しました。サウンド通知に加えてポップアップ通知があります。JAJC ジャバー クライアントも同様です。