El propósito de este artículo es presentar un conjunto de diferencias que existen entre Project Server y SharePoint, en definitiva, un conjunto de tópicos que un administrador de SharePoint debería saber que existen, antes de embarcarse en la instalación de Project Server 2010.

[Agradezco al amigo Sebastián Torres por su revisión del artículo]

Arquitectura

Datos

Los datos en Project Server se almacenan en la base de datos de SharePoint, pero también en bases de datos propias de Project Server.

Draft: donde se almacenan los proyectos no publicados, que no pueden ser visible desde Project Web App (PWA).

Publish: información visible desde PWA. También contiene tablas específicas de PWA como la carga de horas y las vistas, así como también tablas globales como seguridad, metadata, etc.

Reporting: base de datos de sólo lectura, utilizada para la generación de reportes y OLAP. Actualizada prácticamente en tiempo real.

Archive: utilizada para funciones de respaldo y almacenamiento de versiones anteriores de proyectos.

Cada proyecto posee un sitio de proyecto creado con la tecnología SharePoint. Esta información se almacena por lo tanto en la base de datos de contenido de SharePoint dónde se encuentra instanciado Project Server. Microsoft recomienda una base de contenido dedicada para este servicio.

Por otro lado, Project Server utiliza SQL Server Analysis Services para consultar la información mediante OLAP.

Servicios

Project Server se ejecuta dentro de SharePoint como “Project Server Services App”. Podrán notar dos nuevos servicios en Windows:

Microsoft Project Server Events Service 2010
Microsoft Project Server Queue Service 2010

Así mismo, los binarios de Project Server necesita ser instalado en todos los servidores de la granja.

Front end

El usuario accede a la solución a través de dos aplicaciones:

Project Web App: una colección de sitios de SharePoint, con funcionalidades muy específicas de Project Server.

Project Professional: el cliente MS Project que muchos conocen, pero conectado con la base de datos de Project Server.

Arquitectura de Project Server

Fuente: Microsoft Project 2010 “Ignite” training slide presentations

Estructura de sitios

Existen dos puntos clave a la hora de definir cómo resultará conveniente desplegar Project Server en nuestra organización.

Integración de Project Server con el SharePoint corporativo

En este primer punto deberemos pensar si resulta conveniente instalar PS dentro de nuestra Intranet SharePoint o en una granja separada. Algunos puntos a tener en cuenta:

Integración de Project Server con la Intranet.

Actualización del software.

Impacto de uno en la estabilidad del otro.

Seguridad.

Esta es una decisión que conviene tomar en forma temprana y luego de una profunda discusión.

Instancias de Project Server

El otro punto clave es discutir qué unidades organizacionales requieren Project Server. Aquí existen dos posibilidades.

Compartir una instancia de PS entre varias unidades organizacionales.

Crear una instancia de PS para cada unidad organizacional.

Puntos a tener en cuenta para tomar esta decisión:

Necesidad de integrar proyectos de distintas unidades organizaciones.

Seguridad.

Posibilidad de que la configuración pueda ser la misma para distintas unidades.

Queue service

La mayoría de las operaciones que el usuario ejecuta tanto desde Project Server (actualización de tareas, aprobación de tareas, etc) como desde Project Professional (cambios al calendario, asignación de tareas, etc) son procesadas por Project Server a través de su servicio de cola.

Al ser una parte central de la solución, este es un servicio que necesita ser monitoreado en forma continua, ya que es quién nos informa aquellas operaciones que culminaron en forma correcta o las que presentaron errores.

Los principales puntos a tener en cuenta son:

La configuración del servicio para que posea un buen rendimiento.

El monitoreo del servicio.

El tratamiento de incidentes asociados al servicio de cola.

La interacción con el usuario final necesaria para resolver alguno de los incidentes que se producen.

Algunos de los parámetros que se configuran de este servicio son:

Queue Type

Maximum Number of Job Processor Threads

Polling Interval (in milliseconds)

Retry Interval (in milliseconds)

Retry limit

SQL retry interval (in milliseconds)

SQL retry limit

SQL Timeout (in seconds)

Cleanup Interval (in hours)

Cleanup Interval Offset (in minutes)

Cleanup Age Limit for Successful Jobs (in hours)

Cleanup Age Limit for Non-Successful Jobs (in hours)

Bookkeeping Interval (in milliseconds)

Queue Timeout (in minutes)

Fast Polling

Sitios de proyectos

Los sitios de proyectos constituyen una de las funcionalidades principales de Project Server, y terminan siendo la funcionalidad con más usuarios reales.

¿Qué debe saber un administrador acerca de ellos?

Que Project Server suele estar configurado para que se cree en forma automática un sitio cada vez que se publica un nuevo proyecto, lo que hace que crezca con bastante rapidez nuestra estructura de sitios, para lo cual debemos estar preparados.

Que los sitios se crean en base a plantillas de sitios que:

Siempre son modificadas respecto al estándar.

Que estás plantillas deben ser desplegadas en el sistema como soluciones.

Que no se permite cualquier modificación sobre las mismas, y una operación tan sencilla como la eliminación de una columna de SharePoint podría producir un error grave en el sistema.

¿Por qué estos sitios son particulares?

En principio porque poseen un conjunto de 4 listas (riesgos, issues, entregables y documentos) que están integradas a funcionalidad del sistema. Por ejemplo:

Se puede vincular un documento a una tarea de proyecto.

Se puede vincular un entregable a una tarea de proyecto. El entregable se visualiza en el Gantt dentro de Project Pro y además puede ser creado y vinculado dentro de Project Pro.

