APIs de la plataforma CommuniGate
CommuniGate Pro es una plataforma cuyo comportamiento se puede regular a niveles diferentes. Desde el cliente hasta el acceso a los módulos de comunicación básicos y elaboraciones de su propia funcionalidad a base de protocolos estandarizados. Al mismo tiempo la solución es estable y es compatible con cargas grandes.
A pesar de que el límite de entrada total a todas las API de CommuniGate puede parecer bastante grande, cubren la mayoría de las tareas a las que se enfrentan de los administradores de servicios de comunicaciones.
Vamos a ver el conjunto de herramientas en el servidor CommuniGate Pro para:
- La automatización de tareas administrativas
- Trabajo con mensajes y llamadas
- La conexión de programas y scripts de terceros
- Construcción de interfaces HTML
- La creación de clientes UC y programas de utilidad en plataformas diferentes
CLI
La interfaz de la línea de comando es la forma estándar de administración de muchos productos. Es cómodo para la automatización de las tareas administrativas. En el manual del administrador se encuentra la descripción del formato y la información detallada de comandos, más abajo se dan unos ejemplos de su uso en el manual:
Acceso por poppwd
Hay varias opciones de acceso a CLI Uno de las mas cómodos para conocer los comandos es el modulo PWD En la configuración estándar del servidor basta con utilizar el comando del sistema operativo "telnet server.address 8106" (o "telnet server.address 106", en dependencia del sistema operativo y de la versión). Al principio este modulo fue sólo la realización del protocolo del cambio de contraseña - poppwd:
$ telnet localhost 8106
Trying 127.0.0.1...
Connected to 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
Acceso por HTTP
Los comandos CLI pueden completarse enviando un pedido POST o GET con el parámetro "command" a la direccion server.name:[http port]/CLI/.
Bibliotecas
Como para tareas complejas el acceso de texto no es muy fácil, hemos creado bibliotecas Perl y Java para el trabajo con CLI.
También en la pagina hay una sección especial donde se dan ejemplos de CLI de scripts para resolver las tareas frecuentes.
La ejecución de comandos CLI también es posible por el protocolo de XIMSS (comando "cliExecute") y en el lenguaje CG/PL (función ExecuteCLI()).
Reglas de correo y de señales
Tal vez las reglas no se pueden adjuntar a la API, pero en Communigate Pro, además de su destino principal, las reglas pueden transmitir mensajes a programas de terceros (por ejemplo, a varios filtros), poner en marcha programas y scripts CG/PL en el sistema operativo.
Las señales en Communigate Pro son objetos especiales que se utilizan en comunicaciones "en tiempo real" (Real-time). La señal es la unidad de la comunicación Real-time Los distintos participantes (SIP, clientesXMPP, aplicaciones PBX y etc.) transmiten uno a otro las señales para la organización, rotura y actualización de estados de los diálogos y de otras acciones.
Como funcionan las reglas
Las reglas se dividen en tres niveles: del servidor, de domen y de cuenta de usuario. En cada uno de estos niveles hay reglas distintas para señales y para el correo.
Cada regla tiene su nombre y prioridad, las reglas de señales tienen una condición adicional "Cuando". Con las mismas condiciones la regla se activará antes, si su prioridad es más alta. La condición "Cuando" determina en qué momento funciona la regla. Esto puede ser un segundo determinado de procesamiento de la señal o el hecho de que se produzca un error con un código determinado (No responde, Ocupado, etc.):
El orden de procesamiento de los mensajes de correo:
- Se aplican todas las reglas del servidor.
- Las cartas que han resultado en las cuentas de usuario locales como resultado del direccionamiento, se procesan por las reglas de dominio y las reglas en las cuentas de usuario de la siguiente manera:
- Las reglas de dominio con la prioridad >5
- Las reglas en la cuenta de usuario
- Las reglas de dominio con prioridad <>
El orden del procesamiente de señales:
- Se aplican las reglas de señal del servidor con el campo en blanco "Cuando"
- Las señales que han resultado en las cuentas de usuario locales como resultado del direccionamiento se procesan por las reglas restantes del servidor (el campo Cuando no está en blanco), reglas de dominio y reglas en las cuentas de usuario en el orden siguiente:
- Las reglas del servidor con prioridad >5.
- Las reglas de dominio con la prioridad >5
- Las reglas en la cuenta de usuario
- Las reglas de dominio con prioridad <>
- Las reglas del servidor con prioridad <>
Ejemplos de uso
Limitación de reenvío del dominio:
Todas las llamadas con destinos fuera de dominios determinados se redirigen a la dirección especificada:
Helper
En Communigate Pro se ha creado el protocolo que permite usar los programas externos para el servidor del programa para solucionar tareas diferentes.
Cuando se cumplen ciertas condiciones el servidor pone en marcha el programa Helper. Las condiciones pueden ser diferentes, por ejemplo, la regla de correo pone en marcha un filtro para la carta o con la autorización se inicia de autentificación exterior. Después el programa Helper a través de la entrada estándar envía comandos y lee las respuestas de la salida estándar utilizando un helper protocolo especial.
Abajo hay un ejemplo de esta sesión generalizada para el protocolo helper (I — entrada al programa, O — salida):
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
Aquí el comando INTF concuerda la versión del protocolo, y QUIT termina la sesión, * es un mensaje informativo al que servidor no reacciona pero escribe a un registro.
En el marco de este protocolo se desarrollan extensiones mas especializadas para realizar las siguientes tareas:
- Elaboración del cuerpo de la carta
- Autenticación exterior
- Conexión de un sistema de banner
- Adición de RADIUS demandas a la autenticación
- Control de la distribución de la carga en un clúster
Todos ellos se conectan en la página Configuración->General->Asistentes WebAdmin del interfaz
Todas las rutas a los archivos ejecutables se cuentan desde el directorio Básico Communigate Pro (directorio con los datos de usuario).
Elaboración del cuerpo de la carta
Los procesadores de cartas se ponen en marcha por una regla de correo, por ejemplo:
Una descripción detallada de los comandos de este y otros helpers se puede encontrar en el manual del administrador.
Los helpers de este tipo se utilizan principalmente para la conexión a los programas anti-virus y anti-spam de CGPro.
Autenticación exterior
El Helper de protocolo para la autenticación externa normalmente se utiliza si:
- Se requiere un método de autenticación que no es compatible con el servidor directamente
- Una parte de cuentas se encuentra en otro sistema (por ejemplo, Active Directory)
- Se requiere un redireccionamiento complejo
- Se necesita una gestión exterior de servicios\configuración de la cuenta de usuario
Puede encontrar ejemplos de estos Helper en la página
El resto de helpers
Los Helpers de sistemas de banners proporcionan al servidor banners para XIMSS, HTTP y otros clientes.
Los RADIUS helpers permiten añadir al proceso de autenticación validaciones adicionales de protocolo RADIUS.
Los helpers de la distribución de la carga controlan el Equilibrador de carga en la configuración de clúster Communigate Pro.
WSSP
WSSP (Web Server-side Pages) — es el lenguaje para los moldes de páginas Web.
Cada Web skin se compone de tres tipos de archivos:
- Los archivos estáticos - gráficos, estilos, ...
- Archivos WSSP
- Archivos de lenguaje y línea
Junto con la distribución Communigate Pro se suministra un pequeño conjunto (stock) de interfaces Web. Uno de ellos sin nombre (Unnamed), el resto con nombres Estos skins demostrativos se almacenan en el Application directorio del servidor (el directorio en el sistema operativo donde se encuentran los archivos ejecutables) y por lo tanto se sustituyen con la actualización del servidor. Los administradores no tienen que cambiar los skins demostrativos porque con la instalación de la actualización estos cambios pueden perderse. Para resolver la tarea de cambio de los skins están organizados en una estructura jerárquica.
La jerarquía de archivos en skins
Cada skin puede ser de servidor, de dominio o estándar.
En el procesamiento de solicitudes desde el navegador al servidor por general, se necesita presentar archivos de skins con nombres determinados. Además, si el archivo no ha sido encontrado en el skin de dominio, el servidor lo buscará en el nivel superior de la jerarquía, en el skin de servidor con el mismo nombre. Si no ha sido encontrado en el skin de servidor. la búsqueda continuará en el skin de stock. Si el archivo aún no se ha encontrado y el skin corriente tiene nombre, el archivo se buscará en skins sin nombre.
Por lo tanto, subiendo sus propios archivos al skin de servidor sin nombre, el administrador del servidor puede lograr el uso de sus archivos sin estándares
Con este enfoque se pueden hacer tanto pequeños cambios en los skins estándares, como crear sus propios completamente.
Ficheros de línea
Los archivos .data contienen datos de texto (UFT-8) en el formato de diccionario CG/PL. Estos datos se utilizan por diferentes módulos de servidor para la formación de líneas en la interfaz y la transferencia de valores de configuración de la cuenta.
Los datos de estos ficheros también forman una jerarquía, pero ya en el nivel de claves en el diccionario. Si una clave falta en el fichero strings.data de un skin de dominio , el servidor intenta encontrarlo en el fichero strings.data en el nivel de servidor y etc.
El inglés es el idioma predeterminado para las líneas en la interfaz. Si el idioma del usuario (sesiones) no es el inglés, los valores de las claves de los archivos de idioma (french.data, russian.data) sustituyen los valores de strings.data del fichero.
Este sistema permite incluir a interfaces un poco modificados, cambiando sólo los archivos de strings.data, sólo las claves cuyos valores han sido cambiados (por ejemplo, el nombre de la empresa, mrcas), y no todo el conjunto.
Procesamiento de solicitudes
Cuando el navegador se conecta con el servidor por el protocolo HTTP, el servidor recupera el nombre de host de la solicitud y busca un dominio con el mismo nombre. Si se encuentra el dominio, el servidor encuentra un skin seleccionado como una Web interfaz predeterminada para los usuarios de este dominio y se pone en marcha la página login.wssp de este skin.
Los archivos wssp se componen del código de marcado (normalmente HTML), con algunos elementos adicionales:
- el texto limitado de dos partes con un doble símbolo % (%%element%%)
- las estructuras que comienzan con el marcador "<!--%%" y que terminan con el marcador "-->"
Ejemplo de un documento similar:
<html>
<body>
<h1>Bienvenido al %%servidor%%. Su login %%ID%%.</h1>
<!--%%IF EXISTS(lastLogin)-->
La última visita %%lastLogin%%
<!--%%ENDIF-->
</body>
</html>
Los valores de las claves de archivos .data forman el "entorno". Después del procesamiento por el servidor todas las estructuras especiales serán reemplazadas por líneas o áreas de líneas, de este "entorno", tales como el nombre de dominio, valores de configuración o otros objetos.
Otros ficheros simplemente se pasan al cliente.
Las interfaces web básicas de demostración pueden considerarse como ejemplos de oportunidades de páginas WSSP. Pero el acceso a distintos módulos y la ejecución de algunas acciones en el servidor, así como la conversión de formatos de datos en WSSP es muy limitado. Para la solución de tareas que requieren tales acciones, se utiliza la siguiente instrumentación.
CG/PL
Puede encontrar información sobre el lenguaje CG/PL y su uso para el desarrollo de aplicaciones PBX en este artículo.
Además PBX se utiliza activamente para el desarrollo de interfaces web de Communigate Pro. Si se abre la lista de ficheros incluso del Web skin básico (Usuarios->Interfaces), allí habrá 14 ficheros con pequeños programas CG/PL que procesan solicitudes HTTP.
Para llamar el programa CG/PL programa para el procesamiento de la petición HTTP, es necesario grabarla en cualquier editor de texto, guardarla como .wcgp y subirla a algún Web skin.
Después de esto hay que hacer una solicitud a URL del tipo:
http://domain.name:[port]/programFile.wcgp/?Skin=skin_name
Pondrá en marcha el programa.
http://domain.name:[port]/auth/programFile.wcgp/?Skin=skin_name
Pondrá en marcha desde el nombre de la cuenta con autenticación previa
http://domain.name:[port]/sys/programFile.wcgp
Esta solicitud busca el programa en el servidor sólo en el Unnamed skin del servidor y la pone en marcha del nombre de usuario postmaster (administrador de servidor)
Como ejemplo, consideramos un pequeño script que ejecuta el comando CLI "listaccounts" y que convierte el resultado en el formato JSON:
entry sysEntry is
void(executeCLI("listaccounts mymac.ru"));
accountList = Vars().executeCLIResult;
SetHTTPResponseCode(200);
SetHTTPResponseData(ObjectToJSON(accountList));
end entry;
XIMSS
La alta funcionalidad del servidor - voz, mensajes instantáneos, correo electrónico, servidor de ficheros y etc., a veces causa algunas dificultades en la escritura del cliente unificado. Es necesario elegir o desarrollar bibliotecas que ejecutan SIP, conjunto de protocolos *DAV, SMTP, IMAP, XMPP. Al mismo tiempo el trabajo de organizar mensajes y formatos de datos de estos protocolos lo realiza el cliente.
Como solución de estos problemas hemos desarrollado un protocolo XIMSS — XML Interface to Messaging, Scheduling and Signaling.
Todos los comandos de este protocolo son simples documentos XML con atributos con sentido transparente. Por ejemplo, este simple comando redirigirá (fork) la llamada entrante a dos usuarios:
C:<callRedirect id="A018" callLeg="inp003" >
<To>user1@example.com</To><To>user2@example.com</To>
</callRedirect>
S:<response id="A018"/>
Todos los formatos de datos (MIME, vCard) vienen al XIMSS cliente en una forma confortable para el uso.
También este protocolo permite realizar todos los comandos CLI disponibles en el servidor, a través de él se pueden regular todo tipo de configuración, incluyendo las administrativas.
Para una serie de plataformas hemos diseñado bibliotecas XIMSS.
Como ejemplos de oportunidades de XIMSS clientes recomendamos consultar con la aplicación Samoware. La versión Web de demostración de esta aplicación están en nuestro stand demo.communigate.ru.
Un protocolo en lugar de 10
En Communigate Pro cualquier tarea se puede resolver a través de un protocolo - XIMSS. La revisión de correos electrónicos, calendarios y contactos, llamadas e incluso la administración del servidor sin necesidad de conocer múltiples normas internacionales.
 |
|