Communardo Software GmbH, Kleiststraße 10 a, D-01129 Dresden
+49 (0) 351/850 33-0

Sharepoint 2010: Client object model & Silverlight – synchroner Ansatz

Eines, der für mich meist erwarteten Features von Sharepoint 2010, ist das neue Client object model. Gerade hinsichtlich der Entwicklung von Silverlight Web Applikationen in Verbindung mit Sharepoint, erleichtert es uns deutlich die Arbeit. Bisher mussten umständlich Serveranwendungen geschrieben werden um dann per Sharepoint Webservices auf die API zurück zu greifen. Das Client object model zieht nun eine neue Abstraktionsschicht ein, um diese Zugriffe zu erleichtern. Mit Hilfe des Client object models stehen fast alle Eigenschaften und Daten einer Site Collection zur Verfügung, so zum Beispiel der Zugriff auf Listen.

Das Client object model steht für nahezu alle Technologien zur Verfügung. Ob WPF, Forms Anwendungen, Silverlight oder Javascript.

  • für .NET clients steht die  Microsoft.SharePoint.Client.dll im “14\ISAPI”  Ordner zur Verfügung
  • Für Silverlight clients nutzt man die
    • Microsoft.SharePoint.Client.Silverlight.dll aus dem  “14\LAYOUTS\ClientBin” Ordner
    • Microsoft.SharePoint.Client.Silverlight.Runtime.dl aus dem “14\LAYOUTS\ClientBin” Ordner
  • Und für Javascript clients die SP.js file aus dem  “14\LAYOUTS” Ordner

In diesem ersten Überblick zeige ich wie das Client object model verwendet werden kann, um Daten aus einer Sharepoint 2010 Liste auszulesen. Das Auslesen der Daten soll in einer Silverlight Web Applikation stattfinden. Diese  soll nicht, wie in den meisten Beiträgen zum Client object model, in Form eines Sharepoint Webparts erstellt werden, sondern außerhalb von Sharepoint laufen.

Voraussetzungen für dieses Beispiel:

  • installiertes Sharepoint 2010 inkl. Silverlight 3
  • eine Sharepoint Liste mit Daten
    • In meinem Fall, meine Einkaufsliste

Los geht’s:

1. Im ersten Schritt muss ein neues Silverlight 3 Projekt innerhalb von Visual Studio angelegt werden. Zum Beispiel Silverlight 3 Navigation Application.

2. Die folgenden beiden DLLs werden als Referenz in dem Silverlight Projekt benötigt.

  • Microsoft.SharePoint.Client.Silverlight.dll
  • Microsoft.SharePoint.Client.Silverlight.Runtime.dll

Wenn Visual Studio 2010(Beta 2) verwendet wird und nach dem Hinzufügen der beiden DLLs ein kleines rotes Ausrufezeichen an der Referenz kleben sollte, habt ihr nichts falsch gemacht. Dabei handelt es sich um einen Bug von Visual Studio 2010. Der Fehler ist in der Pfadtiefe des Projektes und der Silverlight DLLs begründet. Um den Fehler zu beheben habe ich das Projekt einfach unter C:\Projects gelegt.

3. Da sich Sharepoint 2010 und das Silverlight Projekt in einer unterschiedlichen Domain befinden, wird der Zugriff auf den Client Context verweigert. Silverlight benötigt eine Clientaccesspolicy.xml Datei welche bestimmt, ob der Zugriff autorisiert ist. Diese Datei muss sich im Rootverzeichnis des Webservers befinden. Hier kommen die domain policy helper von Tim Heuer ins Spiel. Innerhalb des Webprojektes der Silverlightanwendung wird eine XML Datei mit den Namen Clientaccesspolicy.xml erstellt.

In dieser Datei wird das Snippet Menü via STRG+K+X aufgerufen und das Silverlight Clientaccesspolicy.xml Snippet ausgewählt. Der folgende Inhalt sollte erscheinen.
Wichtig: Vor Verwendung der Datei muss ein IIS Reset erfolgen.

4. Auf der darstellenden Seite benötigen wir ein Anzeigeelement für die Listen Daten. Dazu empfiehlt sich ein Datagrid. Dieses kann, basierend auf einem Datenobjekt, seine Spalten dynamisch generieren.

<data:DataGrid AutoGenerateColumns="True" Height="200" Name="einkauf" Width="311" HorizontalAlignment="Left" />

Mit diesem XAML Code wird ein Datagrid mit dem Namen „einkauf“ erstellt, welches automatisch seine Spalten generiert.

5. Auf Basis der Sharepoint Liste wird ein Datenobjekt erstellt.

 public class EinkaufData
    {
        public string Title {get;set;}
        public string Preis { get; set; }
        public string Details { get; set; }
    }

Dieses wird benötigt um das „einkauf“ Datagrid zu befüllen.

6. Basierend auf dem Datenobjekt wird eine Liste erstellt.

 private List einkaufList = new List();

7. Wie im Titel erwähnt, nutze ich in diesem Beispiel die synchrone Datenübertragung. Für synchrone Anfragen wird die Methode ExecuteQuery() genutzt, für asynchrone ExecuteQueryAsync . ExecuteQuery darf nicht eingesetzt werden, falls damit das Laden des User Interfaces beeinträchtigt wird. Falls die Methode trotzdem verwendet wird, tritt folgende Exception auf.

InvalidOperationException. The method or property that is called may block the UI thread and it is not allowed.

Um dieser Exception aus dem Weg zu gehen, wird die Methode LoadSharepointContext in einem Hintergrundprozess ausgeführt.

ThreadPool.QueueUserWorkItem(new WaitCallback(LoadSharepointContext));
private void LoadSharepointContext(Object stateInfo)
        {
 ClientContext clientCxt = new ClientContext("http://siteCollectionAdresse");
            List shoppingList = clientCxt.Web.Lists.GetByTitle("Einkauf");
            CamlQuery query = CamlQuery.CreateAllItemsQuery();
            ListItemCollection listItems = shoppingList.GetItems(query);
            clientCxt.Load(listItems);
            clientCxt.ExecuteQuery();

            foreach (ListItem item in listItems)
            {
                einkaufList.Add(new EinkaufData
                {
                    Title = item["Title"].ToString(),
                    Details = item["Details"].ToString(),
                    Preis = item["Preis"].ToString()
                });
            }
}

8. War das Laden des Sharepoint Kontextes erfolgreich, sollte die einkaufList nun mit den Daten der Sharepoint Liste gefüllt sein.
Als letzter Schritt muss nun die Liste dem Datagrid als Quelle zur Verfügung gestellt werden. Dabei muss beachtet werden, dass die Liste nicht im User Interface Thread befüllt wurde. Hier kommt der Dispatcher zum Zug.

Dispatcher.BeginInvoke(() =>
          {
             einkauf.ItemsSource = einkaufList;
          });

9. War alles erfolgreich sollte das Datagrid wie folgt aussehen.

Tipp: Sollte ein Zugriff auf eine Eigenschaft eines SP Objektes erfolgen, ohne die Query vorher abgesetzt zu haben, erhält man die folgende Exception :
PropertyOrFieldNotInitializedException. Diese Exception tritt solange auf, bis eine Eigenschaft geladen und die Query mittels ExecuteQuery abgesetzt wurden ist.

Wie die asynchronen Anfragen an Sharepoint mit dem Client object model realisiert werden, zeige ich im nächsten Blogeintrag.

[…] Es sind die Schritte 1. – 6. des Blogeintrages “Sharepoint 2010: Client object model & Silverlight – synchroner Ansatz” […]

#Sharepoint 2010: Client object model & #Silverlight – ansynchroner Ansatz http://ow.ly/XAIk #fb
This comment was originally posted on Twitter

#Sharepoint 2010: Client object model & #Silverlight – synchroner Ansatz http://ow.ly/XAIw #fb
This comment was originally posted on Twitter

[…] Dieser Eintrag wurde auf Twitter von Planet SharePoint und Torsten Hufsky, aseantic erwähnt. aseantic sagte: #Sharepoint 2010: Client object model & #Silverlight – synchroner Ansatz http://ow.ly/XAIw #fb […]

Sharepoint 2010: Client object model & Silverlight – asynchroner Ansatz
http://bit.ly/94KYk6
This comment was originally posted on Twitter

Vielen Dank werte Kollegen, sehr nützerlich Beitrag :).

kann das ganze auch analog mit silverlight 4 angewendet werden?

wenn ich das richtig verstehe wird die grafik darüber hinaus automatisch aktualisiert, sobald neue listen-elemente eingetragen werden?

Hallo,

ja das ganze ist analog mit Silverlight 4 anwendbar. In der nächsten oder übernächsten DotNetPro Zeitschrift erscheint dazu ein Artikel von mir. In diesem habe ich ein ähnliches Vorgehen mit Silverlight 4 erklärt. Die ListBox, in welcher die Elemente angezeigt werden, wird sofort aktualisiert sobald neue Element in die Liste eingetragen werden.

Vg,

Torsten

Kommentar hinterlassen


Pin It on Pinterest