Experiences with Sitecore Federated Experience Manager

Over the past couple of days I’ve been a little fun with Federated Experience Manager and I’m really liking it 🙂 There’s a great deal of functionality and fun (yes I’m like that!) to be had. Especially with the concept of “hooking into” a completely independent site and tracking what pages are visit or even the concept of pushing content to other sites (we’ll explore that concept in a future blog post)

In this blog post I’ll quickly demonstrate how to quickly set up Federated Experience Manager and get started with the basics like tracking analytics.

How do I install Federated Experience Manager?

For my “independent” site I simply created a new Web Application (that contains no functionality – it’s not needed for this purpose) in Visual Studio. For this example I used ASP.NET MVC Application. What’s important to remember is that as it’s independent site to Sitecore it’s actually technology agnostic – you could have set up a demonstration in PHP or even straight HTML :).

So, once my independent site is set up it looks something like this:


As you can see, I’ve set this up to respond under http://testsite (IIS/hosts files have been configured etc.)

Now we can do the fun but and add a reference to this site in Fereration Experience Manager by adding an “External Site”:


There’s not a great deal of information to fill in here – what is very important is the “Tracking Script” (or Tracking Beacon). This is a piece of Javascript that you need to include in your independent site where you want the Federated Experience Manager to hook into. Without this script, there will be no interaction between Sitecore and your external site.

As my site is as out-of-the-box ASP.NET MVC site, I included this tracking script in the <head> element of _SiteLayout.cshtml:

<meta charset="utf-8" />
<title>@Page.Title – My ASP.NET Web Page</title>
<link href="~/Content/themes/base/jquery.ui.all.css" rel="stylesheet" type="text/css" />
<link href="~/Content/Site.css" rel="stylesheet" type="text/css" />
<link href="~/favicon.ico" rel="shortcut icon" type="image/x-icon" />
<script src="~/Scripts/jquery-1.10.2.min.js"></script>
<script src="~/Scripts/jquery-ui-1.10.3.js"></script>
<script src="~/Scripts/modernizr-2.6.2.js"></script>
<!– Tracking Beacon inserted from Sitecore Federation Experience Manager –>
<script src="//sitecore8-150223/bundle/beacon"></script>
<!– End of Tracking Beacon script –>
<meta name="viewport" content="width=device-width" />

view raw
Tacking Beacon
hosted with ❤ by GitHub

Now that we have the Tracking Script configured on our site, we should be in a position to go to the Federated Experience Manager, select our Test Site and click the “Open in Experience Editor” button. You should see the following appear:


That made me smile 🙂 My completely independent site opening in the Experience Editor in Sitecore ready for action!

For this simple example all I’m going to show is how to capture someone clicking on the Register button (you would normally plan your events ahead however this shows its simplicity). If you click the “Capture Click Action” button, you should be able to select any HTML element on the page in order to assign a click action to it. For example, if you click on the “Register” button of the website you should see that Sitecore has identified that you have clicked on an Anchor tag and allow you to assign a “click action” to it:


You can navigate to the specific element in question if you need to and when you’re happy you can click on the “Add a new action” to further define your click action:


Once you’ve given your Click Action a name, you can assign any Goals or Analytic Attributes that you already have set up in Sitecore:


The rest of the UI should be familiar to you in terms of assigning goals/outcomes etc. When this is done ensure that your changes are saved and published – and that’s it 🙂

So, what happens when we browse our site?

When we browse our test site and click on the Register link, the Tracking Beacon Javascript will now call Sitecore to register the event. This can be evidenced in Telerik’s Fiddler tool:


Checking that this has worked.

You can verify this has worked in the usual places where you expect gather reports on Experience Analytics, for example, below shows the Page URL’s that have been tracked, which includes visits to my testsite:


Also, if you take a look in the Experience Profiler, you will also see the usual profile of the visits that have occured, including visitors of your external sites as shown in the detail of a specific visit below:


I hope this has given you a taste of the level of power you have with Federated Experience Manager. So far I’ve only scratched the surface of what’s achievable. I will be exploring other concepts of FXM in future posts.

Utilising simple Data Models in your Sublayouts

In this post I’m going to demonstrate a cleaner approach of  binding information to your Sublayouts by using simple Data Models.

Over the past few years I’ve been a huge advocate for utilising Datasources for absolutely everything. This is absolutely vital if you want to leverage Testability and Personlisation  – and never assume that a piece of content will never want to be personalised, you simply cannot tell what the future holds 🙂

There are cases though where data does not come directly from Datasources but is the product of a Search or some other form of acquisition. Generally this is bound to a Repeater and the fields a loosely typed in terms of pulling the data out:

<asp:Repeater id="rptTest" runat="server">
         <%# Eval("Name") %>
         <%# Eval("Author") %>
         <%# Eval("Intro Text") %>

