Better to be on the safe side? Zugriffsrechte! (2/2)

Um die Zugriffsrechte, die im vergangen Tipp der Woche präsentiert wurden, autorenfreundlich verwalten zu können, werden diverse Tools eingesetzt. Sitecore bietet hierfür verschiedene Möglichkeiten mit dem User Manager, Role Manager, Security Editor, Access Viewer, Domain Manager und dem Security Bereich im Content Editor, die im Anschluss kurz vorgestellt werden:

User Manager
Der User Manager dient der Benutzerverwaltung. Hier können Benutzer erstellt, bearbeitet, gelöscht, blockiert, aktiviert und Passwörter geändert werden.
Sitecore User Manager

Role Manager
Der Rollen Manager kann zur Verwaltung von bestehenden und zur Erstellung von neuen Rollen, welche Benutzer zugewiesen werden können, verwendet werden. So können neue Rollen definiert, bestehende Rollen gelöscht, sowie Benutzer Rollen zugewiesen und wieder entfernt werden.
Sitecore Rollen Manager

Security Editor
Im Security Editor können Pfad spezifische Zugriffsrechte bestimmt werden.
Sitecore Security Editor

Access Viewer
Der Access Viewer liefert einen Überblick über Zugriffsrechte von Security Accounts.
Sitecore Access Viewer

Domain Manager
Mit dem Domain Manager können neue Domains erstellt und gelöscht werden. Weiteres kann definiert werden, ob die Domains global oder nur lokal gemanagt werden können.
Sitecore Domain Manager

Security im Content Editor
Im Content Editor können Zugriffsrechte auf Items im Navigations-Baum vergeben, Eigentumsrechte von Items geändert, sowie einen Überblick über Zugriffsrechte der Rollen und Benutzer eingesehen werden.
Sitecore Content Editor

Best Practice Tipps

Was muss bei der Rechtevergabe beachtet werden?

  • Zugriffsrechte nur Rollen und nicht Usern direkt vergeben
  • Rollen nicht domainspezifisch erstellen
  • Vererbungen verwenden um Zugriffsrechte von Rollen einzuschränken

Mit den hier präsentierten Rollen- und Rechtekonzepten und den zur Verfügung stehenden Management-Tools, bietet Sitecore die Möglichkeit, auch komplexe Zugriffsszenarien umsetzen und effizient verwalten zu können.

Sitecore E-Commerce Services 2.0

Die Sitecore E-Commerce Services (SES) beinhalten zahlreiche E-Commerce-Funktionen, die den Aufbau und die Verwaltung komplexer und leistungsfähiger E-Commerce-Lösungen ermöglichen. Durch die SES wird die notwendige, grundlegende Infrastruktur bereitgestellt, um E-Commerce-Websites mit dem Sitecore CMS zu bauen. Dabei nutzen die SES die Leistungfähigkeit des Digital Marketing System, um Besucher auf der Website zu tracken und zu segmentieren. Dieses Vorgehen erlaubt eine gezielte, zielgruppenspezifische Ansprache der potentiellen Kunden und ermöglicht damit eine Erhöhung der Conversion.

Mittlerweile hat Sitecore die Version 2.0 der E-Commerce Services (SES) veröffentlicht. Im Vergleich zur Vorgängerversion wurden einige Bereiche in Sitecore E-Commerce Services 2.0 grundlegend überarbeitet bzw. hinzugefügt.

Die Highlights der neuen Version von E-Commerce Services 2.0 sind:

  • Das neu entwickelte Order Management zur Vereinfachung der täglichen Arbeit von Order Managern und Kundenservice durch den Einsatz eines neuen, aufgabenbasierten User-Interface.
  • 3 neue APIs, die ein verbessertes Core-Order Management, Visitor Order Management und Merchant Order Management ermöglichen.
  • Ausdruck von Bestellbestätigungen.
  • Order Management, das über den Browser direkt zugänglich ist. Der etwas umständlichere Zugang über den Sitecore Desktop kann damit umgangen werden.

 

