Arquitectura de Project Server 2013

Office 2013 y posterior

Project Server 2013 integra la característica de administración de proyectos en una granja de SharePoint y permite el uso de Project Online con un modelo de objetos de cliente (CSOM) y una interfaz OData para los datos de informes.

Project Server 2013 es un sistema de varios niveles que extiende la arquitectura introducida en Office Project Server 2007. Los cambios de arquitectura incluyen la asociación del Servicio de aplicaciones de Project con las recopilaciones de sitios de SharePoint, además de algunos objetos de negocios en la web front-end (WFE), el modelo de objeto del cliente (CSOM) para el acceso remoto, una base de datos de Project única, una interfaz OData para las tablas y vistas de informes, la integración de la versión 4 (WF4) Windows Workflow Foundation a través de Cliente del Administrador de flujos de trabajo 1.0 en la nube o en un servidor local, así como receptores de eventos remotos accesibles mediante múltiples instalaciones de Project Server.

Este nivel front-end incluye Project Profesional 2013, Project Web App y aplicaciones de terceros. Las aplicaciones de clientes se comunican con el nivel intermedio a través de la interfaz de Project Server (PSI, Project Server Interface) o mediante los extremos CSOM, que a cambio se comunican con la PSI y la capa del objeto de negocio. El acceso a la base de datos se integra en los objetos de negocios. El sistema de creación de eventos de Project Server (Project Server Eventing System) puede acceder tanto a los controladores de eventos locales como a los receptores de eventos remotos. El servicio de cálculo del proyecto (Project Calculation Service) implementa el motor de programación Project Professional en Project Server. Las aplicaciones del cliente no acceden (o no deben acceder) a la base de datos de Project; Project Server esconde los objetos de negocio de los clientes.

Nota Nota

Project Server está basado en la arquitectura de SharePoint. Para más información sobre la arquitectura de SharePoint Server 2013 y del modelo de aplicaciones de SharePoint, vea la sección Introducción al desarrollo con SharePoint en la documentación para el desarrollador Office 2013.

El servicio de aplicaciones de Project en Project Server 2013 puede asociarse con la recopilación de sitios de SharePoint para su uso con las listas de tareas de SharePoint. El servicio de aplicaciones de Project también puede importar una lista de tareas de SharePoint como un proyecto empresarial para el control total de Project Server. Con una lista de tareas de SharePoint, este mantiene el sitio del proyecto en una recopilación de sitios; Project Professional puede sincronizarse con la lista de tareas además de actualizarlas. El sitio de un proyecto puede ser una lista de tareas de SharePoint interdependiente o bien una lista de tareas que esté sincronizada con un archivo .mpp; este archivo puede almacenarse a nivel local o en una biblioteca de SharePoint.

Project Server mantiene los proyectos cuanto tiene el control total; Project Professional guarda los datos directamente en Project Server. La Tabla 1 compara el comportamiento de una lista de tareas, el elemento web Schedule (Schedule Web Part) y otra funcionalidad para el control de SharePoint de las listas de tareas y para los proyectos importados cuando Project Server tiene el control total. El elemento web Schedule (Schedule Web Part) contiene la cuadrícula en la página de Project Web App donde puede editar la programación de un proyecto. El modo vinculado es aquel en el que los datos de estados se escriben una vez tanto para las tareas como para los partes de horas. Sin embargo, en el modo de entrada única, los datos de estados de tareas se escriben independientemente de los partes de horas.

Tabla 1. Comparación de una lista de tareas de SharePoint y el control total

Característica

Lista de tareas

Control total

Lista de tareas en SharePoint

Lectura/escritura

Solo lectura

Elemento web Schedule (Schedule Web Part)

Solo lectura

Lectura/escritura

Reporting

Informes avanzados con Project Server

Informes avanzados con Project Server

Otras funciones de Project Server

Función bloqueada:

  • Ediciones del proyecto del servidor con Project Web App o aplicaciones de clientes personalizadas

  • Estados

  • Las tareas no son visibles en modo vinculado

La funcionalidad completa está habilitada

Administración de proyectos como listas de tareas de SharePoint