This post will show you an alternative approach. Nowadays I use Data Models (or View Models?) to represent the information that needs to be rendered on the front end. This ensures that there is a strongly typed class (or data set) that contains what is needed (and no more). This also ensures that we have a consistent entity which can also interact with the rest of your code. In the instance of a Repeater, you can utilise the property ItemType in order to define which Data Model is bound to the repeater. Once this is done it makes it much simpler to pull the data out of the Datasource that is bound to the Repeater.

<asp:Repeater id="rptTest" runat="server" ItemType="SitecoreJim.Entities.Book">
        <%# Item.Title %>
        <%# Item.Author %>
        <%# Item.IntroText %>

Taking this one step further

Generally when I create Sublayouts I inherit from a base class called SublayoutBase which provides a good deal of generic functionality that we use everyday in our components. I have created a new variant of SublayoutBase in which you can pass in your Model type at the point you inherit from it:

public abstract class SublayoutBase<T> : SublayoutBase
    public T Model { get; set; }

    public abstract void CreateModel();

Also in the SublayoutBase there is an abstract method called CreateModel(). As its an abstract method, the intention is that when you inherit from SublayoutBase the implementation for this method is required –  the model is created in the place that understands how to create it. Now that we have everything in place, when we bind the Data Model to the Repeater and specify the ItemType, it makes it much easier to understand what information is bound to the Repeater and where the information is coming from.

Usage in the Page Editor

Using the methods above it is actually very easy to specify an example Datasource for our repeater specifically designed for the Page Editor. In the CreateModel() method it is a simple case of checking for the Page Editor and creating an example model for rendering

public override void CreateModel()
    List<Book> books = new List<Book>();

    if (Sitecore.Context.PageMode.IsPageEditor)
        books.Add(new Book()
            Title = "Black Diamond - How we started",
            Author = "Jamie Little",
            IntroText = "This is a great book"

        books.Add(new Book()
            Title = "From Rags to Riches, back to Rags and finally to Riches again",
            Author = "Stewie Mcnaughty",
            IntroText = "This is another great book";
        books.Add(new Book()
            Title = "Sense and Nonsensability",
            Author = "Fred Cringer";,
            IntroText = "How not to build stuff in Sitecore";
        // Populate Model using data

Remember, as this data comes from a different source it would not be content editable anyway, however it’s always good practice to show a representation of the component when the content editor inserts it into a placehder

The new SublayoutBase can be found here:


This inherits from a SublayoutBase class which you might also want to take a look at.

Anyway, any comments, feel free to leave them below

Sitecore Services Client – Creating a Custom Authorisation Filter

Recently I’ve been looking into the Sitecore Services Client with interest. Sitecore Services Client was developed to provide a consistent way of integrating Client applications with Sitecore. There are many applications for this. You may have a client application (A SPEAK application, or a Single Page Application on a website) or even other systems acting as a “client” which requires to call Sitecore for information.

Sitecore Services Client is very extensible. The aspect I’m going to touch upon in this post in authorisation of requests.

The scenario I’m going to use for this is “Only authorise Sitecore Services Client if the IP address of the caller is the same as Sitecore itself”. This scenario could be useful if you had a bunch of services that are only designed to be available from applications that execute on the same box.

To do this, I’m going to create a LoopbackAuthorisationFilter which is designed to only authorise requests that origniate from the same IP address.

Firstly, create your class, inheriting from AuthorisationFilterAttribute (in the System.Web.Http.Filters namespace) and override the OnAuthorization function.

public class LoopbackAuthorisationFilter : System.Web.Http.Filters.AuthorizationFilterAttribute
        public override void OnAuthorization(HttpActionContext actionContext)
            // Play nicely with the base class

            // If the request does not originate from this machine
            if (!System.Web.HttpContext.Current.Request.IsLocal)
                // Create an Unauthorised Access response
                actionContext.Response = actionContext.Request.CreateResponse(HttpStatusCode.Unauthorized, "Unauthorised Access");

What I’m doing here is ensuring that the original request originates from the local machine (with the same IP address). If the originating request is different, create a HTTP Unauthorized response back to the caller.

To wire this up in Sitecore Services Client, all you need to do is to add an entry into the section of the Sitecore.Services.Client.config file:

<filter>SSCActionFilter.LoopbackAuthorisationFilter, SSCActionFilter</filter>

It’s as simple as that 🙂

I have an example project on GitHub for you to try if you wish which will compile a DLL for you to use with your Sitecore Serice Client implementation:


Whilst this filter is simplistic, it is very easy to extend it to cater for any scenario you require, or even create your own Authorisation Filter.

Hope you have fun with this!

To find out more about the Sitecore Services Client, have a look at the Developers Guide to Sitecore.Services.Client here: