Modelos de desenvolvimento do SharePoint

por Thiago Holder 

mar 15, 2017 wm Blog Lambda3

Link para o original.

Olá Pessoal, tudo bom?

Estamos de volta com mais um assunto legal sobre Sharepoint e vamos abordar mais um pouco sobre quais as opções que devemos escolher ao desenvolver para a plataforma SharePoint, ou seja, é realmente necessário customizar sempre? Porém customização no SharePoint não é tão simples e nem sempre o ideal, mas o projeto precisa e é necessário entregar.

Quando nos deparamos com SharePoint Framework, Client Model / Add-in, Server Model, Farm / SandBox Solution e Hosted Apps / Single Pages Apps, isso cria logo um nó na cabeça e confesso que assusta bastante quando pegamos um projeto de desenvolvimento do SharePoint e vem aquela dúvida: -E aí, qual o modelo eu escolho? Bom, já informo que não há um modelo perfeito, porém há maneiras de analisar e direcionar para um modelo que possa atender as necessidades do projeto. A sugestão que eu dou é analisar quais são os principais requisitos que o projeto necessita, em termos de quesitos técnicos e de negócio. Lembrando que geralmente os projetos que necessitam de customização no SharePoint são colocados em um perfil de projetos “long terms” principalmente as chamadas fases de análise, o que isso não quer dizer que seja um padrão, mas é o que se observa durante algum tempo em projetos grandes.

Mediante a isso, eu venho estudando algumas formas de pensar o mais simples possível e realizar entregas pequenas, sem ter muito o pensamento do todo e sim do que é mais significativo para o projeto. Com essa linha de pensamento, sabemos que uma plataforma já está pronta, o SharePoint. Esta plataforma já nos permite trabalhar pensando em um perfil de desenvolvimento direcionado a “Features”, “WebParts”, “Single Pages”, “Pages Layouts” e etc, ou seja, tudo é um pedaço funcional do sistema.

Deixando bem claro que não estamos abordando aqui um modelo ideal e nem mesmo um processo de desenvolvimento que possa ser confundido ao modelo de SCRUM, Agile, XP e etc. Estamos abordando os modelos de desenvolvimento da Plataforma SharePoint e como a escolha de um modelo essencial possa fazer a diferença na velocidade das entregas em projetos que envolvam customizações no SharePoint.

E aí pensei em alguns tópicos legais:

• Quais as perspectivas de negócio e funcionalidade que aquela customização irá atender? Neste ponto, a resposta pode se tornar simples, como por exemplo se o SharePoint é OnLine ou OnPremisse. Então, já filtro as necessidades que irão atender as diferenças de um modelo de desenvolvimento destas duas versões, pois há modelos que não irão atender ao SharePoint OnLine, como o modelo de Farm ou SandBox Solution – WSP´s.
• Avalie também quais são as experiências que o time tem sobre os diversos modelos de desenvolvimento que o SharePoint oferece. Em um projeto de entregas rápidas e funcionais, não é necessário gastar muito tempo com: “ – Vocês viram que legal saiu a versão beta do Sharepoint framework, vamos usar ?”. Bom, podemos usar se o nosso time concordar. O tempo de experiência no SharePoint Framework não é algo significativo para discutir se ele irá realmente atender as necessidades do projeto. Acredito que não seja realmente necessário se basear em um modelo “achando que ele é realmente bom e legal”.

Particularmente, eu prefiro observar os principais pontos de vantagens e desvantagens que um determinado modelo, mediante uma análise inicial, poderá oferecer ao time.

Neste primeiro momento vamos falar dos dois principais modelos de desenvolvimento do SharePoint. Nossa intenção é de criar uma sequência de posts dos diversos modelos existentes.

Abaixo algumas das vantagens e desvantagens que acredito serem importantes, pois existem uma enorme comparação, mas não há necessidade de detalhar todas. Irei resumir alguns aspectos teóricos que eu utilizo.

Soluções clássicas do SharePoint (WSP´s) – Server Model

Vantagens	Desvantagens
Há muita documentação e recursos que possam ser reutilizados e fáceis de encontrar na internet. Onde a maioria dos desenvolvedores experientes compartilham muitas formas de resolver problemas.	SandBox e Farm solution não são suportados pelo SharePoint OnLine. Acredito que isso torna-se uma desvantagem quando avaliamos que hoje o crescimento do SharePoint OnLine está cada vez maior e a tendência de migração também é maior.
Desde a versão 2010 do Visual Studio, já contém ferramentas para o desenvolvimento de soluções SharePoint e isso ajuda bastante ao gerar um pacote, publicar, criar templates, edições de arquivos manifests (a maioria das soluções são), criação de features, controles e etc.	Sabemos que FarmSolution pode causar impacto significativos na Farm, isso poderá gerar um custo maior na manutenção, segurança e confiabilidade na infraestrutura. Como por exemplo, atualizações de versões e isso pode gerar um tempo de inatividade dos serviços ou até mesmo conflito com a solução que foi entregue.

