Erstellen eines Silverlight-Dashboards für SharePoint 2010 (Wrox)

SharePoint 2010

Zusammenfassung: Informationen zum Erstellen von Microsoft Silverlight-Dashboards in einer Microsoft SharePoint Server 2010-Umgebung.

Wrox-Logo

Bücher von Wrox zu SharePoint (in englischer Sprache)

Das Erstellen von Microsoft Silverlight-Dashboards in einer Microsoft SharePoint 2010-Umgebung wird in diesem Artikel anhand eines Szenarios veranschaulicht. Die Marketingabteilung des fiktiven Unternehmens Adventure Works nutzt zum Verwalten und Bereitstellen von Ressourcen eine SharePoint-Teamwebsite. Das Team beschließt eine Optimierung der Benutzeroberfläche mithilfe von Silverlight, um genehmigte grafische Ressourcen für die Produkte besser durchsuchen und verwalten zu können. Mithilfe von SharePoint-Workflows und einer Aufgabenliste fordern Mitarbeiter aus dem Marketing Ressourcen beim Grafikdesignteam an.

In den folgenden Tabellen werden die für diesen Artikel relevanten Listen und Dokumentbibliotheken beschrieben und die Felder und Typen definiert, die mit dem Quellcode in diesem Artikel korrelieren.

Tabelle 1 enthält die Dokumentbibliothek Products Assets (Produktressourcen), die eine Beschreibung der Ressourcen sowie das Datum der Genehmigung durch die Rechts- und Marketingabteilung der Ressourcen enthält. Tabelle 2 enthält die Produktlisten und Tabelle 3 die Produktkategorielisten. Nach der Definition dieser Listen und Daten funktioniert der Quellcode in diesem Artikel für eine SharePoint-Website ordnungsgemäß.

Nachdem das Grafikdesignteam die Ressource übermittelt hat, wird ihr Inhalt zunächst vom Marketingteam und anschließend von der Rechtsabteilung geprüft, ehe die Ressource einem größeren Nutzerkreis zur Verfügung gestellt wird. In einem einfachen sequenziellen in Visual Studio vordefinierten Workflow wird die Ressource nach Angabe des Datums der Genehmigung durch die Rechts- und Marketingabteilung als genehmigt markiert. Das Dashboard der Anwendung hat drei Diagramme: ausstehende Genehmigungen nach Abteilung, Ressourcenanzahl nach Produkt und Anzahl der Tage, die für die Genehmigung einer Ressource erforderlich sind, nach Abteilung.

Schwerpunkt dieses Artikels sind die Grundlagen der Verwendung von Silverlight in SharePoint 2010. Leser können basierend auf den Beispielen Szenarien entwickeln, die für ihre Geschäftsprozesse und Berichtsanforderungen spezifisch sind.

Tabelle 1: Dokumentbibliothek "Products Assets"

Feld

Zweck

Typ

Title

Beschreibung der Ressource

Eine Textzeile

Product

Nachschlagefeld zum Zuordnen eines Produkts aus der Produktliste

Nachschlagefeld (Produktliste)

LegalApprovalDate

Dient zum Speichern des Datums, an dem die Rechtsabteilung die Verwendung der Ressource genehmigt hat

Datum und Uhrzeit

MarketingApprovalDate

Dient zum Speichern des Datums, an dem die Marketingabteilung die Verwendung der Ressource genehmigt hat

Datum und Uhrzeit

Tabelle 2. Liste "Products"

Feld

Zweck

Typ

Title

Beschreibung des Produkts

Eine Textzeile

ProductNumber

Interne Artikelposition des Produkts im ERP-System (Enterprise Resource Planning) von Adventure Works

Eine Textzeile

ProductCategory

Nachschlagefeld zum Zuordnen einer Kategorie aus der Produktkategorieliste

Nachschlagefeld (Produktkategorieliste)

ProductModel

Die Modellbeschreibung im ERP-System von Adventure Works

