Arquivo da tag: Apps

Request Digest no SharePoint

Olá SharePointers,

Hoje vou falar um pouco sobre o RequestDigest. Para quem está acostumado a trabalhar com códigos client-side, com certeza já teve que usá-lo para criar itens ou outros objetos no SharePoint.

Toda vez que desejamos alterar algo no SharePoint, precisamos passá-lo no cabeçalho do request para que a operação seja concluída com sucesso. Para evitar ataques, o SharePoint gera um token específico para o usuário atual, site atual e por um tempo específico. Esse token é conhecido como Request Digest ou Form Digest.

Sendo assim, quando for executar uma chamada basta pegar o valor do RequestDigest e colocar no cabeçalho X-RequestDigest, como demonstrado abaixo:

image

Porém, se o usuário abrir a página e deixar aberta, sair do computador por um tempo e depois tentar clicar em algum botão, pode ser que o tempo de duração do token já tenha expirado. 

Para resolver esse problema, existe uma função Javascript que gera um token novo para você: UpdateFormDigest.

Para facilitar o entendimento, criei uma função que chamei de getRequestDigest que sempre me retorna o valor do token e, caso esteja vencido, ele renova o token e me retorna o valor atualizado.

image

e utilizo, onde precisar, essa função.

image

 

Abraços!

SharePoint Workflows–Acessando dados de um outro site

Olá SharePointers,

Hoje vou falar de uma dica muito útil: como acessar dados de um outro site, utilizando workflows. Nesse exemplo, acessarei uma lista do site pai.

O Workflow manager veio para simplificar a forma como os workflows são feitos. De forma declarativa, ficou bem mais simples.

Internamente,  a engine de workflows converte todas as ações em chamadas REST. Resumindo, tudo o que podemos fazer utilizando workflows, podemos fazer utilizando as APIs REST disponíveis.

Introdução

O Workflow roda como um add-in. Dessa forma, ao criar um workflow, ele é autorizado a executar naquele site. Mas, você pode dar permissões para o Add-in e rodar algumas ações em contexto app-only.

Para rodar o exemplo abaixo, é necessário ativar uma feature (de Web) no site que o workflow será criado:

image

Após isso, vá em Configurações do Site e clique  em Permissões de Aplicativo de Site

image

Copie o Id do aplicativo

image

Abra o outro site que deseja consultar informações e abra a página http://[site]/_layouts/15/appinv.aspx

Cole o Id do aplicativo e clique em pesquisa.

image

Cole o xml abaixo no último campo e clique em criar.

Atenção: O xml abaixo está dando permissão Manage em uma lista que você selecionará na próxima tela. Altere o xml conforme a sua necessidade de negócio.

<AppPermissionRequests AllowAppOnlyPolicy="true"> <AppPermissionRequest Scope="http://sharepoint/content/sitecollection/web/list" Right="Manage" /> </AppPermissionRequests>

Aparecerá uma tela para você confiar no Workflow e escolher a lista que deseja extrair informações.

image

 

Workflow

Crie o workflow e adicione um App Step.

image

Coloque uma ação Build Dictionary

Coloque duas entradas no Build Dictionary: Accept e Content-Type com o mesmo valor

image

e outra Call HTTP Web Service

image

Faça a sua chamada REST, clique nas propriedades da ação REST

image

e configure o RequestHeaders para ter o valor da variável que você criou no Build Dictionary

image

Pegue o valor da resposta e utilize-o conforme desejar.

image

 

Conclusão

Demonstrei como acessar dados, via REST, de outro site utilizando o workflow manager. Muitas vezes, por questões de organização e estruturação dos dados, precisamos acessar dados que não estão no site que estamos trabalhando e as APIs REST nos permitem isso de maneira bem simples. Entretanto, pode ser um pouco complicado fazer o passo-a-passo para fazer com que o mesmo processo funcione dentro do workflow.

 

Abraços Smile

Criar uma HighTrust SharePoint App

Olá SharePointers, 

Nesse post vou falar como criar um High-Trust SharePoint App.

