Grosse Sitecore Solutions in wartbare Module herunterbrechen

In diesem Artikel möchten wir (Matthias Gmür und Mark Lowe) ein Thema beleuchten, welches uns in den letzten Jahren bei einigen unserer Kunden beschäftigt hat: Die Architektur von grossen Sitecore Solutions.

(mehr …)

HTML-Seiten via Media Library bereitstellen

Meistens wird die Sitecore Media Library genutzt um Bilder und Dateien, wie PDFs, für den eigenen Webauftritt zu speichern und einzubinden, beziehungsweise zum Downloaden zu verlinken. Allerdings gehen die Möglichkeiten mit der Media Library noch viel weiter – hat man denn Bedarf daran.

In diesem Artikel wird erläutert, wie statische HTML-Seiten inklusive JavaScript und CSS über die Sitecore Media Library eingebunden und bereitgestellt werden können. Und das tolle daran: genau wie andere Items und Dateien lässt sich der Zugriff über die Sitecore Berechtigungen ganz genau festlegen – damit auch nur wirklich das von Ihnen gewünschte Zielpublikum darauf zugreifen kann!

Aus diesem Beispiel lassen sich natürlich auch weitere Use Cases ableiten, zum Beispiel wenn im Webauftritt ein Flashplayer integriert werden soll und die dazugehörigen Flashfilme (.flv Dateien) in der Media Library abgespeichert werden.

(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.

 

Starter Paket für Sitecore Entwickler

In der Präsentation wird vermittelt, was Sitecore Software Engineers grundlegendes über das CMS wissen sollten, um mit der Entwicklung zu starten.

Nachfolgende Themen werden behandelt:

  • Einrichten
  • Authoring
  • Development
  • Deployment
  • Ressourcen

Haben wir Dein Interesse geweckt für die Sitecore CMS-Entwicklung? Namics hat fortlaufend spannende Stellen im .NET Umfeld in der Schweiz und Deutschland zu besetzen. Wir freuen uns auf Deine Bewerbung!

Urwald der Konfigurationen

Wie bereits in unserem Blog-Eintrag Sitecore Web.Config aufteilen beschrieben, ist es möglich die Konfiguration der Sitecore Solution in logisch-trennbare Dateien zu splitten. Dies verbessert zum einen den Überblick massiv und vereinfacht das Austauschen von einzelnen Konfigurations-Bereiche.

Neben der eigentlichen Web.Config und deren Bestandteile, besitzt Sitecore jedoch eine grosse Menge an weiteren Konfigurationsdateien. Im App_Config Verzeichnis verstecken sich nur schon in einer leeren Sitecore-Solution viele weitere Konfigurationsdateien. Zu all dem kann man als Entwickler relativ einfach und schnell, weitere Config’s erzeugen, welche es später dem Administrator der Webseite erlaubt – im vordefinierten Rahmen – die Lösung an die gewünschten Bedürfnisse anzupassen.

Nun ist es jedoch so, dass wir selten direkt auf der schlussendlichen Zielplattform entwickeln und bei jedem Speichern/Kompilieren dies direkt live haben wollen. So entstehen pro Plattform verschiedene Konfigurationen. Als Entwickler möchte ich beispielsweise alle Debug-Informationen im Log, ein visuelles Tracing auf der Dev-Webseite oder eine andere Ansicht für gewisse Informationen haben, welche spätestens in der Live-Webseite nicht mehr erscheinen sollten. Je nach Kritikalität des Projektes gibt es da noch Testing-, Quality-, Content-Plattformen dazwischen. All diese Umgebungen benötigen unter umständen verschiedene Einstellungen.

Damit dies nicht zu einem unübersichtlichem Urwald führt und bei jedem Deployment darauf geachtet werden muss, welche Configs überschrieben, angepasst oder gelöscht werden müssen, haben wir einen kleinen, simplen Skript dazu geschrieben:

 

@ECHO off

REM Title:          Set Environment Configuration

REM Description:    Recursively replaces all master files with the specific environment
REM                 files for a given suffix, starting at the defined path or the default
REM                 path if none given. The format for each environment file has to be as
REM                 follows: myfilename.config_SUFFIX, ex. sitecore.config_Q
REM Parameters:     %1 Environment Suffix, ex. Q (required)
REM                 %2 Start Path, ex. "C:\My Directory" (optional)
REM Example:        set_env_config.bat Q "C:\My Directory"

SETLOCAL ENABLEDELAYEDEXPANSION

ECHO.

REM Error handling - check parameters

IF (%1)==() (
    ECHO Parameter environment suffix missing, ex. Q
    GOTO END
)

IF NOT (%2)==() (
    IF NOT EXIST "%~2" (
        ECHO Specified path not found, check if the directory exists and make sure to use quotes, ex. "C:\My Directory"
        GOTO END
    )
)

REM Looks recursively for files following the pattern *.config_SUFFIX, starting at the

REM specified path or the default path if none given
FOR /r %2 %%f IN (*.config_*%1*) DO (
    REM environment path (with filename) and file
    SET env_path=%%f
    SET env_file=%%~nxf
    REM replace _SUFFIX in specific environment file to get the original filename
    SET orig_path=!env_path:_% class="re2">1=%!
    REM copy and override the env file with the original one without confirmation
    xcopy "!env_path!" "!orig_path!" /Y
    REM check for errors after copy
    IF errorlevel 0 (
        ECHO -- Successfully copied file !env_file! to !orig_path!
    ) ELSE (
        ECHO -- Error while copying file !env_file! to !orig_path!
    )
    ECHO.
)

:END
REM PAUSE
REM EXIT

 

Dieses Script ersetzt also alle Config-Dateien mit einem bestimmten Dateinamen-Suffix.

So kann ich beispielsweise für die ConnectionsStrings, pro Umgebung eine Konfiguration vorbereiten:

  • ConnectionString.config_DEV
  • ConnectionString.config_TEST
  • ConnectionString.config_QUALITY
  • ConnectionString.config_LIVE

Im Deployment-Prozess kann ich dann lediglich das Batchfile ausführen & meine Umgebung ist bereits richtig konfiguriert:

D:\inetpup\myWebsite\SetEnvironmentConfig.bat QUALITY

 

Dies durchsucht nun alle Config-Dateien (ab Batch-Standort & Subfolder) und ersetzt alle bestehenden Konfigurationen mit den Quality-Einstellungen.