Diretrizes empresariais da Estrutura do SharePoint

O SPFx (Estrutura do SharePoint) é um novo modelo de desenvolvimento para extensibilidade da interface do usuário do SharePoint. Ele é usado por primeiros e terceiros, complementando as opções de personalização e extensibilidade existentes, como o modelo de suplemento do SharePoint. O Estrutura do SharePoint permite uma abordagem estruturada e com suporte para enriquecer e estender a interface do usuário do SharePoint usando estruturas do lado do cliente. Com base nos padrões modernos da Web, ele oferece um conjunto exclusivo de recursos para tornar as personalizações do SharePoint amplamente disponíveis para desenvolvedores e empresas, mas ao mesmo tempo se alinha com modelos e padrões anteriores no SharePoint. Nesta página, fornecemos aos administradores os planos de fundo, benefícios e conhecimentos necessários para gerenciar com êxito componentes baseados em Estrutura do SharePoint em seus ambientes do SharePoint.

Histórico

O SharePoint tem sido usado como uma plataforma de aplicativo e desenvolvimento há muito tempo e oferecido muitos conjuntos de opções de desenvolvimento e personalização que variam desde código de confiança total em execução em servidores do SharePoint em si até soluções em Área restrita, suplementos, e personalizações de interface obtidas usando recursos prontos para uso ou inserção de JavaScript/CSS.

Em vários locatários do SharePoint Online, nunca houve suporte a código de confiança total, e o serviço de código de área restrita foi preterido. Os padrões mais comuns de personalizações do SharePoint Online eram por meio de suplementos, execução de código remoto (código em execução em outro lugar, como no Azure) por meio das APIs padrão e inserção de JavaScript. Embora a inserção de JavaScript tenha sido uma forma poderosa de estender o SharePoint, também era difícil acompanhar o modelo atualizado do SharePoint Online. A Estrutura do SharePoint tem por objetivo resolver esses problemas, fornecendo uma estrutura padronizada para criar extensões de interface do usuário personalizadas e criar aplicativos com base no SharePoint Online de uma maneira dotada de suporte e preparada para o futuro.

A Estrutura do SharePoint estende a interface do usuário do SharePoint com web parts do lado do cliente e extensões.

Web Parts do lado do cliente

As Web Parts do lado do cliente usam o paradigma conhecido das Web Parts, que foi um dos fatores de sucesso do SharePoint ao longo dos anos e pode ser adicionado a páginas e personalizado independentemente pelos usuários finais. Eles podem ser adicionados às páginas e personalizados de forma independente pelos usuários finais. Essas Web Parts do lado do cliente funcionam nas novas páginas modernas e nas páginas clássicas e até no aplicativo móvel do SharePoint.

Observação

Para obter mais informações, consulte visão geral das Web Parts do lado do cliente do SharePoint.

Extensões

As extensões SPFx permitem que os desenvolvedores implementem determinadas personalizações de interface do usuário na experiência "moderna" que eram possíveis na experiência "clássica" do SharePoint. Os desenvolvedores podem adicionar JavaScript a qualquer página, adicionar cabeçalhos e rodapés de página, adicionar itens de menu a listas e bibliotecas e personalizar a exibição de um campo em uma lista.

Modelo de desenvolvimento e ferramentas

A Estrutura do SharePoint foi criada desde o início usando um TypeScript moderno baseado em pilha da Web, JavaScript, HTML e CSS. Todas as partes dos artefatos gerados são executadas no navegador do usuário final. A Estrutura do SharePoint também vem com um conjunto novo de ferramentas. Essa nova ferramenta é independente de plataforma e funciona no Windows, macOS, Linux e se baseia em tecnologias de software livre, como o Node.js, o Gulp, o Webpacke o Yeoman. Essas estruturas e ferramentas são usadas em tempo de compilação de simplificar a experiência do desenvolvedor para compilação, empacotamento e implantação, não sendo necessárias para a execução real do código da Estrutura do SharePoint.

Status atual da Estrutura do SharePoint

A Estrutura do SharePoint foi lançada para o SharePoint Online em fevereiro de 2017. A versão mais recente e todas as demais versões do SharePoint Framework estão hospedadas e disponíveis no SharePoint Online.

A Estrutura do SharePoint também está disponível para o SharePoint Server 2016 (com Feature Pack 2) como versão v1.1 e SharePoint Server 2019 como versão v1.4.1.

Do ponto de vista do desenvolvedor

Todos os desenvolvedores do SharePoint, sejam eles iniciantes ou experientes, têm algo a ganhar com a Estrutura do SharePoint. Ela permite que o desenvolvedor estenda os recursos da interface do usuário do SharePoint de forma segura e estruturada, usando inicialmente Web Parts do lado do cliente. Esses componentes são executados no lado do cliente e podem trabalhar com dados no SharePoint, no Microsoft 365 por meio do Microsoft Graphou até mesmo usando suas próprias APIs Web personalizadas que usam métodos OAuth e REST padrão.

Um desenvolvedor experiente do SharePoint estará familiarizado com os conceitos, como o modelo de dados do SharePoint e Web Parts. No entanto, as ferramentas para compilação, empacotamento e implantação de Web Parts do lado do cliente serão novas. Os desenvolvedores precisam adquirir experiência especificamente com TypeScript, que é a linguagem principal para o desenvolvimento de artefatos da Estrutura do SharePoint. O TypeScript adiciona vários benefícios ao JavaScript, o que é importante para o desenvolvimento corporativo, como objetos fortemente tipados, herança de objeto, classes e interfaces, conceitos que devem ser familiares para desenvolvedores atuais de .NET, Java e C++. Do ponto de vista de compilação e empacotamento, os desenvolvedores não têm mais o Visual Studio como a única opção disponível para gravar soluções do SharePoint. Graças ao uso de tecnologias de software livre e projetos como node.js, npm e Gulp, o desenvolvimento da Estrutura do SharePoint pode ser feito em qualquer plataforma com o editor de código ou IDE preferencial dos desenvolvedores, por exemplo, Visual Studio Code, Sublime ou até mesmo o Bloco de Notas.

Para desenvolvedores que nunca criaram soluções do SharePoint anteriormente, mas estão familiarizados com tecnologias da web modernas, não há uma curva de aprendizado significativa. Muitos desenvolvedores já migraram para o desenvolvimento do lado do cliente ou uma combinação dele. O desenvolvimento do lado do cliente pode fornecer uma experiência melhor, mais dinâmica e mais ágil para os usuários e até uma experiência mais fácil para os desenvolvedores. Graças à liberdade para escolher o editor de código, o uso de estruturas e tecnologias de software livre conhecidas e populares, muitos desenvolvedores que talvez sequer tenham trabalhado no ecossistema da Microsoft podem facilmente começar a criar extensões do SharePoint.

Um dos padrões mais comuns na extensibilidade do SharePoint Online foi o uso de inserção de JavaScript (também conhecido como injeção de código JavaScript). É um método em que, por exemplo, você usa a Web Part de Editor de Script para inserir JavaScript arbitrário na página e, depois, a manipulação de DOM (Modelo de Objeto do Documento) do navegador da Web para inserir HTML, CSS e JavaScript e criar uma solução ou um aplicativo. Esse método tem muitas desvantagens e, em muitos casos, até mesmo impedia os clientes de tirar proveito dos novos recursos no SharePoint Online devido a suas dependências rígidas em relação à forma como o SharePoint criava a estrutura de HTML e CSS. A Estrutura do SharePoint possibilita uma opção melhor para essas personalizações de inserção de JavaScript, embora ainda não ofereça uma substituição completa. Conforme mencionado, a Estrutura do SharePoint usa TypeScript, permitindo uma transição bastante fácil das inserções de JavaScript para uma opção padronizada e preparada para o futuro. A iniciativa de PnP OfficeDev também tem projetos de exemplo e diretrizes sobre como fazer essa transição.

Em perspectiva: a Estrutura do SharePoint na plataforma mais ampla do SharePoint

A Estrutura do SharePoint é um novo modelo, em adição aos métodos já existentes, mas concentrado em agregar mais valor para personalizações da interface do usuário, como Web Parts do lado do cliente. Essa estrutura é projetada para funcionar em conjunto com modelos de trabalho já existentes e facilitar a criação de novas personalizações da interface do usuário de forma mais sustentável e com mais suporte.

Importante

A página do SharePoint HTML DOM não é uma API. Você deve evitar dependências na estrutura DOM da página ou nos estilos CSS, que estão sujeitas a alterações e potencialmente interrompem suas soluções. O SharePoint Framework fornece uma API avançada para personalizar a experiência do SharePoint de maneiras confiáveis e é o único meio suportado para interagir com a HTML DOM da página do SharePoint.

Comparação com os suplementos

Os Suplementos do SharePoint, introduzidos no SharePoint 2013 como Aplicativos do SharePoint, mas posteriormente renomeados, foram uma das únicas opções disponíveis para adicionar personalizações ao SharePoint Online de maneira compatível e governada. No entanto, os Suplementos do SharePoint exigem muito mais infraestrutura do que o necessário em muitos casos em que é necessária uma personalização simples da interface do usuário.

Há dois tipos de Suplementos do SharePoint: hospedados pelo SharePoint e hospedados pelo provedor. Os suplementos hospedados pelo SharePoint têm sido uma das maneiras de executar código do lado do cliente no SharePoint de forma compatível, mas, conforme mencionado, exigem muito mais esforço do que o necessário para incluir apenas uma Web Part simples do lado do cliente (JavaScript). Em muitos casos, os suplementos hospedados pelo SharePoint eram criados apenas para implantar artefatos, como listas e Web parts, em um site do SharePoint. Esses suplementos estão contidos em um site "especial" chamado Aplicativo Web, que é um site com recursos limitados.

Suplementos hospedados pelo provedor são suplementos executados remotamente do SharePoint (Online) e podem aproveitar o código do lado do servidor e o código do lado do cliente. Isso tem um benefício para ISVs que desejam proteger sua propriedade intelectual/código/lógica e para cenários que não podem ser executados do lado do cliente usando JavaScript, como operações de execução longa e com muitos cálculos ou acesso a dados remotos que não podem ser obtidos usando scripts do lado do cliente.

A principal vantagem dos suplementos é o isolamento já que o código real não é executado no navegador do site do SharePoint, as proteções de scripts entre sites impedem que o suplemento tenha o mesmo acesso que o usuário. Os suplementos são limitados às permissões que lhes foram concedidas no momento da instalação. Isso torna os suplementos uma opção mais segura para cenários em que um administrador adquire um suplemento de terceiros e também permite que a Microsoft tenha uma Loja da qual você pode baixar suplementos.

A Estrutura do SharePoint trabalha lado a lado com os suplementos hospedados pelo SharePoint e aqueles hospedados pelo provedor, mas também pode ser usada como uma alternativa em cenários em que apenas scripts do lado do cliente são necessários. Por exemplo, os suplementos podem adicionar App Parts ao site em que estão hospedados. Essas App Parts são semelhantes às Web Parts, mas em vez de serem executadas no contexto da página, são executadas em seu próprio domínio (App Web ou Web hospedada pelo provedor) em um Iframe na página. Isso impede que o suplemento tenha o contexto de usuário do restante da página.

Por outro lado, a Estrutura do SharePoint não é executado em um Iframe. Por isso, ele pode ser executado mais perfeitamente no contexto da página com todo o controle do usuário que está exibindo a parte. Essa é a chave para habilitá-lo para ser executado com funcionalidade avançada, mas, ao mesmo tempo, significa que ele não tem o mesmo nível de controles de segurança que os suplementos. As soluções da Estrutura do SharePoint estão sujeitas e isso também sendo referidas como soluções do lado do cliente de confiança total. Os Iframes têm o problema de não serem responsivos, o que faz com que a página da Web renderizada não seja tão fluente em um telefone celular ou em um tamanho de tela alternativo.

No momento da redação deste artigo, as soluções da Estrutura do SharePoint não têm um repositório do qual você possa baixar e instalar soluções, devido ao aspecto de segurança mencionado acima. Em muitos cenários, o uso do contexto dos usuários é um cenário desejado, em que a Estrutura do SharePoint poderia ser usada em vez disso.

Inserindo JavaScript em HTML

Uma das abordagens mais populares usadas pelos desenvolvedores é usar um método chamado inserção de JavaScript (também conhecido como injeções de JavaScript). Isso significa que JavaScript arbitrário era inserido nos sites e nas páginas usando, por exemplo, Ações Personalizadas, páginas mestras, layouts de página e até Web Parts de Editor de Scripts. Esse método se mostrou mais simples do que a criação de suplementos hospedados pelo SharePoint e permite que o código de script seja executado no contexto completo dos usuários e é por isso que ganhou muitas popularidade. A desvantagem dessa abordagem é que muitas das inserções usavam manipulação DOM e, para fazer e manter isso, eram necessárias habilidades dos desenvolvedores.

Devido à natureza sempre existente do SharePoint Online, essas soluções criadas inserindo JavaScript podem ser interrompidas sempre que o SharePoint Online foi atualizado, porque os desenvolvedores podem ter assumido dependências (até mesmo acidentalmente) de como as páginas do SharePoint são estruturadas ou estiladas. Quando são feitas atualizações no SharePoint, mesmo que elas sejam secundárias e sutis, isso pode ter grande impacto sobre essas soluções e fazer com que o JavaScript inserido seja completamente danificado.

Agora, com a Estrutura do SharePoint, há uma maneira padronizada e com suporte da Microsoft para chegar a muitas dessas soluções anteriormente criadas usando inserções de JavaScript.

Web Parts de Editor de Scripts

A maneira mais comum de inserir personalizações arbitrárias de HTML, JavaScript ou CSS no SharePoint é usar a Web Part de Editor de Scripts ou a Web Part do Editor de Conteúdo. As Web Parts do Editor de Scripts ganharam popularidade devido à facilidade de adicionar scripts personalizados a qualquer página. Qualquer editor de um site pode adicionar uma web part do Editor de Scripts a uma página, copiar e colar JavaScript nele e fazer com que o JavaScript faça as personalizações necessárias. Assim como com as inserções de JavaScript, pode ser um desafio para que os administradores tenham controle das web parts de Editor de Scripts.

Em muitos casos, a Estrutura do SharePoint pode ser um substituta direta para essas configurações de Web Part de Editor de Scripts.

Controle de recursos de script no SharePoint Online

O SharePoint Online permite que os administradores controlem a capacidade de adicionar scripts personalizados a sites e páginas, para aumentar a segurança e a integridade do locatário. Isso é feito usando o recurso "Script Personalizado" no site de administração do SharePoint Online ou individualmente por site usando o PowerShell.

Os scripts personalizados podem ser desabilitados em todos os sites ou apenas em sites pessoais. Por padrão, os novos locatários têm os scripts desabilitados em sites pessoais, em todos os sites de autoatendimento criados, e no conjunto de sites raiz do locatário.

Quando os scripts personalizados são desabilitados, os editores de sites não têm permissão para adicionar web parts como a web part de Editor de Scripts. No entanto, são permitidas soluções da Estrutura do SharePoint, desde que sejam consideradas seguras após serem aprovadas por um administrador no catálogo de aplicativos.

Diferenças na maneira como as soluções da Estrutura do SharePoint são criadas e porque isso é importante

A Estrutura do SharePoint usa um novo paradigma para desenvolvedores do SharePoint referente à maneira de projetar, criar e implantar personalizações do SharePoint, utilizando uma abordagem de pilha Web moderna e concentrando-se nas personalizações com base no lado do cliente/navegador.

Isso marca uma alteração importante na forma como o desenvolvimento do SharePoint está sendo tratado.

Ao usar tecnologias e estruturas como TypeScript, Node.js, Yeoman, Gulp e muito mais, a Estrutura do SharePoint atrairá públicos-alvo de desenvolvedores que tradicionalmente não estavam no SharePoint ou até mesmo Microsoft, eco-system, enquanto, ao mesmo tempo, abrem as portas para desenvolvedores existentes do SharePoint criarem personalizações do SharePoint usando uma abordagem mais moderna e padronizada.

Criação de soluções

Devido à necessidade de ferramentas específicas e direcionadas fornecidas por meio do Visual Studio, o desenvolvimento do SharePoint foi feito por meio do Visual Studio em um ambiente de desenvolvimento baseado no Windows com uma instância instalada e configurada localmente do SharePoint. Isso limitou as preferências de hardware e usuário e aumentou os custos de desenvolvimento. Por outro lado, a Estrutura do SharePoint usa várias ferramentas Web comuns de software livre disponíveis para diversas plataformas diferentes, como macOS e Linux, para permitir mais flexibilidade no desenvolvimento.

As soluções da Estrutura do SharePoint são criadas usando uma ferramenta chamada Yeoman, juntamente com um gerador específico da Estrutura do SharePoint baseado em Node.js. O Yeoman é uma ferramenta de estruturação de projetos. Ele criará seu projeto e gerará os artefatos necessários, instalará os pacotes Node.js necessários e configurará o sistema de compilação.

Depois que o projeto é gerado, ele pode ser editado em qualquer editor em qualquer sistema operacional, como Visual Studio, Visual Studio Code, Core ou Atom. Isso possibilita mais preferências de uso e estilo, em e entre equipes. O gerador Yeoman pode ser executado várias vezes no mesmo projeto para adicionar artefatos, como Web Parts do lado do cliente.

Desenvolvendo e criando soluções

O sistema de build é baseado no Gulp. O Gulp é um executor de tarefas que compila, empacota e, opcionalmente, implanta os artefatos da Estrutura do SharePoint. Como o Yeoman, o Gulp também é baseado em Node.js e permite que os desenvolvedores compilem e implantem em qualquer sistema operacional.

Uma parte do conjunto de ferramentas de compilação da Estrutura do SharePoint se chama Workbench. O Workbench é uma ferramenta em que o desenvolvedor pode hospedar e testar a solução da Estrutura do SharePoint. O Workbench é reativo e recarrega automaticamente os artefatos quando o desenvolvedor salva um arquivo. Assim, os desenvolvedores podem ver e testar a solução de maneira rápida.

Há duas versões do Workbench. Existe uma versão fora do SharePoint, hospedada localmente no computador de desenvolvimento que é executado offline sem acesso ao SharePoint e dados do SharePoint. Isso permite que a equipe e os designers compilem e projetem soluções com dados fictícios ou falsos para se concentrar na interface do usuário.

A outra versão do Workbench é hospedada dentro do SharePoint e deve ser usada quando você precisa testar e verificar a solução da Estrutura do SharePoint usando dados e contexto reais do SharePoint.

Importante

O Workbench local requer um navegador evergreen moderno. O Internet Explorer 11 não tem suporte no Workbench local.

Implantação de soluções da Estrutura do SharePoint

A implantação de soluções da Estrutura do SharePoint é feita implantando um pacote de solução no catálogo de aplicativos e aprová-lo para uso em seu locatário ou conjunto de sites.

Para soluções implantadas no SharePoint Online, você pode usar a CDN hospedada do Microsoft 365 para armazenar e servir os artefatos na solução que são usados para implementar os componentes do lado do cliente. Para obter mais informações, consulte a seção CDN Pública do Microsoft 365.

Para soluções implantadas no SharePoint Server, você precisará determinar onde seus artefatos serão armazenados. Essa é uma etapa de implantação adicional que não é exigida pelo SharePoint Online. O único requisito é que os artefatos sejam acessíveis pelos usuários da sua solução.

Alternativas à CDN do SharePoint Online

Os desenvolvedores da solução da Estrutura do SharePoint podem optar por usar qualquer serviço da CDN, como o Armazenamento do Azure, a CDN do Azure ou até o próprio SharePoint, de preferência usando os recursos da CDN do SharePoint (mais adiante nesse documento). O uso de uma CDN pública, em que os ativos implantados na CDN estão publicamente disponíveis na Internet, permite que a solução da Estrutura do SharePoint seja usada por vários locatários. Em uma solução da Estrutura do SharePoint implantada na CDN do SharePoint, os scripts e os recursos implantados estão disponíveis apenas para o locatário em que estão implantados.

Por padrão, há uma tarefa interna nas ferramentas de compilação para implantar a solução empacotada em um armazenamento de Blobs do Azure. Isso é algo que normalmente é estendido, por SIs ou ISVs, para oferecer suporte às configurações ou locais de CDN personalizados.

Depois de alterar o código e criar a solução, o Estrutura do SharePoint toolchain produz um novo pacote de solução (*.sppkg) e um conjunto de arquivos de script. Esses arquivos de script incluem um hash exclusivo em seu nome de arquivo, que indica que o conteúdo desses arquivos difere das suas versões implantadas anteriormente. Para usar uma nova versão da solução, você precisa implantar o novo conjunto de scripts em sua CDN e atualizar o pacote da solução no catálogo de aplicativos. Embora teoricamente você possa substituir o conteúdo dos arquivos de script existentes e evitar a atualização do pacote da solução, isso não é confiável nem recomendável. Dependendo da configuração do seu CDN, é possível que os arquivos de script baixados anteriormente sejam armazenados em cache por um longo tempo nos computadores clientes, complicando ainda mais a distribuição da solução para os usuários finais.

O local da CDN é importante. O local em que os ativos da Estrutura do SharePoint estão hospedados deve ter alta disponibilidade. Portanto, são recomendados provedores de CDN confiáveis, como Azure, Akamai ou semelhantes e o próprio SharePoint. Do ponto de vista da segurança, é importante saber quais CDNs estão em uso por soluções implantadas da Estrutura do SharePoint. Uma CDN danificada também pode danificar as soluções da Estrutura do SharePoint e, na pior das hipóteses, uma CDN comprometida pode fazer com que os dados do locatário do SharePoint (Online) também sejam comprometidos.

Ao aprovar soluções de terceiros da Estrutura do SharePoint, um item de lista de verificação típico é verificar a autoridade e a confiabilidade do local da CDN e de quaisquer terceiros que possam hospedá-la. Isso ocorre porque, depois que o aplicativo é instalado e utilizado nos conjuntos de sites do SharePoint, esses conjuntos de sites têm uma dependência em relação à localização da CDN. No momento em que esse artigo foi redigido, ainda não havia uma maneira fácil de controlar esse ponto de extremidade. O provedor de terceiros da CDN pode fazer a atualização com alterações desejadas e indesejadas sem o conhecimento dos usuários, abrindo uma superfície de ataque, já que a Estrutura do SharePoint está sendo executada no contexto dos usuários e pode fazer tudo o que os usuários podem fazer.

Uma recomendação é que os administradores de TI controlem quais CDNs são usadas e quais CDNs são aprovadas pela organização. Isso também deve ser comunicado aos desenvolvedores da empresa.

CDN pública do Office 365

A CDN Pública do Microsoft 365 é um novo recurso no Microsoft 365 e no SharePoint Online que permite que os administradores hospedem automaticamente ativos estáticos como arquivos JavaScript, imagens e estilos CSS em uma CDN para fornecer o melhor desempenho. A CDN Pública do Microsoft 365 é um recurso de cache distribuído geograficamente que mantém os ativos estáticos mais próximos dos navegadores de usuários finais que os solicitam.

Os administradores podem habilitar o recurso de CDN Pública do Microsoft 365 em uma ou mais bibliotecas de documentos, que servirão como a origem para os ativos estáticos. A administração de bibliotecas e da CDN é feita usando os cmdlets do PowerShell do SharePoint Online. Os ativos, na biblioteca de documentos, serão replicados para a CDN do Microsoft 365 e serão acessíveis por meio das URLs da CDN Pública do Microsoft 365 geradas e associadas à biblioteca de documentos. As atualizações nos ativos serão refletidas nos pontos de extremidade da CDN em 15 minutos. Todos os ativos dentro das bibliotecas de documentos estarão disponíveis para usuários anônimos por meio do ponto de extremidade da CDN.

Estrutura do SharePoint na empresa

O SharePoint é e tem sido uma das plataformas de colaboração empresarial mais bem-sucedidas, e um dos motivos para seu sucesso são as opções de extensibilidade e usá-lo como uma plataforma para aplicativos e integrações. A Estrutura do SharePoint expandirá ainda mais esse sucesso, tornando o SharePoint uma plataforma mais moderna para compilar personalizações do lado do cliente de modo padronizado e com suporte.

Desenvolvedores corporativos

A Estrutura do SharePoint permite que Desenvolvedores corporativos, geralmente desenvolvedores que criam o aplicativo para uso em uma organização, estendam o SharePoint (Online) com nova funcionalidade de maneira estruturada e com suporte. A Estrutura do SharePoint oferece tudo, desde a estrutura de desenvolvimento e o pipeline de compilação até a implantação real, e permite que os desenvolvedores acessem em pouco tempo todos os conjuntos de sites com novas soluções e recursos, todos controlados pelo catálogo de aplicativos. Em um cenário empresarial, você também tem controle total dos locais da CDN, externos ou internos no SharePoint, e pode implantar facilmente correções e atualizações em toda a sua organização.

Na empresa, os administradores e os desenvolvedores devem criar em conjunto um projeto para a forma como as soluções da Estrutura do SharePoint devem ser implantadas. A impressão azul deve conter detalhes sobre estruturas preferenciais do lado do cliente, locais da CDN e assim por diante.

Para obter mais informações, consulte a seção criar um plano em torno de personalizações da Estrutura do SharePoint.

Desenvolvedores cidadãos

Por muito tempo, os desenvolvedores cidadãos usaram o SharePoint para criar aplicativos de negócios usando muitos métodos e técnicas.

A Estrutura do SharePoint para determinados cenários, especificamente incorporações JavaScript e soluções de web part do Editor de Scripts, será uma boa maneira de avançar. Isso é para tornar essas soluções mais padronizadas e facilitar sua manutenção ao longo do tempo. Para desenvolvedores cidadãos, pode haver alguma curva de aprendizado para se ajustar a essa nova maneira estruturada de criar soluções, mas a longo prazo se mostrará mais estável, segura e sustentável.