Com a avaliação realizada acima, hoje eu pensaria neste modelo caso a customização não precisasse ser migrada para o OnLine. Um outro exemplo é criar uma lista customizada que tem diversas ações internas para atender um determinado fluxo ou área de negócio, e que a necessidade funcional dela fosse bastante simples. Também se a solução necessitasse de um controle sobre as Features Lançadas, modificar um controle nativo de um determinado SiteCollection, modificação de comportamento de features nativas e outras propostas que precisam de um acesso mais interno ao ambiente SharePoint.

Um exemplo clássico e que foi muito utilizado é o desenvolvimento de sites públicos. Porém, não é mais possível fazer sites públicos, aqueles portais institucionais com acesso anônimo, na plataforma SharePoint OnLine, mas o OnPremisse disponibiliza essa possibilidade, visto que o controle de toda a infra é de nossa responsabilidade. Portanto, para atender as necessidades de um grande portal, com diversas implementações, master pages, controles diversos, features, pages layouts, bibliotecas customizadas, busca customizada, customização de dados gerenciados e por aí vai, uma boa escolha seria usar também esse modelo, mas não é uma regra e sim um direcionamento.

Sharepoint add-in model – Client Model

Vantagens	Desvantagens
Um modelo que funciona nos dois lados, como no SharePoint OnPremises e Online.	Implementação de iFrame para as web-parts desses add-ins (add-in parts). Esta é uma das desvantagens que atualmente não soa bem.
A parte de segurança, para códigos que não serão executados diretamente no SharePoint Server, isso torna um código mais isolado para cometer falhas no ambiente SharePoint. Isso funciona porque o domínio de add-ins são isolados da farm do SharePoint.	O controle dos dados é um pouco complicado. Como exemplo um add-in de notícias que utiliza dados de uma lista que está no hosted (domínio isolado), essa lista se for apagada não irá para a lixeira do SharePoint. Assim é necessário ter todo esse controle de dados quando se usa o Add-In Model.
Todas as personalizações incluídas no SharePoint ficam mais desacopladas. Como mencionado acima, ele estará em um local isolado, só utilizando o ambiente SharePoint para hospedá-lo. Por isso que é um add-in sendo hospedado pelo SharePoint (Provider Hosted Add-Ins).	Toda a parte de configuração para começar a desenvolver com este modelo torna-se complicado, pois há uma série de requisitos que devem ser levantados e isso irá exigir um pouco mais de esforço da equipe.

O que podemos avaliar dentro de um cenário que pode ser necessário usar o add-in model? Bom, no meu caso, uso esta abordagem quando é necessário realizar algum tipo de integração com outros sistemas e eu preciso integrar determinadas informações dentro de um ambiente SharePoint, aproveitando de todo o ambiente interno já montando (Intranet), e fazer com que algumas soluções isoladas possam ser executadas e hospedas no SharePoint. Isso é legal, porque o meu desenvolvimento irá se basear praticamente em tecnologias Clients, para isso temos a biblioteca do CSOM (Client Side Object Model). Essa vantagem é importante por ser uma tecnologia hibrida e de fácil migração, quando se trata de dois ambientes tanto o OnPremisse como o On-Line. Sim, este seria meu ponto de partida, pois eu terei praticamente acesso a muitas ferramentas e serviços que estão integradas a esse ambiente, como consumir informações corporativas dos usuários e pensar em prover serviços isolados para enviar e-mails a um determinado grupo de pessoas (isso pode soar fácil, mas quando tenho serviços que integram isso é bem mais fácil) e inclui a questão de ter toda a parte de permissão já pronta.

Pontos que devemos tomar muito cuidado ao usar esse modelo: avaliar sempre a base técnica da equipe que irá fazer o projeto. Esse modelo é direcionado para pequenas customizações isoladas que necessitam de uma integração e maior segurança. Não vamos confundir em fazer um portal todo com um modelo de Add-in, pois lembre-se que iremos ter dificuldades em fazer SEO, visto que terá seus add-ins no iFrames. Se é possível fazer SEO com iFrame? Bom, a resposta que eu posso dar é que o esforço vai ser muito grande se isso for possível.

Vamos encerrar por aqui, para que o nosso post não fique enorme e confunda nossas mentes pensantes. Nos próximos momentos estarei comentando e comparando outros modelos que estão surgindo no SharePoint, com o objetivo principal de compartilhar nossas experiências nesse mundo chamado SharePoint.

Referências:

• Visão Geral de Desenvolvimento no SharePoint 2013 – https://msdn.microsoft.com/pt-br/library/office/jj164084.aspx
• APIS do SharePoint – https://msdn.microsoft.com/pt-br/library/office/dn268594.aspx
• Serviços REST do SharePoint – https://msdn.microsoft.com/pt-br/library/office/fp142380.aspx