Cuando se asocia Project Server a una recopilación de sitios de SharePoint en el que SharePoint mantiene el control, las listas de tareas y los archivos (.mpp) Project Profesional 2013 en las bibliotecas de documentos son visibles para el servicio de aplicaciones de Project. Sin embargo, SharePoint mantiene los datos maestros para la sincronización (consulte Figura 1). La programación del servidor con el elemento web Schedule (Schedule Web Part) no puede realizarse. Puede utilizar Project Professional para realizar la sincronización y la edición de la lista de tareas en un sitio de proyecto. Al comenzar con las listas de tareas de SharePoint, las organizaciones pueden evolucionar gradualmente para utilizar todas las funciones de Project Server.

La Figura 1 muestra los siguientes procesos cuando se mantienen los proyectos en las listas de tareas de SharePoint:

  • (A) Project Professional puede sincronizarse con las listas de tareas y crear nuevos sitios de proyectos en una recopilación de sitios ya sea antes o después de la asociación con Project Application Service.

  • (B) Project Server se sincroniza con los datos del sitio del proyecto a fin de informar, pero SharePoint mantiene los datos maestros y las listas de tareas siguen en lectura/escritura.

  • (C) Después de la asociación, Project Professional puede crear nuevos proyectos y guardar o publicar en Project Server. La caché activa en Project Professional mantiene la sincronización de datos con Project Server.

  • (D) Cuando se publica un nuevo proyecto en Project Professional, el usuario tiene la opción de crear un sitio de proyecto para el proyecto. También es posible crear un proyecto en Project Web App como un tipo de proyecto con lista de tareas en SharePoint o como un tipo de proyecto empresarial (EPT) con control total. El paso (D) muestra el EPT con control total.

Figura 1. Utilizar los sitios de proyecto como listas de tareas en SharePoint

Uso de sitios de proyectos en modo de visibilidad

Administración de proyectos con control total

Cuando Project Server se asocia con un conjunto de sitios y tiene control total, este importa listas de tareas de SharePoint como proyectos empresariales y puede borrar cualquier archivo .mpp. Project Server mantiene los datos maestros para la sincronización de la lista de tareas; las listas de tareas en el conjunto de sitios se convierten en solo lectura (consultar Figura 2). Los proyectos importados pueden editarse mediante Project Professional o mediante Project Web App.

Nota Nota

Una vez que Project Server importa un proyecto, el usuario escoge si borrar el proyecto desde el sitio o romper la conexión antes de editar el proyecto. La selección puede realizarse en Project Professional.

La Figura 2 muestra los siguientes procesos cuando Project Server mantiene los proyectos empresariales con control total:

  • (A) El usuario puede escoger qué sitios de proyecto importa. Project Server importa los sitios de proyecto y de manera opcional elimina los archivos .mpp asociados. La lista de tareas de SharePoint de un proyecto importado se convierte en solo lectura.

  • (B) Después de la asociación, Project Professional crea nuevos proyectos y los guarda o publica en Project Server. La caché activa en Project Professional mantiene la sincronización de datos con Project Server. El elemento web Schedule (Schedule Web Part) in Project Web App puede realizar la programación del servidor.

  • (C) Cuando se publica un nuevo proyecto en Project Professional, el usuario tiene la opción de crear un sitio de proyecto para el mismo. También se puede crear un proyecto en Project Web App con un EPT con control total y se puede publicar con una lista de tareas de solo lectura en un sitio de proyecto en la recopilación de sitios.

Figura 2. Utilizar sitios de proyectos con control total

Uso de sitios de proyectos en modo administrado

La Figura 3 muestra una vista generalizada de la arquitectura de Project Server 2013 incluyendo la aplicación de servicio de Project, una instancia de Project Web Appen un WFE y otras varias aplicaciones de cliente que incluyen Project Profesional 2013.

Puede haber múltiples instancias de Project Web App que se comuniquen con la aplicación de servicio de Project back-end. Para una instalación en local, el WFE puede estar en un servidor independiente en una granja de SharePoint o puede estar en el mismo servidor de SharePoint con la aplicación de servicio de Project. Project Online incluye un WFE, la aplicación de servicio de Project y un servidor local o remoto Cliente del Administrador de flujos de trabajo 1.0.

