Arquivo da categoria: Apps

SharePoint Framework – Quick Samples

Olá SharePointers,

Criei um repositório no Github onde colocarei alguns exemplos rápidos, mas que podem ajudar bastante no nosso dia-a-dia.

O link do repositório é: https://github.com/RARomano/SharePointFramework-Samples – Se gostarem, cliquem no ícone Star no Github 😀

O primeiro exemplo, mostra como carregar CSS de um CDN, o que acredito que será muito útil para todo mundo.

Para quem quiser o Link direto dessa dica é esse aqui: https://github.com/RARomano/SharePointFramework-Samples/tree/master/AddCustomStyles

 

Grande Abraço!

SharePoint Framework – Overview

Olá SharePointers,

O SharePoint framework, atualmente em General Availability (https://github.com/SharePoint/sp-dev-docs/wiki/Release-Notes-GA), está pronto para utilizado e precisamos ter algumas coisas em mente:

Contexto de execução

Diferentemente do que acontece com os Add-ins, as webparts criadas utilizando esse framework rodam no contexto da página. Ou seja, não roda dentro de um iFrame.

Isso é muito importante!

Quando instalávamos um add-in, um site isolado era provisionado e a sua aplicação residia lá. No SharePoint Online por exemplo, a URL era: https://[tenant]-[id].SharePoint.com.

Mesmo quando você utilizava uma App Part para colocar o seu App dentro do contexto do seu site principal, internamente isso acontecia dentro de um iFrame e, com isso, a aplicação não conseguiria fazer mal ao seu site principal. (Lembre-se que ao instalar o Add-in, você precisa aceitar as permissões que são solicitadas).

Em uma Webpart do SharePoint Framework, por outro lado, roda diretamente no site, no DOM da página e com as permissões do usuário atual. Apenas para deixar claro, tudo o que o usuário logado tiver permissões para fazer, o código também terá permissões para fazer.

Utilização de Bibliotecas de Terceiros

É muito comum utilizarmos bibliotecas de terceiros em nossas aplicações. E, as vezes, utilizamos essas bibliotecas diretamente de CDNs.

Como eu disse no tópico anterior, como essas WebParts rodam diretamente no contexto do usuário, é preciso ter um critério muito grande em relação aos scripts que for utilizar, caso sejam maliciosos, eles podem causar problemas – fica aí um ponto de atenção para os administradores do portal.

Framework de Desenvolvimento

Uma coisa muito interessante desse modelo é que você tem a liberdade de trabalhar da forma como achar melhor.

Você pode utilizar Angular, React, Knockout, Handlebars ou seja lá o que for mais confortável para você. Isso é um grande passo da Microsoft, nos dá liberdade como desenvolvedores e permite trabalharmos da forma como nosso time estiver mais confortável.

 

E aí pessoal, compartilhem suas experiências com o esse novo framework. Estão utilizando?

Abraços! 😀

Registrando um Add-in e concedendo permissões utilizando PowerShell

Olá SharePointers,

Muitas vezes é necessário criarmos Add-ins no SharePoint. Entretanto, nem sempre é possível utilizar o modelo SharePoint-hosted.

Para facilitar o processo, podemos utilizar um script powershell para criar um Client ID e fazer o deploy do .app.

$targetWeb = “https://site.sharepoint.com”
$appDisplayName = “App”
$clientID = [Guid]::NewGuid().ToString()

$authRealm = Get-SPAuthenticationRealm -ServiceContext $targetWeb
$AppIdentifier = $clientID + “@” + $authRealm

Write-Host “Creating the new app principal registration…”
Register-SPAppPrincipal -NameIdentifier $AppIdentifier -Site $targetWeb -DisplayName $appDisplayName
$appPrincipal = Get-SPAppPrincipal -Site $targetWeb -NameIdentifier $AppIdentifier

write-host “Display Name:” $appPrincipal.DisplayName
write-host “Name Identifier:” $appPrincipal.NameIdentifier
write-host “ClientID:” $clientID

Write-Host “Uploading the app…”
$spapp = Import-SPAppPackage -Path D:\MyApp.app -Site $targetWeb –Source ObjectModel
$instance = Install-SPApp -Web $targetWeb -Identity $spapp
Write-Host “Granting permissions…”
$web = Get-SPWeb $targetWeb

Set-SPAppPrincipalPermission -Site $web -AppPrincipal $appPrincipal -Scope SiteCollection -Right FullControl

$web.Dispose()

Esse script substitui aquelas operações que temos que fazer nas páginas [SiteUrl]/_layouts/AppRegNew.aspx e [SiteUrl]/_layouts/AppInv.aspx.

 

Esse script funciona tanto para SharePoint On-Premises quanto para SharePoint Online.

 

Referências

http://www.manasbhardwaj.net/powershell-alternative-sharepoint-2013-appregnew-aspx/

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

Aumentando a produtividade com SharePoint Add-ins – Parte 2 (A beleza do Upgrade)

Olá SharePointers,

Fiz um novo post falando de como aumentar a produtividade do desenvolvimento utilizando Add-Ins e publiquei o documento no DOCS.com da Microsoft.

O link para o documento é: https://doc.co/GGzdmo

O projeto está publicado no GitHub.. O link do repositório é: https://github.com/RARomano/SharePointHostedUpdateApp

 

Abraços!

Aumentando a produtividade com SharePoint Add-Ins – Parte 1

Olá SharePointers,

Para quem tem acompanhado os direcionamentos que a Microsoft vem apresentando para modelo de desenvolvimento do SharePoint, principalmente quando o assunto é o SharePoint Online, percebe que o direcionamento é muito forte para os chamados “Add-Ins“.

Já fiz um post falando dos modelos de desenvolvimento disponíveis no SharePoint (http://rodrigoromano.net/2015/01/27/sharepoint-2013-e-seus-modelos-de-desenvolvimento/ e dos “novos” modelos de provisionamento de objetos http://rodrigoromano.net/2015/07/04/modelo-de-provisionamento-de-objetos-no-sharepoint/), mas o foco desse post é falar sobre como tirar proveito dessa nova orientação e criar soluções de negócios que de fato agreguem valor ao negócio do cliente.

Para (re)lembrar: Quando falamos de add-ins (antigamente conhecido como Apps), eles podem ser: SharePoint-hosted ou Provider-hosted.

Muitos desenvolvedores podem falar/pensar assim “Mas eu já tinha um framework que acelerava o meu desenvolvimento utilizando Farm Solutions e agora preciso alterar toda a arquitetura para esse modelo novo?” e a resposta é:

SIM, mas podemos fazer isso utilizando algumas vantagens que esse modelo de add-ins nos apresenta e compensar esse trabalho que teremos (somente na primeira vez).

Pensando nisso, farei alguns posts explicando em como tirar proveito do modelo de add-ins.

 

Contexto

A Microsoft fez vários anúncios recentes que demonstram que a visão dela está mudando, ou melhor, está mudada. Vimos que o código do .NET virou open-source (código disponível no github: https://github.com/dotnet), vimos a apresentação da hololens, do continuum e uma série de novidades que deixaram todos boquiabertos (falei um pouco desse posicionamento nesse post: http://rodrigoromano.net/2015/05/24/novo-posicionamento-da-microsoft-e-projeto-oxford/).

Com tudo isso, podemos notar que a estratégia é simples: permitir a interoperabilidade, ou seja, qualquer plataforma/linguagem poder interagir com recursos Microsoft.

SharePoint-Hosted Add-ins

Quando o assunto é SharePoint-Hosted add-ins, a primeira coisa que vem a nossa cabeça é que nesse modelo não podemos colocar código server-side. Há algum tempo atrás isso era um paradigma, mas acredito que isso já tenha mudado um pouco.. 

Em contrapartida, por só permitir código JavaScript, HTML e CSS, esse modelo nos permite (ou força) a abrirmos os olhos para o movimento do mercado. Para quem trabalha com aplicações front-end, JavaScript é uma ferramenta de trabalho diário. Para facilitar a vida dos desenvolvedores front-end, várias bibliotecas (ou “mini-frameworks”) foram criados e (são criados a todo momento!). É muito provável que enquanto estou escrevendo esse post, tenha alguma biblioteca nova sendo criada 😉

Uma dessas bibliotecas é o Knockout JS.

O Knockout JS é uma biblioteca que facilita (e muito) a vida de um desenvolvedor front-end. Com essa biblioteca, você pode colocar tags no seu código HTML para fazer o “BIND” automático entre um objeto do DOM e uma variável e, dessa forma, quando esse campo for alterado, a variável seja atualizada automaticamente (ou vice-versa). Recomendo a leitura da documentação: http://knockoutjs.com/documentation/introduction.html

Utilizando essa biblioteca, fiz um exemplo (não levou mais de 1 hora para fazer) que demonstra como utilizar o Knockout JS, REST APIs e SharePoint JSOM (JavaScript Object Model) para construir uma App pode ser bem simples e disponibilizei no GitHub: https://github.com/RARomano/KnockoutJSandSharePointHostedApp.

 

Próximos Passos

O meu próximo post apresentará como fazer o upgrade de SharePoint-Hosted add-ins e ver como os recursos que a Microsoft disponibiliza pode ajudar a salvar muito tempo e sermos mais produtivos.

 

Abraços! 😀

 

Protegendo Web API utilizando Azure AD e integrando com SharePoint Online usando oAuth

Olá SharePointers,

Hoje vou falar de um cenário Híbrido envolvendo SharePoint Online e Azure.

É comum para nós, especialistas no produto, encontrarmos cada vez mais cenários híbridos e integrados. 

 

Cenário

Tenho uma aplicação desenvolvida em alguma linguagem que está fazendo Single Sign On com o Azure AD utilizando oAuth e OpenID. Basicamente, quando um usuário se loga na aplicação, a aplicação vai até o Azure e solicita um token de acesso para esse recurso. 

Com esse token, preciso conseguir acessar uma Web API que está hospedada no Azure. Essa WebAPI não permite acesso anônimo. Para acessar essa API, eu devo utilizar o token de acesso recebido na etapa anterior. Por questões de segurança, eu não tenho acesso a credencial do usuário (usuário e senha).

Após autenticado, essa WebApi fará um request para o SharePoint Online, utilizando o token do usuário que se logou na primeira aplicação. 

 

 

Tem uma série de leituras interessantes sobre o assunto e vários exemplos na internet, mas nenhum mostrava como fazer as duas partes. É comum encontrar um exemplo de como proteger a WebApi ou como acessar o SharePoint online utilizando AccessTokens, mas nenhum faz essa ligação direta.

Pensando nessa dificuldade criei um Projeto no GitHub https://github.com/RARomano/AzureAD-WebAPI-SPOnline que demonstra, passo-a-passo, como fazer essa integração de forma simples.

Estou seguindo o mesmo modelo de aplicações que o time de Azure e a comunidade americana estão construindo, veja mais informações aqui: https://github.com/AzureADSamples.

O MVP de SharePoint Andrew Connell fez vários posts legais sobre o assunto e estão na seção “Referências” abaixo.

 

Basicamente, o que acontece por trás dos panos é o seguinte:

  1. O Usuário acessa a aplicação. 
  2. Windows Azure redireciona para página de Login
  3. O usuário faz o login
  4. A aplicação recebe um access token
  5. A aplicação faz um request para WebAPI utilizando esse token
  6. A Web API solicita um outro token para acessar o SharePoint e traz os dados desejados

É importante ressaltar que, nesse cenário, estamos utilizando o modelo App+User, ou seja, aplicação do Azure está agindo como se fosse o usuário. Inclusive, se você fizer uma operação que adicione ou modifique um item, no campo Modificado/Criado por aparecerá:

Criado por [nome do app] em nome do [Usuário]

 

 

Pensando em facilitar a nossa vida e facilitar esse processo de obter os tokens, criaram uma biblioteca denominada ADAL.NET (https://github.com/AzureAD/azure-activedirectory-library-for-dotnet). Ela ajuda e muito no processo. Estou utilizando essa biblioteca nos exemplos que fiz, mas todo o processo poderia ser feito de maneira manual fazendo HTTP Requests manuais para o Azure AD.

 

Referências

http://bitoftech.net/2014/09/12/secure-asp-net-web-api-2-azure-active-directory-owin-middleware-adal/

http://blogs.technet.com/b/ad/archive/2015/03/06/simplifying-our-azure-ad-authentication-flows.aspx

https://github.com/AzureADSamples

https://msdn.microsoft.com/en-us/library/azure/jj573266.aspx

https://msdn.microsoft.com/en-us/library/azure/dn499820.aspx

http://www.andrewconnell.com/blog/user-app-app-only-permissions-client-credentials-grant-flow-in-azure-ad-office-365-apis

http://www.andrewconnell.com/blog/looking-at-the-different-oauth2-flows-supported-in-azuread-for-office-365-apis

https://msdn.microsoft.com/pt-br/library/azure/jj573266.aspx

http://www.cloudidentity.com/blog/2013/09/12/active-directory-authentication-library-adal-v1-for-net-general-availability/

https://github.com/AzureAD/azure-activedirectory-library-for-dotnet

 

 

 

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ê?