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.
The following table provides a quick reference for well-known plugin identifiers:
21F19BA23527461EAE84F4C350BACCC9 Api
85247C616C9545D7954B15C416ECB7B8 HTTP Chat
C7476D0D0D194771849028A672ED559B Ticketing
E0738FBB653F4461AA3EA4DC5C648FE0 SIP
EF105D29E15140A7A86BF869AA7EB90E Pop3
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.
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.”
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”
For example, ProviderConfigSettings is upate to “<Root><Config name=\"HTTP Chat\" providerid=\"85247C616C9545D7954B15C416ECB7B8\"></Config></Root>” for all chat activities.
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.
The following sections describe actions that should be manually done in config files and administration database.
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"
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"/>
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"
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
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"/>