Welche Vorteile bietet der Einsatz von Sitecore E-Commerce Services gegenüber weiteren E-Commerce Systemen?

  • Sowohl die Website als auch der Web-Shop basieren auf ein und derselben Plattform. Dies erlaubt einen effizienten Betrieb und vereinfacht die Wartung des gesamten Systems.
  • Eine einheitliche Bedienbarkeit für Editoren und Entwickler vereinfacht die tägliche Arbeit mit dem System und ermöglicht eine bestmögliche Zusammenarbeit.
  • Optimierung der User Experience, da keine Sprünge zwischen verschiedenen Systemen erforderlich sind.
  • Hohes Cross-Selling-Potential, da Empfehlungen auf Basis des Userprofils aus dem CMS ausgesprochen werden können.
  • Der Einsatz einer einheitlichen Lösung erlaubt ein echtes Digital Marketing über alle Kanäle hinweg.

 

Durch die Version 2.0 konnten die Sitecore E-Commerce Services weiter verbessert werden und an Funktionenreichtum und Benutzerfreundlichkeit zulegen.

„Unit-Testing“ mit Sitecore

Viele Software-Entwickler dürften mittlerweile um die Wichtigkeit und Nützlichkeit von Unit-Tests Bescheid wissen. So erleichtert der Einsatz von Unit-Tests beispielsweise das Schreiben robuster und flexibler Software. Ausserdem dienen die Tests beim Refactoring als „Sicherheitsnetz“, um das „äussere Verhalten“ der Software nicht unbeabsichtigt abzuändern.

Allerdings bringt das Schreiben von Unit-Tests auch einiges an Mehraufwand mit sich und in gewissen Umgebungen scheint das Schreiben von Unit-Tests
sehr schwierig oder gar unmöglich zu sein. Gerade auch bei Web-Applikationen mit Sitecore scheint das Schreiben von Unit-Tests ein schwieriges Unterfangen zu sein, da die Sitecore-API „im Hintergrund“ auf Datenbanken zugreift und einen Web-Context voraussetzt.

In diesem Artikel wollen wir aufzeigen, wie man für Sitecore-Code mit einem pragmatischen Ansatz trotzdem relativ einfach automatisierte Tests schreiben kann.

Automatisierte Tests mit einem Web-Testrunner

Alistair Deneys hat eine sehr schöne Reihe von Posts zum Thema „Unit-Testing mit Sitecore“ veröffentlicht. Im Buch „Professional Sitecore Development“ wurde ausserdem ein ganzes Kapitel dem Thema „Testing“ gewidmet, welches ebenfalls von Deneys verfasst wurde. Deneys diskutiert in seinen Blogs und im Buch „Professional Sitecore Development“ verschiedene Möglichkeiten, um Code, der die Sitecore-API verwendet, testen zu können.

Ein sehr pragmatischer Ansatz, um Sitecore-Code zu testen, besteht darin, die Tests in einem Web-Testrunner im Sitecore-Context auszuführen. Mit dieser Technik bleibt das (teilweise mühsame und zeitaufwändige) Mocking von Datenbankzugriffen und dem Web-Context erspart. Wenn die Tests in einem Web-Testrunner ausgeführt werden, haben wir in den Tests vollen Zugriff auf die Sitecore-Datenbanken und den Web-Context.

Wenn wir Tests schreiben, die in einem Web-Testrunner ausgeführt werden, dürfen wir streng genommen allerdings nicht mehr von „Unit-Tests“ sprechen, sondern viel mehr von „automatisierten Tests“ (siehe Definition „Unit-Test“ von Roy Osherove).

Ein einfacher Web-Testrunner, welcher auf NUnit basiert, kann bei Deneys gratis heruntergeladen werden (Link Web-Testrunner). Bei dem Web-Testrunner handelt es sich im Wesentlichen um eine ASPX-Page, die in das Visual-Studio-Sitecore-Web-Projekt eingebunden werden kann. Im Code-Behind dieser ASPX-Page referenziert man dann die DLL des Testprojektes, in welchem sich die automatisierten Sitecore-Tests befinden.

Folgende Abbildung zeigt ein Beispiel des Web-Testrunners in Aktion (Quelle).

Ein einfaches Code-Beispiel

Deneys geht in seinen Posts auf verschiedene „Typen“ von Tests ein. Etwas vereinfacht können wir zwischen folgenden beiden Test-Typen unterscheiden:

  1. Testen von Präsentationskomponenten (Layouts, Sublayouts, Usercontrols, …)
  2. Testen von Code, der auf die Sitecore-API zugreift (beispielsweise Helper-Klassen, um Sitecore-Items zu bearbeiten/auszulesen/etc.)

