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 :-)

lunes, 27 de mayo de 2013

Lecciones aprendidas de un proyecto de Workflow en Project Server 2010

En este breve artículo voy a resumir algunas lecciones aprendidas en un proyecto de implementación de flujo de trabajo en Project Server 2010. A pesar de que estos proyectos deben desarrollarse en Visual Studio (excepto que usen Nintex), no voy a centrar el artículo en cuestiones técnicas, sino en aspectos funcionales y de arquitectura. Esto se debe a que muchas veces no sabemos cuál es el mejor enfoque para resolver un problema en esta tecnología, debido fundamentalmente a la falta de información. A continuación, mis experiencias en casos reales, que intentan poner un granito más de arena a este mundo, en donde una búsqueda en Google arroja tan pocos resultados que nos hace sentir cierto temor...

clip_image001

 

Introducción

La funcionalidad de flujos de trabajo en Project Server se utiliza muchas veces para manejar el proceso de aprobación de los proyectos antes de su ejecución. Si bien la arquitectura de flujos de trabajo de Project Server está montada sobre la de SharePoint, posee muchos aspectos propietarios que nos dirigen con mucha fuerza hacia un formato de solución. Estos lineamientos principales se pueden resumir en los siguientes puntos:

1) A través de configuración se define un conjunto de fases y etapas que constituyen los pasos de nuestro flujo de trabajo. Las etapas son importantes porque pueden definir detalles como la obligatoriedad de los campos de empresa o la posibilidad de definirlos como sólo lectura. También pueden definir qué páginas de empresa pueden estar visibles. Y por último no debe olvidarse que servirán de filtros en nuestras vistas de Project Server.

2) La arquitectura de las PDPs nos permite crear páginas de SharePoint que se muestran dentro del contexto de uno o varias etapas de nuestro flujo de trabajo. Al ser páginas de SharePoint, nos permiten agregar cualquier tipo de elemento web, no es necesario usar elementos web exclusivos de Project Server. Esto nos brinda una posibilidad enorme de extender nuestros flujos de trabajo, con configuración y/o desarrollo.

3) Por último, los campos de empresa clásicos de Project Server, forman parte del corazón del flujo de trabajo. Constituyen la manera más sencilla de capturar información en cada uno de los pasos. Pero no es la única forma y tiene algunas limitaciones.

 

Lección 1) Maestro detalle

Es casi imposible escaparle a este requerimiento. En algún momento vamos a necesitar que en alguno de los pasos se cargue o visualice información de detalle. Ejemplos: productos, documentos, notas, etc. La forma más sencilla que se puede utilizar es creando una PDP que contenga varios elementos web: un elemento de la lista de SharePoint en donde guardaremos el detalle; un elemento de formulario InfoPath que sirva para crear elementos de detalle asociados al maestro (el proyecto); y un elemento de filtro de URL para pasar el dato de ID del Proyecto a los otros elementos web. Este esquema no requiere programación y es muy potente. Y puede ser mejorado con Client Object Model.

Más información en: http://surpoint.blogspot.com/2012/12/workflow-en-project-server-2010-como.html

 

Lección 2) Valores predeterminados en campos de empresa

Con el uso de las pdps y toda su estructura para manejo de campos de empresa, seguramente necesitarás completar valores predeterminados en los campos e incluso ocultarlos. Esta característica no funciona como se espera con las opciones fuera de la caja, en particular con la configuración del valor predeterminado del campo en la configuración de Project Server. Sin embargo, siempre es posible usar algo de código jQuery para ayudar. La siguiente porción de código, que pueden incluir en una CEWP muestra cómo resolver esta problemática:

$('input[title="'+id_campo+'"]').attr("value",texto_valor);

$('input[title="'+id_campo+'"]').attr("LTValue",guid_valor);

$('input[title="'+id_campo+'"]').parent().parent().parent().parent().parent().parent().css("display","none");

Más información en: http://surpoint.blogspot.com/2013/01/workflow-en-project-server-2010-valores.html

 

Lección 3) Manejo de rechazos en un paso del flujo de trabajo

Manejar vuelta a pasos anteriores siempre es algo complicado en un flujo de trabajo. Un requerimiento muy común, es que ante un rechazo, se pueda modificar la información y relanzar el proceso. Una forma sencilla de resolver esto en Project Server es:

• Asignar tareas a los distintos aprobadores, en la que puedan elegir entre Aprobar o Rechazar

• Ante una aprobación, pasar a la siguiente etapa

• Ante un rechazo terminar el flujo de trabajo

• Si el iniciador quiere volver a iniciar el proceso, deberá hacer uso de la opción Restar Workflow, para lo cual habrá que haberle asignado el permiso correspondiente.

• Lo bueno es que la información de campos de empresa no se pierde, así que sólo debe modificar lo que cambió

• Una posible mejora es crear una lista en SharePoint que muestre un log de aprobaciones y rechazos histórico, para que el usuario pueda conocer en cada caso las razones de los rechazos.

clip_image002

 

Lección 4) Asignación de tareas basada en roles

Un requerimiento típico es que las tareas de aprobación de cada paso deban ser asignadas a diferentes personas, dependiendo de una condición, basada en algún campo completado en algún paso. Una forma de resolver esto es crear una lista en SharePoint que maneje las reglas de asignación. El usuario configura en esta lista la regla, por ejemplo: "cuando el país es Argentina y el sector es Marketing, entonces el grupo de asignación es Gerentes de Marketing de Argentina."

Internamente, el flujo de trabajo consulta la lista con el fin de obtener el grupo de asignación para cierta condición. Ese grupo, no es más que un grupo de SharePoint que puede incluir uno o varios miembros. Cuando el flujo de trabajo asigna la tarea al grupo, SharePoint envía el mail en forma automática. Este tipo de reglas le dan enorme flexibilidad al flujo de trabajo.

 

Lección 5) Visibilidad de PDPs

Project Server nos permite definir qué PDP puede estar visible en cada etapa del flujo de trabajo. Esto nos da mucho poder con poco esfuerzo. A continuación enumero sólo algunos ejemplos, como para entender el alcance funcional:

• Diferentes campos de empresa en cada etapa

• Habilitar la PDP de Schedule sólo a partir de una determinada etapa

• Mostrar información de una lista de SharePoint de forma distinta en diferentes etapas. Por ejemplo con opciones de creación y edición en una etapa, y con opciones de sólo lectura en otras etapas

• Diferentes páginas de estado en diferentes etapas

clip_image004

Estos fueron sólo algunos ejemplos y nunca debemos olvidar la innumerable cantidad de opciones que tenemos al poder personalizarlas con diferentes elementos:

• Varios elementos web de Project Fields, que nos permiten agrupar la información.

• Infopath

• Reporting Services

• Listas de SharePoint

• CEWP con código JavaScript y con Client Object Model

• Librearías de documentos

• Estado visual del flujo de trabajo

• Elementos de filtro por URL

• Etc.

Más información en:

• Fases y etapas: http://surpoint.blogspot.com/2012/11/workflow-en-project-server-2010-como_3147.html

• PDPs: http://surpoint.blogspot.com/2012/11/workflow-en-project-server-2010-como.html

• PDP de estado: http://surpoint.blogspot.com/2012/11/workflow-en-project-server-2010-como_30.html

 

Lección 6) Sobre el uso de campos de empresa

Los campos de empresa constituyen la alternativa natural para capturar información en un flujo de trabajo.

clip_image006

Esto está muy bien y es recomendable, pero conviene tener en cuenta algunas cuestiones:

• La cantidad de campos puede afectar el rendimiento de Project Server. De hecho es una de las variables para realizar un dimensionamiento de la arquitectura.

• Los campos aparecen en Project Pro y la única forma de no mostrarlos es usando la funcionalidad de departamentos.

• Modificar un campo desde un flujo de trabajo implica operaciones costosas como la desprotección y la protección del proyecto. Y lo más importante es que nadie verá los cambios hasta que no se publique el proyecto.

• Los campos de empresa no manejan información repetitiva como las relaciones maestro detalle.

• Los campos de empresa no tiene flexibilidad en el manejo de tipos de datos, ni permiten validaciones sofisticadas.

Es por ello que en algunos casos, la alternativa de usar listas de SharePoint nos permite soluciones más livianas y flexibles. Es absolutamente recomendable usar esta alternativa en muchas situaciones, no en todas por supuesto.

 

Lección 7) Seguridad

A diferencia de la mayoría de las implementaciones de Project Server, en donde la configuración estándar suele cubrir muchos requerimientos, cuando implementamos un flujo de trabajo, aparecen algunas necesidades que a continuación enumero:

• La necesidad de crear un grupo y una categoría para los iniciadores de flujos de trabajo. Este grupo no suele coincidir con los líderes de proyecto y puede necesitar permisos especiales, por ejemplo para reiniciar un flujo de trabajo.

• La necesidad de crear un grupo para los que aprueban pasos del flujo de trabajo.

• La necesidad de crear grupos en SharePoint para poder acceder a listas como la de tareas, pero también a listas especiales que hayamos creado para capturar información durante el proceso.

• Por último, es posible que necesitemos crear un grupo de administración de la configuración del flujo de trabajo.

Más información en: http://surpoint.blogspot.com/2013/01/Workflow-ProjectServer-Seguridad.html

 

Conclusiones

En este breve artículo he intentado presentar algunas lecciones aprendidas en proyectos de gestión de la demanda en Project Server 2010. Lamentablemente es complicado encontrar suficiente información sobre este tema y a veces no es sencillo saber si estamos tomando la decisión correcta. Por ello este artículo: para compartir mi experiencia.

¿¿Y cuál ha sido tu experiencia???

Hasta la próxima!

 

Juan Pablo Pussacq Laborde
SharePoint MVP
Blog: http://surpoint.blogspot.com/
Facebook: http://facebook.com/surpointblog/
Twitter: http://twitter.com/jpussacq/

viernes, 17 de mayo de 2013

Flujos de trabajo en SharePoint 2007 asociados a tipos de contenido


Requerimiento
Poder asociar flujos de trabajo a tipos de contenido.
  • Esto permitiría por ejemplo que el mismo flujo de trabajo se aplique en un conjunto de sitios.
  • Eso también permite que los cambios al flujo de trabajo sean centralizados, facilitando el mantenimiento.
¿Puedo asociar un flujo de trabajo a un tipo de contenido con SharePoint Designer 2007?
No, no es posible. En SharePoint Designer 2007, sólo se puede asociar el flujo de trabajo a librerías o listas. Esta definición puede encontrarse en: http://msdn.microsoft.com/es-es/library/ms414204(v=office.12).aspx
En SharePoint 2010, el enfoque cambia, porque se pueden crear flujos de trabajo re-usables y luego asociarlos a un tipo de contenido.
La solución con Visual Studio
Si creamos un flujo de trabajo con Visual Studio, tenemos tres posibles métodos de asociación:
  • A una lista o librería
  • A un tipo de contenido. Imaginemos por ejemplo asociarlo al tipo de contenido “documento” lo que haría que el flujo de trabajo se ejecute cada vez que se crea un documento en cualquier librería de documentos, de cualquier sitio de la colección de sitios
  • A un tipo de contenido, dentro de una lista: lo que nos permite que un flujo de trabajo se ejecute sólo para algunos tipos de contenido dentro de una lista.
La solución mediante Visual Studio es más costosa porque se hace a través de código, pero definitivamente más flexible cuando necesitamos que un flujo de trabajo se utilice en muchos sitios a la vez.

martes, 7 de mayo de 2013

The Enterprise global already contains a group named 'No Group'

Síntomas del problema

Existen dos síntomas para este problema, los cuales se dan bajo las siguientes condiciones:

  • El proyecto es creado desde PWA
  • El proyecto usa un EPT sin flujo de trabajo
  • El proyecto se abre luego desde Project Pro
Síntoma 1:

El proyecto se crea con un plantilla de plan sencilla con sólo dos tareas desde PWA.
Al abrir el proyecto desde Project Pro aparece el siguiente mensaje:

"The Enterprise global already contains a group named 'No Group'"

Este grupo no puede ser luego eliminado desde el Organizador.

Síntoma 2:

El proyecto se crea con o sin plantilla de plan desde PWA.
Luego de utilizar la funcionalidad de Build Team, los recursos no aparecen para ser seleccionados en las tareas, exceptuando que se salve el proyecto luego de haber creado el equipo.

Causa del problema

La causa es un posible error luego de la migración desde Project Server 2007 a Project Server 2010. Aparentemente no habría terminado en forma correcta la desactivación del modo de compatibilidad hacia atrás: BCM - Project 2007 Compatibility Mode.

¿Cómo se puede visualizar la causa?
  1. La opción de BCM se encuentra desactivada e inhabilitada en Adittional Server Settings
  2. Se crear un proyecto desde PWA usando el EPT default
  3. Se abre el proyecto desde Project Pro
En la parte superior de la pantalla se observa el mensaje "Compatibility Mode". Este mensaje no debería aparecer, porque el servidor no está corriendo en modo de compatibilidad.

Solución al problema

La solución consiste en abrir la Enterprise Global (que estaría corrupta) y hacer un cambio menor, para que Project Server note que hay un cambio y decida almacenar una nueva versión de la misma. Un cambio menor puede ser simplemente cambiar el ancho de una columna.

Luego de realizar el cambio, grabar la Enterprise Global.

A partir de ahí sucede lo siguiente:
  • Los proyectos nuevos ya no experimentan el problema
  • En los proyectos que posean el problema, se puede utilizar la opción "Replace" en el momento en que aparece el mensaje "The Enterprise global already contains a group named 'No Group'" y luego salvar el proyecto.
Los proyectos no deberían presentar ahora la leyenda "Compatibility Mode"

Tener en cuenta que en algunos casos puede ser necesario limpiar el caché para que se tome la nueva versión de la Enterprise Global. Esto no aplica a los creados desde PWA porque no usan caché.

lunes, 6 de mayo de 2013

Sharepoint Messenger

Les dejo este interesante proyecto para implementar chat o messenger en SharePoint 2010: