Archive for : October, 2017

Creating Custom Server Roles in Sitecore 9

Sitecore 9 brings about a new feature: Server Roles. This is actually one of the features I was most excited about.

What is a Server Role?

Sitecore 9 ships with 5 server roles: ContentManagement, ContentDelivery, Processing, Reporting, Standalone. You can read more about what each role is used for from their documentation page. Using these server roles, you can conditionally load sections of configuration based off the server role. Rob Ahnemann wrote a more in-depth blog post that you should check out if you want more information on what you can do with server roles.

What Role is Right for Me?

Standalone is typically used for local development. Emphasis on the word “typically.” Many dev servers are typically Standalone environments too. I may have a configuration that I want to be set on local environments, but not the dev server. What role would I use?

None of them!

You’re not limited to using just the 5 roles. You can also set more than one role at a time. If you take a peek at web.config:

<!-- SUPPORTED SERVER ROLES Specify the roles that you want this server to perform. A server can perform one or more roles. Enter the roles in a comma separated list. The supported roles are: ContentDelivery ContentManagement Processing Reporting Standalone Default value: Standalone -->
    <add key="role:define" value="Standalone" />

you’ll see that the role value is currently “Standalone”. This is actually a comma-delimited list of roles.

Proof of Concept Time

I tossed a random config file into the App_Config/Include folder:

<configuration xmlns:patch="http://www.sitecore.net/xmlconfig/" xmlns:role="http://www.sitecore.net/xmlconfig/role/">
    <sitecore>
        <foo role:require="LocalDev">foobar</foo>
    </sitecore>
</configuration>

Notice I wrote “LocalDev” as the required role? I went to /sitecore/admin/showconfig.aspx and did a CTRL+F for “foobar”. 0 Results! What happens if I change the defined roles now?

<add key="role:define" value="Standalone,LocalDev" />

Save. Refresh. Search.
We have a winner!

<foo patch:source="dev.config">foobar</foo>

is now present in the ShowConfig.aspx

Hope this helps anybody looking to work some config magic on their solutions.

Still want to learn more? Check Kamruz Jaman’s blog post showing more advanced features and tricks for server roles.

Autowiring XConnect Models

I’ve been playing around with XConnect for the last few weeks and so far I like what I see.

While playing around with custom models, I noticed that model schemas need to be manually registered. While not actually a big deal, this is an additional step that can be forgotten. I prefer to eliminate these “forgettable” tasks. I sought to determine a way of automatically wiring in these models. I’m pretty handy with reflection and figured if I could tag these models with an attribute, I could figure something out.

The Standard Configuration

For starters, let’s take a look at the configuration to see how you would normally add a model:

<?xml version="1.0" encoding="utf-8" ?>
<configuration xmlns:patch="http://www.sitecore.net/xmlconfig/">
<sitecore>
    <xconnect>
    <runtime type="Sitecore.XConnect.Client.Configuration.RuntimeModelConfiguration,Sitecore.XConnect.Client.Configuration">
        <schemas hint="list:AddModelConfiguration">
            <!-- value of 'name' property must be unique -->
            <schema name="documentationmodel" type="Sitecore.XConnect.Client.Configuration.StaticModelConfiguration,Sitecore.XConnect.Client.Configuration" patch:after="schema[@name='collectionmodel']">
                <param desc="modeltype">Documentation.Model.CollectionModel, Documentation.Model</param>
            </schema>
        </schemas>
    </runtime>
    </xconnect>
</sitecore>
</configuration>

Let’s break this down a bit. RuntimeModelConfiguration is the runtime model the XConnect client uses. It has a public method AddModelConfiguration This method is called in the XML at runtime. This entire config block essentially translates to:

var runtime = new RuntimeModelConfiguration();
var documentationmodel = new StaticModelConfiguration();
runtime.AddModelConfiguration(modeltype: documentationmodel);

The Model

First, I need an attribute:

public class XModelAttribute : Attribute
{
}

That was easy.
Now I need a model:

[XModel]
public class TestModel
{
    public static XdbModel Model => BuildModel();
    public static string ModelName => typeof(TestModel).FullName;
    protected static XdbModelVersion ModelVersion => new XdbModelVersion(0, 1);

    private static XdbModel BuildModel()
    {
        var builder = new XdbModelBuilder(ModelName, ModelVersion);
        builder.ReferenceModel(CollectionModel.Model);
        return builder.BuildModel();
    }
}

The above is a sample model. I used the dev docs as an example, but trimmed it down a bit.

The Registration

I wanted to customize as little as possible to make upgrades a bit easier. I also wanted to ensure compatibility in case someone wanted to manually register models. I decided the cleanest way to do this would be to extend the RuntimeModelConfiguration

public class CustomRuntimeModelConfiguration : RuntimeModelConfiguration
{
    public CustomRuntimeModelConfiguration()
    {
        var assemblies = AppDomain.CurrentDomain.GetAssemblies();
        foreach (var assembly in assemblies)
        {
            var types = assembly.GetTypes().Where(t => t.IsDefined(typeof(XModelAttribute), true));
            foreach (var type in types)
            {
                AddModelConfiguration(new StaticModelConfiguration($"{type.FullName}, {type.Assembly}"));
            }
        }
    }
}

When this configuration is initialized, it scans the current assemblies for any classes decorated with the XModel attribute, and creates a new StaticModelConfiguration for it. It’s then added to the runtime model.

Remember this from before?

var runtime = new RuntimeModelConfiguration();
var documentationmodel = new StaticModelConfiguration();
runtime.AddModelConfiguration(modeltype: documentationmodel);

We’re doing the same thing now, but from the constructor.

All that’s left is to patch the config so that we’re using the Custom runtime config.

<configuration xmlns:patch="http://www.sitecore.net/xmlconfig/">
    <sitecore>
        <xconnect>
            <runtime type="Sitecore.XConnect.Client.Configuration.RuntimeModelConfiguration,Sitecore.XConnect.Client.Configuration">
                <patch:attribute name="type" value="Foundation.XConnect.CustomRuntimeModelConfiguration, Foundation" />
            </runtime>
        </xconnect>
    </sitecore>
</configuration>

The Conclusion

Our custom XConnect models will now autowire themselves! The actual customization is fairly light. Manual registration is still possible, as well.

Now you’re probably wondering, “isn’t tagging these classes with an attribute is almost as forgettable as adding an entry to a config file?”

Well… yeah, technically. At least it’s in the same file now, though!