Die SharePoint Sandbox wurde nun bereits mehrmals gut beschrieben, seit diese mit SharePoint 2010 das Licht der Welt erblickt hat.

Heute möchte ich aufzeigen, wie man mit SharePoint 2010 OnPremise Wege aus der Sandbox implementieren kann.

 

Warum möchte man Wege aus der Sandbox finden?

Die SharePoint Sandbox isoliert Custom Code, so dass die vorhandene SharePoint Farm von vermeidlich „kleinen“ oder „unscheinbaren“ Lösungen nicht in Mitleidenschaft gezogen werden kann. Sie ermöglicht es SiteCollection Administratoren direkt über die Solution Gallery WSPs – welche explizit als Sandboxfähig markiert sind – bereitzustellen und zu aktivieren. Ein perfekter Mechanismus für die OnDemand Variante Office365, doch in Konzernen möchte man häufig etwas mehr.

Dieses „etwas“ kann der Aufruf eines bestimmten WebServices, das Schreiben auf eine bestimmte FileShare oder das Laden und Interpretieren des Unternehmens-Feeds sein. In jeder Limitation die uns die Sandbox vorschreibt finden SharePoint Anwender ein kritisches Feature welches Sie aber innerhalb Ihrer Sandbox als verfügbar sehen möchten.

Durchaus üblich sind solche Anforderungen von zentralen IT Abteilungen, die womöglich weltweit verfügbare und verwendete SharePoint Farmen administrieren. Hier muss natürlich auf Sandboxing gesetzt werden, weil der Betrieb solcher SharePoint Farmen schon sehr intensiv ist, würde hier das Monitoring und die Validierung aller Custom Solutions noch bei der Abteilung aufschlagen welche für das Hosting verantwortlich ist, würde dies zu einer mehr als hohen Auslastung führen. Daher ist es in PrivateCloud Szenarien üblich SharePoint’s Full-Trusted Proxies einzusetzen und somit bewusst Wege aus der Sandbox heraus zu öffnen.

Full-Trusted Proxies

In SharePoint 2010 stellt ein „Full-Trusted-Proxy“ genau eine Methode zur Verfügung welche aus Sandboxed Lösungen heraus aufgerufen werden können. Das Deployment eines Full-Trusted-Proxies geschieht über eine WSP – welche nur von einem Farmadministrator installiert und aktiviert werden kann.

Analog zur eigentlichen Sandbox Solution läuft auch der Proxy nicht im IIS Prozess (w3wp.exe) sondern im Prozess SPUCWorkerProcessProxy.exe, in dem auch die Standard Microsoft.SharePoint.dll zur Verfügung steht. Abbildung 1 zeigt wie das Zusammenspiel der Komponenten an dieser Stelle ist.

clip_image002

Abbildung 1 – Full-Trusted Proxies Quelle www.microsoft.com

 

Wichtig ist darüber hinaus, dass die Full-Trusted-Proxy Operation mit der Sandbox-Lösung nur über Ihren eigenen Rückgabewert kommunizieren kann.

 

Die Implementierung

Im folgenden Beispiel möchte ich die Anforderung aufgreifen, die ich zu Beginn angesprochen habe. Einen RSS Feed innerhalb einer Sandboxed Solution abfragen. Innerhalb der Sandbox ist es via CAS verboten die Load Methode der Klasse XElement aufzurufen, deshalb muss diese Operation als Full-Trusted-Proxy realisiert werden.

 

Abbildung2

Wie in Abbildung 2 zu sehen ist, muss das Projekt für den Proxy als Full-Trusted-SharePoint Projekt angelegt werden. Die Realisierung als Full-Trusted-Proxy kann im Wesentlichen auf drei elementare Bestandteile reduziert werden.

 

SPProxyOperationArgs

Zunächst sollte man eine Klasse erstellen, die von SPProxyOperationArgs abgeleitet ist. Diese neue Klasse wird im späteren Verlauf für den Übergabewert der Execute Methode verwendet. Alles was für den RSS-Feed-Reader benötigt wird ist die zugrundeliegende URL, welche aggregiert werden soll.

Abbildung3

 

SPProxyOperation

Der zweite und wichtigste Bestandteil ist die Implementierung des Proxy’s selbst. Hierzu wird eine weitere Klasse erstellt, die von SPProxyOperation abgeleitet ist. Innerhalb der Execute Methode wird die Logik platziert, die den RSS Feed lädt.

 

Abbildung4

 

Hierbei sind zwei Dinge zu beachten. Erstens muss der Parameter der Methode von SPProxyOperationArgs in unseren zuvor erstellten Typ RssFeedReaderArgument gecasted werden. Zweitens kann der Rückgabewert der Methode nur ein serialisierbares Objekt sein.

Registrierung des eigenen Full-Trusted Proxies

Der dritte und letzte Bestandteil des Full-Trusted-Proxies ist die Registrierung des Proxies beim gewünschten UserCodeService. Hierzu kann der FeatureEventReceiver des Farm-Features verwendet werden. Zur Vollständigkeit hier ebenfalls der Code zum Entfernen des Proxies bei der Deaktivierung des Features.

Abbildung5

Die Verwendung in einer Sandboxed Solution

Dank der Methode ExecuteRegisteredProxyOperation der Klasse SPUtility, ist die eigene Proxy-Operation im Handumdrehen aufgerufen. Die Methode bekommt lediglich drei Parameter

· FullQualifiedAssemblyName der Proxy-Operation

· FullQualifiedTypeName der Proxy-Operation

· Eine Instanz der RssFeedReaderArgument Klasse

Abbildung6

Als Resultat des Aufrufes erhält der Sandbox-Entwickler den RSSFeed als String, genau wie zuvor implementiert.

 

Fazit

Full-Trusted-Proxies bieten einen einfachen, sicheren und kontrollierten Weg aus der Sandbox heraus. Gerade in PrivateCloud Szenarien bieten Full-Trusted-Proxies ein gutes Mittel um Herr aller Custom Solutions zu werden.

 

-Thorsten

2 Kommentare to “Leaving the SharePoint Sandbox”

Erstelle Kommentare

You must be logged in to post a comment.

Hinweis zum Kommentar

Zum Kommentieren der Beiträge (und damit zur Teilnahme am Gewinnspiel) bitte auf die Zahl in der Bubble neben dem Titel des Blogeintrags klicken, dies öffnet das Kommentarformular!

Sponsored by

Subscribe

Über

Der SharePoint Advent

Ein Gemeinschaftsprojekt der deutschsprachigen SharePoint MVP's

Rubriken

Impressum

(c) 2011 SharePointCommunity