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
Connection strings are extensively used in application server configuration files. When deploying a NCS platform in previous versions, it was required to adapt a lot of connection strings, mainly in “Http.config”. This process has been drastically reduced to avoid repetitive tasks leading to potential mistakes...
In NCS 2.1, connection strings can be automatically generated based on a connecting string pattern specified at the domain level:
<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}">
This pattern specifies how connection strings will be generated by the various applications defined in that domain. The part identified by “{1}” will be substituted by the application id. For example, consider the following section under the domain previously described:
<application id="admin" name="CrAdmin" type="NixxisAdminApp"> ...
</application>
The “admin” application will use “Integrated Security=SSPI;Persist Security Info=False;Data Source=localhost;Initial Catalog=Admin” as connection string.
Applications also have the possibility to override partially or totally connection strings. If we consider the following agenda application:
<application id="agenda" >
<add key="connectionString" value="Initial Catalog={1}_{2}" /> ...
</application>
This means that the connection string used by the agenda application will use “agenda_context” as connection string’s initial catalog.
The replacement parameters in connection string patterns are:
More information can be found chapter “Databases concepts” of the NCS 2.1 API documentation.
3. Application server installation
In previous versions, installation and removal were done through the “InstallUtil” tool, generally by the mean of a batch file launching the tool on the various NCS assemblies. This process is no longer needed.
3.1 Installation
Deployment of the application server is done by executing the “CrAppServer.exe” assembly with a parameter specifying that the installation should be triggered.
CrAppServer.exe -install
Please note that this will deploy performance counters and create the “ContactRoute Application Server” service, operations requiring administrator rights.
3.2 Removal
As it is the case for installation, the application server removal is done through the executable, providing the appropriate parameter:
CrAppServer.exe -uninstall
Of course, this action also requires administrative rights.
4. NCS Reporting server
The “CrReportingServer” service used to be the module required to generate statistical databases from the raw events generated by the application server. This is not the case anymore in NCS 2.1 as this functionality has been integrated into the main service, “ContactRoute Application Server”. This does not mean that the “statistical generator” cannot be deployed on a separate machine: it simply means that if splitting services is needed, multiple “CrAppServer” services will be deployed using different “Http.config” values to specify the modules loaded.
In “Http.config”, the section describing the “statistical generator” is identified by “NixxisReportingApp” type as seen in the following example:
<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>
Notice how the connection strings keys are specifying the statistical databases. In the same way, pay attention to the pattern specifying the location of the state machine folder (the “reporting” subfolder in the sample).
5. Reporting
NCS 2.1 includes the possibility to trigger standard reporting from the Nixxis client application. In order to achieve that, it is important to configure a few keys in “Http.config” file.
First settings are related to the admin application as seen in following sample section:
<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” is quite self explanatory and point to the SSRS web service.
“reportsBasePath” specifies the folder containing administrative reports used for printing lists.
“reportsStatsBasePath” specifies the root folder containing the deployed reports.
Last but not least, credentials must be provided in order to allow accessing the reports. This is done through the use of “credentials” section as shown in the following sample:
<credentials>
<add credential="\Reporting:ReportingPwd" roles="NixxisReportingRole"/> ...
</credentials>
In addition to specifying the credentials used when accessing the reports, this entry is also used at database creation time to add the appropriate users and roles to the databases. Notice that the credential section has to be present at DB creation time; when databases are created, adding the credential section will not alter DB anymore.
Please note the particular format used in the user and password specification. For more information, consult the “ContactRoute.Data.UserCredential” section of NCS 2.1 API documentation. For standard installations, it is recommended to use a Windows credential instead of a SQL credential for the NixxisReportingRole. This allows the reporting client to also authenticate at the HTTP level. If more than one entry is defined with NixxisReportingRole, the last one in the list is the one that will be used by the client.
6. Carriers and sip peers
Although carriers were already available in previous NCS versions, they have now a critical role in NCS configuration. In order to have telephony working properly, the appropriate value must be specified in the “Code transmitted to gateway” parameter of the carrier definition. This value must match a peer definition on the Nixxis Media Gateway. For more information, please consult “Nixxis Contact Suite V2.1 Asterisk configuration”.
7. Cloud
A big part of modifications in behavior that have been described so far are related to the cloud philosophy. In the same direction, some sample configuration files for the cloud are now provided. They are “HttpCloud.config”, “SipCloud.config” for the application server and “sip_sample_cloud.conf” for the Nixxis Media Gateway. These files can be ignored if installing a standalone platform.
8. Dialer, EventServer
The dialer and eventserver applications, hosted by the “ContactRoute Application Server” used to rely on their own configuration file specified in “Http.config”. This is not the case anymore: all settings keys can now be included directly under the application section. Please notice that new “Http.config” sample file specify no key at all under the dialer section, corresponding to a standard situation, with settings identical to a NCS platform of a previous version.
9. Licensing
In previous versions Nixxis was providing the “License.exe” licensing tools. This tool was mainly used for requesting the initial license request or for renewal purposes.
With NCS 2.1, this is no longer the case as the licensing function has been included inside the server code. To request a new license, one can launch the application server in a console using “-license” as argument. For renewal purposes, it is strongly advised to use the maintenance plan integrated with the application server.
10. SQL files
In previous versions Nixxis was providing “TranslationsV2.sql” and “install_NixxisReporting.sql” that were used for translation and reporting stored procedure creation purposes...
With 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.