Eine Textzeile

Description

Kurzbeschreibung des Produkts

Eine Textzeile

Tabelle 3. Liste "Product Categories"

Feld

Zweck

Typ

Title

Beschreibung der Kategorie

Eine Textzeile

SharePoint 2010 bietet APIs, über die Silverlight auf Daten zugreifen kann: REST-Dienste, Clientobjektmodell und Webdienste. Die Funktionalität dieser APIs ist bei geringfügigen Abweichungen ähnlich. Sie müssen die Unterschiede zwischen den APIs kennen, bevor Sie entscheiden, welche API für Ihr Projekt geeignet ist.

Die REST-Dienst-API bietet eine ATOM XML- oder JSON-Ansicht (JavaScript Object Notation) der Listen- und Bibliotheksdaten. Wenngleich die REST-API Ihnen einen Teil der manuellen Codierung erspart, die zum Erstellen der Klassen für die einzelnen Listen- und Bibliotheksobjekte erforderlich ist, bietet die API keine Funktionalität zum Verwalten von Websites und Webseiten. Darüber hinaus kann das Abfragen von Daten bei diesem Modell wesentlich einfacher erfolgen, da es mithilfe von LINQ erfolgt. Doch bei großen Datenmengen führt das selbstbeschreibende ATOM-Format zu einem zu hohen Verarbeitungsaufwand, sodass langfristig keine akzeptable Leistung möglich ist.

Das Clientobjektmodell bietet eine API, die der des Serverobjektmodells ähnlich ist, und sollte deshalb Entwicklern vertraut sein, die Erfahrung mit der herkömmlichen SharePoint-Entwicklung haben. Die Clientobjektmodell-API ist leistungsstark, erfordert jedoch für das Abfragen von Daten bestimmte SharePoint-Kenntnisse, z. B. von Collaborative Application Markup Language (CAML).

Die Webdienst-API bietet eine abwärtskompatible SOAP-API zum Verwalten von SharePoint-Daten und -Ressourcen und ist die einzige API, die mit SharePoint 2007 abwärtskompatibel ist. Wenn Sie mit dieser Methode Erfolg haben möchten, müssen Sie jedoch eine angepasstere Infrastruktur einrichten, um mit CAML Abfragen durchführen und Verbindungen mit den Diensten herstellen zu können. In weiteren Artikeln dieser Reihe werden die Vor- und Nachteile der einzelnen Zugriffsmethoden erläutert.

In Tabelle 4 werden verschiedene wichtige Unterscheidungsmerkmale zusammengefasst, die Sie beim Bestimmen der für ein Projekt geeigneten API berücksichtigen sollten.

Tabelle 4. Übersicht über die SharePoint 2010-APIs für den Zugriff auf Daten aus Silverlight

API

Unterscheidungsmerkmale

ADO.NET Data Services (REST)

Streng typisiert

Abfrage mit LINQ

Nur Listen- und Bibliotheksdaten

Clientobjektmodell

Schwach typisiert

Abfrage mit CAML

Aktualisierung durch Objekte

Ähnliches Programmiermodell wie das Serverobjektmodell

Webdienst

Schwach typisiert

Nur CAML-Abfragen

Abwärtskompatibel

Da ein Dashboard eine schreibgeschützte Ansicht von Listen- und Bibliotheksdaten ist, bietet die REST-API die einfachste Möglichkeit der Abfrage der Daten, die zum Anzeigen der Dashboardmetriken erforderlich sind.

