Parte 3 del kit de herramientas de integración de notificaciones, Azure y SharePoint

Parte 3 del kit de herramientas de integración de notificaciones, Azure y SharePoint

Esta es la tercera parte de una serie de cinco partes sobre el kit CASI (del inglés Claims, Azure, and SharePoint Integration). En la parte 1 se presentó la solución y el marco completos y se describieron los temas que se van a tratar en la serie. En la parte 2 se proporcionaron instrucciones para crear aplicaciones WCF, configurarlas para notificaciones y, a continuación, moverlas a Windows Azure. En esta entrada de blog describiré una de las grandes entregas de este marco, que es una clase base de control personalizada que se usa para establecer la conexión desde SharePoint hasta la aplicación WCF hospedada en Windows Azure. Estos son los puntos que se tratarán:

· La clase base: qué es y cómo se usa en el proyecto

· Una página de diseños: cómo agregar el nuevo control a una página en el directorio _layouts

· Propiedades importantes: una explicación de algunas de las propiedades importantes que deben conocerse de la clase base

La clase base del Kit CASI

Una de las entregas principales del kit CASI es la clase base de un control personalizado que se conecta a la aplicación WCF y envía solicitudes con el token de inicio de sesión del usuario actual. La clase base propiamente dicha es un control de servidor ASP.NET estándar y la implementación de este modelo de desarrollo requiere la creación de un nuevo control de servidor ASP.NET que herede de esta clase base. Por motivos que no se abordan en esta entrada de blog, el control en realidad deberá hacer dos cosas:

1. Crear una referencia de servicio a la aplicación WCF hospedada en Windows Azure.

2. Invalidar el método ExecuteRequest en la clase base. Esto es realmente bastante sencillo, porque lo único que debe hacerse es escribir unas cinco líneas de código al crear y configurar el servidor proxy que se va a conectar a la aplicación WCF y, a continuación, llamar al método ExecuteRequest de la clase base.

Para comenzar, puede crear un nuevo proyecto en Visual Studio y elegir el proyecto de tipo biblioteca de clases de Windows. Una vez cambiados el espacio de nombres y el nombre de clase según lo desee, debe agregar una referencia a la clase base del kit CASI, que se encuentra en el ensamblado AzureConnect.dll. También deberá agregar referencias a los ensamblados siguientes: Microsoft.SharePoint, System.ServiceModel, System.Runtime.Serialization y System.Web.

En la clase base, agregue una instrucción using para Microsoft.SharePoint y, a continuación, cambie su clase de modo que herede de AzureConnect.WcfConfig. WcfConfig es la clase base que contiene todo el código y la lógica para conectarse a la aplicación WCF, para incorporar todas las propiedades para agregar flexibilidad a la implementación y para eliminar la necesidad de realizar todos los cambios típicos al archivo web.config que normalmente se necesitan para conectarse a un extremo de servicio WCF. Es importante comprender esto: normalmente necesitaría agregar casi 100 líneas de cambios a web.config para cada aplicación WCF a la que se conecta, en cada archivo web.config de cada servidor para cada aplicación web que lo usa. La clase base WcfConfig encapsula todo ello en el control propiamente dicho, de modo que solo necesita heredar del control y este hará el resto automáticamente. No obstante, todas esas propiedades que se cambiarían en el archivo web.config también pueden cambiarse en el control WcfConfig, ya que expone propiedades de todas ellas. Proporcionaré más detalles sobre esto en la sección de propiedades importantes.

Ahora llegó el momento de agregar una nueva referencia de servicio a la aplicación WCF hospedada en Windows Azure. Aquí no hace falta realizar ninguna tarea específica del kit CASI; tan solo haga clic con el botón secundario en Referencias en el proyecto y seleccione Agregar referencia de servicio. Conecte la dirección URL a la aplicación WCF de Azure con "WSDL" al final para que recupere el WSDL para la implementación del servicio. A continuación, cambie el nombre tal como desee y agregue la referencia, con lo que esta parte ya está completa.

En este momento, dispone de una clase vacía y una referencia de servicio a la aplicación WCF. Ahora llegó el momento de escribir el código, el cual afortunadamente es bastante corto. Deberá invalidar el método ExecuteRequest, crear y configurar el proxy de clase de servicio y, a continuación, llamar al método ExecuteRequest de la clase base. A continuación le presento el código completo del control de ejemplo adjunto a esta entrada de blog. He resaltado en amarillo las partes que debe cambiar para que coincida con la referencia de servicio:

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();

        }

    }

}

