FXM
Introduction, New releases

Extending the Reach of your Sitecore Platform using the Federated Experience Manager.

The Customer Experience Management system landscape is incredible fragmented, covering amongst others content management, online customer service, e-commerce, campaign management, analytics and tracking, personalization, automation, social media, ad management, retargeting and many more, and most organisation have multiple systems in place – not only to handle different parts of the process, but often identical systems – like multiple CMS’s – to cover the same processes.

This scenario is not likely to change in the near future.

One of the newest features of the Sitecore Platform is the Federated Experience Manager, which can help connect a fragmented digital platform and make it possible to track and reach out to all visitors across all the owned channels in an organization.

Disconnected Platforms

Before joining Sitecore in 2014, I worked the last 14 years in a company called Pentia, based in Copenhagen, Denmark and since Pentia was the company from which Sitecore originally sprung in 2001, we were almost exclusively building Sitecore solutions for Danish and international customers.

Through the years, most of the clients I worked on aquired Sitecore as a major technological investment and as a new platform for driving their marketing efforts. So building or rebuilding their brand website, customer service website or e-commerce solution – and configuring the marketing tools – was almost always a major project for them.

When this is said, almost without exception, all would be stuck with one or more legacy websites or CMS systems following the migration or implementation project. This was not because the marketing division necessarily wanted it, but typically because the technical migration of their entire web platform would be too costly – or simply because Sitecore did not feel like the a good fit for a remaining systems.

So even though a lot of hours and smart people worked on implementing Sitecore and making the marketing platform better and giving the customers a better experience, it would often feel like we were working on a part that mattered very little.

Disconnected Experiences

We often saw that the legacy websites which were not converted to Sitecore was the e-commerce platforms, the direct customer service websites or the transaction websites. In other words, the websites actually giving the most value to the visitors – and often the organisation – and where the customer experience and visitor journey tracking was most vital to the success of the whole online platform, was being kept on legacy systems and technologies that were not allowing Sitecore to help marketing and customer service.

So the result was often a bad and very disconnected customer experience.

Seemingly simple things, like the visual design changing slightly from website to website, the overall flow or information architecture being bad or simply the content being wrong, not updated or just not assisting the customer towards the goal and the conversion. Furthermore the tracking and profiling capabilities of Sitecore was severely crippled, making the investment in personalization and optimization at best poor but often simply not worthwhile.

One platform, One Experience

Personally this was why I was rather excited when I first heard about the Federated Experience Manager a while ago.

By allowing Sitecore to reach out to non-Sitecore websites and applications and track visitor behaviour across these, we can start to see the entire visitor journey on the owned platforms and profile the users accordingly. But more importantly, we can start incorporating the legacy websites into the optimization effort, assisting the visitors on making those vital transactions, or start marketing our products or services on the websites where the visitor actually is, and not just where we would like them to be.

This will allow the marketing people to get even more control over all the digital channels – and ultimately make the investment in Sitecore and their new marketing platform much more valuable.

The Sitecore Federated Experience Manager

Sitecore Federated Experience Manager, FXM, will in short allow you to track the individual visitors across Sitecore and non-Sitecore websites using javascript tags – just like you know it from other analytics tools. This will allow you to use the standard Sitecore tools for goal tracking and visitor profiling. This mechanism is pretty much independent of technology, and FXM can even be used to track non-websites such as mobile apps.

But FXM will also allow you to push content from Sitecore to non-Sitecore websites and applications. This of course means that content can be maintained in one location within Sitecore and pushed across to other platforms. But potentially this can also be used to push theming and visual elements, to assure a unified user experience across all systems.

And since all content is managed and shared though the standard Sitecore mechanisms, we can leverage all Sitecores tools including personalization and A/B testing.

Finally FXM can be used to push data back to Sitecore too. This means that events and data from the external system can be sent across to Sitecore, and by leveraging Sitecores rules engine, we can trigger marketing events in Sitecore, for example engagement automation.

FXM is available for Sitecore 7.1 and forward on SDN.

Standard
Architecture, Sitecore

Dedicated image server and Sitecore

A lot of sites which have a large amount of visitors use a dedicated image server.  There are several reasons for this, but mostly it is because that most browsers only allow a few simultaneous connections to the same domain, which stalls the download of a page that has more than two resources. For instance imagine you have a page consisting of multiple images, stylesheets and javascript files. As the clients only allows a few simultaneous downloads, the browser won’t download all the resources at the same time, but wait for each download to complete and first then start the next download.

The reason of this behavior is that the HTTP standard says that only two simultaneous connections between a client and a server should be allowed. This was specified to save servers from heavy IO load, when files where requested. Browsers like IE7 and Firefox 2 lives up to this standard and only allow 2 connections, while new browsers like IE8 and Firefox 3 allows 6 connections.
To ensure that the HTML can be fully loaded independently and without waiting for other downloads and to remove the load from the primary web server; a dedicated image server can be used. This server holds all files and uses a different domain (for instance images.mydomain.com). All files used on the page can then be fully referenced and thereby be downloaded from a different domain. Eg <img src=”http://images.mydomain.com/image1.jpg alt=”image1”/>. As the images are now on a different domain, these can be requested independently of the server providing the HTML and more simultaneous connections can be opened.

But how is this possible in Sitecore where the media library controls all the images?

One of the easiest ways is to have another publishing target for the media. In that way you will have two frontend servers: One serving the normal requests and one serving all media items. You can easily set up another publishing target and for instance use the staging module to clear the cache. Read more on SDN if you want to know how to set it up.

The remaining problem is: How do we ensure that all media items gets prefixed with another domain? Unfortunately there isn’t a simple setting for this (it will probably come in a future a release of Sitecore – I hope :)). However there is a simple solution to the problem as links are expanded by the LinkProvider, which can be overridden. More precisely the links are expanded in the LinkProvider.ExpandDynamicLink method, so we need to override this replacing the media path:

namespace TestApplication
{
  public class CustomLinkProvider : LinkProvider
  {
    public const string MEDIA_PATH = “~/media/”;

    public override string ExpandDynamicLinks(string text, bool resolveSites)
    {
      string baseExpands = base.ExpandDynamicLinks(text, resolveSites);
      return baseExpands.Replace(MEDIA_PATH, “http://images.pentia.dk/” + MEDIA_PATH);
    }
  }
}

Here I override the ExpandDynamicLinks in the inherited class CustomLinkProvider. I replace all media paths (identified by the prefix ~/media/) and replace it with the full path to the image server. The remaining thing to do is to replace the LinkProvider type in the web.config:

<linkManager defaultProvider=”sitecore”>
  <providers>
    <clear />
    <add name=”sitecore” type=”TestApplication.CustomLinkProvider, TestApplication” addAspxExtension=”true” alwaysIncludeServerUrl=”false” encodeNames=”true” languageEmbedding=”asNeeded” languageLocation=”filePath” shortenUrls=”true” useDisplayName=”false” />
  </providers>
</linkManager>

Here I just point the LinkProvider type to my own implementation.

Now that this is set up, all requests for media items will be handled by the image server. This does not just allow faster load times for the client, but will put less pressure on the main server. Further you can tune the media server to handling media items by increasing the media cache, setting the prefetch cache etc.

Enjoy your new Sitecore media server 🙂

Standard
Open source

Shared Source Modules

Great! Sitecore has extended its platform for its shared source modules on sdn. Now they offer Subversion and Trac, so that we all can help make the modules even better. That I am able to influence the modules directly, makes me seriously consider using one of these modules next time.
The logical question is: why not extend this with all the official modules? It’s not like the code is obfuscated or anything, so we can look into it anyway – and this way we can all contribute to making the Sitecore product even better.

Standard
Sitecore

Continuous Integration and Sitecore

We have recently launched our internal Continuous Integration environment for use in our many Sitecore projects. The setup is pretty straightforward with NAnt, CruiseControl.NET and Subversion in beautiful harmony. Because of the integration with Visual Studio, we would have liked to use Visual Studio Team System, but the pricing deterred us. When nAnt, CC.NET and Subversion are so cool why on earth has Microsoft set their price so high? In my view, they could have cornered the entire .NET based market by having a more relaxed price policy.
Well back to the point: We have tried to implement an environment which helps our developers and increases productivity, by removing some of the mundane tasks of developing in Sitecore. I am real excited about the prospects, so I would like to share some of the cool features we’ve implemented:

Module Library:
We have collected an entire module library, including all newer version of Sitecore, all Sitecore modules as well as all our internal modules. This means that when starting a new project, or when implementing a new modules in a project, the customer merely points the build configuration to which modules the project uses, and – hey presto – the module is included in the project. This includes code files, Sitecore packages, configuration file changes (see later) and all other related files. The point is – the project points to a module, and the module is responsible for integrating itself in the project.

Configuration files management:
We have previously had a lot of hassle trying to maintaining changes in the Sitecore web.config as well as all the other configuration files. Trying to keep all config files in all project targets (dev, test, prod, etc.) synchronized is a pain. Therefore we have developed a nAnt task which when running the build, merges project/module specific changes into Sitecores standard configuration file. I.e. when a full build is run:

  1. The standard Sitecore configuration files are copied from the Module Library (from the correct version of Sitecore)
  2. The relevant Sitecore modules standard configuration changes are merged into the configuration files
  3. Dependant on which target the build is for, the project specific configuration changes (connection strings etc.) are merged into the configuration files.

A side from keeping the configuration files synchronized, this also means that when upgrading Sitecore (a task which basically to point the project to the new version in the module library) all Sitecore’s new or changed configuration settings are automatically included.

Our CI environment also implements Subversion, MSBuild, FxCop, automatic test server deployment and installation versioning/packaging.
One of the problems we are facing with Sitecore and CI is the amount of functionality and configuration hosted in the Sitecore database. We’ve through hard about e.g. integrating the Sitecore packager with the build environment, but dropped the idea. Please let me know if you’ve done something similar.
As you can hear i’m pretty excited about this, and would really like to make it as cool as possible – so throw me a comment if you have experiences with CI/build environments and Sitecore.

Standard
Open source, Sitecore

Open source modules

For a while, Pentia has been working on a new Forum module for Sitecore. As some of you might know there are some licensing issues which causes problems with the current Community Server based implementation.
As thing are looking now, the new Forum module will be based on YetAnotherForum.NET, a .NET/MSSQL based open-source discussion forum or bulletin board system. This means that the source code for the forum system, which is licensed as GPL, will be distributed along with the module.
Hopefully this will spread as a trend within the Sitecore modules, as one of problems I often face is trying to get the restrained standard modules to work the way I, or rather the customer, wants or expects it to behave. What I find, is that we Sitecore developers today face the option of using the modules and the module functionality as is, or to code the functionality from scratch.
I truely hope that the future Sitecore modules will be more flexible and open – perhaps even the source 🙂

Standard