Figura 3. Arquitectura general de Project Server 2013

Arquitectura de Project Server

Los siguientes comentarios generales se aplican a la Figura 3:

  • Project Online: puede crear aplicaciones que usen las interfaces CSOM, REST y OData. Un paquete de aplicaciones también puede instalar receptores de eventos remotos en un servicio web personalizado en un servidor local, en un servidor Azure o en Microsoft Azure. Project Online no admite soluciones locales de terceros, la interfaz WCF, la interfaz ASMX ni controladores de eventos locales.

  • Receptores de eventos: los receptores de eventos pueden llamarse también controladores. Project Online admite el registro de receptores de eventos remotos de Project Server, que una instancia Project Web App puede en la nube o bien por una instalación local de Project Server. Una instalación local de Project Server admite los receptores de eventos remotos, así como los controladores de eventos de plena confianza.

  • Exploradores: no hay limitaciones entre distintos exploradores para visualizar algunas páginas de Project Web App, como hay en Project Server 2010. Se admiten los siguientes exploradores para un uso completo con Project Web App:

    • Internet Explorer 8.x (en Windows 7 y versiones anteriores de Microsoft Windows), Internet Explorer 9.x, e Internet Explorer 10.x

    • Firefox 4.x (en Windows, Mac OS-X, y Linux/Unix)

    • Safari 5.x (en Windows y Mac OS-X)

    • Chrome

  • Interfaces de programación: para las aplicaciones de terceros, Project Online expone la interfaz HTTP/HTTPS (incluida REST), la interfaz CSOM, un servicio OData para CSOM y un servicio OData para informes. Para las aplicaciones cliente de terceros que son locales (de la intranet), puede usar la interfaz WCF para PSI, o bien puede usar las interfaces CSOM, OData y REST a través de HTTP. Los clientes de Project Web App y de Project Profesional 2013 usan la interfaz WCF. En una instalación de un único servidor, los servicios web ASMX front-end, CSOM y REST llaman internamente a los servicios WCF back-end.

    Nota Nota

    La interfaz ASMX basada en SOAP para los servicios web en PSI sigue disponible en Project Server 2013, pero está en desuso.

    El servicio WCF OData.svc implementa el servicio OData para el informe. Puede obtener el documento de metadatos del servicio para los datos del informe mediante http://ServerName/ProjectServerName/_api/ProjectData/$metadata.

    El servicio OData para CSOM está diseñado para plataformas como Windows RT, iOS y Android, donde puede usar la interfaz REST con JavaScript en las páginas HTML.

    Nota Nota

    Aunque la opción $metadata para el servicio de informes ProjectData es válida, la opción $metadata para el servicio ProjectServer de CSOM se quitó de la versión publicada de Project Server 2013. Para más información sobre las consultas REST para CSOM, vea Modelo de objetos de cliente (CSOM) para Project Server.

  • Reenviador PSI: el acceso mediante programación a PSI en un WFE independiente tiene lugar mediante el reenviador PSI, que incluye un reenviador WCF y un reenviador de servicios web. Los clientes que usan la interfaz ASMX tienen acceso a PSI a través del reenviador de servicios web. Los clientes que usan la interfaz WCF tienen acceso a PSI a través del reenviador WCF. El acceso mediante programación a través de CSOM, OData y REST se canaliza a través del reenviador WCF.

  • Flujos de trabajo: los flujos de trabajo declarativos (flujos de trabajo definidos en SharePoint Designer 2013) se descargan en Cliente del Administrador de flujos de trabajo 1.0 para su procesamiento. Cliente del Administrador de flujos de trabajo 1.0 se puede ejecutar en un servidor independiente en la granja de SharePoint, en Microsoft Azure en la nube o en un único equipo con Project Server para pruebas o demostraciones. Los flujos de trabajo codificados que se desarrollan con Visual Studio 2012 se procesan en el tiempo de ejecución del flujo de trabajo dentro de SharePoint, como en Project Server 2010. Para más información, vea Comenzar desarrollando flujos de trabajo de Project Server.

  • Red perimetral (DMZ): la Figura 3 no muestra que un servidor WFE local puede aislarse por un firewall adicional en una red perimetral (también conocida como una "zona desmilitarizada" o DMZ). Una red perimetral puede permitir que los clientes de Internet accedan a SharePoint y a Project Server a través de un firewall.

  • Servicios web de SharePoint: la Figura 3 no muestra la infraestructura de SharePoint, como la aplicación de servicios web de SharePoint back-end, que es parte de SharePoint Server 2013. Cuando instala Project Server, la aplicación de servicio de Project se añade a los servicios web de SharePoint.

