Sitecore Usergroup Deutschland-Treffen in Frankfurt vom 31.08.2017

Die Sitecore Usergroup Deutschland traf sich zum dritten Mal in diesem Jahr.  Diesmal am 31. August 2017 in Frankfurt am Main.
Das Treffen mit etwa 40 Teilnehmern fand in der Nähe der Frankfurt Messe, im Kino „Orfeos Erben“ statt. Ein Vorteil: Unglaublich bequeme Sitzmöglichkeiten :)

Sitecore Usergroup Deutschland Kino

Es gab reichlich gute und praxisnahe Vorträge:

Übersicht der Vorträge:

  1. Sitecore E-Commerce vom allg. bis zum technischen Deepdive
  2. Buses and Queues with Sitecore & Azure
  3. 100% Availabilty – Scale your System waterproof
  4. Diskussion Sitecore Entwicklung im Team
  5. Über die Sitegroup User Group Deutschland e.V.

Sitecore E-Commerce vom allg. bis zum technischen Deepdive

Vortrag von Christian Hahn (ecx.io), Blog: hachweb.wordpress.com. Christian stellte die Entwicklung mit dem Anfang 2017 eingeführten Sitecore Commerce 8.2 vor.

Sitecore Usergroup Deutschland Christian Hahn

Keyfeatures:

  • Technische Basis weitgehend .NET Core
  • xDb Integration inkl. Personalisierung, dem Alleinstellungsmerkmal gegenüber anderen Herstellern. Nahtloses Tracking, die Experience Plattform Tools können integrativ verwendet werden. Durch die Nutzung der Commerce API werden Analytics Events automatisch getriggert.
  • Verwendung der Business Logic von Sitecore.
  • Erweiterbar. Eigene Plugins können hinzugefügt werden.
  • Pricing Engine mit Dynamisierung der Preisbildung anhand Faktoren, Steuersätze, Währungen, Staffelpreise, Sonderpreise, auch zeitlich befristet, Kampagnen, etc. Tagging für Price Cards.
  • Versandgebühren: weitgehend statische Konfiguration für Shipping und Steuer.

Architektur:

  • Core, Master, Web-Datenbanken wie bekannt. Commerce DB für Content Management (CM) und Content Delivery (CD), Services inkl. Load Balancer, und Search Index.
  • Entscheidung für eine Staging-Instanz.
  • Empfehlung die Storefront-Demo nicht in produktiven Projekten zu nutzen. Es gab viele Empfehlungen für das Aufsetzen und Konfigurieren einer „nackten“ Instanz.
  • Beim Installieren gab es einige Herausforderungen, z.B. Storefront-Package Inhalte, welche im Core benötigt werden. Auch zentrale Funktionen der Commerce API sind nur im Storefront-Package enthalten, sollen aber in zukünftigen Versionen direkt im Core integriert werden. Insgesamt ist die API-Architektur übersichtlich gehalten, es wurden eigene Request & Response-Klassen entwickelt.

Installationsprobleme

Viele Probleme liessen sich nur mit dem Sitecore-Support lösen, Christian fühlte sich als Beta-Tester. Das Update 8.2.1  wirkt stabiler, wobei auch hier weitere Patches notwendig sind.
Anfang 2018 soll die Version 9 von Sitecore Commerce erscheinen. Da dann Legacy Code entfernt wird und weitere Features hinzukommen sollen, könnte es sich lohnen hier eine Neubewertung vorzunehmen.

