Partager via

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

  • Article

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

Dies ist Teil 4 einer fünfteiligen Serie zum CASI Kit (Claims, Azure and SharePoint Integration, Integration von Forderungen, Azure und SharePoint). Teil 1 ist eine einführende Übersicht über das gesamte Framework und die Lösung. Es wird erläutert, welche Themen in der Serie behandelt und abgedeckt werden. Teil 2 enthält Anweisungen zum Erstellen von WCF-Anwendungen und zum Festlegen der Unterstützung für Forderungen sowie zum anschließenden Verschieben dieser Anwendungen zu Windows Azure. Teil 3 behandelt die Basisklasse, die Sie zum Einbinden der SharePoint-Website mit Azure-Daten verwenden werden, indem ein neues benutzerdefiniertes Steuerelement einer Seite im _layouts-Verzeichnis hinzugefügt wird. In diesem Beitrag wird das Webpart erläutert, das als Teil dieses Framework enthalten ist. Es wurde speziell zur Verwendung mit dem benutzerdefinierten Steuerelement entwickelt, das Sie in Teil 3 erstellt und der layouts-Seite hinzugefügt haben.

Verwenden des Webparts

Bevor Sie mit der Verwendung des Webparts beginnen, wird vorausgesetzt, dass Sie a) einen funktionsfähigen WCF-Dienst besitzen, der in Windows Azure gehostet wird, und dass Sie b) ein benutzerdefiniertes Steuerelement erstellt und der layouts-Seite wie in Teil 3 dieser Serie beschrieben hinzugefügt haben. Weiterhin wird vorausgesetzt, dass Sie sowohl die CASI Kit-Basisklassenassembly als auch die Assembly für das benutzerdefinierte Steuerelement im GAC auf jedem Server in der SharePoint-Farm bereitgestellt haben. Darüber hinaus wird vorausgesetzt, dass die benutzerdefinierte ASPX-Seite, die das benutzerdefinierte Steuerelement hostet, im layouts-Verzeichnis auf jedem Front-End-Webserver in der Farm bereitgestellt wurde. Zur Beschreibung der Verwendung des Webparts verwende ich das Beispielprojekt AzureWcfPage, das ich hochgeladen und an den Beitrag zu Teil 3 angefügt habe. Sehen wir und nun also an, wie Sie diese beiden Dinge miteinander verbinden können, um Daten aus Azure auf einer SharePoint-Website zu rendern.

HINWEIS: Es ist zwar keine Anforderung, aber in der Regel viel einfacher, das Webpart zu verwenden, wenn von den aufgerufenen WCF-Methoden HTML zurückgegeben wird, sodass die Daten ohne weitere Verarbeitung direkt auf der Seite angezeigt werden können.

Im ersten Schritt wird die Lösung AzureRender.wsp in der Farm bereitgestellt. Die WSP-Datei ist in der ZIP-Datei enthalten, die diesem Beitrag angefügt ist. Sie enthält das Feature zum Bereitstellen des DataView-Webparts von Azure und von jQuery 1.4.2 im layouts-Verzeichnis. Wenn die Lösung bereitgestellt und das Feature für eine Websitesammlung aktiviert wurde, können Sie das Webpart einer Seite hinzufügen. Zu diesem Zeitpunkt können Sie schon fast mit dem Rendern der Daten aus Azure beginnen, es muss nur noch eine einzige Eigenschaft festgelegt werden. Wenden wir uns der Funktion dieser und anderer Eigenschaften für das Webpart zu.

Webparteigenschaften

Alle Webparteigenschaften befinden sich im Abschnitt Connection Properties. Sie müssen mindestens die Data Page-Eigenschaft für die layouts-Seite festlegen, die Sie erstellt und bereitgestellt haben. Ein Beispiel: /_layouts/AzureData.aspx. Falls im Servertag für das benutzerdefinierte Steuerelement mindestens die Eigenschaften WcfUrl und MethodName definiert sind, sind keine weiteren Schritte erforderlich. Falls nichts Anderes mehr festgelegt wurde, ruft das Webpart die Seite auf und verwendet den WCF-Endpunkt und die auf der Seite konfigurierte Methode. Dann empfängt es die von der Methode zurückgegebenen Daten (vorgeblich werden diese im HTML-Format zurückgegeben) und rendert sie im Webpart. In den meisten Fällen möchten Sie jedoch sehr wahrscheinlich einige der anderen Webparteigenschaften für ein Maximum an Flexibilität verwenden, daher werden Sie hier im Einzelnen vorgestellt:

· Method Name* – Der Name der Methode in der WCF-Anwendung, die aufgerufen werden soll. Falls Sie die layouts-Seite mit Ihrer eigenen JavaScript-Funktion aufrufen müssen, lautet der Abfragezeichenfolgenparameter für diese Eigenschaft methodname.

· Parameter List* – Eine durch Semikolon getrennte Liste von Parametern für die WCF-Methode. Wie in den Teilen 2 und 3 dieser Serie erläutert wurde, werden nur die Basisdatentypen unterstützt: string, int, bool, long und datetime. Wenn Sie einen komplexeren Datentyp verwenden müssen, sollten Sie zunächst eine Zeichenfolge deserialisieren, dann die Methode aufrufen und sie dann wieder in einem komplexen Typ im WCF-Endpunkt serialisieren. Falls Sie die layouts-Seite mit Ihrer eigenen JavaScript-Funktion aufrufen müssen, lautet der Abfragezeichenfolgenparameter für diese Eigenschaft methodparams.

· Success Callback Address – Diese JavaScript-Funktion wird zurückgerufen, nachdem die jQuery-Anforderung für die layouts-Seite erfolgreich beendet wurde. Standardmäßig verwendet diese Eigenschaft die JavaScript-Funktion, die im Lieferumfang des Webparts enthalten ist. Falls Sie eine eigene Funktion verwenden, sollte die Funktionssignatur wie folgt lauten: function yourFunctionName(resultData, resultCode, queryObject) . Weitere Informationen finden Sie in der jQuery AJAX-Dokumentation unter https://api.jquery.com/jQuery.ajax/.

· Error Callback Address – Diese JavaScript-Funktion wird zurückgerufen, falls die jQuery-Anforderung für die layouts-Seite nicht erfolgreich beendet wurde. Standardmäßig verwendet diese Eigenschaft die JavaScript-Funktion, die im Lieferumfang des Webparts enthalten ist. Falls Sie eine eigene Funktion verwenden, sollte die Funktionssignatur wie folgt lauten: function yourFunctionName(XMLHttpRequest, textStatus, errorThrown). Weitere Informationen finden Sie in der jQuery AJAX-Dokumentation unter https://api.jquery.com/jQuery.ajax/.

· Standard Error Message – Diese Meldung wird im Webpart angezeigt, wenn während der serverseitigen Verarbeitung des Webparts ein Fehler aufgetreten ist. Dies bedeutet, dass Szenarien, in denen Daten aus Azure abgerufen werden, NICHT eingeschlossen sind.

· Access Denied Message* – Dies ist die Fehlermeldung vom Typ Zugriff verweigert, die angezeigt wird, wenn der Zugriff des Benutzers für eine bestimmte Methode verweigert wird. Wie in Teil 2 dieser Serie erläutert wurde, kann jede Methode mit einer PrincipalPermission-Anforderung versehen werden, da das Benutzertoken zusammen mit dem WCF-Aufruf übergeben wird. Ein Beispiel: Dieser Benutzer muss Teil der Gruppe der Manager des Vertriebs sein. Wenn der Benutzer eine PrincipalPermission-Anforderung nicht erfüllt, dann tritt für den WCF-Aufruf ein Fehler vom Typ Zugriff verweigert auf. In diesem Fall wird vom Webpart die entsprechende Meldung zum verweigerten Zugriff angezeigt. Beachten Sie, dass Sie diese Meldung umfassend formatieren können, indem Sie beispielsweise die Schriftart mithilfe von HTML-Tags auf Fettdruck und Rot festlegen (d. h. <font color='red'>Sie besitzen keine Zugriffsrechte. Wenden Sie sich an den Administrator</font>). Falls Sie die layouts-Seite mit Ihrer eigenen JavaScript-Funktion aufrufen müssen, lautet der Abfragezeichenfolgenparameter für diese Eigenschaft accessdenied.

· Timeout Message* – Diese Meldung wird angezeigt, wenn ein Timeoutfehler beim Ausführen des WCF-Methodenaufrufs aufgetreten ist. Es wird auch eine umfassende Formatierung unterstützt, z. B. das Festlegen der Schriftart auf Fettdruck, Rot usw. Falls Sie die layouts-Seite mit Ihrer eigenen JavaScript-Funktion aufrufen müssen, lautet der Abfragezeichenfolgenparameter für diese Eigenschaft timeout.

· Show Refresh Link – Aktivieren Sie dieses Feld, um ein Aktualisierungssymbol über den Azure-Datenergebnissen anzuzeigen. Falls auf das Symbol geklickt wird, wird die WCF-Methode erneut ausgeführt, um die neuesten Daten abzurufen.

· Refresh Style – Ermöglicht Ihnen das Hinzufügen weiterer Style-Attribute zum Hauptattribut Style im IMG-Tag, mit dem die Aktualisierungsverknüpfung angezeigt wird. Sie können z. B. float:right mithilfe dieser Eigenschaft hinzufügen, damit das Aktualisierungsbild am rechten Rand ausgerichtet wird.

· Cache Results – Aktivieren Sie dieses Feld, wenn die Ergebnisse der Abfrage von der jQuery-Bibliothek zwischengespeichert werden sollen. Dann wird bei jedem Laden der Seite eine zwischengespeicherte Version der Abfrageergebnisse verwendet. Dadurch werden Roundtrips zu Azure eingespart, und die Leistung für Endbenutzer wird beschleunigt. Falls die abgerufenen Daten nicht regelmäßig geändert werden, dann ist das Zwischenspeichern der Ergebnisse eine gute Option.

· Decode Results* – Aktivieren Sie dieses Feld, wenn von der WCF-Anwendung Ergebnisse vom Typ HtmlEncoded zurückgegeben werden. Falls Sie diese Eigenschaft auf true festlegen, wird HtmlDecoding auf die Ergebnisse angewendet. In den meisten Fällen ist dies nicht erforderlich. Falls Sie die layouts-Seite mit Ihrer eigenen JavasSript-Funktion aufrufen müssen, lautet der Abfragezeichenfolgenparameter für diese Eigenschaft encode.

* – Diese Eigenschaften werden ignoriert, falls die AllowQueryStringOverride-Eigenschaft des benutzerdefinierten Steuerelements auf false festgelegt ist.

Typische Verwendung

Wenn von der WCF-Methode HTML zurückgegeben wird, werden Sie das Webpart in den meisten Fällen einer Seite hinzufügen und zwei oder drei Eigenschaften festlegen: Data Page, Method Name und möglicherweise Parameter List.

Falls Sie komplexere Anzeige- oder Verarbeitungsanforderungen an die von Azure zurückgegebenen Daten stellen, können Sie hierzu eine benutzerdefinierte JavaScript-Funktion verwenden. In diesem Fall müssen Sie die JavaScript-Funktion der Seite hinzufügen und die Success Callback Address-Eigenschaft auf den Namen der JavaScript-Funktion festlegen. Falls Ihr Part weitere Weiterleitungen zurück zur WCF-Anwendung erfordert, z. B. für Hinzufügungen, Updates oder Löschungen, dann sollten Sie dies in die eigenen JavaScript-Funktionen einfügen und die benutzerdefinierte layouts-Seite mit den entsprechenden Werten für Method Name und Parameter List aufrufen. Die in der Abfragezeichenfolge zu verwendenden Variablennamen sind weiter oben dokumentiert. Wenn die ajax-Methode in jQuery zum Aufrufen der layouts-Seite verwendet wird, sollten Sie in der Lage sein, einen ähnlichen Ansatz wie beim Webpart zu verwenden. Die verwendete Aufrufkonvention basiert auf der Skriptfunktion unten. Beachten Sie, dass Sie die gezeigte dataFilter-Eigenschaft sehr wahrscheinlich weiter verwenden werden, da sie die gesamte Seitenausgabe abruft, die NICHT aus der WCF-Methode stammt:

$.ajax({

type: "GET",

       url: "/_layouts/SomePage.aspx",

dataType: "text",

data: "methodname=GetCustomerByEmail&methodparams=steve@contoso.local",

dataFilter: AZUREWCF_azureFilterResults,

success: yourSuccessCallback,

error: yourErrorCallback

});

 

Versuchen Sie es!

Nun besitzen Sie alle Teile, um die End-to-End-Lösung zu testen. An diesen Beitrag angefügt finden Sie eine ZIP-Datei mit der Lösung für das Webpart. Im nächsten und damit letzten Beitrag in dieser Serie beschreibe ich, wie Sie das in Teil 2 entwickelte benutzerdefinierte Steuerelement zum Abrufen von Daten aus Azure verwenden können. Zudem wird seine Verwendung im ASP.NET-Cache zusammen mit anderen Steuerelementen erläutert, und auch seine Verwendung in SharePoint-Aufgaben wird beschrieben – in diesem Fall anhand eines benutzerdefinierten SharePoint-Zeitgeberauftrags.

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