El nivel front-end incluye las aplicaciones de terceros, Project Professional y Project Web App. Un explorador muestra las páginas ASP.NET 4.0 (páginas .aspx) en Project Web App. Las páginas Project Web App utilizan los elementos web de Project Server que se comunican con la PSI y que también utilizan los elementos web de SharePoint.

El nivel intermedio utiliza la PSI y la capa de objeto de negocio, que está compuesta de objetos lógicos que representan a las entidades de negocio de Project Server. Las entidades de negocio incluyen el Proyecto, la Tarea, el Recurso, la Asignación, etc. La PSI y el nivel del objeto de negocio están emparejadas estrechamente y están ubicadas en el mismo servidor. Una aplicación de cliente llama a la PSI a través de una de las interfaces disponibles y la PSI invoca los objetos de negocio. Para un rendimiento mejorado, el WFE de Project Server 2013 incluye algunos objetos de negocio para las solicitudes que no usen el sistema de creación de colas de Project Server (Project Server Queuing System) o requieren el Servicio de cálculo del proyecto (Project Calculation Service). Los objetos de negocio de WFE se comunican directamente con la base de datos de Project.

Los componentes Project Web App de Project Server utilizan la base de datos de configuración SharePoint 2013 para la configuración del sitio de proyecto y la base de datos de contenido para el contenido del sitio de proyecto como listas de tareas, páginas personalizadas, flujos de trabajo, configuración de administración, documentos y listas de problemas, riesgos y compromisos. La configuración de SharePoint y las bases de datos de contenido admiten características adicionales para la administración de proyectos, como plantillas del proyecto y área de trabajo, listas personalizadas para la colaboración de equipos e informes.

Project Web App y el WFE

Puede configurar múltiples instancias de Project Web App en un servidor WFE y múltiples servidores WFE en una intranet corporativa para habilitar la distribución de carga para clientes de la intranet. Cuando una aplicación de cliente usa una instancia de Project Web App en un servidor WFE independiente, las llamadas PSI se enrutan a través del reenviador de PSI. Este (ya sea el reenviador de WCF o el reenviador de servicio web) realiza las siguientes funciones:

  • Optimiza las llamadas para la PSI desde clientes remotos.

  • Distingue entre las llamadas PSI que requieren el servicio de cola de Project Server (Project Server Queue Service) y entre las que no lo necesitan. Los nombres de métodos PSI asincrónicos comienzan con Queue, como QueueCreateProject.

  • Identifica las llamadas PSI que invocan controladores de eventos locales registrados.

  • Identifica las llamadas PSI que requieren el Servicio de cálculo del proyecto (Project Calculation Service).

  • Utiliza una caché basada en servidor que funciona con la caché activa del cliente en Project Professional para reducir las llamadas de ida y vuelta en Project Server.

Una vez SharePoint ha autenticado a un usuario de Project Server, el reenviador PSI envía de manera transparente solicitudes que utilizan servicios back-end a los servicios PSI en el equipo que ejecuta Project Server. Las solicitudes que no requieren servicios back-end se envían a los objetos de empresa en la instancia local Project Web App. El reenviador PSI mejora la escalabilidad, el rendimiento y la confianza del procesamiento de Project Server a través de LAN, WAN y en Project Online.

