Archiv für die Kategorie ‘Development’

OneNote heiratet CRM/SharePoint-Integrator

Freitag, 12. September 2014

Wedding coupleDer erste Schritt ist getan, denn ab sofort kann unser CRM/SharePoint-Integrator auch OneNote-Abschnitte und OneNote-Seiten erzeugen. Manchmal gehen Wünsche eben doch in Erfüllung, zumindest wenn es die Wünsche unserer Kunden sind.

Wie ist das möglich?

Beschäftigt man sich ein wenig mit der Materie, findet man die vor kurzem noch angekündigte OneNote-API. Jedoch kann diese API im aktuellen Status nur das OneNote-Notizbuch im eigenen OneDrive bearbeiten. Eine Bearbeitung eines im SharePoint liegenden Notizbuchs ist aktuell noch nicht möglich, aber immerhin bereits auf der Wunschliste.

Da aber auch wir nicht so lange warten wollen, haben wir analysiert, welche Alternativen es gibt. Erstaunlicherweise sind es sogar recht viele, die jedoch alle der Reihe nach aus Gründen der Performance oder Kompatibilität ausscheiden. Nur eine Alternative blieb, die Anfangs regelrecht gepflastert mit Stolpersteinen schien, die sich jedoch im Laufe der Zeit eher als Steighilfen erwiesen.

Wie habt ihr das gemacht?

Nun, allzu sehr möchten wir natürlich nicht ins Detail gehen. Soviel sei jedoch gesagt:
Wir nutzen für dieses Feature die Dienste der Office WebApps für SharePoint. Konkret simulieren wir dabei die Nutzung der OneNote WebApp in SharePoint. Das die entsprechende Implementierung natürlich recht komplex ist und viel Zeit in Anspruch nahm, sollte sich fast schon von selbst verstehen.

Wie schaut das Ganze nun aus?

Dazu haben wir wie üblich ein kleines Beispiel erstellt. In den folgenden Abbildungen haben wir eine Beispielkonfiguration für Sie vorbereitet. Zum besseren Verständnis der Möglichkeiten, zeigen wir Ihnen einen zweistufigen Aufbau.

1. OneNote-Abschnitt pro Firma

Mit dieser Konfiguration wird pro Firma ein OneNote-Abschnitt erstellt. Der Name des Abschnitts wird aus der Firmennummer und dem Firmenname zusammengesetzt, wodurch sich bspw. ein Abschnitt mit dem Name “1234 – Musterbau GmbH” ableitet. Dieser Abschnitt ist leer und erhält, wie in der Konfiguration angegeben, eine zufällige Farbe. Das Ergebnis könnte wie folgt aussehen.

2. OneNote-Seite pro Verkaufschance

Diese Konfiguration basiert auf der Annahme, dass bereits eine Konfiguration zur Erstellung von OneNote-Abschnitten pro Firma existiert, welche die ID des Abschnitts in das Feld “new_onenotesection_id” schreibt. Dieses Feld lesen wir in unserer Konfiguration zur Erstellung von OneNote-Seiten pro Verkaufschance wieder aus, wodurch die OneNote-Seite im vorher angelegten OneNote-Abschnitt erscheint. Das Ergebnis sollte dann wie folgt aussehen.

Fazit

Mit dem neuen Feature des CRM/SharePoint-Integrators zur Integration von OneNote, wird die komfortable Verwaltung von Notizen in OneNote mit der Struktur und Verwaltbarkeit des CRM gepaart. Eine Hochzeit ungleicher Produkte mit dem Ziel sich gegenseitig zu ergänzen. Was gibt es schöneres?

Autor: Dirk Sarodnick

Google+

Dynamics CRM 2013: Ihre Verkaufschancen-, Angebote und Produkte stets im Gleichgewicht.

Montag, 14. April 2014

Dynamics CRM_Ihre Verkaufschancen- und Angebotsprodukte im GleichgewichtDynamics CRM ist ein flexibles Produkt von Microsoft, das sich relativ einfach an Ihre Unternehmensanforderungen anpassen lässt. Manch individuelle Prozesse erfordern tiefergehende Anpassungen in Dynamics CRM, wie die kürzlich bei uns eingegangene Kundenanforderung.

Standardmäßig ist im Dynamics CRM folgende Business-Logik vorhanden: Angebote werden aus einer Verkaufschance generiert, jedoch gibt es im Nachgang keine automatisierte Synchronisation der eventuell geänderten Angebotsprodukte in die dazugehörige Verkaufschance. Heißt, passe ich die Preise der Angebotsprodukte an, so ist mein Forecast in der Verkaufschance verzerrt und der Mitarbeiter müsste die Differenz eigentlich beheben; dafür fehlt aber meist die Zeit oder man vergisst es einfach. Diese ineffiziente Vorgehensweise kann man mit Hilfe eines Plug-Ins unterbinden.

Problemanalyse

Auf den ersten Blick schien die Aufgabe einfacher zu sein, als sie dann tatsächlich war. Im Prinzip sollte es doch sehr einfach sein, zwei Entitäten miteinander abzugleichen. Die Werte müssen von einer Entität zur anderen kopiert werden. Aber wie die vorhergehende Analyse zeigte, sind die Angebotsprodukte nicht mit den Verkaufschancenprodukten verdrahtet: Quasi als ob die Kinder (die Angebotsprodukte) nichts von ihren Eltern (den Verkaufschancenprodukten) wissen. Fazit: Out-of-the-box gibt es keine eineindeutige Zuordnung zwischen Angebots- und Verkaufschancenprodukten. Diese benötigen wir jedoch, um die Produkte abgleichen zu können.

Eine Verkaufschance kann zudem mehrere Angebote haben. Hm.. Was nun? Welches Angebot muss denn letztlich aktualisiert werden, wenn ein Produkt in der Verkaufschance hinzugefügt, aktualisiert oder gelöscht wird? Für diesen Fall fanden wir zusammen mit dem Kunden einen Kompromiss: Geht man nach dem Prozess vom Kunden, so kann immer nur ein Angebot pro Verkaufschance zum Zeitpunkt X aktiv sein. Mit dem aktiven Angebot galt es die Produkte zwischen Verkaufschance und Angebot abzugleichen.

Problemlösung und Implementierung

1.      Produkte der Verkaufschance aktualisieren

Das erste Problem war schnell gelöst: Wir haben zur Angebots – (Produkt)-Entität ein zusätzliches Feld „opportunityproductid“ hinzugefügt, in dem die ID (GUID) der Verkaufsschancen -(Produkt)-Entität gespeichert wird. Um diese Speicherung zu realisieren, mussten wir auf ein externes Tool von einem MVP (Microsoft Most Valuable Professional) zurückgreifen: http://crm2011entitymaps.codeplex.com/. Das Tool kann versteckte Mapping-Regeln im Vergleich zum Standard-Interface verwalten. Nun dachten wir es sei gelöst, aber ein GUID-Feld kann vom Admin im Anpassungsbereich nicht erzeugt werden. Somit hinterlegten wir die ID zunächst als Textfeld und erzeugten im Nachgang via Plugin ( Step „Post-Create of opportunityproduct“) eine GUID, die wir für die Synchronisation benötigen.

2.      Produkte in dem Angebot aktualisieren

Wie vereinbart, werden die Angebotsprodukte nur in dem einzigen, aktiven Angebot aktualisiert. Der Ablauf für Create-, Delete-, Update-Operationen ist identisch:

  1. Aktives Angebot finden
  2. Das Angebot löschen
  3. Ein neues Angebot aus der Verkaufschance generieren
  4. Neuerstellte Angebot aktivieren

Dynamics CRM 2013 So synchronisieren Sie Ihre Verkaufschancen- und Angebotsprodukte_2

Hinweis: EntityOperations-Klasse ist unsere Sammlung von Funktionen zur Arbeit mit CRM-Entitäten. Das ist vergleichbar mit „Data Access Object“-Entwurfsmuster, welches die Funktionen zum Zugriff auf die Datenquellen kapselt.

Um ein Angebot aus der Verkaufschance zu erstellen, bietet das CRM SDK schon einige Funktionen:

Dynamics CRM 2013 So synchronisieren Sie Ihre Verkaufschancen- und Angebotsprodukte_3

Die Enums mit sämtlichen States können Sie im SDK unter …\SDK\SampleCode\CS\HelperCode\OptionSets.cs und in den generierten Proxy-Klassen finden. Ein Proxy können Sie mit Hilfe eines SDK-Tools CrmSvcUtil generieren. Auf den MSDN-Seiten finden Sie eine gute Anleitung zu diesem Tool.

Fazit

Der Kunde ist zufrieden, sein individueller Prozess konnte im Dynamics CRM umgesetzt werden und sein Forecast ist immer auf dem aktuellen Stand. Das Plug-In hat zudem Weiterentwicklungspotenzial: Es kann so angepasst werden, dass aus mehreren Angeboten nur eines zur Aktualisierung ausgewählt werden kann. Haben Sie dieselbe Anforderung oder möchten gerne auf diese Anforderung aufbauen? Dann kontaktieren Sie uns.

Autor: Walter Nuss

PT_Blog_VK_WNuss_jpg

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+

SharePoint (Online) in CRM (Online) integrieren? Go for IT!

Mittwoch, 04. Dezember 2013

SharePoint-CRM-IntegrationKennen Sie das Problem, wenn Dokumente im CRM nicht auch im SharePoint sind? Oder wenn zu einem Kunden jedes mal manuell eine passende SharePoint-Seite angelegt werden muss? Wir nicht mehr, denn wir haben eine Lösung.

[Randnotiz: Das ist unser Einführungs-Blogartikel. Erfahren Sie mehr auf unserer Produktseite.]

Seit Längerem haben wir eine Lösung in Betrieb, die uns so einige Integrationsthemen abnimmt. Anfänglich noch eher spartanisch, kann diese mittlerweile mit den Eigenheiten der neuen Onlinevarianten von CRM 2013 und SharePoint 2013 umgehen. Der eine oder andere Kunde bekam diese Lösung bereits, jedoch musste diese immer aufwändig angepasst und bereitgestellt werden. Doch nun haben wir eine CRM-Lösung, die bequem importiert und konfiguriert werden kann.

Was denn nun für eine Lösung?

Wir nennen ihn liebevoll “CRM-SharePoint-Integrator“. Es ist, wie bereits erwähnt, eine CRM-Lösung (Solution) die ziemlich einfach importiert werden kann. Dazu begibt man sich im CRM in das Menu “Einstellungen” > “Lösungen”. Dort angekommen wählt man “Importieren” und klickt sich durch den sich öffnenden Assistenten.

Import-Solution1

Was kann der CRM-SharePoint-Integrator?

Vereinfacht ausgedrückt, kann er für unterschiedlichste Ereignisse im CRM (bspw. das Anlegen/Ändern einer Firma) ein/mehrere SharePoint-Objekt/e (siehe Produktmatrix hier) im SharePoint anlegen. Im Folgenden möchten wir Ihnen ein paar Antworten auf die typischen Fragen zu, die uns als Microsoft Systemhaus in Kundenprojekten immer wieder begegnen beantworten:

Wie verbinde ich Microsoft SharePoint und Dynamics CRM?

  • Wie erstelle ich automatisch eine SharePoint-Webseite pro Account, Opportunity oder Kampagne im Dynamics CRM?
  • Wie erstelle ich nach Bedarf SharePoint Bibliotheken, – Webseiten etc. für Entitäten im Dynamics CRM?
  • Wie synchronisiere ich Accountdaten aus Dynamics CRM als Listeneintrag in SharePoint?

Die Standard-Integration bietet leider nur wenig Features, um SharePoint mit Dynamics CRM zu verbinden: Dynamische URLs werden erzeugt, eine Dokumentenverwaltung steht zur Verfügung. Mehr ist es leider nicht. Aber die Lösung CRM-SharePoint-Integrator von ProTechnology bietet viele Vorteile, wie Sie anhand der Produktmatrix unten sehen. Neben Dokumenten-Bibliotheken sind auch Standardlisten, benutzerdefinierte Listen (auch nach Vorlage), Teamseiten und vieles mehr möglich automatisiert aus Entitäten (Datensatztyp) im CRM zu erzeugen. Für die Konfiguration steht eine eigene Entität zur Verfügung, in der Ihr Systemadmin schnell und einfach bestimmen kann, in welcher Entität bei einem bestimmten Ereignis eine SharePoint-Seite/-Element benötigt wird. Auch die Online-Versionen von SharePoint und Dynamics CRM werden unterstützt .

Oberflaeche_fuer_die_Konfiguration

Oberfläche für die Konfiguration

Wie kann die Standard-SharePoint-Integration in Dynamics CRM erweitert werden?

Die Standard-Integration kann um die in der hier aufgeführten Produktmatrix genannten Listen/Seiten erweitert werden oder nutzen Sie komplett die Funktionalität, die SharePoint Ihnen bietet, indem Sie sich SharePoint im IFrame in Dynamics CRM anzeigen lassen. Auf diesem Weg können Sie über ein Fenster im CRM-Datensatz in den SharePoint schauen und Features, wie Kopie herunterladen, Eigenschaften bearbeiten, SharePoint-Suche etc. nutzen.

SharePoint_Dokumentenbibliothek_pro_Account

SharePoint Dokumentenbibliothek pro Account

Projektmanagement_mit_Integration_Dynamics_CRM_und_SharePoint_verbessern

Projektmanagement mit Integration Dynamics CRM und SharePoint verbessern

Welche SharePoint Apps und Funktionen sind im Dynamics CRM integrierbar?

Unsere Produktmatrix und unsere Anwendungsfälle erläutert im Detail, welche SharePoint-Elemente, wie im Dynamics CRM konfiguriert werden können. Von Standardlisten, Dokumentenbibliotheken, benutzerdefinierten Listen/Seiten, Teamseiten, Ordnern, benutzerdefinierten Listeneinträgen mit konfigurierbarem Feld-Mapping, OneNote-Notizbücher/bzw. -Abschnitte, Taxonomie-Einträge mit Hierarchie und vieles mehr sind derzeit möglich aus dem CRM im SharePoint zu erstellen.

Wie verbinde ich OneNote mit Dynamics CRM?

Beschäftigt man sich ein wenig mit der Materie, findet man die vor kurzem noch angekündigte OneNote-API. Jedoch kann diese API im aktuellen Status nur das OneNote-Notizbuch im eigenen OneDrive bearbeiten. Eine Bearbeitung eines im SharePoint liegenden Notizbuchs ist aktuell noch nicht möglich, aber immerhin bereits auf der Wunschliste.

Da aber auch wir nicht so lange warten wollen, haben wir analysiert, welche Alternativen es gibt. Erstaunlicherweise sind es sogar recht viele, die jedoch alle der Reihe nach aus Gründen der Performance oder Kompatibilität ausscheiden. Nur eine Alternative blieb, die Anfangs regelrecht gepflastert mit Stolpersteinen schien, die sich jedoch im Laufe der Zeit eher als Steighilfen erwiesen. Im Screenshot sieht man, wie eine mögliche Konfiguration aussehen könnte. Mehr dazu gibt es auf dem folgenden Blog-Beitrag: OneNote heiratet CRM/SharePoint-Integrator

OneNote - Seite

OneNote-Abschnitt/-Seite pro Account/Verkaufschance im Dynamics CRM

Fazit

Der CRM-SharePoint-Integrator kann Ihnen viele wiederkehrende Aufgaben abnehmen und integriert zudem den SharePoint je nach Wunsch in Ihrem CRM. Kompatibel ist der CRM-SharePoint-Integrator mit dem CRM ab Version 2011 in den Varianten On-Premise und Online sowie mit dem SharePoint ab Version 2007 in den Varianten On-Premise und Online. Die Funktionalität können Sie sich auch nochmal im Webcast hier anschauen:

Erfahren Sie mehr auf unserer Produktseite. Haben Sie Fragen zum Produkt, möchten Sie eine Vorführung oder das Produkt beziehen, so sprechen Sie uns an.

Autor: Dirk Sarodnick und Melanie Wolf
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

SharePoint 2013 Website mit benutzerdefiniertem WebTemplate per Workflow erstellen

Freitag, 15. November 2013

Artistic EndeavourMein Kollege Herr Weichert erklärte in seinem letzten Blogbeitrag, wie mit einfachen Bordmitteln ein WebTemplate im SharePoint 365 per Workflow zu deployen ist. Dabei setzte das Szenario jedoch voraus, dass der Workflow an einer bestimmten Liste hängt und bei jedem neu hinzugefügten Item ausgelöst wird. Das funktioniert mit Standard-Templates, wie der Teamwebsite, sehr gut. Im Workflow wird einfach „STS#0“ als WebTemplate angegeben. Nun haben selbst angelegte WebTemplates keinen solch einfach strukturierten Template-Namen. Was muss ich also angeben, sodass anstatt der Teamsite meine eigens erstellte Vorlage genutzt wird?

Im SharePoint Designer hat man in der entsprechenden Variable „WebTemplate“ verschiedene Typen zur Auswahl:

–          Boolesch

–          Datum/Uhrzeit

–          Ganze Zahl

–          GUID

–          Wörterbuch

–          Zahl

–          Zeichenfolge

Für die Teamseite nutzten wir den Typ „Zeichenfolge“. Für unsere eigene Vorlage schien der Typ GUID vorerst prädestiniert. Spontan fiel uns die SolutionID aus der Manifest.xml ein. Wenn man diese allerdings einträgt, wird man arg enttäuscht. Es wird keine Subsite angelegt.

Die Lösung ist relativ simpel. Wenn man sich die Zeichenfolge „STS#0“ anschaut, scheint diese Struktur nicht willkürlich. Das Gros der Leser erkennt natürlich, dass das der Standardwert von Microsoft für eine Teamseite ist. Die Werte sind auch relativ schnell mit den IE Developer Tools auffindbar: in der Selektionsbox beim Erstellen der Unterseite als „value“ des entsprechenden Eintrags. Weiterhin tauchen dann in den anderen Auswahlmöglichkeiten auch Dinge auf wie „BLOG#0“ oder „COMMUNITY#0“. Einige von euch werden wissen, worauf es hinausläuft.

Scrennshot1

Im Reiter „Benutzerdefiniert“ befindet sich unsere eigene Vorlage. Mit den IE Developer Tools markiere ich den Eintrag und es wird mir eine relativ kryptische Zeichenkette angezeigt, die im Wesentlichen folgendes Format hat:

–          {GUID}#[TEMPLATENAME]

Ein Beispiel sieht wie folgt aus:

–          {71F841A7-F471-4043-8DC7-FB26D64D0F25}#MyWebTemplate

Achtung: Diese Guid entspricht nicht der SolutionID! Das ist die FeatureID, mit der die Vorlage ausgerollt wurde. Diese ID ist also auch beim Ausrollen auf einer anderen SiteCollection in jedem Fall identisch.

Scrennshot2

Wenn wir diese Zeichenkette als Wert im SharePoint Designer eintragen und den Workflow erneut starten: Voilà. Unser eigenes Template bekommt seine Oberfläche per Workflow.

screenshot4Die FeatureID kann man schlussendlich auf zwei Wege herausfinden. Zum einen ist es möglich, diese einfach im Feature abzulesen, wenn es sich um eine selbsterstellte Lösung handelt. Sollte das nicht der Fall sein, kann man einen aus SharePoint 2010 bekannten Umweg gehen, indem man auf „Deaktivieren“ des jeweiligen Features klickt. In der Adressleiste des Browsers taucht eine URL auf, die die ID des Features enthält. Der Eintrag hinter dem Doppelkreuz definiert dann nur noch das eigentliche Template.

Autor: Henrik Krumbholz

PT_XING_HKrumbholz_jpg

 

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