Integrando o SQL Azure ao SharePoint 2010 e ao Windows Azure
Integrando o SQL Azure ao SharePoint 2010 e ao Windows Azure
Esta postagem é mais útil quando usada como complemento da minha série de cinco partes sobre o Kit CASI (Integração de Declarações, Azure e SharePoint).
· Parte 1: uma visão geral introdutória de toda a estrutura e solução e descreveu o que a série vai testar e abranger.
· Parte 2: a parte de orientação do Kit CASI. Ela começa com a transformação do WCF no front-end de todos os dados – podendo ser conjuntos de dados, XML, classes personalizadas ou HTML direto. Na fase 1, pegamos o serviço WCF padrão e o orientamos a declarações – que é o que nos permite obter o token de usuário do SharePoint e enviá-lo pelos aplicativos ou limites de data centers para os aplicativos WCF personalizados. Na fase 2, vamos examinar a lista de todos os aspectos necessário para obter esse aplicativo WCF do local e hospedá-lo no Windows Azure. Depois de fazer isso, você terá o back-end instalado para oferecer suporte a vários aplicativos e data centers com autenticação integrada.
· Parte 3: descreve o assembly do kit de ferramentas personalizado que oferece a aderência necessária para conectar seu aplicativo WCF com reconhecimento de declaração na nuvem e seu farm do SharePoint. Explicarei o uso do assembly e falarei sobre o controle muito fácil e personalizado que você precisará criar (aproximadamente, 5 linhas de código), e abordarei como é possível hospedá-lo em uma página do diretório _layouts, como um meio de recuperar e renderizar dados em Web Parts. O código-fonte completo do exemplo de controle personalizado e a página _layouts também serão postados.
· Parte 4: a Web Part que estou incluindo com o Kit CASI. Isso fornece uma solução pronta para uso e sem código, para você interligar e conectar com uma consulta assíncrona do cliente, com o objetivo de recuperar dados do serviço hospedado em nuvem e então exibir na Web Part. Também há interligações internas, para que você possa personalizar bastante e usar suas próprias funções JavaScript para renderizar os dados.
· Parte 5: um breve passo a passo de alguns aplicativos de exemplo que demonstram outros cenários para a utilização do controle personalizado que você criará e que foi descrito na Parte 3 em alguns outros cenários comuns. Um cenário usará o controle para recuperar alguns tipos de dados de usuário ou de configuração e armazená-lo no cache ASP.NET, usando-o, depois, em uma Web Part personalizada. O outro cenário usará o controle personalizado para recuperar dados do Azure e usá-los em uma tarefa comum, neste caso, um trabalho de timer personalizado do SharePoint. O código-fonte completo desses exemplos de aplicativos também serão postados.
Com o Kit CASI, ofereço uma certa orientação e algumas ferramentas para ajudá-lo a se conectar com bastante facilidade e rapidez ao Windows Azure do SharePoint 2010 ao mesmo tempo em que você envia o token para o usuário atual, o que lhe permite tomar decisões de segurança muito granulares. O aplicativo WCF original que era consumido pelo Kit CASI utilizava apenas um conjunto codificado dos dados que eram expostos. Em uma compilação subsequente (e, na verdade, não documentada nas postagens do Kit CASI), atualizei a parte de dados para que ela armazenasse e recuperasse dados usando o repositório de tabelas do Windows Azure. Agora, eu o aprimorei um pouco mais criando os dados no SQL Azure e fazendo com que o meu WCF no Windows Azure recupere dados dali. Agora, ele é realmente um pacote de aplicativos de várias nuvens: Windows Azure, SQL Azure e (ostensivamente) SharePoint Online. O foco desta postagem é, na verdade, simplesmente compartilhar algumas dicas sobre o trabalho com o SQL Azure para que você possa incorporá-lo com mais rapidez aos seus projetos de desenvolvimento.
Dicas de integração
1. Você realmente deve atualizar para o SQL 2008 R2 para poder abrir bancos de dados do SQL Azure com a ferramenta SQL Server Management Studio. Tecnicamente, é possível fazer com que o SQL Server 2008 funcione, mas, para que isso aconteça, é necessário passar por uma série de etapas com soluções alternativas. O 2008 R2 já tem isso pronto, e você terá a melhor experiência com ele. Se você realmente quiser trilhar a rota de soluções alternativas do 2008, dê uma olhada neste link: https://social.technet.microsoft.com/wiki/contents/articles/developing-and-deploying-with-sql-azure.aspx. Existem algumas dicas realmente boas neste artigo e, portanto, vale a pena lê-lo de qualquer forma
2. Planeje o uso do T-SQL para tudo. As ferramentas gráficas não estão disponíveis para o trabalho com bancos de dados, tabelas, procedimentos armazenados etc. do SQL Azure. Novamente, algo que achei útil, como não sou especialista em T-SQL, é simplesmente criar primeiro um banco de dados do SQL Server local. Na ferramenta Gerenciamento do SQL, crio duas conexões – uma para a minha instância local do SQL e uma para a minha instância do SQL Azure. Crio tabelas, procedimentos armazenados etc. na instância SQL local para poder usar as ferramentas gráficas. Em seguida, uso o Script [qualquer objeto Sql] As…CREATE to…New Sql Query Window. Isso gera o script SQL para criar meus objetos e então posso colá-lo em uma janela de consulta que abri para o meu banco de dados do SQL Azure.
3. Isto é importante, pessoal – o tempo limite padrão com frequência não é longo o suficiente para conectar ao SQL Azure. É possível alterá-lo usando as classes SqlClient do .NET na cadeia de conexão, isto é, adicione "Connection Timeout=30;". Se você estiver usando o SQL Server Management Studio, clique no botão Avançado na caixa de diálogo onde o nome do servidor e as credenciais são inseridos e altere-o para pelo menos 30. O padrão é de 15 segundos e costuma falhar com frequência, mas 30 segundos parece funcionar bastante bem. Infelizmente, não há uma maneira de alterar o tempo limite de conexão para um tipo de conteúdo externo (isto é, definição de aplicativo BDC) para uma origem de dados SQL Azure.
4. Não use a conta de administrador do banco de dados para a conexão a seus bancos de dados (isto é, a conta obtida para criar o banco de dados propriamente dito). Crie uma conta separada para o trabalho com dados. Infelizmente, o SQL Azure só oferece suporte a contas SQL e, portanto, você não poderá usar diretamente a identidade do usuário solicitante para tomar decisões sobre o acesso aos dados. Você pode contornar isso usando um aplicativo WCF que faça o front-end dos dados no SQL Azure e usando a autenticação de declarações no Windows Azure, o que é exatamente o modelo usado pelo Kit CASI. Além disso, ele precisa de algumas etapas para criar um logon que possa ser usado para conectar um banco de dados específico aos dados. Veja um exemplo:
--crie o banco de dados primeiro
CREATE DATABASE Customers
--agora, crie o logon e um usuário no banco de dados a partir do logon
CREATE LOGIN CustomerReader WITH PASSWORD = 'FooBarFoo'
CREATE USER CustomerReader FROM LOGIN CustomerReader
--agora, conceda direitos ao usuário
GRANT INSERT, UPDATE, SELECT ON dbo.StoreInformation TO CustomerReader
--conceda direitos EXECUTE a um procedimento armazenado
GRANT EXECUTE ON myStoredProc TO CustomerReader
Para obter mais exemplos e detalhes, incluindo a definição de direitos no nível do servidor para contas no SQL Azure, consulte https://msdn.microsoft.com/en-us/library/ee336235.aspx.
5. Você deve criar regras de firewall no SQL Azure para cada banco de dados que deseja criar para permitir comunicações de clientes diferentes. Se quiser permitir a comunicação de outros serviços Azure, você deverá criar a regra de firewall do MicrosoftServices (o que o SQL Azure se oferece para fazer por você quando o banco de dados é criado pela primeira vez), que é um intervalo inicial de 0.0.0.0 a 0.0.0.0. Se você não criar essa regra, nenhum dos seus aplicativos do Windows Azure poderá ler, adicionar ou editar dados de seus bancos de dados do SQL Azure! Você também deve criar uma regra de firewall para permitir comunicações com qualquer servidor usado para roteamento na Internet. Por exemplo, se você tiver um roteador a cabo ou DSL ou um servidor RRAS, talvez prefira usar seu endereço externo ou um endereço NAT para algo como RRAS.
Estas são dicas provavelmente muito boas para fazer com que seus dados fiquem prontos para serem usados.
Acesso aos dados
O acesso aos dados a partir do seu código personalizado – Windows Azure WCF, Web Part etc. – felizmente é muito parecido com a recuperação de dados de um SQL Server local. Veja um exemplo de código rápido, e depois apresentarei uma sequência passo a passo um pouco mais detalhada de algumas partes desse código:
//define um tempo limite maior porque 15 segundos quase sempre não são
//suficientes; a documentação do SQL Azure recomenda 30
private string conStr = "server=tcp:foodaddy.database.windows.net;Database=Customers;" +
"user ID=CustomerReader;Password=FooBarFoo;Trusted_Connection=False;Encrypt=True;" +
"Connection Timeout=30";
private string queryString = "select * from StoreInformation";
private DataSet ds = new DataSet();
using (SqlConnection cn = new SqlConnection(conStr))
{
SqlDataAdapter da = new SqlDataAdapter();
da.SelectCommand = new SqlCommand(queryString, cn);
da.Fill(ds);
//faça algo com os dados
}
Na verdade, não há nada que precise de muitas explicações, a não ser a cadeia de conexão. Os principais pontos que valem apontar e que possivelmente são diferentes de uma conexão típica com um SQL Server local são:
· server: precede o nome do banco de dados do SQL Azure com “tcp:”.
· Trusted_Connection: deve ser falso, uma vez que você não está usando segurança integrada
· Encrypt: deve ser verdadeiro para qualquer conexão feita com um banco de dados hospedado em nuvem
· Connection Timeout: conforme descrito acima, o tempo limite padrão é de 15 segundos e com frequência isso não é o suficiente; em vez disso, eu o defini como 30 segundos aqui.
Outro cenário que gostaria de mencionar brevemente aqui é o uso da migração de dados. Você pode usar a ferramenta BCP que vem com o SQL Server para mover dados de um SQL Server local para o SQL Azure. A rotina básica para a migração de dados é assim:
1. Criar um arquivo de formato – usado para a exportação de dados locais e para importá-los para a nuvem. Neste exemplo, estou criando um arquivo de formato para a tabela Region no banco de dados Test e salvando-o no arquivo region.fmt.
bcp Test.dbo.Region format nul -T -n -f region.fmt
2. Exportar dados do SQL local – neste exemplo, estou exportando da tabela Region do banco de dados Test para um arquivo chamado RegionData.dat. Estou usando o arquivo de formato region.fmt criado na etapa 1.
bcp Test.dbo.Region OUT RegionData.dat -T -f region.fmt
3. Importe dados para o SQL Azure. O mais importante a ser observado aqui é que, quando estiver importando dados para a nuvem, você DEVE incluir “@nomedoServidor” com o parâmetro do nome do usuário. A importação falhará sem ele. Neste exemplo, estou importando dados para a tabela Region do banco de dados Customers no SQL Azure. Estou importando do arquivo RegionData.dat para o qual exportei meus dados locais. O nome do meu servidor (o parâmetro -S) é o nome do banco de dados do SQL Azure. Para meu nome de usuário (o parâmetro -U), estou usando o formato nomedousuário@nomedoservidor como descrevi anteriormente. Estou dizendo para ele usar o arquivo de formato region.fmt criado na etapa 1 e defini um tamanho de lote (o parâmetro -b) de 1000 registros por vez.
bcp Customers.dbo.Region IN RegionData.dat -S foodaddy.database.windows.net -U speschka@foodaddy.database.windows.net -P FooBarFoo -f region.fmt -b 1000
Isto é tudo neste artigo, pessoal. Espero que o que foi descrito aqui ofereça um bom entendimento sobre a mecânica básica da criação de um banco de dados do SQL Azure e sobre a conexão com ele e sua utilização no seu site do SharePoint. Como observação extra, usei o Kit CASI para recuperar esses dados por meio do meu front-end WCF do Windows Azure para o SQL Azure e o renderizei no meu site do SharePoint. Segui meu próprio blog do Kit CASI ao criá-lo para experimentar e validar tudo o que publiquei anteriormente e, em geral, achei-o bastante preciso. Houve algumas pequenas correções que fiz na parte 3, junto com uma seção adicional rápida sobre a solução de problemas que adicionei. Mas, em geral, levei 30 minutos para criar um novo controle personalizado e talvez 15 minutos para criar uma nova Web Part Visual. Use a Web Part do Kit CASI para exibir um conjunto de dados do SQL Azure a partir do WCF e, na Web Part Visual, criei programaticamente uma instância do controle personalizado para recuperar um conjunto de dados, Em seguida, o associei a uma grade ASP.NET. Juntei tudo em uma página de exemplo que, na verdade, tem uma ótima aparência e que pôde ser estendida para exibir dados de algumas formas diferentes de uma maneira bem fácil. Veja a sua aparência:
Esta é uma postagem de blog traduzida. Consulte o artigo original Integrating SQL Azure with SharePoint 2010 and Windows Azure