Algunas de estas listas / columnas son enviadas a la base de reporting.

Pueden estar configurados con elementos web propios de Project Server.

Conclusión:

Estar preparado para la creación exponencial de sitios.

Admitir la personalización de plantillas de sitios.

Cuidado al personalizar las plantillas!

Seguridad

La seguridad es uno de los aspectos más importantes a tener en cuenta, principalmente porque Project Server tiene su propio modelo de seguridad conformado por:

Grupos

Categorías

Permisos sobre PWA

Permisos sobre Sitios de Proyectos sincronizados

RBS

Seguridad en vistas.

El acceso a los datos está controlado por este modelo y se aplica tanto a:

Project Web App

Project Pro

Base OLAP

Sitios de proyectos

Este modelo de seguridad restringe el acceso a los datos basado en reglas de negocio. Por ejemplo:

Un líder puede editar sus proyectos, pero no los de otro.

Un líder puede ver los proyectos de personas de su misma rama dentro de la estructura organizacional (RBS).

La sincronización con los sitios de proyecto

Los sitios de proyectos utilizan seguridad estándar de SharePoint.

Sin embargo, la particularidad es que esta seguridad se sincroniza en el momento de publicar el proyecto, basando la misma en la seguridad de Project Server.

Esta sincronización puede también hacerse en forma manual o eliminarse (no recomendado).

Extensiones

PSI

Lo primero que debemos conocer es que existe una API de Project Server denominada PSI (Project Server Interface) disponible como servicios web ASMX y servicios WCF. Esta interfaz es utilizada por Project Pro, Project Web App y aplicaciones de terceros para interactuar con datos de las bases de datos Draft, Publish y Archive.

SharePoint

En principio se aceptan casi todos los métodos estándar de desarrollo en SharePoint para modificar Project Server, principalmente en los sitios de proyecto.

Importante: PWA no puede ser editado con SharePoint Designer (los sitios de proyecto sí)

Workflow

La funcionalidad de gestión de la demanda es uno de los principales cambios de la versión 2010 de Project Server, que permite manejar flujos de trabajo a través de todo el ciclo de vida de la administración de los proyectos, incluso antes de que estos tomen la forma de proyectos.

Estos flujos de de trabajo se construyen con Visual Studio, no con SharePoint Designer. La arquitectura posee una capa superior a SharePoint, propia de Project Server y un conjunto de entidades para manejar los datos que se configuran desde Project Web App:

Fases

Etapas

Campos personalizados

Project Details Pages

Project Server workflow architecture

Project Server Workflow Architecture

Fuente: Workflow and Demand Management

Workflow creation process

Workflow Creation Process

Fuente: Workflow and Demand Management

Importante: en caso de usar herramientas de terceras partes para manejar flujos de trabajo, debemos revisar que dichas herramientas estén preparadas para Project Server, no sólo para SharePoint.

Idioma

Un punto a tener en cuenta, es que no todos los idiomas disponibles en SharePoint, están disponibles para Project Server.

Por otro lado, debemos tener en cuenta que ciertas personalizaciones como los nombres de vistas o los campos personalizados no admiten configuración multi-idioma.

Licenciamiento

A modo de resumen, a nivel de servidor se requiere:

Project Server 2010

SharePoint Server 2010 Enterprise

A nivel de cliente, se necesita:

Project Professional (para los usuarios que aplique)

Project Server CAL (incluida en Project Professional)

SharePoint Standard CAL

SharePoint Enterprise CAL

SQL Server CAL

Windows Server CAL

Fuente: Enterprise Project Management 2010 - Licensing Guide

Reportes

Como mencionamos anteriormente, Project Server utiliza una base de datos propia para la generación de reportes.

A nivel OLAP, existen un conjunto de cubos predefinidos, sin embargo el usuario puede elegir campos personalizados para agregar a los mismos como medidas o dimensiones.

Por otro lado, Project Server genera un Business Intelligence Center, que está soportado por distintas herramientas de reporting tales como:

Excel services

Performance Point Services

Visio Services.

Reporting Services

Microsoft Business Intelligence Tool Segmentation

Fuente: Microsoft Project 2010 “Ignite” training slide presentations

Reportes es una de las funcionalidades en donde más se trabaja en extender la plataforma, ya que el usuario suele necesitar informes a medida que no suelen estar cubiertos por las funcionalidades out of the box.

Actualizaciones de software

Cada dos meses Microsoft libera paquetes acumulativos de Project Server. A diferencia de SharePoint, también pueden existir actualizaciones para Project Pro (clientes) y es fundamental que las actualizaciones se hagan al mismo tiempo (servidores y clientes).

Esta es una de las razones que llevan a evaluar si es conveniente integrar Project Server con la Intranet corporativa o conviene desplegarlo en una granja independiente.

Backup

Todo las políticas de SharePoint aplican pero!!!

Tenemos 4 bases de datos adicionales a tener en cuenta.

Debemos tener implementado un mecanismo para recuperar sitios individuales.

Debemos tener implementado un mecanismo para recuperar proyectos individuales, usualmente a través de la base de datos de Archiving.

Integración con Exchange

La integración entre Project Server 2010 y Exchange Server permite a los usuarios ver (y actualizar) las tareas de Project como tareas de Outlook. Requiere configuración en Project Server y Exchange Server y activación de la sincronización para cada usuario.

Esta es una funcionalidad muy pedida por los usuarios, por lo cual es conveniente contemplarla y entender las implicancias a nivel de administración y configuración.