PLANEJAMENTO DO DESENVOLVIMENTO E INTEGRAÇÕES

Anexo II D Novo Portal Sesc Rio PLANEJAMENTO DO DESENVOLVIMENTO E INTEGRAÇÕES Página 1 de 16

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 devem 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. 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. Página 2 de 16

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. 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. 7 Página 3 de 16

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. 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 Página 4 de 16

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. 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 for 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, utilizamos 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. Página 5 de 16

Figura 3 - Tipos de APIs 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. Página 6 de 16

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 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 contâiners, descreve detalhamento cada tipo de coluna, seus valores possíveis e tipos de dados. Esses dados estão disponíveis no documento Sesc Portal - Detalhamento de listas e bibliotecas. Além do detalhamento de toda estrutura do site, a metodologia da contempla 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. Página 7 de 16

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 O portal prevê integrações com as seguintes fontes: CtrlPAE / SAE Facebook Instagram Youtube Intranet CtrlPAE / SAE CtrlPAE (Controle de Programação Atividades e Eventos) é o sistema interno que contém informações sobre os eventos do SESC. A Base de dados está no formato SQL Server. As informações relativas às atividades assistemáticas e sistemáticas são gerenciadas por esse sistema, entretanto, todas as programações oferecidas pelo SESC devem estar cadastradas no CtrlPAE. O Sesc possui também o Sistema de Atividades Esportivas (SAE) que controla as inscrições dos alunos nas modalidades esportivas oferecidas pelo Sesc Rio. Desta forma, em relação as atividades esportivas, haverá duplicidade de informação, devendo o responsável pela publicação deste conteúdo no Portal fazer este filtro antes da publicação. As informações de esporte para publicação no Portal deverão ser retiradas do sistema SAE por possuir todas as informações necessárias. As informações deverão ser consumidas conforme descrito no detalhamento abaixo, as demais informações de atividades que não estão no CtrlPAE / SAE, serão gerenciadas e cadastradas diretamente no SharePoint conforme a Especificação Funcional. SAE é o Sistema de Atividade Esportivas, que contém os detalhes das programações. Esse sistema é responsável pelos dados das programações sistemáticas referentes à modalidade esportiva, e contém os dados abaixo: As demais informações que não estão no SAE, serão gerenciadas e cadastradas diretamente no SharePoint conforme a Especificação Funcional. Página 8 de 16

O sistema SAE disponibilizará um WebService para essas informações e atualmente encontra-se em desenvolvimento. A query abaixo foi utilizada, como exemplo, para extração e demonstração dos dados que serão apresentados no WebService do SAE. SELECT DISTINCT CE.Des_Nom_Unidade, CM.Des_Nom_Modalidade, CF.Des_Nom_Faixa_Etaria, dbo.retornadiassemanaporturma(ct.cod_num_turma) AS DIAS, CA.Hor_Inicio_Aula, CA.Hor_Fim_Aula, 14 Página 9 de 16

CTR.Val_Mensalidade, CTR.Dat_Ini_Tarifario, CTR.Nom_Categoria, CTR.Cod_Num_Categoria FROM CURSO_ESTABELECIMENTO CE INNER JOIN CURSO_TURMA CT ON CT.Cod_Num_Unidade = CE.Cod_Num_Unidade INNER JOIN CURSO_MODALIDADE CM ON CT.Cod_Num_Modalidade = CM.Cod_Num_Modalidade INNER JOIN CURSO_FAIXA_ETARIA CF ON CF.Cod_Num_Faixa_Etaria = CT.Cod_Num_Faixa_Etaria INNER JOIN CURSO_AULAS CA ON CA.Cod_Num_Turma = CT.Cod_Num_Turma INNER JOIN CURSO_TARIFARIO CTR ON CTR.Cod_Num_Modalidade = CM.Cod_Num_Modalidade WHERE CTR.Dat_Ini_Tarifario = '2013-07-16 00:00:00.000' AND CT.Sta_Turma = 'AT' AND CTR.Cod_Num_Categoria IN (00,70) ORDER BY CE.Des_Nom_Unidade, CM.Des_Nom_Modalidade Para as atrações Não-sistemáticas (Shows, Teatro, etc.), os dados são provenientes do CtrlPAE. Utilizando a Query abaixo, conseguimos extrair os campos da revista para alimentar as listas referentes a esse tipo de atração no SharePoint. SELECT DISTINCT B.PROG_NM_PROGRAMACAO,B.PROG_DT_INICIAL,B.PROG_DT_FINAL,A.TEPR_DT_EXECUCAO,A.TEPR_HR_INICIAL,A.TEPR_HR_FINAL,F.TUNI_NM_UNIDADE,C.TLOC_NM_LOCAL,D.TPPU_VL_PRECO,E.TPUB_NM_PUBLICO 15 Página 10 de 16

,B.NM_FAIXA_ETARIA,B.CD_CATEGORIA_REVISTA,B.NM_DESCRICAO_REVISTA,B.NM_OBS_REVISTA,B.DT_REVISTA_EDITOR,B.DT_REVISTA_REVISOR,H.TEVE_CD_EVENTO FROM CPAE_TEXECUCAO_PROGRAMACAO A INNER JOIN CPAE_TPROGRAMACAO B ON A.PROG_CD_PROGRAMACAO = B.PROG_CD_PROGRAMACAO INNER JOIN CPAE_TLOCAL C ON A.TLOC_CD_LOCAL = C.TLOC_CD_LOCAL INNER JOIN CPAE_TPROG_PUBLICO D ON A.PROG_CD_PROGRAMACAO = D.PROG_CD_PROGRAMACAO INNER JOIN CPAE_TPUBLICO E ON D.TPUB_CD_PUBLICO = E.TPUB_CD_PUBLICO INNER JOIN CPAE_TUNIDADE F ON C.TUNI_CD_UNIDADE = F.TUNI_CD_UNIDADE LEFT JOIN CPAE_TUSUARIO G ON B.TUSU_CD_USUARIO = G.TUSU_CD_USUARIO LEFT JOIN ENT_TEVENTO H ON G.TPER_CD_PERFIL = H.TPER_CD_PERFIL WHERE TEVE_CD_EVENTO = 6 Programações com um dos campos abaixo preenchidos são da Revista, e por conseguinte são assistemáticas. B.CD_CATEGORIA_REVISTA B.NM_DESCRICAO_REVISTA B.NM_OBS_REVISTA B.DT_REVISTA_EDITOR B.DT_REVISTA_REVISOR Esses campos são: Página 11 de 16

Para cada tipo de público, será gerado um registro novo, repetindo todos os dados e alterando apenas as colunas Tipo de Público e Valor. As informações serão apenas consumidas e disponibilizadas no portal, ou seja, não existirá uma interface para gravar dados nesses sistemas. Todas as alterações necessárias serão feitas no SharePoint. Além disso, deverá existir um tratamento dos dados provenientes do SAE e do CtrlPAE para que seja feito um MERGE e disponibilizado na estrutura que o SharePoint espera receber essas informações. Por questões de carga e quantidades de acesso, é recomendável a replicação somente dos eventos aprovados para uma base de dados isolada para ser consumida pelo portal do SharePoint. Para eventos, aulas e cursos, a estrutura prevista do SharePoint precisará receber as informações abaixo. Caso alguma das informações necessárias para o funcionamento do sistema não esteja disponível no CtrlPAE / SAE, ele deverá fornecer o máximo que contiver ou o SESC deverá prover alguma alternativa para alimentação desses dados. Eventos Página 12 de 16

Aulas e Cursos: Página 13 de 16

Facebook Será utilizado para compartilhamentos, seguidores e comentários. Todas essas informações serão tratadas pelo Facebook e nenhuma informação ficará disponível no portal. Instagram A integração com o Instagram está prevista para exibição de imagens em algumas áreas do portal. Youtube É necessário a utilização de alguns vídeos do youtube no portal e, para isso, eles serão adicionados no modelo de EMBED. Intranet O portal precisa consumir algumas informações da Intranet. Dentre elas: Página 14 de 16

Licitações Arquivos das Licitações Central de Relacionamento com o Público A página de Fale Conosco que contém o Formulário de Contato deve apresentar um formulário adicionado no modelo de EMBED da Central de Relacionamento com Público, que deverá atender pessoas físicas e jurídicas, contendo características específicas no formulário para cada público de acordo com a opção a ser selecionada pelo usuário. Em relação ao Chat online, ao clicar um pop-up com a identidade visual do Portal será acionado e este serviço também será fornecido pela Central de Relacionamento com o público. 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 Página 15 de 16

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. 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. Autenticação dos Usuários Como é um portal público, todas as áreas serão configuradas para permitir acesso anônimo. Entretanto, o sistema deverá prever uma área administrativa isolada, autenticada utilizando usuário do AD do Sesc para manutenção do portal e de seu conteúdo. Essa área poderá ser publicada para que colaboradores do SESC possam fazer essa manutenção remotamente. Página 16 de 16