Tag: coveo cloud

Posted on

Implement Coveo on Multi Tenant/Multi Language Architecture

I am very excited to start this series as we are almost close to pulling off Coveo Cloud Implementation on a multi site/multi language Sitecore Instance using legacy Coveo For Sitecore Javascript Framework to support web forms Sitecore Implementation.  I am gathering my thoughts around all the challenges we faced while getting Coveo to work seamlessly with complex Sitecore Instance.  Some were very straight forward and some were anything but that. 🙂

I am going to list down each important problem and note options to tackle each.  Do note that though most of the solutions I would attempt to provide are generic, it highly depends on your Sitecore implementation and customization done to Sitecore in general.

One thing that really helped me solve some of these is understanding when and where Coveo connects with Sitecore.   I would recommend to deep dive on this to any one who is attempting to implement Coveo For Sitecore on their multi tenant and multi lingual Sitecore implementation.

I will start by noting the first problem we faced right after Coveo for sitecore installation on our system.  On Diagnostics page, we had the error such as noted in question and answer below.

https://answers.coveo.com/questions/15435/coveo-search-rest-endpoint-invalid-uri-the-format.html?childToView=15530#comment-15530

One of the first question to answer when implementing Coveo For Sitecore is – Does your Sitecore implementation have a custom link manager as that drives what you would need to watch out for or customize if needed, a quick way to check would be

-> Go to your /sitecore/admin/showconfig.aspx and examine what you see in the node below.  if you see default provider as something other than “sitecore”, then, you can ensure that there has been some customization done on this.  To be honest, any medium to high sized Multi tenant instance that has been active on Sitecore for long time would have some customization around it.  So, it is even more important to know how to ensure Coveo works with your custom link provider settings.

link provider section on config

For instance, in our case languageembedding setting on Linkprovider was set to “always” which means that any website/site served by Sitecore, when a link is generated it would append language to it.  That should surely ring some bells, in  Coveo For Sitecore case upon installation of package, you would see three new sites in the <sites> node when you take a peek at showconfig which are named as coveo_website, coveoanalytics, coveorest.  We definitely do not want to add language embedding on these URL’s here to ensure we do not throw off internal business logic on Coveo end.

To gracefully solve this, I would recommend having an ability to use different Link Providers per site.  There is a very decent solution compiled by my favorite Sitecore MVP Jammy Kam below.

Site Specific Link Provider for Multisite Implementation in Sitecore

By doing this we can assure that Coveo specific sites do not have language embedding in it that would cause issue noted on Q&A above.

Of course, if your sitecore implementation was done more on old school style where the answer was – There is a pipeline for that. 🙂

In those cases, check to see where you can ensure to exclude Coveo sites from having language embedding on them.

One open question I do have is would this be any different with Sitecore 9.0+, a short answer might be a NO.  If any one has any input in regards to this, leave a comment.

That is it about our first ever hiccup, more to come soon.  My hope is that this series will help any one who is driven to use Coveo for Sitecore components and power of framework on a complex Sitecore instance, but, are worried that it might be quite a feat or they might be safe using total custom system.  You can re-visit my blog on this topic and I am sure you will get confidence in sticking to framework instead.  🙂

Tune in for more on this series!

 

 

Posted on

Coveo Cloud Learnings – Part 1

Coveo_Cloud

I am super excited to share my experiences with you as I rolled up my sleeve to play with super cool search tool out there, Coveo Cloud!

Before I got this chance to work intimately with this platform, I did hear a lot and read a lot.  Was wondering and anticipating, when will I get to actually do hands on and I really wished to do that before I head out to Coveo Impact at SanFrancisco this year. Between, crazy excited to hear all the awesome new things and also geared up to participate in their Hackathon event as well.  Know more about their event here below

http://impact.coveo.com/

Now, I plan to write up my experiences with Coveo cloud first hand, the project is near completion on my end and I think this is the perfect time to reflect on all the set of challenges we had while pulling off a simple yet complex due to Architecture decisions involved on the project.

First things first, when you are about to start implementation on Coveo for Sitecore platform, decide on your version and framework you plan to use.  This goes long way to ensure you picked the correct version that supports all your other related third party components and ensure it is indeed a right step towards desired search experience.

On this project, we chose December 2017 version matching the Sitecore version we are using on this instance.  My first comment on getting Coveo for Sitecore up and running on my local and other environments is “Piece of Cake”.  Compared to challenges, hiccups I and my fellow team members had with on premise version of Coveo, this was a total opposite.  It took me less than an hour as opposed two full days(give or take) with on-premise version.  It was an awesome feeling to see the green quite quickly this time.

While you are at this step in your project, also, decide which version of JS framework would you like to use.  I would vote for Hive as it is new, more robust and modular, but, it highly depends on project of course.   You can see compatibility and more decision factors here on their documentation.

https://developers.coveo.com/display/public/SitecoreV4/What%27s+New+In+Coveo+for+Sitecore+4

While I was doing the steps or while trying to understand the new platform, I tried comparing and contrasting to the knowledge I had working with their on-premise version.  It did help me a lot actually trying to figure – “How is this different from before?”

Some helpful notes on Installation and Set up with Cloud.   Do note that your sitecore indexes, both, master and web would be now on Cloud and so are your logs, content browser and other cool things you were used to pulling up from port 8081, it should now all be located on Coveo Cloud Console. Also, understand that some features are now abstracted out, like you can not turn off and on the live monitoring on indexes for instance.  One important thing to realize is all your index rebuilds are queued in some fashion which you may not have control over, so, talk to your Coveo consultant or drop in a support ticket if you encounter some delays more than usual on your rebuilds.

On our end, we always ensure to use cloud sandbox(trial) for all our lower environments.  Note that there could be some limit on number of indexes on Sandbox, so, check with your Coveo rep when in question.

One subtle catch I would like to mention is – after installation of Coveo for Sitecore and hooking up proper Coveo Sandbox configuration and a full site publish, I did see the web index on the cloud from Sitecore perspective, but, note that master did need a manual rebuild by going in to your Indexing Manager on Sitecore Control Panel.

If you got time on you, explore the Coveo Cloud Administration Console, it has different and clearly named sections that should give you fair idea on which is what, but, it is definitely worth going over this as you drill deep in to Cloud Implementation.

Also, note that with Cloud you can build sample search pages on the fly, it is a cool feature to test some of the fields you have on your index or could be a custom build external index that you would like to target, but, if your implementation calls for some thing more complex, I would recommend to house your search pages within your sitecore instance by customizing the components and adding them to your presentation plus creating the templates.

So, you installed Coveo For Sitecore cloud version, got all green in diagnostics, sitecore indexes in check and could see your items and indexed data on cloud console content browser.  Did I hear that right? That is it, we can now jump right ahead and do some cool stuff that is made possible by the platform.

My next blog will focus on more challenges, gotchas and learning we had during this wave of time.   Also, will expound on choices we made at each step as well.

References/Helpful Resources for Coveo For Sitecore Cloud 

Installation guide:
https://developers.coveo.com/display/public/SitecoreV4/Installing+Coveo+for+Sitecore

Architecture and Beyond
https://developers.coveo.com/display/public/SitecoreV4/Understanding+the+Architecture+of+Coveo+for+Sitecore

Framework Choice

https://developers.coveo.com/display/public/SitecoreV4/What%27s+New+In+Coveo+for+Sitecore+4

Coveo Impact

http://impact.coveo.com/

Versions

https://developers.coveo.com/display/public/SitecoreV4/Downloads

Posted on

A Battle – Coveo Search Framework | Coveo Search API

I am going to give it away to you all in who is the winner. 🙂

In reality, I think there is no battle when there is a clear winner and your vision to pursue should always be to use Coveo for Sitecore platform.  When the world turns up side down, you hit the wall like 100 times and when Coveo team also gives up only then you would pick the other option to build ground up.

Folks who love to code to solve problems or passionate to take full control in to their own hands in terms of business logic implementation have to remember and think about why did the executives spent money and time investing in Coveo For Sitecore.  Now, with the cloud version, their biggest selling point is of no suspense, heavy contexual marketing and machine learning are sure a huge cherry on top to their easy to integrate search experience.  Between, if you have installed Coveo for Sitecore on-premise and then also had experience with Coveo For Sitecore cloud, you will have to agree with me.  It took minute slice of earlier to set up cloud platform on a Sitecore instance.

Recently, after we did a thorough comparison between these two options for one of our clients, Coveo team released their best practices, I included the link here.  If you have not already, please check this out, it is very useful.  I definitely learned and shared a thing or two from here with my teams.  Now, this document just solidified what we pitched and I could not be more happier. I mean getting a backing from Technical Architects from Coveo on what we thought was correct approach.  Nice feeling you all!

Coveo Best Practices Document:  https://developers.coveo.com/display/public/SitecoreV4/Coveo+for+Sitecore+Project+Guide

Hint:  Look at Page Number 52 – Section Developing Against the Coveo Search API directly

I would like to share pros/cons of these approaches for any one who is trying to convince their client to not lean towards re-building something they don’t have to. 🙂

To keep this to the point, I will list what you will miss if you go with using Coveo Search API instead of Coveo for Sitecore framework.

Disclaimer:  Got to Hurt…Ouch!!!

  1. You will forgo ability to be able to add in Coveo Custom Components, they are becoming more and more powerful especially if you have Enterprise and above license where you hardly would need to write any JS, just use properties as much as you can to pass in those Filtering and other settings.
  2. Incremental refresh of Indexes – Depending on how huge your solution is, this will hurt you more. 😉 Coveo when integrated with your sitecore deeply you will notice that it taps on to most important pipelines to ensure it keeps your master and web indexes in sync using some clever strategies.  That means it will not rebuild the whole indexes until you request it to do so, saving lot of time and being efficient.  Web sources and other type of indexes you might create might not have this feature.
  3. Machine Learning/Coveo Analytics and any thing beyond.  Now, let me re-iterate the obvious, the world is moving towards AI for better or for worse and this might be one the biggest reasons why Coveo was a big win and hence the decision to go forward with the product.  Coveo Analytics are collected through one of their component that when added to search interface will push all the goodness ML would need to then use awesome Coveo ML features such as query suggestions and ART for instance.  You will miss out on this if you do not install the framework.  Now, I do see some API’s with which you can get usage analytics and either do a read or write to Coveo Analytics using the same, but, why go through this process when you can simply add a component that has been built and tested by Coveo.  If you are curious –

https://usageanalytics.coveo.com/docs/write/

https://usageanalytics.coveo.com/docs/read/

There could be more?  you think you know some? Leave a comment.

Now, remember all this losses while making a decision, but, also do understand that in some really complicated architectures where there seem to be no way that we can seamlessly integrate and use full power of Coveo platform then Coveo Search API in combination of a lot of custom code might be a way.  But, before you go that route I urge you talk to every one you think might know a different, better or easier way to fully juice and extract the goodness of the platform.  At the end of the project, we definitely do not want regret on our plate on this type of decisions.

Now go out there and make some tough decisions. 🙂