Project Web App se desarrolla con ASP.NET 4.0. Los elementos visuales en archivos .aspx (HTML, controles de servidor y texto estático) son independientes de la lógica de programación en las clases subyacentes al código que se encuentran en ensamblados compilados (archivos .dll). Las páginas del sitio en Project Web App, como la página de nivel superior, Centro de proyectos y Centro de informes pueden personalizarse mediante elementos web. Las páginas de aplicación que no tienen una opción de Editar página en el menú Acciones del sitio no pueden editarse, como la página de Configuración del servidor y la página de Revisión del parte de horas.

El CSOM y la interfaz de Project Server (Project Server Interface)

La PSI se factoriza en 22 servicios públicos, como Project, Resource, CustomField y Statusing. Asimismo, la PSI contiene siete servicios privados para su uso interno. La PSI es la API fundamental de Project Server, expone la funcionalidad de Project Server para el CSOM y para las aplicaciones externas. El CSOM incluye clases que acceden a las clases PSI más utilizadas y a los miembros que son utilizados por aplicaciones de terceros. En Project Server 2013, algunas funciones de Project Server no están disponibles en el CSOM, como los servicios Admin, Calendar, PortfolioAnalyses y Security.

Project Profesional 2013 y Project Web App utilizan la PSI para acceder a los datos de Project Server en las tablas y vistas de borrador, publicadas y de archivo de la base de datos de Project. Puede acceder al servicio PSI a través de un archivo proxy o un ensamblado proxy, ya sea para los servicios WCF o para los servicios web ASMX.

Nota Nota

El CSOM es la interfaz preferida para los desarrolladores de Project Server de terceros porque puede utilizarse para aplicaciones que acceden tanto a una instalación de Project Server local como Project Online. Le recomendamos que utilice el CSOM para desarrollar nuevas aplicaciones, si CSOM incluye la función que requiere su aplicación.

Algunas aplicaciones de línea de negocio (LOB) y otras aplicaciones de terceros que se desarrollaron para Project Server 2010 requieren servicios PSI que aún no están representados en el CSOM. Si se orientan únicamente hacia una instalación local de Project Server, las aplicaciones pueden seguir usando la interfaz WCF o la interfaz ASMX del PSI.

Las aplicaciones de cliente realizan las llamadas al PSI mediante servidores proxy de servicio. Los clientes que utilizan la interfaz WCF acceden a todos las PSI a través de http://ServerName/ProjectServerName/_vti_bin/psi/ProjectServer.svc. Los clientes que utilizan una interfaz de servicio web ASMX usan la URL Project Web App para el servicio determinado. Por ejemplo, el servicio Resource se encuentra en http://ServerName/ProjectServerName/_vti_bin/psi/resource.asmx?wsdl. Si las aplicaciones no tienen acceso a la intranet de Project Server, pueden usar un servidor Project Web App en una red perimetral (no se muestra en la Figura 3).

La Figura 4 muestra el panel de Conexiones en el Administrador de Internet Information Services (IIS) para una instalación de servidor único de SharePoint Server 2013, Project Server 2013 y un sitio de administrador del flujo de trabajo para Cliente del Administrador de flujos de trabajo 1.0. La recopilación de sitios de SharePoint (A) incluye los servicios de PSI front-end en el subdirectorio virtual _vti_bin\PSI. La aplicación de servicios web de SharePoint (B) incluye la aplicación del servicio de Project con los servicios PSI back-end en el subdirectorio virtual 508c23fb7dfd4c83a8919fae24bc68c5/PSI. El GUID es el nombre de la instancia de la aplicación de servicio de Project para esa instalación de Project Server.

Figura 4. Administrador de Internet Information Services (IIS) que muestra la PSI front-end (A) y la PSI back-end (B)

PSI front-end y PSI back-end

Las aplicaciones de cliente no pueden acceder directamente a los servicios WCF para el PSI en la aplicación de servicio de Project back-end. Si no requieren acceso a Project Online, las aplicaciones de cliente y los componentes de las aplicaciones de línea de negocios (LOB) usan servidores proxy para el PSI. Una URL back-end para la interfaz WCF del servicio Resource en la Figura 4, por ejemplo, sería http://ServerName:32843/508c23fb7dfd4c83a8919fae24bc68c5/psi/resource.svc. El puerto 32843 es el puerto de HTTP predeterminado para la aplicación de servicios web de SharePoint (32844 es el puerto para las comunicaciones HTTPS). Sin embargo, el archivo web.config para Project Web App bloquea el acceso directo a los servicios PSI back-end.

