Save SharePoint DataView WebPart Roll Up Grouping

There's already plenty of blogs explaining how to create a data view web part that rolls up information across lists from a site collection so I won't be going into detail about that, you can however look up on these blogs for information on that:

http://zioed.wordpress.com/2011/10/24/using-a-data-view-web-part-to-create-a-cross-site-lists-rollup-view-office-365-sharepoint-online-and-sharepoint-2010/

http://blog.metrostarsystems.com/2011/10/03/jennys-sharepoint-tip-rollup-items-across-a-site-collection-by-creating-a-cross-list-data-view-web-part/

Writting this mostly as a self note, when you create a Roll Up dvwp, you need to be aware that any custom filtering, grouping, and headers that would change the xlst or parameters of the structure of the table, need to be set from Sharepoint Designer, such as Design -> Options -> Grouping toolbar.

After saving the results of these changes you can export your webpart to a site gallery or to a file, and add it to any normal sharepoint page, or just redirect to your custom site page.

Saving to gallery lets you add this webpart inside a webpart zone of a non site page without having to bother with SPD, and more over, to include this in a site template or to insert it in several sites, so you can re-use the code without doing it from scratch.

If you try to set group headers or filtering after, you won't see very good results.

Creación de paginas en MiSitio

Últimamente he estado trabajando en personalizaciones para MiSitio en MOSS 2007 y uno de los problemas que me encontré al intentar hacer esto fue el hecho de que los sitios no contienen bibliotecas de paginas o infraestructura de publicación para crear paginas como lo haríamos normalmente, también está el hecho de que todas las bibliotecas de documentos incluidas en el portal del usuario podrán ser modificadas por este, ya que el mismo es administrador de su propio sitio!.

Buscando la forma de crear una página o archivo que no perdiera las características con las que cuenta la pagina default llegue a la solución de copiar la misma página default.aspx.

SPFile f = miWeb.GetFile("default.aspx");

f.CopyTo(miWeb.ServerRelativeUrl + "DefaultCopia.aspx");

Con esto podremos copiar la pagina una vez que exista, personalizarla (por ejemplo para eliminar las webpats existentes y agregar webparts propias) y agregarla navegación.

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.