Monday, February 20, 2017

Unable to cast object of type 'System.String' to type 'Sitecore.Analytics.Reporting.ReportDataProvider'

Sitecore + WFFM

You can face the following exception:
Exception: System.InvalidCastException
Message: Unable to cast object of type 'System.String' to type 'Sitecore.Analytics.Reporting.ReportDataProviderBase'.
Source: Sitecore.Forms.Core
   at Sitecore.Forms.Core.Dependencies.DefaultImplFactoryObjectsProvider.CreateObject[T](String configPath, Boolean assert)
   at Sitecore.WFFM.Analytics.Dependencies.ReportDataProviderWrapper.GetReportDataProviderBase(Boolean assert)
   at Sitecore.WFFM.Analytics.Providers.AnalyticsFormsDataProvider..ctor(ReportDataProviderWrapper reportDataProviderWrapper, ILogger logger, IAnalyticsTracker analyticsTracker, ISettings settings)

If it's a CD + CM server, you should remove the highlighted node from the App_Config\Include\Z.SwitchMasterToWeb\SwitchMasterToWeb.config file:

<reporting>
  <dataProvider>
<datasources>
 <add key="item">
<FiltersFactory>
 <param desc="definitionDatabaseName">web</param>
</FiltersFactory>
 </add>
 <add key="collection">
<FiltersFactory>
 <param desc="definitionDatabaseName">web</param>
</FiltersFactory>
 </add>
 <add key="reporting">
<FiltersFactory>
 <param desc="definitionDatabaseName">web</param>
</FiltersFactory>
 </add>
</datasources>
  </dataProvider>
</reporting>

This is fixed in Sitecore 8.1 Update-1 (bug number - 96933).

If it's a CD server, please comment out the whole <reporting> node because it's trying to patch the Sitecore.Analytics.Reporting.config file which has to be disabled on a CD server.

Friday, February 3, 2017

The Analytics.ClusterName and Analytics.HostName settings


I will try to explain the purpose of each setting.

Very short

The Hostname setting is important only for multi-clustered environments. For the environments, which are not multi-clustered the setting is not important. But, there is a known issue with multi-site environments when the setting isn't empty. Therefore, you just need to keep the setting empty. It shouldn't be empty only in a multi-clustered environment with an only one site.

The Clustername setting is also used in multi-clustered environments (each cluster must have its own value of the setting). But, it's important for non-clustered environments too. It should be set to the domain name. This is related to both servers CM and CD. If it is empty, there is another known issue.

Details

The main purpose is scaling ability. The main idea of these settings is the following.
For example, you have 40 geographically distributed CD servers:

  • 10 in Australia;
  • 10 in Asia;
  • 10 in Europe;
  • 10 in the USA.

There is a sense to group them into 4 CD clusters. Each cluster will have its own session and shared session databases. But here we need a mechanism which will not allow a situation when the first request will be served by one cluster and the second request from the same user will be served by another cluster. Therefore, each of our clusters will have its own Analytics.Clustername setting, for example:

  • cluster1.site.com
  • cluster2.site.com
  • cluster3.site.com
  • cluster4.site.com

When the first visit of a visitor comes to cluster3.site.com, for example, this cluster will get (or create) a contact in the Mongo Analytics database and add the { "Lease.Owner.Identifier": "cluster3.site.com" } field to the contact. Which means that this cluster has locked this user. If the second request from the same client comes to another cluster, it will be redirected back to cluster3.site.com because this cluster serves the client and this cluster's session databases have the actual session data of the client. But even in a non-clustered environment, this setting is used to lock the contacts. Therefore, it's important to set it to the correct hostname on both CM and CD servers. Also, this host should be accessible from the CM.

Hostname setting, in this case, should be set to the main domain name - site.com which is under a load balancer. If the setting is not empty, Sitecore doesn't allow the first request in session to be made directly to a cluster. The first request is expected to be made to the host whose name is specified in Analytics.HostName setting which is under the load balancer that will redirect the first request to the most geographically appropriate cluster. But there is a known issue with multisite solutions since any site will be redirected to Hostname.