Folgendes Listing zeigt ein einfaches Beispiel, wie ein Test für den Test-Typ 2 aussehen könnte.

[TestFixture]
[Category("Util Tests")]
public class TestClass
{
   private Item m_root, m_child1, m_child2, m_child3 = null;

   [SetUp]
   public void TestFixtureSetUp()
   {
      var home = Sitecore.Context.Database.GetItem("/sitecore/content/home");
      var template = Sitecore.Context.Database.Templates["User Defined/Page"];

      using (new SecurityDisabler())
      {
         m_root = home.Add("root", template);

         m_child1 = m_root.Add("Child 1", template);
         using(new EditContext(m_child1))
         {
            m_child1["title"] = "Child 1 Title";
         }

         m_child2 = m_root.Add("Child 2", template);
         m_child3 = m_root.Add("Child 3", template);
      }
   }

   [TearDown]
   public void TestFixtureTearDown()
   {
      using (new SecurityDisabler())
      {
         m_root.Delete();
      }
   }

   [Test]
   public void TitleNotEmptyTest()
   {
      string title = Util.GetTitle(m_child1);
      Assert.AreEqual("Child 1 Title", title);
   }

   [Test]
   public void TitleEmptyTest()
   {
      string title = Util.GetTitle(m_child2);
      Assert.AreEqual("", title);
   }
}

Der Code im obenstehenden Beispiel zeigt, wie wir in der Setup-Methode eine „Dummy-Item-Struktur“ für die Tests mit der Sitecore-API aufbauen. In der Teardown-Methode wird diese Dummy-Item-Struktur wieder gelöscht. In den Tests können wir diese Dummy-Items dann verwenden, um unseren Code (im obigen Beispiel die Methode GetTitle der (Helper-)Klasse Util) zu testen.

Fazit

In diesem Artikel haben wir gesehen, dass man mit einem pragmatischen Ansatz auch für Sitecore-Solutions relativ einfach automatisierte Tests schreiben kann. Die Tests werden dabei in einem Web-Testrunner im Sitecore-Context ausgeführt, wodurch wir in den Tests vollen Zugriff auf die Sitecore-Datenbanken und den Web-Context haben. Das zeitaufwändige Mocking von Datenbankzugriffen und dem Web-Context erübrigt sich durch das Ausführen der Tests in einem Web-Testrunner.

Custom Gutter für die Übersicht der Item-Versionen

„Gutters“ sind wohl eines der versteckteren Features des Sitecore Content Editors – bieten jedoch eine schnelle optische Erfassungsmöglichkeit über die ganze Sitecore-Item-Hierarchie für eine bestimmte Anforderung. Standardmässig sind folgende Gutters im System vorhanden:

  • Clones
  • My Locked Items
  • WorkflowState
  • Broken Links
  • Missing Versions
  • Publishing Warnings
  • Validation Rules
  • Presentation Overriden

Nach der Aktivierung eines oder mehreren Gutters, erscheint – und darum der Name – in der linken „Rinne“ des Content-Editors ein Symbol, welches zusätzliche Informationen visuell, aber auch textuell über einen Tooltip präsentiert. Die vorhandenen Gutters decken bereits eine gewisse Anzahl an Bedürfnissen ab, je nach Projekt können aber natürlich weitere hinzukommen. Die Grundarchitektur von Sitecore ermöglicht einem hierbei, eigene Gutters zu erstellen. Selbstverständlich auf einfache Art und Weise.

Ein Beispiel

Als häufige Kundenanforderung wird oft eine Übersichtsmöglichkeit gewünscht, bei der man sehen kann, ob ein Item in der aktuell aktivierten Sprache vorhanden ist, oder nicht. Out of the Box bietet Sitecore den Gutter „Missing Versions“ an, welcher sich jedoch darauf spezialisiert hat alle Items hervorzuheben, welche irgend eine Lücke in einer Sprache besitzen – unabhängig von der gewählten Sprach-Version. Dies ist zwar sehr nützlich, jedoch nicht für jede Situation brauchbar.

Aus diesem Grund erstellen wir nun einen eigenen Gutter mit der gewünschten Funktionalität. Da wir in einigen Projekten den Language Fallback von Alex Shyba im Einsatz haben, werden wir dieses Modul ebenfalls mitberücksichtigen.

 

1. Erstellung der Klasse, welcher innerhalb der Web-Applikation zur Verfügung steht:

