WSS 3.0 & MOSS: Creación de actividades para SD 2007!

Hace un par de semanas veíamos como crear un workflow de máquina de estados para plataforma SharePoint. Como sabéis, este tipo de workflows para SharePoint sólo se pueden crear con Visual Studio y las plantillas específicas de creación de workflows. Ahora bien, esto no es así en el caso de workflows secuenciales puesto que los podemos crear con Visual Studio 2005 o bien de manera más rápida y visual (aunque limitada) utilizando SharePoint Designer 2007 (SD 2007)…¿cuáles son las diferencias fundamentales entre estas dos posibilidades de creación de workflows para SharePoint? Pues hay varias y a modo de resumen:

Worflows diseñados con el Diseñador VS 2005 Workflows diseñados con Sharepoint Designer 2007
Se pueden escribir workflows para WSS o MOSS Se pueden escribir workflows para WSS o MOSS
Los archivos de código permiten escribir código customizado para modelar procesos de negocio El fichero de reglas de workflow encapsula los procesos de negocio
Se pueden asociar a múltiples sitios y listas Sólo se pueden asociar a una única lista en tiempo de diseño
Los distintos ficheros que componen el workflow se compilan en un assembly Los distintos ficheros que componen el workflow se almacenan sin compilar en una librería de documentos específica de WSS
El workflow (template) ha de estar asociado con cada lista o elemento en que debe estar disponible La asociación (automática) se da en el momento en que se crea el workflow en una cierta lista
Se puede usar cualquier tipo de formulario: ASPX o InfoPath Solo se pueden utilizar formularios de tipo ASPX
Se pueden incluir modificaciones en el workflow No permite incluir modificaciones en el workflow
Se puede crear actividades customizadas Sólo se pueden usar las actividades disponibles
El assembly y definición del workflow se empaquetan como una feature de WSS, y luego se despliegan en el sitio (manual) El despliegue es realizado de forma automática
Se puede usar un formulario de inicialización para recoger información del usuario cuando se arranca el workflow Se puede usar un formulario de inicialización para recoger información del usuario cuando se arranca el workflow
Se pueden usar formularios customizados para interactuar con tareas de WSS Se pueden usar formularios customizados para interactuar con tareas de WSS
Disponible debugging de VS No es posible el modo debugging
Se pueden crear workflows secuenciales y de máquina de estados Sólo se pueden crear workflows de tipo secuencial

Cómo ya comentaba hace tiempo Carlos Segura en un par de posts (este y este otro), las piezas para la creación de workflows con SD 2007 son las actividades que tengamos disponibles. Estas actividades en el fondo son actividades de Windows Workflow Foundation (WF), pero específicas para SD 2007 y que en este entorno se clasifican en dos tipos: acciones y condiciones. La idea de este post es refrescar los conceptos básicos (que Carlos ya nos explicó) de creación de acciones para SD 2007 y detallar como crear una condición para SD 2007. Empecemos.

Creación de acciones para SD 2007

El cometido de la acción a crear dentro de SD 2007 será determinar y asignar una fecha laboral (de lunes a viernes) a un ítem de una lista o librería de documentos. Lo primero que haremos es crear un proyecto de actividad de workflow. Para ello ejecutamos VS 2005y dentro de los proyectos de tipo C# seleccionamos la opción Workflow. Veremos que VS 2005 nos da varias plantillas de proyecto para crear workflows. Seleccionamos la plantilla Workflow Activity Library.

image image

Una vez creada la actividad, el siguiente paso es añadirle las propiedades y métodos necesarios para modelar su comportamiento (nos vamos a la vista de código de la actividad). Empecemos por las propiedades. Para la definición de las propiedades, vamos a aprovechar las facilidades que nos aporta VS2005 a través del uso de code snippets. Para ello, y debajo del constructor de la actividad pulsamos el botón derecho y a continuación las opciones: Insert Snippet.. -> Workflow -> DependencyProperty – Property. De este modo podremos crear una propiedad vinculada a nuestra actividad.

image image image

Dentro del código que nos genera el snippet, introducimos los siguientes cambios:

§  myProperty, por WorkingDayDate.

§  Type,  de tipo DateTime.

§  Description, Working Day Date.

§  Category, GetWorkDayDate.

Al introducir estos cambios, el código debería ser similar al siguiente:

public static DependencyProperty WorkingDayDateProperty =

System.Workflow.ComponentModel.DependencyProperty.Register(“WorkingDayDate”,

typeof(DateTime), typeof(GetWorkDayDate));

[Description(“Working Day Date”)]

[Category(“GetWorkDayDate”)]

[Browsable(true)]

[DesignerSerializationVisibility(DesignerSerializationVisibility.Visible)]

public DateTime WorkingDayDate

{

get

{

return ((DateTime)(base.GetValue(GetWorkDayDate.WorkingDayDateProperty)));

}

set

{

base.SetValue(GetWorkDayDate.WorkingDayDateProperty, value);

}

}

En mi caso, la acción a crear tendrá otras dos propiedades de dependencia que se crean siguiendo el método comentado. Una vez creadas las propiedades, vamos a añadir los métodos correspondientes a la actividad. En particular, vamos a añadir un método Execute a nuestra actividad para poder calcular un día laboral válido teniendo en cuenta que el mismo tiene que estar comprendido entre el lunes y viernes de una semana cualquiera. Para ello sobreescribimos el método Execute de nuestra actividad. El código necesario sería el siguiente:

protected override ActivityExecutionStatus Execute(ActivityExecutionContext executionContext)
{
    DateTime dt = DateTime.Now;
    switch (this.Unit)
    {
        case “days”:
            dt=dt.AddDays(this.AddValue);
            break;
        case “months”:
            dt = dt.AddMonths(this.AddValue);
            break;
        case “years”:
            dt = dt.AddYears(this.AddValue);
            break;
        default:
            break;
    }

    if (dt.DayOfWeek==DayOfWeek.Saturday)
    {
        WorkingDayDate = dt.AddDays(-1);
    }
    if (dt.DayOfWeek == DayOfWeek.Sunday)
    {
        WorkingDayDate = dt.AddDays(+1);
    }

    return ActivityExecutionStatus.Closed;
}

Lo que hace el código anterior es añadir el número adecuado de días/semanas/meses a la fecha actual y modifica el resultado para obtener un día comprendido dentro de la semana laboral. Compilamos la solución para asegurarnos que no hay errores. Una vez compilado, lo que hacemos es firmar el ensamblado para darle un strong-name. Una vez que tenemos compilado y firmado el ensamblado de la actividad, ya estamos listos para desplegarla y usarla con SD 2007 como una custom action. Lo primero que tenemos que hacer es copiar el assembly generado al compilar al proyecto en la GAC de la máquina dónde tenemos instalado SD 2007, así como en la GAC del servidor de WSS 3.0 & MOSS dónde vamos a crear los workflows.

Lo siguiente que tenemos que hacer es modificar el archivo web.config de la web application en la que vamos a crear workflows con SD 2007:

·         Abrimos el archivo web.config (con el bloc de notas o Visual Studio).

·         Añadimos el assembly en la sección authorizedTyes (que especifica la lista de ensamblados que se permiten en la web applications) añadiendo lo siguiente:

<authorizedType Assembly=”WorkDayDate, Version=1.0.0.0, Culture=neutral,

PublicKeyToken=5edf8dddd72c45e5” Namespace=”WorkDayDate” TypeName=”*” Authorized=”True” />

  • Creamos un archivo denominado WorkDayDate.actions (con el bloc de notas o Visual Studio) ubicado en Program FilesCommon FilesMicrosoft Sharedweb server extensions12TEMPLATE1033workflow.  Le añadimos a este archivo el siguiente contenido:

<?xml version=”1.0″ encoding=”utf-8″?>

<WorkflowInfo Language=”en-us”>

<Actions Sequential=”then” Parallel=”and”>

<Action Name=”Get Working Day Date”

ClassName=”WorkDayDate.GetWorkDayDate”

Assembly=”WorkDayDate, Version=1.0.0.0, Culture=neutral,

PublicKeyToken=5edf8dddd72c45e5″

Category=”Custom”

AppliesTo=”all”>

<RuleDesigner Sentence=”Get Nearest Working Day %1 %2

from current date (store in %3)”>

<FieldBind Field=”AddValue” DesignerType=”Integer” Text=”Number” Id=”1″/>

<FieldBind Field=”Unit” DesignerType=”Operator”

OperatorTypeFrom=”DropDownMenu”

Text=”timeframe” Id=”2″>

<Option Name=”days” Value=”days”/>

<Option Name=”months” Value=”months”/>

<Option Name=”years” Value=”years”/>

</FieldBind>

<FieldBind Field=”WorkingDayDate” DesignerType=”parameterNames”

Text=”WorkingDayDate” Id=”3″/>

</RuleDesigner>

<Parameters>

<Parameter Name=”AddValue” Type=”System.Int32, mscorlib” Direction=”In” />

<Parameter Name=”Unit” Type=”System.String, mscorlib” Direction=”In” />

<Parameter Name=”WorkingDayDate” Type=”System.DateTime, mscorlib”

Direction=”Out” />

</Parameters>

</Action>

</Actions>

</WorkflowInfo>

El listado anterior nos permite que la actividad sea accesible en SD 2007 y configura como es visualizada por el usuario que la va a utilizar desde SD 2007.

·         Hacemos un IIS Reset desde la línea de comandos.

     Una vez que ya hemos desplegado la actividad para ser utilizada como una custom action de SD 2007, ya estamos listos para utilizarla en SD 2007. Para ello, nos vamos a SD 2007 y creamos un nuevo flujo de trabajo asociado a una lista o biblioteca de documentos de SharePoint:

image image

En la pantalla de diseño del workflow seguimos los siguientes pasos:

  • Pulsamos sobre Actions.
  • Seleccionamos la opción More Actions…
  • En la ventana que se abre:
    • Seleccionamos Custom en el combo Select a Category. 
    • En el listado que se muestra aparecerá nuestra actividad customizada: Get Working Day Date. La seleccionamos y nos aparecerá como acción del workflow de acuerdo al formato especificado en el archivo WorkDayDate.ACTIONS.

image 

Creación de una condición para SD 2007

Estas condiciones de no son más que simples clases que contienen al menos un método estático (compartido).  En nuestro caso, tenemos dos posibilidades para crear nuestras propias custom conditions:

  1. Seguir la filosofía de la sección anterior, crear un proyecto de tipo class library y añadirle el método o métodos estáticos que se consideren necesarios.
  2. Aprovechar el trabajo realizado en la sección anterior y añadirle a la custom action el método o métodos estáticos que se consideren oportunos

Vamos a seguir la opción 2. que implica que no es necesario modificar el archivo web.config.

image

Una vez creada la clase, simplemente tenemos que añadirle un método estático a la clase. Este método estático tiene que devolver obligatoriamente un valor True. 

        public static bool ReturnTrue()       
                {
           
                return true;
       
                }

Una vez añadido el método a la clase, compilamos todo el proyecto para asegurarnos que no hay ningún error.Para hacer el despliegue de la Custom Condition, tenemos que repetir algunos de los pasos seguidos en el despliegue de la Custom Action mostrado en el apartado anterior. En concreto:

  • Copiar de nuevo el assembly del proyecto en la GAC.
  • Modificar el archivo WorkDayDate.Actions añadiendo el siguiente contenido al que ya tiene el archivo: 

<Conditions>

                               <Condition Name=”AlwaysTrue”

                                  FunctionName=”ReturnTrue”

                                  ClassName=”WorkDayDate.GetWorkDayDate”

                                  Assembly=”WorkDayDate, Version=1.0.0.0, Culture=neutral, PublicKeyToken=5edf8dddd72c45e5″

                                     AppliesTo=”list”  UsesCurrentItem=”true”>

                                               <RuleDesigner Sentence=”true”>                                                       

                                               </RuleDesigner>

                                               <Parameters>                                                      

                                               </Parameters>

                               </Condition>

                </Conditions>

  • Realizar un IIS Reset.

Para probar que la condición está disponible en SD 2007, seguimos los pasos ya comentados en la sección anterior. En este caso, tendremos que pulsar sobre Conditions y luego sobre nuestra Custom Condition que aparecerá disponible:

image 

Sin más, hasta aquí llega lo que os quería contar con respecto a la creación de custom actions y condiciones para ser utilizados en SD 2007 y dotar así de mayor poder y capacidad a los workflows que podamos crear con esta herramienta. Espero que el post os haya resultado interesante.

Publicado por

Juan Carlos González

Juan Carlos es Ingeniero de Telecomunicaciones por la Universidad de Valladolid y Diplomado en Ciencias Empresariales por la Universidad Oberta de Catalunya (UOC). Cuenta con más de 12 años de experiencia en tecnologías y plataformas de Microsoft diversas (SQL Server, Visual Studio, .NET Framework, etc.), aunque su trabajo diario gira en torno a SharePoint & Office 365. Juan Carlos es MVP de Office Servers & Services desde 2015 (anteriormente fue reconocido por Microsoft como MVP de Office 365 y MVP de SharePoint Server desde 2008 hasta 2015), coordinador del grupo de usuarios .NET de Cantabria (Nuberos.Net, www.nuberos.es), co-fundador y coordinador del Grupo de Usuarios de SharePoint de España (SUGES, www.suges.es), así como co-director de la revista gratuita en castellano sobre SharePoint CompartiMOSS (www.compartimoss.com). Hasta la fecha, ha publicado 8 libros sobre SharePoint & Office 365 y varios artículos en castellano y en inglés sobre ambas plataformas.

3 comentarios en “WSS 3.0 & MOSS: Creación de actividades para SD 2007!”

  1. Hola Juan Carlos, gracias por el post, es muy interesante, hasta hace poco solo habia realizado flujos desde VS2005, pero ahora que he intentado hacer una acción que copie un item de una lista/biblioteca ha otra, sin importar el sitio donde se encuentra, con un flujo normal usaria “workflowProperties.Item.CopyTo”, pero con una accion para SD ¿Como puedo hacerlo?.
    Gracias

  2. Hola Diego,
    Gracias…pues básicamente, te puedes crear una acción personalizada y reutilizar el código que ya has utilizado en tus workflows…tendrías que tu sitio origen es fijo en cuanto a que lo vinculas con SD 2007, pero el destino lo puedes especificar en tu código…

    Un saludo

    JC’s

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *