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...

 

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.

 

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

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.

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/

Leer más...

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.

Leer más...

Workflow en Project Server 2010 ¿Cómo crear información de maestro detalle en una PDP? Enfoque 2

Las PDPs nos permiten capturar información que se almacenan en campos personalizados de Project Server. Sin embargo, un requerimiento muy común es que se necesiten cargar datos repetitivos asociados a un proyecto, como por ejemplo:

• Productos afectados
• Lista de stakeholders
• Documentos
• Etc…

En un artículo previo, explicamos como generar información de tipo maestro-detalle en Project Server utilizando InfoPath. Este enfoque funciona bien, exceptuando en los ambientes en donde el separador entre el apellido y el nombre del usuario es un ";". En esto caso, se produce un error al editar el formulario en InfoPath. Para resolverlo hay que utilizar otro separador, lo cual puede ser complicado en entornos que utilicen sincronización con AD.

Es por ello que estuve trabajando en una alternativa que no utilize InfoPath. Descarté también el uso de Client Object Model para armar una pantalla de alta, principalmente porque me obligaría a cambiar ese desarrollo cada vez que se haga un cambio en las columnas de las litas

El enfoque propuesto

• Usar las pantallas estándar de SharePoint.
• Alta
• Crear un link para llamar a la pantalla de alta en forma modal
• Pasarle como parámetro el ID del proyecto
• Completar el campo de ID con el dato recibido en la URL
• Ocultar el campo
• Refrescar la pantalla en caso de alta
• Modificación / Baja
• Usar la pantalla de Display para arrancar estas operaciones. Porque si se arranca del Edit, al eliminar el registro, no se vuelve a la PDP original
• Código para ocultar la clave del maestro
• Código
• Formado por cuatro CEWP, una para la PDP y las otras tres para las pantallas dispForm, EditForm y NewForm

A continuación, trasncribo el código utilizado:

El código para la PDP

<script src="/PWA/Internal/jquery-1.4.2.min.js" type="text/javascript"></script>

<script type="text/javascript">

 $("td:contains('There are no items to show in this view of the'):last").empty();

 function Callback (result, target) {
     if (result == SP.UI.DialogResult.OK) {
         window.location.reload();
     }

 }

 function AbrirVentanaModal( pUrl ) {  
   SP.UI.ModalDialog.showModalDialog(   
     {  
       url: pUrl,
       //width: 700,  
       //height: 600,
       dialogReturnValueCallback: Callback  
       //title: pTitulo  
     }  
   );  
 }

 function url_param ( name ){  
  name = name.replace(/[\[]/,"\\\[").replace(/[\]]/,"\\\]"); 
  var regexS = "[\\?&]"+name+"=([^&#]*)"; 
  var regex = new RegExp( regexS ); 
  var results = regex.exec( window.location.href ); 
  if( results == null ) 
    return "";
   else 
    return results[1];
 }

</script>

 <table><tr><td class="ms-addnew" style="padding-bottom: 3px"><span style="height:10px;width:10px;position:relative;display:inline-block;overflow:hidden;" class="s4-clust"><img src="/_layouts/images/fgimg.png" alt="" style="left:-0px !important;top:-128px !important;position:absolute;" /></span>&nbsp;<a class="ms-addnew" id="NewFinancialData" href="javascript: var PU=url_param('projuid'); AbrirVentanaModal('/PWA/Lists/Financial%20Data/NewForm.aspx?ProjUid='+PU)" target="_self">Add financial data</a></td></tr><tr><td><img src="/_layouts/images/blank.gif" width="1" height="5" alt="" /></td></tr></table>

El código para NewForm.aspx

<script src="/PWA/Internal/jquery-1.4.2.min.js" type="text/javascript"></script>

<script type="text/javascript">

 // Esto lo hago porque el Editar estándar desde la PDP vuelve a cualquier lado luego de eliminar, incluso cambiando el source
 $('input[title="Title"]').attr("value","Edit");
 $('input[title="Title"]').parent().parent().parent().css("display","none");
 
