Kit de integração de Declarações, Azure e SharePoint Parte 5
Kit de integração de Declarações, Azure e SharePoint Parte 5
Esta é a parte 5 de uma série de 5 partes sobre o Kit CASI (Integração de Declarações, Azure e SharePoint). A Parte 1 deu uma visão geral introdutória de toda a estrutura e solução e descreveu o que a série vai testar e abranger. A Parte 2 abordou as diretrizes de criação de aplicativos WCF e instruiu como torná-los orientados a declarações e como movê-los para o Windows Azure. A Parte 3 examinou a classe base a ser usada para interligar o site do SharePoint com os dados do Azure por meio da adição de um novo controle personalizado a uma página do diretório _layouts. A Parte 4 documentou a Web Part entregue com o Kit CASI e descreveu como usar, quais são suas respectivas propriedades etc. Nesta postagem final, vou examinar os dois outros cenários desse kit – usando o controle personalizado criado na Parte 3 para recuperar dados do Azure e armazená-los no cache ASP.NET para uso com outros controles, e usando-o em uma tarefa do SharePoint – nesse caso, um trabalho de timer personalizado do SharePoint.
Usando o controle em outras Web Parts
Um dos principais cenários que precisa de suporte implica o uso da estrutura Kit CASI para recuperar dados a serem usados em outras Web Parts do SharePoint. Permanece, porém, a outra meta de design, que é NÃO introduzir chamadas de rotina no lado do servidor para possíveis pontos de extremidade de WCF remotos. Para tentar e gerenciar essas duas necessidades divergentes, a classe base implementa suporte para recuperação de dados armazenando-os diretamente em um cache ASP.NET. Isso permite desenvolver outras Web Parts personalizadas e cumprir um padrão bem simples:
1. Verifique se os seus dados estão no cache ASP.NET.
a. Se assim for, recupere-os daí.
b. Caso contrário:
i. Crie uma instância do controle
ii. Defina OutputType como ServerCache e defina ServerCacheName e ServerCacheTime com os valores adequados.
iii. Chame o método ExecuteRequest e obtenha os dados
Para começar, inicie o Visual Studio Project – nesse caso, vou pressupor o Visual Studio 2010, portanto, poderemos criar um novo projeto do SharePoint 2010. Com o projeto configurado para criar uma nova Web Part, adicione duas referências – uma para a classe base CASI Kit e outra para o controle personalizado criado na Parte 3. Observe que, se você não adicionar uma referência à classe base CASI Kit, quando tentar e definir qualquer uma das propriedades do seu controle, o Visual Studio o realçará com um rabiscado vermelho e dirá a você que não é possível localizar a propriedade. Se receber esse tipo de erro, você saberá que ainda não adicionou a referência à classe base CASI Kit.
Depois de definidas as referências, será possível escrever qualquer código apropriado à Web Part. Quando você chega ao ponto em que é necessário obter dados do Azure – conteúdo, informações de configuração etc.– aqui está um exemplo de como o padrão descrito acima foi implementado:
string CACHE_NAME = "AzureConfigConsumerCacheSample";
int CACHE_TIME = 10;
//criar uma variável do tipo de dados de configuração a serem recuperados
AzureWcfPage.CustomersWCF.Customer[] Customers = null;
//procurar nosso item no cache
if (HttpContext.Current.Cache[CACHE_NAME] != null)
{
//se encontrarmos, processá-lo para o nosso tipo e extraí-lo do cache
Customers =
(AzureWcfPage.CustomersWCF.Customer[])
HttpContext.Current.Cache[CACHE_NAME];
}
else
{
//se não estiver no cache, recuperá-lo e colocá-lo no cache
//criar uma instância do controle
AzureWcfPage.WcfDataControl cfgCtrl = new AzureWcfPage.WcfDataControl();
//definir as propriedades para recuperar dados
cfgCtrl.WcfUrl = "https://azurewcf.vbtoys.com/Customers.svc";
cfgCtrl.OutputType = AzureConnect.WcfConfig.DataOutputType.ServerCache;
cfgCtrl.ServerCacheName = CACHE_NAME;
cfgCtrl.ServerCacheTime = CACHE_TIME;
cfgCtrl.MethodName = "GetAllCustomers";
//executar o método
bool success = cfgCtrl.ExecuteRequest();
if (success)
{
//obter a versão bem definida de nossos dados
//o tipo de dados precisa vir do controle que estamos criando
Customers =
(AzureWcfPage.CustomersWCF.Customer[])cfgCtrl.QueryResultsObject;
//se o desejado for a representação XML do objeto que você quer obter
//de QueryResultsString
string stringCustomers = cfgCtrl.QueryResultsString;
}
else
{
//ocorreu algum problema; conecte o tratamento de erro aqui
}
}
Vamos analisar um pouco do código em mais detalhes. Primeiro, é importante entender que, na sua Web Part, você NÃO precisa adicionar uma referência de serviço ao ponto de extremidade do WCF. Tudo isso fica encapsulado no controle personalizado, portanto, é possível usar os tipos de retorno do aplicativo WCF que foram expostos via controle personalizado. Essa linha de código demonstra:
//criar uma variável do tipo de dados de configuração a serem recuperados
AzureWcfPage.CustomersWCF.Customer[] Customers = null;
Nesse exemplo, AzureWcfPage era meu assembly de controle personalizado. CustomersWCF era o nome que dei à minha referência de serviço WCF. E Customer é o tipo de classe retornado pelo meu método WCF. Tudo isso flui para minha nova Web Part quando adiciono minha referência ao assembly de controle de personalizado.
A primeira verificação que faço é ver se meus dados estão no cache; se estiverem, simplesmente os processo na matriz de instâncias do cliente que armazenei anteriormente. Se não estiverem no cache, escrevo as sete linhas de código necessárias para criar uma instância do meu controle personalizado e recupero os dados. É preciso:
a. Criar uma nova instância do controle
b. Definir as propriedades WcfUrl, MethodName, OutputType, ServerCacheName e ServerCacheTime
c. Chamar o método ExecuteRequest
E é isso. Se o método for concluído com êxito, o valor de retorno do aplicativo WCF será armazenado no cache ASP.NET e, dessa forma, na próxima vez que o código for executado, ele localizará o item lá. Enquanto isso, posso processar minha variável local Customers na propriedade QueryResultsObject do controle personalizado e, então, posso fazer com os dados o que for necessário para minha Web Part. No geral, isso deve ser relativamente fácil e direto de implementar para a maioria dos desenvolvedores de Web Part.
Usando o controle em uma tarefa
Agora, descreverei como usar o controle personalizado desenvolvido na Parte 3 para recuperar conteúdo e/ou dados de configuração do Azure, os quais serão usados em uma tarefa. Neste exemplo, escrevi um trabalho de timer personalizado do SharePoint e, nele, vou recuperar alguns dados do Azure. O padrão é bem similar à Web Part descrita acima, mas, neste caso, assim como em muitas tarefas, você não precisa de um HttpContext, portanto, o cache ASP.NET não será usado. Nesse caso, o OutputType será None, porque não é preciso renderizá-lo em uma página nem é preciso armazená-lo no cache; em vez disso, vamos apenas extrair o diretório de valor do QueryResultsObject e/ou do QueryResultsString. Aqui está um exemplo de código para isso – é um código originado na substituição do método Execute na minha classe personalizada de trabalho de timer:
SPWebApplication wa = (SPWebApplication)this.Parent;
//criar uma instância do controle
AzureWcfPage.WcfDataControl cfgCtrl = new AzureWcfPage.WcfDataControl();
//definir as propriedades para recuperar dados
cfgCtrl.WcfUrl = "https://azurewcf.vbtoys.com/Customers.svc";
cfgCtrl.OutputType = AzureConnect.WcfConfig.DataOutputType.None;
cfgCtrl.MethodName = "GetAllCustomers";
//como não há nenhum contexto Http em uma tarefa do tipo trabalho de timer, também é preciso
//fornecer a URL para um site do SharePoint habilitado para declarações. Esse endereço será utilizado
//para conectar o ponto de extremidade STS com o farm do SharePoint
cfgCtrl.SharePointClaimsSiteUrl = wa.Sites[0].RootWeb.Url;
//executar o método
bool success = cfgCtrl.ExecuteRequest();
//verificar se houve êxito
if (success)
{
//agora, recuperar os dados e fazer o que for preciso com eles
AzureWcfPage.CustomersWCF.Customer[] Customers =
(AzureWcfPage.CustomersWCF.Customer[])cfgCtrl.QueryResultsObject;
string AzureResults = cfgCtrl.QueryResultsString;
//este é o local para execução das tarefas baseadas nos dados obtidos do Azure
foreach(AzureWcfPage.CustomersWCF.Customer c in Customers)
{
Debug.WriteLine(c.Email);
}
Debug.WriteLine(AzureResults);
}
else
{
//fazer algo para registrar o fato de que os dados não foram recuperados
}
Aqui está mais alguma explicação sobre esse código. O trabalho de timer tem escopo de aplicativo Web, assim, começo obtendo uma referência ao SPWebApplication para o qual esse trabalho está sendo executado por referência à propriedade Parent. Em seguida, crio o controle personalizado criado na Parte 3 e defino o mínimo necessário de propriedades para recuperar dados do Azure. Na próxima linha de código, é preciso definir a propriedade SharePointClaimsSiteUrl. Como expliquei na Parte 3, quando a classe base CASI Kit é executada por meio do método ExecuteRequest, ela verifica se há um HttpContext disponível. Se fizer isso, ela realmente usará esse contexto para detectar a URL atual do site do SharePoint e fará a conexão com o STS do SharePoint usando esse site. No entanto, como descrevi acima, quando o código está em execução em uma tarefa, você geralmente não precisa do HttpContext. Nesse caso, a classe base não pode determinar a URL a ser usada para conectar o STS do SharePoint e, sendo assim, é preciso fornecer a URL para um site em um aplicativo Web habilitado para declarações. O código de trabalho de timer, nessa implementação, pressupõe que ele SOMENTE será executado em aplicativos Web habilitados para declarações, portanto, esse é o motivo por que obtenho a referência ao aplicativo Web atual e então simplesmente passo isso à URL no primeiro conjunto de sites. Não importa realmente qual conjunto de sites é utilizado, desde que ele seja um aplicativo Web habilitado para declarações.
Depois que defino a propriedade SharePointClaimsSiteUrl, posso chamar o método ExecuteRequest, conforme demonstrado anteriormente. Se houver êxito na execução, poderei extrair meus dados do controle, diretamente por meio das propriedades QueryResultsObject e/ou QueryResultsString.
Os dois projetos de Web Part e trabalho de timer foram incluídos no arquivo compactado, anexado a esta postagem.
E isso finaliza o tema
Esta é a postagem final da série. Espero que, agora, você tenha um bom entendimento do CASI Kit e de como pode usá-lo para conectar-se com bastante facilidade aos dados hospedados em um aplicativo WCF, no site ou na nuvem, podendo inclusive usar o token de identidade do usuário em aplicativos e mesmo em limites de data centers. Em resumo, o padrão é relativamente fácil de implementar:
1. Crie um front-end WCF para conteúdo e/ou dados de configuração. Habilite-o para declarações e, opcionalmente, mova-o na nuvem. Opcionalmente, implemente decisões de permissão refinada com base em chamadas de identidade de usuário e em declarações.
2. Escreva um controle personalizado que seja herdado da classe base CASI Kit. Substitua um método e escreva cinco linhas de código. Adicione o controle à página simples de layouts e implante.
3. Adicione a Web Part a uma página, defina uma ou mais propriedades e inicie a renderização dos dados do WCF. Opcionalmente, use o controle para recuperar conteúdo ou dados de configuração em uma Web Part personalizada ou em uma tarefa; por exemplo, em um trabalho personalizado de timer.
É basicamente isso. Espero que o CASI Kit resolva muitas dificuldades e mistérios relacionados à conexão do farm do SharePoint com dados armazenados em qualquer parte do mundo. Isso também funcionará com bastante êxito na recuperação de dados de configuração ou personalização e do próprio conteúdo, para exibição em sites do SharePoint. E, agora, você tem a flexibilidade de usar a segurança implementada na sua organização em aplicativos e limites de data centers. Foi muito gratificante imaginar, projetar e desenvolver isso e espero que você considere útil o que descobri. Como sempre, esta é a versão v1 e tenho certeza de que surgirão muitos aspectos que poderemos trabalhar melhor, portanto, fique à vontade para acrescentar comentários ao longo dessas postagens. Periodicamente, eu vou analisá-las como fonte de inspiração para a próxima edição.
Esta é uma postagem de blog traduzida. O artigo original está em The Claims, Azure and SharePoint Integration Toolkit Part 5