SUGCON Europe 2017 – Sitecore Cognitive Services

Sitecore Poster SUGCON EU 2017

Microsoft bietet mittlerweile seit einer geraumer Zeit eine Fülle von „Cognitive Services“ an. Diese Services bieten in verschiedenen Bereichen wie Vision, Speech, Language, Knowledge und Search Funktionalität an, die kaum ohne Cloud Power ausführbar sind. Da es sich hierbei wirklich … Weiterlesen

Namics at SUGCON Europe 2017

sugcon-europe-2017

Am Donnerstag 18.5 bis Freitag 19.5 hat in Amsterdam die SUGCON Europa 2017 stattgefunden. Dieses Sitecore User Group Treffen mit grob über den Daumen geschätzten 400-500 Teilnehmern aus ganz Europa und darüber hinaus die Austauschplattform zu aktuellen Sitecore Themen. Die … Weiterlesen

Sitecore PowerShell Extensions – Fieldtype Source Report

SPE Fieldtype Report

Sitecore Template Felder besitzen über das Source Feld zusätzliche Konfigurationen die Feldtyp spezifisch sind. Oft handelt es sich dabei um Referenzen auf einen Pfad, ein bestimmtes Item oder eine Auswahl von Items (Sitecore Query). Ein oft verwendetes Beispiel wäre das … Weiterlesen

Sitecore & Redesigns

Webseiten stehen unter ständigem Wandel und meist wirkt ein „State of the Art“ Design bereits nach 2 oder 3 Jahren wieder veraltet.
Im Gegensatz zu einzelnen Weiterentwicklungen, die sich in der Regel sehr gut step-by-step in eine bestehende Solution ausliefern lassen, steht bei einem Redesign oft bereits wieder ein grösserer Projektkontext dahinter (ja, man denkt sogar an eine neue Solution?). Zu guter Letzt sitzt man aber doch auf einer bereits beträchtlich angewachsenen „Datenbasis“ bestehend aus Seiten, Dokumenten und anderen Elementen die nur ungern ausgemistet, überarbeitet oder gar ganz neu erstellt werden müsste.

Oft stellen sich in Sitecore auch noch weitere Herausforderungen wie:

  • Multisite Solution mit unterschiedlichen Designs oder einem schrittweisen Ausrollen des Design auf einzelne Seiten
  • Nachvollziehbarkeit für die Autoren wie eine Seite vorher/nachher ausgesehen hat
  • Schulung für Autoren, wenn sich der Editierprozess bedeutend ändert
  • Umstellung des Designs ohne Content-Freeze (Zeit während der Umstellung, in der die Autoren keinen neuen Content erfassen können)

Ein möglicher Ansatz mit einer solchen Situation umzugehen zeige ich hier anhand eines einfachen Standard Sitecore Bordmittels auf: den Devices! (mehr …)

The Power of Pipelines – Custom Pipeline

Ein oft verwendetes Architekturmuster von Sitecore ist die Pipeline. Eine Pipeline definiert eine Abfolge von auszuführenden Prozessoren. Jeder einzelne Prozessor übernimmt dabei eine ganz konkrete Aufgabe und  trennt damit die Verantwortlichkeit.
In diesem Beitrag wird gezeigt wie eine eigene Pipeline angelegt wird.
(mehr …)

Sitecore & Azure

Wie bringt man Sitecore auf Microsofts Azure Cloud Services?

Ein Weg um Sitecore in die Cloud zu stellen, ist der direkte Weg über das manuelle Einrichten von Sitecore Instanzen via Cloudservices oder virtuellen Servern, die Azure einem anbietet. Um aber wirklich auf Wolke 7 zu schweben, hat sich Sitecore ein Modul ausgedacht: Sitecore Azure!

Sitecore Azure
Das Sitecore Azure Modul lässt sich einfach vom Sitecore Development Network (SDN) herunterladen. Zusammen mit einer 27 Seiten starken Dokumentation zum Installieren und Konfigurieren der Anwendung.

Ausgangspunkt ist eine lauffähige Sitecore Instanz des Projekts. Auf diese Sitecore Instanz wird über den „Installation Wizard“ von Sitecore das „Sitecore Azure“ Modul installiert. Also ganz so, wie man es sich von Sitecore gewohnt ist!

