Piattaforma API CommuniGate Pro
Il comportamento della piattaforma CommuniGate Pro può essere regolato su vari livelli: dal client all'accesso ai moduli di comunicazione principali, alla progettazione delle relative funzionalità basate su protocolli standard. La soluzione garantisce una stabilità costante ed è in grado di sostenere carichi pesanti.
Nonostante la soglia per l'accesso simultaneo a tutte le API CommuniGate sembri abbastanza grande, queste consentono di coprire la maggior parte delle attività svolte dall'amministratore dei servizi di comunicazione.
Analizziamo gli strumenti del server CommuniGate Pro utili per:
- Automatizzazione delle attività amministrative
- Elaborazione di mail e chiamate
- Connessione di applicazioni e script esterni
- Costruzione di interfacce HTML
- Costruzione di client UC e utilità su diverse piattaforme
CLI
La Command Line Interface (interfaccia su riga di comando) è un sistema standard per la gestione di vari prodotti. La riga di comando è comoda inoltre per automatizzare i processi amministrativi. Nel manuale dell'amministratore sono presenti descrizione del formato e informazioni dettagliate sui comandi, mentre qui di seguito sono riportati alcuni esempi del loro utilizzo:
Accesso su poppwd
È possibile accedere all'interfaccia CLI in vari modi. Uno dei moduli più comodi per impartire i comandi è il modulo PWD. Con il server in configurazione standard, è sufficiente digitare nella riga di comando del sistema operativo "telnet server.address 8106" (o "telnet server.address 106", a seconda del sistema operativo e della sua versione). Inizialmente questo modulo realizzava semplicemente il protocollo di modifica della password — 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
Accesso su HTTP
È inoltre possibile eseguire comandi CLI inviando una richiesta POST o GET con il parametro "command" all'indirizzo server.name:[http port]/CLI/.
Librerie
Poiché per attività complesse l'accesso mediante testo non è una scelta molto conveniente, abbiamo creato delle librerie Perl e Java che consentono di lavorare con l'interfaccia CLI.
Sul sito è inoltre disponibile una sezione speciale, dove sono presenti alcuni esempi di script CLI per eseguire le attività più comuni.
È possibile eseguire i comandi CLI anche sul protocollo XIMSS (comando "cliExecute") e nella lingua CG/PL (funzione ExecuteCLI ()).
Regole relative a posta e segnali
Le regole sono di norma difficilmente attribuibili alle API. In CommuniGate Pro, tuttavia, oltre al loro ruolo principale, le regole consentono di trasmettere messaggi di posta elettronica a programmi esterni (ad esempio, vari filtri), avviare programmi CG/PL e script nel sistema operativo.
I segnali di CommuniGate Pro sono oggetti speciali che vengono utilizzati nella comunicazione in "tempo reale" (Real-time). Il segnale è l'unità della comunicazione Real-time. Vari utenti (SIP, client XMPP, applicazioni, PBX, ecc) trasmettono dei segnali per organizzazione, terminazione o aggiornamento di stato dei dialoghi e altre azioni.
Come funzionano le regole
Le regole sono suddivise in tre livelli: relative al server, relative al dominio e relative all'account. Per ciascun livello sono previste apposite regole per i segnali e per la posta.
Ogni regola ha un nome e una priorità; le regole per i segnali hanno inoltre la condizione "Quando". In condizioni paritarie, la regola con priorità più alta viene applicata per prima. La condizione "Quando" determina in quale istante di tempo verrà applicata la regola. Può essere un secondo particolare di elaborazione del segnale o l'evento di comparsa di un errore con un codice specifico (nessuna risposta, occupato, ecc.):
Modalità di elaborazione dei messaggi di posta elettronica:
- Sono applicate tutte le regole del server
- Le mail ricevute in seguito a routing negli account locali sono elaborate con le regole del dominio e le regole degli account nel modo seguente:
- Regole di dominio con priorità >5
- Regole di account
- Regole di dominio con priorità <>
Modalità di elaborazione dei segnali:
- Sono applicate le regole dei segnali del server con il campo "Quando" vuoto
- I segnali ricevuti in seguito a routing negli account locali sono elaborate con le restanti regole del server (campo "Quando" non vuoto), le regole del dominio e le regole degli account come segue:
- Regole del server con priorità >5
- Regole di dominio con priorità >5
- Regole di account
- Regole di dominio con priorità <>
- Regole del server con priorità <>
Esempi di utilizzo
Limite di invio all'interno di un dominio:
Tutte le chiamate verso destinatari al di fuori del dominio specificato sono inoltrate all'indirizzo specificato:
Helper
In CommuniGate Pro è realizzato il protocollo Helper che consente di utilizzare programmi esterni al server per varie attività.
In presenza di condizioni specifiche, il server avvia il programma Helper. Le condizioni possono essere di varia natura. Ad esempio, una regola di posta elettronica avvia un filtro per e-mail o all'autenticazione nel dominio viene avviata l'autenticazione esterna. Di seguito il programma Helper invia comandi tramite input standard e legge le risposte da output standard utilizzando un apposito protocollo helper.
Di seguito è presentato un esempio di una sessione generica per protocollo helper (I - input nel programma, O - output):
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
Nell'esempio il comando INTF coordina la versione del protocollo e QUIT termina la sessione, * è un messaggio informativo a cui il server non risponde, ma che viene registrato nel log.
All'interno del protocollo sono sviluppate delle estensioni più specializzate per eseguire le seguenti attività:
- Elaborazione del corpo del messaggio
- Autenticazione esterna
- Implementazione del sistema di banner
- Aggiunta delle richieste RADIUS per autenticazione
- Bilanciamento del carico nel cluster
Tutte le attività possono essere collegate alla pagina dell'interfaccia WebAdmin Impostazioni->Generali->Helper.
La directory principale di Communigate Pro (la directory contenente i dati utente) è usata come punto di riferimento per tutti i percorsi dei file eseguibili.
Elaborazione del corpo del messaggio
L'elaborazione dei messaggi di posta è avviata da una regola di posta come la seguente:
Una descrizione dettagliata dei comandi di questo e altri helper è disponibile nel manuale dell'amministratore.
Gli helper di questo tipo sono utilizzati principalmente per collegare i programmi anti-virus e anti-spam a CommuniGate Pro.
Autenticazione esterna
Il protocollo helper per l'autenticazione esterna è generalmente utilizzato se:
- Il metodo di autenticazione richiesto non è supportato dal server
- Alcuni account si trovano in un sistema diverso (es. Active Directory)
- È richiesto un routing complesso
- È richiesta la gestione esterna di servizi/impostazioni dell'account
Su questa pagina sono disponibili degli esempi di helper.
Altri helper
Gli helper del sistema di banner offrono al server banner per XIMSS, HTTP e altri client.
Gli helper RADIUS permettono di aggiungere ulteriori controlli sul protocollo RADIUS nel processo di autenticazione.
Gli helper di bilanciamento del carico gestiscono il bilanciatore del carico in una configurazione cluster di CommuniGate Pro.
WSSP
WSSP (Web Server-Side Pages) è un linguaggio per i modelli di pagine Web.
Ogni interfaccia Web è costituita da tre tipi di file:
- File statici: grafica, stili, ...
- File WSSP
- File di linguaggio e di righe
La distribuzione di CommuniGate Pro include un piccolo set di interfacce Web standard (stock). Una tra queste non ha nome (Unnamed), mentre le altre hanno nome. Queste interfacce dimostrative sono memorizzate nella directory Application del server (la directory del sistema operativo in cui si trovano i file eseguibili) e per questo sono sostituite all'aggiornamento del server. Gli amministratori non devono modificare le interfacce dimostrative, dato che all'installazione di aggiornamenti tali cambiamenti possono essere persi. Le interfacce sono organizzate su una struttura gerarchica per agevolarne la modifica.
Gerarchia dei file nelle interfacce
Ogni interfaccia può essere relativa a server, dominio o standard.
Durante l'elaborazione delle richieste, normalmente è necessario trasmettere i file delle interfacce con determinati nomi dal browser al server. Se il file non è trovato nell'interfaccia del dominio, il server continua a cercare, per gerarchia, un file con lo stesso nome nell'interfaccia del server. Se non è trovato nell'interfaccia del server, la ricerca continua nello stock. Se il file non è ancora trovato e l'interfaccia corrente ha nome, il file verrà ricercato nelle interfacce senza nome.
In questo modo, caricando i propri file su un'interfaccia server senza nome, l'amministratore del server è in grado di utilizzare i propri file invece di quelli standard.
Questa tecnica consente di apportare piccole modifiche alle interfacce standard, nonché creare interfacce personalizzate.
File delle righe
I file .data contengono i dati di testo (UFT-8) nel formato del dizionario CG/PL. Questi dati sono utilizzati da vari moduli del server per formare le righe nell'interfaccia e trasferire i valori delle impostazioni account.
I dati di questi file formano anch'essi una gerarchia, per le chiavi nel dizionario. Se una chiave non è presente nel file strings.data dell'interfaccia di dominio, il server tenta di trovarlo nel file strings.data a livello di server, ecc.
L'inglese è la lingua predefinita per le righe dell'interfaccia. Se la lingua dell'utente (sessione) è diversa dall'inglese, i valori delle chiavi dei file di lingua (french.data, russian.data) sostituiscono i valori dei file strings.data.
Questo sistema permette di includere interfacce leggermente modificate, cambiando solo i file strings.data e solamente le chiavi i cui valori sono stati modificati (es. nome società, nome marca), anziché un set completo.
Elaborazione di richieste
Quando il browser si connette al server sul protocollo HTTP, il server recupera il nome host dalla richiesta e cerca il dominio corrispondente a tale nome. Se il dominio è trovato, il server trova l'interfaccia selezionata come interfaccia Web predefinita per gli utenti di questo dominio e lancia la pagina login.wssp dell'interfaccia.
I file wssp consistono nel codice di marcatura (di solito HTML) e in alcuni elementi aggiuntivi:
- testo delimitato su entrambi i lati da un doppio simbolo % (%%element%%)
- la struttura inizia con il marcatore "<!--%%" e finisce con il marcatore "-->"
Un esempio di tale documento:
<html>
<body>
<h1>Benvenuti in %%server%%. Il tuo login %%ID%%.</h1>
<!--%%IF EXISTS(lastLogin)-->
Ultima connessione %%lastLogin%%
<!--%%ENDIF-->
</body>
</html>
I valori delle chiavi dei file .data nell'interfaccia formano "l'ambiente". Dopo l'elaborazione sul server, tutte le strutture speciali sono sostituite con le righe o array di righe di questo "ambiente", quali nome di dominio, valori delle impostazioni e altri oggetti.
Tutti gli altri file sono semplicemente trasferiti al client.
Le interfacce dimostrative Web di base possono essere considerate come esempi di opzioni di pagine WSSP. Le richieste ai vari moduli e l'espletamento di qualsiasi azione sul server, nonché la conversione di formati dei dati WSSP sono tuttavia limitati. Per eseguire le attività che richiedono tali azioni sono utilizzati i seguenti strumenti.
CG/PL
In questo articolo sono riportate informazioni dettagliate sul linguaggio CG/PL e sviluppo di applicazioni PBX.
Inoltre PBX viene utilizzato nello sviluppo delle interfacce Web di CommuniGate Pro. L'elenco dei file, anche per l'interfaccia Web di base (Utenti->Interfacce), comprende 14 file con piccoli programmi CG/PL, che elaborano le richieste HTTP.
Per accedere al programma CG/PL per l'elaborazione di una richiesta HTTP, è necessario crearlo in qualsiasi editor di testo, salvarlo come .wcgp e caricarlo in un'interfaccia Web.
Successivamente, una richiesta URL del tipo:
http://domain.name:[port]/programFile.wcgp/?Skin=skin_name
avvierà il programma.
http://domain.name:[port]/auth/programFile.wcgp/?Skin=skin_name
sarà eseguito dal nome dell'account precedentemente autenticato.
http://domain.name:[port]/sys/programFile.wcgp
Questa richiesta cerca il programma unicamente nell'interfaccia Unnamed del server dal nome utente postmaster (amministratore del server).
Di seguito è presentato, a titolo esemplificativo, un piccolo script che esegue il comando CLI "listaccounts" e converte il risultato in formato JSON:
entry sysEntry is
void(executeCLI("listaccounts mymac.ru"));
accountList = Vars().executeCLIResult;
SetHTTPResponseCode(200);
SetHTTPResponseData(ObjectToJSON(accountList));
end entry;
XIMSS
L'alta funzionalità del server (voce, messaggi istantanei, posta elettronica, file server, ecc.) a volte introduce alcune difficoltà nello sviluppo di un client unificato. È necessario scegliere e sviluppare una libreria che implementa SIP, set di protocolli *DAV, SMTP, IMAP, XMPP. In questo caso il carico sull'analisi dei messaggi e formati dei dati di questi protocolli spetta al client.
Come soluzione a questi problemi, abbiamo sviluppato il protocollo XIMSS, XML Interface to Messaging, Scheduling and Signaling.
Tutti i comandi di questo protocollo sono dei semplici documenti XML con attributi evidenti. Ad esempio, questo semplice comando inoltra (fork) la chiamata in arrivo a due utenti:
C:<callRedirect id="A018" callLeg="inp003" >
<To>user1@example.com</To><To>user2@example.com</To>
</callRedirect>
S:<response id="A018"/>
Tutti i formati dati (MIME, vCard) raggiungono il client XIMSS in una forma di comodo utilizzo.
Questo protocollo, inoltre, permette di eseguire tutti i comandi CLI disponibili al server: è possibile cambiare tutti i tipi di impostazioni, comprese quelle amministrative.
Per alcune piattaforme sono state elaborate delle librerie XIMSS.
Come esempio di varie funzionalità di client XIMSS, consigliamo l'applicazione Samoware. È possibile testare la versione Web demo sul nostro sito demo.communigate.ru.
Un unico protocollo invece di 10
In CommuniGate Pro ogni attività può essere svolta attraverso un unico protocollo XIMSS: visualizzare mail, calendario e rubrica, effettuare chiamate o amministrare il server, senza la necessità di studiare i numerosi standard internazionali.
![]() |
|