Conforme mencionado acima, considerando que os métodos de controle de Script Personalizado estão em vigor, os desenvolvedores cidadãos não terão permissão para adicionar código JavaScript arbitrário ou web parts de Editor de Scripts. Isso pode tornar seu ambiente do SharePoint potencialmente mais estável e sustentável, mas, ao mesmo tempo, talvez impeça inovações na empresa, portanto, garanta que os desenvolvedores cidadãos se alinhem com os desenvolvedores empresariais quanto ao uso da Estrutura do SharePoint no futuro.

Desenvolvedores de front-end e projetistas da experiência do usuário

Para desenvolvedores Web ou designers de interface/experiência do usuário, o Estrutura do SharePoint será valioso. O Workbench permite que os desenvolvedores de front-end trabalhem com uma solução da Estrutura do SharePoint em qualquer sistema operacional e usem as ferramentas de edição de sua preferência sem o SharePoint, já que usam dados fictícios e se concentram na experiência do usuário.

A Estrutura do SharePoint é lançada em paralelo com o Office UI Fabric, que é a estrutura de desenvolvimento de front-end oficial para o Office e o Microsoft 365 e permite que os projetistas da experiência do usuário criem uma experiência perfeita no Office, no Microsoft 365 e nas soluções personalizadas criadas.

SI (Integradores de Sistemas)

Se você tira proveito de SI (Integradores de Sistemas) ou consultorias para criar soluções do SharePoint e do Microsoft 365, deve definir recomendações ou até mesmo requisitos sobre como eles devem criar soluções da Estrutura do SharePoint para que se alinhem ao plano da empresa para a Estrutura do SharePoint.

Normalmente, os Integradores de Sistemas têm uma maneira preferencial de criar soluções, que pode nem sempre estar alinhadas com sua governança. Portanto, essa discussão sobre os Integradores de Sistemas é importante e, em última analise, facilitará o trabalho para todas as partes.

Um cenário típico com Integradores de Sistemas é que eles criam a solução para sua empresa e, depois que o projeto é concluído, cabe a você a manter e atualizar a solução. Isso só enfatiza que você precisa se alinhar com o SI sobre a forma como as soluções da Estrutura do SharePoint são criadas e hospedadas.

Fornecedores Independentes de Software (ISVs)

Os ISVs (Fornecedores Independentes de Software) são organizações que criam soluções de terceiros para o mercado em massa. Eles podem nem sempre atender a seu plano para as soluções da Estrutura do SharePoint. Além disso, os ISVs normalmente têm seus próprios códigos e propriedade intelectual. Assim, é difícil para você alterar a maneira como eles implementam e hospedam suas soluções.

Quando utilizar soluções da Estrutura do SharePoint de provedores de terceiros, você precisará examinar especificamente como eles gerenciam as atualizações e como as soluções são hospedadas. Por exemplo: você permite que a solução seja atualizada sem seu conhecimento? Você permite que os ativos estáticos hospedados na CDN do ISV sem seu controle? Qual é sua relação de confiança com esse ISV?

Lembre-se de que qualquer código do lado do cliente na Estrutura do SharePoint é executado no contexto do usuário atual, e você não pode impor restrições para isso, como pode fazer com os Suplementos do SharePoint.

Criação de um plano para personalizações da Estrutura do SharePoint

Ao introduzir a Estrutura do SharePoint como uma das ferramentas para estender as instâncias do SharePoint (Online), é necessário planejá-lo. O plano deve começar com a introdução da nova pilha de tecnologia usada durante a criação de soluções da Estrutura do SharePoint. Os desenvolvedores podem precisar de treinamento para usar TypeScript como o idioma principal de gravação do código da Estrutura do SharePoint.

Outro aspecto da Estrutura do SharePoint que os desenvolvedores precisam conhecer é a cadeia de ferramentas real da Estrutura do SharePoint, que inclui Node.js, NPM e Gulp, e como usar as diferentes tarefas do Gulp para compilar, empacotar e implantar soluções. Os recursos iniciais bons para isso são a documentação oficial da Estrutura do SharePoint ou os repositórios do GitHub do SharePoint.

Os desenvolvedores talvez queiram padronizar em uma estrutura do lado do cliente específica para a organização ou em estruturas diferentes. As estruturas do lado do cliente incluem, mas não se limitam a, React, Nocaute, Angular, Guidão, jQuery etc. Há vantagens em padronizar em uma estrutura, pois isso permite que os desenvolvedores criem um código mais reutilizável e tenham melhor consistência na forma como criam e mantêm suas soluções.

Há vantagens de permitir mais de uma estrutura, pois cada estrutura do lado do cliente tem seus prós e contras e casos de uso. Porém, permitir qualquer estrutura do lado do cliente pode causar fragmentação nas soluções empresariais, sem mencionar que ter várias estruturas diferentes pode aumentar o tempo de carregamento de página, pois isso requer o carregamento de mais bibliotecas externas.

Pronto para uso, o gerador Yeoman da Estrutura do SharePoint tem modelos para duas estruturas do lado do cliente: React e Knockout. Ao longo do tempo, pode-se esperar que a comunidade adicione mais geradores ou subgeradores para usar outras estruturas do lado do cliente. Escolher o React como sua estrutura preferencial do lado do cliente tem uma vantagem, pois a Microsoft criou uma versão do React do Office UI Fabric. Assim, você obterá a aparência do Office e do Microsoft 365 na personalização, se a organização preferir.

A quarta coisa é como e onde você implanta seus artefatos de solução, ou seja, em que CDN estão seus pacotes de script gerados e ativos armazenados. Prontos para uso, nas tarefas do Gulp incluídas na cadeia de ferramentas, apenas o armazenamento de Blobs do Azure e a CDN do Azure têm suporte. Essa pode ser uma boa opção se for possível gerenciar uma assinatura do Azure e compartilhar ativos entre vários locatários. Outro cenário comum é usar o SharePoint Online e seu recurso da CDN como host para os artefatos. Desde a versão 1.4 da Estrutura do SharePoint, os ativos estáticos são, por padrão, fornecidos no pacote da Estrutura do SharePoint. Quando esse pacote é implantado no catálogo de aplicativos, é automaticamente hospedado da CDN do Microsoft 365 (se habilitada) ou da URL do catálogo de aplicativos.

Por fim, os desenvolvedores precisarão pensar no gerenciamento do ciclo de vida do aplicativo (ALM): a maneira como você gerencia o código-fonte e a versão, o build automático, o teste e a implantação e assim por diante. Os sistemas de versão de código-fonte mais comuns podem ser usados, como Git, GitHub ou Visual Studio Team Systems.

Para integração contínua não existem ferramentas padrão e você pode usar a ferramenta de sua preferência que dê suporte a node.js, como Visual Studio Team Systems, Travis CI ou Jenkins. Usando essas ferramentas, você pode automatizar o processo de build e teste e, se houver um build bem-sucedido e aprovado, você pode até mesmo implantar automaticamente os artefatos no local da CDN e, dessa forma, automatizar tudo, desde a verificação do desenvolvedor no código até a implantação para produção.

Recursos de gerenciamento de soluções da Estrutura do SharePoint

Todas as soluções da Estrutura do SharePoint implantadas em um locatário devem ser aprovadas por um administrador locatário. Isso é feito carregando o pacote Estrutura do SharePoint, o arquivo *.sppkg na biblioteca Aplicativos para SharePoint. Quando uma nova solução for adicionada à biblioteca, o administrador receberá uma caixa de diálogo que pede o consentimento para aprovar a solução para uso no locatário. A caixa de diálogo explica que essa é uma solução de código do lado do cliente de confiança total sem restrições de recursos e é executada no contexto dos usuários. A caixa de diálogo também mostra de qual domínio obterá conteúdo principalmente. Essa é a localização da CDN para os scripts da Estrutura do SharePoint. Qualquer aplicativo da Estrutura do SharePoint pode carregar dados de outros locais, após o carregamento inicial da CDN. Uma vez aprovada, a solução da Estrutura do SharePoint pode ser habilitada em qualquer conjunto de sites.

Um administrador do catálogo de aplicativos pode remover o pacote do catálogo de aplicativos a qualquer momento, removendo o pacote de solução da biblioteca de Aplicativos para SharePoint. Isso impedirá que a solução seja usada em todos os conjuntos de sites. A solução também pode ser desabilitada modificando-se a propriedade Enabled do pacote carregado. Isso desabilitará imediatamente a solução em todos os conjuntos de sites. As páginas existentes que estiverem usando web parts do lado do cliente não renderizarão a web part e o aplicativo não estará disponível nos conjuntos de sites nem estará disponível para adição a conjuntos de sites existentes. Ao ser removida uma solução da Estrutura do SharePoint, isso não removerá informações ou dados criados pela solução do lado do cliente real no SharePoint ou em qualquer fonte de dados externa usada pela solução.

O administrador também pode modificar outras propriedades do pacote no catálogo de aplicativos para aprimorar a visibilidade da solução nos conjuntos de sites. Por exemplo, o ícone, a categoria, a descrição e o status em destaque podem ser alterados.

Se houver necessidade de atualizar o pacote da solução, o que será necessário se novos artefatos da Estrutura do SharePoint ou outras alterações de nível de pacote forem feitas, o administrador só precisará carregar uma nova versão do pacote para a biblioteca.

Um administrador de locatário também pode monitorar as soluções da Estrutura do SharePoint, como ocorre com Suplementos do SharePoint. No centro de Administração do SharePoint, em aplicativos, o administrador do SharePoint pode adicionar as soluções Estrutura do SharePoint e ver quantos locais instalados existem para uma solução específica, para Suplementos do SharePoint e soluções da Estrutura do SharePoint.

Para habilitar uma solução da Estrutura do SharePoint em um conjunto de sites, o administrador do conjunto de sites deve adicioná-la ao conjunto de sites. Os procedimentos para os Suplementos do SharePoint são os mesmo. Basta escolher Adicionar um novo aplicativo no conjunto de sites e escolher a solução na lista de aplicativos. Depois que o aplicativo é adicionado, está disponível para uso no conjunto de sites. O administrador do conjunto de sites também pode remover a Estrutura do SharePoint do conjunto de sites. Isso é feito entrando no Conteúdo do Site e escolhendo Remove no aplicativo.

Escopos de implantação da Estrutura do SharePoint

Ao criar as soluções da Estrutura do SharePoint, os desenvolvedores podem escolher se a solução oferecerá suporte à implantação em todo o locatário ou se ela deverá ser implantada em cada site separadamente. A última opção será necessária quando a solução tiver de provisionar recursos adicionais, como listas, depois de ser implantada em um site.

Embora os desenvolvedores que estiverem criando a solução decidam se a solução dará suporte à implantação em todo locatário ou não, são os administradores que tomarão a decisão final sobre como a solução será implantada. Mesmo se uma solução puder ser implantada em todos os sites no locatário, os administradores poderão optar por implantá-lo somente em sites específicos. Se a solução não oferecer suporte à implantação em todo o locatário, os administradores poderão implantá-la somente em sites específicos.

Importante

A implantação em todo o locatário só está disponível no SharePoint Online. No SharePoint hospedado no local, as soluções da Estrutura do SharePoint podem ser implantadas apenas em sites específicos.

O Estrutura do SharePoint não tem um repositório, que os Suplementos do SharePoint têm. Por esse motivo, as implantações sempre devem ser iniciadas pelo administrador de locatário, adicionando e aprovando um pacote de soluções ao Catálogo de Aplicativos.

Fazendo backup e restaurando componentes da Estrutura do SharePoint

As soluções da Estrutura do SharePoint não têm recursos específicos de backup e restauração. A única coisa recomendada de uma perspectiva administrativa é que pode ser uma boa ideia ter uma cópia de todos os arquivos de pacote de solução instalados (*.sppkg), se um pacote de solução for removido por engano do catálogo de aplicativos. No entanto, o catálogo de aplicativos é uma biblioteca do SharePoint e tem os mesmos recursos que qualquer biblioteca de documentos, com o controle de versão principal ativado e a lixeira.

Não é possível fazer backup dos artefatos de solução reais, como pacotes de script e ativos, que são hospedados em uma CDN. Se você tiver controle da CDN ou se a CDN for um site do SharePoint, será possível fazer backup deles. Se você estiver usando soluções da Estrutura do SharePoint fornecidas por terceiros, talvez não exista uma maneira para que sua organização faça backup deles.

Roteiro da Estrutura do SharePoint

A Estrutura do SharePoint atingiu a Disponibilidade Geral (GA) em fevereiro de 2017. Disponibilidade Geral significa que a TI e os desenvolvedores podem usar a Estrutura do SharePoint em produção de uma forma com suporte. Além da Disponibilidade Geral, esperamos que o conjunto de cenários em que componentes baseados na Estrutura do SharePoint são criados e usados se expandirá para além dos cenários de Web Parts e para áreas como personalizações de site e lista.

Saiba mais sobre a Estrutura do SharePoint no Roteiro da Estrutura do SharePoint dedicado.

As alterações importantes ou a introdução de novos recursos principais serão anunciadas pelo Centro de Mensagens do Microsoft 365, encontrado no administrador do locatário. Isso é algo que um administrador do Microsoft 365 já deve verificar como parte de sua rotina diária. Outro recurso importante é o blog do Desenvolvedor do Office onde você encontrará mais detalhes e atualizações.

Suporte e SLA

A Microsoft não oferece suporte para soluções personalizadas criadas para o SharePoint por meio dos canais de suporte regulares do SharePoint Online. Todos os problemas relacionados à criação de soluções do SharePoint devem estar conectados no GitHub na https://github.com/SharePoint/sp-dev-docs/issues . Grupo de engenharia do SharePoint faz a triagem de problemas neste repositório regularmente e se esforça para responder às solicitações de entrada assim que possível.

Se sua organização tiver um contrato de suporte do Premier, ela deve ser o canal padrão para a solicitação de suporte de problemas relacionados à criação de soluções do SharePoint. Os engenheiros de escalonamento da Microsoft lidarão com as solicitações de acordo com sua urgência.

A estrutura do SharePoint pode ser compatível com versões anteriores. A Microsoft garante que as soluções criadas usando qualquer uma das versões geralmente disponíveis do SharePoint Framework continuarão funcionando até que um aviso explícito de depreciação para a versão específica tenha sido fornecido antecipadamente.

Resumo

A Estrutura do SharePoint é uma ótima adição nova e uma evolução da caixa de ferramentas de personalização do SharePoint que permite aos desenvolvedores estender o SharePoint de uma maneira controlável e com suporte. A Estrutura do SharePoint, com base em software livre e tecnologias modernas, permite que os desenvolvedores estendam o desenvolvimento empresarial do SharePoint não apenas para a equipe do SharePoint, mas para incluir um conjunto mais diverso de desenvolvedores. Como administrador, o fornecimento de governança e suporte adequados para a Estrutura do SharePoint no locatário pode capacitar os desenvolvedores a criar soluções mais envolventes com mais rapidez, resultando em maior eficiência geral.

Como a Estrutura do SharePoint foi criada para desenvolvedores internos e de terceiros e seu uso pela Microsoft está se expandindo para aprimoramentos de recursos futuros do SharePoint, também é uma escolha segura para sua organização. Pode esperamos atualizações incrementais e adições à Estrutura do SharePoint ao longo do tempo para eliminar a lacuna de recursos entre o SharePoint clássico e a experiência moderna do SharePoint.