Benutzer, die das Silverlight-Dashboard anzeigen, um den aktuellen Status des Genehmigungsprozesses zu prüfen, benötigen Zugriff auf die Listen in SharePoint, da der Silverlight-Client diese Listen abfragt. (Selbst wenn das Dashboard sich auf einer Seite befindet, für die dem Benutzer der Zugriff gewährt wurde, ist Silverlight clientbasiert.) Wenn diese Listen über die Remote-API abgefragt werden, werden dieselben Sicherheitsregeln erzwungen wie diejenigen, die gelten, wenn der Benutzer versucht, diese Listen in einem Browser zu durchsuchen. Im Gegensatz zur ASP.NET-Programmierung wird der Code, der geschrieben und in die Silverlight-Anwendung kompiliert wird, nicht auf dem Server ausgeführt. Bei Code, der das Serverobjektmodell oder die Remote-APIs verwendet, erfolgen alle Aufrufe zum Anzeigen oder Aktualisieren von Daten im Sicherheitskontext des aktuellen Benutzers. Im Gegensatz zu Code für das Serverobjektmodell können Berechtigungen für einen API-Aufruf zum Anzeigen oder Aktualisieren von Daten in SharePoint nicht heraufgestuft werden. Alle drei APIs beachten die vordefinierten Sicherheitseinstellungen, die über die SharePoint-Web- und Designerschnittstellen erzwungen werden. Wichtig ist der Hinweis, dass alle Aufrufe unter der Federführung des authentifizierten Benutzers erfolgen, wenn auf Daten in SharePoint zugegriffen wird. Der Benutzer muss Berechtigungen für alle Websites, Listen oder Elemente haben, auf die über die API zugegriffen werden soll.

Zusätzlich zum Zugriff auf den Inhalt, auf den der Aufrufer zuzugreifen versucht, muss der aufrufende Benutzer auch Mitglied einer Websitegruppe mit der Berechtigung Remoteschnittstellen verwenden (siehe Abbildung 1) sein, da diese Berechtigung die Fähigkeit des Zugriffs auf alle drei APIs steuert. Untersuchen Sie die Einstellung der Option Berechtigungsstufe bearbeiten für Websitegruppen in der Website. Die Berechtigung ist standardmäßig für Mitglieder der Websitegruppe Lesen und höher aktiviert.

Abbildung 1. Remoteschnittstellen verwenden

Remoteschnittstellen verwenden

In diesem Abschnitt wird erklärt, wie Sie mithilfe einer Silverlight-Anwendung SharePoint-Daten anzeigen können, indem Sie mehrere einfache Abfragen erstellen, die Daten auf eine Weise zusammenfassen, die sich gut für die Anzeige in einem Dashboarddiagramm eignen.

Die REST-Dienst-API basiert auf ADO.NET Data Services, deren Installation zu den Voraussetzungen für SharePoint 2010 zählt. Da die betreffende Anwendung nur einen Bildschirm hat, ist das einfachste Silverlight-Anwendungsprojekt ausreichend.

  1. Starten Sie Visual Studio.

  2. Wählen Sie im Menü Datei den Befehl Neues Projekt aus, um das Dialogfeld Neues Projekt zu öffnen.

  3. Doppelklicken Sie auf Visual C#, und wählen Sie Silverlight aus.

  4. Wählen Sie im mittleren Bereich Silverlight-Anwendung aus.

