novo portal sesc rio planejamento do … · página 3 de 16 12. o fornecedor da solução deverá...
TRANSCRIPT
Página 1 de 16
Anexo II D
Novo Portal Sesc Rio
PLANEJAMENTO DO
DESENVOLVIMENTO E
INTEGRAÇÕES
Página 2 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/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.
Página 3 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 4 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 5 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 6 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 7 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 8 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
● 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 9 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 10 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 11 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 12 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 13 de 16
Aulas e Cursos:
Página 14 de 16
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.
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 15 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 16 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.