In talking through potential Online Marketing Suite scenarios with prospects, clients and partners these days, the discussion often leads to very interesting possibilities in evaluating external data sources as part of an overall personalization strategy. For those of you that have worked with Sitecore, you know it’s built for this. Rather than enforce a migration of data to the content repository, a well developed Sitecore strategy continues to take advantage of data and application functionality wherever it is best served from. OMS is no different.
The following is a simple example of a common scenario. We want to develop an OMS condition that queries an external database and determines whether a product is available before showing the promotion our marketing team has created for it. With the condition in place, it will be easy for us to build a rule that does something when the condition is true. This is a classic “When” condition, and we can think of all kinds of rules that might be appropriate based on the boolean value returned.
Many of my conversations lately have been around “Who does what in OMS?”. A very fair question. I get excited by the question, because it gives me confidence in the “newness”of what OMS is doing. Sure, every piece of OMS could be developed separately (it is software, and everything is possible), but Sitecore has sparked the questions because it’s not JUST developers anymore. While developers are certainly creating the great methods that evaluate conditions and implement rule-driven functionality, others (you get to decide who) are mapping the business processes and visualizing the results. These two sides are equally important—if a Condition falls in the woods and nobody….you get the idea.
Back to it. 1st step is the condition definition itself. Who does this? Well, in most cases this one’s for the developer. The reason is that we’re coding brand new logic here. If you’re talking about the rich set of standard OMS Conditions (geolocation info, DNS info, authenticated user, the visitor entered as as part of an Email Campaign, etc), then there’s no work to do here. These Conditions are already defined and available to you as you build a rule to evaluate that particular Condition. More on that later. The screenshot below shows the beginning of the scrollable list of prebuilt Conditions:
In standard Sitecore fashion, all prebuilt Sitecore functionality is built and referenced in the same way you’ll build yours. If you look in the Content Editor under /sitecore/system/Settings/Rules/Conditional Renderings/Conditions/Area Code Condition, you’ll see the definition (the Item in the tree) that represents the condition. Even though this is a standard OMS Condition, Sitecore shows you the class being used:
You’ll notice that the AreaCodeCondition class in the Sitecore.Analytics assembly is referenced. You’ll also see that the Text field allows you to define placeholders where a content author can enter additional parameters to the condition evaluation. I talk a little more about these values here, and our Rules Engine Cookbook does a great job of going into more detail.
So for our purposes today, it’s going to be even easier. Rather that doing a compare of values between Analytics data and content author entered parameters, we’re simply going to check the “trueness” of a condition. Does the product have any availability? Based on the result, we can then decide what to do about it.
The reason for the belaboring: this is the thought process you’ll go through as you answer the “Who does what?” question with OMS.
- A cross-functional team discusses the Conditions that need to be evaluated. Some will exist in OMS already, some will need to have these comparisons / when-condition methods crafted to encapsulate your business rules, query external sources, etc.
- A cross-functional team discusses the Rules, the things that should HAPPEN when a Condition is evaluated. Some will exist in OMS already (easily hiding or showing a control, having a control display a different piece of content, moving a control to a different area of the page, initiating a specific Email Campaign, etc.) and some will do fun and exciting things outside of the Sitecore application domain and context.
- A cross-functional team discusses where and when these rules are appropriate (the marching red ants theorem first developed in the 90’s has new corollaries).
- A cross-functional team ensures that both sides of the brain communicate, and that the development efforts and the business process mapping stay on the same (albeit flexibly winding) trail.
The point here isn’t that you need a huge cross-functional team. The point is that if you’re a team of one (or 2, or 10, or 100), you need to think cross-functionality. Nothing new here.
Back to it. Now that we’ve seen where the Condition definitions are, we’ll simply add our own and call out our own Class.
This condition is set up to take a look at the Northwind database, see if there is any Tofu available, and return true if so:
using Sitecore.Diagnostics;
using Sitecore.Rules.Conditions;
using Sitecore.Rules;
using System;
using System.Linq;
using System.Data.Linq;
using nwind;
namespace Examples
{
public class NorthwindProductAvailable<T> : RuleCondition<T> where T : RuleContext
{
// Methods
protected void WhenCondition()
{
}
public override void Evaluate(T ruleContext, RuleStack stack)
{
Assert.ArgumentNotNull(ruleContext, "ruleContext");
Assert.ArgumentNotNull(stack, "stack");
stack.Push(this.Execute(ruleContext));
}
protected bool Execute(T ruleContext)
{
try
{
Northwind_Extended db = new Northwind_Extended(@"Data Source=(local);Initial Catalog=Northwind; user=sa; password=*");
var numUnits = (from m in db.Products
where m.ProductName == "Tofu"
select m.UnitsInStock).SingleOrDefault();
return numUnits > 0;
}
catch
{ return false; }
}
}
}
That’s it. As my previous post shows, now this condition is available to us to define any action to take after the evaluation of it.
We’d certainly have a more complex business rule in the real world, and that would invariably lead to the ability to have marketers and other content authors being able to include their parameters to the condition evaluation. By including tokens for replacement, this becomes a very easy exercise.