// Cargo el dato de clave del Maestro
 PU = url_param ('ProjUid');
 $('input[title="ProjUID"]').attr("value",PU);
 $('input[title="ProjUID"]').parent().parent().parent().css("display","none");

 function url_param ( name ){  
  name = name.replace(/[\[]/,"\\\[").replace(/[\]]/,"\\\]"); 
  var regexS = "[\\?&]"+name+"=([^&#]*)"; 
  var regex = new RegExp( regexS ); 
  var results = regex.exec( window.location.href ); 
  if( results == null ) 
    return "";
   else 
    return results[1];
 }

</script>

El código para EditForm.aspx

<script src="/PWA/Internal/jquery-1.4.2.min.js" type="text/javascript"></script>

<script type="text/javascript">

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

</script>

El código para DispForm.aspx

<script src="/PWA/Internal/jquery-1.4.2.min.js" type="text/javascript"></script>

<script type="text/javascript">

 $('a[name="SPBookmark_Title"]').parent().parent().parent().css("display","none");
 $('a[name="SPBookmark_ProjUID"]').parent().parent().parent().css("display","none");

</script>

Enlaces relacionados

• http://blogbaris.blogspot.com/2012/09/open-sharepoint-2010-display-edit-new.html
• http://msdn.microsoft.com/en-us/library/ff410058.aspx
• http://saifalmaluk.wordpress.com/tag/sp-ui-modaldialog/
• http://www.spdeveloper.co.in/articles/pages/using-sharepoint-2010-modal-dialogs.aspx

Hasta la próxima!

Leer más...

Workflow en Project Server 2010 - Problemas con Submit desde PDPs que non poseen campos de empresa

Cuando presionamos el botón SUBMIT desde algunas PDPs, nos encontramos con el problema de que la página se queda aparentemente esperando un "check in" en forma indefinida.

Por lo que pude observar, esto se da en las páginas que no poseen campos de empresa y que poseen elementos web de lista como la que explicamos anteriormente en este artículo.

La solución en estos casos, aunque poco ortodoxa es:

1. Agregar un elemento web de "Project Fields"
2. Insertar al menos un campo, por ejemplo el nombre del proyecto
3. Ocultar el elemento web

Funciona...

Leer más...

Pruebas de correo electrónico con formato HTML en Outlook

Si te ha tocado trabajar dándole formato a los correos electrónicos enviados por ejemplo desde un flujo de trabajo de SharePoint, habrás notado que Outlook tiene muchas diferencias con otros clientes de correo. Incluso, lo que se ve bien en OWA no se verá igual en Outlook.

Es por eso que a continuación te dejo algunos recursos que me han sido muy útiles en este tipo de pruebas. Espero te sean útiles y desde ya te agradezco que compartas los que conozcas:

• Breve paso a paso que nos explica cómo probar nuestros correos en Outlook sin enviarlos: http://ucdavistechtalk.wordpress.com/2012/04/27/how-to-send-an-html-e-mail-from-outlook-2010/
• Sitio que nos permite realizar pruebas en Outlook 2003 con la versión gratuita. Si bien eso no aporta mucho, es útil el validador de código: http://www.emailonacid.com
• Excelente comparador de características de CSS soportadas por cada cliente de correo. Fundamental: http://www.campaignmonitor.com/css/
• Información oficial de Microsoft: http://msdn.microsoft.com/en-us/library/aa338201(v=office.12).aspx

Hasta las próxima!

Leer más...

Workflow en Project Server 2010 ¿Valores predeterminados en campos de empresa en una PDP?

Cuando trabajamos con PDPs en Project Server 2010, no es sencillo establecer un valor predeterminado para un campo de empresa de tipo obligatorio. Si bien la configuración de campos de empresa permite establecer valores predeterminados, estos funcionan en forma correcta en Project Pro, pero no en la forma esperada dentro de PWA.
Es por ello que en este breve artículo vamos a explicar como manejar los valores predeterminados utilizando un poco de JavaScript. El enfoque de trabajo es el siguiente:

• Utilizar JavaScript para configurar el valor predeterminado de los campos, sólo si se trata de la PDP usada en una creación de proyecto.
• Utilizar JavaScript para ocultar dichos campos.

