Sitecore 8 Federated Experience Manager pt. 2 – Pushing renderings to non Sitecore sites

What has always intrigued me with some of the new functionality of Sitecore 8’s Federated Experience Manager is how content is pushed to other sites. This post will explore this concept.

Following on from my first post regarding capturing analytic information from non Sitecore sites, I wanted to see how easy (or difficult) it is to add content to external sites

For this, I will set up a basic Title and Text component and see how we can utilise this rendering on a non Sitecore site. The site I’m going to add this too is the basic default ASP.NET MVC site I configured in part 1 – it is important to point out that the technology behind the site really doesn’t matter (which is cool in itself!)

Setting up a Rendering Component for this test (ascx)

Just to briefly show how the component is set up, below is the markup:

<sc:Text runat="server" Field="Title"/>
<sc:Text runat="server" Field="Text"></sc:Text>

view raw
hosted with ❤ by GitHub

One observation I made when testing this was that the component itself needs to be surrounded via a containing element. Beforehand, my component didn’t contain a surrounding DIV and all that was being rendered was the H2 – so ensure that your component has a containing element and you should be fine.

Below is the Datasoure Template used for this component:


Now, if we open up the Federated ExperienceManager, click on our site and click the “Open in Experience Editor” button, you will open the external site in the Experience Editor ready for personalising.

You will notice that on the Ribbon there is a botton marked “Add Placeholder”. This will allow you to provide an anchor point on the page where the components can be inserted.

When you click onthe “Add Placeholder” button, you’ll notice that all other buttons are grayed out. What you can do now is to click on any element from within the page and a list of options will appear.


Notice that the selection will display the element that you want to interact with, the “up left” arrow allows you to fine-tune your selection to ensure that the correct element in the DOM is selected.

You will also have three options:

  • Add Before – allows you to add a component before this element
  • Replace – Replace this element entirely
  • Add After – Gives you he option to add components after this element

In this experiment, I’ll select “Add before” and give the placeholder then name of “promo-panel” and select “Test Site” as the parent element.


Now that we have a placeholder on the page we can select this placeholder to insert our Title and Text component


