Welche Möglichkeiten bietet Sitecore externe Daten zu integrieren?

Tipp der Woche

Die einfachste Integration von externen Daten ist via Link oder iFrame. Darüber hinaus bietet Sitecore zahlreiche Möglichkeiten Verbindungen zu Datenbanken, Web-Services oder anderen externen Services einschliesslich SharePoint herzustellen. Der Enterprise Integration Layer ermöglicht es, externe Daten in Sitecore einzubinden als wären es Sitecore Inhalte.

Hilfreich in diesem Zusammenhang sind auch die „Shared Source Module“, welche auf dem Opensource Gedanke basieren. Alle Module werden vor der Publikation durch Sitecore geprüft und können jetzt neu unter Sitecore Marketplace (http://marketplace.sitecore.net) heruntergeladen werden. Hier finden Sie unter anderem Module für Youtube Integration, Data Import oder die Anbindungen an SQL / XML Datenbanken. Weiters wurden auch spezielle Module für Multimedia Inhalte entwickelt.

Hier
finden Sie einen Überblick (aus technischer Perspektive) über die Integration von externen Daten mit Sitecore

Vereinfachen Sie Ihren Verwaltungsaufwand und integrieren Sie Ihre bestehenden Systeme in ein Sitecore CMS!

Sitecore Architektur-Varianten

Nach der Entscheidung, ein neues  Content Management System einzuführen, stellt sich früher oder später die Frage, welche Netzwerk-Architektur Verwendung finden soll. Die Entscheidungsgrundlage für die Auswahl der Architektur-Variante ist insbesondere:

  • die Anforderung an die Verfügbarkeit des Systems
  • die Anforderung an die Laststabilität des Systems
  • die Anforderung an die Sicherheit des Systems
  • die bereits bestehende Infrastruktur
  • das zur Verfügung stehende Budget

Nachfolgend werden mögliche Sitecore Netzwerk-Architekturen für verschiedene Internet Szenarien vorgestellt und deren Vorteile und Nachteile kurz beleuchtet.

Eine Sitecore Netzwerk-Architektur besteht aus mehreren Komponenten: dem sogenannten Content Management Server (nachfolgend CM genannt), der primär für die Erfassung von Content für die Autoren dient und dem Content Delivery Server (nachfolgend CD genannt), der als sogenannter Front-End Server fungiert. Weiterhin erforderlich ist ein SQL Server, der den Content sowie die Konfigurationseinstellungen beinhaltet. Der SQL-Server enthält dafür drei Sitecore Datenbanken: Master, Web und Core. Der Content wird in der Master-Datenbank verwaltet und im Rahmen des Veröffentlichungsprozesses auf die Web-Datenbank transferiert. Die Core-Datenbank beinhaltet die Sitecore Einstellungen sowie die Security Informationen von Sitecore.

Stand-Alone-Architektur

Hierbei übernimmt ein einzelner Server sowohl die Funktion des CM als auch des CD.

Vorteile dieser Architektur:

  • Einfache Installation und Administration
  • Keine Load-Balancer Konfiguration notwendig
  • Schnelle Inbetriebnahme möglich

Nachteile dieser Architektur:

  • Aus Gründen der Performance sollte CM und CD nicht zusammen auf einem Server installiert werden. Denn sobald die Autoren ihre erstellten Seiten veröffentlichen, wird der Server für einen kurzen Moment ausgelastet. Dies könnte die Performance des Internet Auftritts beeinträchtigen.
  • Sollte der Server ausfallen, ist die Erreichbarkeit des Internet-Auftritts nicht mehr gewährleistet.
  • Beim Veröffentlichen von Seiten durch die Autoren wird zudem der Cache geleert, dies bedingt eine längere Ladezeit der Webseiten beim erstmaligen Aufruf nach der Veröffentlichung.

Netzwerk-Architektur mit separatem CM und CD

Diese Architekturvariante sieht jeweils einen separaten Server für CM und CD vor:

Vorteile dieser Architektur:

  • Autoren greifen auf einen dedizierten CM Server zu und belasten somit nicht den CD Server. Der Veröffentlichungsprozess beeinträchtigt die Performance der Website nicht.
  • Der Cache wird durch den Veröffentlichungsprozess nur inkrementell geleert. Damit bleiben kurze Ladezeiten für den übrigen Internet-Auftritt gewährleistet.
  • Bei einem Ausfall des CM kann der CD kurzzeitig die Aufgaben des CM übernehmen. Der Internet-Auftritt bleibt also weiterhin kontrollierbar. Allerdings gelten die Einschränkungen eines Stand-Alone-Systems.

Nachteile dieser Architektur:

  • Bei einem Ausfall des CD ist der Internet-Auftritt für Besucher nicht mehr erreichbar.

Netzwerk-Architektur  mit einer durch eine Firewall getrennten CM und CD Umgebung

Bei dieser System-Architektur liegt das Augenmerk auf der Sicherheit des Systems. Dazu werden die CD und die CM Server durch eine Firewall getrennt. Der CD und der SQL-Server (Database1) befinden sich in der DMZ und der CM und der SQL-Server (Database2) im LAN.

Vorteile dieser Architektur:

  • Der CM ist nicht von aussen zugänglich und wird durch eine Firewall geschützt.
  • Der CD verfügt über einen eigenen SQL-Server. Dies dient der Optimierung der Performance.
  • Bei einem Ausfall des CM kann der CD kurzzeitig die Aufgaben des CM übernehmen. Der Internet-Auftritt bleibt also weiterhin kontrollierbar. Allerdings gelten die Einschränkungen eines Stand-Alone-Systems.

Nachteile dieser Architektur:

  • Bei Ausfall des CD können die Benutzer auch hier nicht auf den Internet Auftritt zugreifen.

Architektur mit zwei CD und Load-Balancing (Hochverfügbarkeit)

Diese Sitecore Architektur gewährleistet sowohl eine hohe Verfügbarkeit als auch eine hohe Sicherheit. Dabei befinden sich zwei CD Server mit Load-Balancer sowie der SQL-Server (Database 1) in der DMZ. CM-Server und SQL-Server (Database 2) befinden sich im LAN.

Vorteile dieser Architektur:

  • Der CM ist von aussen nicht zugänglich und wird durch eine Firewall geschützt.
  • Der CD verfügt über einen eigenen SQL-Server. Dies dient der Optimierung der Performance.
  • Die beiden CD gewährleisten eine hohe Verfügbarkeit, da bei dem Ausfall eines CD der andere noch von aussen erreichbar bleibt und somit die Verfügbarkeit des Internet-Auftritts weiterhin gewährleistet.
  • Bei einem Ausfall des CM kann einer der CD kurzzeitig die Aufgaben des CM übernehmen. Der Internet-Auftritt bleibt also weiterhin kontrollierbar.

Nachteile dieser Architektur:

  • Variante erfordert mehr Aufwand für die Konfiguration.
  • Diese Lösung stellt umfangreichere Hardware-Anforderungen als die vorgenannten Varianten.

Fazit und Empfehlung

Nachdem nun mehrere mögliche Sitecore Architekturen mitsamt ihren Vor- und Nachteilen vorgestellt wurden, wird deutlich, dass das Aussprechen einer generellen Empfehlung nicht sehr sinnvoll ist. Vielmehr hängt die Auswahl der geeigneten Architektur-Variante sehr stark von den individuellen Anforderungen an das System und der verfügbaren Infrastruktur ab. Allerdings kann festgehalten werden, dass zum einen der gemeinsame Betrieb von CM und CD auf einem Server aufgrund der hohen Lastspitzen im Veröffentlichungsprozess nicht empfehlenswert ist und zum anderen der Einsatz von einem CM-Server und mehreren CD-Servern mit Load-Balancing eine nahezu beliebige Skalierbarkeit und Performance sowie eine enorme Flexibilität des Systems ermöglichen.

 

Der Namics Sitecore Showcase

 

Ich habe mir vor längerer Zeit, als ich in unserem Sitecore Team angefangen habe, ein Projekt geschnappt, welches mir helfen sollte Sitecore kennen zu lernen.

Vorstellungen und Aufbau

Ziel des Projektes war, eine saubere und gut funktionierende Demo-Umgebung von Sitecore zur Verfügung zu haben. Schlussendlich sollte die Lösung aus einem Blog bestehen, den man auch mit anderen Modulen oder Features erweitern könnte.

Der Blog sollte in verschiedene Kategorien eingeteilt werden können. Vom Design her sollte er ähnlich wie die übrigen Namics-Seiten aufgebaut sein. Ebenfalls sollte er vollständig über den Sitecore Page-Editor bedienbar sein.

In einem weiteren Release sollte aus der Lösung eine Multisite entstehen und mehrere Sprachen integriert werden.

Der Showcase besteht aus drei verschiedenen Seitentypen. Diese sind die Übersichtsseite, die Kategorie Übersicht und der Blogeintrag. Das Frontend wurde mit Terrific umgesetzt. Im Sitecore-Backend habe ich versucht eine möglichst logische Struktur zu erstellen.

JSON Service

Ich wollte für den Blog unbedingt auch eine dynamische Wortmarke haben. Dazu habe ich mir das Terrific-Modul von einem anderen Projekt kopiert und es dann integriert. Damit wurden jedoch die Wörter direkt in das JavaScript File hineingeschrieben. Damit ich dies im Backend steuern konnte, habe ich einen JSON-Service erstellt.

Auf einem Sitecore-Item habe ein einfaches Textfeld erstellt, in dem ich alle Tags definieren konnte. Im Service habe ich dann die Wörter ausgelesen und in einen Array gespeichert. Zusätzlich habe ich einen Counter erstellt, mit dem ich festlegen kann ,wie viele Wörter angezeigt werden sollen. Weiterhin wird der Array wird noch zufällig sortiert und immer die ersten Wörter (Counter) des Arrays an ein JavaScript zurückgegeben.

Fazit

Ich habe es geschafft, mich mit diesem Projekt näher an die .NET Technologien und Sitecore heran zu arbeiten. Diese Arbeit hat mein Interesse für die Backend-Entwicklung ebenfalls gestärkt. In der nächsten Zeit soll der Blog so erweitert werden, dass dieser möglichst viele Funktionen von Sitecore wird beinhalten können.

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!

Broken Links? Wie entdecke ich sie vor den Kunden?

Tipp der Woche

Mit einem einfachen Rechtsklick (links neben der Seitenstruktur) können Sie die Anzeige von „Broken Links“ aktivieren. So werden alle Seiten bzw. Items, welche „Broken Links“ enthalten, mit einem „gebrochenen Link-Symbol“ gekennzeichnet.
Broken Links Anzeige aktivieren
Weiters besteht die Möglichkeit einen „Broken Link Report“ zu integrieren, bei welchem Sie auf einen Blick alle „Broken Links“ einsehen und diese z.B. in eine Excel-Datei exportieren können.

Wie kann ich das Entstehen von „Broken Links“ vermeiden?

Mit dem Real-Time Link-Handler von Sitecore vermeiden Sie grundsätzlich die Entstehung von Broken Links.  Dieser ermöglicht, dass die Links immer aktuell gehalten werden und die Seitenkonsistenz erhalten wird. So werden sie bereits beim Löschen oder Verschieben von Seiten und Items auf bestehende Verlinkungen hingewiesen und können direkt bestimmen, ob diese neu verlinkt, gelöscht oder „broken“ sein sollen. Häufige Ursache für „Broken Links“ ist neben der Verschiebung und Löschung von Inhalten auch die Verlinkung auf unpublished Seiten oder Items.

Kontrollieren Sie regelmässig Ihre Broken Links und treffen Sie vorbeugende Massnahmen. Ein überschaubarer Zeitaufwand für Sie  – ein grosser Gewinn für Ihre Kunden.

Type Safe Programming mit Sitecore

Das Ablegen der strukturierten Inhalte in Sitecore erfolgt in vordefinierten Templates. Die Items speichern die nach dem zugeordneten Template strukturierten Informationen ab, welche anschliessend für das Rendern der Webseite verwendet werden können.

Problematik

Im Sitecore Backend wird diese Struktur/Templates für das Editieren der Informationen herangezogen. Dem Programmierer bleibt die Struktur der Templates während der Design Time (Entwicklung) immer verwehrt. Erst zur Runtime sind diese Informationen verfügbar. Dies führt dazu, dass beim kompilieren keine Validierung des Zugriffes auf die Daten erfolgen kann, was z.B. beim Umbenennen oder Typenändern eines Feldes nicht sofort zu einer Exception führt. Weiter muss der Entwickler immer den jeweiligen Feldnamen und Typen kennen/nachschlagen.

Lösung

Extrahieren der gesamten Sitecore Template Struktur zur Entwicklungszeit ins Visual Studio. Dabei gibt es unterschiedliche Varianten wie dies erfolgen kann:

Methode Beschreibung Vorteile Nachteile
dynamic Mit .Net 3.0 wurden dynamische Objekte eingeführt die erst zur Runtime bestimmt werden.
  • sehr einfache Implementation
  • Kein Intellisense zur Design Time
  • Keine Validierung zum Kompilierzeitpunkt
F# Typeprovider F# bietet die Möglichkeit beim Kompilieren dynamisch statische Typen aus externen definitionen zu erstellen
  • F# Klassen lassen sich nahtlos in C# verwenden
  • Voller Funktionsumfang
  • Automatisches Update bei Änderungen
  • Intellisense nur in F# vorhanden
T4 Templates Mittels T4 Templates werden zur Design Time statische Klassen generiert, welche den Zugriff auf die Sitecore Items stark typisiert wrappen
  • Intellisense
  • Validierung zum Kompilierzeitpunkt
  • Manuelles Anstossen des Generiervorganges bei Änderungen (könnte durch PreBuild Action erfolgen)
Project Roslyn Spracherweiterung für C# welche zur Design und Runtime den Zugriff auf die Item Definition in Sitecore sicherstellt
  • Optimale Integration
  • Änderungen im Sitecore sind sofort erkennbar
  • LINQ Funktionalität
  • Sehr komplex
Wir haben uns für die T4 Template Lösung entschieden, da alle aktuellen Codegerneratoren im Visualstudio darauf basieren und es sich um eine bewährte Technologie handelt (Microsoft Entity Framework, SOAP, usw). Um den Zugriff auf Sitecore stark zu kapseln wurden für alle Standardfeldtypen aus Sitecore Helperklassen erstellt die z.B. den Zugriff auf die Url direkt über ein Property möglich machen.

Sitecore Template

Generiertes Interface

Datenzugriff (Razor)

Durch die weitere Integration von Razor als Render Engine kann nun stark typisiert sauberer Render-Code erstellt werden und gänzlich auf den Stringbuilder und dergleichen verzichtet werden.

Durch den Aufbau dieser beiden Verbesserungen konnte das Entwickeln/Debuggen mit Sitecore massiv verbessert und beschleunigt werden.

Dynamische Sitemaps

Eine XML-Sitemap ist eine klassische Datei, welche nahezu jede Seite besitzen soll. Da wir unter der Haube ein modernes CMS haben, wollen wir hierbei natürlich auch eine automatisch generierte Sitemap-XML haben. Unsere Sitemap soll jedoch nicht blind, alle Content-Items in ihren Index packen, sondern auch je nach Fall entscheiden können, diese draussen zu lassen.

Damit dies in Sitecore möglich ist, erstellen wir hierfür einen gewöhnlichen ASPX-Handler, welcher sich gegen aussen als www.mywebsite.ch/sitemap.xml outet.

  1. Wir erzeugen also in unserer Solution einen Handler (Add new item…) und geben ihm den Namen sitemapxml_handler.ashx
  2. Wir erstellen eine für uns optimale XML-Sitemap. Hier ein mögliches Beispiel:
    // --------------------------------------------------------------------------------------------------------------------
    // <copyright file="SitemapXmlHandler.cs" company="Namics AG">
    //   (c) Namics AG
    // </copyright>
    // <summary>
    //   The sitemap xml handler.
    // </summary>
    // --------------------------------------------------------------------------------------------------------------------

    namespace Namics.Samples.WebApp.Services
    {
        using System;
        using System.Web;
        using System.Xml;
        using Namics.Framework.Sitecore.Core.Utils;

        using Sitecore.Configuration;
        using Sitecore.Data;
        using Sitecore.Data.Items;
        using Sitecore.Diagnostics;
        using Sitecore.Links;

        /// <summary>
        /// The sitemap xml handler.
        /// </summary>
        public class SitemapXmlHandler : IHttpHandler
        {
            #region Public Properties

            /// <summary>
            /// Gets a value indicating whether IsReusable.
            /// </summary>
            public bool IsReusable
            {
                get
                {
                    return true;
                }
            }

            #endregion

            #region Public Methods and Operators

            /// <summary>
            /// The process request.
            /// </summary>
            /// <param name="pContext">
            /// The context.
            /// </param>
            public void ProcessRequest(HttpContext pContext)
            {
                try
                {
                    pContext.Response.ContentType = "text/xml";
                    pContext.Response.StatusCode = 200;
                   
                    XmlDocument xmlDoc = new XmlDocument();
                    XmlDeclaration xmlDeclaration = xmlDoc.CreateXmlDeclaration("1.0", "utf-8", null);

                    XmlElement rootNode = xmlDoc.CreateElement("urlset");
                    rootNode.SetAttribute("xmlns", "http://www.sitemaps.org/schemas/sitemap/0.9");
                    xmlDoc.InsertBefore(xmlDeclaration, xmlDoc.DocumentElement);
                    xmlDoc.AppendChild(rootNode);

                    string databaseName = Settings.GetSetting("Sitemap.Database");
                    string startItemPath = Settings.GetSetting("Sitemap.StartItemPath");
                    Database database = Factory.GetDatabase(databaseName);
                    UrlOptions urlOptions = UrlOptions.DefaultOptions;
                    urlOptions.AlwaysIncludeServerUrl = true;

                    Item item = database.GetItem(startItemPath);
                    AddUrlEntry(item, xmlDoc, rootNode, urlOptions);
                   
                    pContext.Response.Write(xmlDoc.OuterXml);
                }
                catch (Exception ex)
                {
                    Log.Error("Error at sitemap xml handler.", ex, this);
                    pContext.Response.StatusCode = 500;
                }
            }

            #endregion

            #region Methods

            /// <summary>
            /// The add url entry.
            /// </summary>
            /// <param name="pItem">
            /// The item.
            /// </param>
            /// <param name="pXmlDoc">
            /// The xml doc.
            /// </param>
            /// <param name="pRootNode">
            /// The root node.
            /// </param>
            /// <param name="pUrlOptions">
            /// The url options.
            /// </param>
            private void AddUrlEntry(
                Item pItem, XmlDocument pXmlDoc, XmlElement pRootNode, UrlOptions pUrlOptions)
            {
                if (pItem != null && pItem.Visualization != null && pItem.Visualization.Layout != null && pItem.Name != "*")
                {
                    if (!pItem.Fields.Contains(FieldNames.GetFieldId(FieldNames.EXCLUDEFROMSITEMAP))
                        || pItem.Fields[FieldNames.EXCLUDEFROMSITEMAP].Value != "1")
                    {
                        string url = LinkManager.GetItemUrl(pItem, pUrlOptions);
                        GenerateUrlEntry(pXmlDoc, pRootNode, url);
                    }
                }

                if (pItem != null)
                {
                    foreach (Item childItem in pItem.Children)
                    {
                        AddUrlEntry(childItem, pXmlDoc, pRootNode, pUrlOptions);
                    }
                }
            }

            /// <summary>
            /// The generate url entry.
            /// </summary>
            /// <param name="pXmlDoc">
            /// The xml doc.
            /// </param>
            /// <param name="pRootNode">
            /// The root node.
            /// </param>
            /// <param name="pUrl">
            /// The url.
            /// </param>
            private void GenerateUrlEntry(XmlDocument pXmlDoc, XmlElement pRootNode, string pUrl)
            {
                XmlElement sitemapNode = pXmlDoc.CreateElement("url");
                pRootNode.AppendChild(sitemapNode);

                XmlElement locationNode = pXmlDoc.CreateElement("loc");
                locationNode.AppendChild(pXmlDoc.CreateTextNode(pUrl));
                sitemapNode.AppendChild(locationNode);

                XmlElement changeFrequencyNode = pXmlDoc.CreateElement("changefreq");
                changeFrequencyNode.AppendChild(pXmlDoc.CreateTextNode("weekly"));
                sitemapNode.AppendChild(changeFrequencyNode);
            }

            #endregion
        }
    }
  3. Wir registrieren unseren Handler in der Web.Config unter der Rubrik Handlers:
    <add verb="*" path="sitemapxml_handler.ashx" type="Namics.Samples.WebApp.Services.SitemapXmlHandler, Namics.Samples.WebApp" name="Namics.SitemapXmlHandler" />
  4. Wir registrieren unseren Handler in Sitecore (ebenfalls Web.Config) unter der Rubrik „CustomHandlers“ und geben ihm unseren gewünschten Namen:
    <handler trigger="/sitemap.xml" handler="sitemapxml_handler.ashx" />
  5. Wie im C-Sharp Code ersichtlich, prüfen wir noch, ob ein Item aus der Sitemap excluded werden soll. Hierfür erstellen wir auf dem entsprechenden Page-Template ein Checkbox-Field, welches „Excluded from Sitemap“ lautet und demzufolge für die Steuerung zuständig ist.

Als Resultat haben wir eine vollfunktionsfähige sitemap.xml auf unserer WebPage.

Wie kann ich die Laufzeit von Inhalten begrenzen?

Tipp der Woche

Haben Sie Inhalte (z.b. Rabatt-Aktionen, Mittagsmenüs etc.), welche nur über eine bestimmte Laufzeit gültig sind? Wollen Sie den laufenden Veröffentlichungsaufwand verringern?

Mit der Lifetime-Funktionalität von Sitecore können Sie dies ganz einfach tun. Diese ermöglicht eine zeitgesteuerte Veröffentlichungen von Inhalten. So können Sie die Inhalte ganz einfach im Voraus erfassen und mittels „Valid from“ und „Valid to“ bestimmen wann diese  online bzw. offline gesetzt werden sollen.

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.

Sitecore Intranet Portal (SIP) Teil 3

In den Post’s Intranet Portal (SIP) Teil 1 und Teil 2 haben wir die Möglichkeiten der Intranet Lösung von Sitecore vorgestellt. Nachfolgend fassen wir die Stärken und Schwächen der vorgefertigten Lösung zusammen:

Sitecore Intranet Portal (SIP) bietet

  • Diverse OOB Features, die typische Use Cases der Intranetnutzung abdecken, z.B.: AD Anbindung, Telefonbuch, Kalender, Organigramm,  Umfragen, Forum/Marktplatz, Workflows, Versionierung, Blogs, etc.
  • Viele Konfigurationsmöglichkeiten für Autoren
  • Attraktive Lizenzkosten
  • Mehrsprachigkeit
  • Anbindung/Integration von SharePoint

Sitecore Intranet Portal (SIP) hat Schwierigkeiten mit

  • Erweiterungen der OOB Komponenten, da das SIP in erster Linie als Projekt und nicht als Framework (wie CMS) angedacht ist
  • In-page Editing für Redakteure, da Verbesserungen erst in neueren Sitecore-Versionen (und auch vorerst nur fürs CMS) vorgenommen wurden
  • WYSIWYG Texteditor (Telerik), insb. in Kombination mit IE
  • Templating verursacht verhältnismässig viel Aufwand

Aus Projektsicht empfiehlt es sich die SIP dann einzusetzen, wenn sich die Konzeption der Lösung  an den Out of the Box Mitteln von Sitecore orientiert. In der FrontEnd-Umsetzung können Fallstricke entstehen, wenn die bestehenden Funktionen einem neuen Designansatz unterzogen werden.

Seite 20 von 24« Erste...10...1819202122...Letzte »