Digital Learnings in Sitecore & Cloud

We recently had the challenge of moving across a legacy project, that we inherited, to run on Azure DevOps.  This project is five or six years old and still leverages TDS for packaging Sitecore items. Helpfully the code repository already had a copy of the nuget package contents checked in and referred to by the TDS project files, however this was designed to use an older version of visual studio (2015) than we had available as a part of the default Microsoft supplied build agent (2019).  In addition we needed to make sure the build agent was able to use our TDS license keys. Setting up the TDS license The old HedgeHog documentation has some good info on how to set up TDS to run on a build server.  This states to set up two environment variables: TDS_Owner and TDS_Key with the license information that the TDS tool will look for at runtime. Our first attempt to follow this instruction for DevOps was to create a powershell task to set the variables - task: PowerShell@2 ...

We've been working on a large headless solution recently that utilises Sitecore Experience Edge for XM. We are working in a micro-front ends architecture, with some parts of the site leveraging Sitecore JavaScript Rendering SDK (previously known as JSS) for delivering pages whilst supporting full inline editing and page designing. Other parts of the site use GraphQL queries via backend-for-frontend (BFF) style APIs to pull back content. Both these approaches leverage Experience Edge for serving GraphQL however the nuances of how they are implemented need to be understood because we have found they lead to some different behaviours that can impact the way content editors need to use the system. The point of rendering One of the most important things to understand about Experience Edge before you start using it is that for performance reasons it does a lot of work at the point of publishing, that used to happen at the point a page was rendered when using Content Delivery instan...

Sitecore JavaScript Services (JSS) was launched, now a few years back, as Sitecore's solution for meeting the needs of doing headless content mangement on Sitecore using JavaScript, without losing the key capabilities (especially in line editing) which makes Sitecore great. It consisted of JavaScript SDKs that worked with the JSS layout service running on Sitecore. Now renamed the Sitecore JavaScript Rendering SDK , and supporting the JSS services or Experience Edge, this SDK is an important part of delivering JavaScript web apps leveraging Sitecore editing capabilties. That said, for a lot of front end developers JSS is a skillset that they might not know a lot about. Using it properly requires not only an understanding of how to install and work with the SDKs, but also understand Sitecore concepts such as placeholders. Furthermore not all web use cases, even those that leverage content, benefit from such advanced capabilities. Benefits and complexities I see the followin...

In a project where we're implementing Content Hub, there in a PIM system which is used to manage products that feed into various downstream systems. Content Hub is to be the new source of truth for Digital Assets, and this will include all product images. We already have various entities mastered in other systems including PIM such as products and categories bing syncrhonised into Content Hub as taxonomies that will enable tagging of Digital Assets to assist in organising them. This integration is done via Mulesoft with the PIM system raising an event when an individual product/category is changed, with a Mulesfot subscriber responding to the event and pushing the change to Content Hub via it's REST interface . In our case we want the association of product images with products in Content Hub to control what images are shown for products in downsteram systems. This means that data will flow from Content Hub back through Mulesoft and into PIM. PIM then manages the flow of ...

In Part 1 of this series, I covered the background of relevance scoring in search and covered setup of Search Studio and Sitecore CDP & Personalise. In part two I will work through some example code that pulls these products together to show end to end search capability using the setup we covered in the last post. This demo code provides a command line "head" which utilises the Sitecore and Search Studio APIs to return personalised search results for the provided search terms of user. Overview The high level flow of the demo application is reasonably simple: Console.WriteLine("Getting search model for user " + email); var searchModel = await GetModelForUserAsync(email); Console.WriteLine("Search Model calculated: " + searchModel); Console.WriteLine("Getting search results"); var searchResults = await GetSearchResultsAsync(searchModel, term); if (!(searchResults is null)) ...