From this point, you will have the same level of functionality as the standard Experience Editor – so add your component (in my case the Title and Text component and associate a Datasource with it in the standard manner

Once this is done, publish the changes. Now let’s look at our site:


As you can see, our new component is being rendered onto the page of our non Sitecore site. Pretty clever eh?

How does this look in Sitecore?

Lets inspect the backend of Sitecore and see how this is acheieved. The settings for this are stored in /sitecore/system/Marketing Control Panel/Federated Experience Manager


You’ll notice that our “promo-panel” Placeholder is here. Let’s have a look at that:


You’ll notice that there is a Selector field. This indicates exactly where in the DOM to insert the content – and the above “Position” field signifies to insert content before this selector.

Now all that’s missing is “what” is inserted into this Placehlder. This is defined in the Presentation Details of the Placeholder:


Pretty clever stuff eh? 🙂

From here is should also be possible to provide Personalisation and DMS based rules to the Presentation in the same manner as any other Presentation in Sitecore. I’ll be looking to explore this in a future post.

Hope you have fun with this.

Sitecore 8 Experience Analytics and Outcomes

So far, there isn’t a massive amount of resource available on what Outcomes are in Sitecore 8 and how and why you should use them. This post will aim to explore what Outcomes are and give an example of how they could be used in a real life situation.

So, what are Outcomes?

An Outcome is essentially a “Business Significant Result” and can be used in your Personalisation rules and tour Engagement Plans. An Outcome can be put simply as “something that has happened that is of significance”.

Rules Engine usage

You can utilise Outcomes in the Rules Engine to personalise content related to a specific outcome that has occured for the visitor. The following two rules are defined for you:

Outcome Rules

You can see that out of the box there are two rules

  • where the current contact has registered the outcome during any interaction
  • where the current contact has registered the outcome during any interaction where monetary value compares to value

(the Outcome Rule Action on the right-hand side is a custom rule action that I’ve created, I’ll cover this later)

How can we use Outcomes?

To demonstrate how Outcomes can be used, I will set up an example scenario. The scenario will be to register an Outcome if a new Product has been purchased as a result of expressing interest in the Product before it was released. For this example I will set up three basic content pages:

  • To register as a User
  • To register initial interest for the Product
  • To purchase the Product

Page Setup

Each page will register a specific goal. The final page will register a custom goal which will also register the Outcome.

As shown below, I’ve added the following Goals which are used in this example:

  • Purchase Interest Submitted Goal – fired when the Interest Submitted page loads
  • Purchase Product Goal – fired when the Purchased-Product page loads
  • Purchase Product Register Outcome Goal – fired when the above two goals have been fired

Goal Setup

The last goal in the list is a custom goal as it will also register an Outcome. This can be achieved by setting up a custom Rule Action using the below code:

public class TriggerOutcomeRuleAction<T> : RuleAction<T> where T : Sitecore.Rules.RuleContext
public override void Apply(T ruleContext)
public void RegisterOutcome()
ID id = ID.NewID;
ID interactionId = ID.Parse(Tracker.Current.Interaction.InteractionId);
ID contactId = ID.Parse(Tracker.Current.Contact.ContactId);
// Definition for Product Purchase Outcome
var definitionId = new ID("{9016E456-95CB-42E9-AD58-997D6D77AE83}");
var outcome = new ContactOutcome(id, definitionId, contactId)
DateTime = DateTime.UtcNow.Date,
MonetaryValue = 10,
InteractionId = interactionId
var manager = Factory.CreateObject("outcome/outcomeManager", true) as OutcomeManager;

(You can find more information on how to register outcomes on Ian Graham’s blog post here

Then I will set up an Outcome Definition called “Product Purchase” in the new Outcomes section of the Content Editor. This is the Outcome that the Rule Action will fire:

Outcome Definition

Then, for the “Product Purchased Register Outcome” Goal, I will utilise this custom Rule Action to the Rules that are evaluated for that Goal (see Rule 1 below):

Rules for registering Outcome

Now that we have all the pieces to make this work,, I’d like to introduce you to a new feature of Sitecore 8. The Explore Mode of the Experience Editor. This is a very useful way to test and verify that your Goals are converting and your Outcomes are being registered. To find out more about Explore Mode, have a look at Martin Davies’s blog post here:

All I will be doing is visiting the three pages in turn (interest-submitted and purchase-product) to simply evidence the Goals have been converted and the Outcome has been fired.

After quickly running through the pages – Explore Mode verified that my Goals had been converted:

Experience Editor

Currently, Explore Mode does not give us a view of any Outcomes that have been fired, but we can use the Experience Profiler to view the. Firstly ensure that everything is published (as you’ll need to browse the site properly for analytics to be captured) and then go into the Experience Profiler and select your visit (once the analytics have been flushed to MongoDB – this happens when the session ends). The Experience Profiler will show information on your visit – with one of the tabs representing Outcomes that have occured.


Arguably I should have named my Outcome a little better (e.g. Product Purchased after registering) but you get the idea.

Hope this is of use to someone 🙂

Dynamic Menu’s in Sitecore Part 2

Welcome to Part 2 of setting up Dynamic Menu’s in Sitecore. In this post, I will quickly demonstrate how easy it is to utilise the power. Of DMS to alter what is displayed in site navigation and empower users to make choices on which content is displayed.

If you want to have a look at how a dynamic menu can be structured, please read Part 1. This post will follow on from there.

So, just to recap, we now have a navigation Item, which is simply an instance of a Navigation link on your site and a Navigation Collection, which consists of a collection of Navigation Items. The Navigation Collection can then be used as a Datasource Navigation Component.

Let’s choose the simple scenario that you want to have a different navigation displayed for a user that has successfully logged into out site.

First let’s assume that we have the following Navigation Items defined:

Navigation Items

Now lets two navigation collections, one for not logged in and one for logged in:

Navigation Collections

The “Not Logged In” collection will contain links to the “Log in” and “Sign Up” Navigation Items:

Not Logged In Collection

The “Logged In” collection will contain links to the “My profile” and “Log out” Navigation Items”

Logged In Collection

As these two collections are designed to be used as Datasources, we need to establish which Datasource to pass to the Navigation component and what drives this decision. This can be achieved by setting up a Rule Condition

Then, set up a Rule Condition which will detect whether the user has logged in:

public class AuthenticatedRuleCondition&lt;T&gt; : TrueCondition&lt;T&gt; where T : RuleContext
protected override bool Execute(T ruleContext)
Assert.ArgumentNotNull(ruleContext, &amp;amp;amp;amp;quot;ruleContext&amp;amp;amp;amp;quot;);

if (Sitecore.Context.IsLoggedIn)
return true;

return false;

We also need to register this new Rule Condition in Sitecore. This can be done by inserting a new Conditional Rendering into the following location (replacing <rule-condition-class> the fully qualified namespace/class name and <dll> with the DLL in which the rule resides):


We can now use this Rule Condition to help decide which navigation to display. To do this, “Personalise” the component in the Presentation Layer and make use of this Rule Condition. Essentially what I am saying below is if my Rule Condition is true (i.e. the user is logged in), use a different Datasource to what is the default (the default is Not Logged In Datasource)


… and that’s it! It really is that simple. Sitecore already has a rule for authentication “when the current user is anonymous” (or the reverse of that rule) however the above can be easily modified to check for presence of a Role:

if (Sitecore.Context.User.IsInRole(&quot;extranet\\membership&quot;);)


// Perform some additional checks if necessary

return true; }

… or any other condition necessary.

When all is published, you will notice that Sitecore provides a different Datasource to the Navigation component when the user is logged in (or when the condition is met).

Hope this helps 🙂

Dependency injection and Inversion of Control (IOC)

I was involved in an interesting debate a few days ago regarding the importance of IOC containers and whether they are necessary, whilst this post will not teach you what IOC is (there are many excellent posts that do this) I just wanted to share my experience with IOC and one of the most compelling reasons for using them.

Sure, you can get by without using them, they are not mandatory for Dependency Injecion, however if you follow the Single Responsibility Principle (SRP), you will find they are a huge as advantage and also clean up your code no end.

For me, the “Eureka!” Moment came whilst doing TDD for the first time whilst exercising Separation Of Concerns and the Single Responsibility principle, I noticed that my class construction was becoming too involved and almost unreadable.

To quickly demonstrate this, I’ve put together a very crude implementation to demonstrate how IOC can assist.

For example, if I had a UserRegistration component that is dependent on a number of other classes, this is how it might look:

IUserRegistration registration = new UserRegistration(new CRMUserRegistration(),
new UserEmailSender(new SMTPService()),
new MembershipEmailSender(new SMTPService()));

As you can see, there are several dependencies being injected here. With a tool like StructureMap, all you need is a single declaration

IUserRegistration userRegistration = ObjectFactory.GetInstance<IUserRegistration>();


This does require a little setup:

var container = new Container();
container.Configure(x =>

This only needs to be done once in your code (normally on application start up)

As a user of the component you no longer need to know (or even care) what all the dependencies are which is great 🙂 You can still use the older method of declaring dependencies however there really is no need. StructureMap will automatically new up and instances that are required and even walk through the dependency tree creating any new instances that are necessary in any sub components that are required.

Also, as you are using an IOC (in the case StructureMap), you can quickly make an instance a Singleton instance without modifying your class:


I’ve quickly put together a project that demonstrates this principle .. not that none of the code does anything, this is purely for demonstration purposes 🙂

Within the project there is a RegistrationController.cs class which demonstrates the above – bear in mind the project doesn’t do anything, it’s purely for educational purposes. If I get a bit of time I might turn it in to something more useful 🙂

So, to conclude, there is no longer any need to create your own class factories to do this. IOC Containers are the way to go (well, in my opinion anyway).

Many many awesome posts have been written on this subject, take a look below for some further reading:

Sitecore CMS also uses the Sitecore Dictionary

Something I was reminded of today, Sitecore will also use the Dictionary that you define in the CMS 🙂

Let’s do a quick demonstration. Say you have a Page Template called My Details:

My Details Page Template

Then, add this to the Insert Options of a particular item, say the Home item. If you right-click on the item in your content tree and select Insert, it will display your “My Details” page template as an option:

My Details Insert Options

Now, say there is a requirement to translate/manage the string for a navigation item on the website, more specifically the My Details navigation item and you wanted to change this to My User Area. One way of doing this is to add a dictionary definition for this and reference this dictionary definition in your code:

My User Area definition

Now go back to the Home Page and right-click to add a new child item. You will see that Sitecore has identified that there is a dictionary definition for “My Details” and is using this instead of your template name.

My User Area Insert Options

Be mindful of this, sometimes this may be unintended. however if you wanted to translate aspects of the Sitecore CMS, then this would be a great place to do this 🙂