Anexo II C Extranet Social PLANEJAMENTO DO DESENVOLVIMENTO E INTEGRAÇÕES Página 1 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 2 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/enus/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 3 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 4 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 5 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 6 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 7 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 8 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 Facebook 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 9 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 10 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 11 de 15
Página 12 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 13 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. Facebook 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 14 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. Página 15 de 15