Monday, February 29, 2016

Sitecore 8.x Component Datasource Item Locking Behavior



A question was posed on the Sitecore Community Site around items in workflow and component datasource item locking, and it piqued my curiosity enough to want to dig in to understand Sitecore's behavior on datasource items when we have multiple content authors working within the same content scope.

After my review, I discovered some unexpected behavior that could pose a potential problem for content authors. Talking through the results with veteran MVP, Kamruz Jaman, he suggested a potential workaround that could will help provide relief for author's in this scenario.

Test Configuration

In my tests, I was working with Sitecore 8.1 Update 1, and created Author A and Author B who were both part of ​the sitecore\Author​ and ​sitecore\Designer roles. I made sure that my authors had the necessary read, write, delete etc permission for the content scope that they were working in.

Datasource Item Locking Behavior

Author A locks an the item with presentation that consists of a component with a datasource item. The item is locked but the datasource item is not locked.

Author A makes inline edits to the component's datasource item's content, and then clicks the save button. After saving the item, the datasource item is now locked.

Author B locks an item that has a component with the same datasource item that has been locked by Author A.

Author B cannot make inline edits to the component with the locked datasource item.

Author B can make inline edits to all other areas of the item that aren't linked to locked datasource items.

Two important things to note from above:

  1. Author's cannot make changes to a component's datasource item when another author has locked the datasource item. One would expect this behavior.
  2. The datasource item only gets locked by the author when the author has made changes to the datasource item and clicks the save button. Making changes to other items on the page and saving will not lock the datasource item.


So far, things work pretty much the way one would expect. The only oddity is that the datasource item only gets locked on save. This is something that we can live with though.

The problem that I identified from the abovementioned scenario was that when Author A had finished making edits and unlocked the item, the datasource item didn't get unlocked in with the item. It stayed locked!

Workaround - Automatic Unlocking

One would expect both items and datasource items in workflow to be unlocked when an author has clicked the unlock button after making their content changes.

As Kamruz pointed out, one way to deal with this is to have the automatic unlocking setting enabled. The setting can be found in the Sitecore.config file:

 <setting name="AutomaticUnlockOnSaved" value="false" />  
When the value of AutomaticUnLockOnSaved is set to true, then every item is automatically unlocked after saving.

Having this enabled would provide relief from the unexpected behavior that is there by default.

Monday, February 15, 2016

Sitecore xDB Cloud Edition: Using the REST API

As I mentioned in a previous post, one of the nice things about using xDB Cloud Edition is that once your licensing is in place, getting up and running is very easy.

It's important to note that you don't have direct access to the various collections. So, you can't connect using a tool like Robomongo or MongoVUE to get information about your instance. In the past, getting consumption information about your cloud instance would require you opening up a ticket with support.

All this has changed with the introduction of the REST API for the xDB Cloud service. To find more information about what the API has to offer, I recommend that you read through the REST API reference for the xDB Cloud service.

In this post, I will show you how to use the API with one of my favorite browser plugins, Postman, so that you can get useful information and manage various processes in your Cloud Instance.

Nexus Authentication Token

The first order of business is to use the SSO Encode Sitecore License endpoint ( to obtain a Nexus Authentication token.

In order to do this, you need to generate a POST request to the endpoint with your Sitecore license file in the body of the request.

After performing the post, you will see your Nexus token in the response:

Check xDB consumption

Once you have your Nexus token, hitting the other endpoints is a walk in the park.  All you need to do is pass over the token value in a custom header called "X-ScS-Nexus-Auth" when making the request.

One of the endpoints that you will be accessing regularly is the consumption one. This gives you very useful information such as instance size, number of contacts and interactions.

For this endpoint, you need to pass over the following parameters along with the token:
  • licenseId – your Sitecore license ID (1 below)
  • deploymentId – the unique identification of the deployment (2 below)
  • year – the consumption year (3 below)
  • month – the consumption month (3 below)

4 below is my generated Nexus token called "X-ScS-Nexus-Auth" that I have added to the HTTP header.

So for example, to get consumption information for October 2015, my GET request looks like this:

You will see that there is small bug in my particular instance, where it is returning "0GB" for size. At the time of writing this post, the Cloud Team was actively working to get this resolved.

If you want to use this data to create a fancy report, what you can do is convert the JSON data into CSV format using one of the free conversion sites like

Using this site, I was able to get the data into Excel and create some cool looking graphs in a few clicks:

Other xDB Endpoints

Other endpoints that are available to you include:

Get Firewall settings{licenseId}/{deploymentId}

Get history processing status{licenseId}/{deploymentId}

Get xDB collection verification dataset{licenseId}/{deploymentId}

Get xDB set status{licenseId}/{deploymentId}

List xDB sets{licenseId}

Trigger history processing{licenseId}/{deploymentId}

The Trigger history processing endpoint above is another one to note. This gives you the ability to trigger a rebuild of your cloud reporting database. Note that the HTTP method is a PUT for this.

Final Thoughts

With this API in place that gives us a good level of control of the xDB Cloud, we can't help but get even more excited about the additional self service APIs and the xConnect API, that will be released with 8.2 later this year.