Nota Nota

La descarga del SDK de Project 2013 incluye archivos proxy PSI para los servicios WCF y los servicios ASMX, así como instrucciones acerca de cómo compilarlos en ensamblados de servidores proxy.

Para crear archivos proxy PSI que usen la interfaz WCF, se debe usar la utilidad svcutil.exe o Visual Studio directamente en el equipo de Project Server.

Los miembros de los servicios PSI suelen producir o consumir objetos escritos DataSet como forma para intercambiar información con los objetos de negocio. También existen distintos modelos para el desarrollo PSI. Por ejemplo, los servicios PSI Resource, CustomFields y LookupTable utilizan objetos de filtro XML para la manipulación de DataSet y otros servicios no lo hacen; algunos métodos del servicio Statusing usan un parámetro changeXml mientras que otros métodos y servicios no lo realizan. El CSOM no utiliza conjuntos de datos. Aunque el CSOM tiene un modelo de programación diferente al del PSI, y puede usar o bien los ensamblados .NET o JavaScript, el desarrollo con CSOM normalmente es más sencillo y más coherente que el desarrollo realizado en la PSI.

Para más información sobre PSI, vea Información general de referencia PSI de Project. Para más información sobre CSOM, vea Modelo de objetos de cliente (OMSC) para el proyecto de 2013.

Objetos de negocio en WFE y la aplicación de servicio de Project

El modelo de objeto interno de Project Server incluye los objetos de negocio, que representan a las entidades lógicas como Proyecto y Recurso. Las aplicaciones de cliente acceden a los objetos de negocio tan solo a través de CSOM o la PSI. Los objetos de negocio, sin embargo, acceden a las tablas y vistas de borrador, publicadas y de archivo en la base de datos de Project.

Los objetos de negocio no se exponen a desarrolladores de terceros. La PSI controla la asignación de API a los objetos de negocio y el CSOM asigna su API al PSI. Las entidades lógicas de los objetos de negocio pueden clasificarse en tres tipos:

  • Las entidades principales son objetos como proyectos, tareas, asignaciones, recursos y calendarios. Las entidades centrales incluyen lógica de negocios básica como permisos y normas de nomenclatura.

  • Las entidades de negocio son objetos como partes de horas, carteras de proyectos y modelos. Las entidades de negocio incluyen lógica empresarial adicional y normalmente se suelen crear a partir de una combinación de entidades principales.

  • Las entidades de soporte técnico son objetos como seguridad y validación.

En Project Server 2010, todos los objetos de negocio se implementan en la aplicación de servicio de Project. En Project Server 2013, el WFE hospeda muchos de los objetos de negocio que procesan los métodos sincrónicos y no requieren el Servicio de cálculo del proyecto (Project Calculation Service). Los métodos sincrónicos de la PSI como DeleteProject y ReadAssignments no utilizan el servicio de cola de Project Server (Project Server Queue Service). Los métodos asincrónicos de la PSI tienen nombres que comienzan con Queue, como QueueCreateProject y QueueUpdateTimesheet. Un método asincrónico envía un mensaje al servicio de cola de Project Server (Project Server Queue Service), que programa el procesamiento del método mientras se devuelve el control al usuario.

El reenviador de PSI determina qué solicitudes se envían a la aplicación del servicio de Project y cuáles pueden ser procesados por los objetos de negocio en WFE. Estos objetos desvían la aplicación de servicio de Project y tienen acceso directo a la base de datos de Project, de una manera similar a la que otros procesos de SharePoint acceden directamente en un WFE a la configuración y bases de datos de contenido. La ejecución de muchos objetos de negocio en el WFE mejora la eficiencia de Project Server, reduce la carga en el nivel de la aplicación y permite a Project Server realizar una mejor ampliación para el aumento de las cargas de trabajo.

Nota Nota

