Por dentro do SharePointEnterprise Project Management com SharePoint

Pav Cherny

Código disponível para download em: ChernySharePoint2008_12.exe(959 KB)

Sumário

Arquitetura do Project Server
Integração com o SharePoint
Implantações de farms de servidores
Bem-vindo ao IIS 7
Permissões em sessão de banco de dados
Permissões de serviços compartilhados
Firewall do Windows
Serviços do MOPS e contas de serviço
Integração com Analysis Services
Conclusão

Que tecnologias do SharePoint são ideais para você? No afã de encontrar a resposta, é provável que você tenha examinado uma lista aparentemente interminável de categorias, como Colaboração e Computação Social, Portais, Enterprise Search, Gerenciamento de Conteúdo Corporativo, Processos Empresariais e Formulários, Business Intelligence e Recursos em Plataforma para Desenvolvedores, e comparou os recursos disponíveis no Windows SharePoint Services (WSS) 3.0, Microsoft Office Search Server 2008 Express, Microsoft Office Forms Server 2007 e Microsoft Office SharePoint Server (MOSS) 2007. No entanto, existe uma tecnologia que talvez você não tenha considerado, porque a Microsoft não a relaciona sob a categoria Produtos e Tecnologias do SharePoint: Enterprise Project Management (EPM), que é habilitada através do Microsoft Office Project Server (MOPS) 2007.

Mas o MOPS 2007 é uma tecnologia do SharePoint; ele foi baseado no WSS 3.0 e o estende de uma maneira comparável ao MOSS 2007. O MOPS 2007 é a escolha certa se você deseja aumentar a eficiência da colaboração em equipe dentro e entre departamentos através do gerenciamento do trabalho, de recursos e do orçamento para além dos recursos básicos de gerenciamento de tarefas do WSS 3.0 e do MOSS 2007. Com o MOPS, você pode transformar sites de equipes em espaços de trabalho de projetos, gerenciar a colaboração em equipe dentro e entre departamentos e estabelecer uma base sólida de EPM para uma organização inteira. Todavia, primeiro você precisa vencer os desafios da implantação.

Nesta coluna, eu discuto a implantação do MOPS 2007 em um ambiente Windows Server 2008 com SQL Server 2005 SP2 e WSS 3.0 SP1. Primeiro, faço uma rápida análise da arquitetura do MOPS para mostrar de que maneira os componentes se integram ao WSS 3.0 do ponto de vista de um arquiteto de sistemas. Essa informação ajuda a acompanhar a próxima discussão, que aborda os desafios típicos de implantação e integração com os quais você poderá se deparar, como problemas de configuração do pool de aplicativos, permissões de acesso não encontradas, erros na fila de inicialização do sistema e problemas relacionados ao SQL Server 2005 Analysis Services.

Para ilustrar as etapas de implantação e solução de problemas, eu uso um ambiente de teste básico com dois servidores WSS 3.0 em um farm de servidores, um controlador de domínio dedicado e um computador à parte executando o SQL Server, semelhante ao ambiente de teste que venho usando até agora para esta coluna do SharePoint. Você encontra as planilhas correspondentes, com instruções passo a passo, no material complementar desta coluna, disponível no site da TechNet Magazine.

Arquitetura do Project Server

O MOPS 2007 é um dos aplicativos mais avançados e complexos do SharePoint. Ele aproveita a plataforma WSS 3.0 ao máximo para oferecer administração centralizada, provisionamento de sites, autenticação e segurança. O aplicativo também adiciona outros componentes, como 25 Web Parts gerais e especializadas do MOPS e um novo conjunto de até quatro bancos de dados MOPS por site do Project Web Access (PWA). Cada um é acessado através de um conjunto de 21 Web Services públicos e internos do MOPS que juntos formam a Interface do Project Server (PSI), como ilustrado na Figura 1. Você encontra mais detalhes sobre os Web Services do MOPS no MSDN.

Figura 1 Integração do SharePoint com o MOPS 2007 (clique na imagem para ampliá-la)

A arquitetura do MOPS 2007 utiliza uma série de componentes distribuídos entre estações de trabalho cliente, servidores de aplicativos e servidores de bancos de dados. Nesta coluna, analiso os mais importantes entre esses componentes, mas se você estiver interessado em todos os detalhes técnicos leia a documentação "Arquitetura do Project Server" no SDK do Project 2007.

Quando ler o SDK, apenas se lembre de que as Web Parts do PWA e o Microsoft Office Project Professional 2007 não acessam os Web Services da PSI diretamente. O SDK sugere que os clientes façam chamadas diretas para a PSI, mas na verdade a maioria dos aplicativos usam o PSI Forwarder, que é um componente de sites do PWA que fornece acesso indireto aos Web Services da PSI. Apenas componentes baseados em servidor, como os serviços de Fila e de Eventos, executados com permissões do nível de sistema fazem chamadas diretas à PSI. É importante lembrar deste pequeno detalhe em situações de solução de problemas por vários motivos, especificamente estes:

• Os sites do PWA definem o contexto de banco de dados (cada site do PWA tem bancos de dados Rascunho, Publicado, Arquivo Morto e Relatório separados) e permissões de usuário, mas as contas de usuário comuns não recebem acesso aos Web Services da PSI.
• O PSI Forwarder não dá suporte à representação e usa a conta do pool de aplicativos do site do PWA para acessar os Web Services da PSI em nome dos usuários.
• As chamadas à PSI não necessariamente usam os Web Services da PSI local se o farm inclui várias instâncias de servidor de aplicativos.

Integração com o SharePoint

Agora vamos analisar mais de perto a integração propriamente dita do MOPS com o SharePoint. Do ponto de vista de um administrador do SharePoint, o MOPS é um aplicativo Web compartilhado gerenciado como um serviço de farm na Administração Central do SharePoint 3.0. Isso é relativamente básico para um administrador familiarizado com os Provedores de Serviços Compartilhados (SSPs) do MOSS 2007.

Mas se você é um administrador do WSS 3.0 e novato em administração de SSP, consulte a planilha "Implantando o Project Server 2007", disponível no material complementar, para obter instruções passo a passo de como criar e configurar serviços compartilhados de um farm do SharePoint e sites do PWA. Após a instalação e a configuração do MOPS, você poderá analisar a implementação do sistema no Gerenciador do IIS. Conforme ilustrado na Figura 2, você deverá ver sites separados para serviços compartilhados, administração de SSP e conjuntos de sites em um servidor de aplicativos do MOPS.

Figura 2 Acesso ao Project Server 2007 através do PWA e do PSI Forwarder (clique na imagem para ampliá-la)

Os clientes acessam os Web Services da PSI pelo diretório virtual _vti_bin/PSI em um site do PWA. Entretanto, os Web Services da PSI não residem nesse diretório virtual. O diretório virtual _vti_bin/PSI mapeia para o seguinte caminho físico: %COMMONPROGRAMFILES %\Microsoft Shared\Web Server Extensions\12\ISAPI\PSI. Você perceberá que esse diretório contém um arquivo web.config que especifica em uma seção <httpHandlers> que todas as solicitações HTTP de arquivos *.asmx (ou seja, Web Services baseados em ASP.NET) devem ser passadas para um manipulador HTTP personalizado, instanciado através de Microsoft.Office.Project.Server.PSIForwarderHandlerFactory.

Esse manipulador HTTP personalizado é o PSI Forwarder. O PSI Forwarder estabelece uma nova conexão HTTP com os Web Services da PSI, encaminha a solicitação HTTP do cliente e retorna os resultados para o cliente.

Os Web Services da PSI estão disponíveis para o PSI Forwarder via HTTP através do diretório virtual PSI do aplicativo Web dos Serviços Compartilhados, que fica hospedado no site de Web Services do Office Server. Por padrão, esse diretório virtual mapeia para o caminho físico %PROGRAMFILES %\Microsoft Office Servers\12.0\WebServices\Shared\PSI, onde você encontra os arquivos *.asmx do MOPS 2007.

Falarei sobre o site de Web Services do Office Server mais adiante; por ora, a lição mais importante que podemos tirar da Figura 2 é que o PSI Forwarder se comunica com os Web Services da PSI utilizando a identidade da conta do pool de aplicativos Web do site do PWA em vez do usuário que está acessando o site do PWA.

Implantações de farms de servidores

O PSI Forwarder também desempenha um papel importante em implantações de farms de servidores que usam servidores front-end da Web e servidores de aplicativos separados para aumentar a escalabilidade e a disponibilidade do sistema. Um servidor front-end do MOPS é um servidor WSS 3.0 que não hospeda os Web Services da PSI ou outros serviços do MOPS (como os serviços de Fila e de Eventos), mas dá acesso para os clientes a sites do PWA, que incluem o PSI Forwarder, como ilustrado na Figura 3.

Figura 3 Um farm de servidores de porte médio do MOPS 2007 (clique na imagem para ampliá-la)

Por outro lado, um servidor de aplicativos é um servidor WSS 3.0 que tem instalado todo o conjunto de componentes e serviços do MOPS. Servidores de aplicativos podem hospedar sites do PWA, mas frequentemente eles só fornecem serviços back-end para servidores front-end e não executam o serviço Aplicativo Web do WSS. Você escolhe a função de servidor durante a instalação do MOPS.

A Figura 3 mostra a configuração de um farm de servidores de médio porte. É possível adicionar mais servidores front-end para aumentar a escalabilidade, além de servidores de aplicativos para ter maior disponibilidade, dependendo das necessidades da sua organização. Não é preciso configurar um cluster de balanceamento de carga para servidores de aplicativos MOPS, pois o PSI Forwarder automaticamente faz o balanceamento de carga das solicitações da PSI quando há vários servidores de aplicativos do MOPS no farm de servidores. Para obter informações detalhadas sobre as opções de implantação do MOPS, consulte o "Guia de Implantação do Office Project Server 2007".

Bem-vindo ao IIS 7

Chega de teoria! Vamos atacar alguns problemas reais que você pode encontrar durante a implantação do MOPS 2007. Um dos meus problemas favoritos tem a ver com conjuntos de sites do PWA nomeados por host. Neste cenário, você implanta o MOPS com êxito, configura o SSP, provisiona um site do PWA em um modo de cabeçalho de host informando a URL completa do PWA (por exemplo, pwa) depois de marcar a caixa de seleção Usar caminho do Project Web Access como cabeçalho do host na página Criar Site do Project Web Access. Em seguida, após todos os recursos serem devidamente provisionados, você tenta abrir o site, mas, em vez do PWA, aparece a tela padrão de Boas-vindas do IIS 7.

Isso é o que acontece quando o Site Padrão não é estendido pelo SharePoint e não existe outro site com uma ligação de site apropriada para a URL do PWA. Sem uma ligação de site explícita, o IIS associa a solicitação pwa ao Site Padrão não estendido, por isso você vê a tela de boas-vindas. Talvez você esperasse que a Administração Central do SharePoint 3.0 adicionasse a ligação exigida ao aplicativo Web do SharePoint selecionado para hospedar o site do PWA, mas isso não acontece.

Para resolver este problema, você deve estender o Site Padrão com o SharePoint e usar esse conjunto de sites para provisionar sites do PWA, conforme descrito na planilha complementar Solucionando problemas do IIS e do PWA. Se preferir, você pode adicionar manualmente essa ligação de site não encontrada no Gerenciador do IIS ao aplicativo Web selecionado para PWA. Não se esqueça de executar esta etapa em todos os servidores WSS que hospedam o site do PWA.

Permissões em sessão de banco de dados

Se você optar por estender o Site Padrão, não deixe de usar uma conta de domínio para o pool de aplicativos — consulte "Plano de contas administrativas e de serviço (Office SharePoint Server)" — do contrário, terá problemas relacionados a permissão depois de provisionar sites do PWA, que geralmente se manifestam em uma mensagem de erro do SharePoint pouco informativa, como a exibida na Figura 4.

Figura 4 Erro ao acessar o banco de dados do SSP (clique na imagem para ampliá-la)

Para obter informações mais pertinentes, consulte os logs de rastreamento disponíveis no diretório %COMMONPROGRAMFILES %\Microsoft Shared\Web Server Extensions\12\LOGS. Essa tarefa pode ser cansativa se o seu farm tem vários servidores front-end da Web com balanceamento de carga.

Para fins de solução de problemas, é uma boa prática alterar o registro DNS do nome de host do PWA e apontá-lo temporariamente para um único servidor front-end. Dessa forma, você sabe qual servidor processa as solicitações de cliente e só precisa verificar os arquivos de log de rastreamento daquele servidor.

Abra o arquivo de log mais recente no Bloco de Notas e procure a entrada "Não é possível abrir o banco de dados". Se encontrá-la, você saberá que está com um problema de permissões de banco de dados. O log de rastreamento da Figura 4, por exemplo, mostra que a conta LITWARE\WSS02$ não tem acesso ao banco de dados SharedServices1_DB. Esse é um indicador claro de que o site do PWA está sendo executado com uma identidade do Serviço de Rede.

LITWARE\WSS02$ é a conta do computador do servidor front-end da Web e SharedServices1_DB, o banco de dados do Provedor de Serviços Compartilhados. Entre outras coisas, os servidores front-end da Web usam esse banco de dados para fazer a manutenção dos dados de Estado de Sessão do ASP.NET na tabela ASPStateTempSessions, mas LITWARE\WSS02$ não tem acesso a ele.

É importante observar que você deve incluir o banco de dados do Provedor de Serviços Compartilhados nas atividades de manutenção semanal do banco de dados para assegurar o desempenho estável do sistema. Por exemplo, você deve remover dados de estado de sessão vencidos da tabela ASPStateTempSessions usando o comando TRUNCATE TABLE ASPStateTempSessions do SQL, conforme documentado em "Implantar o Project Server 2007 em um ambiente de farm de servidores".

Os problemas de configuração relacionados ao Serviço de Rede podem ser confusos, por isso vou analisá-los mais detalhadamente. As contas de domínio (como LITWARE\SspConfigAdmin) funcionam para pools de aplicativos em farms de servidores porque elas são exatamente iguais em todos os computadores. Por sua vez, a conta Serviço de Rede (NT AUTHORITY\NETWORK SERVICE) é diferente em cada computador. Em um servidor front-end chamado wss02.litware.com, a conta NT AUTHORITY\NETWORK SERVICE é convertida em LITWARE\WSS02$. Porém, em um servidor chamado sql01.litware.com, a conta NT AUTHORITY\NETWORK SERVICE se refere a LITWARE\SQL01$. É aí que está o problema.

Se você examinar as permissões do SQL Server para SharedServices1_DB no SQL Server Management Studio, verá que a conta NT AUTHORITY\NETWORK SERVICE tem permissões db_owner em uma tentativa de conceder a pools de aplicativos que usam a conta Serviço de Rede acesso ao banco de dados do Provedor de Serviços Compartilhados. Mas lembre-se de que isso só funciona para instalações feitas em um único servidor.

Para corrigir as atribuições de permissão, conceda explicitamente a LITWARE\WSS02$ e a todas as outras contas do servidor WSS (talvez LITWARE\WSS01$ e assim por diante) permissões db_owner para SharedServices1_DB, mas é melhor usar contas de domínio para pools de aplicativos, de forma que todos os servidores front-end utilizem a mesma identidade à qual o SharePoint concedeu as permissões de banco de dados necessárias.

Permissões de serviços compartilhados

Se o pool de aplicativos do seu site do PWA usar a conta Serviço de Rede por algum motivo, você também terá problemas de permissão relacionados ao SSP. Você lembra que eu disse que o PSI Forwarder acessa os Web Services da PSI em nome do usuário no contexto da conta do pool de aplicativos de sites do PWA? Se essa conta não tiver permissões para acessar o site de Web Services do Office Server, você voltará à estaca zero, com a mensagem de erro costumeira do SharePoint. Desta vez, o log de rastreamento no servidor front-end informa que "Falha na solicitação, com o status HTTP 401: Não autorizado", como mostra a Figura 5.

Figura 5 Falha na solicitação, com o status HTTP 401: Não autorizado (clique na imagem para ampliá-la)

Lembre-se de que este erro não se refere a permissões de usuário no PWA. As permissões do SharePoint concedidas em um site do PWA determinam que usuários podem acessar o subdiretório virtual _vti_bin/PSI do site, mas esses usuários não recebem permissões de acesso ao aplicativo Web de Serviços Compartilhados nem aos Web Services da PSI no servidor de aplicativos.

Mesmo que você seja o administrador de um conjunto de sites do PWA, ainda assim ocorrerá uma falha no MOPS se a conta do pool de aplicativos do site do PWA não tiver acesso aos Web Services da PSI. Isso ocorre especificamente quando você ignora a recomendação de usar contas de domínio para pools de aplicativos em um farm de servidores e, no lugar dela, utiliza a conta Serviço de Rede.

Para verificar as permissões de acesso do SSP no servidor de aplicativos, consulte o arquivo web.config no diretório raiz do site de Web Services do Office Server (por padrão, %PROGRAMFILES%\Microsoft Office Servers\12.0\WebServices\Root). Você verá a entrada NT AUTHORITY\NETWORK SERVICE na seção <authorization>, que deve autorizar pools de aplicativos que usam a conta Serviço de Rede. Mas novamente ela não executa a tarefa, pois a entrada só se refere ao computador local, que não é o servidor front-end.

A melhor estratégia é alterar a configuração do pool de aplicativos e usar uma conta de domínio. Mas, se você insistir em usar a conta Serviço de Rede, deverá autorizar as contas do servidor front-end explicitamente.

Não edite o arquivo web.config no servidor de aplicativos diretamente, pois, do contrário, o SharePoint substituirá as alterações. Em vez disso, use a Administração Central do SharePoint 3.0 para conceder as permissões que estão faltando, como descrito na planilha "Testando permissões de acesso do Provedor de Serviços Compartilhados". Verifique também a configuração usando um aplicativo ASP.NET simples que estabeleça uma conexão HTTP direta com os Web Services da PSI, como SSPCheck (incluso no material complementar). Só não se esqueça de executar o aplicativo de teste ASP.NET no pool de aplicativos do site do PWA para obter resultados confiáveis.

Firewall do Windows

A esta altura, é grande a probabilidade de que você consiga abrir o PWA — a menos, é claro, que esteja tentando acessá-lo através de um servidor front-end da Web e o Firewall do Windows no servidor de aplicativos do MOPS bloqueie as portas TCP 56737 e 56738. Essas são as portas padrão atribuídas ao site de Web Services do Office Server para comunicação HTTP e HTTPS.

O SharePoint não abre essas portas automaticamente no servidor de aplicativos do MOPS durante a criação do site de Web Services do Office Server. Se o Firewall do Windows estiver habilitado no servidor de aplicativos, crie uma regra de firewall manualmente que permita o tráfego para essas portas de maneira que os servidores front-end possam acessar os Web Services da PSI. Se um firewall bloquear essas portas, você receberá a mensagem de erro exibida na Figura 6, e o log de rastreamento do servidor front-end informará que o "host conectado não respondeu".

Figura 6 O Project Web Access não pode conectar-se ao Project Server (clique na imagem para ampliá-la)

Serviços do MOPS e contas de serviço

Depois de resolver os problemas de comunicação entre front-end/back-end, você deve conseguir acessar o Project Web Access. Parabéns! Agora é hora de se concentrar em um problema mais complexo específico do MOPS. Respire fundo e abra o log de eventos do aplicativo no servidor de aplicativos do MOPS, mas não se espante se vir milhares e milhares de mensagens de erro informando que "O sistema de fila não pode ser iniciado", como ilustra a Figura 7. Você também deve perceber que os serviços do MOPS geram utilização de CPU próxima dos 100%.

Figura 7 O sistema de fila não pode ser iniciado (clique na imagem para ampliá-la)

O sistema de fila é a base da infraestrutura de aplicativos do MOPS para processar solicitações de atualização e inserção de banco de dados, executar tarefas de limpeza e manutenção e atualizar o banco de dados Relatório para uso em tarefas de análise de dados. Isso é explicado detalhadamente no artigo "Sistema de enfileiramento do Microsoft Office Project Server 2007". Segundo esse artigo, o sistema de fila conta com um serviço do Windows, implementado no assembly Microsoft.Office.Project.Server.Queuing.exe e executado sob a identidade da conta do serviço de administração de configuração e timer do SharePoint para acessar o banco de dados de configuração do farm.

Na inicialização, o serviço do Windows recupera a lista de todos os SSPs do banco de dados de configuração, inclusive as contas de administrador de SSP correspondentes e suas senhas criptografadas, e então inicia um processo Microsoft.Office.Project.Server.Queuing.exe adicional para cada SSP associado a sites do PWA no contexto da conta de administrador de SSP correspondente. Em outras palavras, Microsoft.Office.Project.Server.Queuing.exe inicia várias instâncias de si mesmo sob diferentes contas, por isso o total de processos Microsoft.Office.Project.Server.Queuing.exe em execução em um servidor de aplicativos do MOPS é igual ao número de SSPs mais um.

As instâncias de processos adicionais são os processos de trabalho de fila. Cada processo de trabalho de fila adicional determina seu próprio conjunto de sites do PWA com base no SSP associado, inicia threads de sondagem separados para cada site do PWA e começa a processar as tarefas enfileiradas para os bancos de dados de sites do PWA correspondentes. É assim que o sistema de fila funciona, e você pode conferir isso no Gerenciador de Tarefas do Windows.

Em um servidor de aplicativos do MOPS de um farm com um SSP associado a sites do PWA, você vê dois processos Microsoft.Office.Project.Server.Queuing.exe: um executado como a conta de administração de configuração e o outro como a conta de administrador de SSP. No meu ambiente de teste, essas contas são WssConfigAdmin e SspConfigAdmin, como mostra a Figura 8.

Figura 8 Falha na comunicação entre processos devido a acesso negado (clique na imagem para ampliá-la)

Então porque o sistema de fila não inicia? A entrada de erro no log de eventos do aplicativo não contém informações suficientes, mas você pode obter mais detalhes se definir temporariamente o Evento Menos Crítico a Ser Relatado no Log de Rastreamento de todas as categorias como Detalhado na Administração Central do SharePoint 3.0, na guia Operações em Log de Diagnóstico.

A Figura 8 mostra o log de rastreamento resultante e, se você observar com atenção, verá que ProjectQueueService (o serviço geral do Windows) inicia um QueueExecService (um processo de trabalho de fila), mas o processo QueueExecService falha porque o acesso é negado. Como QueueExecService falha, ProjectQueueService tenta reiniciá-lo, mas ele falha novamente pelo mesmo motivo e por isso continua a consumir ciclos de CPU e a preencher os logs de eventos e de rastreamento com milhares de erros. É um loop infinito.

Infelizmente, mesmo o mais detalhado log de rastreamento não revela a causa específica do erro de acesso negado. Mas não se desespere — pelo processo de eliminação, é possível descobrir rapidamente qual é a causa principal.

Se você alterar a conta de administrador de SSP na Administração Central do SharePoint 3.0 e especificar a conta de administração de configuração (WssConfigAdmin), o sistema de fila será iniciado. Também funciona ao contrário; se você simplesmente deixar a conta de administrador de SSP inalterada (SspConfigAdmin) e usá-la como a conta de serviço para o serviço do Windows, o sistema de fila também iniciará.

Assim, tanto a conta de administração de configuração quanto a conta de administrador de SSP têm todas as permissões necessárias; o que acontece é que o sistema de fila não iniciará se ProjectQueueService e QueueExecService usarem contas diferentes.

Este é um indicador claro de um problema de permissões entre processos distintos que querem interagir no computador local. Afinal, os processos ProjectQueueService e QueueExecService devem monitorar uns aos outros para assegurar um comportamento de serviço consistente (observe as entradas ProcessWatcher no log de rastreamento mostrado na Figura 8). Por exemplo, quando você encerra o serviço ProjectQueueService do Windows, todos os processos de trabalho QueueExecService também devem ser encerrados.

É a tentativa de acessar um processo executado em um contexto de segurança diferente que gera o erro. Para acessar um processo em outro contexto de segurança, são necessários privilégios elevados. Embora as contas de serviço possam ter esses privilégios, mesmo assim o Windows Server 2008 nega o acesso porque o Controle de Conta de Usuário (UAC) fica habilitado por padrão, fazendo com que os processos sejam executados com privilégios padrão.

Tão logo você desabilita o UAC, os processos ProjectQueueService e QueueExecService podem ser executados com privilégios elevados e o sistema de fila é iniciado. Você escolhe entre usar a conta de administração de configuração como a conta de administrador para todos os SSPs, e assim executar todos os processos na fila com a mesma conta, ou enfraquecer a segurança nos servidores de aplicativos do MOPS desabilitando o UAC.

Recursos do SharePoint

Site de produtos e tecnologias do SharePoint
microsoft.com/sharepoint

TechCenter do Windows SharePoint Services
technet.microsoft.com/windowsserver/sharepoint

Developer Center do Windows SharePoint Services
msdn.microsoft.com/sharepoint

Referência geral do Microsoft Office Project 2007
msdn.microsoft.com/library/bb258902

Blog da equipe de produtos e tecnologias do Microsoft SharePoint
blogs.msdn.com/sharepoint

Plano de contas administrativas e de serviço (Office SharePoint Server)
technet.microsoft.com/library/cc263445

Integração com Analysis Services

Vamos encerrar esta coluna com um problema do SQL Server 2005 Analysis Services que provavelmente você enfrentará se seguir as instruções descritas em "Requisitos para usar o SQL Server 2005 Analysis Services com o Serviço de Criação de Cubo do Project Server 2007" (com data de 5 de abril de 2007 quando esta coluna foi escrita). Se você seguir o caminho para criar o repositório do Analysis Services criando um banco de dados SQL Server 2005 conforme documentado, será gerado o erro exibido na Figura 9 quando tentar criar o cubo no PWA.

Figura 9 Erro de criação de cubo devido a configuração incorreta do Analysis Services (clique na imagem para ampliá-la)

O ponto importante é que o MOPS 2007 foi projetado para o SQL Server 2000 Analysis Services. O SQL Server 2005 Analysis Services requer mais etapas de configuração para fins de compatibilidade com versões anteriores. A versão do SQL Server 2000 armazena informações de repositório sobre o cubo criado em um banco de dados Microsoft Jet e, embora seja possível migrar um banco de dados Jet para trabalhar com o SQL Server 2005, isso não é necessário em uma implantação nova do MOPS.

O artigo do TechNet que mencionei há pouco explica como configurar o SQL Server 2005 para emular a funcionalidade do banco de dados Jet, independentemente de o banco de dados estar ou não presente. No entanto, o artigo não menciona que o MOPS ainda verifica informações de bloqueio de repositório no compartilhamento de arquivos .dso do servidor de banco de dados, independentemente de o Analysis Services estar configurado para usar um banco de dados Jet (o método antigo) ou um banco de dados SQL Server 2005 pré-configurado (o método preferencial).

A menos que esse compartilhamento de arquivos exista e a conta de administrador de SSP receba acesso de Controle Total ao compartilhamento, a criação do cubo falhará e será exibido o erro de permissão mostrado na Figura 9. Para que o SQL Server 2005 Analysis Services funcione corretamente com o Serviço de Criação de Cubo do MOPS, siga as etapas descritas na planilha complementar "Configurando cubos".

Conclusão

Não é fácil implementar o MOPS 2007. A arquitetura é complexa, e uma implantação bem-sucedida envolve inúmeras tarefas, que vão desde o planejamento adequado das configurações de farm de servidores, a instalação de arquivos binários e a execução do Assistente de Configuração de Produtos e Tecnologias do SharePoint em servidores de aplicativos e servidores front-end da Web, passando pelo provisionamento de pools de aplicativos, serviços compartilhados, sites de administração de SSP e sites do PWA na Administração Central do SharePoint 3.0 até finalmente configurar o Analysis Services no SQL Server Management Studio.

Para aumentar os desafios da implantação, existe a interferência de recursos de segurança do Windows Server 2008, como o Firewall do Windows e o UAC, pontos fracos nas ferramentas de administração do SharePoint e omissões na documentação de implantação do MOPS. Você não pode contar com a Administração Central do SharePoint 3.0 para avisá-lo quando o pool de aplicativos usar a conta Serviço de Rede em um farm de servidores, aplicar automaticamente todas as alterações de configuração exigidas (como ligações de site do IIS e regras de firewall do Windows) ou verificar o estado operacional de sites do PWA provisionados.

Também não espere que tudo funcione logo de imediato. É preciso que você entenda toda a arquitetura e as dependências do MOPS, não ignore as recomendações do produto e valide totalmente a configuração e a funcionalidade do MOPS criando recursos e planos de projeto de teste para assegurar o êxito da implantação.

Apesar desses desafios, o MOPS também herdou os pontos fortes do SharePoint como plataforma empresarial. Utilizando as tecnologias do SharePoint e de Web Services, o MOPS elimina a necessidade de uma conectividade de banco de dados direta em estações de trabalho cliente. Através do sistema de fila, o MOPS aumenta a sustentabilidade em horários de pico (por algum motivo inexplicável, todos os gerentes de programas querem atualizar seus planos de projetos na segunda-feira de manhã), e por meio de outras tecnologias do MOSS é possível integrar o MOPS a mais aplicativos de linha de negócios.

Por ter desenvolvido soluções comerciais para o Project Server 2003 no passado, considero os desafios de implantação do MOPS 2007 minúsculos em comparação com os problemas de escalabilidade anteriores, os antigos problemas de conectividade ODBC em conexões de rede lentas e a dificuldade de criar consultas de banco de dados, que envolviam tantas instruções JOIN que eu tinha de usar o Excel para acompanhar todas as subconsultas. O MOPS 2007 é um marco importante na evolução de EPM, e o trabalho de implantação vale a pena.

Pav Cherny é especialista em TI e autor especializado em tecnologias Microsoft de colaboração e comunicação unificada. Entre suas publicações estão white papers, manuais de produto e livros com foco nas operações de TI e na administração do sistema. Pav é Presidente da Biblioso Corporation, empresa especializada em serviços de documentação gerenciada e localização.