Les bonnes pratiques

Les bonnes pratiques

1.    Introduction 
En choisissant Nixxis Contact Suite, vous offrez le meilleur à votre centre d’appel et à ses utilisateurs. Afin de vous 
procurer toujours mieux, nous travaillons constamment sur l’amélioration du système.   Afin de bien comprendre l’utilité de ces modifications, nous vous expliquons dans cet article les changements importants apportés à NCS 2.1.  

2.    Chaînes de connexion du serveur applicatif 
Les chaînes de connexion sont très largement utilisées dans les fichiers de configuration du serveur applicatif. Lorsque vous déployiez une plateforme NCS dans la version précédente, il était nécessaire d’adapter un certain nombre de chaînes de connexion, principalement dans “Http.config”. Ce procédé a été drastiquement réduit afin d’éviter des tâches répétitives menant à de potentielles erreurs.  
Dans NCS 2.1, les chaînes peuvent être automatiquement générées sur base d’un schéma de chaînes de connexion spécifié au niveau du domaine : 
 
<domain id="default" domainType="http"  host="192.168.1.1:8088"  
  connectionString="Integrated Security=SSPI;Persist Security Info=False;Data 
Source=localhost;Initial Catalog={1}"> 
 
Ce schéma spécifie comment les chaînes de connexion seront générées par les différentes applications définies dans le domaine. La partie identifiée par “{1}” sera substituée par l’id. d’application. Par exemple, considérez la section suivante sous le domaine précédemment décrit: 
 
   <application id="admin" name="CrAdmin" type="NixxisAdminApp"> ... 
   </application>  

L’application “admin” utilisera “Integrated Security=SSPI;Persist Security Info=False;Data Source=localhost;Initial Catalog=Admin” comme chine de connexion.  
Les applications ont également la possibilité de passer outre les chaînes de connexion et cela en partie ou en totalité: 
 
    <application id="agenda" > 
    <add key="connectionString" value="Initial Catalog={1}_{2}" /> ... 
    </application> 
 
Cela signifie que la chaîne de connexion utilisée pas l’application agenda utilisera “agenda_context” comme catalogue initial de chaîne de connexion.  
Les « remplacement des paramètres » dans les schémas de chaîne de connexion sont les suivants : 
• 0: le code du compte (également connu comme l’id du domaine) 
• 1: l’id d’application 
• 2: élément ou contexte spécifique à l’application  
Vous trouverez plus d’informations dans le chapitre “Databases concepts” de la documentation NCS 2.1 API.

3.    Installation du serveur applicatif 
Dans les versions précédentes de NCS, l’installation ou la suppression s’effectuait à travers l’outil “InstallUtil”, généralement grâce au fichier de commande lançant l’outil sur les divers assembly  de NCS.   

3.1  Installation 
Le déploiement du serveur applicatif se fait en exécutant le “CrAppServer.exe” assembly avec un paramètre spécifiant le déclanchement de l’installation. 
CrAppServer.exe -install 
Veuillez noter que ceci déploiera les compteurs de performance et créera le service “ContactRoute Application Server”, des opérations nécessitant des droits administrateur.  

3.2  Suppression 
Tout comme c’est la cas pour l’installation, la suppression du serveur applicative se fait à travers l’exécutable fournissant les paramètres appropriés : 
CrAppServer.exe -uninstall 
Bien évidemment, cette action requière également des droits d’administration.  

4.    Serveur de reporting NCS  
Le service “CrReportingServer” nécessitait le module pour générer les bases de données statistiques à partir des événements bruts générés par le serveur d’application. Ce n’est plus le cas dans NCS 2.1 puisque cette fonctionnalité a été intégrée dans le service principal: “ContactRoute Application Server”. Cela ne signifie pas que le “générateur de statistiques” ne peut pas être déployé sur une machine séparée: cela signifie simplement que si vous avez besoin de diviser les services, plusieurs services “CrAppServer” seront déployés en utilisant différentes valeurs “Http.config” pour spécifier les modules chargés.  
Dans “Http.config”, la section qui décrit le “générateur de statistiques” est identifiée au moyen de  “NixxisReportingApp” comme montré dans l’exemple qui suit: 
 
