NOTIFYeye technology gears

NOTIFeye

Fondements techniques du système de notification de masse

NOTIFeye

»

TECHNIQUE

Conçu pour la flexibilité, la résilience et la performance

  • Fonctionne en tant que service sur Linux, sur site ou dans le cloud

  • Des interfaces flexibles offrent des sockets, des web sockets et des ReST, avec des structures de données JSON natives pour tout l’intérieur et l’extérieur

  • Déclencheurs push et pull (publish-subscribe) pour envoyer des notifications

  • Alertes unidirectionnelles et bidirectionnelles pour automatiser non seulement les notifications, mais aussi capturer les données de réponse des destinataires

  • Interfaces avec les services en ligne et les appareils de communication locaux pour soutenir les opérations continues en cas de sinistre physique

Schéma

NOTIFeye technology block diagram

Modules Majeurs

Le module Trigger Interface est chargé de recevoir des alertes provenant de différents points de terminaison. Les alertes peuvent arriver de manière non sollicitée (push to NOTIFeye) ou sollicitées (interrogation de systèmes/appareils externes ou souscription à des déclencheurs à partir de ces terminaux). Toutes les alertes sont mises à l’épreuve pour des raisons de sécurité, puis transmises au module de traitement des règles. Toutes les communications avec les points de terminaison de déclenchement sont enregistrées.

Le module Processeur de règles est chargé de recevoir les demandes de notification approuvées et de récupérer les modèles associés. Les modèles dictent les règles qui doivent être appliquées, qui affectent la sélection des cibles, l’ordre des notifications et les conditions qui déterminent les étapes prises. Le processeur de règles envoie des notifications individuelles au module d’interface d’alerte pour effectuer les communications.

Le module d’interface d’alerte est chargé de transmettre des messages à divers points de terminaison. Le message peut être sous forme textuelle ou sonore selon le point final, avec conversion automatique de la synthèse vocale si nécessaire. Le module d’interface d’alerte est également chargé de recevoir les réponses des points de terminaison (bidirectionnels) et de stocker ces données pour une tabulation ultérieure. Les données stockées comprendront les réponses des points de terminaison qui prennent en charge la livraison et/ou les confirmations d’état de lecture, ainsi que les réponses aux messages qui demandent des commentaires.

Le module Planificateur est responsable de la planification et de la reprise des règles en cours qui ont été suspendues en fonction de l’heure du jour ou de la date. Cela permet aux règles de différer la transmission des notifications en fonction de divers critères, par utilisateur et par point de terminaison.

Le module Contrôleur de sécurité est chargé d’appliquer les stratégies de sécurité pour toutes les connexions, utilisateurs, rôles, points de terminaison et appareils. De plus, le contrôleur de sécurité consigne les menaces et les tentatives d’atteinte à la sécurité aux fins de vérification et d’examen ultérieurs. En cas d’attaque en cours, le contrôleur de sécurité bloquera également les points de terminaison / utilisateurs / connexions.

Le module Processeur de rapports est chargé de générer des rapports à la demande et selon des calendriers prédéfinis. Tous les rapports sont stockés dans une base de données au format JSON, pour une récupération et un formatage ultérieurs par des systèmes externes. NOTIFeye regroupe les rapports couramment utilisés, et Telium peut créer des rapports personnalisés pour les clients.

Le module Contrôleur de gestion est responsable de la gestion des comptes d’utilisateurs et des attributs, de l’activation/désactivation des points de terminaison et du contrôle des opérations du système NOTIFeye. Toutes les fonctionnalités de gestion sont accessibles via des API, ainsi que via une interface en ligne de commande (pour la configuration / le diagnostic de base).

Points de terminaison de déclenchement

Points de terminaison d’alerte