Making sense of Sitecore SPEAK pipelines

Following this great post by my colleague Alan I came up with an idea on how to improve the SPEAK pipelines concept.

The main problem with the pipelines as they are in Sitecore 7.1 is that there is no way to add or remove processors without making changes in JavaScript code. You can’t even change the order in which they are added without changing their priority in code (see Alan’s blog post).

Update: This concept is now a part of the new SPEAK version with small updates. It will be available in Sitecore 8. Thanks Sitecore for reading my blog. More on this implementation in a soon-to-come post.


Configuring pipelines

First I’ve added two templates, one for a SPEAK-Pipeline and one for a SPEAK-Pipeline-processor.

The SPEAK pipeline template contains one field for the name of the pipeline, I don’t like using the item name for this and a regex ensuring no spaces etc. should be added. The pipeline item’s standard values has insert options set for SPEAK-Pipeline-Processor items.

The SPEAK-Pipeline-processor template have two fields, one for the path to a processor JS file and one for the name of the processor (the object name used in the JS file, will be removed later).

Speak Pipeline templates

Now pipelines can be configured, not in config, but in Sitecore. The concept is then to add a Pipelines folder beneath the app in which the pipeline is used.

This approach sticks to the concept of keeping everything confined within an application to get rid of potential dependency spaghetti.

Pipeline Items 

The pipeline component

Then I’ve created a new SPEAK component called Pipeline. This component only renders out a div tag with a require attribute that points to /-/speak/v1/pipelines/pipeline.js?id=<the id of the rendering datasource>

The component also renders out three optional rendering parameters which I bind to the model. One called pipelineArgs, one called trigger and one called targetControl.

The pipelineArgs can be used to bind the arguments which is passed to the pipeline with another model attribute. The trigger can be used to trigger the pipeline if the event written as trigger is triggered on the targetControl.

I really like this binding concept. UI events can trigger a client side pipeline making them potentially extremely powerful and still extremely easy to inject your own custom code into.

Creating the dynamic pipelines

So last thing to get this concept up and running is to dynamically generate the Javascript which adds the processors to the pipeline.

I got inspired by the rules javascript magic and created a new server side processor for the resolveScript pipeline defined in Sitecore.Speak.config.

And here is the outputted JavaScript, really simple even though the C# code could need a real good cleaning (not now)..

I’ve added the processor in the Sitecore.Speak.Config file just after the rule processor which as mentioned has been a source for inspiration. This should of course be patched in a separate config include file if this code is used by someone other than Sitecore.

As you saw in the pipeline component implementation we then let require do it’s magic by requiring the outputted JavaScript making sure that we have the pipeline and all the processors at our disposal.

The pipeline can now be run either by binding it to some pipelineArgs object and setting a trigger on the rendering parameters or it can be started in the PageCode or other places like this:

How is a processor written then?

There is one small issue with this implementation which I will fix later by implementing another resolveScript processor.

The issue is that the processor object has to be named exactly like it is written on the processor item in the processor name field. Otherwise the JavaScript will fail as it is implemented now. It is a bit redundant but the fix is clear.


Sitecore, please use this concept (maybe for a good bottle of red wine or some shares :-) ). The code will need some polishing though, but the whole binding client events to trigger pipelines could be very powerful and make it extremely easy to inject custom code into the UI by adding new processors in Sitecore.

One might also argue that the same functionality could be achieved by making a rule action which executed a pipeline (I can feel yet another a blog post coming up soon). The CallFunction action from this post could actually also be used together with the pipeline rendering to call the function startPipeline and there you have it already, executing pipelines from a rule.

If the concept is implemented in Sitecore then it could also be used for “Core” SPEAK pipelines as well which then would be shared between app’s for common functionality. Just be aware that they really need to be real system pipelines to reduce inflexibility of the API in the future.

In a follow up post I will show an example usage of this pipeline implementation and who knows maybe also make sure that the processors can be dynamically named from the items so we get rid of the name redundancy.

Anders Laub

Anders Laub Christoffersen

Anders has been working with Sitecore for over a decade and has in this time been the lead developer and architect on several large scale enterprise solutions all around the world. Anders has been nominated a Sitecore Technical MVP three years in a row for 2014, 2015 and 2016. Anders is now working as a Sr. Solutions Architect at Sitecore in Copenhagen.

One thought on “Making sense of Sitecore SPEAK pipelines

  1. Nice article, I guess its in our build library already? and we should push Sitecore to make it part of SPEAK:-) we could also move it to configuration file :-)

Leave a Reply

Your email address will not be published. Required fields are marked *