- Part 1: Milwaukee Sitecore Developer's Meetup Presentation (video)
- Part 2: The Experience Profile and Experience Database
- Part 3: xDB Setup, Contact Identification and Shared Sessions
- Part 4: xDB Deployment, On Premise vs Cloud
- Part 5: Persisting Contact Data to xDB
- Part 6: Extending Report Data via Aggregation
With its flexible schema and scalable architecture, the xDB immediately becomes an attractive option in Sitecore 7.5 for storing all sorts of user-centric data, particularly anything you are interested in utilizing for reporting purposes. Developers who have worked with the .NET MongoDB Driver know how easy it is to persist any object data to the database. However, for good reason, your access to xDB is a bit more abstracted than this. You do, however, have three options for persisting contact data to the xDB.
I myself only implemented one of the options below in my search for a means to persist shopping cart data in a POC for Active Commerce. But I’ve provided an overview of all three options.
The submitContact Pipeline
We saw in Part 3 of this series how data can be associated with the current contact via the Contact.Attachments dictionary.
Though very useful, data in the Attachments collection is not persisted with the contact when the session is flushed. However, you could tap into the submitContact pipeline by creating your own SubmitContactProcessor, and persist the data to your own collection in MongoDB.
As for how you persist, and how you load that data later, you’re a bit on your own. There is no corresponding loadContact pipeline at this time, and your best option for persistence appears to be accessing MongoDB directly via Sitecore.Analytics.Data.DataAccess.MongoDb.MongoDbDriver. You could then potentially access that data via an extension method on your Contact. Not ideal, and I’m not sure whether this would work with xDB Cloud.
This did not seem to be the ideal option for me. I wanted something more straightforward which worked within the existing xDB data structures.
This structure on the contact seems to allow storing of simple name/value string pairs that are persisted and loaded with the contact data. This is a step forward, but for a shopping cart, I needed something that could handle a complex object.
Contact FacetsNot to be confused with search facets, contact facets allow you to define entirely new model classes that can be stored with the contact, and accessed via Contact.GetFacet<T>(string). Here we have an option which allows us to store complex data with the contact, without having to worry about persisting the data ourselves. Sitecore 7.5 includes a number of contact facets, which can be utilized to store additional information about the contact. This data appears to help fill out the Experience Profile report.
The facets are configured in a new /sitecore/model configuration element, which defines various data model interfaces and their implementations, and associates them to entities (a contact in this case) with a given name.
For example, to fill in a contact’s first/last name, we can use the Personal facet.
Implementing your own facet requires a few steps, but is not difficult. The steps below include my POC for persisting shopping cart data.
- Create an interface for your facet which inherits IFacet. Add your desired fields.
- Create an implementation which inherits Facet. Use base methods to “ensure,” “get,” and “set” member values.
- For composite object structures, create an IElement and Element following the same pattern.
- Register your element in the /sitecore/model/elements configuration.
- Register the facet in the /sitecore/model/entities/contact/facets configuration.
- Access the facet via Contact.GetFacet<T>(string).
After the contact’s session is flushed, you can very plainly see your new data persisted with the Contact. Nice!!
As you can see, facets are an easy and powerful means of persisting contact data to xDB.
That’s it for Part 5! In the last part of this series, we’ll look at another new extension point available in Sitecore 7.5, data aggregation.