SUGCON Europe 2019 – London is Calling

Zurück aus der Hauptstadt Englands möchten wir gerne unsere Eindrücke der Sitecore Usergroup Conference Europe mit euch teilen. Zusammengefasst kann man sagen: es waren zwei sehr intensive Tage. Sehr viel Input, sowohl neues Wissen als auch einfach neue Denkanstöße, interessante Gespräche, wenig Schlaf, viel unterwegs…

Die Organisation und die Location waren super. Wenn man ganz ostwestfälisch was zu meckern finden möchte, dann dass der Platz zwischen den Räumen, welcher auch fürs Catering genutzt wurde, vielleicht etwas beengt war. Aber dadurch eben auch kommunikativ 😉 Seht selbst:

Zu den Sessions: Es gab bis zu 5 (!) Sessions parallel. Wir haben uns bestmöglich verteilt und Team-intern live und ausführlich via Slack berichtet:

Das alles hier im Blog mal eben zusammen zu fassen, würde den Rahmen sprengen. Daher haben wir uns überlegt, jeder von uns schreibt mal etwas zu seinem persönlichen Highlight der SUGCON. Wer an Details interessiert ist, kann die gesammelten Materialien der SUGCON auf der offiziellen Webseite einsehen.

Lennart: The Wheels on the Rebus – Go Queue, Queue, Queue

Mich persönlich hat der Vortrag zum Sitecore Message Bus von Pete Navarra besonders beeindruckt. Da ich den Sitecore Message Bus bisher so noch nicht kannte.

Auf spielerische Art und Weise hat Pete zunächst die Vorteile einer Message Queue gegenüber einer “Direct Connection” verdeutlicht. Dazu wurde das Publikum in vier Gruppen mit je einem Freiwilligen eingeteilt. Aufgabe für die Freiwilligen war es, alle Mitglieder der eigenen Gruppe mit einem Ball zu versorgen.

Dabei durfte Gruppe 1 nur eine “Direct Connection” zum Verteilen der Bälle verwenden (Der Freiwillige aus Gruppe 1 musste jedem Einzelnen seinen Ball bringen.). Die übrigen Gruppen haben die Bälle über eine Message Queue (Durchreichen der Bälle nach FIFO-Prinzip durch die Gruppe selber) verteilt. Die Freiwilligen aus Gruppe 2-4 haben dabei als Service Bus agiert und Behältnisse in unterschiedlichen Größen nutzen dürfen um die Bälle, die drei weitere Freiwillige (Producer) vorsortiert hatten, an die eigene Message Queue weiterzugeben.

Wie zu erwarten war, waren die Gruppen 2-4 wesentlich eher fertig als Gruppe 1.

Diese Demonstration hat sehr eindrücklich gezeigt, wie viel einfacher man Message Queues im Vergleich zu “Direct Connections” skalieren kann.

Der Clou: Jeder durfte seinen Ball behalten. 😉

Der Sitecore Message Bus

Danach wurde es wieder technischer und Pete hat den Sitecore Message Bus vorgestellt, welcher seit Sitecore 9.0.1 fester Bestandteil der Platform ist und auf Rebus.NET basiert.

Das relevanteste Beispiel für die Nutzung des Message Bus ist EXM. Während EXM mit Sitecore 8.x noch die direkte Verbindung von Content Delivery und Content Management Server benötigt, wird seit Sitecore 9.0.1 stattdessen der Message Bus für EXM genutzt. Das bedeutet, dass man sich viele Fragen wie “Was ist wenn es mehrere CD’s gibt?” oder “Was ist wenn es mehrere CM’s gibt?” gar nicht mehr stellen muss, denn mit der Nutzung des Message Bus sind Content Delivery und Content Management Server bzgl. EXM nicht mehr voneinander abhängig.

Der Sitecore Message Bus kann auch für eigene Implementierungen genutzt werden, wenn zum Beispiel Ereignisse, die auf dem Content Delivery Server eingehen, auf dem Content Management Server verarbeitet werden sollen. Dazu hat Pete einen Email Bounce Handler implementiert, der auf Bounce Messages reagiert, die auf dem CD eintreffen und dann die entsprechende EXM Pipeline auf dem CM anstößt.

Alles in allem lässt sich sagen, dass die Sitecore Message Queue ein sehr spannendes Konstrukt ist, das mitunter sehr hilfreich sein kann. Außerdem ist es im Hinblick auf die immer größer werdende Microservice Architektur (Sitecore Host) von Sitecore quasi ein logischer Schritt, um einen neuen Weg zu schaffen, wie die Microservices miteinander kommunizieren können.

Weitere Infos und die Codebeispiele zum Vortrag hat Pete Navarra in seinem Blog veröffentlicht.

Marcel: Advanced Publishing Service & New Features in V5

Während der Arbeit mit Sitecore kommt man nicht daran vorbei, auch mal ein paar Items zu veröffentlichen. In der Regel verwendet man dafür den bekannten Publish von Sitecore, was aber nicht die beste Lösung ist.

Wer große Mengen an Items regelmäßig publizieren muss, sollte sich daher einmal den Publishing Service ansehen. Dieser wartet mit einigen Features auf, die man beim regulären Publish vermisst, wie zum Beispiel den Fortschritt des Publish-Prozesses sehen zu können.

Im Vortrag konnten wir einige Eindrücke über die Vorteile des Einsatzes sammeln. Zunächst und wahrscheinlich der wichtigste Punkt des Vortrags sind die Benefits bei der Performance. Diese Vorteile erhält man bereits seit der dritten Version des Publishing Service.

