There are 4 sets of Contact APIs in Sitecore xDB:
Each of them, apart from the ContactManager, has a clear purpose of working with a specific Contact storage. The ContactManager actually works with both the shared session and the Collection database via the underlying APIs, as you can see on the following diagram:
It’s relatively easy to update contact data via each of these API, provided that you know which one to use.
But what if you just want to update the contact, no matter where it’s currently located? Here’s a method I recently created that will help you:
And here’s how you can use it:
With the release of 8.2, out-of-the-box Sitecore now uses IServiceProvider — ASP.NET’s own dependency injection abstraction, as well as its default implementation. If you haven’t yet, go read Kam’s article “Dependency Injection in Sitecore 8.2” that describes how to use the built-in capabilities of the new Sitecore DI.
Since Sitecore has become DI-aware, its internals have undergone significant rewiring, allowing for a more seamless implementation swapping — not only for its internal components, but even for some parts of its infrastructure.
So you already have a dependency injection container coming with Sitecore. Why would you want to substitute it with something else? …
On Sitecore 8.1, when rebuilding the Reporting database, the following error occurs and halts the rebuild process:
Exception when storing an aggregation result into reporting database.
Item will be postponed and retried later.
Failed to insert or update rows in the [Fact_FormSummary] table.
Here’s an excerpt from our Sitecore log:
Note that this error may potentially occur in other conditions as well. Rebuilding the Reporting DB was just the context where we saw the error first.
First, I am going to show how you can fix this issue.
(corresponding connection strings are
You don’t need to rebuild the reporting DB after this fix. Once the processing servers have been restarted, they will proceed to successfully aggregate all form data. …