Separaremos el código en dos archivos:

• Un archivo con el contenido de la CEWP que se insertará en la PDP, debajo de los campos de empresa. .
• Un archivo de constantes con los guids y demás valores de cada campo.

El código del archivo de contantes

/* Valor predeterminado para el campo Stage en la PDP Request */

STAGE_ID = "ctl00_m_g_80e4b936_45c6_442d_b8de_a93ac30efea1_ctl00_pfp_Repeater_ctl06_idCF_976b5670-7e3b-407d-ad53-1d0343fc3f0c";
STAGE_GUID = "966707bd-8f55-4f0e-97d1-8c94256c55a3";
STAGE_TEXTO = "Planned";

/* Valor predeterminado para el campo Program en la PDP Request */

PROGRAM_ID = "ctl00_m_g_80e4b936_45c6_442d_b8de_a93ac30efea1_ctl00_pfp_Repeater_ctl08_idCF_38852eb9-5126-4fb2-b1ef-45e6edfeb116";
PROGRAM_GUID = "d74da6ee-48ce-491a-ad6e-416da8c99ab2";
PROGRAM_TEXTO = "Yes";

El código de la CEWP 

<script src="/PWA/Internal/jquery-1.4.2.min.js" type="text/javascript"></script>
<script src="/PWA/Internal/constantes_workflow.js" type="text/javascript"></script>

<script type="text/javascript">

 $(document).ready(function() { 

     predeterminar_campo (STAGE_ID, STAGE_GUID, STAGE_TEXTO);
     predeterminar_campo (PROGRAM_ID, PROGRAM_GUID, PROGRAM_TEXTO);

   });


function predeterminar_campo ( id_campo, guid_valor, texto_valor ) {

     if ( workflow_url_param ( "NewProject" ) == "yes" ) {
    
         // Valor del campo
         $('#'+id_campo).attr("value",texto_valor);

         // ID del valor del campo
        $('#'+id_campo).attr("LTValue",guid_valor);
     
         }

     // Oculto la fila de la tabla que contiene el campo
    $('#'+id_campo).parent().parent().parent().parent().parent().parent().css("display","none");

}

function workflow_url_param ( name ){  
 name = name.replace(/[\[]/,"\\\[").replace(/[\]]/,"\\\]"); 
 var regexS = "[\\?&]"+name+"=([^&#]*)"; 
 var regex = new RegExp( regexS ); 
 var results = regex.exec( window.location.href ); 
 if( results == null ) 
   return "";
  else 
   return results[1];
}

</script>

Opción 2

Una segunda opción que he probado y me ha dado buenos (mejores) resultados consiste en buscar el atributo title en lugar del id. Los cambios con:

En el archivo de constantes:


STAGE_ID = "Stage";

En la CEWP:


