Beta Version

BLOG

Kapil Oliveti Author's Perspective
3 Minute read

Sitecore xConnect and Pipelines

Connect or store data from any third party system and get access to the most comprehensive view of the customer with Sitecore xConnect.

xConnect can be described as a service layer that is sandwiched between the xDB and any trusted client, device or even interfaces that wants to read, write or search xDB data. Note that all communication must take place over HTTPs and it is a prerequisite for all clients to have an appropriate certificate thumbprint.

Also, no system can gain direct access to the collection database or search indexes, and systems that are internal to xDB are also required to use xConnect if they need to access xDB data. What this essentially means that xConnect exposes a web API endpoint.

For better understanding, please refer to the graphic below:

xConnect: A separate layer

xConnect is a separate layer that exists independently of Sitecore and has no dependencies on the Sitecore kernel. In simple terms, developers will have two separate IIS websites, two web roots and two URLs - one for the client and the other for xConnect.

Be it in a local or scaled environment, the client application is aware of the xConnect end point. This means that there is no direct association with underlying databases or even search indexes.

Additionally, xConnect incorporates the oData protocol, which are a set of guidelines to build and consume RESTful APIs. By oData convention, the service root is: http://[xconnecthost]:[port]/odata. Note: xConnect and the xConnect Client API are brand new and are not a re-factor of existing methods of working with xDB data. That’s not all - xConnect’s architecture makes it simpler for developers to swap search providers.

Key features of xConnect

  • Model definition and deployment to a centralised configuration server.
  • To integrate third party systems data within Sitecore Experience Database(xDB)
  • Easily extract or stream using the OData industry standard, for example, to Microsoft Power BI.
  • Push and pull operations on contacts and interactions
  • Search features make use of standard technologies like Solr or Azure Search.
  • Automatic indexing of any contact, facet, interaction, or event.
  • Abstraction from a specific database technology to enable IT teams to make use of Microsoft Azure SQL, Microsoft SQL Server 2016, and MongoDB.
  • Operates across all Sitecore Experience deployment options (on premises, hybrid, and managed cloud).
  • Foundation of out-of-box connectors created by Sitecore: Sitecore Connect™ for Microsoft Dynamics 365, and Sitecore Connect™ for Salesforce CRM.
  • It can extract data from a range of connected devices – from mobile apps, store beacons, augmented/virtual/mixed reality systems, Internet of Things (IoT) devices, wearables, call centres, and customer experience systems.
Ebook
Sitecore CMS Best Practices Implementation Audit Guide

What is xDB in Sitecore?

The Experience Database in Sitecore is preferred by marketers in the field of Web Content Management Systems. It stores analytics and interaction data for visitors across all your digital touchpoints in cases when the user is known or unknown. In a nutshell, xDB considers and collects all the customer interactions from all sources in a real-time, big data repository. What it generally does is connect all the data to create a comprehensive and single-view of each customer. This helps marketers to manage customer experience in real time!

For instance, in Sitecore 9, the default data provider for the Collections database in xDB is now SQL Server 2016, not MongoDB!  When xDB was launched with Sitecore 7.5, the contact and interaction model revolved around web interactions.

This illustration explains how everything revolved around a user or Contact here who interacted with your brand on the web. This Contact had multiple interactions and these interactions held a collection of pages that were been visited by the user. These pages had their Page Events, Goals or Outcomes that had been triggered. In case you wanted to do something with external data, you could track the kinds of offline interactions. It was a little tedious though since a fake Page had to be created to hold the event, goal or outcome, just to add it to the interaction. That’s not all - now since everything revolved around web interactions, all the data that was flowing in to and even out of xDB had to go through a full, kernel-based Sitecore instance.

Here’s an illustration of xDB from Sitecore 7.5-8.*:

As you can see, there were many pieces of the Sitecore platform that depended directly on the Collections database.

With the introduction of Sitecore 9 and xConnect, this is how it looks now:

In Sitecore 9, the default data provider for the Collections database in xDB is now SQL Server 2016, not MongoDB, but this does not mean that it won’t be supported.

Pipelines in Sitecore

By definition, a pipeline is a sequence of actions that are executed to perform a task in Sitecore. They are critical to Sitecore’s basic architecture and in fact, most processes are defined as pipelines. These can be modified by developers to either change, add or remove functionality from Sitecore.

Pipelines generally are comprised of more than one step, which are known as processors.

For example, here is the definition for the getRenderingPreview from Sitecore.config:

When the getRenderingPreview pipeline is executed, the processors defined above run in order from first to last. Most pipelines transfer data between each processor in the form of an arguments object. For example, getRenderingPreview makes use of an argument object called GetRenderingPreviewArgs. This stores data that each processor of the pipeline may need. This also includes data about the current Sitecore context.

Types of Sitecore Pipelines:

Sitecore separates the pipelines into two groups:

1.Those defined within the /configuration/sitecore/pipelines.

Example:
<initialize>: Initializes the Sitecore application.
<preprocessRequest>: This is invoked for each HTTP request managed by ASP.NET

The Processors of this pipeline are:

   ex: <processortype=“Sitecore.Pipelines.HttpRequest.EnsureServerUrl, Sitecore.Kernel”>

2.Those defined within the /configuration/sitecore/processors.

Example:

<uiAddFromTemplate>: Add an item based on a data template, branch template or command template.
<uiCopyItems>: Copy an item and its descendants.
<uiCloneItems>: Clone an item and its descendants.
<uiDeleteItems>: Delete an item and its descendants.
<uiDragItemTo>: Invoked when a user drags and drops an item to move it.
<uiDuplicateItem>: Invoked to duplicate an item.
<uiMoveItems>: Invoked to move an item and its descendants.
<uiRenameItem>: Invoked to rename an item.
<uiGetMasters>: Determines the insert options allowed for an item.
<loggingin>: When logging in.
<loggedin>: After login.
<logout>: Implements logout.
<saveUI>: When a CMS user saves an item.
<uiUpload>: Upload a media item.

Call a Pipeline From Code

Every pipeline needs to follow a certain convention and also implement a Process() method, which must return void and also incorporate an arguments class based on Sitecore.Pipelines.PipelineArgs. For example:

Once this pipeline is configured, it can be called elsewhere in the code by using Sitecore's CorePipeline class:

Modifying Pipelines

Most pipelines are called as part of existing Sitecore processes and features. When you add or modify processors to Sitecore's existing pipelines, it is possible for developers to modify the core functionality of Sitecore. What must be noted is that modifying an existing pipeline does require a processor and the appropriate configuration change.
 For example, here's the class for a new step in the PublishItemProcessor pipline:

Here's the configuration for that pipeline. We want to add this processor after the UpdateStatistics step:

And here's the configuration patch file to insert the custom processor to the pipeline:

At Altudo (formerly eDynamic), we help our clients deliver exceptional customer experiences through 1:1 personalization & enhanced engagement, to grow revenue streams.

As Sitecore Platinum implementation partners, our deep understanding of the Sitecore ecosystem goes beyond the basics of CMS, to unleash the true potential of a seamless, personalized website experiences & curating engagement analytics throughout the customer journey.

Kapil Oliveti


Browse Topics

Talk to our Experts

Talk to us about how we bring together 1:1 personalisation, deep Martech Expertise, CX & Demand Gen Strategy, Engagement Analytics & Cross-Channel Orchestration to drive award winning experiences that convert

Get in touch for a complimentary consultation or a demo today.