Außerdem haben wir einen detaillierten Einblick in den neuen Incremental Publish Algorithmus bekommen, einiges über Skalierung und in dem Bezug auch etwas über die Zukunft des Publishing Service mit Sitecore Host erfahren.

Auch wenn der Geschwindigkeitsunterschied allein bereits ziemlich beeindruckend ist, sind es die neuen Features, wie Publishing Sets und die Integration mit Host, die mein Interesse am meisten geweckt haben.

Tim-Patrick: Extending & Implementing Sitecore Cloud Architectures

Fährt man Sitecore produktiv auf Azure PaaS in einer ausgewachsenen XP-Topologie, hat man es mit einer beträchtlichen Anzahl von Diensten zu tun. Darunter diverse Azure App Services, die summiert so richtig ins Geld gehen können.

Müssen sie aber nicht, wie Rob Habraken in seinem Vortrag zeigte. Zum Vergleich: Zahlt man für einen App Service im Premium Plan P3v2 (4 Cores /  14 GB RAM) ganze 492,48 € monatlich, so sind es im Basic Plan B1 (1 Core / 1,75 GB RAM) lediglich 46,17 € – das entspricht grob Faktor 10. Durch das automatisierte Herunterskalieren zu Nebenzeiten sind je nach Anwendungsfall erhebliche Einsparungen möglich. Das liegt zwar auf der Hand, doch erst durch den Komfort einer  Automatisierung etwa mittels Azure Pipelines (Teil der geradezu omnipräsenten Azure DevOps Tools) oder Azure Costs Saver wird der Ansatz tauglich für den produktiven Einsatz. Daumen hoch dafür :)!

Microservice-basierte Sitecore-Architektur

Das zweite Schwerpunkt-Thema des Vortrags: „Going serverless“. Spätestens seit der Einführung von xConnect ist der Umbau von einem Software-Monolithen hin zu einer Microservice-basierten Architektur bei Sitecore unübersehbar. Während der Wechsel von virtuellen Maschinen (IaaS) auf PaaS die Art und Weise verändert hat, wie Software deployed wird, verändert die Umstellung auf serverlose Architekturen gar die Art und Weise, wie wir die Software entwickeln.

Inspirierend waren hier die praktischen Beispiele für eine Erweiterung von Sitecore auf Basis von der serverlosen Azure Functions und Azure Logic Apps. Letzte lassen sich einsetzen, ohne eine einzige Zeile Code schreiben zu müssen – lediglich konfigurieren muss man sie. Die fiktive Anforderung „Setze einen Tweet bei Twitter ab, wenn ein Sitecore Item abgespeichert wird und das Wort <news> enthält“ lässt sich damit recht einfach umsetzen. Aber: „Don’t overdo serverless“ – denn die wachsende Komplexität der Gesamtarchitektur will auch beherrscht werden.

Tim: The Universal Tracker

Auf der diesjährigen SUGCON gab es wieder viele interessante Vorträge und Diskussionen, dabei stach für mich die Session “Offline tracking with the Sitecore Universal Tracker” von Kamruz Jaman besonders hervor.

Jeder SUGCON-Besucher erhielt im Vorfeld bei seiner Registrierung neben einem Namensschild auch eine Karte mit einem RFID-Chip und einem aufgedruckten Tiersymbol.

Beim Betreten des großen Plenarsaals ging man an den extra aufgestellten NFC-Geräten vorbei und konnte dann auf den Bildschirmen und Leinwänden live mitverfolgen, wie sich die Zahlen unterhalb der Tiersymbole mit jedem Session-Besucher erhöhten.

Zudem wurde das Experience Profile eines Contacts geöffnet, um zu zeigen, welche Session wann besucht wurde.

Wie funktioniert der Tracking-Service?

Wir sahen also eine wirklich gut gemachte Live-Demo des Universal Trackers, der mit Sitecore 9.1 released wurde. Der Universal Tracker ist ein skalierbarer Tracking-Service mit offener Web-API, der Benutzerinteraktionen in Echtzeit in Form von Collections sammeln kann. Er verarbeitet und speichert Nutzer-Interaktionen „live“, also in dem Moment, wenn sie passieren. Im Anschluss werden diese Daten via xConnect in xDB gespeichert.

Dadurch können fortlaufend Daten gepushed und gespeichert werden. Dabei handelt es sich um Sitecore Interactions, die wiederum mehrere Goals und Events enthalten können. Die Kommunikation erfolgt über eine REST API, anschließend wird eine Tracking-Interaction-ID zurückgeliefert. Die Session kann entweder programmatisch oder durch Timeout beendet werden.

Zwischen der Erstellung einer Interaction und dem späteren Speichern via xConnect stehen dem Entwickler zahlreiche Processing Pipelines (Pre-Filter, Enrichment und Post-Filter) zur Verfügung.

Die eigentliche Herausforderung sind nicht die Datenmengen, sondern die zahlreichen parallel zu verarbeitenden Interaktionen. Darum ist der Universal Tracker sehr gut skalierbar, z.B. durch Einsatz eines Azure IoT Hub.

Friederike: 2019 MVP Award Ceremony

Für mich ist die SUGCON die stärkste internationale Konferenz im Sitecore-Kosmos, weil sie von der Community für die Community gemacht und weniger Marketing-“lastig” ist. Daher haben mir viele Sessions gut gefallen. Nichtsdestotrotz ist die Verleihung des MVP Awards natürlich mein persönliches Highlight:

Von links: Christian Hahn (@Hahn1Christian ), Friederike Heinze (@ilovesitecore) und Stefan Graber (@stefangraber_sc )

Wir kommen bestimmt wieder und freuen uns schon auf die SUGCON 2020 🙂