SSD: el síndrome de la Sharepoint dependencia

Sharepoint me proporciona seguridad y me hace sentir más fuerte. Las 10 cosas que más me gustan de Sharepoint.

10 puntos para entender a Project Server 2010

Microsoft Project es quizá la herramienta de gestión de proyectos más conocida y utilizada por los líderes de proyectos...

Diseño Gráfico en SharePoint

Serie de artìculos que nos ayudan a incorporar diseño gráfico en las implementaciones de SharePoint...

Revista CompartiMOSS

Artículos publicados en la revista especializada en SharePoint: CompartiMOSS.

Contacto

Enviame un correo :-)

martes, 24 de mayo de 2011

Limitaciones del uso de “deliverables” en Project Server 2007

La funcionalidad de "deliverables" permite manejar dependencias cruzadas entre proyectos en Project Server 2007. A diferencia de los vínculos entre proyectos, los "deliverables" establecen relaciones "blandas" que no impactan de ninguna manera la planificación del proyecto.

En este breve artículo, comentaré las limitaciones de esta herramienta. Si no han utilizado anteriormente esta funcionalidad, les recomiendo este post: http://www.epmcentral.com/articles/ps07deliverables.php. Les dejo también una breve comparación entre vínculos y deliverables:

image

Resumen de limitaciones:

Las principales limitaciones encontradas son:

  • Sólo se puede vincular un “deliverable” por tarea.
  • Es necesario tener creado un workspace en SharePoint para poder utilizar esta funcionalidad.
  • No se pueden crear dependencias entre tareas desde un master project, con lo cual si se desea utilizar dependencias dentro de un programa, se recomienda abrir cada proyecto en forma individual.

Respecto a las limitaciones en cuanto a performance y volumen, en general los lineamientos de Microsoft no establecen restricciones y/o recomendaciones para el uso de Deliverables. En particular no encontré información en la comunidad que notifique sobre algún tipo de limitación, tampoco en los libros de EPM.

Revisando un poco más, consulté el artículo Plan for software boundaries (Project Server) de Microsoft y tampoco establece limitaciones con los entregables, como si lo hace con otras entidades como:

  • Recursos
  • Líneas base
  • Profundidad y amplitud de proyectos insertados
  • Tareas por proyecto
  • Duración de tareas
  • Asignaciones por tarea
  • Campos personalizados locales
  • Campos campos corporativos

Limitaciones de SharePoint:

Existen otros tipos de limitaciones (propias de SharePoint) respecto a la cantidad de ítems que pueden verse en una vista: 2000. Sin embargo esta limitación es por vista (no por lista) con lo cual tampoco parece ser un problema ya que el tope por lista es de 5 millones de ítems. Este tema se puede consultar con mayor profundidad en el paper Working with large lists in Office SharePoint® Server 2007.

Una primera conclusión:

En principio, podríamos decir que:

  • No hay información oficial respecto de Microsoft sobre este tema y no lo menciona en los artículos de rendimiento.
  • En general las pruebas de laboratorio de esta funcionalidad siempre han tenido mejor rendimiento que las de vínculos entre proyectos. Esto se debe principalmente a la forma de implementación en Project Professional, que evita la necesidad de abrir varios proyectos a la vez.

De todas maneras, para poder evaluar el rendimiento, siempre será mejor hacer una prueba de laboratorio con el volumen que nuestra implementación necesite manejar.

Como siempre, espero haber sido útil. Hasta la próxima!

viernes, 20 de mayo de 2011

Los elementos web de Project Server 2010

