Einrichtung des Sitecore Analytics Dashboard Teil 2: Konfiguration mit Hindernissen

Willkommen zum zweiten Teil meines Selbstversuchs zur Nutzung des Sitecore Analytics Dashboards. Zur Erinnerung: Es geht darum, auf meinem Launchpad das Sitecore Analytics Widget mit Leben zu füllen. Es wird zwar dargestellt, enthält aber keine Daten oder Graphen und ist völlig blank.

Auf meinem Weg, das Problem zu lösen, habe ich mich im ersten Teil dieses Blogs zunächst mit dem Kern der Analytics-Welt in Sitecore beschäftigt, der Experience Database (kurz xDB). Dabei handelt es sich um die NoSQL-Datenbank MongoDB. Feststellen konnte ich in diesem Zusammenhang nur, dass offensichtlich keine Analytics-Daten gespeichert werden. Auch das Experience Analytics Dashboard zeigt mir keine Daten an. Soweit der Stand der Dinge.

Die nächsten Schritte

Wie üblich führt der Weg zur Lösung eines Problems zunächst über die Google Suche. Ich versuche es z. B. mit der folgenden Suchanfrage: „sitecore experience analytics not working“. Das Ergebnis ist ernüchternd und es hilft mir nicht weiter.

Abbildung 1: Google Ergebnis

Wenigstens stelle ich fest, dass ich mit meinem Problem nicht alleine bin. Ein Hoch auf das Internet und all die Hilflosen und Verzweifelten, die wie ich keine Lust mehr haben, selbst nach der Ursache für einen Fehler zu suchen. Aber im Ernst: Im Falle eines Problems wäre natürlich die erste Anlaufstelle der hervorragende Sitecore Support. Da ich mich aber auf meiner Sitecore-Spielwiese befinde, sehe ich von solch schweren Geschützen erst einmal ab und versuche die Lösung selbst zu finden. Getreu dem Ratschlag, den ich schon am Ende des ersten Teils dieses Beitrags von meinem Sitecore-System erhalten habe:

„Contact YOUR system administrator“

Datenbankzugriff

Noch bevor ich die Google-Ergebnisse in Anspruch nehme oder den Sitecore Support beziehungsweise den Administrator bemühe, checke ich erst einmal den Zugriff auf die Datenbank durch das Sitecore-System. Die Konfiguration hierfür liegt im Verzeichnis „App_Config\Include“ und heißt „Sitecore.Analytics.MongoDb.config“.

Der Inhalt sieht bei mir so aus:

Abbildung 2: Sitecore.Analytics.MongoDb.config

Connection String

In der Konfiguration sieht man, dass für den Wert des Parameters „connectionString“ ein Platzhalter eingesetzt ist: „$(0)“. Da dies nur die Konfiguration für den MongoDB-Datenbanktreiber ist, wird dieser wohl beim Herstellen einer Verbindung zu einem spezifischen Schema mit einem entsprechenden Wert befüllt. Aber woher kommt dieser? Vielleicht aus der Konfigurationsdatei „ConnectionStrings.config“? Dort befinden sich jedenfalls entsprechende Verbindungsdaten:

Abbildung 3: Robomongo Verbindungsdaten 

Robomongo

Diese Verbindungszeichenfolgen nun einzeln auszuprobieren, wäre zu umständlich. Benutzernamen und Passwörter werden nicht verwendet und mit meinem MongoDB Client „Robomongo“ klappt die Verbindung auch genauso:

Abbildung 4: Robomongo Verbindungsdialog

MongoDB Windows-Dienst

Die Verbindung scheint also zu funktionieren. Ein Check gilt noch dem Windows-Dienst: Läuft dieser? Wie ist der Starttyp?

Abbildung 5: MongoDb Dienst Konfiguration: Alles gut!

MongoDB Log.txt

Nachdem ich festgestellt habe, dass die Dienstkonfiguration in Ordnung ist, fällt mir noch der „logpath“ Parameter auf. Dieser wird der „mongodb.exe“ beim Start mitgegeben. Jetzt gilt es, noch einmal einen Blick in das Logfile zu werfen, ob sich dort irgendetwas Ungewöhnliches finden lässt. Aber im Gegenteil: Es werden Verbindungen hergestellt und Abfragen ausgeführt. Das Lesen der Dateien scheint also zu funktionieren:

Abbildung 6: MongoDb log.txt

Back to Google

Auf der Grundlage des bisher Erreichten wende ich mich wieder an Google: Wie schaffe ich es, dass auf meinem Sitecore Analytics Wiget Daten dargestellt werden? Um einen passenden Beitrag zu finden, muss man ein wenig suchen. In Community-Foren wird häufig aneinander vorbeigeredet. Es werden z. B. unnötige Serverkonfigurationen angefordert und wohlgemeinte Lösungen zu ganz anderen Problemen beigesteuert. Nach stundenlangem Lesen ist man genauso ratlos wie vorher. Irgendwann habe ich dann doch eine Punktlandung erzielt: Einer stellt eine Frage und ein anderer gibt eine fundierte Antwort, die der Fragesteller als Lösung für sein Problem markiert. Beispiel: Stackoverflow. Allerdings läuft man bei dieser Vorgehensweise Gefahr, keine Ahnung zu haben, welchen Code man in seine Anwendung kopiert hat. Für welchen Lösungsweg man sich schlussendlich entscheidet, hängt also unmittelbar mit der zur Verfügung stehenden Zeit und der nervlichen Belastbarkeit bzw. Risikobereitschaft zusammen.