$('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");

Conclusión

Esta ha sido una forma de resolver el inconveniente de los valores predeterminados en las PDPs de flujos de trabajo en Project Server 2010, utilizando código de cliente JavaScript. Espero les haya resultado útil.

Leer más...

Workflow en Project Server 2010 ¿Cómo ocultar los campos personalizados de un WF en Project Pro?

La respuesta en este artículo: http://www.epmcentral.com/pjadmin/pjserver10/hidedemandfields.php

Leer más...

Workflow en Project Server 2010 - Seguridad

Este breve artículo pretende describir algunos temas acerca de los permisos necesarios para trabajar con flujos de trabajo en Project Server 2010.

Los permisos estándar

Los permisos específicos para manejo de flujos de trabajos son:

Permisos globales

• Change Workflow: le permite a un usuario cambiar el EPT (enterprise project type) de un proyecto.
  • Este permiso engloba:
    • La opción de cambiar un EPT
    • La opción de reiniciar un flujo de trabajo (restart workflow)

• Manage Workflow and Project Details Pages: permiso para administrar flujos de trabajo y PDPs.
  • Este permiso hablita o inhabilita todas las opciones de flujo de trabajo disponibles en Server Settings en la sección "Workflow and Project Detail Pages":

Estos permisos están asignados en forma predeterminada al grupo de Administradores únicamente.

 

 

Permisos de categorías

 

No existen permisos exclusivos de flujos de flujos de trabajo en categorías.

 

 

Permisos en SharePoint

Existen en SharePoint los siguientes grupos relacionados con flujos de trabajo:

• Workflow and Project Detail Pages Administrators Group (Microsoft Project Server)
• Project Managers Group  (Microsoft Project Server)
• Team Members Group (Microsoft Project Server)
• Web Administrators Group (Microsoft Project Server)

Estos grupos tienen algún tipo de acceso a las siguientes listas:

• Project Details Pages
• Project Server Workflow History
• Project Server Workflow Tasks

En particular, los projects managers y los team members tienen permisos de team members (colaboración básicamente) en la lista de tareas del flujo de trabajo (Project Server Workflow Tasks) y en la de historial (Project Server Workflow History). También tienen permiso de lectura en la librería de PDPs (Project Details Pages).

 

Esto nos permite entender que usuarios pueden modificar tareas de flujo de trabajo.

 

El grupo de administradores de PDPs tiene permiso de administrador web en las tres listas.

 

Lo no estándar

Es posible que tengamos algunos requerimientos de seguridad específicos, que hagan necesario crear permisos especiales. A continuación veremos algunos ejemplos. De todas maneras, en la medida de lo posible, siempre es conveniente utilizar los permisos predeterminados.

 

Requerimiento 1: iniciadores de flujo de trabajo

 

Requerimiento

Se necesita que el grupo de personas que inicie los flujos de trabajo pueda:

• Iniciar un flujo, lo que implica crear un proyecto
• No pueda modificar flujos de trabajo en donde no es el Owner, sólo los suyos
• Puede reiniciar un flujo de trabajo

 

Enfoque propuesto

• Se trabajará con un grupo y una categoría especial que no se solape con otros existentes que puedan haber surgido en base a necesidades específicas
• Se requiere asignar el permiso "Change Workflow" sólo disponible en Administradores.
• Se requiere una categoría parecida a My Projects, que sólo permita modificar los proyectos en donde el iniciador es el owner

Nueva categoría: mis flujos de trabajo

 

Las reglas dinámicas de la categoría se configuran de la siguiente forma:

 

Nuevo grupo: iniciadores de flujos de trabajo

 

A este nuevo grupo se le asignarán los siguientes permisos para la categoría “mis flujos de trabajo”:

• Build Team on Project
• Create New Task Asignment
• Creat Object Links
• Delete Project
• Edit Project Summary Fields
• Manage Basic Project Security
• Open Project
• Publish Project
• Save Project to Project Server
• View Project Schedule in Project Web App
• View Project Site
• View Project Summary in Project Center
• Asign Resource
• View Enterprise Resource Data
• View Resource Assignments in Assignment Views

Y los siguientes permisos globales:

• Change Workflow
• Change Password
• Log On
• Manage Personal Notifications
• Build Team on Project
• New Project
• Open Project Template
• Vie Resource Plan
• View Project Center
• View Project Schedule Views
• View Task Center
• View Team Builder

Nuevo grupo de SharePoint: Workflows Initiators (Project Server)

 

Es grupo necesita permiso de Team Members en las siguientes librerías de PWA:

• Project Server Workflow History
• Project Server Workflow Tasks

Y permiso de Lectura en:

• Project Details Pages

Es posible que hallamos creado alguna lista para cargar datos en forma de tabla durante alguna de las etapas del flujo de trabajo. Si es así, no debemos olvidar darle permiso al iniciador o a los aprobadores de tareas sobre ese lista. Eso dependerá de nuestras reglas de negocios. Una posible alternativa sería:

• Colaboración para el iniciador
• Lectura para el resto

Nota: es posible que necesitemos quebrar la herencia de permisos en esta nueva lista.

 

Requerimiento 2: los aprobadores de tareas

Requerimiento

Se necesita que el grupo de personas a las que se les asignan tareas de flujo de trabajo pueda:

• Editar y completar las tareas
• Ver los detalles del proyecto

Enfoque propuesto

• Se trabajará con un grupo y una categoría especial que no se solape con otros existentes que puedan haber surgido en base a necesidades específicas

Nueva categoría: mis aprobaciones de flujos de trabajo

 

Se crea una categoría llamada “mis aprobaciones de flujos de trabajo” con la siguiente configuración:

 

Nuevo grupo: aprobadores de flujos de trabajo

 

A este nuevo grupo se le asignarán los siguientes permisos para la categoría “mis flujos de trabajo”:

• Open Project
• View Project Schedule in Project Web App
• View Project Site
• View Project Summary in Project Center
• View Enterprise Resource Data
• View Resource Assignments in Assignment Views

Y los siguientes permisos globales:

• Change Password
• Log On
• Manage Personal Notifications

 

Nuevo grupo de SharePoint: Workflows Aprobers (Project Server)

Es grupo necesita permiso de Team Members en las siguientes librerías de PWA:

• Project Server Workflow History
• Project Server Workflow Tasks

Y permiso de Lectura en:

• Project Details Pages

 

Conclusión

La funcionalidad de gestión de la demanda de Project Server es flexible, lo cual hace que podamos implementar procesos de negocio complejos y diferentes entre sí. Esa puede ser una razón por la cual necesitemos modificar la seguridad estándar de flujos de trabajo. En este breve artículo, hemos explicado que es lo que viene fuera de la caja y dimos ejemplo de personalizaciones.

Cualquier duda me consultan.

 

Bibliografía

• Project Server 2010 global permissions: http://technet.microsoft.com/en-us/library/cc197631(v=office.14).aspx
• Project Server 2010 category permissions: http://technet.microsoft.com/en-us/library/cc197622(v=office.14).aspx
• Project Server 2010 default group permissions: http://technet.microsoft.com/en-us/library/cc197658(v=office.14).aspx

Leer más...

Workflow en Project Server 2010 ¿Cómo crear información de maestro detalle en una PDP?

Anteriormente vimos como crear una PDP para flujos de trabajo de Project Server 2010. Las PDPs nos permiten capturar información que se almacenan en campos personalizados de Project Server. Sin embargo, un requerimiento muy común es que se necesiten cargar datos repetitivos asociados a un proyecto, como por ejemplo:

• Productos afectados
• Lista de stakeholders
• Documentos
• Etc…

A continuación les presento una solución basada en un excelente artículo de Andrew Lavinsky, el cual les recomiendo que lean, más un complemento de Naveen Kumar.

El enfoque de la solución es sencillo:

1. Se crear una lista en SharePoint que almacene la información de detalle.
2. Se modifica la pantalla de alta de esa lista con InfoPath para ocultar el campo de relación con el maestro: Project UID
3. Se agregan tres elementos web en la PDP
1. Un filtro por URL
2. La pantalla de alta en InfoPath
3. La pantalla con la información de detalle de la lista
4. Mediante conexiones, el filtro por URL provee el dato de ID del proyecto a los otros dos elementos web
5. Se agrega algo de código en jQuery para solucionar un pequeño comportamiento  no deseado

El resultado es una pantalla como la que vemos aquí:

 

La lista a crear en SharePoint

Es una lista de tipo “custom” con la única salvedad de contener un campo para el ID del proyecto de tipo texto de una línea:

 

La modificación de la pantalla de alta de la lista

Simplemente hacemos clic en el botón “customize form”, recuerden que en SharePoint 2010, podemos modificar estas pantallas con InfoPath:

Luego, eliminamos la fila que contiene el campo ProjectUID, lo que hará que no esté visible:

Y agregamos un botón debajo, al que le modificaremos las propiedades para que sea de tipo “Submit”:

Luego, publicamos nuestro formulario:

 

Agregando los elementos web a la PDP…

1) Primero agregamos un elemento web para filtro de URL:

