NCS v3.x - Technical - What's new

NCS v3.x - Technical - What's new

Generalities

The introduction of plugins and their relations to activities and media is impacting administration in a few aspects. When upgrading an existing system, it is needed to adapt configuration to take care of the new working mode.

This document explains the actions done by the system and the ones requiring manual intervention.

 

Plugin identifiers reference

The following table provides a quick reference for well-known plugin identifiers:

21F19BA23527461EAE84F4C350BACCC9     Api

85247C616C9545D7954B15C416ECB7B8     HTTP Chat

C7476D0D0D194771849028A672ED559B    Ticketing

E0738FBB653F4461AA3EA4DC5C648FE0     SIP

EF105D29E15140A7A86BF869AA7EB90E     Pop3


Automatically done by appserver

The following sections describes the actions taken by the application server when upgrading. Please note that the order of the actions being executed is important and described hereafter in the same order as they are executed.


Modification of activities ProviderConfigSettings to use new plugins Id.

For mail, Pop3 becomes EF105D29E15140A7A86BF869AA7EB90E in /Root/Config/@providerid.

In log files, the trace “Warning: Found email activities without ProviderConfigSettings using Pop3 as providerId: updating to EF105D29E15140A7A86BF869AA7EB90E” is used when it happens. When inconsistencies are found, the following trace can be found in log file: “Warning: Found email activities without ProviderConfigSettings defined! Manual intervention will be required.


Conversion of simple campaigns to advanced when they would use more or less than one plugin

A new constraint has been introduced with the introduction of plugins related to media: a simple campaign is related to one and only one plugin.

Depending on the case, the following messages can be present in log files:

·         {count} campaigns will be converted to advanced because they use more than one plugin

·         {count} campaigns will be converted to advanced because they are not linked to activities (and therefore plugin)

For each campaign being converted to advanced, the following trace can be seen “Converting campaign {campaign id} to advanced”


Table Campaigns PluginId field is filled with appropriate value for simple campaigns.


Table activities ProviderConfigSettings field is updated with a reference to appropriate plugin for Http Chat, and SIP related activities.

For example, ProviderConfigSettings is upate to “<Root><Config name=\"HTTP Chat\" providerid=\"85247C616C9545D7954B15C416ECB7B8\"></Config></Root>” for all chat activities.


Entries are created in table Plugins for SIP, Http chat, Pop3, API and Ticketing sample

The initial state of these plugins depends on if they were used before. For example, the Pop3 plugin will only be started if at least one activity related to Mail with provider Pop3 was defined.

 

Not handled by application server

The following sections describe actions that should be manually done in config files and administration database.


CrAppServer.exe.config should not define media related plugins except SIP (special case with close relationship with appserver channels).

Remove addons (if present) with attributes:

·         name="nixxisChat" type="Nixxis.Applications.NixxisChatServer, CRHttpChat"

·         name="MailController" type="Nixxis.Applications.MailControllerAddon, CRMailController"

·         name="ApiProcessor" type="Nixxis.Api.ApiAddOn, ApiProcessor"

·         name="NixxisTicketsControllerApp" type="ContactRoute.ApplicationServer.TicketsControllerAddon, TicketsController"


Sip addon should not specify a settings file.

Addon with attributes name="SipServer" type="ContactRoute.SipServer.SipServer, CRSipServer" should not define settings="Sip.config". Resulting entry should look like:

<addon name="SipServer" type="ContactRoute.SipServer.SipServer, CRSipServer"/>


Http.config should not define any media related applications anymore.

These sections are now stored in the Administration database in Plugins table, field Settings. The structure of content of this XML field is:

<Settings configFile="">

  <application id="" name="" >

    <add key="key1" value="value1" />

    <add key="key2" value="value2" />

    

  </application>

</Settings>


The part in bold is the part that was stored in Http.config before 2.5. The enclosing Settings element should be added with its configFile attribute, left with an empty string value; this correspond to “settings” attribute that was defined on the plugin definition in previous version and kept for compatibility even if no plugin is currently using a setting file.


For example, if the API application was configured in Http.config like that:

  <application id="api" name="Api" type="ApiProcessor" debug="2" sessionLess="true" preload="true">

    <add key="directDataKey" value="MyKeyHere" />

    <add key="ServerEndpoint" value="http://*:9090/" />

    <add key="workflowsPath" value="C:\Workflows" />

  </application>

 

Then, the value of field Settings in Plugins table should be:

<Settings configFile="">

  <application id="api" name="Api" type="ApiProcessor" debug="2" sessionLess="true" preload="true">

    <add key="directDataKey" value="MyKeyHere" />

    <add key="ServerEndpoint" value="http://*:9090/" />

    <add key="workflowsPath" value="C:\ \Workflows" />

  </application>

</Settings>


Once table Plugins is correctly filled in according to these rules, the corresponding applications should be removed from Http.config. Here is the list of attributes identifying applications (if present) that should be removed from Http.config:

·         type="MailController"

·         type="SipApplication"

·         type="NixxisChatApp"

·         type="ApiProcessor"

·         type="NixxisTicketsControllerApp"


SIP plugin special case

The application section related to SIP plugins is the union of the application definition coming from Http.config (sipserver) and the domain element coming from sip.config (related to the same domain, of course).


But, as some elements have names in common but not the same purpose, some renaming is needed:

·         “Type” attribute becomes “serverType” attribute

·         “authentication” attribute becomes “sipauthentication” attribute

·         “authentication” elements become “sipcredentials” elements

In the same way, some attributes coming from the domain element in sip.config have no meaning anymore and should be removed:

·         “key” attribute

·         “domainType” attribute

·         “autoload” attribute


Handling external Administration server

As Http.config does not control the media related applications anymore, an extra setting must be used to prevent plugins to be loaded on a server dedicated to administration (else, as this server uses the same administration database, the plugins will be started if they are started on the “main” server).To prevent loading plugins, use the following entry in admin section of Http.config:

<add key="initPlugins" value="false"/>