Página 1 de 15
Anexo II C
Extranet Social
PLANEJAMENTO DO
DESENVOLVIMENTO E
INTEGRAÇÕES
Página 2 de 15
Tudo que for diferente do que foi citado nesse documento deverá ser aprovado
pela área de tecnologia do SESC.
As diretrizes básicas são:
1. Procurar sempre utilizar a forma nativa (out-of-box) utilizada no SharePoint. Evitar
customizações que necessitem desenvolvimento através de Visual Studio.
2. O padrão de nomenclatura dos objetos deve seguir as regras de formação de nomes
abaixo:
a. Assemblies: <Company>.<Component>[<Feature>].dll (Exemplo:
SESC.Portal.WebParts.dll)
b. Namespaces: <Company>.(<Product>|<Technology>)[.<Feature>][.<Subnamespace]
(Exemplo: SESC.Portal.WebParts);
3. A Microsoft recomenda que a arquitetura de soluções com até 3 WSP. Dessa forma, o
ideal é que o mais próximo da arquitetura abaixo seja utilizada:
a. 1 WSP contendo objetos de escopo Global (Timer Jobs)
b. 1 WSP contendo objetos de escopo WebApplication (WebParts, EventReceivers,
Workflows, etc.)
c. 1 WSP contendo objetos de framework, classes de negócios e demais componentes
reutilizáveis.
4. Não poderá ser realizada nenhuma alteração diretamente nos arquivos e configurações
presentes no diretório de configuração do SharePoint denominado “15 hive” - C:\Program
Files\Common Files\Microsoft Shared\Web Server Extensions\15. Qualquer alteração no
sistema de arquivos só será permitida através de pacotes WSPs.
5. Toda instalação de objetos customizados (MasterPages, Páginas, Features, Event
Receivers, WebParts, etc.) deve ser realizada através do deploy de pacotes WSPs ou
utilizando PowerShell Scripts de forma automatizada.
Página 3 de 15
6. Para evitar problemas de performance e instabilidade no ambiente, todo assembly
(*.dll) deve ser verificado e aprovado na ferramenta SharePoint Dispose Checker -
http://archive.msdn.microsoft.com/SPDisposeCheck. O relatório não deve ter erros e os
falsos positivos justificados deverão ser justificados.
7. Todo deploy deverá ser feito por funcionário do SESC utilizando um documento
descrevendo o procedimento a ser realizado (manual de instalação). Nenhum fornecedor
poderá ter acesso direto aos servidores para realização de procedimentos.
8. Nenhum arquivo poderá ser instalado diretamente no servidor. Todas as dependências
da aplicação devem ser instaladas através de pacotes WSPs e do modelo de deploy
definido pela Microsoft: http://technet.microsoft.com/en-
us/library/cc262995(v=office.14).aspx.
9. O SharePoint Designer não poderá ser utilizado como ferramenta alternativa ou auxiliar
para deploy. Páginas, Master Pages, CSS e outros arquivos devem estar dentro do pacote
WSP.
10. Preferencialmente todos os objetos da aplicação (Listas, Bibliotecas, Content Types,
etc.) deverão ser criados através de features, Site Definitions, List definitions e outros
objetos relacionados.
11. Para primeira instalação da solução poderá ser utilizada a opção de Backup-Restore
utilizando as ferramentas administrativas do SharePoint.
12. O fornecedor da solução deverá entregar ao final do projeto um Manual do Sistema
descrevendo os componentes da solução como WebParts, Javascripts customizados, Timer
Jobs e em quais partes do sistema eles estão associados.
Empacotamento e Instalação
Como política de controle de componentes desenvolvidos, controle de itens instalados e
capacidade de recuperação em caso de desastres, é vedada a instalação de itens de código
que não estejam empacotados em formato padrão do SharePoint. Instalação de
componentes como DLLs devem estar devidamente empacotadas em formato WSP, bem
como itens de aplicação como SharePoint Designer Workflows, BCS Definitions, Site
Templates, etc.
Procedimentos de configuração de Web.Config deve estar devidamente documentos e
serão aplicados manualmente pelo responsável pela operação do ambiente.
Procedimentos de configuração de serviço que não impactem diretamente na utilização de
recursos que necessitam de planejamento adicional devem ser automatizados via
PowerShell Script e disponibilizado em formato específico desta tecnologia – “PS1”. Todas
as variáveis de ambiente devem ser configuradas em formato de parâmetro para os
scripts de forma que o procedimento possa ser repetido nos ambientes de QA e produção
alterando-se apenas o parâmetro.
● Procedimentos automatizáveis: Configuração de serviço, criação de propriedades,
criação de listas, alteração de componentes de sites, configuração de busca, configuração
de repositório de perfil.
● Procedimentos não automatizáveis: Procedimentos que envolvam a criação de novos
sites/pools no IIS, criação de banco de dados, alteração de cota de disco para aplicações.
Página 4 de 15
Sistemas compostos por DLLs devem sempre ser compilados com suporte à 64 bits e em
modo Release para ambiente de QA e PD.
É vedado qualquer tipo de ajuste de sistema em ambiente de QA já que o mesmo tem o
objetivo de validar não só as funcionalidades do sistema, mas também o procedimento de
publicação. Ajustes de sistema devem ser realizados diretamente em ambiente de DV e
novamente empacotadas para aplicação em QA.
Autenticação
É padrão para aplicações de acesso interno (ambiente intranet) a utilização de
autenticação integrada ao AD via NTLM. Casos específicos devem ser analisados pelo time
de arquitetura.
Integração com sistemas externos
Por padrão, toda comunicação entre sistemas hospedados em ambiente SharePoint e
sistemas externos, seja via comunicação com banco de dados, Web Service ou qualquer
outro método, deve ser realizada via BCS – Business Connectivity Service.
Página 5 de 15
Padrão de autenticação integrada
Todo processo de autenticação integrada de usuários (Single Sign-on) que necessite de
gerenciamento de credenciais (não implementado via ticket) deverá necessariamente fazer
uso do serviço de credenciais do SharePoint (Secure Store Service). Não é permitido o
armazenamento de credenciais de autenticação para acesso à outros sistemas em
qualquer outro repositório (listas, bancos de dados, XML, entre outros).
Arquitetura da Aplicação
De modo geral, o Microsoft SharePoint 2013 é uma plataforma organizacional baseada na
Web para colaboração de negócios e produtividade.
O SharePoint 2013 é construído com base no Microsoft .NET Framework 4.5, ASP.NET,
Internet Information Services (IIS) e banco de dados SQL Server.
Existem duas modalidades do SharePoint 2013, o SharePoint Foundation que constitui a
tecnologia base de todas as aplicações SharePoint. E o SharePoint Server que contém
todos os recursos do SharePoint Foundation, além de outras funcionalidades e capacidades
como gerenciamento de conteúdo corporativo, Business Intelligence, pesquisa corporativa
e perfis pessoais através de Meus Sites.
A solução desenvolvida será implantada em uma Web Application do SharePoint 2013, que
é hospedada em um website no IIS.
Figura 1 - SharePoint Technology Stack
Com a evolução da plataforma Microsoft SharePoint, o seu modelo de customizações foi
drasticamente alterado e permite uma série de variações para atender melhor as soluções
em qualquer tipo de cenário: seja com servidores instalados no ambiente do cliente ou um
ambiente na nuvem (tanto privada quanto compartilhada - Office 365).
Como as possibilidades de customização da plataforma são enormes, cabe ao arquiteto o
trabalho de decidir qual tecnologia utilizar e como otimizá-la para atingir os resultados da
melhor forma possível.
Página 6 de 15
Figura 2 - APIs de Desenvolvimento
Na metodologia deverá ser adotado sempre que possível a utilização de o máximo da
plataforma nativa (Out of the box) do SharePoint, evitando pontos de customização.
Quando é necessária alguma customização, utilizar os códigos server- side para proteger
regras de negócio do lado do servidor e, sempre que possível, utilizar código client-side
para interação com os usuários do sistema.
O grande desafio é escolher a API certa para utilização de acordo com o projeto ou cenário
do cliente. A figura abaixo ressalta que é possível obter os mesmos resultados de forma
diferente. Assim sendo, o desenvolvedor/arquiteto tem mais liberdade de poder escolher a
ferramenta que ao mesmo tempo consiga elevar a produtividade e atender os requisitos
específicos de cada cliente.
Figura 3 - Tipos de APIs
Página 7 de 15
Aplicar as metodologias de desenvolvimento de mercado para padronização e organização
de código-fonte para gerar um código de qualidade e um produto que atenda aos critérios
de carga da aplicação.
Além de o SharePoint possuir uma grande variedade de APIs para sua customização, ele
disponibiliza serviços para que qualquer operação que você consiga fazer via browser
também seja possível ser executada através dessas “APIs de integração”.
Dessa forma, o SharePoint cria um proxy que faz a tradução das operações e as executa
internamente. Essas operações incluem: gerenciar listas (criar, editar e excluir itens),
gerenciar o site, consumir algum serviço (search, managed metadata) e etc.
Figura 4 - Client APIs
Sendo assim, recomendamos que as funcionalidades sejam desenvolvidas da seguinte
maneira:
1. Sempre que possível usar o nativo (podendo customizar look and feel)
2. Interações com objetos Client deverão ser feitos por Javascript (ou bibliotecas: JQuery,
etc.).
3. Códigos Server-Side devem ser na linguagem C#, utilizando o Server Object Model do
SharePoint.
Estrutura do Site
Página 8 de 15
Parte da metodologia do desenho de uma solução tecnológica consiste em montar uma
arquitetura técnica dos objetos que fazem parte do portal, dentre eles: Listas, Bibliotecas,
Páginas, Repositório de imagens e etc. Esse detalhamento, além dos tipos de containers,
descreve detalhamento cada tipo de coluna, seus valores possíveis e tipos de dados. Esses
dados estão disponíveis no documento Sesc Intranet - Detalhamento de listas e
bibliotecas.
Página 9 de 15
Além do detalhamento de toda estrutura do site, a metodologia deverá contemplar a
criação de um wireframe navegável. Esse wireframe é um protótipo visual que permite ao
usuário a compreensão de como o sistema ficará quando pronto.
Informações Gerais
A aplicação deverá prever a utilização em formato HTTPS, através de certificado digital de
responsabilidade do SESC.
A solução deverá utilizar/prever alguma forma de coleta de métricas de utilização do
sistema. Recomendamos que a solução principal para esse requisito seja a utilização do
Google Analytics.
Integrações
A intranet prevê integrações com as seguintes fontes:
● Datasul
● Sistema de Pontos
● Videos
● Youtube
● Sistema de Mapas
Datasul
É o sistema que contém as informações referentes ao cadastro de fornecedores e o perfil
dos usuários. A versão do sistema é o TOTVS 11 e o Banco de dados é o Progress 10.2B.
Para a funcionalidade de licitações, será necessário que o DATASUL disponibilize alguma
forma de integração que contenha os dados abaixo:
Abaixo, print do módulo de compras (EMS2) com o campo que contém a restrição
(solicitada pelo jurídico).
Página 10 de 15
O sistema deve prever um recurso de sincronização que rodará diariamente lendo as
informações do Datasul e gravando no UserProfile, com base no login do usuário que vem
do AD.
Para o Perfil, os dados abaixo deverão ser disponibilizados pelo DATASUL:
Perfil
Os campos Ramal e Celular corporativo não estão disponíveis no sistema e, portanto, TI
proverá uma tabela para importação desses campos, veja tela do sistema abaixo que
mostra somente os contatos pessoais:
Página 11 de 15
Formação
Abaixo, estão os prints do sistema atual com as informações do Perfil e o detalhamento da
formação.
Página 12 de 15
Página 13 de 15
Sistema de Pontos
O sistema de pontos foi desenvolvido na plataforma ASP.NET (WebForms) e os dados são
armazenados em um banco de dados SQL Server.
Uma interface de integração deverá ser disponibilizada com as informações abaixo.
Somente os registros do próprio profissional deverão ser exibidos. Na fase de
desenvolvimento, deverá ser estabelecido se haverá integração para realização do ponto,
através da intranet, o que resultará na necessidade de disponibilização de uma integração
do tipo Leitura/Escrita.
Além disso, será necessário a disponibilização de uma interface para gerar relatórios com
dados do usuário logado.
Página 14 de 15
Videos
Os videos serão armazenados em um outro sistema, fora do servidor do SharePoint e
apenas o "EMBED" será disponibilizado na ferramenta.
Youtube
É necessário a utilização de alguns vídeos do youtube no portal e, para isso, serão
adicionados no modelo de EMBED.
Sistema de Mapas
A ferramenta deverá prever integração com uma plataforma de Mapas (Bing Maps ou
Google Maps) para mostrar as informações das unidades. Como o SharePoint possui uma
integração nativa om o Bing, recomenda-se a utilização dessa plataforma.
Algumas notícias da intranet poderão ser compartilhadas com o Facebook. Para isso, o
conteúdo precisará, antes, ser replicado em uma área isolada e pública. Dessa forma, o
link da notícia nessa área que será publicado no Facebook.
Deve existir um mecanismo de replicação das notícias que o usuário escolher e quando as
mesmas forem editadas ou excluídas da intranet, o mesmo comportamento aconteça
nessa área isolada destinada às notícias publicadas no Facebook.
Tal funcionalidade será disponibilizada em uma URL que será definida pela equipe do SESC
no tempo de desenvolvimento do projeto, entretanto ficará no mesmo servidor do Portal.
Essa seção não deve ser indexada, de forma que seja tratada como uma área
completamente isolada do Portal.
Serviços utilizados
Está previsto na solução a utilização dos seguintes serviços do SharePoint:
● Search
● Managed Metadata Services
● User Profile Services
● Business Data Catalog
Browsers Suportados
A Microsoft melhorou bastante a quantidade de browsers suportados e reduziu a
quantidade de recursos que dependem exclusivamente do Internet Explorer.
Na tabela abaixo listamos todos os browsers compatíveis com o SharePoint 2013.
Página 15 de 15
Entretanto, alguns recursos Active X podem não funcionar em todos os browsers. Para
mais detalhes sobre isso, consultem o link da documentação oficial da Microsoft em Plano
de suporte do navegador no SharePoint 2013.