En Project Server 2013, los controladores de eventos locales deben estar implementados en el WFE y el equipo back-end de Project Server.

Base de datos de Project Server

En Project Server 2013, las cuatro bases de datos que había en las versiones anteriores de Project Server se combinan en una sola base de datos de Project en SQL Server. El nombre de la base de datos de Project predeterminado es ProjectService. Las tablas y vistas de informes conservan sus nombres anteriores con el prefijo dbo, como dbo.MSP_EpmProject y dbo.MSP_EpmProject_userView. Las tablas y vistas que se encontraban previamente en la base de datos de borrador tienen el prefijo draft. Las tablas y vistas que se encontraban previamente en la base de datos publicada tienen el prefijo pub. Las tablas y vistas de la base de datos de archivo tienen el prefijo ver.

Nota importante Importante

El acceso directo no se admite para las tablas y vistas de borrador (prefijo draft), publicada (prefijo pub) y de archivo (prefijo ver). Los informes deben usar únicamente las tablas y vistas de informes, que tienen el prefijo dbo.

Los datos de Project Server están divididos en la base de datos de Project como se indica a continuación:

  • Las tablas y vistas de borrador contienen datos de proyectos no publicados que se crearon con Project Professional y otras aplicaciones. Project Web App no muestra datos de proyectos de las tablas y vistas de borrador.

  • Las tablas y vistas publicadas contienen todos los proyectos publicados y recursos de empresa, los datos globales para los tipos de proyectos empresariales (EPT) y otras plantillas de proyecto. Los proyectos publicados están visibles en Project Web App. Los datos publicados también incluyen tablas específicas para Project Web App (partes de horas, modelos, vistas y demás), además de tablas de datos globales (campos personalizados, tablas de búsqueda, permisos de autorización de Project Server y metadatos).

  • Los datos de archivo guardan las versiones de copia de seguridad de los proyectos, recursos, campos personalizados y otros datos.

  • Los datos de informes pueden utilizarse para el acceso de solo lectura en aplicaciones de terceros y para informes. Los cubos OLAP de Project Server utilizan las vistas de informes que tienen el sufijo _OlapView. Los cubos OLAP están disponibles en la instalación local de Project Server; sin embargo, no lo están en Project Online.

    Los datos de informes son exhaustivos y se actualizan prácticamente en tiempo real. Las tablas y vistas de informes están optimizadas para la generación de informes de solo lectura. Así, por ejemplo, las tablas de informes están desnormalizadas para ofrecer datos redundantes y para reducir el número de tablas relacionales.

Las entidades lógicas como Recurso o Proyecto pueden abarcar varias tablas y todas las tablas de una entidad determinada tienen la misma clave principal. La clave principal es un GUID en una sola columna que identifica únicamente una instancia de una entidad particular.

Los datos de Project Server para cada instancia de Project Web App se almacenan en una base de datos de Project con otro nombre. Las aplicaciones de cliente que tienen un acceso directo a Project Server pueden leer directamente las tablas y vistas de informes. Para el acceso remoto, las aplicaciones de clientes pueden utilizar la interfaz OData y la interfaz REST para obtener los datos para los informes. Los clientes deben usar únicamente el CSOM o la PSI para acceder a las tablas y vistas de borrador, publicadas y de archivo. El servicio de datos de informes (RDS, que no se muestra en la Figura 3) actualiza los datos de informes a partir de los datos publicados prácticamente en tiempo real. La base de datos de Project puede ubicarse en un servidor independiente.

Los esquemas se documentan únicamente para las tablas y vistas de informes. Para una instalación local de Project Server, puede añadir tablas y vistas de informes para las entidades que no estén definidas en el esquema de la base de datos de Project. También puede crear bases de datos independientes para las aplicaciones locales personalizadas. No se admite la modificación para las tablas y vistas de borrador, publicadas y de archivo. Dado que la base de datos de Project no es accesible directamente en Project Online, no es posible modificar las tablas y vistas de informes. Sin embargo, si tiene una cuenta SQL Azure puede crear bases de datos independientes para un uso personalizado con Project Online.

Receptores de eventos

