Lesson learned – register your own custom route!

It’s been a while since I last updated this blog. Today I want to talk about a lesson learned, a fact that maybe known by many Sitecore developers already but I’ve only recently realized.

I’ve recently worked on a project to create a new component. The project I work on is on Sitecore 8.x and we want to use AJAX call for this new component. As always, I am a lazy developer, so I was thinking to take the shortcut – make use of Sitecore pre-defined route api/sitecore/{controller}/{action} instead of registering our own route. We created a small POC on our local and it works – perfect – until we deployed the new feature to UAT.

The deployed new feature doesn’t work on UAT, or more strictly speaking, not working on CD servers. The AJAX call returns 404 not found. It is however working as expected on CM server. After some investigation , I realised the route we are using api/sitecore/{controller}/{action} is intended for SPEAK framework. So now it makes sense why it can only use in CM server. SPEAK is for Sitecore client use only so it doesn’t work on CDs. And when we tested it on our local, because we don’t have the CM/CDs setup so we didn’t find out.

Sitecore register this route in Sitecore.Mvc.Pipelines.Initialize.InitializeCommandRoute pipeline. And there is way to enable to it to works on CDs by register the route on CD servers through Global.asax. However after reading few articles I think actually it’s not a good idea to use api/sitecore/{controller}/{action} for many reasons

1. It has deprecated so we will have issue with this route when we upgrade anyway.
2. To avoid clashes with Sitecore API it is good practice to have your own route.

Details about how to register your own route, please refer to Sitecore documentation here.

Sitecore 10 in Docker! – and the issues I got during install

Earlier last week, I was excited to hear that Sitecore 10.0 is released. Apart from all other new and innovative features, I am sure there is one thing all developers are exciting about – it is officially support on container!

There are some great works done by the community for the earlier version already, they can be found on https://github.com/Sitecore/docker-images

With version 10, Sitecore has a good guide to get start https://containers.doc.sitecore.com/docs/environment-setup

The documentation is straight forward and it lists out what commands to use at each step, so I am not going to repeat it here. But I did encounter some errors because different set up on individual machine. I am going to list out and explain here in case anyone get the same error and looking for solution.    

For the preparation, I use the script init.ps1 provided by the docker example repository. This script automatic a lot of the steps in preparation so I don’t need to update them manually.

The first error I run into is the init.ps1 file is not digitally signed, so my machine does not allow me to run it.

This means the script is not trusted to run on my system and I need to run command to bypass the execution policy, here is the command

Then I encounter the second error – a parameter cannot be found that matches parameter name ‘AllowPrerelease’.

This is because I have more than one version of PowershellGet installed, and there is a bug with 1.0.0.1 – it seems that the PowershellGet PackageProvider will still default to 1.0.0.1 even higher version is installed.

So I run the following command to force to reinstall the correct version.

TA DA! Now the script runs and do all the steps for me

Now it is exciting moment – start the sitecore 10 instance using docker-compose up. But hang on — Traefik shows error?!

Thanks to the powerful Sitecore community, @thebicninja and @techphoria414 soon point me to the right direction. It was because of the port conflict. My local instance has already use port 443 so I have to get it off from IIS so Traefik can use the port. I have since then saw people having similar issue but it is the solr port 8984. A full list of ports(443, 8079, 8081, 8984, and 14330) that’s been used by the default configuration can be found on the before you begin section on sitecore containers doc.

That’s all I have to do, now my sitecore 10 instance is up and running with docker. Simple, right? Have a go 😉

Update Sitecore Indexes Programmatically -Difference between ISearchIndex and IndexCustodian

When it comes to rebuild Sitecore index programmatically I’ve never realized there are two methods to do it and I’ve been using the less effective one.
From a recent task I need to add a schedule task in Sitecore to automatic rebuild index every day. I used the method directly on ISearchIndex from Sitecore.ContentSearch as this is not a stranger to me – I have seem it from many blog posts^1,2 and my past projects. That I almost think that’s only way. Below is a snippet of the code.

And I assume this is the same as doing the re-index from Sitecore control panel interface. But it has proven I am wrong very soon. After our first schedule rebuild index, we had an issue come up, and the issue can be fixed by a manual rebuild. We are using Coveo for Sitecore on search so I reached out to their support team. And Coveo support is very helpful, they point out that we had a Sitecore config setting that was different on production. So we solved the issue by update the Sitecore config. But this makes me think why my schedule re-index any different than manual re-index. And it turns out that using IndexCustodian from Sitecore.ContentSearch.Maintenance is more appropriate in our situation.
Using IndexCustodian for indexing is similar to indexing through Sitecore control panel, which starts as a job in asynchronous and non-blocking way. While the rebuild command from ISearchIndex start rebuild synchronously. IndexCustodian also performs ‘ForceIncremental Index Update’ even if indexing is paused or stopped. And it also supports switch-on-rebuild. So ‘IndexCustodian’ is a more effective and recommend way to do the task.

Below is the snippet of code after update.

Choosing an ORM for your Sitecore Solution

Most of us start of with Sitecore API but it will save us a lot of time for data conversion when we use ORM framework for our Sitecore solution. And the thing I like most for using ORM is the fact that we can get rid of those magic strings of the field names so it keeps our code cleaner and more maintainable. The two most popular ORM for Sitecore are Glass Mapper and Synthesis. I’ve use Synthesis a lot in the past projects but only recently had the chance to use Glass mapper even though I know it is there for a long time.
It is interesting to see the differences between them, here are some aspects.

Set up
For installation, Glass mapper is easier – just install the nuget packages and job done. Details can be found from their website https://training.glass.lu/courses/367234/lectures/5610532
As for Synthesis, apart from install nuget packages, we might want to tweak settings of Synthesis,config. And it could get more complicate depends on your solution. https://github.com/blipson89/Synthesis/wiki/Configuration

Get Start
I find it very easy to get start with Synthesis as I can still use Sitecore API most of the time, just get the sitecore item as we always did with Sitecore API and covert into the model generated by Synthesis using .As() extension. Then I can use IntelliSense to figure out the properties and methods. So basic daily task takes minimal effort to learn. In comparison, getting start with Glass mapper will have a slightly learning curve. A free fundamentals short training is available at https://training.glass.lu/p/glass-mapper-sc-introduction. For more advance topic, you will need to enroll in paid training. I am able to complete basic daily tasks with just the free training documentation.

Speed
Synthesis is much faster than Glass mapper, this is because Synthesis is a wrapper rather than mapper. So internally it reads from a Sitecore item. Through Synthesis has the advantage for performance, it lost the flexibility as the models are tightly coupled to Sitecore template.

Generate Model
Synthesis generates strongly-type models directly from Sitecore template. This is very handy for developers to use straight away without any modification. While use Glass Mapper, developers need to create and decorate POCO models. But as we said from the above paragraph, this option gives developers more flexibility. With Glass mapper, it is possible to update the properties of the model without affecting the related Sitecore Item. And the models don’t have to match the data structures used in Sitecore. If you want to save time from hand-writing models, there is also option to generate model automatically for Glass mapper, we are using TDS in the project.

In all, both are great tools and popular among the community. There is no “best” one for all projects, it all depends on developer’s preference and experience.

Hello world!

As a Sitecore developer, I want to start my blog and write down my notes and my learning for years. But I have been using “too busy with projects and works as excuse” for my laziness. Like most of the other developers, I prefer write codes than documentation. But here I go, after register here for 5 year, I finally decide to start my blog post. Bear with me and stay tuned 🙂

— Edited at 2020