Tipp: Es lohnt sich die Einschränkungen und Anforderungen vorher gründliche durchzulesen.

Mit dem Tool installieren sich eine Menge Items und Files in Sitecore. Für den Sitecore Benutzer ersichtlich ist danach aber lediglich ein neuer Eintrag in der Programmstartliste.

Mit der Installation wurde aus der Sitecore Instanz ein „Deployment Center“. Das Deployment Center ist nun der Dreh- und Angelpunkt des Geschehens, egal welche Sitecore-Azure-Architektur (Azure Delivery/Azure Live Mode/Azure Authoring + Delivery) Sie nun einsetzen.

Hinweis: Bei der Azure Delivery Architektur dient das Deployment Center auch als Editing Instanz. Bei den anderen nur als Deployment Center.

Delivery Architektur

Ist das Modul installiert, ein Zertifikat generiert und ein „Environment“-File bezogen (Sitecore) steht Ihnen die ganze Welt offen. Dies zeigt sich anhand einer Weltkarte  mit einer Auswahl an möglichen Standorten. Die Standorte entsprechen den physischen Azure Datacentern, auf welche Sitecore nun eingespielt werden kannn.
Mit wenigen Klicks fährt eine Content Editing (CE) Farm oder Content Delivery (CD) Farm Instanz hoch, frei skalierbar.

CE und CD Instanzen einfach Verwalten.

Ein Blick in die Azure Administrationsseite lohnt sich! Mit jeder erstellten Farm werden nämlich SQL Azure Datenbanken oder Cloudservices eingerichtet. Die Namen sind zwar sehr gewöhnungsbedürftig, dafür logisch aufgebaut. Es hilft zu verstehen was Sitecore genau macht. Die Dokumentation liefert hier nämlich kaum aussagekräftige Informationen. Ein Blick auf die anfallenden Gebühren ist sowieso ratsam.

Stolpersteine
Mit dem einen oder anderen Stolperstein ist dann aber doch zu rechnen.
Leider ist nur wenig davon dokumentiert, was und wie Sitecore die Dinge genau macht.
Einige Stolpersteine vorweg:

  • Der „Data“-Folder Pfad in der Sitecore Konfiguration darf nicht relativ angegeben werden.
  • Der „Data“-Folder darf nicht im Sitecore Webverzeichnis liegen.
  • Die Sitecore Konfigurationen dürfen nicht in separate Dateien ausgelagert werden. Alles in Web.config.

Hat man erst einmal den Dreh raus, funktioniert Sitecore Azure einwandfrei. Und merkt man wie einfach die Skalierung dann von der Hand geht, ist man restlos überzeugt.

 

DMS – Conditional Renderings & Visitor Experience

Über Conditional Renderings verändert man einfach die Website anhand der Situation. So entsteht für die Startseite je nach Besucher unterschiedliche Ausprägungen.

  • Einem Besucher der den Newsletter bereits abonniert hat, muss ich keinen Anmeldebanner mehr präsentieren.
  • Einem Besucher der zuletzt einen Flug nach New York gesucht hat, möchte ich möglicherweise einen Buchungsteaser präsentieren.
  • Wer sich gerade erst über ein Reiseziel informiert hat, kommt womöglich wieder und sucht denselben Inhalt erneut.

Für diese Situation bieten sich Conditional Renderings an.
Anhand der Sitecore Demo Jetstream zeigt sich, wie einfach solche Cases umgesetzt werden können.

Der Fall: Besucher von Jetstream suchen einen Flug. Je nach Reiseziel wird die Website für den Besucher angepasst. Sucht der Besucher einen Flug nach New York, werden ihm nicht mehr irgendwelche Bilder und Teaser von Paris gezeigt, sondern Infos über New York. Das Hintergrundbild der Seite ändert sich. Teasers und Links ermöglichen ihm den schnellen Zugriff auf – für ihn – relevante Informationen.

Und so gehts: Für jede Situation werden eigene Slider Daten angelegt. So entsteht ein Set von möglichen Inhalten für die Seite.

Verschiedenen Sliderinhalte

 

Danach konfiguriert man im Page Editor von Sitecore über „Personalize component“ Bedingungen. Das DMS bringt bereits diverse Condition Rules mit. Es ist aber auch möglich, eigene Conditions zu implementieren.

Trifft die Bedingung zu, werden die entsprechenden Daten angezogen. (Beispielsweise die Sliderdaten für New York)

Um das zu bewerkstelligen, werden zwei „Condition Rules“ verwendet. Die eine prüft, ob es sich um einen anonymen Besucher handelt (Basis Rule), die zweite prüft, ob der Besucher einen Flug nach New York gesucht (Custom Rule) hat.

Bedingungen anlegen

Im Page Editor Modus kann man nun zwischen den verschiedenen Ausprägungen umschalten.

Auswahl der Ansicht

Das folgende Video zeigt eindrücklich, wie sich die Seite anhand des Verhaltens des Besuchers anpasst.

Namics Sitecore Search

„Wer suchet, der findet!“

Dass dem nicht immer so ist belegen diverse Projekte. Websites können heute kaum noch auf eine Volltextsuche verzichten und die meisten gehen sogar noch einen Schritt weiter und benötigen eine spezielle Produkt oder Dokumentensuche. Oberflächlich betrachtet erscheinen diese Suchen sehr einfach gestrickt, besteht sie doch meist aus einer Textbox, gegebenenfalls aus einigen weiteren Kriterien. Dass sich darunter doch ein wenig mehr verbirgt zeigt sich meist recht spät im Projekt. Erst wenn die Inhalte erfasst sind, Dokumente hochgelanden und alles andere an seinem Platz zu finden ist, bemerkt man wie die Suche wirklich funktioniert. Dies gilt nicht nur für den Kunden, sondern auch oft für den Entwickler.  So entsteht aus der meist einheitlichen Maske eine sehr individuelle Lösung für den Kunden.

Die Standard Sitecore Suche – basierend auf der Lucene Search Engine – ist zwar offen und flexibel für die meisten Bedürfnisse, erfordert zugleich aber trotzdem noch einen entsprechenden Aufwand für die Entwickler. Implementierte Funktionalität wird von Projekt zu Projekt übernommen, erweitert, verbessert und angepasst. Trotzdem fehlt oft eine einfache und benutzerfreundliche Schnittstelle von Projekt zu Projekt wiederverwendbar, individualisierbar sofern notwendig und zeitsparend bei der Implementierung.

Mit der Namics Sitecore Search haben wir ein Framework erstellt, das in zukünftigen Projekten Wiederverwendung findet und  die Implementierung vereinfacht. Auf dem Framework wurde ein Paket geschnürt welches eine Basis-Implementation einer einfachen Volltextsuche enthält. Individuellere Suchen können über Anpassungen an der Standardsuche vorgenommen werden. Spezielle Erweiterungen setzen einfach direkt auf dem Framework auf.

Suchresultatliste

Standard Namics Sitecore Search

Die Standardinstallation der Suche installiert ein Sublayout für die Suchresultatliste sowie den Service zur Indexierung und Suchanfrage. Für die Volltextsuche werden die Sitecore Seiten gecrawled. Der Crawler indexiert also nicht die entsprechenden Felder der Items einer Page, sondern indexiert den effektiven Inhalt aus Sicht des Benutzers. Über die Rendering Parameter und Placeholdersettings lässt sich auf der Komponente bestimmen, welche Bereiche einer Website nun indexiert werden sollen und welche nicht. Damit man eine konkrete Vorstellung davon erhält was denn eigentlich indexiert wird und was ignoriert wird, enthält die Suchkomponente noch ein zusätzliches Sublayout, welches die entsprechenden Bereiche markiert.

Indexierungsansicht

Indexierungsansicht

Die Daten zur Indexierung werden dem Webservice übermittelt, genauso die Suchanfragen. Zurückgeliefert werden die Resultate in JSON, womit die Weiterverarbeitung in JS erfolgen kann. Auch hier liefert das Paket bereits eine JavaScript-Datei mit, die einem einen Grossteil der Arbeit abnimmt.

Wir hoffen die Suche wird noch viele Einsatzorte finden.