Archiv für Oktober 2013

SharePoint 2013 Suche – Ergebnisse wie man sie sich wünscht.

Montag, 21. Oktober 2013

Papierrollen_Blog_21102013Bei der Entscheidung für “Search” als Datenzugriffstechnologie ist man dank schneller Aktualisierung des Suchindex in der Lage, Übersichten von Webseiten, Bibliotheken, Dokumenten oder Listenelementen sinnvoll durch Filter und Sortierung aufbereitet darzustellen – sogar über mehrere Websitesammlungen hinweg. Jedoch werden die verlinkten Ergebnistitel nicht immer automatisch so angezeigt ,wie es wünschenswert wäre. Was vor kurzem noch mühevoll mit XSLT zusammengefrickelt werden musste, lässt sich heute schnell und bequem mit HTML und JavaScript anpassen. 

Unser Anwendungsfall beinhaltet projekt-bezogene Listenelemente, die über eine Websitesammlung verteilt sind und über einen suchgetriebenen-Mechanismus zu einer Gesamtübersicht zusammengezogen werden sollen. Jeder Datensatz enhält Rich-Text-Felder zur Beschreibung von wöchentlichen Aktivitäten mit Projektbezug. Man kann also verallgemeinert von einem Reporting für projektbezogene Wochenberichte sprechen.

In diesem Beispiel haben wir es mit einem Suchergebniswebpart zu tun, der Listenelemente einer Websitesammlung anzeigt, die einem bestimmten Inhaltstypen (Statusreport) entsprechen. Randnotiz: wenn Sie den Inhaltstypen als Filterkriterium verwenden möchten, geben Sie immer den vollen Namen des Inhaltstypen an – nicht die ID. Der folgende Screenshot zeigt das unangepasste Suchergebnis. Da es sich bei den Suchergebnissen um Listenelemente handelt, werden logischerweise die Ansichtsformulare (DispForm.aspx) als verlinkter Ergebnistitel angezeigt. Da der Ergebnistitel in dieser Form keinen Informationswert besitzt, soll er so angepasst werden, dass er mittels Konkatenation aus den Metadaten des Listenelements einen sinnvollen und informativen Ergebnistitel anbietet.

problemstellung

Der nächste Screenshot zeigt das verwendete Display-Template. In dieser HTML-Datei binden wir die “Platzhalter-Managed Properties” ein, die wir zuvor mit der passenden Crawled Property (in der Regel “ows_Spaltenname”) verknüpft haben. Eine detaillierte Beschreibung zum Thema Managed/Crawled Properties finden Sie hier. Nach dem Eintragen der Managed Properties innerhalb des Tags “mso:ManagedPropertyMapping” können wir beginnen, die übergebenen Werte zur Anreicherung des Ergebnistitels zu verwenden. Dabei verbirgt sich hinter RefinableString00 die Kalenderwoche (KW), hinter RefinableString01 der Projektname und hinter RefinableString27 das Jahr.

Soll-Zustand ist die Syntax: <Projektname> – KW <Kalenderwoche> <Jahr>

Nun wenden wir uns der Zeile 27 zu. Dort weisen wir eine neue Variable mit dem Titel “ctx.CurrentItem.Title” zu. Der Übergabewert  setzt sich aus den Managed Properties in Form einer sinnvollen Verkettung (Konkatenation) zusammen. Randnotiz: obwohl das JavaScript ab Zeile 25 auskommentiert ist, so entfaltet es dennoch seine gewollte Wirkung.

displaytemplatecode

Im nächsten Schritten betrachten wir bereits das Ergebnis. Randnotiz: sollten zunächst keine Werte übergeben werden, warten Sie den nächsten Incremental Crawl ab. Dieser dauert in Office 365 ca. 10 Minuten. Besonders schön zu beobachten ist die Übereinstimmung der Daten mit dem Refinement Panel (rechts), welches die selben Managed Properties konsumiert, wie der von uns angepasste verlinkte Ergebnistitel.

statusreportsapp2

Beim Fahren mit dem Mauszeiger über eine der Ergebniszeilen (Hovering) werden dem Nutzer weitere Informationen aus dem Datensatz angezeigt, ohne den Datensatz explizit öffnen zu müssen. Mehr dazu hier. Im konkreten Fall können wir nun darauf verzichten, im wöchentlichen Turnus etwa Word-Dokumente mit den aktuellen Projektberichten im Unternehmen herumzuschicken. Stattdessen haben wir einen einfachen und automatischen Mechanismus geschaffen, um Statusreports zu Projekten projektübergreifend mit allen wichtigen Filtermöglichkeiten zur Nutzung durch den Anwender bereitzustellen.

Autor: Karsten Ulferts

SharePoint Server 2013 Lizenzierung – einfach und verständlich erklärt

Montag, 14. Oktober 2013

Blog_SharePointLizensierung_KochIn meinem heutigen Beitrag werde ich Ihnen einfach und verständlich die Lizenzierung des SharePoint Servers 2013 erklären. Wir starten mit den rechtlichen Rahmenbedingen und den Grundlagen der Lizensierung. Sie erleben anhand von einem dynamischen Beispiel die verschieden Einsatzszenarien von SharePoint Server 2013 und die Besonderheiten bei der Lizenzierung. Zum Schluss zeige ich Ihnen noch eine mögliche Alternative, den Cloud Dienste mit Office 365.

Richtige Lizenzierung ist Chefsache und eine fehlerhafte Lizenzierung ist kein Kavaliersdelikt. Eine falsche Lizenzierung kann schwerwiegende Folgen für das betreffende Unternehmen haben. Angefangen bei der kostenpflichtigen Nachlizenzierung, über den Imageverlust bei Mitarbeitern und Kunden und im schlimmsten Fall eine Gefängnisstrafe für den Verantwortlichen. Aus diesem Grund ist eine korrekte Lizenzierung sehr wichtig für den Geschäftserfolg und das positive Image des Unternehmens. Die Geschäftsführung, die letztendlich haftet, muss die Verantwortung entweder delegieren oder sich regelmäßig mit dem Thema Lizenzierung auseinandersetzten. Die verschiedenen Softwareanbieter mit ihren verschiedenen Vertragsmodellen, die regelmäßigen Vertragsänderungen und der ständige technische Wandel sind ein sehr komplexes Thema.

Grundlagen der SharePoint Lizenzierung

sharepoint2013logoMicrosoft SharePoint 2013 ist eine webbasierte Plattform für die Zusammenarbeit im Unternehmen und ein sehr umfangreiches Enterprise Dokumenten Management System mit einer tiefen Office-Integration. Mit dieser Technologie können Unternehmen individuelle Lösungen für die folgenden Einsatzszenarien abbilden:

  • SharePoint als Intranet
  • SharePoint als Extranet
  • SharePoint als Internet

Für die Nutzung des SharePoint Server 2013 werden zusätzlich zwei weitere Serverprodukte aus dem Hause von Microsoft benötigt. Als Betriebssystem dem Windows Server und als Datenbank den MS SQL Server; beide idealerweise in der aktuellen Version. Damit es nicht zu kompliziert wird, gehe ich heute nur auf die Lizenzierung des SharePoint Server 2013 ein. Zusätzlich können im SharePoint Server auch noch Web-Apps integriert werden. Diese werden zwar vom SharePoint Server bereitgestellt, aber über das Office des Nutzers lizenziert. Das bedeutet jeder Mitarbeiter, der die Web-Apps nutzen kann, benötigt eine Volumenlizenz für ein Office 2013. Die Web-Apps haben den Vorteil, dass Dokumente in jedem Browser angezeigt und bearbeitet werden können, auch zum Beispiel von einem Smartphone.

Der SharePoint Server wird nach dem Server CAL Modell lizensiert. Bei der SharePoint Lizenzierung wird zwischen Named-Usern und anonymen Zugriffen unterschieden. Das bedeutet alle Named User benötigen immer eine Zugriffslizenz eine sogenannte CAL [Client Access License] Es spielt dabei keine Rolle, ob der Zugriff von einem internen oder externen Mitarbeiter erfolgt. Für den SharePoint Server gibt es die beiden folgenden CAL´s:

  • Share Point Server 2013 Standard
  • Share Point Server 2013 Enterprise

Die Enterprise CAL ist eine Zusatzlizenz. Das bedeutet Nutzer, die Enterprise Features nutzen können, müssen die beiden CAL´s zugewiesen bekommen. Die CAL´s gibt es wiederum in zwei verschiedenen Ausführungen: einmal als User CAL und als Device CAL. Entweder wird eine Person oder ein Gerät lizenziert. Bei einem Unternehmen mit Schichtbetrieb, wo mehrere Nutzer einen Rechner nutzen, kann der Einsatz von Device CAL´s sinnvoll sein. Bei der Nutzer CAL darf der Nutzer von verschiedenen Geräten aus den SharePoint Server nutzen. Eine Mischlizenzierung von USER und Device CAL ist nicht zulässig.

Wichtig ist auch, dass die Server und die CAL Lizenz die gleiche Version entsprechen. Das bedeutet, Sie können mit einer SharePoint Server 2010 Standard CAL keinen SharePoint Server 2013 lizenzieren. Für solche Fälle ist der Abschluss einer Software Assurance sinnvoll. Das bedeutet, Sie kaufen eine Lizenz und zusätzlich für einen vertraglich vereinbarten Zeitraum ein erweitertes Nutzungsrecht. Dieses Recht beinhaltet unter anderem im Vertragszeitraum die aktuellste Software Version einzusetzen.

SharePoint Server 2013-Lizenzierung

 

Beispiel – SharePoint Lizenzierung

In der Regel wird in Unternehmen SharePoint dynamisch eingeführt. Am Anfang als Intranet und in den nächsten Schritten werden die SharePoint Anwendungen erweitert und auch für weitere Szenarien eingesetzt. Das folgende Lizenzierungsbeispiel ist genauso dynamisch aufgebaut.  Wir gehen in diesem Fall von einer On Premise Lösung aus.

1. SharePoint Server Standard für ein Intranet mit 800 Nutzern

Die Lizensierung erfolgt nach dem Server CAL Modell und wir benötigen demnach 1 Lizenz für den MS SharePoint Server 2013 und 800 mal die SharePoint Server 2013 Standard CAL. Sollten aus technischen Gründen mehrere SharePoint Server notwendig sein, so benötigen Sie für jeden Server eine SharePoint Server Lizenz.

2. Für 4 Abteilungen mit insgesamt 200 Mitarbeitern werden SharePoint Enterprise Funktionalitäten bereitgestellt

Die Anwendung ist so konfiguriert, dass nur die 200 Mitarbeiter der beiden Abteilungen die SharePoint Enterprise Funktionalitäten nutzen können. Für diesen Fall werden zusätzlich 200 mal die SharePoint Server 2013 Enterprise CAL benötigt. Wichtig ist, dass der Nutzer die SharePoint Server Enterprise Features nutzen kann, und demnach eine Standard und eine Enterprise CAL zugewiesen bekommt.

3. Erweiterung für ein Extranet mit SharePoint Server Standard 2013 mit 150 Nutzern

Es wird eine Erweiterung für 150 externe Nutzer bereitgestellt. Bei der Lizenzierung werden externe Nutzer genauso nach dem Server CAL Modell behandelt. In diesem Fall werden zusätzlich 150 Lizenzen der SharePoint Server 2013  Standard CAL benötigt.

4. Erweiterung – Internetseite mit SharePoint Server Standard 2013

Es wird zusätzlich mit dem SharePoint Server Content bereitgestellt, der öffentlich verfügbar ist. Aus Sicht der SharePoint Lizenzierung müssen keine neuen Lizenzen bereitgestellt werden. Der SharePoint Server enthält schon alle erforderlichen Nutzungsrechte. Aber nicht zu vergessen ist in diesem Fall, dass der Windows Server und der MS SQL Server für anonyme Zugriffe lizenziert werden müssen. Das bedeutet, dass die Windows Server zusätzlich mit External Connector Lizenzen lizenziert werden müssen. Der anonyme Zugriff bedeutet für den MS SQL Server, dass dieser nicht nach dem Server CAL Modell lizenziert werden darf, sondern pro Prozessorkern.

Bei der korrekten Lizenzierung “OnPremise” gilt es Einiges zu beachten und zusätzlich müssen Sie sich noch um den Betrieb und die Wartung der Systeme kümmern.

 

71Eine Alternative – SharePoint Server aus der Cloud mit Office 365

Sie nutzen den Dienst, verwalten Ihre Nutzer, und die Nutzung der Office Web Apps sind auch in fast allen Varianten von Office 365 schon enthalten. Die Anwendungen sind korrekt lizenziert und um den Betrieb müssen Sie sich auch keine Gedanken machen, denn das erledigt Microsoft zuverlässig in seinen Rechenzentren. Zudem wird der Dienst an die aktuelle Version angepasst, sodass Sie immer mit aktueller Software arbeiten können, ohne neue Lizenzen zu erwerben.

Mehr zu SharePoint Online und den Office365-Plänen erfahren Sie: www.protechnology.de/DesktopModules/PTDownloads/Handlers/Download.ashx?id=71

Expertentipp Hybridlösung: Sie können den SharePoint Server 2013 auch als Hybridlösung betreiben, und dabei die Anfangsinvestitionen sehr gering halten. Wie funktioniert dieser Ansatz? Wählen Sie anstatt der User CAL den entsprechenden Online Plan aus. SharePoint Online „Plan 1“ entspricht dem SharePoint Server Standard und „Plan 2“ entspricht SharePoint Server Enterprise. Sie können bei dieser Variante entscheiden, welche Daten Sie lokal oder in der Cloud speichern. Es ist auch möglich alle Daten lokal zu speichern und ggf. zukünftig diesen Dienst zu nutzen. Zudem haben Sie die Flexibilität, die User monatlich anpassen zu können.

Fazit: Wenn Sie sich nicht um die Lizenzierung kümmern wollen, können Sie sich auf den Online-Dienst von Microsoft verlassen. Zusätzlich haben Sie die Sicherheit, dass Sie korrekt lizenziert sind, können immer mit einer aktuellen Software arbeiten und Sie zahlen nur das, was Sie tatsächlich nutzen. Eine echte Alternative besonders auch für kleine und mittelständige Unternehmen.

Autor: Matthias Boden

PT_XING_MBoden

Office365: Subsite – Workflow – REST und die Verbindung

Mittwoch, 09. Oktober 2013

blog_102013_2Als User der OnPermise Variante respektive SharePoint Server 2013 ist man manche Features einfach gewohnt. Ein einfaches Beispiel ist das Ausrollen einer SubSite über einen Workflow, doch in SharePoint Online? Na huch? Wo ist denn die Aktion für “Create New Site”?

Im SharePoint Designer gähnende Leere und dann auch noch der Aspekt der neuen WorkFlow Engine, sprich 2013er Stages, Steps, Apps und doch gibt es schon einige Anbieter, welche Features wie Projektmanagement-Anwendungen anbieten und auch diese kochen nur mit Wasser. Also muss es einen Weg geben, auch in Office365 und nach langer Suche durch diverse Blogbeiträge hat es KLICK gemacht.

Jedoch ist einfach Abtippen natürlich eine Lösung aber keine Option, wenn man tiefer und weiter gehen will und deshalb standen Stunden voll Theorie, Kopfschmerzen und Verzweiflung auf dem Programm bis ich kapiert habe was er da eigentlich gezaubert hat. Denn mal ehrlich, wer weiß sofort was “REST” ist und wie man es sinnvoll und zielführend nutzt, geschweige denn, zu was es in Office365 fähig ist? Daher zum Anfang der Versuch eines kleinen Wissensaufbaus zum Auffrischen bzw. Heranführen an die Materie.

REST oder in ausgesprochener Form Representational State Transfer soll im Grunde als Ergebnis einen Seiteninhalt als URL auf Basis einer serverseitigen Aufgabe oder Aktion erzeugen. In meinen Worten heißt das, ich speichere Inhalte in Variablen, übergebe sie einen Algorithmus und lasse sie über eine URL bspw. eine neue SubSite erstellen. Und nun genug Vorgeplänkel und auf ins System:

Phase 1: Erstellen der Startbedingung

Als Auslöser erstellen wir “eine benutzerdefinierte Liste”, in meinem Beispiel “nature Projects” in der Website-Sammlung “Test_Project”

Liste_WF

 

In der Liste habe ich zusätzlich noch eine Spalte “Project Url” angelegt und sie als Pflichtspalte gekennzeichnet und “Description”(Beschreibung im deutschen Office365) als optionales Feld ergänzt. So ergibt sich beim Klicken auf neues Element folgendes Bild.

Eingabemaske

Ziel ist, dass bei jeder Erstellung eines neuen Eintrags in der Liste der Workflow gestartet wird und damit die neue Unterseite erstellt wird.

Danach navigieren wir in der Liste über die Ribbon Leiste über “Liste–>Workflow Einstellungen–>Erstellen eines neuen Workflows mit SharePoint Designer”

Im offenen SharePoint Designer geben wir dem Workflow einen Namen z.B. “Create Site”, tragen eine Beschreibung ein (optional) und bestätigen alles.

Phase 2: Der Workflow

Nun kommen wir zum spannenden Teil. Im Vorhinein ein Bild des kompletten Workflows den wir Stage für Stage abarbeiten werden und dabei versuche ich kurz auf die einzelnen Teile und ihre Funktionen einzugehen.

Complete WF

Stage: Creating request Header

Wir erstellen ein Wörterbuch  RequestHeader, fügen in ihm eine Variable content-type und Accept vom Typ Zeichenfolge(String) hinzu und geben ihnen den Wert application/json;odata=verbose.

 

  • Content-type – Gibt Format der Daten an, die vom Client an den Server gesendet werden
  • Accept – Gibt das Format der Daten an, die der Client vom Server erwartet
  • application/json – Objekt vom Typ JavaScript
  • odata=verbose – Open Data Protokoll vom Typ verbose –> Datenaustauschformat basierend auf Standard JavaScript, spezifiziert in der ECMA-262 

Als Bestätigungskriterium habe ich noch einen Genehmigungsworkflow eingefügt, dieser ist aber optional und kann beim Test ausgelassen werden.

Stage: Creating Request Body

Hier legen wir 3 Wörterbücher (MetaData, Request, RESTparameters) an und  geben ihnen folgende Variablen mit:

MetaData:

  • type/Zeichenfolge/SP.WebInfoCreationInformation – Spezifiziert die Meta-Informationen der Seite wie Url, Beschreibung, Vorlage, …

Request:

  • Url/Zeichenfolge/[%CurrentItem:Url%] –> mein angelegtes URL Feld aus der Liste
  • Title/Zeichenfolge/[%CurrentItem:Title%] –> Title Feld aus Liste
  • Description/Zeichenfolge/[%CurrentItem:Beschreibung%] –> Beschreibungsfeld aus der Liste
  • Language/Ganze Zahl/1033 –> Code für deutsche Spracheinstellungen
  • WebTemplate/Zeichenfolge/sts#0 –> Code für Standard Teamseiten Vorlage
  • UseUniquePermissions/Zeichenfolge/false –> keine Zuweisung von eigenen Berechtigungskonzepten (Verwendung der übergeordneten)
  • __metadata/Wörterbuch/MetaData –> Verweis auf Variable für die spezifischen Metadaten der Site

RESTparameters:

  • Parameters/Wörterbuch/Request –> erhält die Variable Request als Inhalt

Stage: Creating Site

Anlegen eines App Steps und hinzufügen einer HTTP-Webdienst Aktion vom Typ POST, wir wollen ja eine Aktion lostreten und nicht per GET etwas empfangen oder holen.

Erweiterte Einstellungen:

  • RequestHeaders: Variable: RequestHeader –> definiert die Informationsaustausch-Richtlinie (siehe Create Request Header)
  • RequestContent: Variable: RESTparameters –> holt die Informationen für die auszuführende Aktion aus Schritt Create Request Body

Zum Abschluss lass ich noch eine E-Mail an mich schicken, um zu wissen, wann und ob der Workflow abgeschlossen wurde.

Speichern und Veröffentlichen.

Wichtig ist noch, dass unter den Workfloweinstellungen die Option zum automatischen Starten aktiviert ist. Ohne Automatismus kein Workflow bei einem neuen Eintrag.

Wf_option

 

Phase 3: App Berechtigung

Nach erfolgreicher Veröffentlichung steht noch ein wichtiger Schritt aus. Der Workflow braucht Berechtigungen, da er durch den AppStep Eingriffe in der Seite vornimmt.

Unter Webseiteneinstellungen –> App Berechtigungen die Nummer des Workflows notieren. Diese befindet sich zwischen dem letzten | und dem ersten @.

WF_ID

Danach wechseln wir in den Berechtigungsbereich der Sammlung, indem wir den Link bis (in meinem Fall) …/sites/t_p/_layouts/ verkürzen und daran appinv.aspx anhängen. Damit öffnet sich die Berechtigungsseite.

Unter App Id trägt man obige Nummern ein und bestätigt das Lookup. Alle Informationen werden automatisch ergänzt und der letzte Schritt besteht darin, die App-Berechtigungen einzutragen. Quasi damit die App respektive Workflow weiß, wo er, was wie darf.

App_Perm

Im nächsten Fenster dem App-Vertrauen zustimmen und fertig.

Phase 4: Neue Seite … GoGoGo :)

Jetzt in die Liste, neues Element anlegen, Pflichtfelder ausfüllen, bestätigen und wie ich freudig im Kreis springen.

Wenn es nicht sofort funktioniert keine Panik, meist liegen die Fehler bei der Variablen-Zuordnung. Am besten im Workflow-Status prüfen, wo er aussteigt, meist findet man so schnell den Grund.

Ich hoffe das konnte Einigen helfen. Der nächste Schritt wird das Einbinden einer eigenen Vorlagenseite sein. Das wird anscheinend noch ein paar Nerven, Haare und Stunden kosten ;)

Bis dahin Stay SharePoint und viel Spaß beim probieren.

Autor: Felix Weichert

PT_XING_FWeichert

Build & Deployment von Windows Azure Anwendungen – Teil 1

Mittwoch, 02. Oktober 2013

blog_102013Dieser Artikel wird der erste Teil einer Serie von Blogartikeln zum Thema Windows Azure CloudServices sein. Im Ersten Teil möchte ich etwas ausführlicher auf den Aufbau und die Konfigurationsmöglichkeiten eines CloudService für Szenarien mit verschiedenen Zielumgebungen eingehen. Das wird als Kontext für diesen und weitere Artikel dienen. Im Anschluss daran wird, anhand einer kleinen Beispielanwendung gezeigt, wie man den Prozess der Erstellung und Bereitstellung weitgehend automatisieren kann. Am Ende dieses ersten Teils werden wir noch einmal die kleinen Ungereimtheiten bezüglich der Konfigurationstransformationen ansprechen, für welche dann im zweiten Teil der Reihe eine mögliche Lösung aufgezeigt wird.

Bevor ich die Beispielanwendung beschreibe, möchte ich kurz etwas zum Aufbau der Dienste, die wir über die Windows Azure Plattform bereitstellen, zusammenfassen.

Die Ziele die man mit dem Einsatz der Windows Azure Plattform verfolgt, sind unter anderem hohe Verfügbar- und Skalierbarkeit, der darauf laufenden Dienste. Um das zu erreichen, versucht man die Abhängigkeiten des Dienstes (bspw. eine Webanwendung) zur Umgebung (VM mit bspw. Windows Server 2008, welche von Windows Azure verwaltet werden) so gering wie möglich zu halten. Dadurch kann man, bspw. den Dienst im Falle eines Hardwareproblems, auf eine andere VM auslagern, oder bei hoher Last einige VM Instanzen hinzuschalten und eingehende Anfragen auf diese neuen Instanzen verteilen.

Um diese „Isolation“ zu erreichen, muss jede Anwendung, die Bestandteil eines solchen Dienst-Packet (CloudService) ist, auch so beschreiben werden, dass Windows Azure damit arbeiten kann. Diese gemeinsame Schnittstelle für die verschiedenen Typen von Anwendungen, wird als Anwendungsrolle bezeichnet. Diese unterteilen sich bspw. in „Web-Rolle“, welche Webanwendungen beschreiben oder „Worker-Rolle“ mit vielen verschiedenen Varianten. Durch die Beschreibung, welche die Anwendungsrolle (und deren Konfigurationswerte) der Windows Azure Plattform liefert, kann diese dann einen entsprechend konfigurierten Host bereitstellen und verwalten. Die beschriebene Anwendung selbst muss natürlich so gebaut sein, dass es keine direkte Abhängigkeit zum bereitgestellten Host gibt. Die Anwendung darf ihrerseits nur mit der API, der Windows Azure Laufzeitumgebung kommunizieren.


Beschreibung der Beispielanwendung

Das Beispiel besteht aus 2 Projekten, die in einer Solution zusammengefasst sind. Das erste Projekt ist eine leere ASP.net Webanwendung. Das CloudService-Projekt hat eine Web-Rolle und diese verweist auf das erste Projekt mit der leeren ASP.Net Webanwendung. Zur Konfiguration einer .Net Anwendung für verschiedene Umgebungen (Test, Produktiv, usw.) kann man Konfigurationsdatei-Transformationen verwenden. Um es grob zu beschreiben, wird dabei der Basisversion einer XML Konfigurationsdatei (bspw. web.config) eine angepasste Version (bspw. web.release.config) pro Zielumgebung zugeordnet. Zum Veröffentlichungszeitpunkt werden diese dann „zusammengeführt“, um die Basisversion auf die gewählte Zielumgebung zuzuschneiden (siehe MSDN). Für mein Beispiel ergibt sich folgender Aufbau:

SolutionExplorer der Beispielanwendung(Begin)
Abbildung 1: Solution Explorer des Beispiels

Außerdem, werde ich einen Wert zur Kontrolle der Transformation der Anwendungskonfiguration verwenden, welcher beim Aufruf der Default.aspx angezeigt wird.

Release-Transformation fÅr Web.config

Abbildung 2: web.release.config

Wofür sind die einzelnen Konfigurationsdateien gut und wie werden die unterschiedlichen Konfigurationen bei der Erstellung bzw. Bereitstellung angewandt?

Die Projektdatei (*.csproj) des ASP.net Web-Projektes importiert mehrere MSBuild Target-Dateien. In diesen wird auch die Web.config Datei mit einer der im Projekt befindlichen Transformationsdateien zusammengeführt. Welche der Transformationsdateien verwendet wird, hängt vom Namen der gewählten Konfiguration zum Zeitpunkt der Erstellung und Bereitstellung ab. In den MSBuild-Targets für Web-Anwendungen wird zwischen „Erstellung“ (Build) und „Bereitstellung“ (Deployment) unterschieden. Einige Schritte werden standardmäßig nur bei der Bereitstellung durchgeführt. Dazu zählt auch die Transformation der Konfigurationsdateien. Wenn ich den Standardprozess, der in den Target-Dateien definiert ist, nicht anpasse, wird bspw. beim lokalen Erstellen und Ausführen im IIS, IISExpress oder Cassini die unbehandelte Web.config aus meinem Projekt verwendet.

 Grober Ablauf VS und MSBuild fÅr Web-Projekt

Abbildung 3: Build & Deployment Ablauf(extrem vereinfacht) für Web-Projekt

Die Konfigurationsdateien des CloudService-Projektes sind allerdings etwas anders aufgebaut. Diese unterteilen sich in einen statischen Teil, die Dienstdefinition (ServiceDefinition.csdef) und einen dynamischen Teil, die Dienstkonfiguration (ServiceConfiguration.cscfg). Die Dienstdefinitionsdatei beinhaltet u.a.:

–        Dienstendpunkte

–        Zuordnung der Zertifikate der Konfiguration (*.cscfg) zum lokalen Zertifikatsspeicher der VM

–        Bindungen der Zertifikate an die Endpunkte

–        Startup-Task für die Rollen

–        Größe der VM

Diese Informationen können nach dem Bereitstellen nicht mehr verändert werden und gelten für alle Instanzen der entsprechenden Rolle(n). Die Dienstkonfigurationsdatei enthält u.a.:

–        Einfache Schlüssel-Wert Paare, die das Äquivalent des AppSettings-Bereiches der Web.config darstellen (hier sind bspw. Verbindungszeichenfolgen für AzureStorage Accounts hinterlegt)

–        Liste mit Zertifikaten, welche aus dem Zertifikatsspeicher der Rolle in den der Rolleninstanz/VM kopiert werden sollen (dazu mehr im 2ten Teil)

–        Anzahl der Rolleninstanzen

Die Dienstkonfiguration kann auch nach der Bereitstellung geändert werden (Azure Management Portal). Nur für die Dienstkonfiguration gibt es die Möglichkeit verschiedene „Transformationen“ zu definieren. Der Mechanismus ist ähnlich wie bei der web.config Transformation, beschränkt sich allerdings auf das Ersetzen bestehender Werte. Der genaue Prozessvorgang ist wiederum in einer eigens für Azure-Projekte, von Microsoft bereitgestellten, MSBuild Target-Datei definiert. Der Name der Datei ist „Microsoft.WindowsAzure.targets“. Auch in dieser Target-Datei wird zwischen Erstellung und Bereitstellung unterschieden. Wie das grob abläuft zeigt die nächste Abbildung:

 Grober Ablauf VS und MSBuild fÅr CloudService

Abbildung 4: Build & Deployment Ablauf(extrem vereinfacht) für CloudService-Projekt

 

Für das lokale Erstellen und Ausführen des CloudService-Projektes via Visual Studio, ist in den Projekteigenschaften standardmäßig festgelegt, welche Dienstkonfigurations-Transformation auf die ServiceConfiguration.cscfg angewendet werden soll:

CloudServiceProjectDetails

Abbildung 5: Eigenschaften des CloudService-Projekts

Das Herstellen dieser Zuordnung zwischen Anwendungs- und Dienstkonfiguration wird mir aber nur für das lokale Erstellen und Ausführen im Azure Compute Emulator abgenommen. Verwende ich hingegen die „Package …“ Option im Kontextmenü des CloudService-Projektes um ein Dienstpaket zu erstellen, muss ich beide Konfigurationen auswählen und bestimme somit welche Transformationen zum Einsatz kommen:

PackageOption

Abbildung 6: “Package…” Option via VS GUI

Wenn ich die Visual Studio GUI nicht verwenden will oder kann, erreiche ich dieselben Ergebnisse in dem ich, MSBuild.exe direkt aufrufe und die MSBuild-Parameter „Configuration“ für die Anwendungskonfiguration und „TargetProfile“ für die Dienstkonfiguration mit den gewünschten Werten übergebe. Dieser Punkt wird beim automatisierten Erstellen via Team Foundation Server wichtig sein. Damit ist der Theorie-Teil für diesen und den folgenden Blogbeitrag erst einmal abgedeckt.

Automatisierung der Erstellung und Bereitstellung über TFS-Online

Kurz zur Erklärung für diejenigen, die mit dem Produkt „Team Foundation Server“ (TFS) und dem Cloud-Dienst TFS-Online nichts anfangen können. Der TFS ist im Kern ein Quellcodeverwaltungssystem, das aber auch viele andere Funktionen bietet, um den Software-Entwicklungsprozess zu unterstützen. Eine der Komponenten ist ein auf Microsofts „Workflow Foundation“ basierender Build-Server. Diese Komponente „Team Build“ arbeitet mit der Quellcodeverwaltung zusammen. Der Erstellungs- und Bereitstellungsprozess wird dabei in einer XAML Datei beschrieben. Das macht das ganze enorm flexibel, leider aber auch ganz schön komplex.

Zurück zum Thema. Wir wollten den TFS-Online Dienst verwenden. Da ich schon einen bestehenden Account verwende, die Einrichtung nicht wirklich Thema ist und hier mit den vielen Bildern nur noch mehr Platz wegnehmen würde, verweise ich mal nur auf die recht gute Dokumentation in der MSDN. Wir haben die Anweisungen der MSDN Anleitung bis zum Ende von Schritt 3 „Connect the Project to Windows Azure“ befolgt und müssten als nächstes definieren wie unsere Beispielanwendung erstellt und, wenn möglich, auch gleich in der Zielumgebung bereitgestellt wird.

Am Ende von Schritt 3 wurde bereits eine Build-Definition für uns erstellt, die jetzt in der Oberfläche des Team Explorers im Visual Studio zu sehen sein sollte. Diese müssen wir noch bearbeiten und die fehlenden Werte ergänzen.

Für mein Beispiel möchte ich den Erstellungsvorgang manuell über den Team Explorer im Visual Studio bzw. das TFS Portal auslösen.

 Tab-Trigger

Abbildung 7: BuildDefinition – Trigger

Der Prozess wird am Anfang über den Build-Server, eine freie VM ermittelt, auf welche der Erstellungsprozess der Anwendung durchgeführt wird. Auf diese werden dann die Verzeichnisse und deren Inhalte aus der Quellcodeverwaltung, die für die Erstellung der Solution notwendig sind, kopiert. Diese Verzeichniszuordnung muss im Tab „Source Settings“ hergestellt werden.

Tab-SourceSettings

Abbildung 8: BuildDefinition – SourceSettings

Auf diesem Build-Agent wird dann, nachdem alle Quellen kopiert wurden, die MSBuild.exe als Bestandteil des Erstellungs- und Bereitstellungsprozesses ausgeführt. Da sich die Projektdatei (*.ccproj) mit im Projektordner aus der Quellcodeverwaltung befand und somit auch auf die VM kopiert wurde, läuft die Erstellung genauso wie beim lokalen Erstellen und Bereitstellen über die „Package …“ Option im Visual Studio ab. Man sollte darauf achten nicht zu viel, aber auch nicht zu wenig (bspw. Solution referenziert DLL’s aus einem anderen Ordner) zu kopieren. Nun müssen nur noch die Parameter für den Prozess der gewählten Vorlagendatei angegeben werden.

 Tab-Process Basic

Abbildung 9: BuildDefinition – Process (Basic)

Die Prozessvorlagendatei „AzureContinuousDeployment.11.xaml“ sollte bereits vorausgewählt sein. Der dahinterliegende Workflow muss natürlich wissen, welche Solution (Parameter: „Solution to Build“) erstellt werden.  Im nächsten Bereich wird die zu erstellende Anwendungskonfiguration der Solution festgelegt (Parameter: „Configuration To Build“).

 Tab-Process Advanced

Abbildung 10: BuildDefinition – Process (Advanced)

Im Bereich „Advanced“ finden wir den letzten und entscheidenden Parameter. Wie schon weiter oben gesagt, kann man damit den festen Wert, der für den MSBuild Parameter „TargetProfile“ verwendet wird (siehe Abbildung 5) überschreiben.

Alles was zu tun bleibt ist eine neue Anfrage in die Warteschlange des Build-Servers zu stellen und das Resultat mit dem des lokalen Ausführens im Azure Emulator zu vergleichen:

 Resultat

Abbildung 11: Minimalistische Webseite lokal (oben) und in Amsterdam (unten)

Wie erwartet, wurden die Werte aus den Transformationsdateien „web.release.config“ und „ServiceConfiguration.CloudEUProd.cscfg“ in der Azure-Umgebung korrekt angewandt.

Für unsere Beispielanwendung, die keine Datenbank, Sessiondaten, Authentifizierung und Autorisierung und alle damit verbunden Dinge verwendet, reicht das alles aus. Was ist aber, wenn wir mit Zertifikaten arbeiten wollen/müssen und diese sich zwischen Test- und Produktivumgebung unterscheiden? Ein anderes Beispiel wäre, dass wir aus Kostengründen in der Testumgebung kleinere Instanz-Größen als in der Produktivumgebung verwenden wollen. Diese Szenarien lassen sich derzeit nur durch Erweiterungen der Standard-Prozessvorlagen und MSBuild-Dateien umsetzen, welche Inhalt des zweiten Teils der Serie sein werden.

Autor: Sascha Blickensdörfer

PT_XING_SBlickensdoerfer