Sitecore Data Modeling Approach for Integrations with Language Fallback

November 14, 2016 Mike Skutta

Overview
We have several clients that integrate or sync data from their HR system into Sitecore.  This typically consists of “people data.”  These people appear on the website with their respective biographies. The data is brought over to Sitecore on a recurring basis.  While the HR system is considered the authoritative source for the people data, sometimes the marketing department requires the ability to override the data in Sitecore.  In some cases, the data from the HR system is not the data they want to display on the website.

How do you support this within Sitecore?  There are various ways to setup the data templates and structure the data.  One way we have found that works well and does not require any additional logic is using language fallback.

Approach
Starting from Sitecore 8.1, language fallback is supported out of the box.  Language fallback is best explained in this article: Language Fallback.  The key take away is, “If a version does not exist in a given language, language fallback activates, and the item or field value is displayed in the fallback language instead.” 

We can use the language fallback to support the data sync and ability to override data, and then take the approach of setting up a base “integration” language.  When data is brought in through a data sync, the data is saved in the integration language version of the item.  Users are not allowed to edit the integration language version of the item.  Only the data sync can modify the data in the integration language version.

The other languages fallback to the integration language.  For example, English falls back to the integration language version.  The public facing site does not directly reference the integration language.  The site rather references the languages that fallback to the integration language.

By default, the English language version does not have the fields filled out that are populated by the data sync.  This allows the English language version of the item to automatically use the field values that come across as part of the integration. If the marketing team wanted to override the values from the integration, all they need to do is set the value of the field in the English language version of the item.  This automatically overrides the value from the data sync.  If they want to revert back to the value from the data sync, all they need to do is reset the field.

The benefits of using this approach are as follows:

  1. Language fallback is natively supported in Sitecore.
  2. Developers building the front end of the site do not need to be aware of the data coming from the integration or if it has been overridden.
  3. Glass Mapper and most other ORMs naturally works with this approach.
  4. Lucene and other search technologies naturally work with this approach.

Here is a diagram depicting the approach:

Data Modeling in Sitecore

Implementation
Sitecore uses the languages/cultures registered on the server.  If you want to create a unique language to represent the integration language, you can optionally create a new system.  Alternatively, you can use an existing language.

To create a custom system language, you can use the following code:

We can then register the integration language in Sitecore:

Sitecore implementation

For the other languages, set the Language Fallback appropriately:

Data modeling in sitecore

For the Fields that are populated via the data sync, they need to be setup as NOT Shared and NOT Unversioned.  Enable field level fallback also needs to be enabled.

Data modeling Approach for Integrations with Language Fallback

You can optionally lock down editing content in the integration language via security.

After these changes are made, you should be able to load data into the integration language and allow the other languages to override.

One thing we need to make sure never happens is publicly exposing the integration language version of the item.  We don’t want the integration version to be linked to or indexed by Google.  The language versions that fallback to the integration language are the versions that should be exposed.  Logic can be added to the <httpRequestBegin> pipeline to prevent this from happening.

Conclusion
This Data Modeling approach has served us well when it comes to data integrations and data syncs.  There are definitely other approaches out there.

Subscribe

The One North Ideas Update delivers each month’s latest posts on digital for PSOs—including industry trends, news and our latest research—directly to your inbox. Although it’s our goal to always include thought-provoking and compelling content, you can unsubscribe at any time. 

See our Privacy Policy to learn more about how we protect and manage your submitted data.

Mike Skutta Architect

As an Architect within the Technology Labs group at One North, Mike works to research, test and integrate new technologies for both One North and its clients. He is also a Sitecore Technology MVP – a distinction received by only 217 people worldwide – and holds more than 14 years of experience architecting, designing, developing software and leading technology teams. Based in Florida, Mike is often seen wheeling around the office via our robot.

  • Favorite vending machine snack: Doritos
  • Most unusual job: Working as a Serf at Medieval Times

One North Interactive 
222 North LaSalle St, #1500
Chicago, IL 60601

+1 312.469.1740