<application id="reporting" name="CrReporting" type="NixxisReportingApp"
preload="true"> 
   <add key="ReportingDatabaseConnectionString" value="Initial 
Catalog=ContactRouteReport"/> 
   <add key="NixxisReportingDatabaseConnectionString" value="Initial
Catalog=NixxisReporting"/> 
   <add key="StateMachineFolder" value="{1}"/> ... 
</application>  
Notez comment les clés des chaînes de connexion spécifient les bases de données statistiques. De la même manière, faites attention au schéma spécifiant l’emplacement du dossier « state machine » (le sous-dossier “reporting” dans l’échantillon). 
   
5.    Reporting 
NCS 2.1 inclut la possibilité de déclencher des rapports standards de l’application client Nixxis. Pour cela, il est important de configure certaines clés dans le fichier “Http.config”. 
Les premiers paramètres sont liés à l’application admin comme montré dans l’exemple suivant:  
 
<application id="admin" name="CrAdmin" type="NixxisAdminApp"> 
   <add key="reportServerUrl" value="http://192.168.1.1/ReportServer"/> 
   <add key="reportsBasePath" value="Nixxis administrator"/> 
   <add key="reportsStatsBasePath" value="/"/> 
    
“reportServerUrl” est assez évident et indique le service web SSRS. 
“reportsBasePath” spécifie le dossier contenant les rapports administratifs utilisés pour imprimer les listes. 
“reportsStatsBasePath” spécifie le répertoire d’origine contenant les rapports déployés. 
Le dernier point mais non le moindre, les identifiants doivent être fourni afin de permettre l’accès aux rapports. Ceci s’opère à travers la section “credentials” comme montré ci-dessous: 
 
<credentials> 
   <add credential="\Reporting:ReportingPwd" roles="NixxisReportingRole"/> ... 
</credentials>  

En plus de spécifier les identifiants utilizes lorsque de l’accès aux rapports, cette entrée est également utilisée au moment de la creation de la base de données pour ajouter les utilisateurs et roles approriés à la base de données. Notez bien que la section “Credential” doit être présente au moment de la creation de la base de données ; lorsque les bases de données sont créées, l’ajout de la section identifiant ne va plus altérer la BD.  Veuillez également noter le format particulier utilize dans la specification utilisateur et mot de passé. Pour plus d’informations, consultez la section “ContactRoute.Data.UserCredential” de la documentation API NCS 2.1. Pour les installations standards, il est recommandé d’utiliser les identifiants Windows plutot qu’un identifiant SQL pour le NixxisReportingRole. Ceci permet au client concerné de s’autentifier aussi au niveau de  l’ HTTP. Si plus d’une entrée est définie avec NixxisReportingRole, la dernière dans la liste est celle qui sera utilisée par le client.  

6.    Fournisseurs télécom et sip peers 
Bien que le choix des fournisseurs télécom était déjà possible dans les version précédentes de NCS, il a maintenant un role critique dans la configuration de NCS. Afin que votre téléphonie fonctionne correctement, la valeur appropriée  doit être spécifiée dans le paramètre « Code transmis à la passerelle » de définition du fournisseur. Cette valeur doit correspondre à la définition d’un peer sur la passerelle média Nixxis. Pour plus d’informations à ce sujet, vous pouvez consulter “Nixxis Contact Suite V2.1 Asterisk configuration”. 

