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.

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.