Los controladores de eventos locales y los receptores de eventos remotos de Project Server permiten la extensibilidad de terceros en respuesta a los eventos de Project Server como la creación o publicación de un proyecto. En Project Server 2010, todos los controladores de eventos son locales y se escriben en código de plena confianza, se implementan directamente en el equipo que ejecuta Project Server y para WFE, además se ejecuta dentro del sistema de creación de eventos Project (Project Server Eventing System). Dado que Project Online no puede usar controladores de eventos de plena confianza, Project Server 2013 implementa los receptores de eventos remotos que son similares a los receptores de eventos remotos en SharePoint Server 2013. Una instalación local de Project Server 2013 puede utilizar controladores de eventos de plena confianza tradicionales así como receptores de eventos remotos.

Se puede implementar un receptor de eventos remoto de Project Server en un servicio web personalizado con un extremo SOAP que se ejecute en Microsoft Azure u otros entornos que admitan los servicios web SOAP. Un paquete de aplicaciones de Project Server puede incluir receptores de eventos remotos que están instalados con la aplicación.

Los receptores de eventos remotos pueden volver a llamar en Project Server mediante los extremos CSOM (no se muestra en la Figura 3). La llamada a un receptor de eventos remoto incluye información desde el sistema de eventos de Project Server y la instancia Project Web App (o el inquilino de Project Web App en Project Online) que emite la llamada. Los receptores de eventos remotos le permiten crear y hospedar un solo servicio web que puedan utilizar las instalaciones de Project Server. Por el contrario, los controladores de eventos locales de plena confianza deben implementarse para cada instalación de Project Server.

Publicación y programación del servidor

Project Server 2013 admite las actualizaciones de programación de proyectos tanto manuales como automatizadas. El proceso predeterminado es una actualización de la programación manual, es decir, el jefe de proyecto comprueba y abre un proyecto en Project Professional o Project Web App, aplica los cambios y, a continuación, guarda y publica el proyecto para que los cambios estén disponibles para todo el mundo. Project Professional tiene un motor de programación que calcula los cambios y luego los guarda en Project Server. En Project Server 2010, el motor de programación del servidor es una implementación distinta del motor de programación de Project Professional.

En Project Server 2013, el Servicio de cálculo del proyecto (Project Calculation Service) implementa el mismo motor de programación que hay en Project Profesional 2013. El Servicio de cálculo del proyecto (Project Calculation Service) se ejecuta en un servicio de Windows llamado Servicio de cálculo de Microsoft Project Server (Microsoft Project Server Calculation Service). La edición de una programación de proyecto en Project Web App o mediante aplicaciones de terceros que utilizan el CSOM da lugar a exactamente los mismos cambios de programación que habría llevado a cabo Project Professional.

Nota Nota

Es posible que las aplicaciones de terceros que utilizan la PSI muestren algunas diferencias en la programación de una programación que calcula Project Web App. Para la compatibilidad con versiones anteriores, los métodos de PSI públicos que realizan programaciones del servidor aún usan el motor de programación que se introdujo en Project Server 2010. Como excepción está QueueUpdateProject2, que es un nuevo método de PSI en Project Server 2013. Por ejemplo, el motor de programación más antiguo no realiza programaciones de subproyectos o vínculos a otros proyectos, así como tampoco calcula el valor acumulado (campos). Para evitar diferencias potenciales en la programación entre aplicaciones de terceros y de Project Professional o Project Web App, debe desarrollar aplicaciones con el CSOM en los casos en los que sea posible.

Project Server permite la versión publicada de un proyecto para que se actualice mientras un jefe de proyecto utiliza la versión de borrador, siguiendo las instrucciones siguientes:

  1. Project Server aplica las actualizaciones y reprograma la versión publicada.

  2. Project Server guarda la actualización para aplicarla a la versión de borrador en caso de que ocurra alguno de los siguientes eventos:

    • Project Professional abre el proyecto.

    • Project Professional intenta publicar el proyecto.

  3. En caso de que surja un conflicto, el jefe de proyecto recibe una notificación y debe resolver el conflicto antes de que se publique la versión de borrador.

Mostrar: