Risposte al Forum Create
-
Articoli
-
Buongiorno, il timeout dello script è di 3 secondi e non è configurabile. Quando lo script va in timeout non viene innescata l’azione di fallimento del nodo IVR, ma scatta l’azione di default “Termina chiamata”.
Salve,
abbiamo provveduto a verificare le problematiche segnalate e ad aggiornare il vostro SERI di riferiemento; potreste effettuare una nuova prova e darci un feedback?
Grazie per la pazienza e buon lavoroSalve,
ci scusiamo per il ritardo con cui rispondiamo ma abbiamo avuto difficoltà a verificare le problematiche segnalate nei nostri sistemi, dove i comandi hanno sempre funzionato. Dobbiamo verificare nel vostro SERI di riferimento il possibile verificarsi di uno scenario che abbiamo evidenziato come potenziale causa dei disservizi; a breve posteremo la soluzione definitiva.A presto e buon lavoro
Salve,
abbiamo aggiornato il vostro SERI di firerimento; potreste fare una nuova prova e darci conferma della correzione?
Grazie e a prestoSalve,
potrebbe trattarsi di una problematica a livello di passaggio della funzione sul SERI del vostro cluster; verifichiamo con il programmatore di riferimento e vi diamo una soluzione al più presto.Cordiali saluti
Salve,
di seguito un esempio in PHP che opera l’import massivo:< ?php // URL $url = 'http://[your integration host]:3542/PBX/seri_endpoint.php'; $params = array('token' => ‘[your integration module token]’,
‘service’ => ‘phonebook_import_sync’,
‘verbose_output’ => 1);if (!empty($params))
{
$parts = array();
foreach ($params as $name => $value)
$parts[] = $name.’=’.$value;$url .= ‘?’.implode(‘&’, $parts);
}// POST
$items = array();
$items[] = array(“name” => “Gustavo”,
“surname” => “Fring”,
“company” => “Los Pollos Hermanos”,
“numoffice” => “0733123123”,
“numhome” => “0733456456”,
“nummobile” => “3339876543”,
“numsms” => “3339876543”,
“nummobil2” => “3339876543”,
“numfax” => “0733998877”,
“numother” => “0254739399”,
“email” => “gustavofring@yahoo.com”,
“uc_app_name” => “ESA”,
“uc_external_id” => “1”);$items[] = array(“name” => “Walter”,
“surname” => “White”,
“company” => “Car Washing Inc.”,
“numoffice” => “555123123”,
“numhome” => “555456456”,
“nummobile” => “5559876543”,
“numsms” => “5559876543”,
“nummobil2” => “5559876543”,
“numfax” => “555998877”,
“numother” => “55554739399”,
“email” => “walterwhite@yahoo.com”,
“uc_app_name” => “ESA”,
“uc_external_id” => “2”);$items[] = array(“name” => “Saul”,
“surname” => “Goodman”,
“company” => “Goodman Lawyer”,
“numoffice” => “06123123”,
“numhome” => “06456456”,
“nummobile” => “069876543”,
“numsms” => “069876543”,
“nummobil2” => “069876543”,
“numfax” => “06998877”,
“numother” => “0654739399”,
“email” => “saulgoodman@yahoo.com”,
“uc_app_name” => “ESA”,
“uc_external_id” => “3”);$items = json_encode($items);
$postparams = array(“contacts” => $items);
$postparams = http_build_query($postparams);// HEADERS
$headers = array(“Content-Length: “.strlen($postparams));
// INIT
$ch = curl_init();
curl_setopt($ch, CURLOPT_URL, $url);
curl_setopt($ch, CURLOPT_POST, true);
curl_setopt($ch, CURLOPT_POSTFIELDS, $postparams);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
curl_setopt($ch, CURLOPT_HTTPHEADER, $headers);// SEND REQUEST
$result = curl_exec($ch);
$error_code = curl_errno($ch);
$error_msg = curl_error($ch);
$info = curl_getinfo($ch);curl_close($ch);
// OUTPUT
echo ‘
‘; if ($info[‘http_code’] != 200 || $error_code != 0) { echo ‘Error: ‘.$info[‘http_code’]; echo “\r\n”; echo ‘Code: ‘.$error_code; echo “\r\n”; echo ‘Message: ‘.$error_msg; } else { echo ‘POST successfull!’; echo “\r\n”; echo ‘Server resp:’; echo “\r\n”; echo “\r\n”; echo ‘‘.htmlentities($result).’‘; } echo ‘‘;
?>Per quanto riguarda la gestione a regime, ad oggi non ci sono comandi che operano una eliminazione massiva dei contatti, quindi l’opzione migliore sarebbe quella di effettuare manutenzione puntuale sfruttando gli ID contatto.
Salve,
chiedo scusa per il ritardo con cui rispondiamo ma deve essere saltato il meccanismo di notifica dei post.
Comunque, il problema non è cosa accade in fase di ricerca, ma in fase di importazione; a causa dell’utilizzo di un external_contact_id non univoco l’importazione ha comportato la problematica che poi si evidenzia in fase di ricerca.
Sconsigliamo inoltre di non utilizzare l’external_contact_id perché resta uno strumento di garanzia di univocità del contatto che permette la corretta manutenzione del sistema di synch delle rubriche, soprattutto quando eseguito in maniera massiva.Saluti
Salve,
faccio una premessa fondamentale: dalla versione 2.4.12 abbiamo introdotto una distinzione fra contatti veri e propri (persone fisiche) e Contatti aziendali, ossia Aziende che oggi possono avere una loro anagrafica ed una loro serie di recapiti e che fungono da contenitori di contatti (in quanto persone fisiche).
Detto questo, venendo alla vostra problematica abbiamo verificato che oggi, eseguendo il comando di get_phonebook, il risultato contiene, fra gli altri, due contatti (un con ID 23910 ed uno con ID 29318) che mostrano lo stesso external_contact_id = 03840440238. Il nostro algoritmo per l’inserimento è la ricerca preventiva di coppia app_name e external_contact_id; probabilmente in fase di inserimento voi avete specificato lo stesso external_contact_id per i due contatti ed il PBX ha fuso il secondo con le informazioni di Fer tech.
A livello di configuratore, in effetti, la visualizzazione, che potrebbe sembrare diversa, in realtà non lo è; in effetti, cercando nella sezione Rubrica–>Aziende otteniamo due contatti con nome azienda Turbotrix; il primo al suo interno contiene proprio i recapiti riferiti a Fer tech (mail e numero), a riprova che il contatto Fer tech deve essere stato aggiunto con il medesimo external_contact_id.
Vi chiediamo di verificare che l’inserimento dei contatti abbia sempre preveduto external_contact_id univoco; se così non fosse, troverete di certo altre asimmetrie di questo tipo.Cordiali saluti
Buongiorno e grazie per averci contatto.
Analizzeremo le informazioni che ci ha fornito con i nostri sviluppatori e vi forniremo una risposta appena possibile.Cordiali saluti
Supporto Integrazione VOIspeed
Salve,
il problema è legato ad una modifica del SERI sul vostro modulo di integrazione; in pratica il SERI precedentemente usato è stato modificato ed avete bisogno delle nuove credenziali. Si tratta di un’operazione che non viene eseguita normalmente se non con adeguata comunicazione precedente. Ci scusiamo per l’incoveniente e provvediamo subito ad inviarvi le nuove credenziali (SERI e token).Salve,
nelle attuali versioni le notifiche vengono inviate dallo stesso HOST (SERI) verso il quale inviate anche i comandi; dalla versione 2.2.x che abbiamo in rilascio in questi giorni (per cui, se non lo siete ancora, sarete presto aggiornati) le notifiche verranno invece inviate dal PBX. Generalmente sono lo stesso IP ma per sicurezza potete riferirvi, in questo secondo caso, all’HOST SIP.
Per quanto riguarda il metodo, si tratta sempre di una GET.Salve,
la paginazione a 100 contatti può andar bene. Per la cancellazione, è corretto usare il comando “delete_phonebook” usando come parametro la chiave esterna.Salve,
per la richiesta relativa all’update della rubrica, il suo commento è corretto. La coordinata che discrimina insert o update è la coppia app_name + external_contact_id. Mantenendo un app_name sempre fisso, quindi, va bene considerare il solo external_contact_id.Per la cancellazione puntuale si può usare il comando specifico riportato nella documentazione. Questo comando prevede anch’esso i parametri app_name ed external_id che consentono di individuare un contatto precedentemente inserito tramite il phonebook_import_sync. Alternativamente questo comando può selezionare i contatti tramite il parametro contact_id, che è l’ID interno della rubrica VOIspeed. Questi ID vengono restituiti in output dalla chiamata a phonebook_import_sync (scegliendo di avere un output verboso), per cui il sw di terze parti può decidere di associare i propri identificativi a quelli interni VOIspeed. Ci sono quindi due approcci per la cancellazione puntuale dei contatti
Commenti recenti