I had the opportunity recently to present at a Sitecore User Group session with Sameer Maggon , the founder of SearchStax. We've used SearchStax for many years to provide cloud hosted managed Solr Cloud for customers -- Sitecore even use SearchStax in their own Managed Cloud offering -- and the now have a new SaaS offering called Search Studio that lets you define different models to apply to searches which alter how relevance scoring is calculated. In part one of this blog post, I'll cover the main moving parts of SearchStax and Sitecore Personalise used to drive the solution. In part two I go through some example code that uses the two configured products together to render personalised search results. Relevance scoring When content is indexed for searching, the contents are tokeninsed and put into an index. Information is stored in a "Document" (either tokenised or stored directly) with term vectors associated. Term vectors are essentially the individ...

The Sitecore product family now provides two key platforms where you can manage content (and technically this is now expanding as you can manage content in Sitecore Send and Sitecore CDP as well -- the future for these is unclear however I'd expect the patterns below may well expend to those other delivery channels in a similar way).  When you have platforms with overlapping capabilities, I believe it's always important to have some clear principles as to what the role of each system is in the overall architecture - so you know what you should and should not do in each place.  I guess it's kind of like putting together a recipe to follow when you are making decisions to ensure that everything works together and you don't end up with a failed cake. Below I outline one way that I feel makes sense to align the responsibilities between Sitecore XP/XM and Content Hub in an enterprise digital architecture. The moving parts The Sitecore tools that we're considering are ...

In a Content Hub implementation you might often need to produce multiple different size of an image that you can link to from external locations. One way to do think in Content Hub would be to create multiple renditions and create public links to them, however there might be cases where you want a bit more control over which assets you create these links to and when in the lifecycle of your content you do this. In this case another useful functionality of Content Hub is the ability to apply conversions directly on public links. Within the UI you see that there a number of options for controlling the public link output: However if you want to control this programatically you will need to interact with the underlying entity record. Looking at the entity record for a public link, you see that this information is captured in a Property called ConversionConfiguration . However the content of this property is a JSON string -- so how do you interact with it from code? ...

We are now well and truly in the age of the API, however I feel that there is still a lot of confusion about the best patterns to put in place in how to structure APIs,  There are a number of competing patterns with some overlap and plenty of trade-offs, particularly in the space of building digital systems where the MACH alliance  is gaining momentum.  Some of the patterns you might have heard of include Microservices, Backends-for-Frontends (BFF) and domain services. I personally prefer to think about structuring APIs in terms of the different types of logic the a system composes of and how this impacts the trade-off between pace of change/innovation compared to reuse and stability.  These two forces are in constant tension in enterprise level development, and is well captured in Gartner's  Pace Layered Architecture  concept. Layers of logic I like to categorise the logic implemented a system into four different layers, as shows in the diagram below. ...

So has been a long time between drinks for my blogging activities! I thought I'd try to get back in the swing by capturing some of the learnings from our current roll-out of Sitecore's Content Hub platform. Content Hub is a pretty neat product, providing really good Digital Asset Management (DAM) capabilities along with MRM and what is called Product Content Management (PCM) which provides a light PIM capability. I think where it really shines however is in it's Content Marketing Platform (CMP) module. Perhaps more about that a little later. If you are used to deploying a platform like Sitecore XP where you have access to the product binaries to dotPeek at, and get really detailed logs, debugging issues within Content Hub can be a bit of a laborious exercise. As a SaaS platform you only get the documentation (which although decent is never as detailed as you need it to be) and some fairly high level error logging. The system is very configurable too, which gives you p...

In my last couple of posts I've talked about when to choose a multi-site versus a multi-instance pattern for deploying Sitecore, and how we approach delivering Sitecore platforms using feature based modular development . In this post I'm going to take a look at the sorts of issues that arise when large global organisations start to look at rolling out digital platforms, and how some we can leverage some of the points that we've covered in the last couple of posts as a part of our approach to designing a Sitecore based digital platform architecture that addresses them. Tyrannies of global size Large organisations hosting a number of different websites are often confronted by some competing forces which lead them to ask about whether they should have multiple sites in a single or multiple Sitecore instances.  These are usually related to the following requirements which address different types of web presence for different parts of a business: We have different site...