Fragen & Antworten zum Vortrag

  • Ist die Price Engine benutzerabhängig?
    • Nicht Out-of-the-box, aber manuell erweiterbar
  • Ist eine Anbindung externer Systeme wie Warenwirtschaft machbar?
    • Leider nichts Out-of-the-box. Eine Erweiterung ist via XML, SOAP-Datenaustausch machbar, aber aufwändig. ERP via SOAP & Co. anbindbar. Catalog Manager für Import / Export. Mit Version 9 werden Management-Konsolen wegfallen.
  • Sitecore Empfehlungen für Use Cases?
    • Eher für B2C einsetzen. B2B wird eher im Fokus der Version 9 liegen.
  • Gibt es ein Doku, ist diese ausreichend?
    • Eine Dokumentation ist vorhanden, deckt allerdings noch nicht alle Schritte und Features ab. Hier muss auf externe Blogs u.a. zurückgegriffen werden.
  • Welche Lizensierungsmodelle gibt es?
    • Paketpreise und individuelle Lizenzen.
  • Empfehlung bzgl. Einsatzbarkeit der aktuellen Version oder besser warten auf v9?
    • Diese Frage kann nicht eindeutig beantwortet werden. Auf der einen Seite funktioniert Version 8 – wenn der Zusatzaufwand eingeplant wird – auf der anderen Seite wird Version 9 ein ausgereifteres Gesamtsystem bieten
  • Storefront mit installieren?
    • Nein, Demodaten haben im produktiven Bereich nichts zu suchen.

Buses and Queues with Sitecore & Azure

Vortrag von Mark Cassidy (Cassidy Consult), den er in gleicher Form auf der SUGCON 2017 in Amsterdam vorgetragen hatte. Mark stellte die Vorteil des Einsatzes von Buses und Queues in der Azure-Cloud vor.

Sitecore möchte das dein Einsatz von Microsoft Azure mehr pushen und ist zentraler Bestandteil der erweiterten Firmenstrategie. Enterprise Service Buses sind seit NT 4 Teil der Microsoft-Welt.

Video: www.youtube.com/watch?v=OssLmU48wiU
Mark Cassidy Online: intothecore.cassidy.dk/

Sitecore Usergroup Deutschland Mark Cassidy

Herausforderung

Wie bewege ich Daten zwischen verschiedenen Systemen, welche lose gekoppelt sind.
Vorteile von Azure: Daten verfügbar machen, dabei Performance-skaliert, wenn man sie braucht. Zudem können (technisch-) interdisziplinäre Teams direkt mit dem vorkonfigurierten System arbeiten, die administrativen Tätigkeiten werden minimiert. Das Nadelöhr im „Black Friday“ (High Request Times): die Datenbank. Typische Reaktion: Ausbau der SQL-Server Instanzen, was viel Geld kostet.

Möglichkeiten, dies zu vermeiden:

  • Nutzung des Message Queue. Asynchrones und synchrones Abarbeiten der SQL INSERTs und UPDATES anstatt direktes Feedback.
    Vorteile: garantiertes Abarbeiten unter Lastbedingungen
  • Effizientes Routing, Sicherheit, Prio Messages.
  • Lose Koppelung bringt den Vorteil, dass individuelle Systeme mittels Message Queuing bzgl. Wartbarkeit / Upgrade unabhängig vom Rest bleiben.
  • Need: die Message Queue mit dem Queue Handler. Ein Handler kümmerte sich um eine dedizierte Instanz einer DB.

Sitecore Usergroup Deutschland Mark Cassidy Sitecore compare to Adobe

Azure Storage und Demo-Konfig

Es gibt aktuell insgesamt 5 verschieden Typen von Speicherarten – Blog (Binaries, Media, etc.), Queue, Table, File und Disk.

Mark demonstrierte die Azure Konfiguration für einen Message Queue während der Präsentation. Konfiguration eines Azure Message Brokers. Die Message wird als serialisiertes Item aufbereitet, z.B. JSON. Mittels Event Broadcasting wird die Nachricht an den Message Broker übermittelt und geht in die Message Queue-Verarbeitung. Für eine lokale Entwicklungsinstanz muss der Message Queue Dienst via Windows Feature installiert werden.

Was sind Limitierungen beim Einsatz einer Message Queue?

  • Nicht geeignet für Multi Point Delivery
  • Die Queue muss aktiv gepullt werden.

Enterprise Service Bus (ESB): Ist in der Lage Clones von Nachrichten für optimiertes Delivery zu erzeugen. MQ ungleich ESB: Speicheranforderungen, Push Notifications, FIFO, Rollen-basierender Zugriff, AMQP Support, Message Routing / Distribution. Transaktionsbasiert, Atomic. Erkennung von Duplikaten. ESB verteilt Nachrichten anhand von Topics und Subscribers.

