Different way of controller rendering in Sitecore. Differences & Doubts

I recently downloaded the latest version of Sitecore which is 8.2.X. And when i was playing with default vanilla instance, i met few things related to controller rendering new which led me dig into it. So, here i am sharing my experience with controller rendering in Sitecore. I am not sure if that is the case with everyone or i interpreted few things wrong. Intention for writing this is to spread my view as well have opinion of community experts stating what’s true and what’s not.

Doubts

After installing Sitecore 8.2 vanilla version, i found that there is a folder inside /sitecore/layout/ named Controllers just like we had models.

000It was present there since some previous versions. Not exactly sure from which version and why. So, i tried to figured out how to use it.

  1. As we can see there are only two fields which is Controller Name and Action Name which we generally comes with Controller Rendering. So, first thought comes in mid if there is some separation of these two fields from controller rendering. But that isn’t a case. We can see both fields present in the Controller Rendering.
  2. For models we creates a model in /sitecore/layout/models folder and link it to view rendering with the help of model field present in view rendering Similar way i tried to check if controller rendering has such field or not (No sense to have it in View rendering at all, neither to have it in controller rendering. But checked if there is some mystery) but couldn’t find.
  3. I than tried to find such thing in layout (again doesn’t make sense, but checked once) but couldn’t found any link.
  4. I also tried to add it to presentation details (taught if can be used in similar way of controller rendering) but couldn’t add any item rather than renderings.

So, it’s still doubtful thing for me, as i couldn’t use it anyway. Anyone got any more idea on this? come forward and share the secret.

Another thing which i specifically found in sitecore version 8.2.X is that sitecore helper also have a new method called ControllerRendering similar to ViewRendering which was there along with Rendering method. In prior than 8.2.X versions, we already had Controller method. So, now in 8.2 onward, we have two methods specifically related to controller. I tried to figure out difference between these two and below is my conclusion.

Differences

I setup one MVC project for my POC website. than i added two areas into that one called SiteA and another SiteB. Both area were having same structure, having one controller named Home, one action inside controller named Index, and a view called Index.

001

I also created one MVC layout and two renderings to load the index action from home controllers. one for SiteA area and another for SiteB area.

002003

All set with the configuration and prep work. let’s use each methods one by one and note the findings.

Controller
I added below markup in the layout.
004
Output was expected. With area and controllers with same name exists, it was going to raise an error saying found two controller for the request.
005
Without area and having unique controller will work fine with this method.
Note that this can be resolved by adding the custom routes to the route table. but we intent to check default behavior here.

Using Controller method and without writing custom pipeline to add custom routes, It won’t be able to resolve Area.

Using Controller method, you are not calling any renderings. It directly instantiate the controller and invokes it. It won’t obey neither mvc.renderRendering nor mvc.getRenderer pipelines. So, you can’t use benefit of caching the html output either.

Rendering
Now, i replaced layout with below markup.
006

Using this method, you can render any type of rendering, be it View Rendering or Controller Rendering. You just require to pass the path or id of the rendering item. We are dealing with the rendering items and with having specified Area name in both the controller rendering, expected output is that it should resolve the area. And it does.
007
It will run the mvc.renderRendering pipeline. Where Area will be resolved by RenderingDefinitionAreaResolveStrategy. Also, as we are directly refering rendering items, we do have specifications for caching and Html caching feature will also work properly.
008.png

009
Only thing is that it will call mvc.getRenderer pipeline but won’t be able to resolve the type of rendering which is RenderingType. And will end up being resolved by GetDefaultRenderer. Unless you are using RenderingType property to determine which type of rendering it is, It is likely to solve the purpose.

Controller Rendering
Sitecore 8.2+ introduces this additional helper method. In the release note, you will find that this is included for better handling controller rendering.  I replaced layout with below markup
010
with the expectation that both the method should resolve correctly. But i ended up with similar error as Controller method for Controller Rendering.
005
As Controller Rendering won’t instantiate controller directly, It will resolve the renderer and likely to run mvc.getRenderer and mvc.renderRendering pipelines. I was expecting it to work as Rendering method. But as we are not referring rendering items directly and we aren’t specifying anything related to area so it also make sense that it couldn’t resolve area. I than tried to specify the area in the layout itself.
011
With the hope that now, it should resolve the area with the help of RenderingLayoutAreaResolveStrategy. But it didn’t. If you dig into this strategy than it checks if RenderingType is Layout than get layout and read value from area field. In our case using Controller Rendering method and mvc.getRenderer pipeline, GetControllerRenderer will resolve it as RenderingType Controller. Adding custom area resolve strategy may solve the issue. So, that’s one possibility to resolve area where it’s even not possible in Controller method.

I was hoping that Html Caching should work but by not referring rendering item directly, we do not have values of renderingargs. So, i really wonder why we would use this method against Rendering method? Anyone have answer, Let’s share.
giphy (1).gif

Basically, i do not have any conclusion at the end of this post. But i wanted to share what i ended up experiencing. And wanted to know the experience of community experts on this topic. so that we could have better understanding of the difference between above methods.

Simple. Not Easy.

giphy

 

Simple. Not easy – Copy/Move Children – Content Editor

Today i thought to write the first blog in “Simple. Not easy” series. It may seem very basic for the Sitecore experts but i personally found it so much helpful so the Content Editors will be.

Why Copy/Move Children is  really helpful?

Generally Content Editor comes up with full loaded utility commands like Copy, Move, Delete, Delete Sub Items, Duplicate etc. But while working with one of the migration task in a project, I ran into a situation where i was required to copy all child items of particular item into another location. For ex: /sitecore/content/home1 has 50 child items and i need to move it to something /sitecore/content/global/pages. Now only option i find is to copy individual items from /home1 to /pages.

That is a very tedious task. For developers, there might be good options to do it Programmatically or by using Powershell script. But if content editor needs to perform these steps than it is a good idea to create a custom command CopyChildrenTo/MoveChildrenTo similar of Delete Sub Items. What you need to do is extract the code for copyto and moveto and apply the simple logic to copy children instead of selected item.

Create a command

Copy Children

using Sitecore.Data.Items;
using Sitecore.Diagnostics;
using Sitecore.Shell.Framework.Commands;
using System;
using System.Collections.Generic;

namespace Demo.POC.Extension
{
    [Serializable]
    public class CopyChildrenTo : Command
    {
        ///
<summary>Executes the command in the specified context.</summary>

        /// <param name="context">The context.</param>
        public override void Execute(CommandContext context)
        {
            CopyChildren(context.Items);
        }

        ///
<summary>Queries the state of the command.</summary>

        /// <param name="context">The context.</param>
        /// <returns>The state of the command.</returns>
        public override CommandState QueryState(CommandContext context)
        {
            Error.AssertObject((object)context, "context");
            if (context.Items.Length != 1)
                return CommandState.Disabled;
            Item obj = context.Items[0];
            if (obj.Appearance.ReadOnly || !obj.Access.CanRead() || !context.Items[0].Access.CanWriteLanguage())
                return CommandState.Disabled;
            return base.QueryState(context);
        }

        ///
<summary>Copy children.</summary>

        /// <param name="items">The items.</param>
        /// <param name="message">The message.</param>
        public static void CopyChildren(Item[] items)
        {
            Assert.ArgumentNotNull((object)items, "items");
            if (items.Length == 0)
                return;
            List<Item> objList = new List<Item>();
            foreach (Item obj in items)
            {
                objList.AddRange((IEnumerable<Item>)obj.Children.ToArray());
            }
            Sitecore.Shell.Framework.Items.CopyTo(objList.ToArray());
        }
    }
}

Move Children

using Sitecore.Data.Items;
using Sitecore.Diagnostics;
using Sitecore.Shell.Framework.Commands;
using System;
using System.Collections.Generic;

namespace Demo.POC.Extension
{
    [Serializable]
    public class MoveChildrenTo : Command
    {
        ///
<summary>Executes the command in the specified context.</summary>

        /// <param name="context">The context.</param>
        public override void Execute(CommandContext context)
        {
            MoveChildren(context.Items);
        }

        ///
<summary>Queries the state of the command.</summary>

        /// <param name="context">The context.</param>
        /// <returns>The state of the command.</returns>
        public override CommandState QueryState(CommandContext context)
        {
            Error.AssertObject((object)context, "context");
            if (context.Items.Length != 1)
                return CommandState.Disabled;
            Item obj = context.Items[0];
            if (obj.Appearance.ReadOnly || !obj.Access.CanRead() || !context.Items[0].Access.CanWriteLanguage())
                return CommandState.Disabled;
            return base.QueryState(context);
        }

        ///
<summary>Move children.</summary>

        /// <param name="items">The items.</param>
        public static void MoveChildren(Item[] items)
        {
            Assert.ArgumentNotNull((object)items, "items");
            if (items.Length == 0)
                return;
            List<Item> objList = new List<Item>();
            foreach (Item obj in items)
            {
                objList.AddRange((IEnumerable<Item>)obj.Children.ToArray());
            }
            Sitecore.Shell.Framework.Items.MoveTo(objList.ToArray());
        }
    }
}

Config patch
Create a custom config patch file to include these new commands as shown below. Copy this config to anywhere in the website/App_Config/Include folder.

<configuration xmlns:patch="http://www.sitecore.net/xmlconfig/">
  <sitecore>
    <commands>
      <command  patch:after="*[@name=copyto]" name="item:copychildrento" type="Demo.POC.Extension.CopyChildrenTo,Demo.POC.Extension" />
      <command  patch:after="*[@name=moveto]" name="item:movechildrento" type="Demo.POC.Extension.MoveChildrenTo,Demo.POC.Extension" />
    </commands>
  </sitecore>
</configuration>

Context Menu Item
Create a Context Menu items for both the commands as shown in below image in Core database under /sitecore/content/Applications/Content Editor/Context Menues/Default/Copying.

Copychildren-1

Copychildren-2

In Action

Copychildren-5

Copychildren-6

Any content editor there, Did you find this helpful? Or share other such issues you face in day to day activity.

Sitecore Helix – Converting existing Sitecore solution into Helix standards

Helix is a set of overall design principles and conventions for Sitecore development. With the evolution of Sitecore itself and large enterprise solutions growing as per company’s business, there is a requirement to define a standard which simplifies the Sitecore development as well maintenance.

Helix is most buzzed word you will hear nowadays. Most of the Sitecore solutions provider has adopted this standard principle while delivering new and all upcoming Sitecore Web Applications. It is little hard to move from the traditional development (vary by person to person) to Helix standards. But once you are familiar with the terms/Standards, Believe me – You will likely love it. There is a well written documentation on  Helix, Habitat – An example solution based on Helix standards which you can refer as example of Helix, And there are many courses/presentation going on Helix.

We talked about how Helix is changing the whole way we develop the Sitecore web application. What about websites already build on Sitecore before we even heard about Helix? I recently got a chance to work on an existing website build on sitecore to make required changes so that solution become more maintainable and as per new standards for future development. I considered one of the thing to reach our goal is to convert it to Helix standards. Based on my experience doing this, We will be talking about

  • Should we convert existing websites to Helix standards?
    • No, What are the reasons for not doing?
    • Yes, How we can do that?

Should we convert existing websites to Helix Standards?

No, Unless you are willing to convert whole application into Helix standards. which generally does not seems to be possible. You will ask why?, Let’s see what are the reasons of not converting existing websites to Helix standards

What are the reasons for not doing?

Although, Helix gives many benefits, I found below points which were stopping me to perform this conversion into Helix standards:

  • Limited Business Context:
    instead-of-i-dont-know
    In a large organization, where an application gets growing over several years of span time, It is very difficult to find out the person who has the complete business context. It is very difficult to understand the business context from application from mid way, we might not know the actual reasons for some of the implementations. The biggest risk of the limited business context is, while conversion we may break the functionalities unknowingly. For ex: Miss some of the code while conversion, Miss some of the references, Miss some of the hard coded IDs & Paths, Miss some Datasource related changes in Sitecore Items due to new Structure/Items, We cleanup some of the unwanted things which is there for future development etc.
  • Limited Time:
    your-time-is-limited-so-dont-waste-it-living-someones-life-steve-jobs-1-728
    As website is already developed and serving business need, we might not get the time as much as we develop a new website. Converting existing web application to Helix standards requires huge amount of time as much as new development from scratch we can say. So, with the limited time duration, we might end up doing mix of traditional and Helix standards. Which is not a good solution from the eye of a good solution architect.
  • Limited Knowledge of Helix:
    quote-integrity-without-knowledge-is-weak-and-useless-and-knowledge-without-integrity-is-dangerous-and-samuel-johnson-95971While working along with different set of people in different teams (In house team, Consultant team etc.), It is very difficult to set the rules and expectations. Although, there are set of rules and recommendations mentioned in Helix standards, One may act differently. For ex: One developer created Foundation for few set of feature, few will create Feature for same, others may argue that it should be in Project and rest just doesn’t follow Helix standards and place everything except Feature/Foundation/Project. This will again end up in duplicate, inconsistent, difficult to understand code/structure.
  • Not adding business value:
    cartoon-why_vision_is_imp
    Spending so much time, money, and efforts and at the end not getting direct business value might not impress to many business people. And i think it is right too at some point of time. Q: What business value it will add? Ans: More development in standard way, Less efforts and time  going forward, and maintainability. Q: What business value it will add right now? Ans: can’t think off.

These are the several factors to keep in mind before jumping in converting everything into Helix standards. But if knowing all these points, we really wanted to convert the existing Sitecore website eventually into Helix standards, we can do in below way.

How we can do that?

Considering fact that we can not start developing existing websites in Helix standards along side existing website. It will than become a development from scratch which is going to take many months, and with this separate development to convert existing website to Helix standard, there will also be some modification and new feature in existing website. Merging these new feature along way with new development is not going to be an easy job.

The approach we can take:

  • Create a blank structure as per Helix standards. https://www.npmjs.com/package/generator-helix. It is now also available as Visual Studio template https://github.com/LaubPlusCo/LaubPlusCo.Helix.VsTemplates
  • Add one empty project application which can act as a heart. No need to jump to Feature and Foundation at this stage.
  • Create a Foundation project named Legacy. Why Foundation and not Feature/Project layer for this purpose?

    Ans: The reason why I’ve put it into Foundation layer is because we can also start implementing new features etc. but we need to make sure that the “old” project still works. So basically we have the Vanila Sitecore instance at the bottom, on top there is the old project and on top of that we can implement new stuff and/or move stuff out of the old project Also one point why it’s not in the Project layer is because, of the references. If you convert part of it into Feature Layer, you cannot have a reference to the Project Layer. But you can have one to the Foundation Layer. Thanks to @nadinelendzian for discussion on this.

  • Put everything from old solution under this Legacy Foundation project.
  • Make sure at this point everything is working fine as it was.
  • Eventually start separating out functionality into different Feature/Foundation/Project layer.

Please find below images as an example:

Before Helix

Sitecore Content Tree

old-1
Content
old-2.1
Layouts
old-2
Renderings
old-3
Templates

Visual Studio Solution
NonHelixVS

After Helix

Sitecore Content Tree

new-1
Renderings
new-2
Layouts
new-3
Templates

Visual Studio Solution
HelixVS

These are some of the example of how an existing solution can be converted to Helix standards gradually.

Again it is my personal view, If you have some other thoughts on converting existing Sitecore websites to Helix standards, I would love to hear that.

I love Helix 🙂

 

Sitecore xDB Cloud 2.0 – Using RestAPI for xDB Cloud Service to solve many purpose

In previous posts, we discussed what is xDB Cloud, Advantages/Disadvantages, Useful Terminologies, How to configure etc. In disadvantages, we seen that we could not connect xDB Cloud directly using tool like Robomongo and MongoVUE. Limiting the action we can perform on MongoDB over On-Premise setup. To overcome this, Sitecore has come up with xDB Cloud RestAPI, not strong enough but maturing steadily. Using which you can perform different operations.

Let’s understand each methods with an example. I use Postman for such purpose. It is a tool build on top of Chrome with lots of cool feature.

You must use a valid authentication token whenever you make a call to the xDB Cloud API. Which can be generated by using a valid Sitecore license file to call the SSO Encode Sitecore License endpoint. You must include the generated token as a HTTP header in all other requests called X-ScS-Nexus-Auth

https://gateway-sso-scs.cloud.sitecore.net/api/License/Encode/

E2k5QvJ

This is the first step you need to perform as all other endpoint requires X-ScS-Nexus-Auth for authentication.

Once you have obtained the token, first thing you wish want to get is list of xDB sets. In response you will get all xDB set listed and DeploymentId for each. Once you have noted LicenseId and DeploymentId, you will be able to make API calls to get information specific to xDB set (DeploymentId). This endpoint becomes very handy when you haven’t received DeploymentId(s) from Sitecore Support.

https://gateway-xdb-scs.cloud.sitecore.net/api/xdb/{licenseId}

uXEw7IJ

Once you have obtained list of xDB sets, you will wish to get the Connection Strings for one of the xDB set (DeploymentId) as it is a vital part in configuring the xDB Cloud. This endpoint becomes very useful when you haven’t received any information about xDB Cloud like Connection Strings, ReportingService from Sitecore Support. With this method in place, you will be able to get all the information required for your setup.

https://gateway-xdb-scs.cloud.sitecore.net/api/xdb/connectionstrings/{licenseId}/{deploymentId}

FXVAO8G

This is also one of the important thing to successfully complete the xDB Cloud setup. Even though you have done all configuration right, but your infrastructure not configured properly, it won’t allow application to connect to MongoDB. Hence, no data will be written to xDB Cloud. Use this endpoint to get all URLs and ports specific to URL. And you have to enable the outbound connections over given ports in Firewall.

https://gateway-xdb-scs.cloud.sitecore.net/api/xdb/firewallsettings/{licenseId}/{deploymentId}?v=2

BUjwk2w

You can utilize this endpoint as a tool to verify weather data is getting stored in xDB Cloud or not. By providing year and month in endpoint URL, you will get informations like Total Interactions, Interactions Added, Total Contacts, Contacts Added etc. per day basis.

https://gateway-xdb-scs.cloud.sitecore.net/api/xdb/Consumption/{licenseId}/{deploymentId}/{year}/{month}

WFn5eJ8

This endpoint also helps like above one to verify weather data is getting stored to xDB Cloud or not by retrieving collections. Collections includes Interactions as well Contacts.

https://gateway-xdb-scs.cloud.sitecore.net/api/xdb/collection/{licenseId}/{deploymentId}

J3p47VZ

This endpoint is useful to get information about xDB set (DeploymentId) such as Sitecore Version (Not sure why it is there), xDB Cloud Version (1.0/2.0), And Deployment Type (Prod/Non Prod).

https://gateway-xdb-scs.cloud.sitecore.net/api/xdb/version/{licenseId}/{deploymentId}

5hVNcsw

This endpoint will be used to ensure xDB Set (DeploymentId) working well or not. This will return Status, Message, and IssueIdOnError. You will find the message if there is any issue with xDB Set. Make a note of IssueIdOnError if you get that in response because you need to provide it to Sitecore Support team when you contact them about the issue with your xDB Set.

https://gateway-xdb-scs.cloud.sitecore.net/api/xdb/{licenseId}/{deploymentId}/status

cVGxtqE

This is a very useful endpoint which will be used to rebuild the Reporting database. Make note that you won’t be able to rebuild the reporting database using admin page in case of xDB Cloud. This is the method which will do the work for you. When calling this method, it should return “In Process” as response. That means rebuild of reporting database for that specific xDB Set has been started.

https://gateway-xdb-scs.cloud.sitecore.net/api/xdb/historyProcessing/{licenseId}/{deploymentId}

DP1Z09E

Get history processing status

Once you have triggered the rebuild Reporting database with help of above method and received response as “In Progress”, you will want to know the status of that task to determine weather it got completed successfully or encountered with an error. By triggering this same API as above again, you will get status of that operation in response. Possible values are Done, In Process, Error, and None.

https://gateway-xdb-scs.cloud.sitecore.net/api/xdb/historyProcessing/{licenseId}/{deploymentId}

L94HZxR

So, that’s it from the xDB Cloud 2.0 series. Aim was to provide everything at a single point from understanding to Configuration, troubleshooting etc. so that it can save a couple of days for someone.

Enjoy xDB Cloud.

Sitecore xDB Cloud 2.0 – Configuration, Connection, and Troubleshooting

In earlier, blog posts we discussed the basics of xDB Cloud, some of the advantages and disadvantages of using xDB Cloud as well some useful terminologies. Now we will see how to configure xDB Cloud for various environments. Consider below versions of the resources for our exercise:

  • Sitecore Experience Platform 8.1 rev. 160519 (8.1 Update-3)
  • xDB Cloud 2.o
  • Sitecore xDB Cloud 8.1 rev. 160721

Configuration

  • Get xDB subscription by getting in touch with Sitecore. Make sure it is attached with your license id. If you make any change to your licensing than reassure it is still attached with the xDB Cloud. Consider the usage and requirement of business subscribe a number of xDB Cloud database set required.

  • Once you have subscribed for xDB Cloud, To request an xDB Cloud 2.0 customer set, You required below things:

    • Your License ID (11111111111111). Get it from the license file. Sitecore 8.1 now requires a license with the “Sitecore.xDB.base” key to enable all features of the Experience Platform. If your license file does not contain this key, Sitecore will default to Experience Management (CMS-only) mode. Any customers or partners with a license to Experience Platform should contact their account manager or login to SPN if they are missing this key.
    • Your Deployment Id (COMPANYPROD81). Get it based on a role of the instance like Dev, Stag, Prod etc. If you do not receive it from Sitecore support, get it using Rest API.
    • The version of Sitecore that you are running (8.1 rev. 160519).
    • The preferred location for your xDB Cloud environment. See the xDB Cloud Service compatibility tables for compatible data center locations. Though, you don’t required it to specify anywhere.
    • MongoDB connection strings:
      analytics, live, tracking.history, tracking.contact. If you do not receive it from Sitecore support, get it using Rest API.
    • A Search index connection string (applicable to Sitecore 8.2.1 and later): cloud.search.
    • Reporting service settings, including the address of the service and the thumbprint of the SSL certificate. If you do not receive it from Sitecore support, get it using Rest API.
  • Download xDB Cloud Client based on Sitecore version and xDB Cloud version. In our case, we needed to download Sitecore xDB Cloud 8.1 rev. 160721. Check https://kb.sitecore.net/articles/966080 for xDB Cloud Service compatibility tables.

  • Now, we need to Enable/Disable the config files as per the role we are configuring.

    • CM: Enable/Disable the files as described in https://doc.sitecore.net/sitecore_experience_platform/81/setting_up_and_maintaining/xdb/configuring_servers/configure_a_content_management_server and Config Enable Disable spreadsheet. Note: based on the version of Sitecore, this will be very.
    • CD: Enable/Disable the configs as described in https://doc.sitecore.net/sitecore_experience_platform/81/setting_up_and_maintaining/xdb/configuring_servers/configure_a_content_delivery_server and Config Enable Disable spreadsheet. Note: based on the version of Sitecore, this will be very.
    • CM + CD (Development): Ensure that the following configuration files are disabled or removed from your local installation by adding .disabled to the end of the file name.
      File path (relative to the website root) Configuration file name
      /App_Config/Include Sitecore.Analytics.Processing
      .Aggregation.Services.config
      /App_Config/Include Sitecore.Analytics.Processing
      .Services.config
      /App_Config/Include Sitecore.Analytics.Tracking
      .Database.ScaledCM.config
      /App_Config/Include Sitecore.MarketingProcessing
      Role.config
      /App_Config/Include Sitecore.PathAnalyzer
      .Processing.config
      /App_Config/Include/CES Sitecore.CES.DeviceDetection
      .CheckInitialization.config
      /App_Config/Include/ContentTesting Sitecore.ContentTesting
      .Processing.Aggregation.config
      /App_Config/Include/ExperienceAnalytics Sitecore.ExperienceAnalytics
      .Aggregation.config
      /App_Config/Include/ExperienceAnalytics Sitecore.ExperienceAnalytics
      .ReAggregation.config
      /App_Config/Include/ExperienceAnalytics Sitecore.ExperienceAnalytics
      .StorageProviders.config
      /App_Config/Include/ExperienceAnalytics Sitecore.ExperienceAnalytics
      .Reduce.config
  • Configure a content management server to use a remote Reporting Service Server as per https://doc.sitecore.net/sitecore_experience_platform/setting_up_and_maintaining/xdb/configuring_servers/configure_a_content_management_server_to_use_a_remote_reporting_service_server Specify ReportingServiceUrl given by Sitecore Support. If you do not receive it from Sitecore support, get it using Rest API.

  • For xDB Cloud 2.0, Update the Path Analyzer configurations. If you connect to a dedicated remote reporting instance, then the content management server no longer has direct access to the Sitecore.Analytics SQL Server reporting database. Instead, the Path Analyzer client retrieves data from a remote reporting server with direct access to the SQL database using Web API services. To enable the Path Analyzer client to communicate with the remote reporting server, make the following configuration file changes:

    Configuration file Folder Enable Disable
    Sitecore.PathAnalyzer
    .RemoteClient.config
    App_Config/Include Picture 154
    Sitecore.PathAnalyzer
    .Processing.config
    App_Config/Include Picture 155
    Sitecore.PathAnalyzer
    .Services.RemoteServer.config
    App_Config/Include Picture 156
  • In the XdbCloud folder (Website/App_Config/Include/xDBCloud), delete the following files. If they already have the extension.disabled it is a good idea to delete them at this point.

    • Sitecore.Cloud.Xdb.config
    • Sitecore.ContentSearch.Cloud.Index.Analytics.config
    • Sitecore.ContentSearch.Cloud.Default.IndexConfiguration.config

 

  • Use the Sitecore Installation Wizard to install the Sitecore xDB Cloud 8.1 rev. 160721 package.

  • To configure instance to communicate with dedicated Azure services of Sitecore xDB Cloud

    • In the fileConnectionStrings.config(Website/App_Config), configure the MongoDB database connection strings by using the connection strings from the response that you received from Sitecore Support. If you do not receive it from Sitecore support, get it using Rest API.The MongoDB connection strings:
      • analytics
      • tracking.live
      • tracking.history
      • tracking.contact

      Note: For a CD instance, you do not require the tracking.history connection string.

    • In the ConnectionStrings.config file (Website/App_Config), add the analytics.cloud.index Connectionstring. Which you generally do not find in ConnectionStrings.config
    • In the ConnectionStrings.config file (Website/App_Config), ensure the following connection string is removed:<add name="reporting" connectionString="Data Source=…"/>
    • In the Xdb Cloud folder (Website/App_Config/Include/xDBCloud), enable the following configuration file:
      • Sitecore.Cloud.Xdb.config

      For versions prior to 8.2 Update-1, also enable below config files:

      • Sitecore.ContentSearch.Cloud.DefaultIndexConfiguration.config
      • Sitecore.ContentSearch.Azure.Index.Analytics.config
        (There isn't such config file available. Enable below config file instead.)
        Sitecore.ContentSearch.Cloud.Index.Analytics.config
    • In the folder (Website/App_Config/Include/), disable the following configuration files:
      • Sitecore.ContentSearch.Lucene.Index.Analytics.config
      • Social\Sitecore.Social.Lucene.Index.Analytics.Facebook.config
    • In the Sitecore.Cloud.Xdb.config file (Website/App_Config/Include/Xdb Cloud), configure the reporting service by using the actual Service URL and SSL certificate thumbprint from the response that you received from Sitecore Support, for example:
      <httpTransportFactory patch:instead="httpTransportFactory" type="Sitecore.Cloud.Xdb.CloudBasedTransportFactory, Sitecore.Cloud.Xdb" singleInstance="true">
      <param desc="serviceUrl">[reporting service URL]</param>
      <param desc="certificateThumbprint">[SSL certificate thumbprint]</param>
      </httpTransportFactory>

      By setting this reporting service properly, you will able to see experience analytics reports working on your Sitecore instance. Still you need to confirm if analytics data are getting stored to MongoDB or not.

  • To complete the xDB Cloud client configuration and connection to the xDB Cloud service, you must deploy marketing definitions.

    • On the Sitecore Launchpad, click Control Panel, Analytics, Deploy marketing definitions.
    • In the Deploy marketing definitions dialog box, select all of the definitions and taxonomies and click Deploy.

Connection

After successfully configuring xDB Cloud for your website, you will be very eager to test it by connecting to MongoDB. But unfortunately there isn’t a straight forward of doing same as you cannot connect to xDB Cloud using Robomongo or MongoVUE tool.

These are the best possible ways doing same:

  • Using Rest API like
  • By generating some random traffic on the site, and by manually or technically doing Session Abandon to reflect the Contact details in Experience Profile.
  • Give a unique name to the site definition rather than website, and generate the random traffic to get the unique site name reflected in Analytics Reports when Session ends.
  • If none of the above trick work than there is maximum chance of connectivity issue, means your data is not getting saved to MongoDB. But still as last option, you can contact Sitecore Support and request full database set collections as backup. By examining the backup collections, you can confirm weather data is getting stored or not.

Troubleshooting

While configuring/connecting xDB Cloud, I ran into several issues. Below are some note on that if you face the same, can save your day by applying these tweaks:

  • While deploying Marketing Definitions to complete the configuration/setup, i was getting following error:
    MarketingDefinitions
    Kiran Patil – Maiden Indian Sitecore MVP, found following error in log file Could not find configuration node: marketingDefinitions/asset/repositories/remote.
    And with his analytical ability he was able to solve this by enabling following config file Sitecore.Xdb.Remote.Client.MarketingAssets.config in \Website\App_Config\Include\
  • While data was getting stored to xDB Cloud at one infrastructure without touching Firewall settings, at another infrastructure it was not getting saved by performing all same steps mentioned above. By checking log file I found error ERROR unable to connect to a member of the replica set matching the read preference primary.
    One of the thing i tried to get rid of this error is removing replica set and secondary servers from ConnectionString which didn’t solved the issue but ended up changing error to ERROR Unable to connect to server *.mongolab.com:[port]: Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host..
    I ended up reverting the change. And looking into Firewall related settings. Will share my learning once i solve the issue.

 

Sitecore xDB Cloud 2.0 – Useful Terminologies

In earlier, blog post we discussed the basics of xDB Cloud, some of the advantages and disadvantages of using xDB Cloud. Now it’s time to jump on the battle field to configure the xDB Cloud on the local environment. But before moving ahead to configuration and connection, let’s walk through few terminologies which will help you understand each and every configuration very well throughout the setup.

  • The xDB Cloud Set – a set of cloud services and connected databases that implement on-premise xDB functionality off-premise in the cloud. This functionality includes the ability to collect and process experience data, as well as contact search and segmentation. In a simple word, It is the set of databases like analytics, tracking.live, tracking.history, tracking.contact, analytics.cloud.index which you generally found in your connectionstring.config.

  • LicenseId – It refers to the Id of your Sitecore license. It will be required while doing Rest API calls which you will see in future blog posts.

  • DeploymentId – Every xDB Cloud set assigned a DeploymentId. Id using which you identify the different set/role. For ex: If we have purchased two xDB Cloud set one for Stag and one for Prod than we will have to correspond DeploymentId. For ex: XYZSTAG01, XYZPROD01. This will be very helpful along with LicenseId while making Rest API call for various purposes.

  • DeploymentType – Type of the xDB Cloud set, either Prod or Non-Prod.  Generally, you don’t need to specify the Deployment Type anywhere. Prod type won’t have reporting related to dataset.

  • SitecoreVersion – The Sitecore version, on which a site is running. There will be little change in configuration based on Sitecore version. We will consider Sitecore Experience Platform 8.1 rev. 160519 (8.1 Update-3) for rest of the blog series.

  • XdbCloudVersion – Version of the Xdb Cloud. Xdb Cloud 1.0/2.0 are available. Based on which Cloud set you have, it requires different configuration.

  • xDB Cloud Client – A package responsible for copying required xDB Cloud DLLs and Config files when installing. It will be different based on Sitecore Version and XdbCloudVersion.

  • XdbConnectionStrings – Connectionstring for all analytics databases like analytics, tracking.contact, tracking.history, tracking.live, analytics.cloud.index etc.

  • ReportingServiceUri – You cannot access reporting SQL database directly in Cloud. You have to access it using a service. So, service for reporting called ReportingServiceUri needed to be updated in one of the config files for xDB Cloud.

  • ReportingServiceCertificate – It is a certificate id provided by Sitecore Support or Rest API, which is required to securely talk with reporting service. It also needed to update in config along with ServiceUri.

Knowing these terms will give you a better understanding of overall xDB Cloud set. And you are now eligible for the configuration and connection which will take place in next blog post.

Go Cloud 🙂

featured-enterprise-cloud-strategy-eBook

Sitecore xDB Cloud 2.0 – What it is? Advantages and disadvantages over On-Premise setup

Sitecore and Cloud

Sitecore extensively looking to offer the cloud offering after joining the party with Microsoft in 2016. In an effort to that, Sitecore now available as an App Service on Azure. Have a look at it https://azuremarketplace.microsoft.com/en-us/marketplace/apps/Microsoft.AppSvc_SiteCore_xp?tab=Overview/ Along with this, Sitecore also supports xDB service completely on the cloud (xDB Cloud) if you are running Sitecore 8.0 or higher.

What is included in Sitecore xDB Cloud?

Sitecore xDB Cloud Edition is a managed service that enables you to run Sitecore xDB entirely in the Cloud. This service includes dedicated Sitecore application servers for processing, aggregation, and reporting.

  • Microsoft SQL Server reporting database
  • MongoDB collection database
  • Contact segmentation index

xDB Cloud overview-Picture 1-rId10-1173281914

That means, When using xDB Cloud offerings, you do not need to take care of reporting, aggregation, and processing server. Your CM and CD environments will be limited to their job of serving site only rather than acting as processing server too which will make them healthy.

Why it is important?

The Sitecore xDB Cloud service provides the following benefits over an on-premise installation:

  • A simpler infrastructure
  • Reduced upfront costs
  • Reduced maintenance costs
  • Increased reliability, provided by the Microsoft Azure cloud platform and the MongoLab (mlab) service for MongoDB databases.
  • A fully managed service that includes Sitecore updates and monitoring. Sitecore continuously monitors the xDB Cloud Sets to minimize system downtime.

Also refer to the fine blog post, which helps you define what solution fits your requirements, either on-premise or on the cloud.

xDB_DecisionTree
Source: http://www.nonlinearcreations.com/Digital/how-we-think/articles/2015/07/Sitecore-xDB-to-Cloud-or-not-to-Cloud.aspx

Let’s also understand some of the things which are not supported by xDB cloud:

  • The downside is that you don’t have direct access to the various collections. So, you can’t connect using a tool like Robomongo or MongoVUE. However, you can request a full export of the xDB Collection database through support.sitecore.net
  • It’s important to note that the reporting SQL databases are hosted in the cloud. This includes both the primary and secondary. There is currently no way to successfully rebuild the reporting databases from the /sitecore/admin/rebuildreportingdb.aspx page. It looks like we have a Rest API for this purpose.
  • You cannot add custom facets to contacts.
  • You cannot create reports based on custom aggregations.
  • You cannot create custom database and collections, hence you have to opt for stand alone database set for different purpose (For ex: Development, QA, Stag, Prod etc.).
  • For more information on what is possible and what not, refer: https://kb.sitecore.net/articles/042722/

Though there are several limitations using xDB Cloud listed above still it’s winning the game. While Sitecore continued to expand its wings on the cloud with the help of Azure, Sitecore is saying that it’s just a beginning and you can expect a lot of things in that direction.

We will see what are the prerequisite and how to configure it for local, CM, and CD in upcoming blog posts.