Fügen Sie nach Erstellen der Anwendung einen Dienstverweis auf die Anwendung hinzu, um die Proxyklassen für die REST-Dienst-API zu erstellen.

  1. Klicken Sie mit der rechten Maustaste auf das Projekt.

  2. Wählen Sie Dienstverweis hinzufügen aus.

  3. Geben Sie die URL der REST-Dienst-API ein.

    Hinweis Hinweis

    Für den Zugriff auf den Dienst über einen Remoteaufruf (z. B. auf einem lokalen Entwicklungsserver oder im Dialogfeld Verweis hinzufügen) müssen Sie zunächst Remoteaufrufe für Silverlight aktivieren. Zum Aktivieren von Remoteaufrufen muss im Stammordner der Website die speziell formatierte Datei clientaccesspolicy.xml vorhanden sein. Weitere Informationen finden Sie unter Verfügbarmachen eines Diensts über Domänengrenzen hinweg.

    Wählen Sie zum Bestimmen des Speicherorts des REST-Diensts den Namen der Website aus, und fügen Sie der URL /_vti_bin/ListData.svc hinzu. Geben Sie beispielsweise zum Erreichen einer Stammwebsite in einer Websitesammlung mit der URL sl2sp.local Folgendes ein: http://sl2sp.local/_vti_bin/ListData.svc. Für dieses Beispiel heißt die SharePoint-Website, mit deren Hilfe die Anwendung erstellt wurde, sl2sp.local. Der Name, der zum Hinzufügen des Dienstverweises genutzt wurde, war DashboardExampleDataService.

    Da der Dienstverweis nun Teil des Projekts ist, steht die DataContext-Klasse zum Schreiben einer Abfrage zur Verfügung. Ähnlich wie bei einem Webdienst wird beim Hinzufügen eines Verweises zur Datei ListData.svc ein lokaler Proxy (samt generierten .NET-Klassen) als Teil des Projekts erstellt. Im Gegensatz zu Webdiensten enthält die Proxyklasse .NET-Klassen für alle Listen und Dokumentbibliotheken, einschließlich aller Felder, die in den Listen definiert sind. Klicken Sie zum Untersuchen der im Projekt erstellten Klassen mit der rechten Maustaste auf den Knoten DashboardExampleDataService des Symbols des Projekts ServiceReferences, und klicken Sie dann auf Im Objektbrowser anzeigen (siehe Abbildung 2). Für alle Listen und Dokumentbibliotheken in der Website werden die Objekte und Eigenschaften automatisch definiert, sodass eine Abfrage mithilfe des DashboardExampleDataContext-Objekts erfolgen kann.

    Abbildung 2. Im Objektbrowser anzeigen

    Im Objektbrowser anzeigen

Nachdem das Projekt eingerichtet wurde, ist das Schreiben von Abfragen zum Abrufen von Daten so einfach wie das Erstellen einer LINQ-Abfrage. Bei diesem Beispiel wird im Ansichtsmodell die DashboardDataContext-Eigenschaft mit dem Typ DashboardExampleDataContext erstellt, der im vorherigen Schritt definiert wurde. Im Konstruktor für das Ansichtsmodell wird der Datenkontext mithilfe des folgenden Codes initialisiert.

DashboardDataContext = new DashboardExampleDataContext(new Uri("http://sl2sp.local/_vti_bin/listdata.svc/"));

Das nächste Codebeispiel hat zwei Methoden. Zur Verkürzung wurden die Fehlerbehandlung und Aktivitätsindikatoren entfernt und der URI für den Zugriff auf die SharePoint-Dienste hartcodiert. Mit der ersten Methode, SelectApprovalStatusSummary, wird die Abfrage erstellt, mit der das Diagramm gebunden wird. Der erste Schritt ist das Leeren der Auflistung, an die das Diagramm gebunden ist, der zweite das Erstellen der LINQ-Abfrage zum Abrufen einer Gruppe von ProductAssets (Produktressourcen). Schließlich wird die Abfrage zusammen mit einer Rückrufmethode ausgelöst. Da in Silverlight alle Aufrufe asynchron erfolgen, dient die zweite Methode zum Verarbeiten des Rückrufs des asynchronen Aufrufs. In der Rückrufmethode kann der Code beginnen, mit den abgefragten Daten zu arbeiten. In dieser Methode verwendet der Code "LINQ to Objects", um die Ergebnisse in einer Übersicht der Daten zu gruppieren.

public void SelectApprovalStatusSummary()
{     
    // Clear the observable collection's contents.
    ProductApprovalCount.Clear();
 
    // Query the list of tasks where the status is not complete. 
    DataServiceQuery<ProductAssetsItem> qry = (from a in DashboardDataContext.ProductAssets select a) as DataServiceQuery<ProductAssetsItem>;
 
    // Set the method that will handle the asynchronous call to get data from 
    // the SharePoint API. 
    qry.BeginExecute(new AsyncCallback(SelectApprovalStatusSummaryComplete), qry);
}
 
