Toolkit für die Integration von Forderungen, Azure und SharePoint - Teil 3
Toolkit für die Integration von Forderungen, Azure und SharePoint - Teil 3
Dies ist Teil 3 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. In diesem Beitrag erläutere ich einen der wichtigsten Bestandteile dieses Frameworks: eine Basisklasse für ein benutzerdefiniertes Steuerelement, mit der Sie eine Verbindung zwischen SharePoint und der in Windows Azure gehosteten WCF-Anwendung herstellen. Folgende Themen werden behandelt:
· Die Basisklasse – was versteht man darunter und wie wird sie im Projekt verwendet
· Eine layouts-Seite – wie wird das neue Steuerelement einer Seite im _layouts-Verzeichnis hinzugefügt
· Wichtige Eigenschaften – eine Erläuterung der wichtigsten Eigenschaften in der Basisklasse, die bekannt sein sollten
Die CASI Kit-Basisklasse
Einer der wichtigsten Bestandteile des CASI Kits ist die Basisklasse für ein benutzerdefiniertes Steuerelement, das eine Verbindung mit der WCF-Anwendung herstellt und Anforderungen mit dem aktuellen Benutzeranmeldetoken übermittelt. Die Basisklasse ist ein standardmäßiges ASP.NET-Serversteuerelement, und für die Implementierung dieses Entwicklungsmusters müssen Sie ein neues ASP.NET-Serversteuerelement erstellen, das von dieser Basisklasse erbt. Aus Gründen, deren Erläuterung den Rahmen dieses Beitrags sprengen würde, muss das Steuerelement zwei Aufgaben ausführen:
1. Erstellen eines Dienstverweises auf die in Windows Azure gehostete WCF-Anwendung.
2. Überschreiben der ExecuteRequest-Methode in der Basisklasse. Dies ist tatsächlich recht einfach, da Sie nur fünf Zeilen Code schreiben müssen, in denen Sie den Proxy erstellen und konfigurieren, der eine Verbindung mit der WCF-Anwendung herstellen wird. Anschließend muss die ExecuteRequest-Methode der Basisklasse ausgeführt werden.
Erstellen Sie zunächst einmal ein neues Projekt in Visual Studio, und wählen Sie den Projekttyp einer Windows-Klassenbibliothek aus. Nachdem Sie den Namespace und Klassennamen bei Bedarf geändert haben, fügen Sie einen Verweis auf die CASI Kit-Basisklasse hinzu, die sich in der Assembly AzureConnect.dll befindet. Zudem müssen Verweise auf die folgenden Assemblys hinzugefügt werden: Microsoft.SharePoint, System.ServiceModel, System.Runtime.Serialization und System.Web.
Fügen Sie in Ihrer Basisklasse eine using-Anweisung für Microsoft.SharePoint hinzu, ändern Sie dann die Klasse, sodass sie von AzureConnect.WcfConfig erbt. Die Basisklasse WcfConfig enthält den gesamten Code und die Logik zum Herstellen einer Verbindung mit der WCF-Anwendung, zum Einbinden aller Eigenschaften für mehr Flexibilität in der Implementierung und zum Verhindern aller typischen Änderungen an web.config, die in der Regel zum Herstellen einer Verbindung mit einem WCF-Dienstendpunkt erforderlich sind. Dieser Punkt ist sehr wichtig: Sie müssten eigentlich bis zu 100 Zeilen mit Änderungen an web.config für jede WCF-Anwendung hinzufügen, mit der Sie eine Verbindung herstellen, an jeder Datei web.config auf jedem Server für jede verwendete Webanwendung. Die Basisklasse WcfConfig schließt dies alles in das Steuerelement ein, sodass alle Einstellungen vom Steuerelement geerbt werden, und das Steuerelement erledigt alles Weitere für Sie. Alle diese Eigenschaften, die in der Datei web.config geändert werden müssten, können auch im WcfConfig-Steuerelement geändert werden, da es alle diese Eigenschaften offen legt. Dieser Aspekt wird im Abschnitt über die wichtigen Eigenschaften erläutert.
Nun muss der in Windows Azure gehosteten WCF-Anwendung ein neuer Dienstverweis hinzugefügt werden. Hier ist für das CASI Kit nichts Besonderes zu beachten. Klicken Sie einfach mit der rechten Maustaste auf Verweise im Projekt, und wählen Sie dann die Option zum Hinzufügen eines Dienstverweises aus. Verbinden Sie die URL mit der Azure-WCF-Anwendung mit „?WSDL“ am Ende, sodass WSDL für die Dienstimplementierung abgerufen wird. Ändern Sie den Namen nach Bedarf, und fügen Sie zum Abschluss dieses Teils den Verweis hinzu.
Zu diesem Zeitpunkt besitzen Sie eine leere Klasse und einen Dienstverweis auf die WCF-Anwendung. Nun muss der Code geschrieben werden, der zum Glück nur klein ausfällt. Sie müssen die ExecuteRequest-Methode überschreiben, den Dienstklassenproxy erstellen und konfigurieren und dann die ExecuteRequest-Methode der Basisklasse aufrufen. Zur Vereinfachung folgt nun der gesamte Code für das Beispielsteuerelement, das an diesen Beitrag angefügt ist. Ich habe in Gelb die Teile hervorgehoben, die Sie für eine Übereinstimmung mit Ihrem Dienstverweis ändern müssen:
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Diagnostics;
using Microsoft.SharePoint;
//requires References to:
//1. AzureConnect
//2. Microsoft.SharePoint
//3. System.ServiceModel
//4. System.Runtime.Serialization
//5. System.Web
namespace AzureWcfPage
{
public class WcfDataControl : AzureConnect.WcfConfig
{
//this method must be overridden so the proxy can be
//configured and created correctly
public override bool ExecuteRequest()
{
try
{
//create the proxy instance with bindings and endpoint the base class
//configuration control has created for this
CustomersWCF.CustomersClient cust =
new CustomersWCF.CustomersClient(this.FedBinding,
this.WcfEndpointAddress);
//configure the channel so we can call it with
//FederatedClientCredentials.
SPChannelFactoryOperations.ConfigureCredentials<CustomersWCF.ICustomers>
(cust.ChannelFactory,
Microsoft.SharePoint.SPServiceAuthenticationMode.Claims);
//create a channel to the WCF endpoint using the
//token and claims of the current user
CustomersWCF.ICustomers claimsWCF =
SPChannelFactoryOperations.CreateChannelActingAsLoggedOnUser
<CustomersWCF.ICustomers>(cust.ChannelFactory,
this.WcfEndpointAddress,
new Uri(this.WcfEndpointAddress.Uri.AbsoluteUri));
//set the client property for the base class
this.WcfClientProxy = claimsWCF;
}
catch (Exception ex)
{
Debug.WriteLine(ex.Message);
}
//now that the configuration is complete, call the method
return base.ExecuteRequest();
}
}
}
Hier haben wir es nun: fünf Zeilen Code, und Sie können den Code aus der Überschreibung von ExcecuteRequest kopieren und direkt in Ihre eigene Überschreibung einfügen. Danach müssen Sie nur die gelb hervorgehobenen Teile durch die entsprechende Klasse und die Schnittstellen ersetzen, die von Ihrer WCF-Anwendung offen gelegt werden. Im oben hervorgehobenen Code gilt Folgendes:
· CustomersWCF.CustomersClient: CustomersWCF ist der Name, den ich beim Erstellen des Dienstverweises verwendet habe, und CustomersClient ist der Name der durch die WCF-Anwendung offen gelegten Klasse. Der Klassenname in der WCF-Anwendung ist tatsächlich nur Customers, und die VS.NET-Tools zum Hinzufügen eines Dienstverweises fügen den Teil Client am Ende hinzu.
· CustomersWCF.ICustomers: CustomersWCF ist dasselbe wie oben beschrieben. ICustomers ist die Schnittstelle, die ich in der WCF-Anwendung erstellt habe und die meine WCF-Customers-Klasse tatsächlich implementiert.
Das ist alles. Dies ist der gesamte Code, den Sie zum Bereitstellen einer Verbindung zurück zur in Windows Azure gehosteten WCF-Anwendung benötigen. Ich hoffe, Sie stimmen mir zu, dass das recht einfach war. Als kleine Hintergrundinformationen sei angemerkt, dass der von Ihnen geschriebene Code den Aufruf der WCF-Anwendung ermöglicht, der zusammen mit dem SharePoint-Benutzertoken übergeben wird. Dies wird in einem anderen Beitrag von mir näher erläutert: https://blogs.technet.com/b/speschka/archive/2010/09/08/calling-a-claims-aware-wcf-service-from-a-sharepoint-2010-claims-site.aspx.
Nachdem der Code nun fertig gestellt ist, müssen Sie sowohl die Basisklasse als auch das neue benutzerdefinierte Steuerelement im globalen Assemblycache auf jedem verwendeten Server registrieren. Dies kann natürlich auf einfache Art und Weise mit einer SharePoint-Lösung geschehen. Wenn das Steuerelement vollständig ist und registriert wurde, können wir uns nun ansehen, wie es zum Abrufen und Rendern von Daten verwendet wird. Mit dem CASI Kit sollen drei wichtige Szenarien für die Verwendung von Azure-Daten behandelt werden:
1. Rendern von Inhalt auf einer SharePoint-Seite mithilfe eines Webparts
2. Abrufen von Konfigurationsdaten für die Verwendung durch 1:n-Steuerelemente und Speichern der Daten im ASP.NET-Cache
3. Abrufen von Daten und Verwenden derselben in ausführbaren Aufgabentyp-Dateien, wie z. B. SharePoint-Zeitgeberaufträgen
Das erste Szenario tritt wohl am häufigsten auf, daher behandeln wir es zuerst. Nachdem diese Methodik entwickelt wurde, wäre es wohl das einfachste, einfach ein benutzerdefiniertes Webpart zu erstellen, das all diese Aufrufe während eines Load-Ereignisses oder Ähnlichem ausführt, die Daten abruft und auf der Seite rendert. Ich denke jedoch, dies wäre ein GROSSER Fehler. Durch das Zusammenfassen dieses Codes im Webpart, sodass er auf der Serverseite während der Verarbeitung einer Seitenanforderung ausgeführt wird, könnte der Gesamtdurchsatz der Farm stark beeinträchtigt werden. Ich hatte große Bedenken, wenn 1:n-Webparts auf einer Seite vorhanden sind und latente 1:n-Aufrufe in Anwendungen und Rechenzentren zum Abrufen von Daten ausführen. Dies könnte sehr schnell zu einer Situation führen, in der eine weit verbreitete Verwendung die gesamte Farm in die Knie zwingen könnte. Es besteht jedoch die Notwendigkeit, dass Code auf dem Server ausgeführt wird, da er zum Konfigurieren des Kanals zur WCF-Anwendung zum Senden des Benutzertokens zusammen mit der Anforderung erforderlich ist. Meine Lösung besteht aus zwei Teilen:
1. Eine benutzerdefinierten Seite, die im _layouts-Ordner gehostet wird. Sie enthält das weiter oben geschriebene benutzerdefinierte Steuerelement, das die vom WCF-Aufruf zurückgegebenen Daten rendert.
2. Ein benutzerdefiniertes Webpart, das KEINEN CODE auf der Serverseite ausführt, sondern stattdessen JavaScript und jQuery zum Aufrufen der Seite im _layouts-Ordner verwendet. Es liest die von der Seite zurückgegebenen Daten und übergibt sie dann an eine JavaScript-Funktion. Standardmäßig rendert diese Funktion dann den Inhalt im Webpart. Im Webpart sind noch mehr Dinge möglich. Das Webpart werde ich im nächsten Beitrag ausführlich behandeln. Wenn ein Benutzer nun die Seite anfordert, wird sie verarbeitet, ohne dass weitere latente Aufrufe der WCF-Anwendung erforderlich sind. Stattdessen durchläuft die Seite die Verarbeitungspipeline und wird direkt im Browser des Benutzers angezeigt. Nachdem dann die Seite vollständig geladen wurde, erfolgt der Aufruf, mit dem nur der WCF-Inhalt abgerufen wird.
Die Layouts-Seite
Die layouts-Seite, auf der das benutzerdefinierte Steuerelement gehostet wird, ist tatsächlich einfach zu schreiben. Ich habe das Ganze in Notepad in ca. fünf Minuten erledigt. Vielleicht geht es bei Ihnen noch schneller, denn ich kopiere einfach meine layouts-Seite und füge sie hier ein. Dabei zeige ich Ihnen, welche Teile Sie auf Ihrer Seite ersetzen müssen.
<%@ Page Language="C#" AutoEventWireup="true" Inherits="Microsoft.SharePoint.WebControls.LayoutsPageBase,Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" MasterPageFile="~/_layouts/simple.master" %>
<%@ Assembly Name="Microsoft.SharePoint.ApplicationPages, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c"%>
<%@ Import Namespace="Microsoft.SharePoint.ApplicationPages" %>
<%@ Register Tagprefix="SharePoint" Namespace="Microsoft.SharePoint.WebControls" Assembly="Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %>
<%@ Register Tagprefix="Utilities" Namespace="Microsoft.SharePoint.Utilities" Assembly="Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %>
<%@ Import Namespace="Microsoft.SharePoint" %>
<%@ Assembly Name="Microsoft.Web.CommandUI, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %>
<%@ Assembly Name="AzureConnect, Version=1.0.0.0, Culture=neutral, PublicKeyToken=c0b51bd3d3b33212"%>
<%@ Register Tagprefix="AzWcf" Namespace="AzureWcfPage" Assembly="AzureWcfPage, Version=1.0.0.0, Culture=neutral, PublicKeyToken=f0ed63b2f4046026" %>
<asp:Content ID="Content1" ContentPlaceHolderId="PlaceHolderPageTitle" runat="server">
<SharePoint:EncodedLiteral ID="wcfConnectPageTitle" runat="server" text="Azure Wcf Connect Page" EncodeMethod='HtmlEncode'/>
</asp:Content>
<asp:Content ID="Content2" ContentPlaceHolderId="PlaceHolderPageTitleInTitleArea" runat="server">
<SharePoint:EncodedLiteral ID="wcfConnectPage" runat="server" text="Azure Wcf Connect Page" EncodeMethod='HtmlEncode'/>
</asp:Content>
<asp:Content ID="Content3" ContentPlaceHolderId="PlaceHolderSiteName" runat="server"/>
<asp:Content ID="Content4" ContentPlaceHolderId="PlaceHolderMain" runat="server">
<AzWcf:WcfDataControl runat="server" id="wcf" WcfUrl="https://azurewcf.vbtoys.com/Customers.svc" OutputType="Page" MethodName="GetAllCustomersHtml" />
</asp:Content>
Wieder ist die eigentliche Implementierung der Seite eine einfache Sache. Was Sie aber unbedingt ändern müssen, ist der starke Name der Assembly für Ihr benutzerdefiniertes Steuerelement. Zur Illustration habe ich auch ein paar Eigenschaften im Tag des Steuerelements hervorgehoben. Diese Eigenschaften sind für meinen WCF-Dienst spezifisch. Sie können in Ihrer Implementierung anders sein oder vollständig entfernt werden. Die Eigenschaften werden weiter unten ausführlich erläutert. Wenn die layouts-Seite erstellt wurde, muss sie im _layouts-Verzeichnis auf jedem Front-End-Webserver in der SharePoint-Farm verteilt werden. Dann kann sie von jeder Website in einer Webanwendung, die Forderungen unterstützt, in der SharePoint-Farm aufgerufen werden. Natürlich können Sie nicht erwarten, dass sie in einer klassischen Authentifizierungswebsite wie die Zentraladministration verwendet werden kann. Nach der Bereitstellung der Seite kann diese vom CASI Kit-Webpart verwendet werden. Dies wird in Teil 4 dieser Serie beschrieben.
Wichtige Eigenschaften
WcfConfig enthält zwei große Kategorien von Eigenschaften: die Eigenschaften für das Konfigurieren des Kanals und der Verbindung mit der WCF-Anwendung und die Eigenschaften zum Konfigurieren der Verwendung des Steuerelements.
WCF-Eigenschaften
Wie bereits zuvor erwähnt wurden alle Konfigurationsinformationen für die WCF-Anwendung, die in der Regel in der Datei web.config enthalten sind, in das WcfConfig-Steuerelement gekapselt. Fast alle diese Eigenschaften sind jedoch offen gelegt, sodass sie abhängig von den Anforderungen Ihrer Implementierung geändert werden können. Zwei wichtige Ausnahmen hierzu stellen die Nachrichtensicherheitsversion, die immer MessageSecurityVersion.WSSecurity11WSTrust13WSSecureConversation13WSSecurityPolicy12BasicSecurityProfile10 lautet, und der Transport dar, der immer HTTPS und nicht HTTP lautet. Das Steuerelement besitzt darüber hinaus einige Eigenschaften, die Sie in der Implementierung vielleicht etwas besser kennen sollten (obwohl Sie diese im Normalfall nicht ändern müssen).
Zunächst sind da fünf schreibgeschützte Eigenschaften zur Offenlegung der Konfigurationsobjekte auf oberster Ebene, die in der Konfiguration verwendet werden. Mit schreibgeschützt ist gemeint, dass die Objekte schreibgeschützt sind. Die einzelnen Eigenschaften können jedoch festgelegt werden, wenn sie das Steuerelement programmgesteuert verwenden. Diese fünf Eigenschaften lauten:
SecurityBindingElement SecurityBinding
BinaryMessageEncodingBindingElement BinaryMessage
HttpsTransportBindingElement SecureTransport
WS2007FederationHttpBinding FedBinding
EndpointAddress WcfEndpointAddress
Die anderen Eigenschaften können alle im Tag für das Steuerelement konfiguriert werden, das der layouts-ASPX-Seite hinzugefügt wird. Für diese Eigenschaften habe ich eine Namenskonvention verwendet, die nach meiner Einschätzung für zusammengesetzte Eigenschaftswerte Sinn macht. Ein Beispiel: Die SecurityBinding-Eigenschaft besitzt eine Eigenschaft mit dem Namen LocalClient, bei der es sich um eine boolesche Eigenschaft mit dem Namen CacheCookies handelt. Da ich dies so einfach wie möglich ausdrücken wollte, habe ich nur eine Eigenschaft mit dem Namen SecurityBindingLocalClientCacheCookies erstellt. Sie werden mehrere Eigenschaften wie diese finden, und das ist auch der Trick für die Suche nach der richtigen Eigenschaft, wenn Sie sich das .NET Framework SDK ansehen und fragen, wie einige dieser Eigenschaftswerte in der Basisklassenimplementierung geändert werden können. Es folgt die vollständige Liste der Eigenschaften:
SecurityAlgorithmSuite SecurityBindingDefaultAlgorithmSuite
SecurityHeaderLayout SecurityBindingSecurityHeaderLayout
SecurityKeyEntropyMode SecurityBindingKeyEntropyMode
bool SecurityBindingIncludeTimestamp
bool SecurityBindingLocalClientCacheCookies
bool SecurityBindingLocalClientDetectReplays
int SecurityBindingLocalClientReplayCacheSize
int SecurityBindingLocalClientMaxClockSkew
int SecurityBindingLocalClientMaxCookieCachingTime
int SecurityBindingLocalClientReplayWindow
int SecurityBindingLocalClientSessionKeyRenewalInterval
int SecurityBindingLocalClientSessionKeyRolloverInterval
bool SecurityBindingLocalClientReconnectTransportOnFailure
int SecurityBindingLocalClientTimestampValidityDuration
int SecurityBindingLocalClientCookieRenewalThresholdPercentage
bool SecurityBindingLocalServiceDetectReplays
int SecurityBindingLocalServiceIssuedCookieLifetime
int SecurityBindingLocalServiceMaxStatefulNegotiations
int SecurityBindingLocalServiceReplayCacheSize
int SecurityBindingLocalServiceMaxClockSkew
int SecurityBindingLocalServiceNegotiationTimeout
int SecurityBindingLocalServiceReplayWindow
int SecurityBindingLocalServiceInactivityTimeout
int SecurityBindingLocalServiceSessionKeyRenewalInterval
int SecurityBindingLocalServiceSessionKeyRolloverInterval
bool SecurityBindingLocalServiceReconnectTransportOnFailure
int SecurityBindingLocalServiceMaxPendingSessions
int SecurityBindingLocalServiceMaxCachedCookies
int SecurityBindingLocalServiceTimestampValidityDuration
int BinaryMessageMaxReadPoolSize
int BinaryMessageMaxWritePoolSize
int BinaryMessageMaxSessionSize
int BinaryMessageReaderQuotasMaxDepth
int BinaryMessageReaderQuotasMaxStringContentLength
int BinaryMessageReaderQuotasMaxArrayLength
int BinaryMessageReaderQuotasMaxBytesPerRead
int BinaryMessageReaderQuotasMaxNameTableCharCount
System.Net.AuthenticationSchemes SecureTransportAuthenticationScheme
System.ServiceModel.HostNameComparisonMode SecureTransportHostNameComparisonMode
System.Net.AuthenticationSchemes SecureTransportProxyAuthenticationScheme
System.ServiceModel.TransferMode SecureTransportTransferMode
bool SecureTransportManualAddressing
long SecureTransportMaxBufferPoolSize
long SecureTransportMaxReceivedMessageSize
bool SecureTransportAllowCookies
bool SecureTransportBypassProxyOnLocal
bool SecureTransportKeepAliveEnabled
int SecureTransportMaxBufferSize
string SecureTransportRealm
bool SecureTransportUnsafeConnectionNtlmAuthentication
bool SecureTransportUseDefaultWebProxy
bool SecureTransportRequireClientCertificate
HostNameComparisonMode FedBindingHostNameComparisonMode
WSMessageEncoding FedBindingMessageEncoding
Encoding FedBindingTextEncoding
SecurityAlgorithmSuite FedBindingSecurityMessageAlgorithmSuite
SecurityKeyType FedBindingSecurityMessageIssuedKeyType
bool FedBindingSecurityMessageNegotiateServiceCredential
int FedBindingCloseTimeout
int FedBindingOpenTimeout
int FedBindingReceiveTimeout
int FedBindingSendTimeout
bool FedBindingBypassProxyOnLocal
bool FedBindingTransactionFlow
long FedBindingMaxBufferPoolSize
long FedBindingMaxReceivedMessageSize
bool FedBindingUseDefaultWebProxy
int FedBindingReaderQuotasMaxDepth
int FedBindingReaderQuotasMaxStringContentLength
int FedBindingReaderQuotasMaxArrayLength
int FedBindingReaderQuotasMaxBytesPerRead
int FedBindingReaderQuotasMaxNameTableCharCount
bool FedBindingReliableSessionOrdered
int FedBindingReliableSessionInactivityTimeout
bool FedBindingReliableSessionEnabled
Wieder wurden diese Eigenschaften so erstellt, dass sie direkt im Tag für das Steuerelement in der layouts-ASPX-Seite geändert werden können. Es folgt ein Beispiel für das Festlegen der FedBindingUseDefaultWebProxy-Eigenschaft:
<AzWcf:WcfDataControl runat="server" id="wcf" WcfUrl="https://azurewcf.vbtoys.com/Customers.svc" OutputType="Page" MethodName="GetAllCustomersHtml" FedBindingUseDefaultWebProxy="true" />
Verwendungseigenschaften
Mit den anderen Eigenschaften im Steuerelement soll die Verwendung des Steuerelements gesteuert werden. Die Liste der Eigenschaften ist recht lang, beachten Sie jedoch, dass sie hauptsächlich einer flexiblen Verwendung dienen. Im einfachsten Fall müssen Sie nur ein oder zwei Eigenschaften festlegen oder diese alternativ im Webpart festlegen, das im vierten Teil dieser Serie beschrieben wird. Es folgt eine Liste der Eigenschaften mit einer kurzen Beschreibung zu jeder Eigenschaft.
string WcfUrl – dies ist die URL zum WCF-Dienstendpunkt, d. h. https://azurewcf.vbtoys.com/Customers.svc.
string MethodName – dies ist der Name der Methode, die bei Anforderung der Seite aufgerufen werden soll. Sie können diese Eigenschaft auf die Standardmethode festlegen, die aufgerufen werden soll. Darüber hinaus können Sie auch die AllowQueryStringOverride-Eigenschaft auf false festlegen, wodurch die Seite NUR den von Ihnen im Tag des Steuerelements festgelegten MethodName-Wert verwenden kann. Diese Eigenschaft kann mithilfe einer Abfragezeichenfolge mit dem CASI Kit-Webpart festgelegt werden.
string MethodParams – dies ist eine durch Semikolon getrennte Liste von Parameterwerten, die an den Methodenaufruf übergeben werden sollen. Sie müssen in derselben Reihenfolge aufgeführt sein, wie sie in der Methodensignatur angezeigt werden. Wie in Teil 2 dieser Blogserie erläutert werden von Parameterwerten nur einfache Datentypen wie string, bool, int und datetime unterstützt. Wenn Sie komplexere Objekte als Methodenparameter übergeben möchten, müssen Sie den Parameter als Zeichenfolge festlegen und Ihr Objekt zu XML deserialisieren, bevor die Methode aufgerufen wird. Dann können Sie in der WCF-Anwendung die Zeichenfolge zurück in einer Objektinstanz serialisieren. Wenn Sie dies jedoch als Abfragezeichenfolgenparameter übergeben möchten, müssen Sie die maximale Länge der Abfragezeichenfolge beachten, die vom Browser und von IIS unterstützt wird. Diese Eigenschaft kann mithilfe einer Abfragezeichenfolge mit dem CASI Kit-Webpart festgelegt werden.
object WcfClientProxy – WcfClientProxy wird für den tatsächlichen Aufruf der WCF-Anwendung verwendet. Diese Eigenschaft muss so konfiguriert sein, dass das Benutzertoken zusammen mit dem Aufruf übergeben wird. Daher haben Sie also im letzten Schritt bei der Konfiguration des Codes, den Sie im benutzerdefinierten Steuerelement in der Überschreibung von ExecuteRequest geschrieben haben, dieses Proxyobjekt auf den Dienstanwendungsproxy festgelegt, den Sie für die Verwendung der aktuellen Clientanmeldeinformationen erstellt und konfiguriert haben.
string QueryResultsString – diese Eigenschaft enthält eine Zeichenfolgendarstellung der Ergebnisse, die vom Methodenaufruf zurückgegeben werden. Wenn die WCF-Methode einen einfachen Datentyp wie bool, int, string oder datetime zurückgibt, handelt es sich bei dem Wert dieser Eigenschaft um den Rückgabewert ToString() . Wenn die WCF-Methode eine benutzerdefinierte Klasse zurückgibt, was ebenfalls zulässig ist, deserialisiert die Basisklasse den Rückgabewert in eine Zeichenfolge, sodass die Daten in XML dargestellt werden.
object QueryResultsObject – diese Eigenschaft enthält eine Objektdarstellung der Ergebnisse, die vom Methodenaufruf zurückgegeben werden. Sie ist nützlich, wenn Sie das Steuerelement programmgesteuert verwenden. Wenn Sie das Steuerelement beispielsweise zum Abrufen von Daten zur Speicherung im ASP.NET-Cache verwenden oder zur Verwendung in einem SharePoint-Zeitgeberauftrag, enthält die QueryResultsObject-Eigenschaft exakt die von der WCF-Methode zurückgegebenen Daten. Falls es sich um eine benutzerdefinierte Klasse handelt, können Sie die Ergebnisse dieser Eigenschaft einfach in den entsprechenden Klassentyp umwandeln, um sie zu verwenden.
DataOutputType OutputType – die OutputType-Eigenschaft ist eine Enumeration, die einen von vier Werten enthalten kann: Page, ServerCache, Both oder None. Wenn Sie das Steuerelement auf der layouts-Seite verwenden und die Ergebnisse mit dem Webpart rendern, dann sollte OutputType den Wert Page oder Both haben. Wenn Sie die Daten abrufen und im ASP.NET-Cache speichern möchten, dann sollten Sie ServerCache oder Both verwenden. HINWEIS: Wenn Ergebnisse im Cache gespeichert werden, wird NUR das QueryResultsObject-Element gespeichert. Mit Both werden die Daten sowohl gerendert als auch im ASP.NET-Cache gespeichert. Wenn Sie das Steuerelement nur programmgesteuert wie z. B. in einem SharePoint-Zeitgeberauftrag verwenden, können Sie diese Eigenschaft auf None festlegen, da QueryResultsString oder QueryResultsObject nach dem Aufruf der ExecuteRequest-Methode lediglich gelesen werden. Diese Eigenschaft kann mithilfe einer Abfragezeichenfolge mit dem CASI Kit-Webpart festgelegt werden.
string ServerCacheName – falls Sie einen OutputType-Wert von ServerCache oder Both ausgewählt haben, dann müssen Sie die ServerCacheName-Eigenschaft auf einen nicht leeren Zeichenfolgenwert festlegen, andernfalls wird eine Ausnahme ausgegeben. Dies ist der Schlüssel zum Speichern der Ergebnisse im ASP.NET-Cache. Wenn Sie die ServerCacheName-Eigenschaft z. B. auf MyFooProperty festlegen, können Sie nach dem Aufruf der ExecuteRequest-Methode das Objekt abrufen, das von der WCF-Anwendung zurückgegeben wurde, indem Sie auf HttpContext.Current.Cache["MyFooProperty"] verweisen. Diese Eigenschaft kann mithilfe einer Abfragezeichenfolge mit dem CASI Kit-Webpart festgelegt werden.
int ServerCacheTime – dies ist die Zeit, in Minuten, für die ein Element, das dem ASP.NET hinzugefügt wurde, aufbewahrt werden sollte. Wenn Sie die OutputType-Eigenschaft entweder auf ServerCache oder Both festgelegt haben, müssen Sie auch diese Eigenschaft auf einen nicht leeren Wert festlegen, andernfalls wird eine Ausnahme ausgegeben. Diese Eigenschaft kann mithilfe einer Abfragezeichenfolge mit dem CASI Kit-Webpart festgelegt werden.
bool DecodeResults – diese Eigenschaft wird für den Fall bereitgestellt, dass 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. Diese Eigenschaft kann mithilfe einer Abfragezeichenfolge mit dem CASI Kit-Webpart festgelegt werden.
string SharePointClaimsSiteUrl – diese Eigenschaft wird hauptsächlich für Szenarien bereitgestellt, in denen Sie das Steuerelement programmgesteuert außerhalb einer HTTP-Anforderung erstellen, z. B. in einem SharePoint-Zeitgeberauftrag. Wenn eine Anforderung über das Webpart ausgeführt wird, verwendet die Basisklasse standardmäßig die URL der aktuellen Website, um eine Verbindung mit dem SharePoint-STS-Endpunkt herzustellen und das Benutzertoken für den WCF-Aufruf bereitzustellen. Falls Sie das Steuerelement jedoch programmgesteuert erstellt haben und kein HTTP-Kontext verfügbar ist, können Sie diese Eigenschaft auf die URL der durch Forderungen gesicherten SharePoint-Website festlegen, und diese Website wird zum Zugriff auf SharePoint-STS verwendet. Diese Eigenschaft sollte also nie im Tag für das Steuerelement auf der layouts-Seite festgelegt werden müssen, da beim Aufrufen dieser Seite immer ein HTTP-Kontext vorliegt.
bool AllowQueryStringOverride – mit dieser Eigenschaft können Administratoren ein Tag für ein Steuerelement in der layouts-Seite effektiv sperren. Ist AllowQueryStringOverride auf false festgelegt, werden alle Überschreibungswerte für Abfragezeichenfolgen, die vom CASI Kit-Webpart übergeben werden, ignoriert.
string AccessDeniedMessage – dies ist die Fehlermeldung vom Typ Zugriff verweigert, die im CASI Kit-Webpart angezeigt werden sollte, falls der Zugriff dem Benutzer 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 Meldung in AccessDeniedMessage 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>). Diese Eigenschaft kann mithilfe einer Abfragezeichenfolge mit dem CASI Kit-Webpart festgelegt werden.
string TimeoutMessage – diese Meldung wird im CASI Kit-Webpart angezeigt, wenn ein Timeoutfehler versucht, den WCF-Methodenaufruf auszuführen. Es wird auch eine umfassende Formatierung unterstützt, z. B. das Festlegen der Schriftart auf Fettdruck, Rot usw. Diese Eigenschaft kann mithilfe einer Abfragezeichenfolge mit dem CASI Kit-Webpart festgelegt werden.
Nun gut, das war ein ganz schön langer Beitrag. Er ist jedoch wahrscheinlich auch der längste der Serie, denn er enthält die meisten Informationen zum CASI Kit. Im nächsten Beitrag wird das Webpart beschrieben, das im CASI Kit zum Rendern der Daten aus der WCF-Anwendung verwendet wird, wobei das benutzerdefinierte Steuerelement und die layouts-Seite verwendet werden, die Sie in diesem Schritt entwickelt haben.
An diesen Beitrag angefügt finden Sie zudem eine ZIP-Datei mit dem von mir erstellten Beispielprojekt in Visual Studio 2010, das die CASI Kit-Basisklassenassembly enthält, mein benutzerdefiniertes Steuerelement, das von der CASI Kit-Basisklasse erbt, und die benutzerdefinierte layouts-Seite.
Es handelt sich hierbei um einen übersetzten Blogbeitrag. Sie finden den Originalartikel unter The Claims, Azure and SharePoint Integration Toolkit Part 3