One Month with Sitecore 7.5 Part 3: xDB Setup, Contact Identification and Shared Sessions
Posted 06/05/2014 by techphoria414
Sitecore has provided an early release of Sitecore 7.5 to MVPs, and I’ve fortunately had a little time to play with it and do some preliminary Active Commerce integration. This blog series reports what I’ve learned about Sitecore 7.5 and how you might utilize or implement it. In this article, I’ll explore the setup process to start developing with xDB, and how you can utilize the new Contact and Shared Session functionality.
Lots of Databases!
Get ready for your ConnectionStrings.config to blow up. Fortunately this doesn’t add a lot to your setup/install process, because through the magic of MongoDB, the additional MongoDB databases get created automatically for you when they are first accessed.
You do of course need to install MongoDB, but this is pretty straight forward. Don’t be scared! MongoDB sets up easily in Windows, and can even be setup as a Windows Service. David Morrison of Sitecore has created a Powershell script to do this for you. Sitecore MVP Benjamin Vangansewinkel has also written a great article on setting up MongoDB.
Don’t Forget the Basics
My initial attempts at getting analytics data flowing from Active Commerce were stymied by a couple rookie mistakes:
- Overwriting Sitecore’s Global.asax. Apparently using a Global.asax that inherits from Sitecore.Web.Application has been a requirement for some time now -- but not to the point that I’d noticed any issues with our Active Commerce demo site up to this point. Because analytics are written on Session_End now, this is a big requirement for Sitecore 7.5.
- Not having an sc:VisitorIdentification tag in my main layout. Still a must-have for Sitecore analytics!
In addition, you’ll want to configure your session state provider. InProc sessions will work, but keep in mind that you can potentially lose data if there is an application pool recycle in the middle of a user session. Sitecore provides two new options -- a MongoDB session provider, and an “enhanced” SQL Server session provider. As the builtin ASP.NET SQL session state provider does not support Session_End, it is no longer an option for use with Sitecore. Keep in mind that all your session objects must now be [Serializable] to utilize these database session state providers.
Here, I’ve configured MongoDB session state. Note that I’ve turned my session expiration way down to help with testing and development. Alistair Deneys also pointed out on the MVP forum that you can utilize Session.Abandon() to end the session and flush data to the xDB. I forsee a /sitecore/admin utility page or maybe even a browser button/plugin to make this easily accessible. It is definitely one of the bigger headaches of working with the new analytics data flow.
As always, documentation is your friend. For complete xDB setup instructions, you will want to review the new xDB Configuration Guide
which will ship with 7.5.
Getting it Working -- Analytics API Changes
As you might expect, there have been a number of changes to Sitecore.Analytics APIs. As this is an early release, these are still subject to change, but here are a few before/after examples from changes I had to make to Active Commerce in order to get a working build against Sitecore 7.5.
As you can see, the primary access point for analytics APIs has changed from Sitecore.Analytics.Tracker to Sitecore.Analytics.Tracker.Current. This appears to allow injection of ITracker implementations, and also dynamic switching of the current ITracker. Not sure yet why you would switch trackers….
Identifying the Contact and Shared Session
The problem with this new “contact” concept is that whole HTTP protocol thing. It’s anonymous and stateless, you know. But we have ways of getting users to self-identify, whether it be a login, placing an order, or filling out a form with their email address. Once a user has done this, Sitecore 7.5 provides an API call to identify the user. Once you make this API call, Sitecore will merge the visit data with any existing data about the contact. For this proof of concept, I’m using the customer’s email address to identify them when they log in, or when they place an order in Active Commerce.
This is powerful not just for analytics data, but also for utilizing the new Shared Session concept. The Contact.Attachments dictionary allows us to store arbitrary data with the contact. Since the contact is in shared session, this means that if an identified contact is accessing the site from multiple devices simultaneously, we can access that “session” on both devices. This is pretty powerful stuff. You can see below that in Firefox and Chrome, I’m sharing the same Active Commerce shopping cart using the 7.5 Shared Session.
Part of the magic that happens when you Identify a contact is that Sitecore will merge data collected for the current “anonymous” contact, and the existing “known” contact, if it already exists. For additive data such as visited pages and triggered events, this isn’t a problem. But what if we have personal information collected for both contacts, or a shopping cart for both contacts? Sitecore provides some builtin logic for this in the mergeContacts pipeline, but I forsee this being a major area of testing and customization, depending on the particular implementation's business rules about what data should win out, and when. Should I load a saved shopping cart just because a user filled out a “Contact Us” form with their e-mail address? What if my mom uses my laptop and logs in to her account? Should her traffic and activities be attributed to my contact? Lots of questions here and likely some best practices to be developed.
Just Scratching the Surface (of the buzzwords)
That’s it for Part 3 of this series on Sitecore 7.5. In part 4, we will explore xDB deployment options on premise, as well as using Sitecore’s cloud hosting option for all your big big data.
Cloud?? Big Data??? WHAT??!!!