We had a list of rules - one for each of the bucket folders that we're using to store data being imported via Data Exchange Framework pipeline batches. This grew slowly but steadily over time, with our process being:

• Create a new data template and folder template to represent the data, configuring the standard values as required.
• Create an instance of the folder to hold the data
• Build the pipeline to import/update the data
• Add a rule to this Settings item to configure the bucketing for the folder template

This was based on the initial assumption that we might have different bucketing requirements, plus looking at the default "where the item bucket is based on the <template> template" rule suggested that it was looking for an exact match on the selected template.

Looking at the implementation of that rule, the Sitecore item definition is located in the /sitecore/system/Settings/Rules/Definitions/Elements/Bucketing, and is named Bucket Item Template.

The underlying type is Sitecore.Buckets.Rules.Bucketing.Conditions.WhenBucketTemplateIs (in Sitecore.Buckets) and looking at the actual implementation of that we found that it checks not just the folder template itself, but also checks against the list of base templates.

This meant we could simplify by creating a new "Bucketing Base Folder" template, inherit that on to all of our type-specific folder templates, and simplify the bucket folder rule down to just "where the item bucket is based on the <Bucketing Base Fodler> template" to have the rule applied consistently.

The Show Pipeline Batch Status command is available when a Pipeline Batch item (under /sitecore/System/Data Exchange/(provider)/Pipeline Batches/) is selected and is currently running.

Our pipelines use IterableDataSettings objects to pass lists of items that need to be created or updated, and this is the count we would like to display - but it doesn't automatically just count the number of items in these objects and use it as the "Entities submitted" count.

With the "Show Pipeline Batch Status" button in the Content Editor as my starting point, I tracked back from there:

• Inspecting the button shows that the onclick event fires javascript:return scForm.invoke('dataExchange:showPipelineBatchStatusCommand()', event)
• This method name is a good place to start, so opening up dotPeek and searching for "PipelineBatchStatusCommand" leads to Sitecore.DataExchange.Local.Commands.ShowPipelineBatchStatusCommand. After validating the state of the pipeline batch, this method calls GetRunningPipelineBatchContext(...) on the pipeline batch runner to retrieve a PipelineBatchSummary object.
• A PipelineBatchSummary has an int EntitySubmitedCount (sp) property, so now we know where the count is stored!
• Doing a "find usages" on the property itself reveals an example usage in Sitecore.DataExchange.Providers.XConnect.Processors.PipelineSteps.BaseSubmitXConnectBatchStepProcessor.OnBatchProcessed(...). It makes sense that this kind of foundational method could be used to update this property consistently for any of the XConnect batches that are running.
• The OnBatchProcessed(...) method ultimately calls the equivalent of: pipelineContext?.PipelineBatchContext?.CurrentPipelineBatch?.GetPipelineBatchSummary() to access the PipelineBatchSummary object, and then does a simple += to increment that int property.

For reference - GetPipelineBatchSummary() used by the previous step is an extension method found in Sitecore.DataExchange.Extensions. It calls pipelineBatch.GetPlugin<PipelineBatchSummary>() - so this object is tracked in the pipeline batch itself using the standard DEF plugin system.

Updating our import job to increment this property allowed us to show the total number of items we had processed.

// The template looks like this:
<#@ template debug="false" hostspecific="true" language="C#" #>
<#@ output extension=".cs" #>
<#@ assembly name="System.Core" #>
<#
  // Code to do things
#>
public class Foo() {
....
}

The output looked like this:

// The output looks like this: 



 
public class Foo() {
....
}

There were also additional blank lines within the body of the generated class - with a blank line being present wherever a T4 tag was closed and a new line started (i.e. #>). After a bit of digging and experimentation I found that the file was checked out with LF line endings instead of CRLF line endings.

It seems that a line ending of \r\n after a closing tag is completely omitted, but if the line ending is just \n it won't be omitted and will actually be rendered out to the generated document.

The fix?

A find/replace to change changing each \n to a \r\n and then re-running the T4 template generated the correct output:

// The fixed output without any extra empty lines:
public class Foo() {
....
}

Calls to the SheerResponse class should be remapped to the ClientResponse class, for example:

Sitecore.Web.UI.Sheer.SheerResponse.Alert("Invalid user.");

becomes

Context.ClientPage.ClientResponse.Alert("Invalid user.");

A static InjectionContainer class holds a reference to our UnityContainer. This container maps all the interfaces to the implementation instances, and is configured at Application_Start as defined in Global.asax.cs (as this is a .NET web application).

void Application_Start(object sender, EventArgs e)
{
    // Code that runs on application startup
    var container = new UnityContainer();
    container.RegisterInstance<IMessagingDao>(new MessagingDao());
    InjectionContainer.Container = container;
}

To actually "do" something, a page/control will create an instance of a repository class. The repository can then resolve and invoke methods on any relevant DAO object(s) as required, as well as internally encapsulating all business logic. Each instance of the repository lives only as long as the calling method requires, and it is disposed of when it falls out of scope. The intent here is to keep all the business logic at the repository layer, separate from the data access layer. A repository class might look similar to:

public class MessagingRepository
{
    // Many methods, similar to:
    public void SendMessage(Message message)
    {
        // (Additional repo-level logic omitted from here)
        var dao = InjectionContainer.Container.Resolve<IMessagingDao>();
        dao.SendMessage(message);
    }
}

Yes, there are lots of newer/better patterns, but this is what we've got and it works. Without a good business case for why we should rip it out, refactor/rewrite and regression test everything - it's going to stick around for a little while.

The challenge here was to make this more testable. The complications were:

1. To minimise changes to the existing code. The purpose is to make the code testable, and possibly a little bit cleaner along the way.
2. To work around the anti-pattern of having a static IoC class. The static InjectionContainer class also causes complications running tests concurrently in the same app domain when you want to have different mappings configured. I'm a big fan of NCrunch so I wanted whatever solution I used to play nicely with it's test runner.

Unfortunately we can't just jump to constructor injection as the change was too big and would necessitate us re-testing everything at a point in time where we weren't able to do this. But we can take a few steps in that direction...

Each repository contains several methods, many of which will ultimately be resolving the DAO. So why not replace all the calls to resolve the interface with a method to give us a single interception point?

public class MessagingRepository
{
    private IMessagingDao _messagingDao;
    private IMessagingDao ResolveMessagingDao()
    {
        if (_messagingDao == null)
            _messagingDao = InjectionContainer.Container.Resolve<IMessagingDao>();
        return _messagingDao;
    }

    public void SendMessage(Message message)
    {
        var dao = ResolveMessagingDao();
        dao.SendMessage(message);
    }
}

I used the more verbose name "ResolveMessagingDao" as some of the repositories rely upon multiple DAOs, so it was easier to be clearly consistent everywhere rather than having some methods named "ResolveDao" if only a single DAO was used in that repository.

This new ResolveMessagingDao() method will now resolve and cache the reference to the DAO object for the lifetime of the repository, which is fine given that our usage pattern is to create an instance of the repository when required, use the repository, then discard it when it falls out of scope. This gives us the point to add constructor injection, by replacing the implicit default constructor with two explicit constructors:

public MessagingRepository()
{
    // Explicit parameterless constructor to replace the implicit
    // default constructor which we used to rely on.
}

public MessagingRepository(IMessagingDao messagingDao)
{
    if (messagingDao == null)
        throw new ArgumentNullException("messagingDao");

    _messagingDao = messagingDao;
}

These constructors give us two options:

1. Implicit support for the old behaviour, where creating an instance of the repository using the parameterless constructor will cause the DAOs to be resolved via Unity. Additionally, the reference to this DAO instance is then cached within the repository for each subsequent use (although admittedly the "cost" of resolving it is insignificant).
2. Explicit support via the new constructor, which allows us to supply the instances of the DAO we want the repository to use. Additionally by preventing null values from being provided to that constructor, I'm making sure that I can't pass in null unexpectedly and then have it (silently) fall back to using Unity for resolution.

Another option would have been to resolve the DAOs in the parameterless constructor, but this didn't feel like the correct solution as there are often repository methods that don't even need to access anything at the DAO layer at all.

Ultimately this solution worked and made all the repository-layer code testable by allowing it to be run against explicitly-created mock DAO objects with minimal side effects on the main project itself.

For example, we had a property on the UserControl that wouldn't persist the value between postbacks:

public string EmptyMessage { get; set; }

This value was being set in the parent's Page_Load event on every page load. To change this so that it would persist the value, I could replace the property declaration with:

public string EmptyMessage
{
    get { return (string)ViewState["EmptyMessage"]; }
    set { ViewState["EmptyMessage"] = value; }
}

In explaining this change, I had to summarise why this wasn't a terrible idea. I'll admit that I had spent a long time thinking that the ViewState was a monstrous blob of encoded text that did nothing but bulk up my web pages unnecessarily, and for a long time wrote code so that every page essentially had EnableViewState="false". ViewState isn't the right answer for absolutely everything, but it is definitely useful in some circumstances.

My key points were:

• If it makes sense to persist a value, then persist it. If saving a property lets you save time or effort, then just persist it. This can help make your code more declarative, so your parent control "tells" this control how to behave once and this control can "remember" to behave a certain way, display a certain message, etc.
• Work out if the ViewState is the right place to persist this information. This is a much bigger question, but the ViewState generally isn't the right place to store large blobs of data. Small strings and other simple values, sure.
• Setting a ViewState-backed property at design time won't make your ViewState huge, because these values aren't actually be stored in the ViewState. If you declare an initial value, for example <project:MyControl runat="server" EmptyMessage="There's nothing here!" /> - this default value won't be saved in to the ViewState because it's being set before TrackViewState() is called. The value will actually just be re-applied to your object on each subsequent page load, and then be overwritten later in the page lifecycle if you've actually changed it.
• Don't try to save things to the ViewState in Init. Similar to the point above, changes you make at this point in the page lifecycle aren't tracked yet, so you'd have to re-apply them on each page request.

I remember that when I started to understand how the ViewState behaves over the page life cycle it was an "a-ha!" moment where the ViewState became something that made sense, rather than being a strange black box that just "somehow" sometimes remembered things.

The first time I saw this, it was an intermittent issue as the visitor identification sublayout was only missing on certain pages. Whether the user had a normal session duration or the shorter (a.k.a. "Why have I been logged out?!") duration depended on their path through the site.

The visitor identification sublayout should be included on every page. The easiest way to do this is to include it in your masterpages/layouts:

// Webforms
<sc:VisitorIdentification runat="server" />

// MVC
@Html.Sitecore().VisitorIdentification()

This renders out a stylesheet tag - if your browser actually requests this file, you're probably a person and it marks your session as 'not a robot'. If you don't load this empty stylesheet, you're probably a robot and you'll have the much faster logout. The exact session timeout is configured as:

<setting name="Analytics.Robots.SessionTimeout" value="1" />

Rather than adding the VisitorIdentification sublayout to every page, there is also the thermonuclear option of disabling the robot detection entirely by setting this value to false:

<setting name="Analytics.AutoDetectBots" value="false" />

More information is available in the Sitecore documentation on how to configure the robot detection component.

Our previous implementation hooked in to the Publish pipeline, and was basically a PublishProcessor that used a little bit of logic to determine if the item being published should trigger clearing the internal cache. The method itself looked something like this:

namespace Project.Pipelines.Publish
{
    public class ClearListCache : PublishProcessor
    {
        public override void Process(PublishContext context)
        {
            // Clear our cache
        }
    }
}

This was then hooked up to the publish pipeline in Sitecore.config.

Our new implementation is an event handler that listens for the publish:end:remote (on delivery servers) or publish:end event (on the authoring server):

namespace Project.Pipelines.Publish
{
    public class PublishEndClearCacheHandler
    {
        public void ClearCache(object sender, EventArgs args)
        {
            // Clear our cache
        }
    }
}

With the following in Sitecore.config (on the delivery server):

<event name="publish:end:remote">
    <handler
        type="Project.Pipelines.Publish.PublishEndClearCacheHandler, Project"
        method="ClearCache" />
</event>

The handler type is a string containing the assembly-qualified name of the event handler class - that is, the type name including the namespace, followed by a comma, followed by the assembly display name. The method string contains the name of the method on that type to invoke.

The handler for this particular event can also accept a PublishEndRemoteEventArgs instead of an EventArgs argument - however we didn't need it in this case.

This date is pulled from a DateField on the item in Sitecore, and stepping through in the debugger it became apparent that the dates were off by exactly 11 hours. Eleven hours is the difference between our current timezone and UTC... suspicious! After a little bit of reading and checking the documentation I confirmed that this is indeed the case.

We were previously using an extension method named GetDateTime which we used to return a DateTime? value from a DateField on an Item, so it was simply a matter of tweaking it slightly to take advantage of the DateUtil.ToServerTime method Sitecore already provides:

public static DateTime? GetLocalDateTime(this Item item, string fieldName)
{
    var field = item.Fields[fieldName];
    if(field != null)
    {
        var field = (DateField)item.Fields[fieldName];
        var value = field.DateTime;
        if(value.Year > 0001)
            return DateUtil.ToServerTime(value);
    }
    return null;
}

I think my favourite thing about this issue was that our testing team initially missed this - because most of the testing was done in the afternoon! If an article was created after 11am, even subtracting 11 hours meant that it would still show the "correct" day. Only pages created before 11am would show the date for the previous day.

A testable method should be relatively self-contained. It should take a set of inputs and return any outputs without requiring or mutating any additional "global" state, so that you're testing just the behaviour of that method.

You need to be able to call the method. This is easy if the method is static, or if it's on a public class that's easy to instantiate (i.e. no huge amount of build-up or tear-down should be required).

The method you're testing needs to be visible to your test project. What access modifier would let me make these already-static methods visible only within the main project and my test project?

• These methods weren't public, and had no reason to be. They shouldn't be called from anything outside that project (except tests!)
• A private method is inaccessible.
• A protected method on a public class would give me the ability to create a derived test class that would inherit from the base class, and would thus have access to the method... but that's too clunky.
• protected internal - also not quite right, similar to 'protected' in this instance.
• internal which would allow them to be "accessed by any code in the same assembly, but not from another assembly".

Luckily internal (Friend in Visual Basic) works with the InternalsVisibleTo attribute to allow you to specify a set of other assemblies which are allowed to access internal methods. This was as simple as adding a declaration to my main project - which I put in to AssemblyInfo.cs:

[assembly:InternalsVisibleTo("My.Test.Project")]

Now, My.Test.Project can call the internal methods declared in my main project without requiring me to make these methods visible to the entire world.

This gets a little bit trickier if you're using signed assemblies as you have to include the public key - but this is documented on the InternalsVisibleTo attribute MSDN page.