Ahí lo tiene; son básicamente cinco líneas de código que puede simplemente copiar de la invalidación de ExcecuteRequest que se muestra aquí y pegar directamente en su propia invalidación. Una vez hecho esto, solo debe reemplazar las partes resaltadas en amarillo con la clase y las interfaces correctas que expone la aplicación WCF. En el código resaltado anterior:

· CustomersWCF.CustomersClient: "CustomersWCF" es el nombre que usé al crear mi referencia de servicio y CustomersClient es el nombre de la clase que expuse mediante mi aplicación WCF. El nombre de clase de mi WCF en realidad es solo "Customers" y las herramientas de adición de referencia de servicio de VS.NET agregan la parte "Client" al final.

· CustomersWCF.ICustomers: "CustomersWCF" es el mismo que acabo de describir. "ICustomers" es la interfaz que creé en mi aplicación WCF, la que realmente implementa mi clase "Customers" de WCF.

Ya está, ese es todo el código que necesita escribir para volver a proporcionar esa conexión a la aplicación WCF hospedada en Windows Azure. Espero que esté de acuerdo en que es bastante sencillo. Para que tenga un poco de contexto, el código que ha escrito es lo que permite que la llamada a la aplicación WCF pase a través del token del usuario de SharePoint. Esto se explica un poco más detalladamente en esta otra entrada de blog: https://blogs.technet.com/b/speschka/archive/2010/09/08/calling-a-claims-aware-wcf-service-from-a-sharepoint-2010-claims-site.aspx.

Ahora que el código está completo, debe asegurarse de registrar la clase base y el nuevo control personalizado en la memoria caché global de ensamblados de cada servidor donde se usará. Obviamente, esto es muy fácil con una solución de SharePoint. Una vez finalizado y registrado el control, llegó la hora de aprender a usarlo para recuperar y representar datos. En el kit CASI, traté de considerar tres escenarios principales para el uso de datos de Azure:

1. Representación de contenido en una página de SharePoint mediante un elemento web

2. Recuperación de datos de configuración para su uso por parte de controles uno a varios y su almacenamiento en la memoria caché de ASP.NET

3. Recuperación de datos y su uso en ejecutables de tipo de tarea, tal como un trabajo del temporizador de SharePoint

El primer escenario es probablemente el más general, por lo que lo abordaremos en primer lugar. Una vez establecida esta metodología, lo más sencillo sería crear un elemento web personalizado que realice todas estas llamadas durante un evento Load o algo similar, recuperar los datos y representarlos en la página. Esto, sin embargo, creo que sería un GRAN error. El encapsulado del código en el elemento web propiamente dicho, de modo que se ejecute en el servidor durante el procesamiento de una solicitud de página, podría perjudicar en gran medida el rendimiento general del conjunto o granja de servidores. He tenido mis serias dudas acerca de incluir elementos web uno a varios en una página que realiza llamadas latentes uno o varios entre aplicaciones y centros de datos para recuperar datos, y fácilmente podría imaginar un escenario en el que el uso intensivo literalmente derrumbaría una granja de servidores completa. Sin embargo, uno de los requisitos es que algún código debe ejecutarse en el servidor, ya que es necesario para configurar el canal a la aplicación WCF para enviar el token de usuario junto con la solicitud. La solución que propongo consta de dos partes:

1. Una página personalizada hospedada en la carpeta _layouts. Incluirá el control personalizado que acabamos de escribir y realmente representará los datos que se devuelven de la llamada de WCF.

2. Un elemento web personalizado que no ejecuta NINGÚN CÓDIGO en el servidor, sino que usa JavaScript y jQuery para invocar la página en la carpeta _layouts. Lee los datos devueltos desde la página y, a continuación, los entrega a una función de JavaScript que, de forma predeterminada, solo representará el contenido en el elemento web. El elemento web puede hacer mucho más que eso, por supuesto, pero esto lo abordaré en detalle en la próxima entrada de blog. El resultado es que cuando un usuario solicita la página, esta se procesa sin tener que realizar ninguna llamada latente adicional a la aplicación WCF. En su lugar, la página atraviesa la canalización de procesamiento y llega de inmediato al explorador del usuario. A continuación, una vez cargada la página completamente, se realiza la llamada para recuperar solo el contenido de WCF.

La página de diseños

La página de diseños que hospedará el control personalizado es realmente muy fácil de escribir. Lo hice todo en el Bloc de notas en unos cinco minutos. Y con algo de suerte le resultará incluso más rápido, ya que copiaré y pegaré mi página de diseños aquí para mostrarle lo que debe reemplazar en su página.

<%@ 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>

 

Una vez más, la implementación de la página en sí es realmente muy fácil. Lo que absolutamente debe cambiarse es el nombre seguro del ensamblado del control personalizado. Con fines ilustrativos, también he resaltado un par de las propiedades de la etiqueta de control. Estas propiedades son específicas de mi servicio WCF, por lo que puede cambiarlas y, en algunos casos, eliminarlas por completo en su implementación. Las propiedades se describirán más adelante con mayor detalle. Una vez creada la página de diseños, debe distribuirse al directorio _layouts de cada servidor front-end web de la granja de servidores de SharePoint. En ese momento, puede llamarse desde cualquier sitio web para notificaciones de la granja de SharePoint. Obviamente, no debe esperar que funcione en un sitio de autenticación clásico, como Administración central. Una vez implementada la página, podrá usarla el elemento web del kit CASI, que se describirá en la parte 4 de esta serie.

Propiedades importantes

WcfConfig contiene dos grandes categorías de propiedades: las que se usan para configurar el canal y la conexión a la aplicación WCF y las que configuran el uso del control propiamente dicho.

Propiedades de WCF

Como se describió anteriormente, toda la información de configuración de la aplicación WCF que normalmente se encuentra en el archivo web.config se ha encapsulado en el control WcfConfig. Sin embargo, prácticamente todas esas propiedades están expuestas para que puedan modificarse en función de las necesidades de su implementación. Dos excepciones importantes son la versión de seguridad del mensaje, que es siempre MessageSecurityVersion.WSSecurity11WSTrust13WSSecureConversation13WSSecurityPolicy12BasicSecurityProfile10, y el transporte, que es siempre HTTPS, no HTTP. Por otra parte, el control tiene varias propiedades que puede resultar conveniente conocer un poco mejor en la implementación (aunque normalmente no es necesario cambiarlas).

En primer lugar, hay cinco propiedades de solo lectura para exponer los objetos de configuración de nivel superior usados en la configuración. Cuando digo solo lectura, me refiero a que los objetos en sí son de solo lectura, pero puede establecer sus propiedades individuales si trabaja con el control mediante programación. Esas cinco propiedades son:

SecurityBindingElement SecurityBinding

BinaryMessageEncodingBindingElement BinaryMessage

HttpsTransportBindingElement SecureTransport

WS2007FederationHttpBinding FedBinding

EndpointAddress WcfEndpointAddress

Todas las demás propiedades pueden configurarse en la etiqueta de control agregada a la página aspx de diseños. Para estas propiedades he usado una convención de nomenclatura que esperaba que tuviera sentido para valores de propiedad compuestos. Por ejemplo, la propiedad SecurityBinding tiene una propiedad denominada LocalClient, que tiene una propiedad booleana denominada CacheCookies. Para lograr que comprenda esto tan fácilmente como sea posible, he creado solo una propiedad denominada SecurityBindingLocalClientCacheCookies. Verá varias propiedades como esta, lo que también será una pista para encontrar la propiedad correcta si busca en el SDK de .NET Framework y se pregunta cómo modificar algunos de esos valores de propiedad en la implementación de la clase base. Esta es la lista de propiedades completa:

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

Una vez más, todas ellas se crearon para poder modificarse directamente en la etiqueta de control de la página aspx de diseños. Por ejemplo, así debería establecer la propiedad FedBindingUseDefaultWebProxy:

<AzWcf:WcfDataControl runat="server" id="wcf" WcfUrl="https://azurewcf.vbtoys.com/Customers.svc" OutputType="Page" MethodName="GetAllCustomersHtml" FedBindingUseDefaultWebProxy="true" />

 

Propiedades de uso

Las demás propiedades del control están diseñadas para controlar su uso. Aunque la lista de propiedades es un poco larga, tenga en cuenta que con ellas se pretende principalmente un uso más flexible. En una instancia simple, solo deberá establecer una o dos propiedades o, como alternativa, simplemente las podrá establecer en el elemento web descrito en la parte 4 de esta serie. Esta es una lista de las propiedades con una breve descripción de cada una.

string WcfUrl: es la dirección URL al extremo de servicio WCF, es decir, https://azurewcf.vbtoys.com/Customers.svc.

string MethodName: es el nombre del método que se debe invocar cuando se solicita la página. Se puede establecer en el método que se invocará de forma predeterminada. Además, también puede establecer la propiedad AllowQueryStringOverride en false, lo que restringirá la página para que SOLO use la propiedad MethodName definida en la etiqueta de control. Esta propiedad puede establecerse a través de una cadena de consulta mediante el elemento web del kit CASI.

string MethodParams: es una lista delimitada por punto y coma de los valores de parámetro que deben pasarse a la llamada de método. Deben aparecer en el mismo orden en que aparecen en la firma del método. Tal como se explica en la parte 2 de esta serie de blog, los valores de parámetro en realidad solo admiten tipos de datos simples, como string, bool, int y datetime. Si desea pasar objetos más complejos como parámetros de método, debe convertir el parámetro en una cadena y deserializar el objeto en XML antes de llamar al método y, a continuación, en la aplicación WCF, puede volver a serializar la cadena en una instancia de objeto. No obstante, si se pasa como un parámetro de cadena de consulta, se verá limitado por la longitud de cadena de consulta máxima que admiten IIS y su explorador. Esta propiedad puede establecerse a través de una cadena de consulta mediante el elemento web del kit CASI.

object WcfClientProxy: es lo que se usa para hacer realmente la llamada a la aplicación WCF. Debe configurarse de modo que permita pasar el token de usuario junto con la llamada. Es por ello que el último código de configuración que se escribe en el control personalizado en la invalidación de ExecuteRequest consiste en establecer este objeto proxy igual al proxy de la aplicación de servicio creada y configurada para usar las credenciales de cliente actuales.

string QueryResultsString: esta propiedad contiene una representación de cadena de los resultados devueltos por la llamada de método. Si el método de WCF devuelve un tipo de datos simple como bool, int, string o datetime, el valor de esta propiedad será el valor devuelto ToString(). Si el método de WCF devuelve una clase personalizada que también funciona correctamente, cuando la clase base obtenga el valor devuelto, lo deserializará en una cadena, por lo que tendrá una representación XML de los datos.

object QueryResultsObject: esta propiedad contiene una representación de objeto de los resultados devueltos por la llamada de método. Resulta útil cuando se usa el control mediante programación. Por ejemplo, si usa el control para recuperar datos para almacenarlos en la memoria caché de ASP.NET o para usarlos en un trabajo del temporizador de SharePoint, la propiedad QueryResultsObject tendrá exactamente lo que devuelve la llamada de método de WCF. Si es una clase personalizada, simplemente puede convertir los resultados de esta propiedad en el tipo de clase adecuado para usarla.

DataOutputType OutputType: es una enumeración que puede ser uno de cuatro valores: Page, ServerCache, Both o None. Si usa el control en la página de diseños y va a representar los resultados con el elemento web, OutputType debe ser Page o Both. Si desea recuperar los datos y almacenarlos en la memoria caché de ASP.NET, debe usar ServerCache o Both. NOTA: al almacenar resultados en la memoria caché, SOLO se almacena QueryResultsObject. Obviamente, Both representará los datos y los almacenará en la memoria caché de ASP.NET. Si solo usa el control mediante programación en algo como un trabajo del temporizador de SharePoint, puede establecer esta propiedad en None, ya que solo se leerá QueryResultsString o QueryResultsObject después de llamar al método ExecuteRequest. Esta propiedad puede establecerse a través de una cadena de consulta mediante el elemento web del kit CASI.

string ServerCacheName: si establece ServerCache o Both para OutputType, debe establecer la propiedad ServerCacheName en un valor de cadena no vacío, de lo contrario se iniciará una excepción. Esta es la clave que se usará para almacenar los resultados en la memoria caché de ASP.NET. Por ejemplo, si establece la propiedad ServerCacheName en "MyFooProperty", después de llamar al método ExecuteRequest podrá recuperar el objeto devuelto de la aplicación WCF mediante una referencia a HttpContext.Current.Cache["MyFooProperty"]. Esta propiedad puede establecerse a través de una cadena de consulta mediante el elemento web del kit CASI.

int ServerCacheTime: es la cantidad de tiempo, en minutos, en la que debe conservarse un elemento agregado a la memoria caché de ASP.NET. Si establece la propiedad OutputType en ServerCache o Both, también debe establecer esta propiedad en un valor distinto de cero; de lo contrario se iniciará una excepción. Esta propiedad puede establecerse a través de una cadena de consulta mediante el elemento web del kit CASI.

bool DecodeResults: esta propiedad se proporciona en caso de que la aplicación WCF devuelva resultados codificados en HTML. Si establece esta propiedad en true, se aplicará descodificación HTML a los resultados. En la mayoría de los casos, esto no es necesario. Esta propiedad puede establecerse a través de una cadena de consulta mediante el elemento web del kit CASI.

string SharePointClaimsSiteUrl: esta propiedad se proporciona principalmente para escenarios donde se va a crear el control mediante programación fuera de una solicitud HTTP, como en un trabajo del temporizador de SharePoint. De forma predeterminada, cuando se realiza una solicitud mediante el elemento web, la clase base usa la dirección URL del sitio actual para conectarse al extremo STS de SharePoint para proporcionar el token de usuario para la llamada de WCF. Sin embargo, si ha creado el control mediante programación y no tiene un contexto HTTP, puede establecer esta propiedad en la dirección URL de un sitio de SharePoint seguro para notificaciones y dicho sitio se usará para obtener acceso al STS de SharePoint. Así que, por ejemplo, nunca debería necesitar establecer esta propiedad en la etiqueta de control de la página de diseños, ya que siempre tendrá un contexto HTTP al invocar esa página.

bool AllowQueryStringOverride: esta propiedad permite a los administradores bloquear eficazmente una etiqueta de control en la página de diseños. Si AllowQueryStringOverride se establece en false, se omitirán todos los valores de invalidación de cadena de consulta pasados desde el elemento web del kit CASI.

string AccessDeniedMessage: es el mensaje de error de acceso denegado que debe mostrarse en el elemento web del kit CASI si se deniega el acceso al usuario para un método concreto. Por ejemplo, como se explica en la parte 2 de esta serie, dado que se pasa el token del usuario junto con la llamada de WCF, puede decorar cualquiera de los métodos con una demanda PrincipalPermission, como "este usuario debe formar parte del grupo de jefes de ventas". Si un usuario no cumple con una demanda PrincipalPermission, se producirá un error de acceso denegado en la llamada de WCF. En ese caso, el elemento web mostrará lo que aparezca en AccessDeniedMessage. Tenga en cuenta que puede usar formato enriquecido en este mensaje para realizar tareas como establecer la fuente en negrita o en rojo mediante etiquetas HTML (por ejemplo, <font color='red'>No dispone de acceso; póngase en contacto con su administrador</font>). Esta propiedad puede establecerse a través de una cadena de consulta mediante el elemento web del kit CASI.

string TimeoutMessage: es el mensaje que se mostrará en el elemento web del kit CASI si se produce un error de tiempo de espera al intentar ejecutar la llamada de método de WCF. También admite el formato enriquecido, como establecer la fuente en negrita, rojo, etc. Esta propiedad puede establecerse a través de una cadena de consulta mediante el elemento web del kit CASI.

Admito que esta ha sido una EXTENSA entrada de blog, pero probablemente será la más extensa de la serie, ya que contiene la información más importante del kit CASI. En la siguiente entrada de blog, describiré el elemento web que se incluye con el kit CASI para representar los datos de la aplicación WCF mediante la página de diseños y el control personalizado desarrollados en este paso.

Además, en esta entrada de blog encontrará un archivo zip adjunto que contiene el proyecto de Visual Studio 2010 de ejemplo que he creado y que incluye el ensamblado de la clase base del kit CASI, mi control personalizado que hereda de la clase base del kit CASI y mi página de diseños personalizada.

Esta entrada de blog es una traducción. Puede consultar el artículo original en The Claims, Azure and SharePoint Integration Toolkit Part 3