[ Artículo publicado originalmente en la revista CompartiMOSS número 7: http://jpussacq.me/2011/03/21/compartimoss-no-7-nuevo-numero-de-la-revista-de-sharepoint-en-espaol/ ]

Project Server 2010 es la solución de Microsoft para implementaciones de EPM (Enterprise Project Management). Se trata de una aplicación montada sobre SharePoint Server 2010, lo cual nos brinda la posibilidad de aprovechar todo su potencial, por ejemplo en la utilización de la plataforma de elementos web. En la siguiente imagen se puede observar la arquitectura del producto y su integración con SharePoint:

image

Fuente: http://technet.microsoft.com/en-us/library/ff686786.aspx.

 

imageDato: para mayor información sobre Project Server 2010 consultar: http://www.microsoft.com/project/en/us/project-server-2010.aspx.

Al igual que sus versiones anteriores, Project Server posee un conjunto de elementos web que nos permiten personalizar nuestras implementaciones EPM. En este artículo vamos a presentar algunas de ellas. Afortunadamente, ahora poseemos un poco más de documentación sobre los elementos web de Project Server, no mucho, pero más que en las versiones anteriores. Dejo a continuación un enlace de Technet que les puede servir como punto de partida para empezar a trabajar en el tema: http://technet.microsoft.com/es-es/library/gg314584.aspx (Planeación de elementos web de Project Server 2010).

 

Los elementos web de Project Server 2010

Los primero que notarán al comenzar a trabajar con la versión 2010 de Project Server es que ahora disponemos de más elementos web para personalizar nuestros sitios y eso se descubre en el primer momento en el que intentamos agregar un elemento web. Vean la siguiente tabla:

Project Server 2010 Project Server 2007
Approval center
Issues
My queued jobs My queued jobs
My schedule My schedule
My tasks My tasks
My timesheet My timesheet
Project center Project center
Project details Project details
Project fields
Project fields (backwards compatible)
Project sites  
  Project workspaces
Project strategic impact
Reminders Reminders
Resource assignments Resource assignments
Resource center Resource center
Risks
  Task update requests
Team tasks Team tasks
Workflow status
Data analysis

 

En líneas generales, estos elementos web pueden utilizarse dentro del sitio principal de Project Server, más conocido como PWA o en cada uno de los sitios de proyecto. Pero hay que tener en cuenta que no todos los elementos web aplican a los dos tipos de sitios.

 

Un ejemplo sencillo

Project Server puede crear un sitio para cada uno de nuestros proyectos. Estos sitios de proyecto manejan comúnmente un conjunto de listas integradas con la funcionalidad de Project Server como Riesgos, Problemas, Documentos y Entregables. También presentan en su configuración predeterminada alguna de las listas estándar de SharePoint como Tareas, Calendario y Discusiones.

Estos sitios pueden personalizarse como veremos más adelante en la sección “Recuerden que esto es SharePoint”. En este breve ejemplo veremos como agregar un simple elemento web que muestre el gantt del proyecto en la página principal de nuestro sitio.

La siguiente imagen muestra el sitio que Project Server crea en forma predeterminada para cada proyecto:

image

Para ver el Gantt, agregamos un elemento web de detalle del proyecto. Vean el cambio en la siguiente imagen:

image

Nota de color: el Gantt de este proyecto fue creado utilizando Project Web Application, es decir, no he necesitado utilizar Project Professional como sucedía en las versiones anteriores de Project Server. Un impresionante avance :-)

 

La novedad – páginas de detalle

Una de las interesantes novedades de Project Server 2010 es su plataforma para el manejo de páginas de detalle de proyectos. Estas páginas, construidas bajo la infraestructura de SharePoint, son páginas de elementos web que soportan el proceso de gestión de demanda de una solución EPM, y pueden ser integradas con flujos de trabajo.

imageEstas páginas nos permiten que el usuario complete determinados campos personalizados de proyecto para un determinado tipo de proyecto corporativo (un tipo de proyecto corporativo es, en forma muy resumida, la combinación de un flujo de trabajo, páginas de detalle de proyecto, departamentos, plantilla de plan de proyecto y plantilla de sitio de proyecto).

Como primer paso iremos a la sección de administración de páginas de detalle de proyecto, en donde crearemos una nueva página de elementos web. Dentro de esa página agregaremos un elemento web de campos de proyecto en donde seleccionaremos que campos de proyectos deseamos que sean completados en esa página (se trata de una simple operación de creación de página en SharePoint, agregado de elemento web y configuración de propiedades)

image

Luego, vamos a la configuración de tipos de proyectos corporativos y agregamos nuestra página como página de detalle de proyectos, tal como muestra la imagen:

image

Ya hemos terminado. Ahora vamos a crear un nuevo proyecto. Cuando lo hacemos, debemos elegir el tipo de proyecto al que le hemos agregado la nueva página de detalle. Observen en la siguiente imagen como aparece un nuevo enlace llamado “SurPoint” debajo de “Project Details”:

image

Al entrar en ese enlace aparecen los campos que hemos elegido en tiempo de diseño:

image

Es realmente un gran avance respecto a lo que teníamos de funcionalidad en Project Server 2007.

Por último probaremos agregar el elemento web Estado del flujo de trabajo, el cual nos adiciona información de resumen del flujo de trabajo de este tipo de proyecto (este elemento web sólo aplica aquellos tipos de proyecto que posean flujos de trabajo). En la siguiente imagen vemos el tipo de información que nos provee este componente:

image

Esos fueron dos ejemplos, como para que puedan imaginar el potencial de las combinación de los elementos web de Project Server 2010 con las páginas de detalle de proyecto. Hay más por supuesto, pero excede el propósito de este artículo recorrer todas las opciones.

 

¡Ah! Recuerden que esto es SharePoint

Tal vez suene obvio lo que a continuación comentaré: siempre debemos recordar que si bien Project Server tiene su propio modelo de programación y parametrización, esta montado sobre SharePoint. Entonces tenemos infinitas posibilidades de extensión, que muchas veces no son aprovechadas, quizá porque en las implementaciones se pone foco principalmente en la parametrización de Project Server.

Sin embargo, es importante que sepamos aprovechar nuestros conocimientos de SharePoint, especialmente en los sitios de proyecto, que en mi experiencia suelen ser la funcionalidad más utilizada de una implementación EPM. En esos sitios podremos agregar todo tipo de elementos web e incluirlos en las plantillas de los sitios.

En Project Server 2010, tenemos una importante novedad y es que con el nuevo concepto de tipos de proyectos corporativos, podemos tener diferentes plantillas de sitios de proyecto (anteriormente sólo podíamos lograr esto vía programación).

A continuación les muestro dos imágenes de sitios de proyecto (una en versión 2007 y otra en versión 2010) para que se vea como se puede partir de algo estándar y evolucionar hacia algo más interesante:

image

image

 

Conclusiones

Como habrán podido observar, es mucho lo que podemos hacer en una implementación de EPM para extender y personalizar la misma a través de elementos web. En este artículo hemos comentado algunos casos, espero poder recorrer el resto de los elementos web en próximos artículos. Vale la pena aclarar que no es la única forma de extender una implementación EPM, ya que por supuesto disponemos de todas las formas de extensión disponibles en SharePoint sumadas al modelo de programación de Project Server. Si desean interiorizarse en el mismo, pueden comenzar por el centro de desarrollo de Project en MSDN: http://msdn.microsoft.com/en-us/office/aa905469.

Como siempre, espero haber sido de utilidad y hasta el próximo artículo,

 

Juan Pablo Pussacq Laborde

http://twitter.com/#!/jpussacq  |  http://surpoint.blogspot.com/

miércoles, 18 de mayo de 2011

¿Cómo ocultar campos en Sharepoint 2010 usando PowerShell?

Hola a todos, en una reciente implementación sobre Sharepoint 2010, me encontré con el pedido del usuario que ciertos campos que corresponden a la lista, no deberían estar disponibles al dar de alta un nuevo elemento en la lista. Esta misma problemática la habíamos tenido en Sharepoint 2007 y una forma elegante y fácil de hacerlo era usando JQuey y Javascrip (Preseleccionar u ocultar valores en las pantallas de alta).

Ahora bien, para Sharepoint 2010 estamos utilizando el poder de PowerShell integrado con Sharepoint 2010. Lo que tienen que hacer es tomar un editor de texto y generar un archivo PS1 con las siguientes instrucciones:

#Abro el sitio
$site = new-object Microsoft.SharePoint.SPSite("
http://MiServidor")
$web = $site.OpenWeb()
#Abro la lista 
$list = $web.Lists["MiLista"]
#Configuro Columna1, en este caso la columna no se ve en ningún formulario standard. 
$field = $list.Fields["Columna1"]
$field.ShowInNewForm = 0
$field.ShowInEditForm = 0
$field.ShowInDisplayForm = 0
$field.Update()
#set Columna2, en este caso, inhabilito la columna sólo para el alta.
$field = $list.Fields["Columna2"]
$field.ShowInNewForm = 0
$field.Update()
#Update y Dispose
$list.Update()
$web.Dispose()
$site.Dispose()

Luego lo ejecutan para el sitio correspondiente, y listo. Una forma sencilla de ocultar campos y con las herramientas que provee Sharepoint 2010.

Hasta el próximo truco.

Arquitectura de Project Server 2010 integrado con Reporting Services

Como muchos sabrán, es posible que SharePoint 2010 trabaje en forma integrada con SQL Server Reporting Services. Como Project Server 2010 es parte de SharePoint Server, entonces, por transitividad, Project Server 2010 también puede trabajar en forma integrada con Reporting Services.

Ahora: ¿qué consideraciones debemos tener a la hora de montar una granja que involucre a estas tres tecnologías?

  • SharePoint Server 2010
  • Project Server 2010
  • SQL Server 2008 R2 con Reporting Services

Bien, si consultamos el documento de Microsoft Estimate Performance and Capacity Requirements for Microsoft Project Server 2010, podremos ver que Microsoft nos recomienda varias configuraciones posibles según las características de nuestra instalación de Project Server. Este es un documento muy interesante de leer (se los recomiendo). Sin profundizar ahora en él, veremos que una de las primeras recomendaciones que nos ofrece es un clásico: la separación de los datos de la aplicación, para montar una arquitectura como la que muestra la siguiente figura:

image

En el documento, podrán ver el resto de las configuraciones posibles, pero sigamos ahora un paso más y analicemos la integración de Reporting Services con SharePoint. Antes de seguir, si no estás familiarizado con esta integración, te dejo algunos enlaces de artículos que escribí sobre este tema:

Si analizamos los requisitos de este tipo de  integración, veremos que, independientemente de la configuración de servidores que utilicemos, debemos tener instalado el servidor de reportes en una máquina que posea una instancia de SharePoint.

¿Qué significa una instancia de SharePoint?

La respuesta está en el artículo de MSDN: How to: Install and Configure SharePoint Integration on Multiple Servers. (cuidado con la versión en español: tiene algunos errores de traducción que pueden confundir)

En este artículo nos muestran dos ejemplos que configuración, que por supuesto podremos ampliar según nuestras necesidades. Ambos ejemplos son de dos servidores:

Ejemplo 1: el primer ejemplo nos brinda la posibilidad de instalar el servidor de datos sin SharePoint, pero este nos obliga a instalar la misma versión de SQL en los dos servidores, ya que se requiere instalar SSRS en la máquina 1 En la imagen se ve claramente:

image

Ejemplo 2: en el segundo ejemplo, se busca tener instalado SQL server en una sóla máquina. Como la instalación integrada con SharePoint, requiere SharePoint en el lugar en donde se instale el Report Server, debemos tener instalado SharePoint en las dos máquinas, tal como muestra la figura:

image

Detalle: realizar una instalación mínima del modelo de objetos de SharePoint 2010 en la máquina 2 implica instalar un servidor web front-end de SharePoint. Y en nuestro caso, esto implica también instalar los servicios de Project Server 2010 en los dos servidores.

imageConclusiones:

Si estamos instalando Project Server 2010 en forma integrada con Reporting Services de SQL Server 2008 R2, y nuestra instalación separa los datos de la aplicación, debemos tener en cuenta que:

  • Si optamos por la configuración 1, debemos instalar SQL Server en ambas máquinas.
  • Si optamos por la configuración 2, debemos instalar SharePoint y Project server en las dos máquinas.

Esto no sucede si la instalación es en modo “no integrada”. En ese caso, se instala SharePoint y Project server en una máquina y SQL Server en la segunda máquina.

Eso es todo por hoy, espero haber sido útil.

Hasta la próxima!

martes, 17 de mayo de 2011