namespace Project.Core.Gutters
{
    using System;
    using Sitecore.Data.Items;
    using Sitecore.Data.Managers;
    using Sitecore.Diagnostics;
    using Sitecore.Globalization;
    using Sitecore.Shell.Applications.ContentEditor.Gutters;

    /// <summary>
    ///     Represents a LockedItems.
    /// </summary>
    public class MissingCurrentVersion : GutterRenderer
    {
        /// <summary>
        /// The language fallback field name
        /// </summary>
        private const string FIELD_FALLBACK = "Fallback";

        #region Methods

        /// <summary>
        /// Gets the icon.
        /// </summary>
        /// <param name="pItem">
        /// The item.
        /// </param>
        /// <returns>
        /// The icon.
        /// </returns>
        protected override GutterIconDescriptor GetIconDescriptor(Item pItem)
        {
            Assert.ArgumentNotNull(pItem, "pItem");

            if (pItem.Versions.Count > 0)
            {
                return null;
            }

            try
            {
                var language = LanguageManager.GetLanguage(pItem.Language.CultureInfo.Name);
                var langItem = language.GetItem(pItem.Database);
                if (langItem != null && !string.IsNullOrEmpty(langItem[FIELD_FALLBACK]))
                {
                    var fallbackLangItem = LanguageManager.GetLanguage(langItem[FIELD_FALLBACK]);
                    if (fallbackLangItem != null)
                    {
                        var fallbackItem = pItem.Database.GetItem(pItem.ID, fallbackLangItem);
                        if (fallbackItem != null)
                        {
                            if (fallbackItem.Versions.Count > 0)
                            {
                                string fallBackMessage = string.Format("{0} {1} | {2} {3}", Translate.Text("Missing versions in: "), pItem.Language.CultureInfo.EnglishName, Translate.Text("Use Fallback-Language: "), fallbackLangItem.CultureInfo.EnglishName);
                                GutterIconDescriptor fallbackGutterIconDescriptor = new GutterIconDescriptor { Icon = "Applications/32x32/nav_undo_red.png", Tooltip = fallBackMessage };
                                return fallbackGutterIconDescriptor;
                            }
                        }
                    }
                }
            }
            catch (Exception ex)
            {
                Log.Warn(string.Format("Gets an Error to check the Language-Versions with message: {0}", ex.Message), this);
            }

            string str = string.Format("{0} {1}", Translate.Text("Missing versions in: "), pItem.Language.CultureInfo.EnglishName);
            GutterIconDescriptor gutterIconDescriptor = new GutterIconDescriptor { Icon = "Applications/32x32/warning.png", Tooltip = str };
            return gutterIconDescriptor;
        }

        #endregion
    }
}

 

2. Anschliessend müssen wir nur noch unsere Klasse in der Sitecore-Core-Datenbank registrieren.

Pfad: /sitecore/content/Applications/Content Editor/Gutters/

 

That’s it! Nun haben wir alle Entwicklungsarbeiten erledigt & können unseren neuen Gutter im Content Editor aktivieren:

 

Anschliessend erhalten wir von Sitecore  eine Warnung, wenn ein Item in unserer aktiven Sprache nicht gepflegt wurde:

Zusätzlich wird eine andere Anzeige aktiviert, wenn es zwar keine Version in meiner aktiven Sprache gibt, aber die definierte Fallback-Sprache hier greifen würde. Dieses Icon ist nur dann ersichtlich, wenn das Modul auch installiert wurde. Ohne Fallback-Modul würde hier ebenfalls das „Warn“-Icon angezeigt werden.

Fazit
Zusammenfassend kann man behaupten, dass man über Gutters sehr schnell, mit sehr wenig Aufwand solche Anzeige-Hilfen in Sitecore erstellen lassen kann.
Daraus resultiert eine Qualitäts- und Produktivitätssteigerung für die Backend-Authoren.

Better to be on the safe side? Zugriffsrechte! (1/2)

In einem zweiteiligen Blogpost möchten wir kurz das Rollen- und Rechtemanagement von Sitecore vorstellen. Im ersten Teil des Posts geht es um die möglichen Rechte und Rollen an sich, im zweiten Teil, den wir nächste Woche veröffentlichen werden, werfen wir einen Blick auf die Administration dieser Zugriffsbeschränkungen innerhalb von Sitecore.

Sitecore setzt Security Accounts ein, um Benutzerzugriffe auf diverse Inhalte der Webseite, sowie Zugriffe auf Sitecore Funktionalitäten zu verwalten. Ein „Security Account“ kann sowohl ein Benutzer als auch eine Rolle sein. Nach dem Erstellen des Benutzers können dem jeweiligen User bestimmte Rollen zugewiesen werden, welche verschiedene Zugriffsrechte beinhalten. Zu Beginn sind Standard-Sitecore-Rollen definiert, welche aber ohne Weiteres bearbeitet oder mit neuen Rollen ergänzt werden können. Ein Benutzer kann grundsätzlich auch mehrere Rollen haben. In diesem Fall werden die Zugriffsrechte konsolidiert. Zusätzlich bietet Sitecore die Möglichkeit der Vererbung (Inheritance). Somit können Zugriffsrechte den unterliegenden Items (z.B. einem ganzen „Navigations-Ast“) vererbt werden.

Zur Verfügung stehende Access Rights (Zugriffsrechte) sind:

  • Read: Entscheidet ob ein Benutzer bestimmte Items / Inhalte sehen kann. (Zugleich Voraussetzung für alle weiteren Zugriffsrechte)
  • Write: Entscheidet ob Benutzer Inhalte bearbeiten können.
  • Rename: Bestimmt ob Benutzer Item Namen ändern können.
  • Create: Entscheidet ob Benutzer „Child Items“ unter dem jeweiligen Item anlegen können.
  • Delete: Entscheidet ob Benutzer Items löschen können.
  • Administer: Entscheidet ob Benutzer Access rights für Items vergeben können.
  • Field Read: Bestimmt ob Benutzer Felder in Items lesen können.
  • Field Write: Bestimmt ob Benutzer Felder in Items updaten können.
  • Language Read: Entscheidet ob Benutzer Sprachversionen von Items sehen können.
  • Language Write: Bestimmt ob Benutzer Sprachversionen von Items updaten können.
  • Site Enter: Entscheidet ob Benutzer Zugriff auf bestimmte Seiten haben.
  • Show in Insert: Bestimmt ob Templates im Content Editor in der „Insert Options List“ oder im Page Editor in der „Insert Dialog Box“ ersichtlich sind.
  • Workflow Command Execute: Entscheidet ob Benutzer bestimmte Workflow Befehle ausführen können.
  • Workflow State Delete: Entscheidet ob Benutzer Items löschen können, wenn sie einen bestimmten Workflow Status haben.
  • Workflow State Write: Entscheidet ob Benutzer Items updaten können, wenn sie einen bestimmten Workflow Status haben.

Um diese Sicherheitseinstellungen verwalten zu können, werden diverse Security Tools benötigt. Mehr zu diesen Sitecore Tools werden wir in der kommenden Woche in unserem „Tipp der Woche“ veröffentlichen.

Splunk for Sitecore Logs

Was ist Splunk?

Splunk ist ein Log-, Monitoring- und Reporting-Tool. Es kann verschiedenste Textdateien, wie Log-Dateien oder andere Daten von Applikationen oder Servern, einlesen und in einem durchsuchbaren Speicher ablegen. Splunk bietet ein komfortables Web-Interface, mit dem die indexierten Daten durchsucht werden können sowie Warnmeldungen und grafisch ansprechende Diagramme generiert werden können.

Sitecore Log Source Type

Splunk liest die einzelnen Files nach einem vordefinierten Muster ein und versucht so, die einzelnen Events zu erkennen. Diese Muster werden Source Types genannt und sind essentiell wichtig, damit die Analyse von Log-Files überhaupt funktionieren kann. Leider existiert für Sitecore bzw. log4net kein Source Type. So haben wir selber einen solchen erstellt und können nun die Sitecore Logs sauber indexieren. In der Datei etc/system/local/props.conf des Splunk-Programm-Verzeichnisses muss dazu folgender Eintrag gemacht werden:

[Sitecore Log]
BREAK_ONLY_BEFORE = \S+\s\d{2}:\d{2}:\d{2}
NO_BINARY_CHECK = 1
SHOULD_LINEMERGE = true
pulldown_type = 1

Sobald die Konfigurationsdatei angepasst und Splunk neu gestartet wurde, kann beim Hinzufügen von neuen Datenquellen der Source Type „Sitecore Log“ ausgewählt werden:

