Sitecore 7.5 und xDB aus technischer Sicht

Eine der interessantesten Veränderungen, die Sitecore mit der Ankündigung der Version 7.5 kommunizierte, ist die neue Struktur der Datenbanken für die Informationsspeicherung. Im folgenden Blogpost werden wir einige Details der neuen Datenbankarchitektur etwas genauer betrachten.

Änderungen in der Datenbankarchitektur

Die generierte Datenmenge in der bisherigen Digital Marketing Suite (DMS) war für MSSQL schlichtweg zu gross und die Analytics-Datenbank lief nach einer gewissen Zeitspanne in unabgenehmer Regelmässigkeit voll. Um diesen Missstand zu beseitigen wird nun neben der MSSQL Datenbank eine weitere NoSQL Datenbank (MongoDB) eingeführt. Diese erlaubt das Speichern der Daten als nicht-relationale Objekte. Damit sollte sich das Handling- Problem bei sehr umfangreichen Datenvolumen nun erübrigen und selbst Datenmengen im Tera- oder sogar Petabyte-Bereich, zumindest nach Aussage von Sitecore, problemlos verwaltet werden können. Auch der Zugriff auf die Daten, welche nun als strukturierte Objekte in der Datenbank vorliegen und nicht mehr über komplexe Queries aus mehreren Tabellen zusammengesucht werden müssen, sollte mit diesem Ansatz einfacher und performanter möglich sein. Zudem öffnet sich mit der Einführung der Mongo DB auch allmählich die Türe zu Big Data.
MongoDB verfügt über eine OpenSource-Lizenz und ist für eine kostengünstige horizontale Skalierung ausgelegt. Das heisst, dass anstatt eines einzelnen, teuer mit Hardware aufgepumpten Datenbank-Servers (vertikale Skalierung), viele kleine parallel laufende NoSQL Shards die Anfragen bedienen und Daten ausliefern können. Über einen Session Provider wird sichergestellt, dass die auf physisch unabhängigen NoSQL-Servern abgelegten Besucherdaten später eindeutig einem Profil zugeordnet werden können.

Datensammlung

Alle besucherrelevanten Daten werden als Object in der NoSQL Datenbank gesammelt (Collection Database). Über einen Verarbeitungsmechanismus werden die Daten der Besucherprofile dann aggregiert und in eine relationale Reporting Datenbank übertragen. Aus der Reporting-Datenbank werden letztendlich die Reports, Dashboard-Informationen und Profilzusammenfassungen aufbereitet.
Für den Zugriff auf die verarbeiteten Daten sowie den detaillierten Rohdaten hat Sitecore eine entsprechende Zugriffs-API entwickelt. Mit dieser API können sehr performante Auswertungen direkt aus dem CMS zur Verfügung gestellt werden – für noch detailliertere Auswertungen auf Ebene einzelner Events kann direkt über die gleiche API auf die Collection-Datenbank zugegriffen werden. Eine Schnittstelle für alle Anwendungsfälle. Der Datenfluss wird mit den folgenden beiden Abbildungen visualisiert.

Collection Database

Reporting Dataflow

Cloud Ansatz

Sitecore plant, die Experience Datenbank auch als Cloud Service mit einem bedarfsangepassten Preismodell anzubieten. Gehostet werden sie von Microsoft Azure und bieten dadurch eine kostensparende Alternative für kleine Unternehmen, die grössere Investitionen in Anschaffung oder Unterhalt einer MongoDB Infrastruktur vermeiden wollen.

Experience Platform Architecture

Änderungen des Visitortrackings

Der alte Ansatz der DMS, jeden Besucher als einzelnen Visit mithilfe eines Cookies zu identifizieren und zu tracken, verfiel mit dem Auftauchen von mobilen Geräten. Nun war es nicht mehr möglich den User über die verschiedenen Geräte eindeutig identifizieren zu können. Dank der neuen Collection Database ist es in Sitecore 7.5 nun möglich, einzelne Visits im Nachhinein zu identifizieren und unter einem eindeutigen Profil zusammengefasst auszugeben. In Sitecore 7.5 heissen Visits neu Interaction und werden über API calls zu einem Contact zusammengemergt.

Visitor Tracking
Für das Tracking wurde neu das Interface ITracker implementiert, wodurch sich der Zugriff auf die Daten folgendermassen ändert: von Sitecore.Analytics.Tracker zu Sitecore.Analytics.Tracker.Current.
Um einen User eindeutig identifizieren zu können, bieten sich Login Informationen oder Formulardaten wie Email Adresse an. Im Code sieht das folgendermassen aus:

