SXA date variant and language fallback

Sitecore SXA DateVariantField

Note: this post assumes you know what a SXA variant is - if not, please read the documentation first.

Within a SXA variant, you can use a DateVariantField "Date" to display date and time from a date field in a chosen format. This definition is similar to the Field variant, but has an additional field "Date format" that allows you to choose a date and time format.

The date formats are stored in /sitecore/system/Settings/Foundation/Experience Accelerator/Rendering Variants/Enums/Date Formats as items (with display names).

On https://sitecore.stackexchange.com/a/8489/237 Alan explains how this works together with cultures and such. In short: SXA will render the date in the current culture with the given format.

We have a project with a few languages and language fallback is enabled with English as fallback for all other languages. Our date variants worked perfectly in Sitecore 9.0.2 with SXA 1.7.1 but after our upgrade to Sitecore 9.2 and SXA 1.9 we saw something weird...

Date variants and language fallback

So we have a site with language fallback enabled and it seems to work fine. But then we noticed weird date formats in our date variants when switching languages - although we had the format set to dd/MM/yyyy we did see a time value:

In English everything was still ok.

The workaround

First thing to check is language fallback is actually enabled on the site.

Note that since SXA 1.9 there is a checkbox to enable item language fallback. As this is an upgraded site, we also still have the fallback setting in the Other properties field, just to be very sure...

The workaround for the issue that I solved it for me was:

1. Create language versions for /sitecore/system/Settings/Foundation/Experience Accelerator/Rendering Variants/Enums/Date Formats/date2 (which is the dd/MM/yyyy item) and give them a display name just like the English version. Repeat for every format you want to use.
2. Remove the standard value from the variants format field. Save. Then select the dd/MM/yyyy again (this time actually selected and not as standard value). 
3. Create language versions for the variant item.

Not all steps might be needed - Support and myself had some different conclusions on that.. and I think caching was also involved. Step 2 however is certainly needed - with a standard value it won't work (bug listed with reference number 119290)

But with this workaround all was fine again.

Sitecore reporting server getting lots of requests?

Reporting server issues in Sitecore 9.x

As part of an upgrade process,  we installed a new Sitecore (9.2) instance on PAAS. No custom code was deployed to it yet. Rather soon, we noticed lots of requests to our reporting server in the logs. As we started importing packages with content, the number of requests seemed to go up until a level where it became troublesome as our logs were really flooded with those requests. With a little help from Sitecore Support we found the issue and I documented it on Sitecore Stack Exchange: https://sitecore.stackexchange.com/q/23923/237

However, recently Chris Auer send this tweet:

Have you checked your reporting database lately? There might be a chance it is chewing up CPU ticks for little reason. One of our clients was seeing 100% every hour on the hour. #Sitecore 9.1 - 9.3 KB fix. https://t.co/hnoNbfWBWy pic.twitter.com/6701paBpLJ

— Chris Auer (@ChristopherAuer) February 26, 2020

This made me realize that more symptoms might be found for actually the same "issue".  A blog post might help to capture those in one place...

Symptoms

What are the symptoms you might encounter:

• rebuild of the sitecore_suggested_test_index is triggered every hour (this is actually the root cause, you should find this in your logs and probably think that is ok)
• High peaks on the reporting server or database as described by Chris
• Logs flooded with requests for: POST /~/v75/reporting/remotedatasourceproxy/

The symptoms will come in batches of an hour, as seen in this view of our Application Insights logs for the POST request to the reporting server:

The root cause

The root cause is actually the sitecore_suggested_test_index which triggers those POST requests. 

The issue is described on the Sitecore knowledge base, and appears in versions 9.1.1+ (reference number is 336911 - as soon as we see this in the release notes, it is fixed). Sitecore mentions this can increase resource consumption - meaning flooded logged and/or possible resource peaks.

The fix 

There is no real fix to stop the requests as those are apparently needed - but you can change the schedule as mentioned in the KB article: change the schedule info on /sitecore/system/Tasks/Schedules/Content Testing/Rebuild Suggested Tests Index to "20140101|99990101|127|1.00:00" for 1 day instead of 1 hour - or go for even less (7 days would be "20140101|99990101|127|7.00:00")  if you don't use the functionality.

Suggested test index

The suggested test index is described on the Sitecore documentation site. 

The Suggested Test index provides storage for computed values for all of the content items in the content tree and is used to suggest the items that should be optimized.

This index drives the suggested test list in the Experience Optimization and inside the Experience Editor. It is also used in the Sitecore client UI to show when a test has ended.

This might help you determine a good period for the rebuild schedule.