Mark demonstrierte zusätzlich noch die Konfiguration einer ESB Queue für Azure.

Fragen & Antworten zum Vortrag

  • Kann man mehrere MQ im Azure Profile konfigurieren?
    Ja!
  • Was passiert bei einem Timeout?
    Es hängt von der Art der Anfrageverteilung ab, ob es kompensiert werden kann.

100% Availabilty – Scale your System waterproof

Vortrag von Sebastian Winter (METRO SYSTEMS GmbH). Folien können auf Anfrage zur Verfügung gestellt werden. Sebastian Winter beschreibt Ansätze, wie man Hochverfügbarkeit erreichen kann bzw. könnte.

Sitecore Usergroup Deutschland Sebastian Winter

Die Hochverfügbarkeit bezieht sich dabei unter anderem auf Content Delivery (CD) Instanzen, bestimmte Subapplikationen und Content Management (CM) Instanzen.

Inkludiert: Infrastruktur, Applikation, Development & Deployment, Hotfixes, Monitoring.

Anhand einer „typischen“, kleinen Sitecore Infrastruktur mit CM, CD und SOLR-Servern wurde das Infrastruktur-Setup vorgestellt.
Die Fragestellung: Welche Antwortzeiten müssen mindestens gelten? Was passiert beim Ausfall eines Systems? Welche Auswirkungen hat das? Mongo und SOLR DB-Skalierung. Load Balancer für CM und CD. Bei METRO sind dabei auch viele Länder-seitige Instanzen dabei (aber nur Core und Web-DBs, CM bleiben in der Zentrale).

Grundsätzliches Problem der Synchronität der Datenbankinhalte:

  • Nicht vollständig Load-Balancing-fähig
  • NoSQL ist besser synchron zu halten als SQL.

Realisierte Infrastruktur

  • Router und Load Balancer sind doppelt vorhanden. Wenn einer ausfällt springt ein anderer ein.
  • Getrennter Reporting-Server entlastet die CM-Instanz.
  • Die Master-DB ist Single-Point-of-Failure: Replizierung auf zweite, passive DB, da schnell austauschbar.
  • Wichtig: verteilte Hardware. Nicht im gleichen Blech synchronisieren.
  • Health Checks mit Auto-Restart Services.
  • SOLR: 1 Core pro Website und pro DB. Index nicht zu groß. Reindex ohne Überschneidung. Konfiguration für „SwitchOnRebuild“. Redirects beim Reindex nicht verfügbar.
  • Caching: Standard Cache-Einstellungen haben die DB „explodieren“ lassen, große DB CPU Last.
  • Performance beim Requests und Response: kompakt halten, komprimieren, minifizieren. View State Problem vermeiden. Probleme mit Event Quere und Deadlocks wurden analysiert und bereinigt.
  • Sitecore Upgrades und Hotfixes regelmäßig einspielen. Beispiel: Media Items Last, Tracking Field Requests erhöht CPU Last. Prüfen, was genau hier getracked werden soll. Es gibt einen Hotfix, der hier die CPU Last stark entlastet.
  • Abhängigkeiten nach dem HELIX-Prinzip gestaltet: nach den Applikationsteilen anhand Layer strukturiert Vorteil: Auswirkungen auf Implementierung, lose Koppelung entschlackt. 3-Layer-Prinzip: Foundation, Feature und Project.
  • Entwicklung und Deployment: früher Master, DEV und Hotfix-Branch. Problem: DEV musste für den Master mittels Cherry Picking gemerged werden. Lösung: Feature, Sprint und Release Branches mit Merge to Master mit PO Approve (DoD). Ziel: mehr in Richtung Continous Integration / Delivery zu gehen.
  • Qualitätssicherung: Testing manuell, Unit Testing, Code Reviews, Regression Tests mit Automatisierung (z.B. Selenium). KPI Tests, z.B. für Login-Verhalten. Load Testing. Identifizierung von Bottle Necks.
  • Security: Einsatz vom Tool „Police“. Crawled Seiten und prüft beispielsweise auf SQL Infection, interne Daten im Markup und weitere. Ergänzend „manuelles“ Hacking durch entsprechend aufgestellte Teams. Sitecore Security Patches sollten aktuell sein.
  • Zero Downtime Deployment: Ist eine Möglichkeit – bei DB-Updates eigentlich ein DB-Backup, DB abhängen, einspielen, DB einhängen.
    Bei METRO wird eine Downtime für Autoren geplant, z.B. Nachts. Deployments sollten standardisiert werden, z.B. mit Octopus.
  • Monitoring: z.B. mit Pingdom, graphische Übersicht, schneller Überblick, verschiedene Lokationen. 1 min. Pings. Zudem Server Monitoring für CPU, RAM, Disk. Alerts für Telefon, Monitoring Team. ELK Stack Monitoring, zentrale Logs in einer Anwendung, einfachere Auswertung, Dashboards.
    Tools: Logstash, ElasticSearch, Kibana, Grafana, Graphite (Alert Mng.).