public void SelectApprovalStatusSummaryComplete(IAsyncResult result)
{
    // Executes code on the UI thread to prevent cross-thread issues 
    // when changing properties that trigger Binding updates. 
    UIThreadDispatcher.BeginInvoke(() =>
        {
        // Receive the DataServiceQuery that was passed as a parameter to 
        // the asynchronous call. 
        DataServiceQuery<ProductAssetsItem> qry = (DataServiceQuery<ProductAssetsItem>)result.AsyncState;                    
                   
        // Finish executing the query to receive the results of the query. 
        var queryResults = qry.EndExecute(result);
 
        // Use LINQ to objects to group and summarize the results for 
        // consumption by the chart.
        ProductApprovalCount = new ObservableCollection<ProductMetricValuePair>(
         (from a in
        queryResults.Select((item) => new ProductAssetItemViewModel(item))
                    group a by a.ApprovalStatus into g
                    select new ProductMetricValuePair() { DisplayName = g.Key.ToString(), ValueCount = g.Count() }).ToList()
        );
        });
}

Zum Zusammenfassen des Status in einer Datenmenge, die gruppiert werden kann, werden zwei Objekte verwendet. Das ProductAssetItemViewModel-Objekt fügt dem ProductAssetItem-Objekt Funktionalität hinzu. Die spezifische verwendete Eigenschaft ApprovalStatus ist ein Element vom Typ Enum, das eine einfache Gruppierung basierend darauf ermöglicht, ob die Ressource auf die Genehmigung durch die Rechts- oder Marketingabteilung wartet, die Genehmigung abgeschlossen ist oder nicht gestartet wurde. Enum wird von der group by-Anweisung in der LINQ-_Abfrage verwendet. Schließlich werden die gruppierten Ergebnisse der Observable -Auflistung ProductApprovalCount hinzugefügt, an die das Diagramm im XAML-Code des Silverlight-Steuerelements gebunden wird (siehe das folgende Beispiel).

<chartingToolkit:Chart Title="Product Approval Status">
<chartingToolkit:Chart.Series>
<chartingToolkit:PieSeries ItemsSource="{Binding ProductApprovalCount}" 
                DependentValueBinding="{Binding ValueCount}"
                IndependentValueBinding="{Binding DisplayName}"/>
</chartingToolkit:Chart.Series>
</chartingToolkit:Chart>

Durch Verwenden der Diagramme im Microsoft Silverlight Toolkit (in englischer Sprache) ist das Ergebnis ein professionelles Kreisdiagramm mit einer Übersicht des Genehmigungsstatus der Elemente in der Dokumentbibliothek Product Assets (siehe Abbildung 3).

Abbildung 3. Diagramm mit dem Produktgenehmigungsstatus

Produktgenehmigungs-Statusdiagramm

Nach dem Debuggen der Anwendung in der lokalen Entwicklungsumgebung können Sie die Silverlight-Schnittstelle einer Seite der SharePoint-Website hinzufügen. Wenn eine Silverlight-Anwendung kompiliert wird, werden die Darstellung und Logik in eine oder mehrere DLLs kompiliert und zusammen mit den Ressourcen in einen besonderen Datentyp mit der Erweiterung XAP gepackt. Da Visual Studio diesen Packvorgang übernimmt, wird die XAP-Datei erstellt und kann bereitgestellt werden, wenn ein Entwickler die Anwendung zum Debuggen ausführt. Im Gegensatz zur herkömmlichen SharePoint-Programmierung, bei der das Serverobjektmodell verwendet wird, erfordert das Packen und Bereitstellen von Silverlight-Anwendungen keinen Administratorzugriff auf SharePoint. Wenngleich die vorgeschriebene Methode zum Bereitstellen einer Anwendung das Packen des Inhalts in eine WSP-Datei vorsieht, können Sie eine Silverlight-Anwendung auch als Inhalt erstellen und bereitstellen. Zum Bereitstellen der XAP-Datei muss die komprimierte Datei in eine Dokumentbibliothek hochgeladen und anschließend einer Seite hinzugefügt werden. Ändern Sie zum Packen der XAP-Datei für die Bereitstellung auf einem Server mit SharePoint die aktive Lösungskonfiguration von Debug in Release, und erstellen Sie anschließend die Lösung. Wechseln Sie auf der Festplatte zum Ordner, in dem die Silverlight-Anwendung gespeichert ist, und öffnen Sie den Ordner Bin. Im Ordner Release befindet sich eine XAP-Datei, deren Name dem des Projekts entspricht (siehe Abbildung 4). Nachdem Sie diese Datei in die Dokumentbibliothek Site Assets hochgeladen haben, kann die Anwendung einer SharePoint-Seite hinzugefügt werden.

Abbildung 4. Suchen der XAP-Datei im Buildverzeichnis

Suchen der XAP-Datei im Buildverzeichnis

SharePoint 2010 bietet ein neues Silverlight-Webpart. Das Standardwebpart bietet eine einfache Möglichkeit, die in einem Silverlight-Projekt erstellte XAP-Datei in eine Webseite einzubeziehen, indem Sie das Webpart hinzufügen und die anzuzeigende Datei auswählen. Beim Hinzufügen eines neuen Webparts wird das Silverlight-Webpart der Kategorie Medien und Inhalt hinzugefügt. Das in Abbildung 5 gezeigte Webpart ermöglicht die Konfiguration des Bereichs, der die Silverlight-Anwendung enthält.

Abbildung 5. Konfigurieren des Silverlight-Webparts

Konfigurieren des Silverlight-Webparts

Mit Silverlight können Sie Dashboards für SharePoint 2010 erstellen. Bevor Sie beginnen, sollten Sie grundsätzlich mit den Unterschieden zwischen den drei APIs vertraut sein, die den Datenzugriff auf Silverlight-Anwendungen ermöglichen, und wissen, welche API wann genutzt werden sollte. Die Codebeispiele für diesen Artikel enthalten zwei Diagramme und Abfragen und veranschaulichen das Verwenden von Zeitachsendiagrammen und des Schlüsselworts Expand, um verwandte Listen zu laden.

Ryan Morgan ist geschäftsführender Gesellschafter und Seniorarchitekt bei Arrow Consulting & Design in West Palm Beach, Florida. Ryan befasst sich bei Arrow mit der Automatisierung von Geschäftsabläufen sowie mit der Business Intelligence in großem Maßstab für die Bereiche Finanzwesen und Masterdatenverwaltung mithilfe von SharePoint zusammen mit Silverlight und ASP.NET. Ryan ist aktives Mitglied der .NET- und SharePoint-Community und hält Vorträge auf Codecamps, bei SharePoint-Samstagen und bei der DevConnections in Las Vegas. Ryan ist Mitverfasser von Professional DotNetNuke 5 für Wrox. Die Firma von Ryan finden Sie im Internet unter www.ArrowDesigns.com und www.ArrowNuke.com.