Splunk ist ein nützliches Tool, um viele Log-Files komfortabel zu durchsuchen und zu analysieren. Die zusätzlichen Funktionen wie beispielweise das automatische Alarmieren bei gewissen Events, machen den Einsatz in einer Produktivumgebung mit grossem Datenvolumen interessant. Zu erwähnen ist ausserdem Splunk Storm, welches die cloud-basierte Version von Splunk darstellt.

SEO Toolkit – Was steckt dahinter?

Suchmaschinenoptimierung mit Sitecore

Von Keywords über Meta Tags, Descriptions und vieles mehr, kann Ihre komplette Webseite mit dem SEO Toolkit schnell und einfach analysiert und suchmaschinenfreundlich verwaltet werden.

SEO Toolkit

Verschiedene Register helfen dem Autor den Überblick über nachfolgende SEO relevanten Themen zu behalten:

Page Information:

Dieses Register bietet einen kurzen Überblick über SEO relevante Inhalte der jeweiligen Seite. So erkennen Sie auf einen Blick wo das SEO Toolkit noch Suchmaschinen-Optimierungspotential sieht.

Text Only View:

Der Text Only View stellt die aktuelle Seite aus Sicht der Suchmaschine dar. So werden jegliche Designs und Bilder entfernt, um den indexierten Inhalt zu sehen. Überschriften werden in grösseren Schriftarten dargestellt, da diese auch von der Suchmaschine besser bewertet werden. Links werden in Form von unterstrichenem Text und Bilder, welche einen gepflegten Alternativtext haben, werden mit eckigen Klammern [Alternativtext] dargestellt.

Key Words:

Die aufgelisteten Keywords in diesem Register, sind Wörter welche im Seiteninhalt am Häufigsten benutzt wurden. Zusätzlich wird in % die Häufigkeit des Wortes in Relation mit dem gesamten Seiteninhalt angegeben. Per Klick können Sie dann das jeweilige Keyword in einer Suchmaschine (Google, Yahoo oder Bing) suchen und direkt Ihr aktuelles Rating beurteilen.

Search Engines:

Hier erhalten Sie per Klick von drei Suchmaschinen (Google, Yahoo und Bing) eine Liste an Seiten, welche auf die aktuelle Seite verlinken. Da die Anzahl an „incoming Links“ Einfluss auf Ihr Ranking hat, ist die Wichtigkeit dessen nicht zu unterschätzen.

Headings:

In diesem Register werden alle Überschriften der aktuellen Seiten aufgelistet. So können Sie auf einen Blick den Inhalt aktueller Headlines überprüfen und gegebenfalls optimieren, um die Relevanz für Suchmaschinen zu erhöhen. Mittels Klick auf die jeweilige Überschrift gelangen Sie direkt zur dementsprechenden Überschrift.

Images:

Im Bezug auf SEO ist nicht das Bild entscheidend, sondern vielmehr der Alternativtext für Suchmaschinen. Deshalb werden in diesem Register alle Bilder mit Alternativtext, URL und Grösse aufgelistet. Jene Bilder welche keinen Alternativtext enthalten werden zuerst gelistet. Mittels Klick gelangen Sie auch hier direkt zum Bild, um den Alternativtext zu pflegen.

Links:

Hier werden alle Links der aktuellen Seite gelistet. Das Toolkit legt hierbei besonderen Wert auf die Funktionsweise der Links. Alle „broken links“ werden auch hier als Erstes aufgelistet.

Meta Tags:

Hier werden die Meta Tag Informationen der jeweiligen Seite aufgelistet. Diese enthalten unter anderem die Description, Keywords und Copyright Informationen. Besonderen Wert sollte auf die Pflege der „keyword meta tags“ gelegt werden, da diese von der Suchmaschine zur Beurteilung der Relevanz der Seite herangezogen werden.

Mit dem einem durchdachten Konzept, dessen konsequenter Umsetzung und der Unterstützung des SEO Toolkits von Sitecore  sind die wichtigsten Voraussetzungen für eine wirksame SEO gegeben.

Multi Device Simulation.

Single Device war gestern – Multi Device ist heute

Im Zeitalter der Multi Devices ist es schlichtweg fast unmöglich Webseiten nur noch auf ein einziges Device zu optimieren. So stellt sich auch für viele Content Autoren immer häufiger die Frage: „Wie sieht die aktuelle Seite denn auf Smartphone, Tablet oder TV aus?“