Antes de mais nada, é importante entender o seguinte:

  • High-Trust não é igual a Full-Trust.
  • Esse tipo de App não pode ser instalado no SharePoint Online.
  • Esse tipo de App utiliza um Certificado para estabelecer a confiança entre o SharePoint e a Web Application do App.

 

Quando você cria um “Low Trust” App, o Azure ACS serve como servidor de Autorização. Mas, quando você está nesse modelo de HighTrust, o próprio App é o servidor de autorização.

 

Basicamente, o processo é o seguinte:

  1. O usuário acessa o SharePoint
  2. O servidor do SharePoint responde com a página, caso o usuário tenha acesso
  3. O Usuário clica no App.
  4. O App se comunica com o SharePoint para ver se um confia no outro.
  5. Caso exista a confiança entre eles, o App é autorizado a acessar o SharePoint
  6. A resposta da transação é apresentada para o usuário

 

Para visualizar o passo-a-passo, acessem o projeto no GitHub (onde o código-fonte está disponível): https://github.com/RARomano/HighTrustSharePointApps

 

Referências:

https://msdn.microsoft.com/en-us/library/office/fp179901.aspx

https://msdn.microsoft.com/en-us/library/office/jj945118.aspx

http://blogs.msdn.com/b/shariq/archive/2013/05/07/how-to-set-up-high-trust-apps-for-sharepoint-2013-amp-troubleshooting-tips.aspx

https://msdn.microsoft.com/en-us/library/office/dn790706.aspx

 

 

 

SharePoint 2013 Apps – Uma nova visão! Criando timer jobs utilizando apps

Olá SharePointers,

Desde que o SharePoint 2013 foi lançado e trouxe o seu novo conceito de APPs (impulsionado pelo Office 365) muito foi falado sobre o assunto.

Desde então fornecedores, profissionais e clientes têm travado uma “guerra” pensando se devem ou não utilizar esse modelo de desenvolvimento quando o assunto é ambiente OnPremises.

É comum, pelo menos aqui no Brasil, ainda mantermos o foco do desenvolvimento utilizando Farm Solutions. Mas, e quando o cliente não quer? Que opção nos resta?

A primeira opção que nos vem a cabeça é No-Code Sandbox Solutions. Faço tudo com Javascript e faço o deploy pelo Browser, não preciso de um administrador para essa tarefa e tudo resolvido.

Esse modelo é muito legal e interessante, ainda mais pelo fato de que a Microsoft está fazendo um esforço muito grande em liberar toda a API que temos disponível via Server Object Model para a versão client. Mas, ainda temos limitações. Por exemplo, fazer um impersonate, ou seja, fazer uma ação com um usuário que não seja o seu… Ou ainda, não criar um usuário apenas para “integração”, que você precisa fornecer tanto o login quanto a senha para acessar o ambiente… Como fazer?

Nesse caso, podemos utilizar Apps de um jeito que não tinhamos pensado antes.. Não apenas como SharePoint-Hosted Apps e Provider-Hosted Apps. Vou explicar:

Pense em um cenário que você precisa criar um “TimerJob”, mas não tem acesso ao ambiente. Como fazer?

Vou mostrar passo-a-passo como fazer isso de forma simples utilizando apps:

1- Criar um Console Application (Console Application? É isso mesmo?  Acreditem, isso mesmo!! 😀 )

1

2 – Clicar com o botão direito na Solution e ir em Manage Nuget Packages.

2

 

3 – Procure por SharePoint app e clique para instalar o pacote App for SharePoint Web Toolkit

3

 

4 – Abrir a URL “_layouts/AppRegNew.aspx” no seu SharePoint

4

Clicar no botão gerar do ID do Cliente e do Segredo do Cliente. Digitar o Título da App preencher um domínio para a APP (pode ser localhost) e uma URL de redirecionamento (pode ser a URL do seu SharePoint). Não iremos utilizar o domínio e a URL, mas são obrigatórios 😀

Quando clicar em Criar, o SharePoint mostrará na próxima tela os dados gerados.

IMPORTANTE: Anote o ID e o SEGREDO do Cliente gerados. Você precisará desses valores posteriormente.

5 – Adicionem os valores abaixo no arquivo app.config

 5

Lembrem de substituir o valor do ClientID e do ClientSecret com o que foi gerado na etapa anterior.

6 – Dar permissões ao App

Para dar permissões ao App, abra a URL “_layouts/AppInv.aspx”

6

Digite o ClientID (gerado na etapa anterior) e clique em pesquisar. Os campos serão preenchidos automaticamente.

No campo XML de Solicitação de Permissão do Aplicativo cole o XML abaixo:

<AppPermissionRequests AllowAppOnlyPolicy=”true”>

    <AppPermissionRequest Scope=”http://sharepoint/content/tenant” Right=”Manage” />

</AppPermissionRequests>

Com esse XML, você dará permissão em todo o Tenant para o App. Você pode alterar se precisar, mas para o nosso cenário, essa permissão está ok.

7 – Codificar

7

Agora é só codificarmos a nossa necessidade.

string siteUrl = “http://localhost”;

Uri uri = new Uri(siteUrl);

string realm = TokenHelper.GetRealmFromTargetUrl(uri);

// Pegar o access token

string accessToken = TokenHelper.GetAppOnlyAccessToken(

    TokenHelper.SharePointPrincipal,

    uri.Authority, realm).AccessToken;

// conectar no site com o contexto do APP

using (var ctx = TokenHelper.GetClientContextWithAccessToken(uri.ToString(), accessToken))

{

    /// codigo vai aqui

}

Agora é só agendar esse executável no agendador de tarefas do Windows e pronto. Para esse caso, criar um serviço do Windows é mais interessante, mas por funções educativas, utilizei o Console Application.

Fiz o upload da solution de testes, para quem quiser baixá-la e utilizar para testes em seu próprio ambiente: http://1drv.ms/1Hh8WIl

O que acharam?

SharePoint 2013 e seus modelos de desenvolvimento

Olá SharePointers,

Passando por alguns projetos recentes e após várias dúvidas comuns a profissionais do ramo, resolvi escrever um post sobre o assunto.

Com a introdução do SharePoint 2013, a Microsoft nos apresentou um recurso muito interessante: Apps for SharePoint. Durante todo o tempo em que esse conceito era apresentado para nós, era comum notarmos que a mensagem que era divulgada é “Apps é o futuro”.

Após esse período inicial, quando todos começaram a trabalhar com o produto, notamos uma grande resistência da comunidade em utilizá-lo. Para mais informações sobre como criar componentes reutilizáveis no SharePoint, veja: https://msdn.microsoft.com/en-us/library/office/jj163953(v=office.15).aspx.

Entretanto, nós profissionais, devemos filtrar a mensagem e entender o que está por trás disso tudo: Office 365. A Microsoft tem investido cada vez mais em sua plataforma de nuvem e é natural que ela concentre os seus esforços em sua “menina dos olhos”. Dessa forma, com os “famosos” apps, ela consegue resolver um problema crítico em um cenário de nuvem (com ambiente compartilhado entre os clientes): permitir que cada cliente possa customizar o seu espaço sem interferir nos demais e não ter um time para validar cada pacote, antes de ser colocado no ambiente SharePoint, para garantir que ele não contenha nenhuma operação potencialmente perigosa para o ambiente.

Com os apps não perdemos o nosso poder de customização e não dependemos de algum IT Pro para instalar, gerenciar os Change Requests no ambiente e potencialmente causar indisponibilidade no mesmo. Fantástico, não? 😀

Sendo assim, a Microsoft conseguiu criar um ambiente muito mais estável e gerenciável, permitindo entregar muita qualidade e evitando que um cliente degrade performance de outro. Combinação matadora para um ambiente de nuvem.

E quem não utiliza essa plataforma e ainda prefere/quer investir em sua plataforma on-premises?

Embora para alguns casos o modelo de Apps possa ser utilizado também, por exemplo em ambientes muito controlados onde customizações não são permitidas, esse modelo é super válido. Permite agregar valor para o usuário de forma rápida e, ainda em uma futura migração de versões do produto, é bem fácil migrar a solução.

Em um cenário onde você tem outras alternativas de desenvolvimento, como farm solutions, avaliá-las pode e deve fazer parte das atividades dos arquitetos de sistema. Escrevi um post uma vez comparando Farm Solutions com Apps (SharePoint 2013 : Farm Solution x Apps), ele aborda os detalhes técnicos com mais detalhes.

Mas, para um time que já investiu tempo (e dinheiro) criando uma série de framework e utilitários para farm solutions, não vale a pena investir esforço migrar para esse modelo novo (a não ser que tenha previsão de migrar para o Office 365 um dia). Além de termos muito mais controle com Farm Solutions, conseguimos evitar alguns comportamentos, na minha opinião, estranhos. Exemplo:

Utilizando REST APIs, ao referenciarmos um campo, devemos utilizar o Display Name do campo sem espaços; Se o campo tem o InternalName: NomePai e o Display Name: Nome do Pai, devo utilizar NomedoPai. Se o display name desse campo mudar, tem que alterar o código..

Não posso deixar de comentar que o investimento que a Microsoft está fazendo em APIs client é absurdo, buscando chegar no mesmo nível do Server Object Model. No mundo ideal, todas as APIs que temos disponíveis no lado do server estará disponível no Client. 🙂

A própria adição do “JSLink” (https://msdn.microsoft.com/en-us/magazine/dn745867.aspx) é sensacional.

Além disso, para uma farm on-prem suportar o modelo de Apps, é necessário realizar uma série de configurações adicionais no ambiente (inclusive no DNS – https://technet.microsoft.com/en-us/library/fp161236(v=office.15).aspx).

Autenticação não funcionará com Kerberos. É impossível lidar com tantas URLs diferentes que são geradas quando utilizamos Apps.

É muito rápido e fácil criar customizações server-side. Em pouco tempo estamos com uma solução pronta para utilização do usuário.

 

Para mim, sempre que possível, o modelo de desenvolvimento para ambientes on-prem é através de Farm Solutions.

 

Para ajudar na decisão de qual modelo escolher, recomendo a leitura desse link: https://msdn.microsoft.com/en-us/library/office/dn268593(v=office.15).aspx

Essa é uma discussão bem longa, gostaria de saber mais de vocês que utilizam o SharePoint no dia-a-dia. O que acham desse assunto? Qual modelo de desenvolvimento utilizam e porquê?

 

SharePoint Apps: Como utilizar o People Picker?

Olá SharePointers,

Hoje vou falar sobre como utilizar o People Picker quando estamos desenvolvendo uma app para SharePoint.

O primeiro passo, é carregar os scripts que serão utilizados (ver imagem abaixo) e colocar a div quer será utilizada para criação do controle dinamicamente.

image

 

Após a criação dos controles acima, basta colocar o código abaixo em um arquivo .js e adicioná-lo a página como referência que o People Picker funcionará perfeitamente.

 

// Run your custom code when the DOM is ready. $(document).ready(function () { // Specify the unique ID of the DOM element where the // picker will render. initializePeoplePicker('peoplePickerDiv'); }); // Render and initialize the client-side People Picker. function initializePeoplePicker(peoplePickerElementId) { // Create a schema to store picker properties, and set the properties. var schema = {}; schema['PrincipalAccountType'] = 'User,DL,SecGroup,SPGroup'; schema['SearchPrincipalSource'] = 15; schema['ResolvePrincipalSource'] = 15; schema['AllowMultipleValues'] = true; schema['MaximumEntitySuggestions'] = 50; schema['Width'] = '280px'; // Render and initialize the picker. // Pass the ID of the DOM element that contains the picker, an array of initial // PickerEntity objects to set the picker value, and a schema that defines // picker properties. this.SPClientPeoplePicker_InitStandaloneControlWrapper(peoplePickerElementId, null, schema); } // Query the picker for user information. function getUserInfo() { // Get the people picker object from the page. var peoplePicker = this.SPClientPeoplePicker.SPClientPeoplePickerDict.peoplePickerDiv_TopSpan; // Get information about all users. var users = peoplePicker.GetAllUserInfo(); var userInfo = ''; for (var i = 0; i < users.length; i++) { var user = users[i]; for (var userProperty in user) { userInfo += userProperty + ': ' + user[userProperty] + '<br>'; } } $('#resolvedUsers').html(userInfo); // Get user keys. var keys = peoplePicker.GetAllUserKeys(); $('#userKeys').html(keys); // Get the first user's ID by using the login name. getUserId(users[0].Key); } // Get the user ID. function getUserId(loginName) { var context = new SP.ClientContext.get_current(); this.user = context.get_web().ensureUser(loginName); context.load(this.user); context.executeQueryAsync( Function.createDelegate(null, ensureUserSuccess), Function.createDelegate(null, onFail) ); } function ensureUserSuccess() { $('#userId').html(this.user.get_id()); } function onFail(sender, args) { alert('Query failed. Error: ' + args.get_message()); }

Bem simples, não acharam?

 

Abraços! 😀

 

Referência

http://msdn.microsoft.com/en-us/library/jj713593.aspx

Troubleshooting SharePoint/Office365: Sideloading of apps is not enabled on this site

Olá SharePointers,
Estava desenvolvendo uma SharePoint Hosted app para o Office 365 e, para minha surpresa, apareceu o erro abaixo.
Esse erro acontecia quando quando tentava fazer o deploy via Visual Studio.

 

Para resolver esse erro, basta rodar o script que está disponível nesse link: http://1drv.ms/1qDs0oy

 

Referência:

http://blogs.msdn.com/b/officeapps/archive/2013/12/10/enable-app-sideloading-in-your-non-developer-site-collection.aspx

Abraços! 😀

SharePoint 2013: Licenciamento de uma App

Olá SharePointers,

Quando a versão nova do SharePoint 2013 foi lançada, muito se especulou sobre o modelo de licenciamento para Apps e como isso funcionaria, entreanto, após tanto tempo (estamos quase no SP1 do SharePoint 2013) pouco vejo falar sobre o assunto.

Em 2012, fiz uma apresentação para um evento no Senac São José dos Campos com vários profissionais renomados no mercado (http://pt.slideshare.net/rodrigoromano/mudanas-no-desenvolvimento-com-sharepoint-2013) e falei um pouco sobre o assunto.

Pensando na falta de conteúdo sobre o assunto, pensei em escrever um post.

 

Aquisição de Licenças

Ao comprar um App, a licença é enviada para o SharePoint em forma de um token. Esse token contém as informações básicas sobre a licença, tais como: data/hora da aquisição, quantas licenças foram adquiridas e etc.

Essas licenças podem ser por usuário ou por aplicativo.

 

image

OBS: O mais importante é entender que é necessário garantir a aplicação da licença via CÓDIGO customizado.

Sendo assim, o SharePoint fornece as APIs para buscar o Token de licenciamento na Store, validá-lo e tomar alguma ação no aplicativo baseado no resultado dessa validação. Dessa forma, o SharePoint provê uma funcionalidade extensível que atenda qualquer caso mais específico de uma App customizada.

 

image

 

 

 

Resumindo…

O SharePoint fornece toda a infraestrutura da App Store, permitindo a venda (gratuita ou paga) das Apps. Além disso, fornece o mecanismo para aquisição e gerenciamento das licenças, bem como WebService para validação de uma licença.

O único trabalho do desenvolvedor, nesse caso, é fazer a chamada ao Web Service, validar a licença obtida e tomar alguma ação baseada em seu resultado.

Simples, não?

SharePoint sempre pensando em nossa produtividade Smiley de boca aberta

 

Referências

(As imagens foram retiradas do link abaixo).

http://blogs.msdn.com/b/officeapps/archive/2012/11/09/licensing-your-apps-for-sharepoint.aspx

http://msdn.microsoft.com/en-us/library/office/jj163257.aspx

SharePoint 2013 : Farm Solution x Apps

Olá SharePointers,

Com a introdução da versão 2013 do SharePoint no mercado, vários conceitos novos foram adicionados à nossa lista de termos técnicos. Um deles é a nova forma de desenvolver soluções usando a plataforma SharePoint 2013: os Apps.

Vemos pessoas comentarem sobre o assunto, discutirem, sites falando diversas coisas sobre o assunto (inclusive o quanto o recurso é interessante, principalmente do ponto de vista de administradores do ambiente) mas ainda não tinha visto alguém falar quando efetivamente eu devo usar um ou outro.

Então, para ajudá-los a decidir qual das tecnologias utilizar, vamos analisá-las com mais detalhe:

 

1. Hosting

A primeira preocupação é decidir onde o meu código será executado. Se for Apps, o código nunca rodará no ambiente do SharePoint. Toda a comunicação será feita através de chamadas via WebServices, REST, etc.

Caso seja Farm Solutions, o código será executado no processo do IIS w3wp ou no do SandBox SPUCWorkerProccess.

Mas, na prática, o que isso influencia?

  • Nenhum código é instalado na farm, aumentando sua estabilidade e segurança
  • O deploy de uma Farm Solution depende de um administrador de TI, gerando períodos de “downtime” por ter que reiniciar o IIS, embora que com Sandbox solutions isso não acontecia.

Basicamente, no caso dos Apps, existem 3 tipos de hosting:

Provider-Hosted: Os apps que implementam esse tipo de arquitetura podem ter uma interface com o SharePoint, mas a maior parte de sua lógica está em outra tecnologia, como um servidor na nuvem. Utilizado para integrar sistemas legados com o SharePoint.

Auto-Hosted: Esse tipo é similar ao anterior (Provider-Hosted), mas a diferença é que o SharePoint (e Azure Alegre) faz o trabalho sujo de provisionar o site e o database necessário para o seu funcionamento.

SharePoint-Hosted: Esse tipo de App roda no SharePoint sem dependências externas, toda a sua lógica roda no contexto de um browser cliente. Sua lógica de negócios é implementada utilizando JavaScript, mas pode fazer deploys de Listas e Bibliotecas.

 

2. Escopos

Solutions

Soluções Full Trusted podem ser instaladas em qualquer escopo (Farm, Web App, Site Collection, Site).

Soluções Sandboxed somente em Site Collections.

Apps

Apps possuem 2 tipos de escopo:

  • Site: Mesmo escopo do site SharePoint
  • Tenancy: Nesse caso, é obrigatório a utilização do App Catalog.
      3. Integração
      Solutions
      As únicas opções disponíveis eram:  BCS ou WebServices, fazendo com que fosse uma experiência limitada no que diz respeito a integração com aplicações externas.
      Apps
      Como o desenvolvimento é feito através de técnicas bastante conhecidas de Web, é possível construir aplicações com quase nenhum conhecimento de SharePoint. Além disso, o Visual Studio 2012 contém os templates necessários para ajudar nessa tarefa.
      Como as aplicações baseiam-se em HTML e JavaScript, elas tornaram-se “Device Free”, podendo rodar em quase todos os dispositivos existentes.

       

       

      Conclusão

      Sempre que possível, considere a utilização de Apps ao invés de  utilizar o método “tradicional”. Além de compatibilidade extendida com dispositivos mobile e maior possibilidade de integrações, esse modelo ajuda todo um ecossistema de desenvolvedores de outras plataformas a conseguirem implantar/integrar suas aplicações com o SharePoint.

       

      Referências

      Apps for SharePoint compared with SharePoint solutions

      http://msdn.microsoft.com/en-us/library/jj164060.aspx#Factors

      http://msdn.microsoft.com/en-us/library/jj162979.aspx

      http://msdn.microsoft.com/en-us/library/office/fp179887.aspx

      http://blogs.msdn.com/b/uksharepoint/archive/2013/03/25/sharepoint-2013-development-apps-versus-solutions.aspx