Con esta configuración:

2) Luego agregamos el elemento web de nuestra lista de SharePoint

Este es un elemento estándar, el punto importante es que quede conectado al elemento web de filtro por URL

3) Finalmente agregamos un elemento web de Infopath

Elegimos nuestro formulario y verificamos que la propiedad “Submit behavior” quede configurada en: “Close the form”

Este elemento hay que conectarlo al de filtro por URL para que el dato ProjectUID de la URL sirva para completar en forma automática el de nuestro formulario alta. Aquí es donde efectivamente estaremos estableciendo el vínculo!

 

Un último detalle

En el paso anterior usamos la opción “Close the form” en lugar de “Open a new form” que hubiese sido la opción lógica. La razón es que la opción “Open a new form” no funciona luego del primer submit, los filtros dejan de aplicarse. Por lo cual nuestra segunda alta quedará con un Project UID nulo!!!

Es por ello que usamos “Close the form”, que tiene un problema bastante feo. Luego de dar un alta, desaparece la pantalla de alta con un cartel que dice que el formulario se ha cerrado. El usuario sólo puede volver a hacer aparecer esta pantalla si refresca la página.

Como este comportamiento es bastante anti natural, la solución poco convencional es:

• Agregar una CEWP
• Que busque el mensaje que dice que el formulario se ha cerrado
• Y que si lo encuentra, recargue la página.

Sí, es feo y lo peor es que genera un doble postback, pero es una alternativa interesante. El código de la CEWP es:

<script src="/PWA/Internal/jquery-1.4.2.min.js" type="text/javascript"></script>

<script type="text/javascript">

$(document).ready(function() {

     if( $('#DialogFinalMessage').children().length>0 ) {
       window.location.href = window.location.href;
       }

   });

</script>

 

Conclusión

Esta es una forma sencilla de implementar maestro detalle en las PDPs de Project Server 2010 usando herramientas conocidas. Y lo más importante es que nos brinda un potencial enorme al poder incorporar información muchos más rica en nuestros flujos de trabajo.

Espero les resulte útil!

Leer más...

Workflow en Project Server 2010 ¿Cómo crear fases y etapas?

Las fases y etapas permiten estructura un flujo de trabajo de gestión de la demanda dentro de Project Server 2010. Mientras que las fases son un simple agrupamiento de etapas, las etapas tienen algunas características más avanzadas tales como:

• Determinar que PDPs están visibles
• Determinar cuál es la PDP para mostrar el estado del flujo de trabajo
• Determinar si un campo personalizado es obligatorio o de sólo lectura en esa etapa

A continuación se enumeran los pasos para crear fases y etapas:

 

Crear una fase

Ir a Project Server / Server Settings / Workflow and Project Details Pages

Clic en Workflow Phases

Clic en New Workflow Phase

 

A continuación sólo se necesita ingresar el nombre, la descripción y salvar:

Una vez creadas las fases, se obtiene algo como lo siguiente:

El siguiente paso es la creación de etapas.

 

Crear una etapa

Antes de crear una etapa, es importante que tengamos creados:

• Las fases
• Los campos personalizados
• Las PDPs de ingreso de datos
• Las PDPs de estado del flujo de trabajo

Con toda esa información, ir a Project Server / Server Settings / Workflow and Project Details Pages

 

Clic en Workflow Stages

Clic en New Workflow Stage

 

A continuación completar los siguientes campos:

Existen otros datos que se pueden almacenar, pero dependerán de la lógica del flujo de trabajo.

Obtendremos una lista como la siguiente:

Seguir el mismo procedimiento para el resto de las etapas.

Leer más...

Workflow en Project Server 2010 ¿Cómo crear una PDP de estado del flujo de trabajo?

Anteriormente se detalló qué son las PDPs y se explicó cómo crear una PDP que permita completar campos personalizados. En este punto explicaremos como crear una PDP que sirva para mostrar el estado de un flujo de trabajo, básicamente en qué punto se encuentra y cuáles son los próximos pasos.

 

Ir a la sección de PDPs

Ir a Project Server / Server Settings / Workflow and Project Details Pages

Clic en Project Details Pages

 

Crear la página

Clic en New Document

Completar el nombre, elegir el layout y presionar Create:

 

Agregar los elementos web

En en el área “Left Column” clic en “Add a Web Part”

Seleccionar la categoría Project Web App y el elemento web Workflow Status. Este elemento nos permitirá mostrar el estado de avance del flujo de trabajo.

Configurar lo que deseamos ver:

Al momento de crear la página, la misma no estará conectada a un flujo de trabajo, motivo por el cual aparecerá un mensaje como el siguiente:

Luego hacer clic en Apply y en Stop Editing.

Por supuesto, pueden agregarse otros elementos web de SharePoint o PWA en este punto.

Cuando está página se use dentro de un flujo de trabajo, tendrá un aspecto como el siguiente:

Fuente: http://msdn.microsoft.com/en-us/library/office/ee767699(v=office.14).aspx

 

Configurar el tipo de página

Existen tres tipos de páginas para las PDPs. Este dato se configura editando las propiedades de la página. En este caso, utilizaremos el valor “Workflow Status”:

Ese fue el último paso. Está página será utilizada al momento de crear las etapas del flujo de trabajo.

Leer más...

Workflow en Project Server 2010 ¿Cómo crear un EPT?

Los EPTs (Enterprise Project Types) de Project Server 2010 permiten tipificar los proyectos. Agrupan las siguientes características:

• Flujo de trabajo
• Plantilla de plan de trabajo (Gantt)
• Plantilla de sitio de proyecto (SharePoint)

Aparecen en PWA como la opción de crear un proyecto o una iniciativa desde la web:

A continuación se enumeran los pasos para crear un EPT.

 

Ir a la sección de EPTs

Ir a Project Server / Server Settings / Workflow and Project Details Pages

Clic en Enterprise Project Types

 

Crear el EPT

Clic en New Enterprise Project Type

Completar la siguiente información y salvar:

• Nombre: es el nombre que aparecerá al momento de elegir el tipo de proyecto a crear. 
• Description
• Site Workflow Association: acá asociamos el flujo de trabajo creado en Visual Studio. 
• New Project Page / Project Details Pages. acá asociamos la PDP que captura los datos al momento de crear el proyecto. Revisar el artículo que explica cómo crear PDPs.
• Default: este dato es importante porque el EPT marcado como predeterminado es el que se utiliza si se crear un proyecto desde Project Pro.
• Departments: útil como opción de filtro, para ver sólo los EPTs correspondientes a un departamento
• Image
• Order
• Project Plan Template
• Project Site Template

Quedará creado el EPT. Las fases y tareas que el EPT utilizará, es parte de la programación que se hace en Visual Studio.

Leer más...

Workflow en Project Server 2010 ¿Cómo crear una PDP?

Las PDPs (Project Details Pages) permiten mostrar o capturar información dentro de un flujo de trabajo de trabajo. Técnicamente son páginas de elementos web de SharePoint que utilizan normalmente elementos web propios de Project Server, pero que también pueden alojar elementos web de SharePoint o elementos construidos por nosotros.

Las PDPs pueden ser usadas para:

• El inicio de un proyecto, requerido para EPTs que usen flujos de trabajo
• Para mostrar el estado de un flujo de trabajo
• Para que un usuario edite información

A continuación se enumeran los pasos para crear una PDP:

 

Ir a la sección de PDPs

Ir a Project Server / Server Settings / Workflow and Project Details Pages

Clic en Project Details Pages

 

Crear la página

Clic en New Document

Completar el nombre, elegir el layout y presionar Create:

 

Agregar los elementos web

En en el área “Left Column” clic en “Add a Web Part”

Seleccionar la categoría Project Web App y el elemento web Project Fields. Este elemento nos permitirá capturar información en campos personalizados.

Agregar los campos que necesitamos que se muestren en esta PDP haciendo uso de la opción Displayed Project Fields:

A modo de ejemplo, puede quedar algo así:

Luego hacer clic en Apply y en Stop Editing.

Por supuesto, pueden agregarse otros elementos web de SharePoint o PWA en este punto.

La página quedará creada de la siguiente forma:

 

Configurar el tipo de página

Como se mencionó anteriormente, existen tres tipos de páginas para las PDPs. Este dato se configura editando las propiedades de la página. En este ejemplo, utilizaremos el valor “New Project”:

 

Ese fue el último paso. Luego, al crear las etapas del flujo de trabajo y los EPTs, se hará uso de cada PDP creada.

Leer más...