What should I be using pipeline groups for?

Question

Sitecore 8 gave us all sorts of handy new tools, including the ability to group pipelines, like so:

<pipelines>
  ...
  <group groupName="mygroup" name="mygroup">
    <pipelines>
      ...
    </pipelines>
  </group>
  ...
</pipelines>

What I am trying to determine is whether or not the ability to group pipelines is just (super useful) syntactical sugar, meant to make organizing and maintaining custom pipelines (e.g. for modules), or if there is a specific time when grouping pipelines adds the ability to do something that one wouldn't otherwise be able to do.

One of the things that has been throwing me is the fact that the Sitecore API refers to the name of the pipeline group as the pipelineDomain. When I think of "domains", I think of domains in Sitecore, I think of security domains. Looking at the Sitecore code-base, I see that in DefaultCorePipelineManager Sitecore actually resolves the pipeline by combining the pipelineName and pipelineDomain like so:

string str = pipelineGroup + "\\" + pipelineName
CorePipeline pipeline = (CorePipeline) this.pipelines[(object) str];

To me, this actually looks like it is used somewhat like a security domain. I understand the namespacing construct doesn't directly provide much beyond some additional flexibility in naming, but it occurs to me that this could be used for things like creating tenant or site-specific pipelines, and beyond.

My question is: when is it best to use a pipeline group, and should I be using it for things like tenant or site-specific pipelines?

Answer 1

In this context, domains does not refer to security domains, rather controlled area.

Pipeline groups could be used for namespacing your pipelines, for example when creating custom pipelines to ensure they do not conflict with other custom pipelines, however this can already be achieved otherwise (and more elegantly) when naming your pipeline, as pointed out my Mark Cassidy.

A more useful usecase, as you suggest, is that it opens up for creating tenant specific, site specific or even more granular pipelines.

When running a pipeline, you can now specify a pipelineDomain (from Sitecore.Abstractions.dll):

namespace Sitecore.Abstractions
{
  public interface ICorePipeline
  {
    void Run(string pipelineName, PipelineArgs args);
    void Run(string pipelineName, PipelineArgs args, bool failIfNotExists);
    void Run(string pipelineName, PipelineArgs args, string pipelineDomain);
    void Run(string pipelineName, PipelineArgs args, string pipelineDomain, bool failIfNotExists);
  }
}

By namespacing your pipelines, for example with tenant or site, combined with the failIfNotExists flag, you could create some quite powerful and flexible pipeline-based modules.

Answer 2

I think it might be too soon to deduce a set of general best practices for this yet. However I'd like to chip in, where I see this opening a few new doors for us when implementing.

Context-tailored pipelines

This is not in regards to new pipelines you define yourself, but the set of pipelines that ship with the product out of the box.

Some of the pipelines we have (think <publish> and <publishItem> for the more obvious examples) only make sense in certain settings. E.g. when your site is acting like content master for your solution. Using the server role as a namespace for this pipeline would make sense, as it serves no function on instances in content delivery mode for example.

But more interestingly; a lot of the pipelines have mixed purposes and roles, across server roles and current display mode (normal, preview, editing and so on). Essentially - today - processors that operate in these pipelines need to make themselves aware of the current context. It looks something like this:

return site != null && site.DisplayMode == DisplayMode.Edit && (!(WebUtil.GetQueryString("sc_duration") == "temporary") && Context.PageMode.IsExperienceEditorEditing);

Example taken from the <renderField> pipeline, one of the pipelines that changes behaviour quite a lot depending on current context.

Similar considerations could be had for tasks/jobs, agents and so on - often these run off the content master server and various hoops have to be built in to the code and/or configs to prevent them from running on CD. Namespacing the pipelines could clean this up a bit.

Inversion of Control

In short; there are many potential usages. One thing I would hope makes it to be an established practice; is that this namespace (or domain, if you will) becomes a matter to be solved by the Dependency Injector and code will allow this property to be injected into their code - rather than just hardcoding a pipeline domain for their custom pipelines. This serves no point at all - you can already name a pipeline <Unicorn.Publish> should you so desire. But with the control of the pipeline domain inverted, there would be all sorts of useful things this new functionality can be used for.

Answer 3

It is 2 main ideas,

1. If you want to then run the pipeline you simply need to include the “domain” in the call.

2. is more structure to the app_config folder. It’s all too easy for this to become rather unruly so this form of segmentation is a nice addition.