Kit de integração de Declarações, Azure e SharePoint Parte 3
Kit de integração de Declarações, Azure e SharePoint Parte 3
Esta é a parte 3 de uma série de cinco partes sobre o Kit CASI (Integração de Declarações, Azure e SharePoint). A Parte 1 foi uma visão geral introdutória sobre a estrutura e a solução completas e descreveu o que a série tentará abordar. A Parte 2 abordou a orientação para a criação de aplicativos WCF, a transformação deles em aplicativos com reconhecimento de declaração e sua adaptação para uso no Windows Azure. Nesta postagem, discutiremos um dos importantes resultados finais dessa estrutura, que é uma classe base de controle personalizado que você usa para hospedar a conexão do SharePoint ao seu aplicativo WCF no Windows Azure. Estes são os itens que abordaremos:
· A classe base – o que é, como usá-la em seu projeto
· Uma página Layouts – como adicionar seu novo controle a uma página do diretório _layouts
· Propriedades importantes – uma discussão sobre algumas das propriedades importantes da classe base que você deve conhecer
A classe base do Kit CASI
Um dos principais resultados finais do Kit CASI é a classe base para um controle personalizado que se conecta ao seu aplicativo WCF e que envia solicitações com o token de logon do usuário atual. A própria classe base é um controle de servidor ASP.NET padrão e a implementação desse padrão de desenvolvimento exige que você crie um novo controle de servidor ASP.NET que herda dessa classe base. Por motivos que estão além do escopo desta postagem, o seu controle realmente precisará fazer duas coisas:
1. Criar uma referência de serviço para seu aplicativo WCF hospedado no Windows Azure.
2. Substituir o método ExecuteRequest na classe base. Na verdade, isso é bem simples, porque tudo o que você precisa fazer é escrever cinco linhas de código para criar e configurar o proxy que se conectará ao seu aplicativo WCF e depois chamar o método ExecuteRequest da classe base.
Para começar a fazer isso, você pode criar um novo projeto no Visual Studio e escolher o projeto do tipo Windows Class Library. Depois de alterar seu namespace e o nome da classe para o desejado, adicione uma referência à classe base do Kit CASI, que está no assembly AzureConnect.dll. Também será necessário adicionar referências aos seguintes assemblies: Microsoft.SharePoint, System.ServiceModel, System.Runtime.Serialization e System.Web.
Em sua classe base, adicione uma instrução using para o Microsoft.SharePoint e altere sua classe para que ela herde de AzureConnect.WcfConfig. WcfConfig é a classe base que contém o código e a lógica para a conexão ao aplicativo WCF, incorpora todas as propriedades para adicionar flexibilidade à implementação e elimina a necessidade de todas as alterações típicas do web.config que normalmente são necessárias para a conexão a um ponto de extremidade do serviço WCF. É importante compreender isto – normalmente, você precisaria adicionar quase 100 linhas de alterações do web.config para todos os aplicativos WCF a serem conectados, para todos os arquivos web.config em todos os servidores para todos os aplicativos web que os utilizem. A classe base WcfConfig envolve tudo isso no próprio controle para que você possa simplesmente herdar do controle e ele faça o resto. Todas essas propriedades que seriam alteradas no arquivo web.config também podem ser alteradas no controle WcfConfig, uma vez que ele expõe propriedades para todas elas. Discutirei este assunto em mais detalhes na seção sobre propriedades importantes.
É hora de adicionar uma nova Referência de Serviço ao seu aplicativo WCF hospedado no Windows Azure. Não há nada específico no Kit CASI que tenha de ser feito aqui – basta clicar com o botão direito do mouse em Referências em seu projeto e selecionar Adicionar Referência de Serviço. Conecte a Url no seu aplicativo WCF do Azure com “?WSDL” no final para que ele recupere o WSDL para a implementação do seu serviço. Em seguida, altere o nome para o que você quiser, adicione a referência e esta parte estará concluída.
Neste ponto, você tem uma classe vazia e uma referência de serviço para o seu aplicativo WCF. Agora é a hora de escrever o código que, felizmente, é bem pequeno. É preciso substituir o método ExecuteRequest, criar e configurar o proxy da classe de serviço e chamar o método ExecuteRequest da classe base. Para simplificar, aqui está o código completo para o controle de exemplo que estou anexando a esta postagem. Realcei em amarelo as partes que você precisa alterar para que elas correspondam à sua referência de serviço:
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Diagnostics;
using Microsoft.SharePoint;
//exige Referências a:
//1. AzureConnect
//2. Microsoft.SharePoint
//3. System.ServiceModel
//4. System.Runtime.Serialization
//5. System.Web
namespace AzureWcfPage
{
public class WcfDataControl : AzureConnect.WcfConfig
{
//este método deve ser substituído para que o proxy possa ser
//configurado e criado corretamente
public override bool ExecuteRequest()
{
try
{
//crie a instância do proxy com associações e crie um ponto de extremidade para a classe base
//o controle de configuração foi criado para isto
CustomersWCF.CustomersClient cust =
new CustomersWCF.CustomersClient(this.FedBinding,
this.WcfEndpointAddress);
//configure o canal para que possamos chamá-lo com
//FederatedClientCredentials.
SPChannelFactoryOperations.ConfigureCredentials<CustomersWCF.ICustomers>
(cust.ChannelFactory,
Microsoft.SharePoint.SPServiceAuthenticationMode.Claims);
//crie um canal para o ponto de extremidade WCF usando o
//token e declarações do usuário atual
CustomersWCF.ICustomers claimsWCF =
SPChannelFactoryOperations.CreateChannelActingAsLoggedOnUser
<CustomersWCF.ICustomers>(cust.ChannelFactory,
this.WcfEndpointAddress,
new Uri(this.WcfEndpointAddress.Uri.AbsoluteUri));
//defina a propriedade cliente para a classe base
this.WcfClientProxy = claimsWCF;
}
catch (Exception ex)
{
Debug.WriteLine(ex.Message);
}
//agora que a configuração foi concluída, chame o método
return base.ExecuteRequest();
}
}
}
Então é isto – basicamente, cinco linhas de código e você pode simplesmente copiar e colar diretamente o código do substituto de ExcecuteRequest mostrado aqui em seu próprio substituto. Depois de fazer isso, basta substituir as partes realçadas em amarelo pelas interfaces e pela classe apropriadas expostas por seu aplicativo WCF. No código realçado acima:
· CustomersWCF.CustomersClient: “CustomersWCF” é o nome que usei ao criar minha referência de serviço, e CustomersClient é o nome da classe que expus por meio do meu aplicativo WCF. Na verdade, o nome da classe em meu WCF é simplesmente “Customers” e as ferramentas de referência de serviço do VS.NET adicionam a parte “Client” ao final.
· CustomersWCF.ICustomers: O “CustomersWCF” é igual ao descrito acima. “ICustomers” é a interface que criei em meu aplicativo WCF e que a classe “Customers” do meu WCF implementa.
Isso é tudo – esse é todo o código necessário para oferecer a conexão ao seu aplicativo WCF hospedado no Windows Azure. Espero que você concorde que ele não é tão complicado. Para proporcionar um pouco de contexto: o código que você escreveu é o que permite que a chamada ao aplicativo WCF passe o token do usuário do SharePoint. Isso é explicado em mais detalhes nesta outra postagem que fiz: https://blogs.technet.com/b/speschka/archive/2010/09/08/calling-a-claims-aware-wcf-service-from-a-sharepoint-2010-claims-site.aspx.
Agora que o código foi concluído, você precisa garantir o registro da classe base e do seu novo controle personalizado no Cache de Assembly Global de todos os servidores onde eles serão usados. Obviamente, isso pode ser feito facilmente com uma solução do SharePoint. Com o controle concluído e registrado, é hora de examinar como você o usará para recuperar e renderizar dados. No Kit CASI, tentei tratar de três cenários fundamentais para o uso de dados do Azure:
1. Renderização de conteúdo em uma página do SharePoint usando uma Web Part
2. Recuperação de dados de configuração para que um ou muitos controles os utilizem e o armazenamento dos dados em um cache do ASP.NET
3. Recuperação de dados e a utilização deles em executáveis de tipo de tarefa, como o trabalho de timer do SharePoint
O primeiro cenário provavelmente será o mais comumente encontrado e, portanto, será o que mostrarei primeiro. O mais fácil a ser feito depois de mapear esta metodologia seria criar uma Web Part personalizada que fizesse todas estas chamadas durante um evento Load ou algo parecido, recuperasse os dados e os renderizasse na página. No entanto, isso seria um erro IMENSO. Se você envolver esse código na própria Web Part, para que ele execute no servidor durante o processamento de uma solicitação de página, isso poderá reduzir severamente a taxa de transferência do farm. Não me agradou a ideia de ter Web Parts com a relação uma-para-muitas em uma página fazendo chamadas latentes do tipo uma-para-muitas para aplicativos e data centers a fim de recuperar dados, e pude prever com muita facilidade um cenário onde a ampla utilização poderia derrubar um farm inteiro. Entretanto, existe o requisito de que uma parte do código deve ser executada no servidor, porque é necessária para configurar o canal para o aplicativo WCF para que ele envie o token do usuário junto com a solicitação. A minha solução para isso consiste em duas partes:
1. Uma página personalizada hospedada na pasta _layouts. Ela conterá o controle personalizado que acabamos de escrever e, na verdade, vai renderizar os dados retornados da chamada WCF.
2. Uma Web Part personalizada que NÃO EXECUTA CÓDIGO no servidor, mas que usa JavaScript e jQuery para chamar a página na pasta _layouts. Ela lê os dados retornados da página e os entrega para uma função JavaScript que, por padrão, renderizará o conteúdo na Web Part. É claro que é possível fazer muito mais usando uma Web Part, mas abordaremos a Web Part em detalhes na próxima postagem. A ideia é que, quando um usuário solicita a página, ela é processada sem precisar fazer chamadas latentes adicionais ao aplicativo WCF. Em vez disso, a página passa pelo pipeline de processamento e segue diretamente para o navegador do usuário. Então, depois que a página é totalmente carregada, a chamada é feita para recuperar somente o conteúdo WCF.
A página de layouts
A página de layouts que hospedará o seu controle personalizado é, na verdade, muito fácil de escrever. Eu a criei no Bloco de Notas em cerca de cinco minutos. Felizmente, será ainda mais rápido para você, porque copiarei e colarei a minha página de layouts aqui e mostrarei o que você precisa substituir na sua 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>
Novamente, a implementação da página é realmente fácil. Tudo o que deve ser alterado é o nome forte do assembly para o seu controle personalizado. Para fins ilustrativos, também realcei algumas propriedades na própria marca do controle. Essas propriedades são específicas do meu serviço WCF e podem ser alteradas e, em alguns casos, totalmente removidas da sua implementação. As propriedades serão discutidas em mais detalhes a seguir. Depois de criada, a página de layouts precisa ser distribuída para o diretório _layouts de todos os servidores Web front-end do seu farm do SharePoint. Neste ponto, ela poderá ser chamada de qualquer site em qualquer aplicativo Web com reconhecimento de declaração em seu farm do SharePoint. Obviamente, você não deve esperar que isso funcione em um site de autenticação clássico, como a Administração Central. Depois de implantada, a página poderá ser usada pela Web Part do Kit CASI, que será descrita na Parte 4 desta série.
Propriedades importantes
O WcfConfig contém duas grandes categorias de propriedades – aquelas para a configuração do canal e da conexão para o aplicativo WCF e aquelas que configuram o uso do controle propriamente dito.
Propriedades do WCF
Como descrito anteriormente, todas as informações de configuração do aplicativo WCF normalmente contidas no arquivo web.config foram encapsuladas no controle WcfConfig. No entanto, quase todas essas propriedades estão expostas de forma que possam ser modificadas, dependendo das necessidades da sua implementação. Duas exceções importantes são a versão de segurança da mensagem, que sempre será MessageSecurityVersion.WSSecurity11WSTrust13WSSecureConversation13WSSecurityPolicy12BasicSecurityProfile10, e o transporte, que sempre será HTTPS, não HTTP. Fora isso, o controle possui várias propriedades com as quais vale a pena se familiarizar para sua implementação (embora geralmente não seja necessário alterá-las).
Primeiro, existem cinco propriedades somente leitura para expor os objetos de configuração de nível superior usados na configuração. Ao mencionar somente leitura, quero dizer que os próprios objetos são somente leitura, mas você pode definir as propriedades individuais deles caso esteja trabalhando com o controle programaticamente. As propriedades são:
SecurityBindingElement SecurityBinding
BinaryMessageEncodingBindingElement BinaryMessage
HttpsTransportBindingElement SecureTransport
WS2007FederationHttpBinding FedBinding
EndpointAddress WcfEndpointAddress
As outras propriedades podem ser configuradas na marca do controle adicionada à página aspx de layouts. Para essas propriedades, usei uma convenção de nomenclatura que esperava fazer sentido para valores de propriedade composta. Por exemplo, a propriedade SecurityBinding tem uma propriedade chamada LocalClient, que possui uma propriedade booliana chamada CacheCookies. Para torná-la fácil de entender e para permitir que seja usada sempre que possível, criei uma propriedade chamada SecurityBindingLocalClientCacheCookies. Você verá diversas propriedades como essa, e isso também é uma dica de como encontrar a propriedade certa se você estiver procurando no SDK do .NET Framework e quiser saber como pode modificar alguns dos valores dessas propriedades na implementação da classe base. Abaixo está uma lista completa de propriedades:
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
Novamente, tudo isso foi criado de forma que possa ser modificado diretamente na marca de controle da página aspx de layouts. Por exemplo, veja como você definiria a propriedade FedBindingUseDefaultWebProxy:
<AzWcf:WcfDataControl runat="server" id="wcf" WcfUrl="https://azurewcf.vbtoys.com/Customers.svc" OutputType="Page" MethodName="GetAllCustomersHtml" FedBindingUseDefaultWebProxy="true" />
Propriedades de uso
As outras propriedades do controle foram criadas para controlar a forma como ele é usado. Embora haja uma lista relativamente extensa de propriedades, observe que elas se destinam principalmente à flexibilidade de uso – para o simples caso de você só precisar definir uma ou duas propriedades ou, alternativamente, simplesmente defini-las na Web Part que será descrita na Parte 4 desta série. Veja uma lista com todas as propriedades e uma breve descrição delas.
string WcfUrl – é a Url do ponto de extremidade do serviço WCF, isto é, https://azurewcf.vbtoys.com/Customers.svc.
string MethodName – é o nome do método que deve ser chamado quando a página é solicitada. Você pode defini-la para mostrar que método será chamado por padrão. Além disso, você também pode definir a propriedade AllowQueryStringOverride como falsa, o que restringirá a página a usar SOMENTE o MethodName definido na marca do controle. Essa propriedade pode ser definida por meio de uma cadeia de caracteres de consulta usando a Web Part do Kit CASI.
string MethodParams – é uma lista de valores de parâmetro delimitada por ponto-e-vírgula que devem ser passados para a chamada do método. Eles precisam estar na mesma ordem como aparecem na assinatura do método. Como explicado na Parte 2 desta série de blog, os valores de parâmetro só oferecem suporte a tipos de dados simples, como string, bool, int e datetime. Se quiser passar objetos mais complexos, como parâmetros de método, você precisará transformar o parâmetro em cadeia de caracteres, desserializar o seu objeto como Xml antes de chamar o método e, então, será possível serializar a cadeia de caracteres novamente para uma instância do objeto no seu aplicativo WCF. Se isso for passado como um parâmetro de cadeia de caracteres de consulta, você ficará limitado ao tamanho máximo da cadeia de caracteres de consulta com suporte em seu navegador e no IIS. Essa propriedade pode ser definida por meio de uma cadeia de caracteres de consulta usando a Web Part do Kit CASI.
object WcfClientProxy – WcfClientProxy é usado para realmente fazer a chamada ao Aplicativo WCF. Precisa ser configurado para oferecer suporte à passagem do token do usuário com a chamada; por esse motivo, o último código de configuração escrito no seu controle personalizado no substituto de ExecuteRequest define esse objeto de proxy como igual ao proxy do aplicativo de serviço criado e configurado para usar as credenciais do cliente atual.
string QueryResultsString – essa propriedade contém uma representação de cadeia de caracteres dos resultados retornados da chamada ao método. Se o seu método WCF retornar um tipo de dados simples como bool, int, string ou datetime, o valor dessa propriedade será o valor de retorno ToString(). Se o seu método WCF retornar uma classe personalizada, isso não é um problema – quando a classe base obtém o valor de retorno, ela o desserializa para uma cadeia de caracteres para que você tenha uma representação Xml dos dados.
object QueryResultsObject – essa propriedade contém uma representação de objeto dos resultados retornados da chamada ao método. Será útil quando você estiver usando o controle programaticamente. Por exemplo, se você estiver usando o controle para recuperar dados para armazená-los no cache do ASP.NET, ou para usá-los em um trabalho de timer do SharePoint, a propriedade QueryResultsObject terá exatamente o que a chamada ao método WCF retornou. Se for uma classe personalizada, você poderá simplesmente converter os resultados dessa propriedade para o tipo de classe apropriado para uso.
DataOutputType OutputType – a propriedade OutputType é uma enumeração que pode ter um de quatro valores: Page, ServerCache, Both ou None. Se você estiver usando o controle na página de layouts e se pretende renderizar os resultados com a Web Part, OutputType deverá ser Page ou Both. Se quiser recuperar os dados ou armazená-los no cache do ASP.NET, use ServerCache ou Both. OBSERVAÇÃO: Ao armazenar os resultados em cache, SOMENTE QueryResultsObject será armazenado. Obviamente, Both renderizará os dados e os armazenará no cache do ASP.NET. Se você só estiver usando o controle programaticamente em algo como um trabalho de timer do SharePoint, poderá definir essa propriedade como None, uma vez que você só lerá QueryResultsString ou QueryResultsObject depois de chamar o método ExecuteRequest. Essa propriedade pode ser definida por meio de uma cadeia de caracteres de consulta usando a Web Part do Kit CASI.
string ServerCacheName – se você optar por um OutputType que seja ServerCache ou Both, precisará definir a propriedade ServerCacheName como um valor de cadeia de caracteres não vazio ou uma exceção será lançada. Essa é a chave que será usada para armazenar os resultados no cache do ASP.NET. Por exemplo, se você definir a propriedade ServerCacheName como “MyFooProperty”, depois de chamar o método ExecuteRequest você poderá recuperar o objeto retornado do aplicativo WCF fazendo referência a HttpContext.Current.Cache["MyFooProperty"]. Essa propriedade pode ser definida por meio de uma cadeia de caracteres de consulta usando a Web Part do Kit CASI.
int ServerCacheTime – é o tempo, em minutos, pelo qual um item adicionado ao cache do ASP.NET deve ser mantido. Se você definir a propriedade OutputType como ServerCache ou Both, também deverá defini-la como um valor diferente de zero ou uma exceção será lançada. Essa propriedade pode ser definida por meio de uma cadeia de caracteres de consulta usando a Web Part do Kit CASI.
bool DecodeResults – essa propriedade é fornecida caso o seu aplicativo WCF retorne resultados HtmlEncoded. Se você definir essa propriedade como verdadeira, HtmlDecoding será aplicado aos resultados. Na maioria dos casos, isso não será necessário. Essa propriedade pode ser definida por meio de uma cadeia de caracteres de consulta usando a Web Part do Kit CASI.
string SharePointClaimsSiteUrl – essa propriedade destina-se, principalmente, a cenários onde você esteja criando o controle programaticamente fora de uma solicitação Http, como em um trabalho de timer do SharePoint. Por padrão, quando uma solicitação for feita por meio da Web Part, a classe base usará a Url do site atual para conectar-se ao ponto de extremidade STS do SharePoint para oferecer o token do usuário à chamada WCF. No entanto, se você tiver criado o controle programaticamente e se não tiver um contexto Http, poderá definir essa propriedade como a Url de um site do SharePoint protegido por declarações e esse site será usado para acessar o STS do SharePoint. Assim, por exemplo, não será necessário definir essa propriedade na marca de controle na página de layouts, uma vez que você sempre terá um contexto Http ao chamar essa página.
bool AllowQueryStringOverride – essa propriedade permite que os administradores bloqueiem efetivamente uma marca de controle na página de layouts. Se AllowQueryStringOverride for definido como falso, qualquer valor de substituição de cadeia de caracteres de consulta passado da Web Part do Kit CASI será ignorado.
string AccessDeniedMessage – é a mensagem de erro Acesso Negado que deve ser exibida na Web Part do Kit CASI caso seja negado o acesso do usuário a um método em particular. Por exemplo, como explicado na Parte 2 desta série, uma vez que estamos passando o token do usuário junto com a chamada WCF, podemos enfeitar qualquer um dos métodos com uma demanda PrincipalPermission, como “este usuário deve fazer parte do grupo Gerentes de Vendas”. Se um usuário não atender à demanda PrincipalPermission, a chamada do WCF falhará com um erro de acesso negado. Nesse caso, a Web Part exibirá AccessDeniedMessage, seja ela qual for. Observe que você pode usar a formatação em RTF nesta mensagem, para fazer coisas como definir a fonte como negrito ou vermelha usando marcas HTML (isto é, <font color='red'>Você não tem acesso; entre em contato com o administrador</font>). Essa propriedade pode ser definida por meio de uma cadeia de caracteres de consulta usando a Web Part do Kit CASI.
string TimeoutMessage – é a mensagem que será exibida na Web Part do Kit CASI caso haja um erro de tempo limite durante a tentativa de executar a chamada ao método WCF. Também oferece suporte à formatação em RTF, como a definição da fonte como negrito, vermelha etc. Essa propriedade pode ser definida por meio de uma cadeia de caracteres de consulta usando a Web Part do Kit CASI.
Certo, esta postagem foi realmente LONGA, mas provavelmente será a maior da série, uma vez que contém a parte mais significativa do Kit CASI. Na próxima postagem, descreverei a Web Part incluída no Kit CASI para renderizar os dados do seu aplicativo WCF usando o controle personalizado e a página de layouts desenvolvidos nesta etapa.
Além disso, em anexo a esta postagem, você encontrará um arquivo zip com o projeto de exemplo do Visual Studio 2010 que criei e que inclui o assembly da classe base do Kit CASI, o meu controle personalizado que herda da classe base do Kit CASI, além da minha página de layouts personalizada.
Esta é uma postagem de blog traduzida. Consulte o artigo original The Claims, Azure and SharePoint Integration Toolkit Part 3