CommuniGate Pro plate-forme APIs
Communigate Pro est une plate-forme dont le comportement peut être contrôlé à différents niveaux. Du client à l'accès aux principaux modules de communication et la conception de la fonctionnalité propre basée sur des protocoles standards. La solution est stable et peut supporter de grandes charges.
Malgré le fait que le seuil d'entrée dans toute la totalité de Communigate API puisse sembler assez grand, ils couvrent la plupart des tâches rencontrées par les administrateurs des services de communications.
Considérons un ensemble d'outils à la disposition du serveur CommuniGate Pro pour :
- Automatisation des tâches administratives
- Traitement des messages et appels
- Connexion d'autres programmes et scripts
- Construction d'interfaces HTML
- Création de clients UC et d'utilitaires sur diverses plate-formes
CLI
Command Line Interface (Interface de la Ligne de Commande) est un moyen standard de gestion de nombreux produits. Elle est adaptée pour l'automatisation des tâches administratives. Le manuel d'administrateur contient une description du format et des informations détaillées sur les commandes, voici quelques exemples de leur utilisation dans la notice :
Accès par poppwd
Il existe plusieurs façons d'accéder à CLI. Le module PWD est l'un des modules les plus pratiques pour se familiariser avec les commandes. Dans la configuration standard du serveur, il suffit d'utiliser la commande du système d'exploitation "telnet server.address 8106" (ou "telnet server.address 106" en fonction du système d'exploitation et de la version). Initialement, ce module était tout simplement une réalisation du protocole de changement du mot de passe - poppwd :
$ telnet localhost 8106
Trying 127.0.0.1...
Connecté à localhost.
Escape character is '^]'.
200 mymac.ru CommuniGate Pro PWD Server 6.0.5 ready <1.1381912847@mymac.ru>
user postmaster
300 please send the PASS
pass ******
200 login OK, proceed
newpass ******
200 Password updated
Accès par HTTP
Les commandes CLI peuvent aussi être exécutées en envoyant une requête POST ou GET à l'aide du paramètre "command" à server.name:[http port]/CLI/.
Bibliothèques
Comme pour des tâches complexes, l'accès au texte n'est pas très utile, nous avons créé des bibliothèques Perl et Java pour travailler avec CLI.
Le site dispose également d'une section spéciale qui présente des exemples de scripts CLI pour résoudre les problèmes rencontrés.
L'exécution des commandes CLI est également possible par le protocole XIMSS (commande "cliExecute") et dans le langage CG/PL (fonction ExecuteCLI ()).
Règles de messagerie électronique et de signaux
Il est possible que la règle de la difficulté puisse être imputée à l'API, mais Communigate Pro, en plus de son objectif principal, dispose de règles qui peuvent envoyer des courriels à des programmes externes (par exemple, à différents filtres), exécuter des programmes CG/PL et des scripts dans le système d'exploitation.
Les signaux dans Communigate Pro sont des objets spéciaux utilisés dans les communications en "temps réel" (Real-time). Un signal est une unité de communication en temps réel (Real-time). Plusieurs participants (SIP, clients XMPP, applications, PBX, etc.) envoient des signaux les uns les autres pour réaliser, couper et mettre à jour le statut des dialogues et d'autres actions.
Fonctionnement des règles
Les règles sont divisées en trois niveaux : serveur, domaine et compte utilisateur. Chaque niveau dispose de règles distinctes pour les signaux et la messagerie.
Chaque règle dispose d'un nom et d'un signal de priorité. Les règles de signal ont une condition supplémentaire "Quand". Dans des conditions identiques, la règle se déclenchera plus tôt si sa priorité est plus élevée. La condition "Quand" détermine le moment où la règle se déclenche. Il peut s'agir d'une seconde déterminée du traitement du signal ou le fait d'une apparition d'un code spécifique d'erreur (Pas de réponse, Occupé, etc.) :
Ordre de traitement des messageries électroniques :
- Toutes les règles de serveur sont applicables
- Les courriers en cours d'acheminement dans les comptes locaux sont traités par les règles de domaine et règlements de comptes comme suit :
- Règles de domaine avec priorité >5
- Règles dans le compte
- Règles de domaine avec priorité <>
Ordre de traitement des signaux :
- Les règles de signaux de serveur avec le champ vide "Quand" sont appliquées
- Les signaux qui se trouvent en cours d'acheminement dans les comptes locaux sont traités par les règles de serveur restantes (champ "Quand" non vide), les règles de domaine et les règles de comptes comme suit :
- Règles de serveur avec priorité >5
- Règles de domaine avec priorité >5
- Règles dans le compte
- Règles de domaine avec priorité <>
- Règles de serveur avec priorité <>
Exemples d'application
Limitation d'envoi dans le cadre de domaine :
Tous les appels pour les destinataires hors de certains domaines sont redirigés vers l'adresse spécifiée :
Helper
Le Communigate Pro offre un protocole Helper qui permet d'utiliser des programmes externes liés au serveur du programme pour réaliser diverses tâches.
Si certaines conditions sont exécutées, le serveur lancera le programme d'assistance Helper. Les termes et conditions peuvent varier, par exemple, une règle de messagerie lance un filtre lors de la rédaction d'un courrier ou lance une authentification externe en cas d'autorisation sur le domaine. Ensuite, le programme Helper envoie des commandes par le biais d'une entrée standard et lit les réponses de la sortie standard à l'aide d'un protocole helper spécial.
Voici un exemple d'une telle session généralisée pour un protocole Helper (I - entrée dans le programme, O - sortie) :
O: * My Helper program started
I: 00001 INTF 1
O: 00001 INTF 1
I: 00002 COMMAND parameters
O: 00002 OK
I: 00003 COMMAND parameters
I: 00004 COMMAND parameters
O: * processing 00003 will take some time
O: 00004 ERROR description
O: 00003 OK
I: 00005 QUIT
O: * processed: 5 requests. Quitting.
O: 00005 OK
Ici, la commande INTF coordonne la version du protocole, et la commande QUIT termine la session * - ceci est un message d'information auquel le serveur ne répond pas, mais il l'enregistre dans le journal (log).
Dans le cadre du protocole, des extensions plus spécialisées ont été mises au point pour effectuer les tâches suivantes :
- Traitement du corps du message
- Authentification externe
- Connexion du système de bannières
- Ajout de requêtes RADIUS à l'authentification
- Gestion de la distribution de la charge dans un cluster
Tous sont connectés à la page Paramètres> Général-> Helpers (assistants) de l'interface WebAdmin.
Tous les chemins d'accès aux fichiers exécutables sont comptabilisés à partir du répertoire de base Communigate Pro (répertoire avec données d'utilisateur).
Traitement du corps du message
Les gestionnaires de courriers sont lancés par des règles de messagerie comme suit :
La description détaillée des commandes de ce Helper et d'autres se trouve dans le Manuel de l'administrateur.
Les Helpers (Assistants) de ce type sont principalement utilisés pour la connexion à des programmes CGPro antivirus et anti-spam.
Authentification externe
Le protocole Helper pour l'authentification externe est généralement utilisé dans les cas suivants :
- Méthode d'authentification non directement supportée par le serveur nécessaire
- Une partie des comptes se trouvent dans un autre système (par exemple, Active Directory)
- Acheminement intégral nécessaire
- Gestion externe des services/paramètres du compte nécessaire
Les exemples de tels Helpers sont présentés sur cette page.
Autres assistants
Les Helpers du système de bannières sont fournis au serveur de bannières pour XIMSS, HTTP et d'autres clients.
Les helpers RADIUS permettent d'ajouter des contrôles supplémentaires lors de l'authentification via le protocole RADIUS.
Les Helpers de répartition de charge gèrent l'Équilibreur de la charge dans la configuration de cluster de Communigate de Pro.
WSSP
WSSP (Web Server-side Pages) est le langage des modèles de pages Web.
Chaque modèle Web comporte trois types de fichiers :
- Fichiers statistiques incluant graphique, styles, etc.
- Fichiers WSSP
- Fichiers de langue et de chaîne
La distribution Communigate Pro comprend aussi un jeu d'interfaces standards (stock) Web. L'une est anonyme (Unnamed) et les autres portent un nom. Ces modèles de démonstration sont stockés dans le répertoire du serveur Application (répertoire dans le système d'exploitation où se trouvent les fichiers exécutables) et, pour cette raison, ils sont remplacés lors de la mise à jour du serveur. Les administrateurs ne doivent pas changer directement les modèles de démonstration, car ces modifications peuvent être perdues lors de la mise à jour. Pour résoudre la modification des modèles, ils sont organisés sous forme de hiérarchie.
Hiérarchie des fichiers dans les modèles
Chaque modèle peut être de serveur, de domaine ou standard.
Au cours du traitement des demandes à partir du navigateur, le serveur a généralement besoin du modèle des fichiers avec des noms déterminés. Par conséquent, si le fichier est introuvable dans le modèle de domaine, le serveur le cherchera plus haut dans la hiérarchie, dans le modèle de serveur avec le même nom. Si le fichier est introuvable dans le modèle de serveur, la recherche se poursuivra dans le modèle standard (stock). Si le fichier reste introuvable dans le modèle actuel nommé, le fichier sera recherché dans les modèles sans nom.
Ainsi, en téléchargeant les fichiers propres dans un modèle de serveur sans nom, l'administrateur du serveur peut utiliser ces fichiers au lieu des fichiers standards.
Cette approche permet d'introduire de petits changements dans les modèles standards, ainsi que créer des modèles personnalisés.
Fichiers de chaînes
Les fichiers .data contiennent des données textuelles (UFT-8) au format du dictionnaire CG/PL. Ces données sont utilisées par les différents modules du serveur afin de former des chaînes dans l'interface et transférer les valeurs de paramètres du compte.
Les données de ces fichiers forment également une hiérarchie, mais au niveau des clés du dictionnaire. Si une clé est manquante dans le fichier strings.data du modèle de domaine, le serveur tente de la trouver dans le fichier strings.data au niveau du serveur, etc.
L'anglais est la langue par défaut pour les lignes de l'interface. Si la langue de l'utilisateur (de session) est différente de l'anglais, les valeurs des clés des fichiers de langue (french.data, russian.data) remplaceront les valeurs du fichier strings.data.
Ce système permet d'inclure dans les interfaces légèrement modifiées, en modifiant légèrement les fichiers strings.data, exclusivement les clés dont les valeurs ont été modifiées (par exemple, la raison sociale, la marque commerciale), et non l'ensemble.
Traitement des requêtes
Lorsqu'un navigateur se connecte à un serveur via le protocole HTTP, le serveur récupère le nom de l'hébergeur de la requête et cherche le domaine avec le même nom. S'il trouve le domaine, le serveur trouvera le modèle sélectionné comme interface Web par défaut pour les utilisateurs de ce domaine et lancera la page login.wssp de ce modèle.
Le contenu des fichiers wssp est le code de disposition (généralement HTML) avec plusieurs éléments supplémentaires :
- texte limité des deux côtés par le double symbole % (%%element%%)
- structures commençant par le marqueur "<!--%%" et finissant par le marqueur "-->"
Exemple d'un tel document :
<html>
<body>
<h1>Bienvenue sur %%server%%. Votre identifiant %%ID%%.</h1>
<!--%%IF EXISTS(lastLogin)-->
La dernière fois, vous vous êtes connectés avec %%lastLogin%%
<!--%%ENDIF-->
</body>
</html>
Les valeurs des clés de fichiers .data dans le modèle forment un "environnement". Après avoir été traitées par le serveur, toutes les constructions spéciales seront remplacées par des chaînes ou des tableaux de chaînes, de cet "environnement", tels que le nom de domaine, les valeurs de paramètres ou d'autres objets.
Tous les autres fichiers sont simplement transférés au client.
Les principales interfaces Web de démonstration peuvent être considérées comme des exemples de fonctionnalités de pages WSSP. Mais l'adressage à divers modules et l’exécution de toutes actions sur le serveur, ainsi que la conversion des formats de données WSSP sont assez limités. Pour réaliser les tâches qui nécessitent de telles actions, il faut utiliser l'instrument suivant.
CG/PL
Le langage CG/PL et le développement des applications PBX sont décrits en détail dans cet article.
Excepté PBX qui est activement utilisé lors du développement des interfaces Web de Communigate Pro. Si vous ouvrez la liste des fichiers même d'un modèle Web de base (Utilisateurs -> Interfaces), vous trouverez 14 fichiers avec de petits programmes CG/PL qui traitent les requêtes HTTP.
Pour accéder à un programme CG/PL pour le traitement d'une requête HTTP, il faut l'enregistrer dans un éditeur de texte, le sauvegarder en tant que .wcgp et le charger dans un modèle Web.
Après cela, la requête de l'URL aura la forme suivante :
http://domain.name:[port]/programFile.wcgp/?Skin=skin_name
Il lancera l'application.
http://domain.name:[port]/auth/programFile.wcgp/?Skin=skin_name
Il lancera l'exécution au nom du compte avec authentification préalable
http://domain.name:[port]/sys/programFile.wcgp
Cette requête recherche l'application uniquement dans le modèle de serveur Unnamed (sans nom) et l'exécute au nom de l'utilisateur postmaster (administrateur du serveur)
À titre d'exemple, nous pouvons considérer un petit script qui exécute une commande CLI "listaccounts" et convertit le résultat au format JSON :
entry sysEntry is
void(executeCLI("listaccounts mymac.ru"));
accountList = Vars().executeCLIResult;
SetHTTPResponseCode(200);
SetHTTPResponseData(ObjectToJSON(accountList));
end entry;
XIMSS
La haute fonctionnalité du serveur est la voix, la messagerie instantanée, la messagerie, le serveur de fichiers, etc. qui rend parfois difficile la rédaction d'un client unifié. Il faut choisir ou développer une bibliothèque qui réalise le SIP, l'ensemble de protocoles *DAV, SMTP, IMAP, XMPP. Dans ce cas, la charge liée à l'analyse des messages et des formats de données de ces protocoles est supportée par le client.
Pour trouver une solution à ces problèmes, nous avons mis au point un protocole XIMSS — XML Interface to Messaging, Scheduling and Signaling.
Toutes les commandes du protocole sont de simples documents XML avec des attributs transparents. Par exemple, cette simple commande redirigera (fork) un appel entrant vers deux utilisateurs :
C:<callRedirect id="A018" callLeg="inp003" >
<To>user1@example.com</To><To>user2@example.com</To>
</callRedirect>
S:<response id="A018"/>
Tous les formats de données (MIME, vCard) parviennent au client XIMSS sous une forme facile à utiliser.
Ce protocole permet également d'exécuter toutes les commandes CLI disponibles sur le serveur - toutes sortes de paramètres peuvent être réglés par ce protocole, y compris d'administration.
Pour certaines plates-formes, nous avons développé des bibliothèques XIMSS prêtes à être utilisées.
En tant qu'exemples de fonctionnalités des clients XIMSS, nous recommandons de prendre connaissance de l'application Samoware. La version Web de démonstration de cet application se trouve sur notre stand demo.communigate.ru.
Un protocole au lieu de 10
Dans Communigate Pro, il est possible d'accomplir n'importe quelle tâche via un seul protocole - XIMSS. Visualisation de la messagerie, des calendriers et des contacts, les appels, y compris l'administration du serveur sans nécessité d'étudier de nombreuses normes internationales.
 |
|