Toolkit für die Integration von Forderungen, Azure und SharePoint - Teil 1

Toolkit für die Integration von Forderungen, Azure und SharePoint - Teil 1

Dies ist der erste Blogbeitrag einer ganzen Serie, die ich sehr spannend finde. Wenn Sie alle Beiträge gelesen haben, finden Sie das hoffentlich auch. Ich habe in den letzten Monaten an einem neuen Framework zum Herstellen einer Verbindung zwischen SharePoint und Windows Azure gearbeitet, und auch die Forderungsidentität sollte so integriert werden, dass sie nahtlos über Anwendungen und sogar über die Grenzen von Rechenzentren hinweg fließen kann. Dem Ergebnis dieser Arbeit habe ich den Namen CASI Kit (Claims, Azure and SharePoint Integration, Integration von Forderungen, Azure und SharePoint) gegeben. Es ist eine Kombination aus Anleitungen, Basisklassenassembly, Webpart und Beispielanwendungen. Alle Teile zusammen ermöglichen Ihnen das Erstellen von WCF-Anwendungen, die Forderungen unterstützen, und das Hosten dieser Anwendungen in der Windows Azure-Cloud. Mit der Basisklasse werden Azure und Forderungen mit SharePoint verbunden. Das Webpart stellt eine einfache und direkt einsatzfähige Möglichkeit zum einfachen Einbinden der Azure-Daten in Ihre SharePoint-Website. Und nebenbei bemerkt geschieht dies asynchron mit einem clientseitigen Aufruf, sodass die Website nicht völlig zum Stillstand kommt, während ein Bündel von serverseitigen Aufrufen von den SharePoint-Seiten an einen möglicherweise latenten Cloud-basierten Dienst gesendet wird. Nach heutigem Stand ist dies so nah an Cloud-Plug & Play wie möglich.

Es folgen weitere Einzelheiten zu den veröffentlichten Blogbeiträgen und dem darin behandelten Inhalt:

· Teil 2: Der nächste Beitrag enthält die Anleitungen zum CASI Kit. Zunächst wird WCF als Front-End für alle Daten festgelegt. Es kann sich hierbei um Datasets, XML, benutzerdefinierte Klassen oder einfaches HTML handeln. In Phase 1 wird die Unterstützung von Forderungen für den WCF-Standarddienst festgelegt. Dadurch kann das Benutzertoken aus SharePoint abgerufen und über die Grenzen von Anwendungen oder Rechenzentren hinweg an unsere benutzerdefinierten WCF-Anwendungen gesendet werden. In Phase 2 wird die Liste aller Schritte erläutert, die Sie ausführen müssen, um diese typische lokale WCF-Anwendung in eine in Windows Azure gehostete Anwendung umzuwandeln. Nachdem diese Aufgabe ausgeführt ist, ist das Back-End vorbereitet, um eine Umgebung mit mehreren Anwendungen und mehreren Rechenzentren mit integrierter Authentifizierung zu unterstützen.

· Teil 3: Als Nächstes folgt ein Beitrag zur benutzerdefinierten Toolkitassembly, die das Bindeglied zwischen der Forderungen unterstützenden WCF-Anwendung in der Cloud und der SharePoint-Farm darstellt. Die Verwendung der Assembly wird erläutert, zudem wird das einfache benutzerdefinierte Steuerelement vorgestellt, das Sie erstellen müssen (ca. 5 Zeilen Code). Und es wird beschrieben, wie dieses Steuerelement in einer Seite im _layouts-Verzeichnis zum Abrufen und Rendern von Daten im Webpart gehostet werden kann. Der vollständige Quellcode für das Beispiel des benutzerdefinierten Steuerelements und der _layouts-Seite wird ebenfalls veröffentlicht.

· Teil 4: Hier wird das im CASI Kit enthaltene Webpart erläutert. Es stellt eine sofort einsatzfähige Lösung ohne Code bereit, die das Einbinden und Verbinden mit einer asynchronen clientseitigen Abfrage ermöglicht, mit der Daten aus einem in einer Cloud gehosteten Dienst abgerufen und dann im Webpart angezeigt werden. Darin integriert sind Bindungen, sodass Sie Anpassungen vornehmen und eigene JavaScript-Funktionen zum Rendern der Daten verwenden können.

· Teil 5: Im letzten Teil dieser Serie werden kurz ein paar Beispielanwendungen erläutert, die einige andere häufig verwendete Szenarien für das Verwenden des benutzerdefinierten Steuerelements zeigen, das in Teil 3 beschrieben wird. In einer Anwendung wird das Steuerelement zum Abrufen von Benutzer- oder Konfigurationsdaten und zum Speichern dieser Daten im ASP.NET-Cache verwendet. Anschließend wird es in einem benutzerdefinierten Webpart verwendet. Im anderen Szenario wird das benutzerdefinierte Steuerelement zum Abrufen von Daten aus Azure und zum Verwenden dieser Daten in einer benutzerdefinierten Aufgabe verwendet. In diesem Fall handelt es sich um einen benutzerdefinierten SharePoint-Zeitgeberauftrag. Der vollständige Quellcode für diese Beispielanwendungen wird ebenfalls veröffentlicht.

Ich hoffe, Ihr Interesse ist hiermit geweckt. Auf dieser Website finden Sie Informationen und Verknüpfungen zu den nachfolgenden Beiträgen und zum Beispielcode.

Es handelt sich hierbei um einen übersetzten Blogbeitrag. Sie finden den Originalartikel unter The Claims, Azure and SharePoint Integration Toolkit Part 1