7.    Cloud 
Une grande partie des modifications du comportement qui ont été décrites jusqu’à maintenant son liées à la philosophie du Cloud. Dans le même sens, certains exemples de fichiers de configuration pour le Cloud sont maintenant fournis.  Ils sont “HttpCloud.config”, “SipCloud.config” pour le serveur applicatif et  “sip_sample_cloud.conf” pour la passerelle média Nixxis. Ces fichiers peuvent être ignore si vous installez une plateforme autonome.  
   
8.    Composeur d’appel, EventServer 
Le composeur d’appel et les applications de l’eventserver, hébergés par le “ContactRoute Application Server” avait pour habitude de compter sur leur propre fichier de configuration spécifié dans “Http.config”. Ce n’est plus le cas à présent : toutes les touches de paramétrage peuvent maintenant être inclues directement sous la section application. Notez que le nouveau fichier “Http.config”  ne spécifie aucune touche dans la section du composeur d’appel, correspondant à une situation standard, avec les paramètres identiques à une plateforme NCS d’une précédente version.  

9.    Licensing 
Les premières versions de Nixxis fournissaient l’outil d’octroi de licences “License.exe”. Cet outil était principalement utilisé pour solliciter la requête initiale de licences ou pour les renouveler.  
Avec NCS 2.1, plus besoin de ça puisque la fonction d’octroi de licences a été intégrée dans le code serveur. Pour solliciter une nouvelle licence, vous pouvez lancer le serveur applicatif dans une console utilisant “-license” comme argument. Pour renouveler vos licences, il est fortement recommandé d’utilisé le plan de maintenance intégré avec le serveur applicatif.  

10.    Fichiers SQL  
Précédemment, Nixxis fournissait le “TranslationsV2.sql” et “install_NixxisReporting.sql” qui étaient utilisés pour la traduction et that were used for translation and reporting stored procedure creation purposes... 
Avec NCS 2.1, the SQL batches are no longer used as the server is executing the appropriate code to create itself the database objects. Translations strings are automatically created based on the content of the “Translations.sql” file located in the application server folder: this SQL file is executed only in the case of a missing “AgentTranslations” table.  

11.    Media server upgrade related 
In asterisk 1.8, language syntax has changed and some settings keys have been altered. An important key used in NCS context is the “canreinvite” setting. This has been renamed to the “directmedia” key. Pay particular attention when upgrading asterisk version. 
Another point that must be taken into account when upgrading the media server is the “documents root” of the “lighttp” module. Depending on versions and “lighttpd.conf” settings, it is possible that the folder structure included in the installation archive does not fit the folder structure really used by the “lighttp” module.





    • Related Articles

    • NCS v3.x - Procédure d'installation et de configuration (FR)

      Introduction Le but de ce document est de vous guider à travers le processus d'installation et de configuration du serveur d'application Nixxis Contact Suite V3.x. 1. Prérequis Prérequis généraux : Il est essentiel de vous assurer que les prérequis ...

    • Best practices

      1.    Introduction  This article explains important changes that have been included in NCS 2.1. It provides information about installation of new servers but also about upgrading an existing system.  2.    Application server connection strings  ...

    • NCS v3.x - Procédure de mise à niveau et de configuration 3.0 vers 3.1.x (FR)

      Introduction Le but de ce document est d'expliquer comment mettre à jour le logiciel NCS de la version 3.0 à la version 3.1.x Dans les étapes ci-dessous, on suppose que le logiciel NCS a été installé sur le disque C:. Si ce n'est pas le cas, veuillez ...

    • NCS v3.x - Installation and configuration procedure

      Introduction The purpose of this document is to guide you through the installation and the configuration process of Nixxis Contact Suite V3.x Application Server. 1. Prerequisites General prerequisites: Important to make sure prerequisites are ...

    • Général - Composeur d'appels - Premiers pas

      Introduction Le dialer, numéroteur ou encore composeur d’appel est une des forces de la plateforme NCS. Il permet de générer les appels sortants. Il est donc primordial de bien comprendre comment il fonctionne afin d’en tirer le meilleur. Ci-dessous ...