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.