Die folgenden technischen Redakteure haben an Microsoft SharePoint 2010-Artikeln von Wrox mitgearbeitet:

  • Matt Ranlett ist ein SQL Server MVP und war über viele Jahre eine feste Institution der .NET-Entwicklercommunity in Atlanta. Als Gründungsmitglied von Atlanta Dot Net Regular Guys hat Matt mehrere regionale Benutzergruppen gegründet und leitet diese. Nach der Arbeit verbringt er viele Stunden mit lokalen und nationalen Communityaktivitäten, wie beispielsweise der SharePoint 1, 2, 3!-Reihe, der Organisation von drei Codecamps in Atlanta, der Tätigkeit als Vice President of Technology im Vorstand von INETA sowie Auftritten bei mehreren Podcasts wie z. B. .Net Rocks und dem ASP.NET-Podcast. Dennoch fand Matt kürzlich Zeit, sich mit einer wunderbaren Frau namens Kim zu verheiraten, die er bei der Aufzucht von drei riesigen Hunden unterstützt. Matt arbeitet derzeit als Seniorberater für Intellinet und gehört dem Team an, das mithilfe von innovativen Lösungen für den Erfolg von Unternehmen sorgt.

  • Jake Dan Attis. Was Muster, Praxis und Steuerung im Hinblick auf die SharePoint-Entwicklung betrifft, sind Sie bei Jake Dan Attis goldrichtig. Er ist von Moncton, Kanada, in die Region Atlanta gezogen und hat einen Abschluss in angewandter Mathematik, ist aber ein hundertprozentiger SharePoint-Hardcoreentwickler. Normalerweise nimmt Dan an Community-Events in der Region Atlanta teil, hält dort Vorträge oder organisiert derartige Events, wie beispielsweise Codecamps, SharePoint-Samstage und die SharePoint-Benutzergruppe in Atlanta. Wenn Dan einmal nicht in Visual Studio arbeitet, verbringt er gerne Zeit mit seiner Tochter Lily, schaut sich Hockey und Football an und kostet weltweite Biersorten.

  • Kevin Dostalek kann über 15 Jahre Erfahrung in der IT-Branche sowie über 10 Jahre Erfahrung in der Verwaltung großer IT-Projekte und der Führung von IT-Personal aufweisen. Er hat Projekte für Unternehmen ganz unterschiedlicher Größe geleitet und hatte verschiedene Funktionen inne, wie beispielsweise Entwickler, Architekt, Business Analyst, technischer Leiter, Manager Entwicklung, Projektmanager, Programm-Manager und Mentor/Coach. Darüber hinaus hat Kevin zwischen 2005 und 2008 auch als Vice President eine Lösungsbereitstellungsabteilung für einen MS Gold Partner mittlerer Größe geleitet und war später auch als Vice President of Innovation and Education tätig. Anfang 2010 gründete Kevin das Unternehmen Kick Studios, das Beratungs-, Entwicklungs- und Schulungsservices für die Spezialbereiche SharePoint und Social Computing anbietet. Seitdem ist er auch bei zahlreichen Benutzergruppenversammlungen, Treffen und Konferenzen im ganzen Land als Referent aufgetreten. Weitere Informationen zu Kevin finden Sie in seinem Blog "The Kickboard".

  • Larry Riemann verfügt über mehr als 17 Jahre Erfahrung im Entwurf und der Entwicklung von Geschäftsanwendungen für einige der weltweit größten Unternehmen. Larry ist ein unabhängiger Berater, Eigentümer von Indigo Integrations und bietet SharePoint-Beratung ausschließlich über SharePoint911 an. Er ist Autor, veröffentlicht Artikel und hält gelegentlich Vorträge auf Konferenzen. In den letzten Jahren befasste er sich in erster Linie mit SharePoint, dem Entwickeln und Erweitern von über SharePoint hinausgehender Funktionalität. Neben seiner Arbeit an SharePoint ist Larry ein ausgebildeter .NET-Architekt und verfügt über umfangreiches Know-how in Sachen Systemintegration, Unternehmensarchitektur und Hochverfügbarkeitslösungen. Weitere Informationen zu Larry finden Sie in seinem Blog.

  • Sundararajan Narasiman ist ein technischer Architekt bei der Content Management & Portals Group von Cognizant Technology Solutions, Chennai, und verfügt über mehr als 10 Jahre Branchenerfahrung. Sundararajan ist in erster Linie als Architektur- und Technologieberater für die SharePoint Server 2010-Stapel- und Mainstream .NET 3.5-Entwicklung tätig. Er ist ein begeisterter Programmierer und interessiert sich auch für Extremprogrammierung und EDT.

Anzeigen: