JUAN PABLO PUSSACQ LABORDE : Workflow

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

Juan Pablo — Mon, 28 Jan 2013 20:52:45 GMT

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>

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.

Workflow en Project Server 2010 - Seguridad

Juan Pablo — Thu, 24 Jan 2013 18:20:59 GMT

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

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

Juan Pablo — Wed, 12 Dec 2012 20:57:38 GMT

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:

Se crear una lista en SharePoint que almacene la información de detalle.
Se modifica la pantalla de alta de esa lista con InfoPath para ocultar el campo de relación con el maestro: Project UID
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
Mediante conexiones, el filtro por URL provee el dato de ID del proyecto a los otros dos elementos web
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:

$(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!

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

Juan Pablo — Fri, 30 Nov 2012 15:50:54 GMT

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:

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.

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

Juan Pablo — Fri, 30 Nov 2012 15:24:01 GMT

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.

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

Juan Pablo — Thu, 29 Nov 2012 19:49:11 GMT

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

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

Juan Pablo — Thu, 29 Nov 2012 19:03:55 GMT

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.

Copia oculta en flujos de trabajo de SharePoint Designer 2007

Juan Pablo — Mon, 01 Oct 2012 19:47:15 GMT

Como ustedes saben, SharePoint Designer 2007 permite enviar correos electrónicos dentro de un flujo de trabajo, pero no permite especificar el campo “copia oculta”.

Existe una forma de resolverlo tal como se explica en este post (en inglés). En SharePoint 2010 es más sencillo, lo puede ver en este otro post.

Lo que se hace es usar el campo CC, pero luego, en el código hacer que en realidad CC funcione como BCC.

Los pasos son sencillos:

Completar el campo CC
Abrir el archivo XOML
Intercambiar las opciones CC y BCC
Desplegar el flujo de trabajo

A continuación las pantallas:

En esta pantalla se ve como no aparece la opción de BCC. En nuestro caso, completaremos de todas formas las opciones TO y CC.

Una vez desplegado el flujo de trabajo, buscamos el archivo XOML y lo editamos con el bloc de notas:

Encontraremos una línea como la siguiente:

<ns0:EmailActivity BCC="{x:Null}" x:Name="ID4" CC="{ActivityBind ROOT,Path=_x005f_ArrayList1}"

Intercambiamos BCC con CC como a continuación se muestra

<ns0:EmailActivity CC="{x:Null}" x:Name="ID4" BCC="{ActivityBind ROOT,Path=_x005f_ArrayList1}"

Salvamos y luego desplegamos nuevamente el flujo de trabajo abriéndolo y haciendo clic en “finish”. En este punto vamos a ver que nuestro campo CC ahora aparece nulo.

Como último punto, hacemos una prueba y veremos como el flujo de trabajo llega a destino.

Eso es todo, hasta la próxima!

¿Cómo cancelar todos los flujos de trabajo activos programáticamente?

Juan Pablo — Wed, 29 Aug 2012 13:26:16 GMT

La siguiente es una página de aplicación de SharePoint que permite cancelar todos los flujos de trabajo activos. Para ejecutarla, debe estar almacenada en la siguiente carpeta (o en una subcarpeta):

C:\Program Files\Common Files\microsoft shared\Web Server Extensions\12\TEMPLATE\LAYOUTS

Algunas consideraciones a tener en cuenta:

Esta página sólo cancela los flujos de trabajo de lista, pero no los de sitio (que existen desde SharePoint 2010)
Es posible que esta página tarde más de 6 minutos en ejecutar el código. En ese caso deberán modificar el web.config que se encuentra en la carpeta mencionada arriba, específicamente la línea <httpRuntime executionTimeout="360" />

A continuación el código. Espero les resulte útil!

<%@ Assembly Name="Microsoft.SharePoint, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c"%>  
<%@ Register TagPrefix="spuc" Namespace="Microsoft.SharePoint.WebControls"
             Assembly="Microsoft.SharePoint, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %>
<%@ Page Language="C#" MasterPageFile="/_layouts/application.master" 
         Inherits="Microsoft.SharePoint.WebControls.LayoutsPageBase" %>

<%@ Import Namespace="Microsoft.SharePoint" %>
<%@ Import Namespace="Microsoft.SharePoint.Workflow" %>
<%@ Import Namespace="System"%>
<%@ Import Namespace="System.Collections.Generic"%>
<%@ Import Namespace="System.Text"%>
<%@ Import Namespace="System.IO"%>

<script runat="server">
  protected override void OnLoad(EventArgs e) {

    FlujosTrabajo.Text = ""; // Salida por pantalla
    int i = 0; // Cantidad de flujos activos
    int s = 0; // Cantidad de sitios

    Error.Text = "Ejecución exitosa";

    try {
        using (SPSite oSite = new SPSite("http://Surpoint")) 
            {
            foreach (SPWeb oWeb in oSite.AllWebs)
//            using (SPWeb oWeb = oSite.OpenWeb("/Blog/"))
                {
                oWeb.AllowUnsafeUpdates = true;
                FlujosTrabajo.Text = FlujosTrabajo.Text + "Site: " + oWeb.Url + Environment.NewLine ;
                s = s +1;
                foreach (SPList list in oWeb.Lists)
                    {
                    // Verifico si la lista tiene flujos de trabajo
                    SPWorkflowAssociationCollection associationColl = list.WorkflowAssociations;
                    if (associationColl.Count >0)
                        {
                        FlujosTrabajo.Text = FlujosTrabajo.Text + " Lista: " + list.Title + " ("+ (list.Items.Count) +") [Workflows asociados: (" + associationColl.Count + ")]" + Environment.NewLine ;
                        for (int y=list.Items.Count-1;  y>=0; y--) 
                            {
                            SPListItem oItem = list.Items[y];
                            // Obtengo los flujos de trabajo activos para el ítem
                            SPWorkflowCollection wfs = oSite.WorkflowManager.GetItemActiveWorkflows(oItem);
                            if (wfs.Count >0)
                                {
                                   FlujosTrabajo.Text = FlujosTrabajo.Text + "  Ítem: " + oItem.ID + " [WF activos: (" + wfs.Count + ")]" + Environment.NewLine ;
                                for (int x=0;  x<wfs.Count; x++) 
                                    {
                                    SPWorkflow workflow = wfs[x];
                                    FlujosTrabajo.Text = FlujosTrabajo.Text + "   Workflow cancelado / ítem: " + workflow.ItemId;
                                    i = i + 1;
                                    // Cancelo el flujo de trabajo
                                     SPWorkflowManager.CancelWorkflow(workflow);
                                    FlujosTrabajo.Text = FlujosTrabajo.Text + " OK] " + Environment.NewLine ;
                                    }
                                }
                            }
                        }
                    }
                oWeb.AllowUnsafeUpdates = false;
                oWeb.Dispose();
                }
               FlujosTrabajo.Text = FlujosTrabajo.Text + Environment.NewLine + "*** Total de workflows cancelados: " + i + " ***";
               FlujosTrabajo.Text = FlujosTrabajo.Text + Environment.NewLine + "*** Total de sitios : " + s + " ***";
               Error.Text = Error.Text + Environment.NewLine + "*** Total de workflows cancelados: " + i + " ***";
            }
        }
    catch (Exception ex)
        {
        Error.Text = "*** Total de workflows cancelados: " + i + " ***";
        Error.Text = Error.Text + Environment.NewLine + "Error: " + ex.Message;
        }
}
    
</script>

<asp:Content ID="Main" runat="server" contentplaceholderid="PlaceHolderMain" >
<asp:TextBox ID="Error" runat="server" Visible="true" TextMode="MultiLine" Rows="3" Width="700px" />
<BR />
<asp:TextBox ID="FlujosTrabajo" runat="server" Visible="true" TextMode="MultiLine" Rows="20" Width="700px" />
</asp:Content>

Acciones de flujo de trabajo en SharePoint Designer 2010: Guía de referencia rápida

Juan Pablo — Sat, 11 Dec 2010 02:57:39 GMT

Les dejo este interesante enlace desde el sitio de Office de Microsoft que explica cada una de las acciones de SharePoint Designer 2010 para el manejo de flujos de trabajo:

http://office.microsoft.com/es-es/sharepoint-designer-help/workflow-actions-in-sharepoint-designer-2010-a-quick-reference-guide-HA010376961.aspx

Gracias a Mario Cortez por la información…

Acceso denegado en flujo de trabajo de SharePoint 2007

Juan Pablo — Sun, 21 Nov 2010 03:55:35 GMT

¿Alguna vez han tenido un error de acceso denegado al ejecutar un flujo de trabajo creado con SharePoint 2007 que sea totalmente inexplicable?

Pues yo sí, pero lo más raro fue la solución que encontré:

1) Ir a la carpeta en donde se encuentra el flujo de trabajo en SPD

2) Realizar un “check out”

3) Realizar un “check in”

Y luego, mágicamente (al menos para mi) se solucionó.

Gracias a este post que me iluminó el camino: http://www.binarywave.com/blogs/eshupps/Lists/Posts/Post.aspx?List=9c93c708-e5ce-4714-bdea-499330361130&ID=160.

Saludos y hasta la próxima!

Comparación de herramientas de terceros para el manejo de workflow en sharepoint

Juan Pablo — Wed, 03 Nov 2010 03:20:19 GMT

Les dejo un interesante artículo proveniente de Mrin's Blog que arriesga una comparación sobre un conjunto de herramientas de terceros para el manejo de flujos de trabajo en SharePoint.

Las herramientas comparadas son:

Nintex
K2
Virto Software
CorasWorks
Wirkflow Essentials
WorkBox SharePoint WorkFlow Manager
Kaldeera Workflow Designer

Pueden leer la información completa en este enlace: http://mrin17.wordpress.com/2010/05/12/third-party-workflow-solutions-for-sharepoint-comparison/.

Que les sea útil!

Nintex Workflow 2010 - Workflows for SharePoint made easy (amazing video)

Juan Pablo — Fri, 16 Jul 2010 19:01:44 GMT

Pueden ver además una breve descripción en el blog de Ignasi en este enlace: http://www.sharepointer.es/2010/07/ya-llego-nintex-2010.html:

Que les sea útil!

Seguridad a nivel de ítem en librerías de documentos

Juan Pablo — Sat, 05 Jun 2010 02:47:31 GMT

Como saben, SharePoint posee una interesante opción de parametrización para configurar el acceso a elementos de listas (ver imagen)

Lamentablemente, esta opción no está disponible en librerías de documentos. Buscando soluciones, encontré ...

Continuar leyendo en: http://surpoint.blogspot.com/2010/06/seguridad-nivel-de-item-en-librerias-de.html.

WebCast: Flujos de trabajo en SharePoint 2010: Novedades y mejoras

Juan Pablo — Tue, 13 Apr 2010 17:08:02 GMT

Desde el Grupo de Usuarios de SharePoint de España, SUGES, nuevo WebCast en el que tendrán la oportunidad de conocer las novedades en Flujos de trabajo en SharePoint 2010. De la mano de Pablo Peris, Director de Proyectos en Raona, repasaremos las mejoras y novedades para la creación y mantenimiento de flujos de trabajo en 2010. Empezaremos viendo las novedades del Visio 2010 y SharePoint Designer 2010 que nos permiten implicar al usuario en la tareas iniciales del desarrollo y acabaremos viendo la potencia de Visual Studio 2010 para extender y desplegar estos flujos. Tres herramientas renovadas que juntas dan soporte a todo el ciclo de vida de cualquier flujo en nuestro SharePoint 2010.

Continuar leyendo en http://surpoint.blogspot.com/2010/04/webcast-flujos-de-trabajo-en-sharepoint.html.

Nintex con workflows dentro de Project server 2010

Juan Pablo — Wed, 10 Mar 2010 22:58:59 GMT

Novedad publicada por Juan Alvarado en su blog. Transcribo:

Esto lo habia visto dentro del summit de MVP en una reunion con el grupo de project pero no se podia decir nada , hasta ahora que ya sacaron el anuncio oficial sobre que la compañia Nintex , muy famosa por el producto de workflows dentro de sharepoint, extiende su funcionalidad ahora con project server 2010. Este producto realmente es buenisimo debido a que puede crear workflows en forma visual e incorporarlos a los diferentes tipos de projects que tengamos dentro del project server. Esto es logico debido a que la infrastructura que usa Project Server 2010 es la misma de Sharepoint Server 2010.

Este es un producto mu recomendable y necesario cuando estamos en implementacion en empresas que necesitan incorporar el concepto de workflows dentro de los project. Actualmente tenemos que trabajar con Visual Studio y desarrollar alli el workflow usando el workflow fundation de windows, el mismo que se usa para CRM tambien. Sin embargo empresas medianas y pequeñas no tienen personal de desarrollo con esos skills necesarios para crear los workflows e implementarlos despues dentro de project server 2007. Sin embargo en Project server 2010 esto es mucho mas sencillo en workflows sencillos o de complejidad baja a mediana. Para los workflows complejos necesitamos soluciones como la de Nintex que me dejo una muy buena impresion desde que la vi. Una herramienta necesaria dentro de Project Server.

Les dejo el anuncio oficial sobre este producto.

Continuar leyendo en: http://juangyssa.spaces.live.com/Blog/cns!4AF18C3FF8E3FA4B!428.entry.