Digital Learnings in Sitecore & Cloud

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. (1) Presentation Logic

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