PUBLIC CLASS IDENTIFYANALYTICSCONTACT : IORDERPIPELINEPROCESSOR
{
PUBLIC VOID PROCESS(ORDERPIPELINEARGS ARGS)
{
VAR TRACKER = SITECORE.ANALYTICS.TRACKER.CURRENT;
VAR IDENTIFIERS = TRACKER.CONTACT.IDENTIFIERS;
IF (IDENTIFIERS.IDENTIFICATIONLEVEL == SITECORE.ANALYTICS.MODEL.CONTACTIDENTIFICATIONLEVEL.KNOWN)
{
RETURN;
}
TRACKER.SESSION.IDENTIFY(ARGS.CART.CUSTOMERINFO.EMAIL);
}
}

oder über das Login:

PUBLIC CLASS CUSTOMERMANAGER : SITECORE.ECOMMERCE.USERS.CUSTOMERMANAGER WHERE T : CUSTOMERINFO
{
PUBLIC OVERRIDE BOOL LOGINCUSTOMER(STRING NICKNAME, STRING PASSWORD)
{
VAR SUCCESS = BASE.LOGINCUSTOMER(NICKNAME, PASSWORD);
IF (SUCCESS)
{
VAR USERNAME = SITECORE.CONTEXT.DOMAIN.GETFULLNAME(NICKNAME);
VAR USER = USER.FROMNAME(USERNAME, TRUE);
SITECORE.ANALYTICS.TRACKER.CURRENT.SESSION.IDENTIFY(USER.PROFILE.EMAIL);
}
RETURN SUCCESS;
}
}

Über das Contact.Attachements dictionary können unlimitiert weitere Daten dem Kontakt hinzugefügt werden:

VAR TRACKER = SITECORE.ANALYTICS.TRACKER.CURRENT;
VAR CART = SITECORE.ECOMMERCE.CONTEXT.ENTITY.GETINSTANCE();
TRACKER.CONTACT.ATTACHMENTS["AC-CART"] = CART;

Der grosse Vorteil von Sitecore 7.5 xDB ist das automatische Merging der angefallenen Besucherdaten eines identifizierten Kontaktes. Für getriggerte Events wie Goals oder Kampagnen ist dies keine grosse Sache, aber was passiert, wenn für verschiedene Sessions des Kontaktes unterschiedliche Daten abgelegt wurden? Um diesen Problemen individuell und nach dem Business Approach des Kunden begegnen zu können, existiert eine eigene Merge-Pipline, die nach den entsprechenden Bedürfnissen customized werden kann:

<mergeContacts>
<processor type=“Sitecore.Analytics.Pipelines.MergeContacts.MergeTags, Sitecore.Analytics“/>
<processor type=“Sitecore.Analytics.Pipelines.MergeContacts.MergeContactCounters, Sitecore.Analytics“/>
<processor type=“Sitecore.Analytics.Automation.Pipelines.MergeContacts.MergeAutomationStates,Sitecore.Analytics.Automation“>
<SessionContextManager ref=“tracking/sessionContextManager“></SessionContextManager>
</processor>
<processor type=“Sitecore.Analytics.Pipelines.MergeContacts.MergeContactAttributes, Sitecore.Analytics“/>
<processor type=“Sitecore.Analytics.Pipelines.MergeContacts.MergeContactFacets, Sitecore.Analytics“/>
</mergeContacts>

In der folgenden Grafik wird der Lebenszyklus der einzelnen Sessions nochmals aufgezeigt. Hier wird erkannt, dass der Shared Session State und somit der Kontakt bis zum Ablauf der letzten Interaction (Visit) gültig ist. Erst nach Ablauf des „session_end“-Events von Asp.Net werden die gesammelten Informationen für die Collection Database freigegeben und können die aggregierten/kalkulierten Statistiken der Reporting-Datenbank beeinflussen. Somit gibt es keine „Verfälschung“ von aktiven Benutzern, welche beispielsweise ihre Engagement-Prozesse noch nicht abgeschlossen haben, da sie sich noch aktuell auf der Seite befinden.

Session Lifecycle

Zusatzinfos:

Sitecore bietet ein CommandLine Tool für den Export der bestehenden DMS Daten.

Slides zur Architektur: http://www.slideee.com/slide/sitecore-xdb-oh-no-sql-where-is-the-data-at

Download MongoDB für Windows: http://www.mongodb.org/downloads

Beispiel eines NoSQL Datensatz:

{
"title" : "MongoDB Example",
"autor" : "Roger Schlumpsf"
"date" : "07/15/2014",
"content" : "Many words go here."
"pageViews" : 100,
"comments" : [
{
"name" : "Andre 3000",
"comment" : "Thanks for this post. It was mildly helpful.",
},
{
"name" : "Big Boi",
"comment" : "Our reunion tour isn't coming to Calgary"
}
],
"tags" : ["mongo", "nosql", "xdb", "sitecore"]
}

2 Gedanken zu “Sitecore 7.5 und xDB aus technischer Sicht

  1. Pingback: Die Sitecore Experience Platform – Der Kunde im Fokus – Sitecore

  2. Pingback: Sitecore 7.5 – Die Module ziehen nach – Sitecore

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

*

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>