There are 4 sets of Contact APIs in Sitecore xDB:
- ContactRepository
- ContactManager
- SharedSessionStateManager
- Tracker.Current.Contact
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.
Why replace the default container?
So you already have a dependency injection container coming with Sitecore. …
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.
Solution
First, I am going to show how you can fix this issue.
1. Add the linked stored procedure to your Reporting database(s).
(corresponding connection strings are reporting and reporting.secondary)
Add_FormSummary Stored Procedure
2. Add the following configuration patch to all processing servers.
3. Restart processing servers.
You don’t need to rebuild the reporting DB after this fix. …
About