Sitecore Knowledge Base

Die Schritt-für-Schritt Ratschläge zur Fehlerbeseitigung, die hier erwähnt werden, sind eher trivial und oberflächlich. Sie decken nur sehr grundlegende Fehlerursachen ab, wie die Erreichbarkeit der Datenbank (funktioniert bei mir), die Überprüfung der Firewall-Einstellungen (ist bei mir ausgeschaltet) oder die Überprüfung der ASP-Session-Einstellungen. https://kb.sitecore.net/articles/977445

Sitecore Community

Unter https://community.sitecore.net/developers/f/9/p/1028/3528#3528 finden sich die üblichen absurden Vorschläge zur Problemlösung. Und ich weigere mich einfach zu glauben, dass ich mich bei einem CMS-System dieser Preisklasse um derartige Dinge selbst kümmern muss, um grundlegende Funktionen zum Laufen zu bringen. Dazu gehört auch die Aufforderung des Nutzers Sergey, einfach mal die Konfiguration zu posten: 

„Are you getting any errors in the log files? Can you share your connectionstrings in connectionstring.config file“

Was zur Hölle will Sergey mit diesen Verbindungsdaten anfangen? Ausprobieren ob sie bei ihm funktionieren? Ferndiagnose per transzendentale Remoteverbindung? Der als Antwort markierte Beitrag ist eine recht abstruse Anleitung. Aber zumindest Teile davon sind brauchbar: 

Sergey"

Danke, Sergey! Immerhin: Das mit den Segmenten erscheint logisch, vor allem, wenn sie fehlen. Also überprüfe ich das per SQL Management Studio. Und wirklich, die Tabelle ist leer.

In der Sitecore Dokumentation erfahre ich, dass das normal ist und z.B. nach der Installation die Segmente erst noch deployed werden müssen. Kurz bin ich versucht, ein Sitecore Upgrade durchzuführen, um dem Ganzen zu entkommen. Doch die flüchtige Durchsicht der Sitecore Upgrade Anleitung erinnert mich wieder daran, dass das kein wirklich gangbarer Weg ist. Zumindest nicht in diesem Zusammenhang. Ein nützlicher Hinweis ist noch der Verweis auf diese Administrations-Seite: 
sitecore/admin/redeploymarketingdata.aspx 

Abbildung 7: Segmente neu installieren

Ich drücke also auf den Knopf und erhalte Rückmeldung über die installierten Segmente. Ein erneuter Blick in die entsprechende SQL-Tabelle bezeugt: Es hat funktioniert und sie ist nun zumindest nicht mehr leer. Das vom Launchpad erreichbare Control Panel bietet eine Übersicht über den Analytics-Status: 

Das sieht gut aus. Und auch ein Blick in mein MongoDB zeigt, dass es aktuelle Daten gibt:

Voller Vorfreude begebe ich mich also wieder zum Analytics Dashboard. Dort muss ich aber zu meiner Ernüchterung feststellen, dass es keine Echtzeit-Ansicht gibt und frühestens die Daten von gestern angezeigt werden. So wie bei Google Analytics prinzipiell zwar auch, allerdings hat man dort die Möglichkeit, die Besucher der Website in Echtzeit zu „verfolgen“. Schade. Immerhin erhalte ich keine Fehlermeldungen mehr (siehe Abbildung zwei). Das stimmt mich trotz allem milde optimistisch.

Zielgerade

Auf Umwegen sieht man zwar mehr von der Landschaft (und warum sollte auch immer alles auf Anhieb funktionieren) aber jetzt möchte ich doch zurück zu meiner eigentlichen Aufgabe und Analytics-Daten auf meinem Launchpad sehen. Ein wenig Recherche fördert aber Ernüchterndes zutage. Wir erinnern uns – die Beschreibung in dem Platzhalter auf dem Launchpad lautet: „Sitecore XP 8.0 enables you to configure this dashboard to show the most important analytics graphs every time you come back to the Launchpad. Use this space to keep on top of the metrics most important to your organization. “

Pustekuchen. Konfigurieren kann man gar nichts. Nicht einmal mit den eigenen CMS-Mitteln von Sitecore, Content Editor oder Experience Editor, lässt sich der Platzhalter entsprechend füllen. Man braucht „Visual Studio“ und, da es sich beim Launchpad um eine SPEAK-Oberfläche handelt, auch noch „Sitecore Rocks“. Wer sich also mit dem Thema weiter beschäftigen möchte, dem sei die Google-Suche nach „sitecore launchpad analytics“ nahegelegt.

Fazit

Es hilft, die Bedienungsanleitung zu lesen. Damit hätte sich das grundsätzliche Problem mit der Speicherung der Analytics Daten gar nicht erst ergeben. Soweit mein Fehler. ABER: Das Versprechen man könne mal eben ein Analytics Dashboard für sein Launchpad konfigurieren, kann Sitecore nicht einlösen. Tatsächlich ist der Weg dorthin nur in Zusammenarbeit mit Entwicklern gangbar möglich. Vor dem Hintergrund aber, dass es gerade die Leute aus der Marketingabteilung sind, die solche Daten interessieren und Sitecore sich diesem Thema explizit verschrieben hat, ist das ein klares Manko.

Allgemein beim Thema Analytics fehlt mir die Ansicht in Echtzeit und Möglichkeiten, die Daten auch innerhalb der Anwendung zu sehen. Man vergleiche hier einmal den Vorschaumodus des Google Tag-Managers.