Diskussion Sitecore Entwicklung im Team

Diskussion initiiert von Benjamin Gabriel & Philipp Nestler (Namics Deutschland GmbH).
Philipp und Benjamin starteten eine Diskussion, wie die Entwicklungsarbeit im Team effizienter und fehlerloser werden kann.

Sitecore Usergroup Deutschland Benjamin GabrielSitecore Usergroup Deutschland Philipp Nestler

Die Diskussionsrunde wurde mit einer einführenden Folie gestartet, welche allgemeine Prozesse in der Sitecore Entwicklung widerspiegelt.

  • Team
    • Remote
    • Git
    • Scrum
  • Deployment
    • Qualitiy Management
    • Versioning / Backups
    • Flexibility

Als Start in die Diskussion wurden die Entwicklungsprozesse bei Namics vorgestellt. Insbesondere mit Fokus auf folgende Themen:

  • Für ein sauberes Deployment ist ein Server für kontinuierliche Integration (wie Bamboo oder Teamcity) unerlässlich. Allerdings muss auch auf die Flexibilität geachtet werden. Beispielsweise müssen Hotfixes und Patches schnell eingespielt werden können.
  • Ganz besonderes Interesse wurde dem automatisierten Testing entgegengebracht. Hierbei stellte sich heraus, dass insbesondere Frontend-Tests mit Selenium einen produktiven Mehrwert in Projekten herbeigeführt haben. Manuelles Testing kann hierbei (auch beim Kunden) reduziert und mögliche Fehlerfindung deutlich reduziert werden.

Aus zeitlichen Gründen konnte leider die Thematik der Item-Serialisierung nicht mehr aufgegriffen werden.

Neben den inhaltlichen Aspekten war es auch ein Ziel zu prüfen, ob eine interaktive Diskussionsrunde eine sinnvolles Format für das nächste Treffen der Sitecore Usergroup wäre. Dies wurde durch positives Feedback bestätigt.
Ein mögliches Thema könnte es hierbei sein, wie ein effizienter Ansatz zur Wiederverwendbarkeit von Basiskomponenten aussehen könnte.

Über die Sitegroup User Group Deutschland e.V.

Abschließend berichteten Friederike Heinze (comspace GmbH & Co. KG) und Christopher Wojciech (netzkern AG) von der Vereinsgründung und den nächsten Schritten. Sowohl Unternehmen als auch Einzelpersonen können Mitglied werden. Vorteil wäre dann z. B. für Veranstaltungen mehr Budget zu haben, rechtliche Rahmenbedingungen wären auch besser erfüllt. Insgesamt gab es dazu ein positives Echo.

Apéro

Im Anschluss an die Veranstaltung haben sich die Teilnehmer der Sitecore Usergroup noch beim Kinorestaurant zusammengefunden, um den Abend mit einem guten Essen und einem kühlen Getränk ausklingen zu lassen.

Sitecore Usergroup Deutschland After Show

Eine tolle und gelungene Veranstaltung, danke an die Organisatoren!

Hinterlasse eine Antwort

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

*

*

Du kannst folgende HTML-Tags benutzen: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>