Das Ende 2012 gelaunchte Sitecore 6.6 bietet hierfür einen Device Simulator. Autoren können somit im Page Editor im Register „Experience“ das entsprechende Device auswählen und die Simulation durchführen. Das Ergebnis des jeweiligen Devices ist zwar nicht pixelgenau, dennoch gibt es einen guten ersten Eindruck, wie sich die Seite auf dem jeweiligen mobilen Gerät verhält. Die Simulation ermöglicht es auch durch die ganze Webseite zu navigieren, zu scrollen (vertikal und horizontal) und das Device zu drehen.

Sitecore Device Simulator

Ein Schritt in die Zukunft. Wir unterstützen Sie gerne.

Sitecore ajaxified – Die Favoritenliste

In einem aktuellen Projekt wollten wir dem (anonymen) Nutzer die Möglichkeit geben einzelne Produkte in eine Favoritenliste abspeichern zu können um diese bei einem späteren Besuch der Webseite wieder abrufen zu können. Das Ganze sollte möglichst ohne reload der Seite realisiert werden.

Mithilfe von .Net 4.0 und jQuery lassen sich ohne großen Aufwand Ajax Funktionalitäten für Sitecore Webseiten umsetzen.

Dazu benötigen wir drei Dinge:

  1. Cookie handling
  2. Einen Sitecore Service
  3. Javascript

Im folgenden Abschnitt wird eine beispielhafte Implementierung der Favoritenliste vorgestellt.

Die Favorites Klasse stellt uns Funktionen zur Verfügung, die uns vereinfachten Zugriff auf die vom HttpContext übergebenen Cookies liefert, bzw. die manipulierten Cookies zurück an den Nutzer liefert.

namespace Namics.Internet.Core
{
    using System.Collections.Generic;
    using Sitecore.Data;
    using System.Web;
    using System.Linq;
    using Sitecore.Data.Items;
 
    public static class Favorites
    {
        private const string FAVORITE_COOKIE_STRING = "FAVORITE_COOKIE";

        private static HttpCookie FavoriteCookie
        {
            get
            {
                if (HttpContext.Current.Request.Cookies[FAVORITE_COOKIE_STRING] == null)
                {
                    HttpContext.Current.Request.Cookies.Add(new HttpCookie(FAVORITE_COOKIE_STRING));
                }

                return HttpContext.Current.Request.Cookies[FAVORITE_COOKIE_STRING];
            }
        }

        public static void Add(Item pItm)
        {
            FavoriteCookie.Values.Add(pItm.ID.ToString(), string.Empty);
            Update();            
        }

        public static void Remove(Item pItm)
        {
            FavoriteCookie.Values.Remove(pItm.ID.ToString());  
            Update();      
        }

        public static void Clear()
        {
            FavoriteCookie.Values.Clear();
            Update();
        }

        public static IEnumerable<Item> GetAll()
        {
            return FavoriteCookie.Values.AllKeys.Select(key => Sitecore.Context.Database.GetItem(ID.Parse(key)));
        }

        private static void Update()
        {
            HttpContext.Current.Response.Cookies.Add(FavoriteCookie);
        }
    }
}

 

Ein Sitecore Service soll nun die Funktionen der Favorites Klasse dem Javascript Client zur Verfügung stellen.
Durch die Einfachheit des Services und nicht für die Öffentlichkeit bestimmten Verwendung der API konnten wir das im .Net 4.0 eingeführte ExpandoObject verwenden um den Code kurz zu halten (und uns z.B. das Schreiben einer serialisierbaren Klasse zu sparen).

namespace Namics.Internet.Core.Handlers
{
    using System.Dynamic;
    using System.Web;
    using Newtonsoft.Json;
    using Sitecore.Data;
    using System.Linq;
   
    public class FavoritesServiceHandler : IHttpHandler
    {
        public bool IsReusable
        {
            get { return true; }
        }

        public void ProcessRequest(HttpContext pContext)
        {
            pContext.Response.ContentType = "application/json";
            dynamic response = new ExpandoObject();

            var command = HttpContext.Current.Request.QueryString["cmd"];
            var idStr = HttpContext.Current.Request.QueryString["id"];        

            if (!string.IsNullOrEmpty(idStr))
            {
                var item = Sitecore.Context.Database.GetItem(ID.Parse(idStr));

                switch (command)
                {
                    case "add":
                        Favorites.Add(item);
                        break;
                    case "remove":
                        Favorites.Remove(item);
                        break;
                }
            }
            else
            {
                switch (command)
                {
                    case "clear":
                        Favorites.Clear();                      
                        break;
                    case "get":
                        response.Result = Favorites.GetAll().ToList();                      
                        break;
                }
            }
           
            response.Success = true;
            pContext.Response.Write(JsonConvert.SerializeObject(response));
        }
    }
}

 

Den Service müssen wir in der Sitecore.config und der Web.config noch wie folgt registrieren.

In der Sitecore.config im Abschnitt

 <customHandlers> 

fügen wir diese Zeile hinzu:

<handler trigger="~/service/favorites" handler="FavoritesServiceHandler.ashx"/> 

und in der Web.config im Abschnitt

 <httpHandlers>
<add verb="*" path="FavoritesServiceHandler.ashx" type="Namics.Internet.Core.Handlers.FavoritesServiceHandler, Namics.Internet.Core" />

 

Nun fehlt noch der Clientseitige Teil, der mit jQuery in wenigen Zeilen umgesetzt werden kann.

$('#clear').bind("click", function () {
 $.ajax({
   url: 'http://mywebsite/service/favorites?cmd=clear',
   success: function (data) {
    if (data.Success) {
     alert("Gelöscht!");
    }
   }
 });
});

 

So konnte die gewünschte Funktionalität in wenigen Schritten und ohne grösseren Aufwand in Sitecore umgesetzt werden.

Teasermanagement auf Basis einer automatisierten Besucherqualifikation

Wäre es nicht besucherfreundlich, wenn die besuchte Website individuell auf den User reagieren würde? Eine einfacher Weg, dies zu realisieren stellt das automatisierte Teasermanagement von Sitecore dar. Es ermöglicht, unterschiedlichen Inhalt in definierten Seitenbereichen anzuzeigen.  Beispielsweise in Abhängigkeit der Tageszeit. Ein zugehöriger Anwendungsfall wäre eine Website, die sich den Servicezeiten des zugehörigen Kundendienstes anpasst. So würde tagsüber an Werktagen eine Servicetelefonnummer angezeigt und in der restlichen Zeit lediglich ein E-Mail-Kontakt angeboten.

Eine andere Variante des Teasermanagements ist, den Standort des Users abzufragen und in Abhängigkeit des ermittelten Standorts z.B. die nächstgelegenen Filialen anzuzeigen.

Eine weitere, sehr interessante Variante des Teasermanagement ist eine Qualifizierung und ein anschliessendes Targeting mit Hilfe der Sitecore Digital Marketing Suite.

Im ersten Schritt können beispielsweise Interessenten für ein bestimmtes Produkt vorqualifiziert werden. Der Ablauf könnte sich wie folgt darstellen:

  • Der User klickt durch das Angebot „Kaffee“ und innerhalb des Kaffee-Angebots nur auf die hochwertigsten Kaffeeröstungen.
  • Für die Aktionen können dem User im System vorher festgelegte Scores vergeben werden, die der Zuordnung zu vorher definierten Zielgruppen dienen. Er erhält beispielsweise für den Klick auf „Kaffee“ zwei Scoring-Punkte für die Zielgruppe „Kaffeeliebhaber“. Durch jeden weiteren Klick auf die hochwertigen Sorten erhält er weitere Scoring-Punkte. Hat er so in der Kategorie „Kaffee“ z.B. zehn Punkte gesammelt, wird ihn das System  als möglichen Kaffeeliebhaber qualifizieren.
  • Sitecore kann insofern auf das Scoring reagieren, als dass dem Kaffeeliebhaber spezielle Sonderangebote direkt auf der Startseite (oder jeder beliebigen Seite) in einem definierten Content-Bereich angezeigt werden.
  • Besucht der User die Website das nächste Mal, wird er über ein Cookie identifiziert und wieder als Kaffeeliebhaber erkannt.

Beispiel einer ortsabhängigen Teaserschaltung

Das automatisierte Teasermanagement von Sitecore ermöglicht es, die Besucherrelevanz der angezeigten Webseiten zu erhöhen und leistet damit einen Beitrag zur Steigerung der Besucherzufriedenheit.

Seite 5 von 512345