Migrar y desinstalar flujos de trabajo de Visual Studio en MOSS 2007 Parte II

Después de continuar con la investigación sobre la implementación y migración con flujos de trabajo de Visual Studio 2008 me encontré con una herramienta que facilita esta tarea.

Dentro de las herramientas de Microsoft VSTO Power Tools 1.0 se encuentra una utilería llamada "Workflow Package Generator", con esta herramienta podemos encapsular los flujos de trabajo para SharePoint creados en Visual Studio 2008 y el Windows Workflow Foundation. Una vez que se hayan instalado las herramientas solo es necesaria la siguiente línea de comandos:

“c:\Program Files\Microsoft VSTO Power Tools 1.0\workflowpackagegen.exe" /featureManifest:feature.xml

La utilidad se basa en el feature.xml para saber que información contiene la característica, en este caso, la información contenida en el workflow. También puedes agregar procesos a tu Visual Studio para crear el wsp usando esta utilería cada vez que implementas tu solución.

Una vez que tengas el archivo WSP se vuelve mucho mas fácil migrar el flujo de trabajo o implementarlo en diversos ambientes.

Mostrar datos de cualquier lista en la granja.

Como saben, las características nativas de MOSS nos permiten mostrar información de listas que se encuentren dentro de la misma colección de sitios, ya sea con la WebPart de Consulta de Contenido, desde SharePoint Designer con ListView y los orígenes de datos. Sin embargo, cuando intentamos mostrar información de listas que se encuentran en otras colecciones de sitios o aun en distintas aplicaciones, se complica el asunto. Lo mismo sucede con WSS que no cuenta con la WebPart de consulta de contenido, y no todos los usuarios están tan familiarizados con SPD, más aun, no todas las empresas

Para solucionar estos problemas existen WebParts de la comunidad, las hay de varios tipos, encontré tres de ellas que me pareció importante compartir con ustedes:

http://www.endusersharepoint.com/2009/09/16/aggregating-across-site-collections/

http://www.novolocus.com/2008/07/24/content-roll-up-options-conclusions/

http://blogs.infosupport.com/blogs/porint/archive/2006/11/14/WSS-v3-Solution-and-Feature-framework-applied-to-the-FlexListViewer-webpart.aspx

Son dos las opciones que me llamaron mas la atención:

FlexListViewerMoss (http://blogs.infosupport.com/media/p/10976.aspx)

Lightning Conductor Web Part (http://www.lightningtools.com/pages/lightning-conductor-web-part.aspx)

1. El primero es gratis y nos presenta la oportunidad de mostrar información de cualquier lista en la granja, inclusive puede mostrar directamente una vista, como una solución básica y flexible es de mucha ayuda.

2. La segunda es una WebPart de paga que es muy configurable y poderosa, cuenta con una versión de evaluación para revisar la funcionalidad de la misma.

Mi recomendación es que evalúen todas las posibilidades y al final decidan cual es la mejor opción para su ambiente, considerando si necesitan liberar estas WebParts al usuario, permitir que las personalice o bien solo desean mostrar información de una lista en un caso especifico, eviten un "overkill".

Posteriormente realizare un análisis mas exhaustivo de comparación para este tipo de WebParts.

Migrar y desinstalar flujos de trabajo de Visual Studio en MOSS 2007

Los flujos de trabajo de Visual Studio con las extensiones para SharePoint, en conjunto con el .NET Framework 3.5 y el Windows Workflow Foundation proporcionan una herramienta muy potente para manejar la lógica de un proceso de negocio y si bien existen herramientas como SharePoint Designer que permiten realizar flujos de trabajo con 0 programación, conforme la complejidad o longitud de estos avanza, se vuelve más complicado mantener una estructura entendible y/o eficiente.

El tema de los flujos de trabajo es enorme y ya iré abarcando el tema poco a poco, una de las primeras preguntas cuando uno genera su primer flujo de trabajo es como se instala, claro, si tenemos la facilidad de un F5 y listo en Visual Studio, pero si se quiere instalar el mismo flujo de trabajo en un ambiente que no tenga Visual Studio, se pensaría que el paso sería el mismo que con Webparts o receptores de eventos, ir a la carpeta, copiar el WSP y el setup.bat, ejecutarlo y listo... pero, los flujos de trabajo no funcionan así!.

Lo mismo sucede cuando intentas desinstalarlo por primera vez, no hay un "setup -uninstall" que nos ayude, así que sin más veamos cómo se resuelven estos problemas dividiendo esto en dos simples secciones: Instalación y Desinstalación.

Instalando (o migrando) un flujo de Trabajo.

Los flujos de trabajo se implementan por medio de una característica (feature) por lo que toda la información necesaria para que el flujo de trabajo funcione se encuentra en dos sitios, la carpeta de la característica y el ensamblado como tal.

La carpeta la podemos encontrar en la ruta de instalación de SharePoint, por ejemplo: "C:\Program Files\Common Files\microsoft shared\Web Server Extensions\12\TEMPLATE\FEATURES", el nombre de la carpeta corresponde al nombre que hayamos declarado al crear el Workflow (para los que tengan tan mala memoria como yo, el nombre también está dentro de los archivos feature.xml y workflow.xml), de no tener un ambiente que tenga previamente instalado el Workflow y por consecuencia no ver esta carpeta simplemente crea una carpeta con el nombre de tu Workflow que contenga los archivos feature.xml y workflow.xml que genera Visual Studio automáticamente.

El ensamblado lo puedes copiar del directorio de tu solución o bien tomar el que se encuentra en el GAC (de un entorno que ya tenga el flujo de trabajo instalado) con una herramienta externa.

Copia estos dos elementos a tu servidor destino, dejando la carpeta en el lugar correspondiente a las características, e instalando tu ensamblado en el GAC (o como muchos prefieren en la carpeta bin) ya sea con alguna herramienta o manualmente pegando el .dll en la carpeta "C:/Windows/assembly", si la seguridad del servidor no te permite esta instalación manual, puedes hacerlo con un workaround desde cmd (tema aparte, si alguien lo necesita lo agrego).

Por ultimo hay que instalar la característica y activarla en el sitio correspondiente, esto por medio del stsadm, que se encuentra en ""C:\Program Files\Common Files\microsoft shared\Web Server Extensions\12\bin", dependiendo del directorio de instalación, lenguaje y sistema operativo. Sitúate en dicha carpeta dentro de una ventana de consola y ejecuta las siguientes instrucciones reemplazando "MiFlujo" por el nombre de tu flujo de trabajo y "misitio" por el sitio donde instalaras el mismo, incluyendo el puerto:

stsadm -o installfeature -name MyFlujo

stsadm -o activatefeature -name MyFlujo -url http://misitio:81

Una vez que todo se haya instalado y activado ya puedes asociar tu flujo de trabajo a la(s) lista(s) que corresponda(n), antes, asegúrate que todos los elementos que necesita el flujo de trabajo ya se encuentran en el servidor, como pueden ser listas adicionales que consulte durante el proceso, o cualquier nombre que hayas puesto en código duro (lo cual no es recomendado..).

Felicidades ya has migrado tu primer flujo de trabajo!.

Desinstalando un flujo de trabajo.

Cuando tenemos un flujo de trabajo de SharePoint Designer, basta con eliminarlo desde el mismo para cumplir este punto, mas sin embargo los flujos de trabajo de Visual Studio son en realidad esto, flujos que podemos reutilizar para n número de elementos, creando instancias en diferentes listas que podrían a su vez tener un comportamiento diferente usando los formularios de iniciación, en fin, eliminar el flujo de la lista solo quitara la instancia que se ejecutaba en esa lista, no desinstala el flujo de trabajo como tal.

Si has leído la primera parte de este post no te será tan difícil comprender como se puede desinstalar un flujo de trabajo, de lo contrario no te preocupes y sigue leyendo que pronto entenderás.

El flujo de trabajo es una característica y para desinstalarlo hay que tratarlo como tal, abre una ventana de consola (cmd) y accede a la ruta de instalación de SharePoint , en la carpeta bin (""C:\Program Files\Common Files\microsoft shared\Web Server Extensions\12\bin" usualmente). Una vez en este directorio ejecuta las siguientes líneas reemplazando los parámetros con los que correspondan a tu flujo de trabajo:

stsadm -o deactivatefeature -name MyFlujo -url http://localhost:81

stsadm -o uninstallfeature -name MyFlujo

Puedes usar el id de tu flujo de trabajo en lugar del nombre, o ambos si asi lo decides, estos se encuentran en los archivos feature.xml y workflow.xml que crea Visual Studio automáticamente.

Con esto el flujo de trabajo ya no aparecerá en las opciones para asociar nuevos flujos a una lista, así mismo, los elementos aun se encuentran físicamente en el servidor, tanto la carpeta de la característica en "C:\Program Files\Common Files\microsoft shared\Web Server Extensions\12\TEMPLATES\FEATURES" como en ensamblado en el GAC (o en el bin si ahí lo instalaste), puedes remover estos elementos manualmente.

Conclusiones.

Como ven el proceso para instalación y desinstalación de flujos de trabajo no es tan complejo como parecería a primera vista, y se puede automatizar aun mas por medio de paquetes como wsp, archivos bat, instaladores de codeplex, etc.

Espero haber resuelto algunas dudas y creado algunas otras, deja tus comentarios si te gustaría que ampliara la información en algún tema, o bien, si tienes dudas o comentarios, la crítica es bien recibida también.

Obtener campos especificos de un item con Linq to SharePoint

Una entrada breve para describir como podemos obtener con linq los valores que necesitamos de un item, la consulta es sencilla, hay que establecer una condicion para obtener el item que necesitamos (en este caso lo hago en base al ID del item) y despues seleccionar los campos que usaremos y de donde obtendran la informacion:

using (SPSite miSitio = new SPSite(SPContext.Current.Site.ID))

{

using (SPWeb miWeb = miSitio.OpenWeb(SPContext.Current.Web.ID))

{

SPList miLista = miWeb.Lists["nombreLista"];

var res = from renglon in miLista.Items.Cast()

where renglon.ID == int.Parse(Lista.SelectedValue)

select new

{

Nombre = renglon["campoNombre"],

Direccion = renglon["campoDireccion"],

};

}

}

Una vez con esto podemos acceder a la informacion en los resultados de la forma en la que queramos, ya sea usandolo como datasource, convirtiendolo en lista, en datatable, o bien si solo se trata de un item como en este caso obtener la informacion directamente, por ejemplo:

res.AsEnumerable().Single().Nombre.ToString();

Esto nos regresara una cadena que podemos usar para cualquier cosa!

Validando un Control PeopleEditor en SharePoint

Bueno, hace poco tuve que validar uno de estos controles para un requerimiento, y buscando información encontré algunas referencias que mencionaban cosas como que no era posible usar controles de valuación para controles de SharePoint, así como preguntas en general sobre como utilizar la lógica de estas validaciones.

Según la experiencia que tuve esta ocación me pareció algo muy sencillo sin embargo aquí incluyo alguna información del mismo para aquellos que tengan problemas sobre este tipo de validaciones.

El control PeopleEditor cuenta con métodos de validación propios, que funcionan a través de algunas propiedades que nosotros establecemos, las propiedades mas comunes son:

PeopleEditorEjemplo.AllowEmpty = false;

PeopleEditorEjemplo.MultiSelect = false;

PeopleEditorEjemplo.ValidatorEnabled = true;

PeopleEditorEjemplo.SelectionSet = "User";

Con esto nos aseguramos que el control no pueda o no estar vació, contar con selecciones múltiples, y que puedan seleccionar solo usuarios o grupos, existen propiedades adicionales por ejemplo, para establecer los grupos que estén disponibles.

Una vez que se tengan establecidas las propiedades solo es necesario llamar el método correspondiente para validar el control:

void btnAceptar_Click(object sender, EventArgs e)

{

PeopleEditorEjemplo.Validate();

}

Con esto el control se validara y mostrara el error correspondiente debajo del control, los mensajes de error dependen de la conflagración de lenguaje de SharePoint. Ejemplo de validación:

Espero les sirva de algo en sus futuros desarrollos.

Establecer permisos de Item en un receptor de eventos programaticamente parte 1

Supongamos que es necesario que cada item de una lista tenga permisos distintos dependiendo de campos especificos que el usuario llena a la hora de crear un item, por ejemplo en una lista de tareas donde queramos que las tareas sean visibles para todos si no estan asignadas a nadie, per que solo un grupo en especifico pueda editarlas, para esto podemos ayudarnos de un receptor de eventos que lea esta informacion y modifique los permisos del item de acuerdo al requerimiento.


El primer paso es el crear un receptor de eventos, puedes ayudarte con las extensiones para Visual Studio que cuentan con una plantilla para la generación de receptores de eventos, esta plantilla no es visible en la creacion de una solucion, solo esta disponible cuando agregas un elemento nuevo a la solucion ya existente. No entrare en detalles en este tema a menos que les interese en cuyo caso dejen sus comentarios.

Sea cual sea el metodo por el que creas el receptor de eventos este debe atrapar el evento ItemAdded, si utilizaste las extensiones solo debes de quitar los tags de comentarios ("//"), ojo, no quites los tags de la descripcion del evento ("///").

Ahora debemos ejecutar el codigo con privilegios elevados, ya explicare la razon de esto mas adelante:

SPSecurity.RunWithElevatedPrivileges(delegate() { using (SPSite miSitio = new SPSite(properties.SiteId)) { using (SPWeb miWeb = miSitio.OpenWeb(properties.WebUrl.Replace(miSitio.Url,""))) {

Con esto lo que hacemos es delegar todo nuestro codigo para ejecutarse con privilegios elevados, en base a estos privilegios obtenemos los objetos SPSite y SPWeb correspondientes al contexto en el que se ejecuto el evento, es muy importante que al crear el sitio lo hagan haciendo referencia al ID del sitio (properties.SiteId) y no lo tomen el sitio del contexto o el sitio como tal, ya que estos incluyen las credenciales del usuario actual; en caso de el SPWeb si solo utilizamos el metodo OpenWeb sin mandarle parametros tambien tendremos problemas con el tipo de credenciales que manejan, es por esto que se le envia la direccion relativa del subsitio actual (por eso se elimina el inicio de WebUrl ya que este incluye la direccion completa del subsitio).

Ahora que tenemos los componentes principales, podemos emepzar a obtener los datos que necesitamos:

miWeb.AllowUnsafeUpdates = true;

SPRoleDefinition RoleDefinition = miWeb.RoleDefinitions.GetByType(SPRoleType.Contributor);

SPListItem miItemActual = miWeb.Lists[properties.ListId].GetItemById(properties.ListItemId); miItemActual.BreakRoleInheritance(true);

miWeb.AllowUnsafeUpdates = true;

while (miItemActual.RoleAssignments.Count > 0)

{

miItemActual.RoleAssignments.Remove(0);

}

Explicando el codigo anterior lo que hacemos es permitir las actualizaciones en la web que obtuvimos (que es un requisito para ejecutar BreakRoleInheritance), despues obtenemos la definicion de rol de Contribuir, puedes cambiar este usando el enum SPRoleType, despues obtenemos el item asociado al evento (ojo aqui vuelvo a hacer referencia al ID de la lista y el item para obtenerlo, si haces referencia directa tendras problemas en el codigo).

En la siguiente parte explicare como crear definiciones de rol de uso.

Error con Flujos de Trabajo recursivos con SharePoint Designer

Microsoft ha dado una explicación oficial a lo que muchos ya sabíamos, a partir del Service Pack 2 para Windows SharePoint Services y Microsoft Office SharePoint Server los flujos recursivos ya no son permitidos.

Impacto

Principalmente los flujos de trabajo que se ven a

• Si creas un flujo de trabajo que envíe una alerta por correo electrónico periódicamente para tareas comunes (respaldos manuales de listas, depuración, informes de uso, etc). Estos flujos no tienen un fin definido, pero pude que el requerimiento este justificado.
  
• Flujos de trabajo que se ejecutan mientras se cumpla una condición especifica (por ejemplo siempre que un elemento muestre un rendimiento debajo del 70%).
  
• Flujos que simulen un State Machine Workflow, ya que para mover el flujo entre cada estado se ejecuta una nueva instancia del mismo. (pueden ver un ejemplo de este en un post de Adnan Farooq Hashmi en ingles).

Justificación

La razón de ser de esta restricción según el anuncio de Microsoft es el problema que al crear un flujo de trabajo que se dispare cuando se modifique un elemento y este mismo flujo realize una molificación al elemento creara un ciclo infinito que muchas veces no es la intención del usuario, pero si admiten que puede ser un requerimiento valido realizar dicho flujo, por lo que proponen una solución a este tipo de requerimientos.

Solución

Existen dos soluciones, o crear el flujo de trabajo por medio de Visual Studio.

La segunda opción es utilizar 2 flujos de trabajo para evitar la restricción impuesta, esto es algo que si bien no complicado se vislumbra laborioso, especialmente para aquellos que tienen muchos flujos de este tipo, demasiado largos o complejos, puesto que necesitan recrear el mismo flujo, así cada uno de ellos se quedara "estancado" en un ciclo, pero el flujo espejo podrá avanzar en su lugar. Para implementar esto se puede copiar el flujo de trabajo pero al intentar implementar el mismo flujo dos veces entran en conflicto, aunque no he realizado pruebas exhaustivas en cuanto a este punto y tampoco he encontrado una herramienta que exista actualmente que te permita recrear el flujo cambiando los IDs y GUIDS asociados.

La ultima forma es un poco mas compleja apunta a que al terminar un flujo de trabajo inicializes el siguiente y viceversa, esto lo puedes hacer con ayuda de las custom activities que estan en codeplex, terminas un flujo "A" e inicializas el flujo "B" que a su vez volverá a iniciar "A".

Conclusiones

Las pruebas que he realizado hasta ahora indican que la segunda solución es la mas viable pero menos recomendada en términos de rendimiento y mejores practicas, la solución de visual studio esta siempre sujeta a los tiempos y complejidad del requerimiento y la ultima opción significa modificar el comportamiento del flujo, tal vez inclusive la estructura.

A mi parecer lo que hace Microsoft es volver SPD un producto mas seguro para usuarios finales o personas que no estén relacionadas muy a fondo con conceptos del desarrollo básicos como la recursividad. Este cambio responde al hecho de que un flujo de trabajo infinito puede llegar a consumir grandes recursos en el servidor, y al parecer es mucho mas común equivocarte y crear un flujo de este tipo sin querer a hacerlo con plena conciencia de lo que pretendes, lo cual representa un problema para aquellos que utilizábamos SPD para este tipo de trabajos debido a la rapidez con la que se genera un flujo.

No se puede mostrar el formulario porque no está disponible el estado de la sesión

Primera Leccion Aprendida, cuando no puedas ejecutar Flujos de Trabajo en un Servidor revisa la configuracion desde 0, es decir no solo la aplicacion sino que los servicios de busqueda y los servicios compartidos del servidor, el enlace hacia la pagina que me ayudo con esto:

Error al mostrar formularios de Flujos de Trabajo