Archiv für die Kategorie ‘Web-Development’

SharePoint: Listeneinträge via Metadatenfeld und JavaScript ermitteln

Mittwoch, 19. März 2014

201403_BLOG_SP_ListeneintraegeMetadatenfelder im SharePoint sind eine feine Sache. Globale Erstellung und Verwendung machen einige Dinge sehr einfach. Andere Dinge wiederum werden etwas umständlicher und zum Graus, wenn man nicht mal weiß, wonach man googlen oder yahooen soll. So zum Beispiel das programmatische Auslesen eines Listeneintrags anhand eines Metadatenfeldes über JavaScript.

Die Herausforderung der Aufgabenstellung sah wie folgt aus: Es bestehen zwei Listen. In Liste A gibt es ein Metadatenfeld, welches isteneintraegemit anderer Bezeichnung und anderem Namen in Liste B vorkommt. In Liste A soll nun ein Lookup-Feld auf Liste B verweisen. In diesem Lookup-Feld steht genau der Eintrag, der durch das Metadatenfeld identifiziert wird.

Klingt relativ simpel. Wir entschieden uns über den Weg CAMLQuery. Dazu benötigten wir den Wert des Metadatenfeldes. Dies stellte sich als relativ einfach heraus, wenn man die entsprechende Stelle im HTML gefunden hat. Trotzdem befindet sich hier schon die erste Stolperfalle. Über die Developertools des IE’s erhält man als sichtbaren Teil des Feldes ein div mit dem Text des Metadatenfeldes.

SharePoint Listeneinträge via Metadatenfeld und JavaScript ermitteln_Bild1

Der von uns benötigte Wert befindet sich allerdings etwas weiter oben in der Hierarchie in einem Input-Feld, das da wie folgt aussieht:

SharePoint Listeneinträge via Metadatenfeld und JavaScript ermitteln_Bild2

  • Mk1: Name des Metadatenfeldes
  • Value: Das ist der eigentliche Wert „Wert|GUID“

SharePoint trennt praktisch Datenanzeige und Dateneingabe.

Der Wert im input-Feld wird in „Anzeigewert“ und „GUID“ per | geteilt. Die GUID ist unerlässlich für die Arbeit mit dem Termstore und ist eineindeutig. Nun liegt die Vermutung nahe anhand der GUID in die Liste B zu gehen und dort per CAMLQuery den Eintrag herauszufinden. Im Internet findet man jetzt die verschiedensten Ansätze das CAML zu nutzen – es geht über Lookups zu Integer und Textfeldern. Schlussendlich sollte aber der Typ „TaxonomyFieldTypeMulti“ gewählt werden (bzw. ohne „Multi“), um auf eine Taxonomiefeld zuzugreifen. Unsere zweite und vermeintlich letzte Hürde ist also genommen und wir erstellen folgende Query:

SharePoint Listeneinträge via Metadatenfeld und JavaScript ermitteln_Bild3

Der Wert in der Variablen „userInput“ entspricht dabei der GUID. Wider Erwarten funktioniert die Query nicht. Verschiedene Methoden führen zu keinem Ergebnis. Mit dem SPCAMLQueryHelper von codeplex war der Fehler dann relativ schnell klar. Schlussendlich ist für die Nutzung im CAML nicht die GUID von Relevanz sondern der Wert selbst. In unserem Beispiel muss also „V1“ übergeben werden, um die entsprechenden Items zu bekommen. Die Query ändert sich dabei nicht.

Mit Aufruf der getItems-Funktion der Liste B erhalten wir alle entsprechenden Einträge.

SharePoint Listeneinträge via Metadatenfeld und JavaScript ermitteln_Bild4

Zur Lösung der Aufgabenstellung muss dann nur noch das korrekte Item herausgefiltert werden. Die Voraussetzungen ermöglichten uns die Annahme, dass immer nur genau ein Item gefunden werden wird. Wir holen uns also die ID des Eintrags und schreiben diese in das Lookupfeld.

SharePoint Listeneinträge via Metadatenfeld und JavaScript ermitteln_Bild5

Obgleich wir im SharePoint ein hohes Maß an Eindeutigkeit durch IDs und GUIDs erreichen, scheint es hier nichts zu nützen. Zwar ist die GUID unerlässlich für die Arbeit im Termstore, aber scheinbar irrelevant für den vorliegenden Fall.

Als Alternative zum JavaScript bleibt dann noch die Möglichkeit des EventReceivers in einer Custom Solution. Je nach Anforderung kann das schneller und besser zum Ziel führen.

Autor: Henrik Krumbholz

PT_XING_HKrumbholz_jpg

 

SketchFlow für zielgerichtetes Prototyping

Dienstag, 04. März 2014

201403_BLOG_SP_SketchflowBei der Projektplanung stößt man immer wieder auf die gleichen Probleme. Haben alle die Anforderungen verstanden? Weiß der Frontendentwickler, wie er die Anwendung zu strukturieren hat? Kann der Architekt mit den Informationen arbeiten? Hat der Designer bereits eine Idee? Ist der Benutzer mit der geplanten Bedienbarkeit zufrieden? Schlecht ist, wenn keine dieser Fragen mit “Ja” beantwortet werden kann. Noch schlechter ist es, wenn die Vorstellungen trotzdem weit auseinandergehen.
Doch mit SketchFlow muss das nicht sein!

Mit SketchFlow ist es möglich, alle Parteien grundlegend zu informieren und gleichzeitig interaktiv am Gestaltungsprozess teilhaben zu lassen. Es gibt einem die Möglichkeit mit einfachen Mitteln einen Prototypen erstellen zu können, dessen Optik nicht ablenkend wirkt. Ein Prototyp in Window Forms beispielsweise ist dem Designer zu hässlich, der Chef bekommt das Gefühl die Anwendung sei bereits weit fortgeschritten und der Benutzer bekommt eine falsche Vorstellung von der Bedienbarkeit, wenn es am Ende eigentlich um eine Webseite geht. Ein Prototyp in ASP.NET ist möglicherweise zu ein- oder unfarbig oder muss mit einem gewissen Aufwand erst optisch aufgewertet werden, obwohl die Struktur und das Design noch längst nicht feststehen. Alles Gründe, warum man Prototypen üblicherweise nur in eingeschränkten Fällen oder zumindest erst in späteren Planungsphasen verwendet. Vorher gibt es jedoch auch Klärungsbedarf zwischen den beteiligten Personen, bei denen verschiedene Hilfsmittel, wie Skizzen, Flipcharts oder gar wildes herumfuchteln mit den Händen eingesetzt werden. SketchFlow hingegen vereint die Macht dieser Hilfsmittel, wodurch man es bereits sehr früh in der Planungsphase einsetzen kann.

Was kann SketchFlow nun?

Im Prinzip ist SketchFlow ein interaktiv bedienbarer Flipchart. Es wird in Form eines Prototypen, mit klickbaren Knöpfe, ausfüllbaren Textfeldern und navigierbaren Menüs zügig eine Anwendung “zusammengeklickt”, die aussieht als wäre sie skizziert. Somit versteht der Entwickler, wie er die Anwendung zu strukturieren hat. Der Designer weiß, an welchen Stellen er freie Hand hat und wo er wiederum an Vorgaben, bspw. Platzierungen von Menüs, Leisten oder Knöpfe, gebunden ist. Sogar der Benutzer bekommt bereits ein Gefühl für die Bedienbarkeit der Anwendung ohne ablenkende Elemente. Allen ist sofort klar, dass nichts davon fertig ist und es darum geht, die Anwendungs selbst zu planen.

Ich will endlich was sehen!

Aber klar doch, kommt sofort. Fangen wir ganz simpel an und öffnen SketchFlow. Halt! SketchFlow ist keine eigenständige Anwendung. SketchFlow ist seit vielen Versionen in “Microsoft Expression Blend” enthalten, welches nun “Blend for Visual Studio” heißt und mit Visual Studio mitgeliefert wird. Also öffnen wir Blend und erstellen ein neues Projekt der Kategorie “Silverlight” -> “SketchFlow”.

Es wird nun ein neues SketchFlow-Projekt erzeugt, welches in unserem Beispiel auf Silverlight basiert. In diesem kann man nun entsprechende SketchFlow-Controls hinzufügen oder sogar normale Controls, falls einem danach ist. Aus psychologischen Gründen, auch wenn ich diese natürlich nicht wissenschaftlich belegen kann, ist es jedoch ratsam weitestgehend bei den SketchFlow-Controls zu bleiben. Warum? Nun mal ehrlich: Wer würde eine offensichtliche Skizze bspw. nach dem Aussehen be-/verurteilen? Bei echten Controls besteht da schon eher die “Gefahr”.

Als Standard wird uns ein Screen 1 (Screen_1.xaml) erstellt und geöffnet, welches wir nun nach belieben mit lustigen Controls füllen können. Die entsprechenden Elemente holen wir uns aus dem Assets Menü im Unterpunkt “SketchFlow”, wobei die üblichen Controls unter “Styles” zu finden sind. Welche es gibt, sieht man recht deutlich auf dem nebenstehenden Bild. Zusätzlich gibt es aber natürlich auch noch allerhand andere Shapes, Screens, Templates, usw. die einem das Leben deutlich leichter machen sollten.

Ziehen wir uns also direkt mal ein paar Sachen in den Screen. Hat man schon einmal mit Blend und/oder Silverlight gearbeitet, dürfte einem die Bedienung natürlich recht bekannt vorkommen. Praktischerweise sind die Controls, welche man sich in den Screen ziehen kann, nicht nur bewegliche Bilder, sondern echte Controls die nur nach Skizzen aussehen. Somit können Comboboxen beispielsweise mit Auswahlmöglichkeiten gefüllt und Knöpfe mit einem Navigationsziel oder gar beliebigem Code ausgestattet werden. Man kann seinen Prototypen also mit genau der Funktionalität versehen, wie es das jeweilige Ziel am besten verdeutlicht. SketchFlow unterstützt auch bei der Erstellung von Animationen, Navigationsabläufen und einigem mehr, was jeder gern selbst mit ein paar wenigen Klicks erforschen kann.

In meinem Beispiel habe ich im oberen Bereich ein Menü mit einem Rectangle-Sketch angedeutet. In diesem habe ich ein TabControl-Sketch platziert, worin ich wiederum einige Button-Sketches und Checkbox-Sketches eingefügt habe. Somit ergibt sich mit ein wenig Geschick recht schnell ein Menü, welches verdächtig nach dem Ribbon-Menü des Windows Explorers aussieht. Dieses könnte man auch als Component-Screen implementieren, um es in verschiedenen Screens wiederzuverwenden. Unter dem Menü habe ich noch ein paar Thumb-Sketches und TextBlock-Sketches hinzugefügt. Soweit so gut.

Als nächstes legen wir noch einen weiteren Screen an, indem wir auf den bestehenden Screen unten in der SketchFlow Map rechtsklicken und einen neuen verknüpften Screen erzeugen. In meinem Beispiel habe ich diesen Bildschirm “New” genannt und den “New”-Knopf in unserem Hauptscreen zudem auf diesen neuen Screen navigieren lassen. Eine solche Navigation kann man auf Button-Sketches recht einfach hinzufügen, indem man diesen mit der rechten Maustaste anklickt, “Navigiere zu” auswählt und darunter den entsprechenden Screen anklickt. Diesen zweiten Screen füllen wir nun auch mit allerhand Controls. Ich habe dafür das Menü aus dem Hauptscreen kopiert und verändert, ein Title-Sketch, einige TextBlock-, TextBox- und ComboBox-Sketches hinzugefügt und zudem eine kleine Überraschung eingebaut, die jeder selbst erkunden darf. Außerdem habe ich ein Note-Sketch hinzugefügt, um den jeweiligen Benutzer/Tester darauf hinzuweisen, dass die Felder nicht vollständig sind und er gerne Vorschläge einreichen darf. Womit wir auch schon bei dem für diesen Blog letzten genannten Feature sind: Der Feedback-Funktion.

Feedback? Das will ich genauer wissen!

Was nützt einem der tollste Prototyp, wenn man die Eindrücke, Vorschläge und Kritiken der jeweiligen Benutzer nur manuell oder sogar garnicht heraus bekommt. Klar könnte man auch eine Feedback-Funktion in den Prototyp einbauen, aber wozu das Rad neu erfinden? In SketchFlow gibt es bereits eine Feedback-Funktion, welche zudem recht mächtig ist.
Der Nutzer kann mit Textmarker oder Freihand den Screen bemalen/beschriften und einen entsprechenden Text in der Feedback-Box schreiben, um so sein Feedback noch exakter rüberbringen zu können. Wie dies genau funktioniert, darf unten in der Beispiel-Vorschau gern ausprobiert werden. Hat man sein Feedback vollendet, kann man es exportieren und dem jeweiligen Designer/Entwickler zukommen lassen.

Fazit und Download

SketchFlow eignet sich aus meiner Sicht sehr gut für Prototyping und auch bereits zur sehr frühen Planung von Benutzeroberflächen, Prozessabläufen und Layouts. Obwohl man mit SketchFlow fast schon fertige Anwendungen erzeugen kann, bleibt der sichtbare Eindruck auf dem Niveau einer Skizze, wodurch jeder Teilnehmer eines Meetings dazu angehalten ist, sich auf das Wesentliche zu konzentrieren. Dazu kommt die einfache Möglichkeit der Verteilung des Prototyps und der Einsammlung von Feedback der verschiedenen Nutzergruppen. Wie viele Tools ist es sehr mächtig, wenn man es richtig dosiert verwendet!

Natürlich gibt es wie üblich die gesamte Solution zum Download. Außerdem darf jeder, der Silverlight installiert hat, das fertige Beispiel direkt hier begutachten.

Quellen: SketchFlow Übersicht, Erstellen von Prototypen mit SketchFlow, SketchFlow Video
Autor: Dirk Sarodnick

Google+

Build & Deployment von Windows Azure Anwendungen – Teil 2

Freitag, 22. November 2013

Lujiazui financial district. ShanghaiIm ersten Teil haben wir uns angesehen, wie wir die Bereitstellung eines Azure CloudService automatisieren können. Manchmal kommt man aber an Punkte, welche sich mit den Standard-Mechanismen und Konfigurationsmöglichkeiten nur schwer, unschön oder gar nicht lösen lassen. In diesem zweiten Teil möchte ich anhand eines Beispiels zeigen, wie man die Standard-Konfigurationsmöglichkeiten, mit wenig Aufwand und ein wenig MS Build Kenntnissen, erweitern kann. Dazu eignet sich die Verwaltung von X.509 Zertifikaten für unseren Beispiel-CloudService ganz gut.

Jeder Azure Cloud-Dienst hat seinen eigenen Zertifikatsspeicher. In diesen müssen alle Zertifikate, welche in der Dienstdefinitionsdatei des CloudService-Projektes angegeben worden, abgelegt werden. Vor der Bereitstellung der Anwendung durch Windows Azure, genauer gesagt beim Hochladen des Dienstpaketes (*.cspkg Archiv Datei), wird geprüft, ob alle Zertifikate, die in der Dienstdefinition angegeben worden, auch im Zertifikatsspeicher des Azure Cloud-Dienstes vorhanden sind. Falls nicht, wird die Bereitstellung fehlschlagen. Während der Bereitstellung des Dienstpaketes und der darin enthaltenen Anwendungsrollen in einer VM Instanz, werden alle Zertifikate aus dem Zertifikatsspeicher des Azure Cloud-Dienstes in den lokalen Zertifikatsspeicher der VM Instanz übertragen. Die Dienstdefinitionsdatei gibt dabei den Ort vor, an welchem die Zertifikate im lokalen Zertifikatsspeicher der VM Instanz abgelegt werden sollen.

Zertifikatssektion der Dienstdefinition(Beispiel)

Zertifikatssektion der Dienstdefinition(Beispiel)

In der Dienstdefinitionsdatei ist das Zertifikat nur über einen selbstvergebenen Namen zu identifizieren. Dieser verweist auf einen Eintrag in der Dienstkonfigurationsdatei, wobei jedem Namen ein Zertifikats-Fingerabdruck zugeordnet ist.

Zertifikatssektion einer Transformationsdatei der Dienstkonfiguration(Beispiel)

Zertifikatssektion einer Transformationsdatei der Dienstkonfiguration(Beispiel)

Dadurch kann ich den Fingerabdruck des Zertifikats je nach ausgewählter Dienstkonfiguration anpassen und bspw. auch das SSL Zertifikat, welches durch den selbstvergebenen Namen angesprochen wird, austauschen. Was ich nicht ohne weiteres machen kann sind Zertifikate für eine Dienstkonfiguration hinzuzufügen oder zu entfernen, den Speicherort im lokalen Zertifikatsspeicher der VM Instanz anzupassen oder Dienstendpunkte zu verändern. Diese Anpassungen, je nach gewählter Konfiguration, würden Änderungen an der Dienstdefinitionsdatei erfordern. In der GUI von VS und den aktuellen MS Build Target-Dateien für Azure Projekte sind solche Szenarien standardmäßig nicht vorgesehen.

Wir werden im folgenden Beispiel ein zusätzliches Zertifikat für eine der Dienstkonfigurationen hinzufügen und die VM-Größe für die Testumgebung anpassen. Im Beispiel wird es 3 Konfigurationen für 3 Zielumgebungen geben. Die folgende Tabelle zeigt die relevanten Einstellungen pro Konfiguration:

Zielumgebung Zertifikatsname(storeLocation/storeName) vmsize
Prod -            SSL Zertifikat (LocalMachine/My)-            RDP Zertifikat (LocalMachine /My) small
Test -            SSL Zertifikat (LocalMachine /My)-            Internes Root Zertifikat (LocalMachine /CA)-            RDP Zertifikat (LocalMachine /My) extra small
Local -            SSL Zertifikat (LocalMachine /My)

In der Produktivumgebung würden wir Zertifikate verwenden, welche von einer kommerziellen CA signiert worden. Die Testumgebung würde selbstsignierte (durch interne CA) Zertifikate verwenden. Das gleiche gilt für die lokale Konfiguration, nur das wir dafür eigentlich kein Zertifikat zur Absicherung eines RDP Zugangs benötigen. Um diese Konfigurationen umzusetzen, müssen wir die MS Build Targets für Azure erweitern, bzw. die darin vorgesehenen Erweiterungspunkte verwenden.

Anpassung des Standardverhaltens der MS Build Targets

Anpassung des Standardverhaltens der MS Build Targets

In der Abbildung sind die zusätzlichen Schritte zu sehen. Durch die Aufteilung der Zertifikatsinformationen auf Dienstkonfigurationsdatei und Dienstdefinitionsdatei (siehe Abbildung 1 und 2), müssen wir beim Entfernen/Hinzufügen in beiden Dateien Änderungen vornehmen. Durch das Ausführen der Transformationen in der Reihenfolge, wie sie in Abbildung 3 zu sehen ist, können wir weiterhin die VS GUI verwenden, um Konfiguration und Definition des Dienstes zu ändern. Alle eigenen Anpassungen werden nachträglich durchgeführt, jedoch noch vor dem Erstellen des Dienstpaketes bzw. dem Kopieren der Dateien in den Emulator. Die dafür notwendigen Änderungen in der Projektdatei des Cloud-Diensts sind in den nächsten Abbildungen zu sehen. Um die Projektdatei im Visual Studio zu bearbeiten, im Kontextmenü „Projekt entladen“ und danach „Projektdatei bearbeiten“ wählen.

Zusätzliche Targets für Cloud-Dienst Projektdatei(*.ccproj) - Schritt 1a und 1b

Zusätzliche Targets für Cloud-Dienst Projektdatei(*.ccproj) – Schritt 1a und 1b

Am Ende der Projektdatei sollte die Import-Anweisung für die Azure Targets zu finden sein (rot). Danach beginnen die Zusätze. In Schritt 3 und 4 werden wir zwei neue Targets definieren, welche die zusätzlichen Transformationen gemäß Abbildung 3 durchführen. Um diese an der richtigen Stelle einzuhängen, können wir entweder das vordefinierte „AfterTransformServiceModel“ Target verwenden oder die Eigenschaft(Liste) „CoreTransformServiceModelDependsOn“ erweitern.

Der für die Modifikation der Dateien notwendige TransformXml-Task ist in der Datei „Microsoft.Web.Publishing.Tasks.dll“ definiert, die in Schritt 2 erst eingebunden werden muss.

Zusätzliche Targets für Cloud-Dienst Projektdatei(*.ccproj) - Schritt 2

Zusätzliche Targets für Cloud-Dienst Projektdatei(*.ccproj) – Schritt 2

Die Schritte 3 und 4 führen die Transformationen der Dienstdefinitionsdatei und Dienstkonfigurationsdatei durch.

Zusätzliche Targets für Cloud-Dienst Projektdatei(*.ccproj) - Schritt 3 und 4

Zusätzliche Targets für Cloud-Dienst Projektdatei(*.ccproj) – Schritt 3 und 4

Die „Source“ und „Destination“ Attribute des TransformXml-Tasks in Schritt 3 verweisen auf die Dienstdefinitionsdatei, die später im Dienstpaket bzw. im Emulator verwendet wird. Das „Transform“ Attribut (gelb) verweist auf den Namen der Datei, welche die Änderungen enthält (bspw. „ServiceDefinition.Local.csdef“ oder „ServiceDefinition.Cloud.csdef“). In Schritt 4 passiert dasselbe, nur das wir dort mit der Dienstkonfigurationsdatei und einer entsprechenden Transformationsdatei arbeiten.

Die Transformationsdateien, welche die Änderungen pro gewählter Konfiguration(„$(TargetProfile)“) enthalten, müssen wir erst erstellen und dem CloudService-Projekt hinzufügen. Hier der Inhalt der Transformationsdatei für die Dienstkonfiguration unseres Beispiels:

Zusätzliche transformation der Dienstkonfiguration

Transformationsdatei “ServiceConfiguration.CloudTest.Certificates.cscfg”

Und die Transformationsdatei für die Dienstdefinition des Beispiels:

Transformationsdatei " ServiceDefinition.CloudTest.csdef"

Transformationsdatei ” ServiceDefinition.CloudTest.csdef”

Das Entfernen des Zertifikats zur Sicherung des RDP Zugangs für die lokale Entwicklungsumgebung habe ich mir hier aus Platzgründen gespart. Um das zu bewerkstelligen müsste man noch weitere Transformationsdateien („ServiceDefinition.Local.csdef“ und „ServiceConfiguration.Local.Certificates.cscfg“) erstellen und dem Projekt hinzufügen, um die überflüssigen Einträge zu entfernen.

Die Transformationsdateien müssen wir im Ordner des CloudService-Projektes ablegen. Das Hinzufügen zusätzlicher Dateien zu diesem Projekttyp geht leider nicht über die GUI. Hier sind die notwendigen Änderungen an der Projektdatei(*.ccproj):

Änderung der *.ccproj Datei um zusätzliche Transformationsdateien einzubinden

Änderung der *.ccproj Datei um zusätzliche Transformationsdateien einzubinden

Mit dieser Methode kann man sowohl Dienstkonfiguration als auch Dienstdefinition, ohne sonderlichen Aufwand, seinen Bedürfnissen anpassen. Den Visual Studio Designer für die Konfiguration des Azure Cloud-Dienstes kann man weiterhin nutzen ohne, dass es zu Konflikten kommt. Diese Modifikationen wurden bisher unter dem Azure SDK Version 1.8 und 2.0 getestet. Das einzige Problem bei älteren (oder kommenden) Versionen sind die unterschiedlichen XML-Strukturen der *.csdef und *.cscfg Dateien, wobei man lediglich die eigens erstellten Transformationsdateien umbauen müsste.

Alle Dateien des Beispielprojektes sind im Anhang zu finden (ohne Zertifikate).

Autor: Sascha Blickensdörfer

PT_XING_SBlickensdoerfer

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

 

 

 

 

 

 

 

 

 

Die schwarze Magie mit XML Mapping in Word 2013 als BusinessObject-Export

Donnerstag, 25. Juli 2013

bildteaser_blog_072013Kennen Sie das Problem bei allen üblichen Reporting Suites, dass exportierte Word-Dokumente schlecht bis garnicht bearbeitbar sind? Der Aufbau des Dokumentenlayouts wird mit Tabellen oder gar Frames zusammengehalten und der Benutzer hat seine Mühe, mal eben ein paar Zeilen einzufügen. Doch was ist, wenn der Kunde einen vollständigen Export benötigt, dessen Resultat (also das Word-Dokument) auch gut, wenn nicht sogar sehr gut, bearbeitbar ist? Was ist, wenn die Vorlage dafür auch noch vom Kunden änderbar sein soll? “Back to the roots” ist die Lösung, denn Microsoft bietet hierfür eine einfache, mächtige und kaum bekannte Möglichkeit: XML Mapping

Was ist XML Mapping?

Schwarze Magie! Doch schweifen wir für einen Moment ab. Der Weg zu diesem Lösungsansatz führte über den Gedanken der Word-Vorlagen und Serienbriefe. Es musste doch irgendwie möglich sein, einem Word-Dokument beizubringen, dass es Felder automatisch ausfüllt und die dafür nötigen Daten aus irgendeiner Datenquelle zieht. Grundsätzlich ist dies auch völlig problemlos möglich, wenn man ein paar einfache Daten anbinden will.

Doch in der Realität braucht man eben immer etwas mehr, als das schöne bunte Beispielprojekt einem zeigt. So auch hier, denn es musste auch möglich sein, anhand der Daten einzelne Tabellen oder Tabellenzeilen zu wiederholen. Der Ansatz des Serienbriefs zerschellte also in tausende kleine Teile. Auch die Word-Vorlagen führten nicht zum Ziel. Irgendwie muss das doch aber funktionieren? Vielleicht fügt man dem Dokument einfach ein wenig VBA hinzu? Klar, das würde auch funktionieren, aber wer möchte schon freiwillig die Ausführung von VBA in einem Word-Dokument aktivieren, welches man von einem Internetportal heruntergeladen hat? Und selbst wenn, will man sowas denn veröffentlichen? Eher nicht.

Fast schon aufgegeben, fand sich dann jedoch ein Menüpunkt “XML-Zuordnungsbereich” im Entwicklertools-Menü, welcher vielversprechend klingt und förmlich darauf wartete, dass man ihn klickt.

XML-Zuordnungsbereich

Wie genau funktioniert XML Mapping nun?

XML-Zuordnung
Mit einem Klick auf den genannten Knopf öffnet sich ein Menü “XML-Zuordnung” am rechten Bildschirmrand. In diesem sieht man eine Dropdown-Liste mit allen verfügbaren XMLs, welche im Dokument eingebettet sind, und deren inhaltliche Struktur. Standardmäßig sieht man daher erst einmal die üblichen Dokumenteigenschaften mit den Daten für Autor, Titel, Beschreibung, usw.

Es scheint also, als könne man eine XML-Struktur inkl. Daten in ein Word-Dokument einbetten. Da man .docx-Dateien problemlos mit dem OpenXML SDK bearbeiten kann, war dies also schonmal der erste Lichtblick. Sollte es tatsächlich möglich sein, dass man mit nur wenigen Zeilen C# ein ganzes serialisiertes BusinessObject in Word einbetten kann, welches wiederum im Word-Dokument vorgefertigte Felder ausfüllt? Ja, genau das sollte es.

Doch erst einmal müssen wir eine Vorlage erstellen. Dazu legen wir uns eine XML-Datei mit der gleichen Struktur wie unser zukünftiges serialisiertes BusinessObject an, jedoch erst einmal ohne Daten. Warum? Nun, es ist eben eine Vorlage. Das vorbereitete XML soll ja ersetzt werden. Ein Klick in die Dropdown-Liste zeigt uns einen Menüpunkt, mit welchem wir unsere XML-Struktur dem Word-Dokument bekannt machen können.

XML-Zuordnung - Neue Komponente
In meinem Beispiel verwende ich dazu dieses XML als Vorlage.

Ist das erledigt, haben wir unsere XML-Struktur zur Verfügung und können unsere Felder hinzufügen. Dabei kann man sogar zwischen unterschiedlichen Typen wählen und somit sogar eine Datumsauswahl direkt im Word-Dokument anbinden, was die Bearbeitbarkeit deutlich erhöht. Dazu Klicken wir einfach mit der rechten Maustaste auf das gewünschte XML-Element und es öffnet sich folgendes Menü.
Kleiner Tipp: Bei leeren XML-Feldern wird einem automatisch der Standardtext angezeigt. Diesen kann man ändern, wodurch auch bei leeren Feldern ein beliebiger Text als Fallback stehen kann.

XML-Zuordnung - Steuerelement

Und was ist mit Wiederholungen?

Da sind wir auch schon beim Kern. Bis hier hin ist ja alles schön und gut, wäre aber auch mit einer einfachen Serienbrief-Datenbindung möglich gewesen. Doch wir wollen ja Wiederholungen in Wiederholungen in Wiederholungen in […]. Dazu klickt man einfach mit der rechten Maustaste auf das XML-Element, welches sich wiederholt, und verwendet den erscheinenden Menüpunkt. Der Einfachheit halber kann man sich auch eine paar Absätze, Tabellen und Texte vorbereiten, markieren und mit diesem Menüpunkt eine Wiederholung daraus erzeugen. Diese Wiederholungen lassen sich sogar noch sinnvoll benennen, wodurch der Nutzer nützliche Menüpunkt erhält.

XML-Zuordnung - Wiederholung

Verarbeitung und Beispiel

Nun muss das Dokument nur noch nach den eigenen Vorstellungen gefüllt werden. Das war’s dann auch schon.
Die damit erstellte Vorlage, welche lediglich ein simples Word-Dokument (docx) mit einer vorbereiteten und eingebetteten XML-Struktur ist, muss nun nur noch mit dem OpenXML SDK bearbeitet werden. Es muss also das Dummy-XML, welches wir im obigen Schritt hinzugefügt haben, ersetzt werden. Entgegen der unten verlinkten Quelle, muss diese Ersetzung natürlich nicht mit VBA-Code innerhalb des Dokuments geschehen. In meinem gleich folgenden Beispiel habe ich dafür dieses XML mit Daten verwendet.

Den Rest erledigt Word beim Öffnen des Dokuments von selbst. Es füllt die Felder und erzeugt die einzelnen ausgefüllten Wiederholungen, wie man im Beispiel-Dokument wunderbar sehen kann. Hierfür habe ich natürlich wieder ein Beispiel vorbereitet, welches nur einen Klick entfernt ist.
Kleiner Tipp: Im Bearbeitungsmodus erkennt man die Magie des Ganzen erst richtig.

Fazit

Es ist also sehr einfach möglich, dem guten Microsoft Word beizubringen, wie es ein Dokument mit Daten zu füllen hat. Das enthaltene XML (bzw. das serialisierte BusinessObject) ist natürlich schnell und einfach mit C# und dem OpenXML SDK in das Dokument eingefügt. Ein komplettes Aufbauen des Dokuments mit dem OpenXML SDK oder aufwändigem Code bleibt einem erspart. Dadurch, dass das Dokument in Word selbst erstellt wird, ist es am Ende für den Nutzer genauso einfach zu bearbeiten, wie die Vorlage selbst. Aufgrund der Nützlichkeit der Wiederholungen ist es zudem noch einfacher für den Benutzer.
Und das Beste an dieser Methode ist, dass die geänderten Daten (inkl. der Wiederholungen) in die XML-Struktur zurück geschrieben werden, wenn der Nutzer auch die entsprechenden Felder verwendet. Dadurch wäre sogar ein Re-Import der Daten denkbar. Wenn das mal nicht nach schwarzer Magie klingt!

Quellen/Links: OpenXML SDK, XML Mapping, CustomXML mit dem OpenXML SDK
Autor: Dirk Sarodnick
Google+

ProTechnology Webseite nun auf ASP.Net. Von Redirect, Routing-Regeln und Sonderzeichen …

Donnerstag, 18. Juli 2013

bildteaser_blog_072013Im Juli war es soweit: Unsere neue Webseite ist online gegangen. Ein Besuch lohnt sich, denn der neue dynamische Webseitenaufbau sowie der hinzugekommene News-Bereich verraten stets Aktuelles zu Ihren Wunschthemen. Doch nun zum heutigen Beitrag aus der Kategorie „Der Verzweiflung nahe“ oder „wenn Routing-Regeln trotz offensichtlicher Korrektheit willkürlich nicht funktionieren“. So geschehen im Zusammenhang mit der Einrichtung unserer neuen Unternehmenswebsite. Aber, wie so häufig, lag der Fehler auch hier im Detail …

Anders als unser vorhergehender Internetauftritt basiert unsere neue Seite nun – wie es sich für ein Microsoft-Systemhaus gehört – auch auf Microsoft-Technologien. So setzen wir nicht mehr PHP sondern ASP.Net unter Verwendung von DotNetNuke als Content Management System ein.

 

routing-website_alt_neu

Aus Alt mach Neu

Da sich natürlich strukturell einiges getan hat sind die neuen Inhalte nun auch über neue URLs zu erreichen. Für Benutzer, die uns über die Startseite besuchen, ist das kein Problem. Allerdings sollten auch diejenigen, die sich zum Beispiel Lesezeichen gesetzt haben, nicht auf einer unschönen 404-Fehlerseite landen – und gleiches gilt freilich auch für Suchmaschinentreffer.

 

routing-bing_urls

Von Bing indexierte Seiten

Deswegen holt man sich in so einem Fall zum Beispiel über die „Webmaster Tools“ der namhaften Suchanbieter eine Liste aller indexierten Seiten ab und stellt über entsprechende Weiterleitungsregeln sicher, dass Aufrufe der alten URLs an einer sinnvollen neuen Stelle herauskommen. Diese Weiterleitungen versieht man mit dem HTTP-Code 301, der angibt, dass es sich um eine dauerhafte und nicht nur temporäre Situation handelt. Soweit also zur Theorie, im Regelfall ist das auch tatsächlich kein kompliziertes Vorhaben.routing-excel

Links die alte, rechts die inhaltlich am besten passende neue URL

In einer ASP.Net Anwendung gibt es nun verschiedene Möglichkeiten, das zu bewerkstelligen. Wir haben uns dafür entschieden, die Regeln über die „web.config“-Datei zu verwalten. Praktisch sieht das also folgendermaßen aus:

routing-web_config

Weiterleitungsregeln in der web.config

Eingestellt sind Weiterleitungen, die alle Aufrufe von ehemaligen Dateien zum Download abfangen und in unseren neuen Downloadbereich umleiten sowie separate Weiterleitungen für Aufrufe von konkreten alten Seiten. Soweit so gut, flugs die Konfigurationsdatei aktualisiert und getestet. Klappt, alles prima. Noch eine Stichprobe, auch alles gut. Aller guten Dinge sind drei, also noch ein letzter Versuch und … 404, Seite nicht gefunden. Zunächst mal kratzen wir uns also am Kopf und schauen nochmal in die Datei hinein. Stimmt die URL? Irgendwo ein Tippfehler? Kann eigentlich nicht sein, war ja alles Copy & Paste. Augenscheinlich ist also alles gut, dennoch funktionieren aber einige Regeln, scheinbar willkürlich, einfach nicht.

Einige Versuche mit geleerten Caches, anderem Browser und ausgewerteten IIS Logs später ist die Situation noch immer ungeklärt. So etwas Seltsames kommt einem selten unter und langsam gehen dann auch die Ideen aus …

Kurz davor stehend, kurzerhand eine andere technische Variante der Weiterleitung zu verwenden, gab es aber dann doch noch ein winziges Detail, welches zufällig ins Auge fiel. Bei Aufruf einer der funktionierenden Weiterleitungen war kurz nach Absenden der Anfrage für den Bruchteil einer Sekunde eine an die URL angehangene Zeichenfolge zu sehen, welche da eigentlich nicht hingehört. Den Moment abgepasst und per Screenshot festgehalten sah besagte URL folgendermaßen aus:

routing-url

URL mit codierten Sonderzeichen

Also die codierten Zeichen schnell in einer ASCII-Tabelle nachgeschlagen und siehe da – offenbar werden drei Sonderzeichen an die URL angehängt. Die Frage ist nur, wo kommen die her? Und genau an dieser Stelle kam der rettende Geistesblitz …

routing-notepad1

routing-notepad2

Anzeige von unsichtbaren Zeichen und geändertes Encoding

Schauen wir uns die besagte „web.config“ in einem passenden Editor wie Notepad++ noch einmal genauer an, kann man über verschiedene Optionen sowohl unsichtbare Zeichen sichtbar machen, als auch die Kodierung der Datei ändern. Ursprünglich auf UTF-8 eingestellt, waren die drei Zeichen also in der Weiterleitungsregel zwar vorhanden, wurden aber nicht angezeigt. Damit wird diese natürlich auch nicht verarbeitet, solange die Sonderzeichen am Ende nicht mit in die URL eingegeben werden. Da die URL aber in diesem Fall durch Copy & Paste aus der Konfigurationsdatei in den Browser eingefügt wurde, waren auch die Zeichen mitgekommen.

Nach Überprüfung aller Regeln und entsprechenden Korrekturen funktionierte dann alles tadellos und wie erwartet. Prima! Bleibt jetzt nur noch die Frage, wie sie da hineingeraten sind. Doch auch dies ließ sich schnell klären: die einzelnen URLs wurden nämlich aus dem oben abgebildeten Excel-Dokument ebenfalls per Copy & Paste übernommen – samt unsichtbarer Sonderzeichen, die je nachdem ob von vorn oder hinten mit dem Markieren begonnen wurde entweder dabei waren oder nicht.

Autor: Tom Halank

Neue Ära – Wie wandelt sich die Technologie und die Anforderungen an die IT?

Freitag, 14. Juni 2013

blog_neue_era2Welche Hardware man benutzt, wird zunehmend egal. Wichtiger ist, dass uns unsere Daten überall zur Verfügung stehen, dank verschiedener Cloud-Dienste und kompatibler Hardware – alles kein Problem. Gleichzeitig stellt dies aber auch eine mannshohe Herausforderung sowohl für App-Entwickler als auch für Unternehmen, die Cloud-Dienste anbieten, dar. Letztlich erfordert es definitiv ein Umdenken beim Anbieter und Konsumenten. 

Zahlreiche Angebote an Hardware und Provider erhöhen die Anforderung an die Entwicklungsabteilung: Die meisten Menschen verwenden Windows PCs aber kein Windows Phone, sondern eher Android oder iPhone. Schon gibt es Inkompatibilitäten aufgrund unterschiedlicher Dienste. Würde man nur in der Windows-Welt bleiben, fehlten trotzdem einige Apps, die nicht für beide Systeme zur Verfügung stehen. Außerdem mag kaum ein Nutzer all seine Daten einem Anbieter anvertrauen. Bevorzugt wird ein Mix, der aber Apps auf allen Systemen voraussetzt. Auch wenn Tablets und Smartphones immer wichtiger werden: Laptops und PCs werden so schnell nicht verschwinden. Stattdessen werden weitere Kategorien hinzukommen, wie Smartwachtes, Wohnzimmerkonsolen, Media Server usw. . Auf all diesen Geräten soll möglichst ohne viel Aufwand Zugriff auf verschiedenste Daten erfolgen.

Eine App-Entwicklung muss somit mit möglichst vielen Systemen kompatibel sein, im besten Fall mit allen.

Anforderungen an moderne Applikationen ändern sich, wie schon erwähnt, ständig und immer schneller. Dies erfordert dementsprechend die Bereitstellung schnellerer, günstigerer, besserer, interaktiver Anwendungen mit rascher Bereitstellung und Auslieferung von Funktionalität. Dafür erforderlich ist ein angepasster Lebenszyklus mit den wichtigsten Elementen Feedback, Qualität und Lieferung. ProTechnology hat den Weg erkannt und nutzt bei der App-Entwicklung agile Prinzipien: Development in kleinen Iterationen mit dem Ziel, diese so schnell wie möglich zu durchlaufen.

Agile Softwarentwicklung

Agile Web- und Software-Entwicklung

 

Wie bereits festgestellt, kann sich jeder Mitarbeiter oder jede Privatperson aus den verlockenden Angeboten an Tablets, Phablets, Smartphones, Hybriden oder Laptops einen bevorzugten Mix zusammenstellen. Diese Welle wird auf Unternehmen überschwappen: In Zukunft möchten Mitarbeiter ihre eigenen Geräte beim Arbeitgeber mitbringen können. Unternehmen müssen somit darüber nachdenken, „Bring Your Own Device (BYOD)“ zu unterstützen.

Nur wie realisiere ich es, dass auf privaten Geräten unternehmensrelevante Daten sichtbar werden?

BYOD bedeutet gleichzeitig eine Kostenersparnis für Unternehmen. Viele IT-Entscheidungsträger äußern allerdings Risiken für die Sicherheit ihres Unternehmensnetzwerks, die mit BYOD in Verbindung gebracht werden. ProTechnology hat sich zu diesem Thema Gedanken gemacht, wie dieser Skepsis mit aktuellen Microsoft-Technologien entgegen gewirkt werden kann. Mit SCCM.eu haben wir den System-Manager SCCM in die Cloud gehoben. Den Unternehmen wird eine ConfigManager 2012 SP1 CU1 Infrastruktur bereitgestellt, die sich leicht in die bestehende Umgebung (Active Directory uvm.) integrieren lässt. BYOD ist mit SCCM.eu nun sicher: Ihre Mitarbeiter bekommen auf Wunsch, den Zugang zu einer für Sie individuell gestalteten Unternehmenswebseite. Dort haben diese nach vorheriger Anmeldung die Möglichkeit ihr eigenes Notebook, Tablet oder auch Windows Phone, sowie jedes andere Smartphone, in Ihrem SCCM.eu-Mandanten zu registrieren. Das Gerät kann im Nachgang leicht mit wichtiger Software betankt werden und Ihnen steht es zu jeder Zeit frei, das Gerät aus dem Unternehmensnetzwerk wieder zu entfernen.

Der IT-Abteilung steht ein Wandel bevor.

Sie müssen sich aus den eben genannten Gründen neu definieren und neu ausrichten. Genauso, wie der IT-Dienstleister: Er entwickelt sich vom traditionellen IT-Betreiber hin zum Service Anbieter. Er agiert als Partner und nimmt die Business-Anforderungen seiner Kunden auf und versucht mit den jeweils passenden Services kosteneffizient die geforderte Qualität und dem Compliance-Anspruch gerecht zu werden.

Wir befinden uns am Beginn einer neuen Ära, in der sich Technologie, wie vorgestellt, endlich dem Menschen zuwendet. Nicht wir passen uns der Technik an, sondern die Technik passt sich uns an. Über diese Themen berichtet die ProTechnology gemeinsam mit Microsoft am 05.06.2013 in der Think:ademy. Die Teilnehmer erfuhren im Rahmen der „New Era“-Veranstaltung, warum Microsofts neue Mission Vielfalt und Wahlfreiheit ist, und in deren Ausdruck Services und Devices die Hauptrolle spielen. Haben Sie die Veranstaltung verpasst, aber Interesse an diesem Thema, so sprechen Sie uns. Wir zeigen Ihnen gerne anhand von vielen unterhaltsamen Beispielen den technologischen Wandel.

SONY DSC SONY DSC
“New Era”-Veranstaltung @Think:ademy, Dresden

Autor: Melanie Wolf

Lokalisierung aus der Datenbank in ASP.NET MVC

Mittwoch, 12. Dezember 2012

Es war einmal ein kleines Kind. Dieses lief seit einigen Monaten und erfreute sich großer Beliebtheit. Doch dieses Kind war nicht so einfach zu betreuen, wie der Herr Vater sich das vorstellte. Bei der Korrektur eines Sprachfehlers, musste man es ständig neu gebären, was auch die Frau Mutter nicht sehr erfreute. Also dachte sich der Herr Vater: “Es muss doch eine Möglichkeit geben, die Sprache des Kindes direkt in seinem Kopf zu korrigieren.”  So, oder so ähnlich, muss es wohl gewesen sein, als der Mensch lernte, seine Sprache in seinem Kopf zu speichern. Doch was ist, wenn das Kind ein Projekt ist? Ständig muss man die Anwendung neu deployen, obwohl man doch nur ein paar Texte und/oder Benennungen verändert hat. Oder man lagert Bereiche, welche sich häufiger ändern (könnten), einzeln in die Datenbank aus. Das klingt nicht nur unflexibel, es ist auch unflexibel. Gerade bei längeren Release-Zyklen oder ewig ladenden Azure-Instanzen wird so eine kleine Textänderung schnell zur Geduldsprobe. Also ab mit den Texten in die Datenbank… und zwar zackig!

Meist nutzt man Resourcendateien, um unterschiedliche Sprachen seiner Webanwendung bereitzustellen. So mancher hat dieses Problem sicherlich längst erkannt und greift die einzelnen Sprachelemente direkt aus der Datenbank ab, statt Resourcen zu verwenden. Doch was ist mit Fremdassemblies, die sich möglicherweise nur über Resourcen lokalisieren lassen? Hier kommt der Ansatz mit einer ResourceProviderFactory zum Zuge. Diese gibt einem die Freiheit, die angefragten Resourcenwerte bspw. aus einer Datenbank oder einem Service zu saugen. Ganz nebenbei lässt sich diese natürlich mit der manuellen Variante ansteuern, um ggf. mächtigere Abfragen zu tätigen. Doch bleiben wir beim Thema.

Schritt 1: Wie sieht so eine ResourceProviderFactory aus?

Bis dahin also noch nichts Spektakuläres. Die Factory erstellt in unserem einfachen Beispiel lediglich eine neue Klasse des ResourceProviders. Dieser enthält nun unsere Logik, um die entsprechenden Resourcen, möglichst geschickt, aus der Datenbank zu saugen. Dabei wird entweder lediglich der Klassenname bei globalen Resourcen oder der virtuelle Pfad bei lokalen Resourcen als ResourceSet übergeben, welches wir in unserem ResourceProvider halten werden. Je nach belieben kann dies für globale und lokale Resourcen in einzelne Klassen getrennt und/oder zusätzlich gefiltert werden.

Schritt 2: Der ResourceProvider verrichtet also das eigentliche Werk. Aber wie?

Dazu muss unser ResourceProvider lediglich die Interfaces “IResourceProvider” und “IImplicitResourceProvider” implementieren. Das sieht im Wesentlichen folgendermaßen aus:

Wie so oft, sagt sich das allerdings wesentlich einfacher, als es dann tatsächlich ist. Gleichermaßen sieht der entstandene Code viel komplexer aus, als er dann tatsächlich ist. Schwer, einfach, schwer, einfach, was denn nun? Angesichts des Gesamtkunstwerks, was uns schon bald erwartet, würde ich zu “Schw’einfach” tendieren. Aber sehen Sie selbst.

Zunächst implementieren wir die Methoden “GetObject” beider Interfaces. Auch hier machen wir kein großes Hexenwerk und verweisen auf eine allgemeingültige Methode “GetObjectInternal”. Lediglich die Methode “ConstructFullKey” zerlegt unseren ImplicitResourceKey, um den eigentlichen ResourceKey herauszufiltern.

Diese Methode “GetObjectInternal” hat eine einfache Aufgabe: Sie holt nun endlich unseren Text aus der Datenbank. Dies geschieht im Folgenden über einen “LocalizationService”, welcher dann direkt auf ein typisiertes DataSet zugreift. Für die Abfrage werden hier die drei Werte zur Identifikation eines Resourcevalues übergeben: Culture (bspw. “de-DE”), ResourceSet (bspw. “Errors” oder “/Views/Shared/Site.Master”) und ResourceKey (bspw. “SiteTitle”). Als Ergebnis dieser Methode erhält man den passenden String (bspw. “Startseite”).

Damit haben wir nun einen wichtigen Teil unserer Anwendung fertiggestellt. Doch aufmerksame Leser werden sicherlich bemerkt haben, dass wir noch nicht alles implementiert haben. Uns fehlt noch die Property “ResourceReader” und die Methode “GetImplicitResourceKeys”, welche eine ICollection zurückliefert. Zudem fällt im obigen Bild auf, dass die Methode “GetObjectInternal”, neben der Serviceanfrage in der Datenbank, zusätzlich eine Methode “GetResourceCache” anspricht.

Schritt 3: ResourceReader und ICollection? Das klingt verrückt.

Die nun angerichtete Verwirrung lässt sich ziemlich schnell wieder auflösen. Grundsätzlich unterscheidet man in diesem ganzen ResourceProvider zwischen zwei Varianten, um Resourcen abzuholen: Einen einzelnen Wert oder eine Auflistung von Werten eines bestimmten ResourceSets und/oder einer spezifischen Culture. Erstere haben wir in unserer Methode “GetObjectInternal” gebündelt abgehandelt. Zweitere werden wir nicht ganz so elegant bündeln, nutzen aber im Kern die gleiche Funktionalität. Doch genug des Vorgeplänkels und zurück in die Praxis.

Fangen wir mit der Methode “GetResourceCache” an. Diese holt uns nun die erwähnten Werte aus der Datenbank und sortiert sie fein säuberlich in unseren Cache. Dazu nutzt sie die übergebene Culture und das festgelegte ResourceSet. Wenn erledigt, gibt sie unseren Cache zurück, damit der Aufrufer damit arbeiten kann.

Und weil es gerade so spaßig ist, springen wir direkt zu der Methode “GetImplicitResourceKeys”. Der nun folgende Code mag durchaus Geschmackssache sein, sieht aber komplizierter aus, als er tatsächlich ist. Wir lesen lediglich unseren ResourceReader aus, filtern dabei nach unseren keyPrefix und trennen schlussendlich nur den ResourceKey unter Verwendung unseres keyPrefixes, um damit einen ImplicitResourceKey erstellen zu können. Zurückgegeben wird also letztlich nur eine ICollection von ImplicitResourceKeys. Nähere Infos dazu lassen sich im MSDN nachlesen.

Zu guter Letzt benötigen wir noch unseren ResourceReader, den wir bereits oft genug verwendet, aber bisher nicht implementiert haben. Groß angekündigt, aber weniger spektakulär: Unser herzallerliebster ResourceReader ist im Grunde nämlich nichts weiter, als ein kleiner Wrapper für unser ResourceCache-Dictionary. Dies sieht dann wie folgt aus.


Schritt 4: Und wie binde ich dieses Kunstwerk nun ein?

Das ist wohl mit Abstand der “schwierigste” Teil unseres Abenteuers. Man fügt einfach folgendes Schnipsel in seine web.config und schon kann sich gefreut werden. Kernbestandteil ist hier natürlich der Wert des Attributs “resourceProviderFactoryType” des Elements “globalization”.

Fazit

Ich hoffe, den meisten Lesern ist bis hierhin bereits klar geworden, welche Vorteile die Implementierung des ResourceProviders und der ResourceProviderFactory mit sich bringt. Es ist nun möglich, viele Stellen in gewohnter Weise zu lokalisieren. Selbst die guten alten meta:resourcekey-Angaben funktionieren damit. Zudem kann man, wie in diesem Beispiel, einen eigenen Service, den man vorher ggf. nur manuell angesprochen hat, zur Lokalisierung anbinden.

Trotz der ganzen Vorteile überkommt mich immer ein seltsames Gefühl, wenn ich mir den entstandenen Code anschaue. “Schw’einfach” trifft es, denn es ist schwer und einfach zugleich, was in meinem Fall aber hauptsächlich an der Verworrenheit der beiden Interfaces liegt. Aber es funktioniert, ist nützlich und kann mit ein wenig mehr Arbeit durchaus noch “sauberer” implementiert werden.

Zudem sollte noch erwähnt sein, dass die Auslagerung der Lokalisierung in die Datenbank, einen weiteren Vorteil mit sich bringt: Es kann problemlos eine Administrationsoberfläche (Web-/ Windowsanwendung) aufgesetzt werden. Mit dieser kann man sogar Resourceninhalte komfortabel mit HTML formatieren, was je nach Einbindung der Resource (<%: vs <%=) kodiert oder nicht kodiert wird. Auch denkbar wäre die Möglichkeit für vorhandene Benutzer, mit an der Übersetzung zu arbeiten.

Als kleiner Bonus zur Weihnachtszeit gibt es die gesamte Solution auch noch zum Download.
In diesem Sinne: Viel Spaß damit!

Quellen: MSDN
Autor: Dirk Sarodnick
Google+

Veröffentlichen einer Webseite – der nun einfache Weg mit Visual Studio 2012

Donnerstag, 06. Dezember 2012

Visual Studio 2012 stellt eine überaus gelungene Möglichkeit bereit, um Webseiten auf einem Webserver zu veröffentlichen. Wie genau die One-Click-Veröffentlichung mit Visual Studio vonstatten geht, vermittelt dieser MSDN Eintrag.

Der eine oder andere dürfte jedoch beim Versuch eine Veröffentlichung durchzuführen, folgenden Fehler bekommen haben:

In den meisten Umgebungen hält man sich einfach an die von Microsoft beschriebenen Schritte um einen Webserver für die Annahme von Web-Veröffentlichungen zu konfigurieren: der IIS ist schon da und Web Deploy 3.0 wird über den Web Platform Installer bereitgestellt. Dann stellt man aber fest, dass man noch den IIS Verwaltungsdienst benötigt, um zum Ziel zu kommen. Hier beginnt allerdings “der Hamster zu humpeln”, denn wenn die eben genannte Reihenfolge eingehalten wird, werden beim Installieren des Web Deploy-Paketes für den Betrieb notwendige Teile stillschweigend übersprungen.

Installiert man Web Deploy 3.0 mittels des hier erhältlichen MSI-Paketes, wird deutlicher wo das Problem liegt: das linke Bild veranschaulicht, dass der Dienst nicht installiert ist. Ist er installiert, wird das rechte Bild angezeigt:

Ist der IIS Verwaltungsdienst bei der Installation von Web Deploy 3.0 noch nicht vorhanden gewesen, bleibt einem nur die Option erneut zu installieren oder die installierten Funktionen von Web Deploy über die Systemsteuerung zu ändern. Zu prüfen ist jetzt noch, ob die beiden Dienste (Webbereitstellungs-Agent-Dienst und Webverwaltungsdienst) auch automatisch gestartet werden und laufen.

Übernehmen sollte der Web Platform Installer eigentlich auch die Freigabe des Ports 8172 in der Firewall. Ist diese Freigabe nicht vorhanden, klappt die Verbindung nicht.

Versucht man jetzt erneut die Veröffentlichung im Visual Studio sollte man in etwa folgendes Ergebnis bekommen:

Fazit: Um der Überschrift nun dennoch gerecht zu werden, haben wir ein kleines Powershell Script bereitgestellt, was die oben beschriebenen Schritte automatisch durchführt.

Autor: Kirsten Kluge
Quellen: MSDN Eintrag, Web Deploy 3.0, Web Platform Installer, msi-Paket

 

Lohnt sich die Migration in die Cloud mit dem Team Foundation Server (TFS)?

Donnerstag, 08. November 2012

In der vergangenen Woche wurde die von Microsoft bereitgestellte Cloud-Variante des Team Foundation Server veröffentlicht. Die Beta-Phase ist damit beendet. Doch lohnt sich der Umstieg auf den “Team Foundation Service” bereits?

Zunächst stellt sich – wie bei allen Clouddiensten – die Frage nach der Sinnhaftigkeit der Verschiebung einer On-Premise Lösung in die Wolke. Speziell beim Team Foundation Server ist diese Frage schnell beantwortet: klar! Da in der Softwareentwicklung zunehmend eine Dezentralisierung der Teams festzustellen ist und dieser Trend durch die Verfügbarkeit von modernen Werkzeugen zur E-Collaboration unterstützt wird, ist bereits jetzt fast jeder TFS von “draußen” erreichbar und die Entwickler arbeiten von unterschiedlichen Standorten aus an dem gleichen Projekt.

Da oftmals auch bestimmte SLAs für den Betrieb von Software, etwa für die Fertigungssteuerung, einzuhalten sind, ist es meist sogar zwingend erforderlich, dass im Notfall von überall Zugriff auf den Quellcode gewährleistet ist. Abgesehen vereinfachter Bereitstellung und Zugriff gelten natürlich auch die bekannten Cloud-Vorteile im Allgemeinen.

Insofern ist der Ansatz durchaus sehr interessant, zumal die SVN- und Git-Konkurrenz auch nicht schläft.

Hinsichtlich Sicherheit und Compliance bestehen ja mitunter noch immer Vorbehalte, sobald das Wort “Cloud” fällt. Im Kontext der Softwareentwicklung sind diese aber aufgrund der fachlichen Nähe zu diesem Thema, wenn überhaupt vorhanden, eher gering ausgeprägt und mehr technischer statt prinzipieller Art. Für Windows Azure, welches die Grundlage für die Bereitstellung der TFS(ervices) bildet, existiert ein recht umfassender “Security Guide” der für die Zerstreuung letzter Bedenken sehr hilfreich ist.

Dennoch gibt es ein paar Einschränkungen, die derzeit (noch) für die Team Foundation Services gelten: Die Individualisierung von Prozesstemplates ist nicht möglich. Es besteht noch keine Integrationsmöglichkeit zu SharePoint, Project Server, etc. Es wird noch keine Active Directory-Federation unterstützt und es gibt geringere Reportingmöglichkeiten gegenüber dem klassischen Team Foundation Server.

Die wichtigste Neuerung, neben der Änderung der URL von “tfspreview.com” nach “tfs.visualstudio.com”, ist die Bekanntgabe der ersten Informationen zum Pricing. Eine sehr wichtige Information, da davon maßgeblich eine Entscheidung pro oder kontra abhängt: Teams bis zu 5 Entwicklern sind kostenlos. Die Anzahl an Projekten ist die beschränkt und aktuell kostenlos verfügbare Features, wie der Build Service, werden in der kostenlosen Version wahrscheinlich nicht verfügbar bleiben.

Dennoch existiert nach wie vor ein gewisser Unsicherheitsfaktor bezüglich der finalen Preisgestaltung, welche noch nicht feststeht und erst 2013 erscheint. Es ist jedoch davon auszugehen, dass schon allein aufgrund der Wettbewerbsfähigkeit eigentlich keine utopischen Preise aufgerufen werden dürften.

Die Infrastruktur ist also bereit und funktioniert. Wir haben intern die Preview schon seit längerer Zeit im Einsatz erprobt und ich kann guten Gewissens festhalten: keine substantiellen Probleme vorhanden. Ganz im Gegenteil, viele interessante Features funktionieren sehr gut. In ersten Versuchen bei einem unserer Entwicklungsteams haben wir zum Beispiel bereits sehr positive Erfahrungen mit dem Einsatz von KANBAN gemacht, welches sehr einfach auf zum Beispiel SCRUM aufgesetzt werden kann und bereits seit August zur Verfügung steht.

Genauere Details zu den angesprochenen Punkten können hier auch noch mal nachgelesen werden.

Der Umstieg klappte dabei unter Verwendung der TFS Integration Tools problemlos, eine entsprechende Anleitung steht im MSDN bereit. Letztlich handelt es sich aber um einen TFS 2012, es ist hilfreich, wenn man mit den zugehörigen Neuerung der 2012er Entwicklungslandschaft bereits einigermaßen vertraut ist.

Die abschließende Empfehlung lautet also auf jeden Fall, den Dienst unbedingt zu testen. Speziell für kleinere Projekte, an denen zum Beispiel mehrere Entwickler nur phasenweise arbeiten, kann man definitiv schon auf die Team Foundation Services setzen, zumal sich diese auch recht einfach übertragen lassen. Komplexe, größere Projekte sollten aber mindestens noch bis zur Veröffentlichung einer feststehenden Preisliste weiterhin lokal verwaltet werden.

Quelle: Security Guide, SCRUM, MSDN, TFS Integration Tools, Migration in die Cloud, Neuerungen

Autor: Tom Halank